[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.
[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.
The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.
[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.
After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.
Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.
[Craig Heffner] has been busy with his Linksys WRT120N router. When we last checked in on [Craig] he had reverse engineered the obfuscation techniques used in the router’s firmware. Since then, he’s re-enabled JTAG, cracked the “encryption” used for saving configuration backups, and now he’s devised a simple attack to change the admin password. With the firmware unlocked, [Craig] went after the hardware JTAG. His first hurdle was a missing jumper connecting the TDI pin to the processor. With a solder blob making the connection, he then found the router would connect to his JTAG debugger, and immediately reset. TDI had been re-used as a GPIO in software, and assigned to the reset button on the back of the router. [Craig’s] JTAG pod was pulling the pin low and causing the reset. To make matters worse, the bootloader also redefined and checked for the reset button. If the button were pressed it would boot into a recovery mode. [Craig] patched the bootloader with a little help from IDA pro. He then desoldered the router’s flash and programmed it outside the system. The firmware required a similar patch. Rather than desolder the flash chip again, [Craig] created a firmware update the router would accept and flashed it via the router’s web interface.
Since he already was deep into the Linksys Firmware, [Craig] looked for any obvious attack vectors. He found a big one in the /cgi/tmUnBlock.cgi. Inside the firmware, the URL sent to the CGI would be sent through sprintf(). In plain english, it means that no input length checking was happening – so a URL longer than the firmware engineers expected (in this case 256 bytes) would overflow into areas of memory it wasn’t supposed to – in this case, the stack. For an astute attacker, that’s a wide open door. [Craig] was able to use find some Return Oriented Programming (ROP) gadgets and created an input value that would cause the router to reset its own administrator password. After running the exploit, a quick trip to the router’s webpage proved his attack was successful.
If that wasn’t enough, [Craig] also spent some time looking at the patches to the router’s firmware. The release notes of one of the patches mentioned encrypting configuration files. The WRT120N, like many routers, allows the owner to download and save the configuration as a file. It turned out that the “encryption” scheme was nothing more than an exclusive OR with 0xFF. A pretty weak encryption scheme by any standards. To [Craig] we send our congratulations. To the WRT120N software engineers, we’d suggest taking one of [Craig’s] embedded device exploitation classes.
[Craig Heffner] recently found himself on the case of the Linksys WRT120N router. The router’s firmware was using some previously unknown form of obfuscation, causing headaches for those wishing to run their own software. The WRT120N, being a 2009 model is somewhat out of date at this point. That didn’t stop [Craig] though, as he dove into reverse engineering the firmware obfuscation.
[Craig] started by running the firmware through his own Binwalk tool. Binwalk analyzes firmware files for known data, be it embedded filesystems, raw compression streams, or binary files. In this case Binwalk only found a small LZMA block which contained the compressed html files for the router’s web interface. The rest of the firmware was unknown data with a high level of entropy. [Craig] couldn’t do anything more with the firmware update file alone, so he ordered a router to attack from the hardware side. Inside he found typical low-end router components: An Atheros AR7240 SoC, a 2MB SPI flash chip, 32MB of RAM. He also found serial and JTAG headers.
[Craig] connected to the serial port and was greeted with a boot menu. This allowed him to run some commands on the router, but didn’t give him any way to dump memory. He had to go straight to the source – connecting directly to the router’s SPI flash with an FTDI C232HM cable. Using libmpsse, another of his open source tools, [Craig] was able to dump the flash. He now had the un-obfuscated bootloader code, albeit in MIPS assembly. [Craig] was then able to go after the bootloader with IDA Pro. After a bit of work, the obfuscation system was exposed. The system was simple – several byte and nibble swaps had been performed between the LZMA header block and the first few bytes of data. [Craig] finished out this part of his hack by writing a simple C program to de-obfuscate and decompress the firmware.