This chapter was supposed to be about additional methods to detect OS.X/Crisis but I had the evil idea of taking full control of Crisis, and played with this idea for the last couple of days. It’s pretty damm easy to customize the dropper, and at the limit, be able to deploy your own version of Crisis to anyone. This raises some problematic questions, some of which I was fooling around with at Twitter. To make it clear, I have no intent whatsoever to resell Crisis or something. First because it enters in conflict with my values, and second because it enters a potentially big legal minefield.
To me, hacking is all about raising the weird questions, playing with stuff, and experimenting with what others doesn’t see. I would love to have the resources to answer and test the legal minefield just because it’s a curious topic. The world is increasingly dangerous for hacking. It’s sort of a paradox that in a age of fast access to information the trend seems to be running towards making it more difficult to access and spread information. But enough of philosophical questions!
I will keep researching in private if I have time to. My free time status is going to change soon so things will be different. I still have some very cool ideas to try with Crisis and they would probably generate some interesting articles. We’ll have to wait and see if the environment changes.
This post is about the first network communication of Crisis with the C&C server. The reason why I think it’s very useful to write about it is that it opens the possibility for you to build a tool to wipe out Crisis from your network. The infection rates appear to be extremely small and there are some technical problems in this implementation. Still, it’s interesting information that can help you to understand this threat and clean it if applicable.
The first packet that the backdoor module sends to the C&C server is an authentication request. In the the sample I have the C&C server was located at the IP address 176.58.100.37. The communication is via HTTP on port 80, with a POST request to /. The contents are encrypted and their size should be always 104 bytes for this request.
The method that is responsible for this initial communication is [AuthNetworkOperation perform] (address 0x22A59 at backdoor module). Its task is to collect some data, encrypt it, send to the server, decrypt and process the response, and act or return a value. That act part is what makes this post valuable – there’s a response that will uninstall Crisis from the infected machine. The problem is that this depends on each sample and I will show you why. Credit is due to Crisis* authors, who appear to have done it right regarding this 😄.
If you want to dump the contents before encryption, put a breakpoint on address 0x2305F and print the object contained in EAX register.
Let me show you the contents of two different requests and then explain what’s in there:
Only the first 32 bytes are different between the two. The reason is that those initial 32 bytes are data from random(). What is everything else? It’s the backdoor ID (I assume this is some kind of serial number, customized to each customer), the AES key, the target type (OSX or OSX-DEMO) and hashes.
To be more specific this is how that data is set:
- 16 bytes of random data [16].
- 16 bytes of more random data [32].
- Backdoor ID string (located at address 0x545D0) (16 bytes field) [48].
- SHA1(MachineSerialNumber+Logged on username) [68].
- Target type string: OSX or OSX-DEMO (16bytes field) [84].
- SHA1(backdoor ID + SHA1(MachineSerial+username) + Target Type + AES Key) [Total 104 bytes].
Now we can see why the remaining bytes are the same between in the two requests. They contain the same information if the source machine and user are the same.
The response tells how this information will be used. Its contents must be 64 bytes long. This check is located at 0x230C8, so you may want to patch it if your server is just returning a standard response or something.
The response contents will be used to establish a session key, which will probably be used for next requests or something else (haven’t reversed it yet). But there is also a very interesting feature for our defensive purposes, which is to uninstall all traces of the backdoor from the infected computer.
How is the session key created? The first 32 bytes of the response are decrypted. A new object is created that will contain the AES key, 16 bytes from those decrypted 32, and the first 16 bytes of the random data sent in the POST request. This data is then hashed with SHA1 and its result is the session key (pointer to object stored at address 0x57694). The last 32 bytes of the server response are then decrypted with this session key and processed. Then we reach the above piece of code with the possibility to remove the infection. We just need to write a small webserver or CGI or something else, that extracts the necessary data from the request and sends a valid response to uninstall Crisis. The C&C server configuration is IP only so you can redirect the requests by doing NAT on the address, redirecting it to the uninstall server.
Now you can understand why this is only possible for a specific sample of Crisis. We need the AES key that is contained inside the backdoor module. Without it we can’t build the correct response, assuming that each delivered copy will use a different key. If not they f*cked up again and it’s a win for us 😃.
This tool doesn’t yet exist but I will post it later to github repo.
That’s it for this post. It allows us to use Crisis own features to wipe it out from infected systems. Useful feature, I think!
Enjoy,
fG!