What’s Up, Santa? (451t)

Web

Description: You really want to get that top of the line Pentium III processor this Christmas, but Santa doesn’t want to get it for you! You need to trick the old man into thinking that he has already promised you one by sending him a message replying to him saying “I will gift you the Pentium III processor this Christmas” (on Santa’s WhatsApp account it should appear as if he has told you this, even though he has never sent you such a message).

WhatsApp phone number: +xx xxx xxx xxx Author: Milkdrop

Solution:

This Whatsapp vulnerability has been known for a long time and in fact this same challenge was used for the previous year’s X-MAS ctf.

There is a really good writeup here about this attack, however things have changed enough where I wasn’t able to get the Burp tool to work for me.

The basic idea with the attack is that you can spoof a message you are replying to. Essentially some data for the original message is bundled with the reply and therefore some validation checks are missing.

The original attack modifies the fromMe parameter on an outbound message so that the message appears to be sent from another user (only for your local client). However, if you reply to this message, rather than attaching a message id (like you might expect), it seems to send the “sender” context along with the message data and therefore you can spoof the original sender.

I tried several methods to attack this system:

1. Decrypt outbound bytestreams and spoof the fromMe parameter (what the linked attack does). – Burp tool didn’t work for me
2. Find the serialization method and modify the fromMe parameter before it is encrypted – Server seems to ignore these messages (maybe it is patched?)
3. Find the deserialization method and modify an incoming message so that my client believes it was sent from someone else. – works!

Essentially we want to be able to spoof a message reply that looks like we are replying to someone else. Luckly for us, the web application already has the logic to do this as long as we can trick our client into thinking some message is from someone else.

We can use a second client to inject new messages in the conversation that must be received by our client (such as using a phone and a laptop). Therefore, we just need to find the code that handles incoming messages and mangle it so that it looks like a message from someone else.

To accomplish this I set a DOM breakpoint on the message panel window that would break whenever a new message was being added. Then I sent a message from my phone and hit the breakpoint.

I traced backwards in the callstack and examined local variables at each point ensuring that at each level I had some object that corresponds to the new message.

Eventually I found the outer most frame:

Now I have a javascript object that seems to contain a lot of data about this message:

We can mutate it and see how our client responds.

After playing around for a bit with this object, I found that you can simply do:

a.__x_sender = a.__x_to

When the client receives the message, it will initially appear like it is from you. However, when you reply to the message it will show up as from the other person.