(See parts I, II and III of this serie)
In the previous post we managed to obtain the original SWF, but discovered that the exploit is embedded in a ByteArray. Will we be able to obtain it?
First of all, we must extract the contents stored in the ByteArray. To do this, we need a Flash decompiler desktop: Adobe SWF Investigator (It’s free!). Once installed we open the last file obtained: uncompressed_exploit.swf. We go to “Tag Viewer” and select “DefineBinaryData” among all the tags. Then we save it by clicking in “Dump to file” and naming it as “dump_exploit.bin”, for example.
We look into the first three bytes of the file “dump_exploit.bin” in hexa mode. If it is a Flash file these must be 5a 57 53 (ZWS) or 43 57 53 (CWS) or 46 57 53 (FWS), as we’ve seen above.
$ hexdump dump_exploit.bin -n 3 -C 00000000 0e 03 07 |...| 00000003
But as we know, these bytes have been XORed to complicate the analysis. As seen in the ActionScript code, they have used the “T” character to perform the XOR encryption to each byte. Therefore, we try to do the same operation from a Python console with these first bytes:
>>> ord("T") # Valor decimal en ASCII.
84
>>> chr(int('0x0e',16)^84) # 0x0e XOR 84
'Z'
>>> chr(int('0x03',16)^84) # 0x03 XOR 84
'W'
>>> chr(int('0x07',16)^84) # 0x07 XOT 84
'S'
‘Z’, ‘W’, ‘S’ :) Do you remember them?
It’s a SWF file compressed with LZMA as seen in the third part of this series! Quickly, we develop a script that applies XOR operations to all the bytes of the binary file.
#!/usr/bin/python
# -*- coding: utf-8 -*-
key = "T"
data_in = "dump_exploit.bin"
data_out = "out.bin"
file_in = open(data_in, "rb")
file_out = open(data_out, "wb")
while 1:
byte = file_in.read(1) # Lectura byte a byte.
if not byte: break
xor = chr(int(hex(ord(byte)), 16) ^ ord(key)) # Applies XOR
file_out.write(xor) # Saves the result in a file
file_in.close()
file_out.close()
Once executed, we get a binary file named “out.bin”.
$ file out.bin out.bin: data $ hexdump out.bin -n 128 -C 00000000 5a 57 53 17 f9 4d 00 00 f0 1b 00 00 5d 00 00 20 |ZWS..M......].. | 00000010 00 00 3b ff fc 8e 19 fa df e7 66 08 a0 3d 3e 85 |..;.......f..=>.| 00000020 f5 75 6f d0 7e 61 35 1b 1a 8b 16 4d df 05 32 fe |.uo.~a5....M..2.| 00000030 a4 4c 46 49 b7 7b 6b 75 f9 2b 5c 37 29 0b 91 37 |.LFI.{ku.+\7)..7| 00000040 01 37 0e e9 f2 e1 fc 9e 64 da 6c 11 21 33 ed a0 |.7......d.l.!3..| 00000050 0e 76 70 a0 cd 98 2e 76 80 f0 e0 59 56 06 08 e9 |.vp....v...YV...| 00000060 ca eb a2 c6 db 5a 86 7b 47 de 99 5d 68 76 38 16 |.....Z.{G..]hv8.| 00000070 bd 93 3c d3 d0 9e d3 55 63 5a da b0 db 27 e6 7c |..<....UcZ...'.|| 0000008
It is similar to what we saw in the third part, so we do the same:
$ python swfzip.py out.bin exploit.swf
info : Input file: out.bin
info : Output file: exploit.swf
info : Reading out.bin
info : lzma compressed swf detected.
info : Filesize in signature: 19961
info : Filesize decompressed: 19961
info : Generating uncompressed data
info : Compressing with zlib
info : Packing zlib header
info : Generating compressed data
File compressed with zlib, size decreased: -21%
Notice: Recompressing may cause filesize increased
$ file exploit.swf
exploit.swf: Macromedia Flash data (compressed), version 23
$ ./uncompress.sh exploit.swf
uncompressing to ./uncompressed_exploit.swf
$ file uncompressed_exploit.swf
uncompressed_exploit.swf : Macromedia Flash data, version 23
$ hexdump uncompressed_exploit.swf -n 128 -C
00000000 46 57 53 17 f9 4d 00 00 78 00 04 e2 00 00 0e a6 |FWS..M..x.......|
00000010 00 00 18 01 00 44 11 19 00 00 00 7f 13 76 01 00 |.....D.......v..|
00000020 00 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 |...
Okay! We got the exploit! Let's decompile it using http://www.showmycode.com/, and what we get is this: ActionScript code.
We take a look at it and ... WOW! It's ******* crazy!
Analyzing the code we can see there are several methods to check the Flash version:
Normally, the Flash version is checked using Javascript functions. But in this case, the Flash is being executed directly from the memory, preventing the antivirus from detecting the javascripts during navigation.
Also, we see that it reads the parameters FlashVars and access the “exec” variable:
This is processed by different functions until it reaches one using "url" as a parameter name. So the "exec" variable contains the URL to download the binary that really infects the computer?
It is a theory, but it can be easily proved releasing the exploit in a vulnerable environment and changing this part of the payload from the HTML, viewing the request generated.
Without modifying the payload ...
... we execute the exploit and it creates the download request correctly to what it is the dreadful malware (5) BV4NBkQDAQ9SHwMfBh1SDFcCDwBRBVcHHVUOSwABAE0FUBlQUg0ZBkVnFHwARhgzRFc
But now, if we change the payload modifying a few bytes ...
... the request changes ...
... proving the above theory.
If we continue analyzing the code, we get to the most important part, which shows that the exploit used is the one related to CVE-2015-0311. This vulnerability is explained in detail in this Trend Micro blog post.
We can see the “uncompress” string and how it generates the “compress” string...
... that are used in the most critical parts of the exploit:
And as we can notice, they are very similar to the example linked above. Finally, we can upload one of the Flash files to Virustotal and confirm that the exploit used is the one related to CVE-2015-0311.
Greetings!
