Mobile Security


Seems like the pwn2own this time around is going to be putting up prizes of about $100,000+ for people who can find 0-days for a variety of platforms. Especially, the fact that about $60,000 are being devoted for 0-days on the mobile security platform including the android platform etc., indicates a new era of security bugs.
The iPhone (non-jailbroken ones) as well as the BlackBerry application do tend to use signed executables. One only hopes that like the trust-relationships of the SSL-based certificates, the trust is really kept by analyzing the blackberry and iPhone apps.
Tyler Shields from Veracode presented his work of TXSBBSpy (source code URL: http://www.veracode.com/images/txsBBSpy.java; Presentation slides: http://www.veracode.com/images/TylerShields-MonkeyBerries-ShmooCon-2010.pdf).  In this he suggested that when controlled APIs are used the code needs to be signed by RIM but to do that RIM only gets the hash and not the source code.  This presents an interesting situation where RIM could actually be signing something that they don’t really know what it seems to be doing.


New Year and Browser Helper Objects


The New Year brings in interesting things (or so we hope). My friend came up to me with an “infected” computer with a fantastic piece of malware installed. The malware was presented the user with a completely different HTML page when something was searched on Google. Browser Helper Objects (BHOs) are Dynamic Link Libraries (DLLs) that are installed in Internet Explorer (IE) and have a complete access to the DOM tree of the browser window. The name of the DLL was xyusx.dll (or something like that). This DLL was packed so that it wouldn’t permit a clean disassembly. The usual tricks seemed to work and I was able to unpack the DLL.

The procedure is simple. Open the DLL in OllyDbg. Search for the PUSHAD instruction (this instruction stores all the registers on the top of the stack) and set a breakpoint (F2 key in OllyDbg) on that instruction.

Press F9 to continue the debugging. Press F8 to execute the instruction, and then set a hardware breakpoint on the top of the stack in the Dump Window as shown in the image. You can do this easily by right clicking on the ESP register and clicking on “Follow in Dump”.
Once you reach the POPAD instruction or the hardware breakpoint is activated, this shows that the registers that were saved on the stack are now going to be restored in the respective registers. This indicates that the program has now finished extracting itself and is ready to execute the instructions.
I used OllyDump to dump out the contents of this DLL and then used LordPE to repair the import table. This process, however, needs more work due to the nature of the automated import address table repairing as some things can be missed.
Once this repairing was finished, I opened the file in IDA Pro to disassemble the unpacked DLL. This did give me a lot of information about this DLL, however, I’m still in the process of completing a good disassembly of this DLL.
As for now, I can say that this DLL installed a bunch of spyware CLSIDs into the system.
Some of the CLSIDs (out of the 45 that it uses) by this malware are listed below:


This DLL also seemed to communicate to :

Whatever you do to these servers is upto you. Some google searches allude that this is a “Vundo infection”. I’m also not sure what solutions people are posting to this problem but I’d not feel safe if this malware was on my computer and I’d definitely format my Windows install, patch it and change my passwords! I’m not completely dne with the disassembly and reversing of this malware yet, but I’m sure I’ll post more when I delve into this disassembled code deeper.