As a thank you to those who nominated me for the European Security Bloggers Awards, I’m going to release some new scripts this week. Here’s the fourth one.
pecheck.py is a wrapper for pefile, but this version has a new feature: check a PE file stored in a (password protected) ZIP file (password infected).
XORStrings is best described as the combination of my XORSearch tool and the well-known strings command.
XORStrings will search for strings in the (binary) file you provide it, using the same encodings as XORSearch (XOR, ROL, ROT and SHIFT). For every encoding/key, XORStrings will search for strings and report the number of strings found, the average string length and the maximum string length. The report is sorted by the number of strings found, but can also be sorted by the maximum string length (use option -m). By default, the string terminator is 0x00, but you can provide your own with option -t, like the space character (0x20) in this example:
I’ve used XORStrings to identify the encoding used in TeamViewer traffic.
There are more options than the ones I mentioned here. I’ll create a dedicated page for this tool, but for now, I invite you to discover the options yourself.
I will give a talk on network forensics at my local ISSA chapter.
I’m preparing it with a couple of PoCs.
First PoC is how changing the canary value 0xFD0110DF to another value can provide defense against exploits like FX explained in this paper. I changed the appropriate instructions so that IOS uses canary value OxFC0220CF. You can see it at the bottom of this memory dump:
Second PoC is how I can change the behavior of an IOS command for offensive purposes. Topo mentioned this idea at Black Hat. The verify command checks the embedded MD5 signature in an IOS image. I patched the appropriate instructions so that the verify command always reports a valid signature, regardless of the actual embedded value:
I did not change CCO hash. This is the MD5 hash of the complete IOS image. I did not change this on purpose, but it would be as easy as changing the embedded hash. If you lookup this CCO hash with Cisco, you will not find it.
This new version of XORSearch comes with a new operation: shifting left.
It comes in handy to reverse engineer protocols like TeamViewer’s remote access protocol.
Here’s an example. When you run TeamViewer, your machine gets an ID:
We capture some TeamViewer traffic with Wireshark, and then we use XORSearch to search for TeamViewer ID 441055893 in this traffic:
And as you can see, XORSearch finds this ID by left-shifting the content of the pcap file with one bit.
Sorry for the lack of recent posts, I’ve been ill and had to catch up with a lot of work.
Braden Thomas wrote an interesting series of posts on reversing the TeamViewer protocol.
I want to add my own observation: when TeamViewer is forced to communicate over an HTTP proxy, it will issue GET statements with parameter data that can be decoded in a similar way as Braden describes for the direct protocol (i.e. without proxy).
First of all, to identify TeamViewer traffic in proxy logs, you look for this User Agent String: “Mozilla/4.0 (compatible; MSIE 6.0; DynGate)”.
You will see HTTP GET requests like this one:
When you decode the value of the data= parameter as base64, you can identify the version of the protocol (first 2bytes) and the command (3rd byte):
0x12 is a CMD_MASTERCOMMAND. By left-shifting the data from the 5th byte with 1 bit, you can decode the arguments of a MASTERCOMMAND, like this:
When parameter f (the function) is RequestRoute2, you know that the TeamViewer user issued a command to connect to another TeamViewer client. Parameter id identifies the originating client (123456789 in my example), and parameter id2 identifies the destination (987654321 in my example).
A malicious PDF file I analyzed a couple of months ago (the one featured in this video) had a corrupted stream object. It uses a /FlateDecode filter, but I could not find a way to decompress it with the zlib library. Back then, I wrote it off as an error of the malware author.
Lately, I’ve been analyzing some shellcode, and while looking at the shellcode in said malicious PDF, I saw it! The second-stage shellcode, a egghunt shellcode, is searching through process memory for the 8 bytes at the beginning of the corrupted stream object.
The malware author knows that the PDF reader loads the PDF document in memory, so he just overwrote the stream object with his third-stage shellcode. This way, his third-stage shellcode is already in memory, waiting to be found by his second-stage shellcode. And the size of his third-stage shellcode is not limited by the buffer he is overflowing.
Another stored password question I was asked: where does SQL Server 2005 Management Studio store the passwords, and are they encrypted?
When you set the Remember Password toggle:
the password is saved in this file (default install, Administrator account):
C:\Documents and Settings\Administrator\Application Data\Microsoft\Microsoft SQL Server\90\Tools\Shell\mru.dat
The password is not stored in cleartext. The file contains a BASE64 blob, strongly resembling a DPAPI protected data blob.
Convert it to hex:
(all the protected DPAPI data blobs I’ve seen start with byte sequence 01 00 00 00 D0 8C 9D…)
Let’s decode this with CryptUnprotectData (all optional parameters set to NULL):
We get no error, proving that it’s indeed data protected by DPAPI on this machine for this user. The content is just the password in UNICODE.
The nice thing for a software developer, is that DPAPI allows him to encrypt/decrypt data without having to worry about encryption keys. For details on all the keys used by DPAPI, read this MSDN article.
This escaped my attention, but SpiderMonkey 1.7 has been released for some time now.
I patched this new version (download on my SpiderMonkey page), and decided to add another small trick: implement the window object with the navigate method:
Remember my DisableAMD post? In stead of patching the EXE file, you can also use my Basic Process Manipulation Tool Kit to patch the running process.
There is a small difficulty, however. The check for the DisableCMD key is done when CMD.EXE is started, so to be successful, we have to start the program and change the DisableCMD string in memory before the check is made. Sounds impossible? Not really, the CreateProcess function allows you to create a new process with its main thread in a suspended state (this means that the program is not running). This gives you the opportunity to change the string in memory before it is used.
Use the start statement to start a new process in suspended state:
Change the string in memory:
search-and-write module:. unicode:DisableCMD unicode:DisableAMD
The main thread will be resumed after the last statement was executed (search-and-write in our example):
The cmd.exe window in the background was launched from the start menu (showing you that cmd.exe is disabled), while the cmd.exe window in the foreground was launched with the bpmtk (showing you the bypass of the GPO).
And did you notice that this screenshot is taken on a Windows 2008 server?
Next time, I’ll show some tricks to use the bpmtk in a restricted environment, like a Terminal Server.