Monday, March 3, 2014

Reverse engineering IPmsg: UDP spoof attack to annoy users!

What really caught my attention after reading about Kevin Mitnick was how he conducted the TCP blind spoofing attack. It was an attack which required packet crafting and insertion into an already established TCP connection. What is interesting about this attack is that it does not require knowledge about any specific tools but instead relies on the person's knowledge about the protocol. So I started reading about packet crafting and a protocol or an application that I could play with. The modern OS puts random sequence numbers in the TCP packets making it very difficult to achieve what Kevin Mitnick did.

Thus UDP becomes the obvious choice. In comes IPMsg! It is a UDP based chatting application especially useful in LAN networks. What it suffers from is the spoofing attack. So if you are able to decode the IPmsg packet formats it is upto your imagination how you want to annoy others. From my experience following is an IPMSG packet structure:

|----------------------------------------------------------------|
| 0 | Sequence no | ipmsg-name | hostname | packet-type | data  |                                                                   |                                                                                               |
----------------------------------------------------------------

The 0 is fixed for all packets. Each packet that a user sends is marked by a sequence number, which is increased by one for every new message sent.  The next field is the display name that you have set for Ipmsg. Packet type field defines what kind of packet has been sent. The receiving application processes the data accordingly.

Now by default the sequence number is initialized to the timestamp when the application started.

Let me quickly go through some interesting packet types:

0:startup packet to announce that the host is running ipmsg
288: New packet.
33: acknowledgment for the packet. this is done in the background for all the packets.
1051424: a sealed message. 
1048624: acknowledge a sealed message. Upon receiving such a packet the sender machine will display a pop-up message shown below.

If you start the application, it registers itself on the network by sending a specific message. Following is a sample of the message.

Note that it initializes a counter which increments whenever it sends a new message.

Ipmsg traffic seen on wireshark

The client increases the counter when it sends another message


All the hosts keep track of this counter and ignores any packet with wrong value.

The IPmsg Attack


Ipmsg is a very lightweight and simple application. It has a very basic error detection mechanism at the application layer (verifying the counter value) and it cannot detect a spoofed packet. To slyly insert you can either send an initiation packet and reset the counter value stored by recipient victim. Or you can simply use the values being used by the original sender.

I prefer the former approach since it gives the attacker more control.

Sending the initiation packet:


Send a packet with 0 as the packet type and NULL as data. And set the counter with whichever value you want to. Here is an example.

Note the message type as 0


With this simple packet you have hijacked the connection. The original machine is unaware of this and it will keep using its own counter value which the recipient machine will ignore since the attacker has reset and changed the value.

Sending messages

You need to run Wireshark while you send spoofed packets to know the counter value of the recipient machine. As soon as you send the packet mentioned above the recipient machine will reply with its confirmation message and its own counter value.

A Demo:

Important Note:

The latest version of Ipmsg encrypts all data and it cannot be configured to send in plaintext. Therefore install the older version and change the registry value
HKEY_CURRENT_USER\Software\HSTools\IPMsgEng --> EncryptNum to 0.

This will force the Ipmsg to use plaintext.


I have used colasoft packet crafter which works on windows. it is a little difficult to use and I would highly suggest tools like scapy or hping3.

First send a packet with message type 0 and set a custom counter value.




To send a message use the packet type 288. Construct a packet with appropriate mac entries. If the destination pc does not reside on your own subnet then you will have to put your gateways mac as the destination mac.




Even more fun

There are two ways to send a message in ipmsg. One is the default method and the other is known as a "sealed" message. When you send a sealed message the receiver has to click on the a greyed box to display it. Upon clicking a UDP message is sent to the initial sender of the message and an intrusive pop up is displayed on his screen.


Colasoft packet crafter running 




Now, suppose I start sending these UDP messages to a victim machine acting as someone else?


Moreover you can automate the entire process using hping with Tcl or Scapy.

I hope you get my point!

Some interesting things that you can do-
a) Act as some other device and send packets with someone else's name.
b) Fill the victim machine's screen with confirmation pop ups.

Conclusion


As it is clear by now, there is no way to tell who sent what. Although this post is concentrated on Ipmsg, the subtle point is that it is strongly recommended that such applications are not run in corporate or critical environments.
All important data should be encrypted and only reliable clients should be used.

For a protocol designer, there are techniques to make a protocol robust against such replay or spoofed attacks.

Important Links


1) Wiki on Kevin mitnick
2) TCP/IP spoofing attack
3) Ipmsg older version
4) Replay attacks

2 comments: