I claim to be the first to practice real warclimbing.
My N800 with Kismet running:
N800 in the pocket:
Starting the climb with Kismet attached to my climbing harness:
Capturing frames at the top:
Wednesday 31 October 2007
Tuesday 23 October 2007
A000n0000 0000O000l00d00 0I000E000 00T0r0000i0000c000k
When I found a malicious script riddled with 0x00 bytes, SANS handler Bojan Zdrnja explained to me that this was an old trick. When rendering an HTML page, Internet Explorer will ignore all zero-bytes (bytes with value zero, 0x00). Malware authors use this to obscure their scripts. But this old trick still packs a punch.
This is how the script looks in vi:
Maybe this hex dump makes it more clear to you:
Recognize <html> <script…?
Well, a lot of AV programs are still fooled by this trick, VirusTotal reports that only 15 out of 32 AV products detect this malicious script.
When I remove all obscuring zero-bytes from this script, things get better: 25 out of 32 AV products detect it.
But what happens when I add more zero-bytes to the script?
Even more AV are fooled! Gradually adding more zero-bytes makes the detection ratio go down.
And at 254 zero-bytes between the individual characters of the script, McAfee VirusScan is the only AV to still detect this obscured script. One byte more (255 zero-bytes), and VirusScan doesn’t detect the script anymore. No AV on VirusTotal detects this malware obscured with 255 zero-bytes (or more). But for IE, this obscured HTML poses no problem, it still renders the page and executes the script.
But you cannot rely on VirusTotal results alone. Modern AV products do not solely rely on file scanning to identify malware, they come with many techniques. For example, VirusScan has a feature called ScriptScan, a utility that intercepts all script execution requests to the MS scripting engines (VBS & JS). Since IE sends the malicious script stripped of its zero-bytes to the VBS scripting engine, ScriptScan has no problem detecting the malware and prevents its execution.
As it is the first time I get such a clear example of ScriptScan in action, I’ve made a screencast (YouTube) of it, XviD hires here.
Friday 19 October 2007
Pwned @ hack.lu?
While using the WiFi today at hack.lu I got this pop-up on my N800:
Care to guess what happened? Post a comment!
EDITED TO ADD (21/10): Thomas Roessler managed to capture a lot more than a screenshot while witnessing the attack, read his excellent blog post here.
And be sure to read the comments for my post, several are from hack.lu attendees who lived through the attack.
Tuesday 16 October 2007
UserAssist V2.4.1
The most important feature of this new UserAssist version is the explain command. Now you can right-click an entry, select explain and get a nice explanation for the selected entry, like this:
I’ve spend some time researching all the different types of values the UEME strings can have and how they relate to user actions. The explain function contains everything I discovered. The source code for this feature is a prototype, I’ve been developing it as I discovered the logic behind the UEME strings, hence it is not a clean design and I plan to rewrite it once I get the full picture. Of course, this design is hidden for you as a user and you should not care about it.
The Logging Disabled switch is OS-aware (Windows XP, 2003 and Vista).
And the last new feature of this version is the support of cleartext Userassist entries (i.e. entries that are not ROT13 encoded). BTW, Windows Vista doesn’t support the NoEncrypt setting.
This version was also tested on Windows 2003, I didn’t notice a difference with Windows XP, but I must admit the testing was limited.
And I would like to test it on Windows 2008 while attending Microsoft IT Forum.
Tuesday 9 October 2007
WhoAmI? Firefox Extension
Can you help me test my new Firefox extension WhoAmI?
It’s very simple, it displays the name of the current profile on the statusbar:
I’ve been using the Firefox Profile Manager for some time now, but recently I learned how to run several instances of Firefox. There have been several posts about this, like this one, to help mitigate Google account vulnerabilities. But sometimes I forget which profile I’m running, until I developed my WhoAmI? extension.
You can download it here. It is also in Mozilla Add-ons site’s sandbox. Please report your test results back to me (OS & FF version), it will help me to get my extension out of the sandbox and into the public part of the Mozilla site.
Tuesday 2 October 2007
AutoIt Malware Revisited
Since I’ve blogged about malware written with the AutoIt scripting language, I got a couple of mails asking for assistance or advice on how to detect and decompile AutoIt malware compiled to executables. In this post, I’m describing a method to identify and reverse AutoIt malware, and I show that old malware packed inside a compiled AutoIt script will elude most AV products.
When you compile an AutoIt script with the Aut2Exe tool, by default, an UPX packed executable is produced. Identifying such a compiled script is easy, the version strings tell you exactly what it is:
And the (default) file icon in the Windows Explorer view is also a giveaway:
Of course, it’s easy for a malware author to change these telltale signs. But you can also identify AutoIt malware with a magic number (see further).
Decompiling is easy, just start the decompiler (Exe2Aut, it’s in the extras folder of the AutoIt ZIP installation package) and point it to the executable.
But what if it was compiled with a passphrase, and you don’t know the passphrase? Well, as I pointed out in my previous post, you can still execute the script without providing the passphrase. And I found out some other interesting things.
Add extra whitespace to a script, or change the indentation, compile & decompile it, and the whitespace is preserved. When compilers compile source-code into machine language or intermediate language (like Java bytecode and .NET MSIL), they ignore whitespace. But because we still see the whitespace as we typed it in the decompiled program, it’s very likely that we’re not dealing with a real compiler. I believe that the source-code is stored inside the “compiled” AutoIt script.
Another test supports this hypothesis: write an AutoIt script with a syntax error and compile it. You won’t get an error! It’s only when you execute the compiled script that you’ll get an error. Decompile it, and you’ll get the script with your syntax error!
Like most seasoned computer users, I don’t RTFM before I start using software. But I skimmed the AutoScript help file for my research, and here is what I found:
Technical Details
The compiled script and additional files added with FileInstall are compressed with my own (Jon) compression scheme.
Because a compiled script must “run” itself without a password it needs to be able to decrypt itself – i.e., the encryption is two-way. For this reason you should regard the compiled exe as being encoded rather than completely safe. For example, if I wrote a script that contained a username and password (say, for a desktop rollout) then I would be happy using something like a workstation-level user/password but I would not consider it safe for a domain/entire network password unless I was sure that the end-user would not have easy access to the .exe file.
The AutoIt author (Jonathan Bennett) is aware of the limitations of his protection scheme and discloses them. That’s very professional of him.
FileInstall is also an interesting feature for malware authors: it allows you to include (binary) files in the compiled script. The script itself is also stored as a file. And it’s not only the file content that is stored, but also file properties like the original filename and timestamps. When a malware is included in a compiled AutoIt script with FileInstall, most AV products will not detect it. Here’s a little test:
I took an old Warezov / Stration e-mail worm that all AV products on VirusTotal detect. Then I included this worm in a compiled AutoIt script with FileInstall, and let VirusTotal do its work. Only 4 AV products detected it, and only 2 of these (F-Secure & Kaspersky) detected it as a Warezov / Stration e-mail worm! I cannot trust the results of the other 2 AV products that detected it, because they will also identify an empty AutoIt script as malware. The 2 reliable AV products even detected the virus inside the AutoIt script when it was compiled with a passphrase and with the new fileformat (see further).
So how about decompiling passphrase protected AutoIt malware? Well, it’s easy. A compiled script contains the MD5 hash of the passphrase, and the obfuscation routine is based on the MD5 hash, not on the passphrase itself (this will work with version 3.2.5.1 and earlier compiled scripts).
Here’s my howto (there are other methods to do this):
- Unpack the executable (UPX –d malware.exe)
- Open the unpacked executable with a binary editor, and search for the magic number A3484BBE986C4AA9994C530A86D6487D
- This magic number will be followed by string AU3!EA05 (if you find AU3!EA06, you’re dealing with the new version that can’t be decompiled with the Exe2Aut decompiler). The MD5 hash of the passphrase is stored in the 16 bytes following this AU3!EA05 string (in fact, an AutoIt script compiled to an executable is just the AutoIt interpreter PE file with the compiled script appended at the end)
- Once you’ve recovered the MD5 hash, you have 2 options
- Try to reverse the MD5 hashing (brute-force, dictionary, rainbow tables, …) to obtain the original passphrase and use this with the decompiler
- If this fails, or you don’t like this option, try the following trick
- Start the Exe2Aut decompiler (I’m using version 3.2.4.9 on Windows XP SP2) with a debugger like OllyDbg
- Set a breakpoint at 0x00402064
- Start debugging, and decompile your file. After clicking the Convert button, the debugger will pause at the breakpoint
- At the address pointed to by EBX+ESI (0x0012F520 in my test), you’ll find the 16 bytes of the MD5 hash of the passphrase you entered (it will be equal to the well-known MD5 hash d41d8cd98f00b204e9800998ecf8427e if you’ve left the passphrase empty)
- Replace this hash with the MD5 hash you recovered from the malware
- Continue debugging
- Voilà, the Aut2Exe decompiler produced the source code of the malware
This debugger method also works if the checkbox “Allow decompilation” was unchecked when the AutoIt script was compiled. The reason is that when this flag is unchecked, the compiler will generate a long random passphrase and use this to compile the script.
Since I’ve worked out this method, a new AutoIt version was released with a new fileformat (AU3!EA06). This new obfuscation scheme doesn’t use passphrases (and hence no MD5 hash) and Jonathan Bennett doesn’t release a decompiler for this format. Of course, someday, someone will spend the time needed to reverse this scheme. And Jonathan is aware of this, he warns developers for this on the AutoIt forums.
Browsing these forums, I learned that AutoIt is also used heavily for gamebot development and that developers are urged to move to the new version to avoid decompilation. There is an interesting ecology of reversing and anti-reversing tricks, like this one. When malware developers start picking up these tricks, we will have a harder time reversing AutoIt malware.
Didier Stevens 