This Week In Security: Signal, WhatsApp, Oauth Fishing, And More State-Sponsored Attacks

A bug was recently fix in Signal that allowed a caller to force a call connection without any user interaction on the receiving side. We’ve seen this sort of problem in other chat applications, most recently the Zoom debacle.

The Signal client uses the same function to connect an outgoing call as an incoming call. This bit of code re-use allows a malicious client to initiate a call, and then send the “Accept Call” message. Because of the code re-use, this message triggers the same code as the accept call button on the receiving side. It’s as if the attacker uses reverse psychology to trick the other client into connecting.

It seems this bug only affected the Android client, and didn’t trigger a video call. It’s unclear whether the bug was discovered and exploited before it was fixed, but now that it has been announced, be sure to get Signal up to date.

WhatsApp Gif of Death

WhatsApp was discovered to be vulnerable to a malicious GIF image. This is a double-free vulnerability, triggered in the GIF processing library. The library allocates a buffer for the image frame, and re-uses that buffer for frames of the same size. In the event of GIF frames that are a different size, the library re-allocates the buffer to be the proper size. If a frame is set to zero size, reallocarray() is called with a new size of zero, which is undefined behavior. On Android, it has the effect of freeing the memory block, and returning a pointer to the now freed memory. Calling this again results in a double-free condition, also undefined behavior, which corrupts the memory management data.

Once this double-free operation has been carried out, the next two memory allocations of matching sizes will point to the same location. This means that the program acts as if it has two separate buffers, but they are actually one and the same, allowing the data from a GIF frame to overwrite a function pointer in the GIF data struct. A clever bounce through another function, and the GIF has suddenly run arbitrary code.

OAuth Fishing

Google Attack Warning

You know it’s going to be an interesting day when Google warns you that your account is being attacked by a government entity. Amnesty International started the week off by describing a coordinated attack against several Egyptian organizations. This particular attack Isn’t the normal credential stealing attack, but instead tries to convince a user to authorize an OAuth application access to the account.

It may not be a particularly sophisticated attack, but the fact that the entire process happens while connected to the Google.com domain with a proper HTTPS certificate makes it just a little harder to spot. It does bypass two-factor authentication, in that once the malicious application has been given access to the account, no further logins are necessary.

Presidential Campaign Targeted

Microsoft has announced that one of the US presidential campaigns was targeted in an email compromise attempt. Nicknamed “Phosphorous”, the group’s attacks were simplistic, using personal data to attempt password resets and account recoveries. The fact that the attack included Iranian nationals living outside of that country leads one to suspect Iran as the sponsoring party.

We’ve briefly discussed attack attribution in the past, but this is a prime example of the difficulty of pinning down the people behind such an attack. What data does Microsoft have? The list of accounts targeted, the originating IP addresses, and perhaps some other metadata like browser user-agent strings. A naive look at that data would clearly reveal the attacker’s identity, but security, and history, should teach us not to take anything at face value. How difficult would it be for an attacker to include Iranian targets in their attack, launch from IP addresses that are associated with Iran, and spoof user-agents? It’s not likely, as this would be a more sophisticated effort than the attack itself, but such possibilities are extremely difficult to rule out.

These last two stories also touch on something else I found interesting. Apparently both Google and Microsoft have special procedures for dealing with state-sponsored attacks. It’s an interesting new world, when big companies are taking on nations, and vice-versa, for the sake of user security.

10 thoughts on “This Week In Security: Signal, WhatsApp, Oauth Fishing, And More State-Sponsored Attacks

  1. >> It’s an interesting new world, when big companies are taking on nations, and vice-versa, for the sake of user security.

    They really aren’t though. These same companies will help countries create draconian tools to oppress their own citizens.
    We can commend them for doing something helpful but lets not forget the bad.

  2. Big tech having to deal with state sponsored attacks sounds like a huge problem, but this particular attack described doesn’t sound so complex. It sounds like that attempted hack was just someone trying to guess a users password or personal info, not some complex, highly funded attack. If a hacker wanted to conceal their true location, or make it appear as if coming from somewhere else, i presume that wouldn’t be too difficult.

  3. While you’re reading this someone is trying to phish a political or defense entity in the US… While you’re reading this botnets are mass mailing malicious websites and attachments to millions of scraped email addresses…. If you don’t know this you don’t know about security..

    FYI: CrowdStrike never released the 2016 malware. Public researchers might find out they already have it from a honeypot and it’s just another malware campaign that conveniently hit a campaign network full of clueless users on unpatched endpoints..

  4. The Signal vulnerability sounds a lot like the libSSH one (https://www.guardicore.com/2018/10/libssh-new-vulnerability-allows-authentication-bypass). Basically, since there is a state machine that implements both client and server cases, if the client sends an “Authentication successful” message to the server, the server enters that state, and allows the client to connect. The problem being that the server was never actually in a state where it could transition to the “Authentication successful” state.

    In the Signal case, once again, the recipient of the call was not in a state where it should have been able to transition to the “Call established” state on receipt of a “call answered” message from the caller, only on a “call answered” event from the recipient.

    Sounds like there is a lot of mileage in reviewing these state machines from an adversarial perspective!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.