I’ve updated ExtractScripts to handle comments inside <script> tags.
Wednesday 11 July 2007
Tuesday 3 July 2007
The BlockSite Firefox Add-on
The Firefox add-on BlockSite by Erik van Kempen allows you to maintain a blacklist of sites you want to block for surfing. I extended his add-on with a whitelist: in stead of specifying the sites you want to block, you can decide to specify the sites you want to allow, and all other sites will be blocked. Erik has integrated my code in his add-on:
Version 0.5 — December 30, 2006 — 34 KB
[+] Whitelist/Blacklist feature (by Didier Stevens): Choose if the list is a blacklist or a whitelist.
[~] Password protection still pending (unfortunately), most probably in next major release
Reverse engineering a Firefox add-on is really simple. The file format for add-ons, XPI, is in fact a ZIP file. After unzipping the XPI file, you’ll find a JAR file (again, this is also based on ZIP). Unzip the JAR file and then you can analyze the JavaScript and XUL files.
You can also load an unpacked Firefox add-on in Firefox to test and debug it, how is explained here.
Tuesday 26 June 2007
ExtractScripts
ExtractScripts is another one of my little tools I use to analyze malware.
Wednesday 20 June 2007
UserAssist Q&A
I was a speaker at the local ISSA chapter last Monday. My talk explained how to use my UserAssist tool for forensic analysis. The audience had great questions for me at the Q&A, some of which I want to share here.
Does switching to the “Classic Start Menu” prevent the logging of data in the UserAssist registry keys?
No, it doesn’t. When you use the classic start menu (the start menu from Windows NT & 2000, without a frequently used programs pane), Windows explorer still continues to monitor and log the programs you execute. When you switch back to the “modern” start menu, you’ll see several of the programs you recently used in the frequently used programs pane.
Does disabling the Active Desktop prevent the logging of data in the UserAssist registry keys?
No, it doesn’t. In fact, I use the following litmus test to know if starting a program is recorded in the UserAssist keys: did a user perform the action through Windows explorer? If a user did, then the action is logged.
The only trick I know to permanently disable the UserAssist keys is this one:
- add a new subkey “Settings” under the “UserAssist” key
- add a new DWORD value “NoLog” and set it to one.
My UserAssist tool allows you to toggle this setting via a simple menu command.
One audience member asked me if I was really sure that using a mandatory user profile (NTUSER.MAN) implied that the UserAssist registry keys where not persisted.
I promised him that I would test it, and I must admit that I was wrong.
A mandatory user profile is a profile that the user can change, but the changes are not saved when the user logs out.
This is how I tested the UserAssist tool with a mandatory user profile:
- a domain controller
- a member workstation
- a domain user with the profile path set to a share on the DC
- renaming NTUSER.DAT to NTUSER.MAN
- log on to the workstation with the domain user account
- start some programs
- analyse the profiles
I discovered that the NTUSER.MAN file in the local copy of the profile (file NTUSER.MAN in c:\document and settings\user on the workstation) had been modified, and that the UserAssist keys listed the program I had executed. As expected, the NTUSER.MAN file on the DC in the roaming user profile was not modified. And when I logged on to the workstation a second time, the local profile was overwritten with the mandatory profile, as expected.
So you can use the NTUSER.MAN file in a forensic investigation, but some restrictions apply:
- use the local copy, not the file hosted on the DC (in fact, you should compare the UserAssist entries from both files, because some entries in the UserAssist keys might come from the original NTUSER.MAN file)
- make sure to grab a copy before the user logs on again, otherwise the file will be overwritten (you could try to recover it)
- entries in the UserAssist keys will pertain to the last session of the user, it is not a complete history of all the sessions (and remember restriction 1, comparing the profiles)
Raymond Chen has started a series of blog posts about the Start Menu’s frequently used programs. Keep in mind that he discusses the rules that govern the display and ranking of programs on the start menu, and not actually the rules for collecting the data (i.e. UserAssist keys). What he calls points is not the same as the counter in a UserAssist entry.
Monday 11 June 2007
Some e-voting observations
Last Sunday, we had federal elections here in Belgium. I’m glad to see that the electronic voting system I used is designed to minimize voter coercion.
The secret ballot prevents coercion (being forced to vote for a certain person or party): if the voter can’t produce evidence of how he voted, he can lie to the coercer about his vote without risk. Some political parties want to change the process of the secret electronic ballot and include a paper trail. This is not a good idea, it will make coercion much more effective, as the voter will have an official paper with his vote.
The ubiquitousness of mobile phones equiped with a camera gives coercers a new opportunity to require proof from the persons they are coercing. The coercer just has to instruct his victim to take a picture of his ballot. The Belgian electronic ballot is designed to prevent this. When you’ve casted your vote, you’ll see a screen like this one:
The 2 buttons at the bottom of the screen allow you to:
- left button: go back a screen and change your vote
- right button: confirm your vote
Once you have confirmed your vote, the next screen doesn’t display how you voted. So if one is coerced and has to deliver proof, one just has to take a picture of the vote one was coerced into, and then back out from the screen and change ones vote. The only workaround I see is for the coercer to demand a video of the complete voting process, in stead of a picture of the ballot.
I’ve made a video of my voting last Sunday, and it turned out to be rather difficult to do. First of all, I was standing very close to the screen and I clumsily managed to film only the bottom of the screen. Secondly, the brightness of the CRT screen (black letters on a white background) makes it very hard to read my ballot on the video. This could also be an anti-coercion mechanism, taking legible pictures of a white screen is very hard.
This is an advantage that our electronic ballot has over our paper ballot, it is more effective against voter coercion.
You can find a simulation of the Belgian electronic ballot here:
Tuesday 5 June 2007
OMG, My N800 is Infected!
I followed a link from a comment spam I had on my blog. Turns out my machine is infected:
This is really disappointing, I didn’t expect my brand new Linux-based Nokia N800 to get infected so soon:
Monday 28 May 2007
Find Madeleine
I knew this was bound to happen, but I still got upset when I was confronted with it.
http://findmadeleine.com, the official website to find Madeleine McCann, has a page with links to news articles.
Several days ago, when clicking on one of the news links, a new IE window opened, showing the news article, and ultimately, downloading a trojan. Someone must have taken action, because as of this writing, the trojan is not downloaded anymore. And just to be clear: the trojan was not hosted on or linked to from the findmadeleine.com site.
The official website to find Madeleine McCann links to news sites with articles about the search for Madeleine. One of these sites links to http://47z.nh5egc.gondar-my.info/htm/cc1.php?p=55, which in turn links to http://ww3.boz.com.my-expert-pop-block.biz/track3/sh.htm, which in turn downloads http://ww3.boz.com.my-expert-pop-block.biz/track3/%73%68%65%2e%6a%73.
%73%68%65%2e%6a%73 (she.js) is an encoded JavaScript trojan, detected as JS/IEstart.gen.c. Some of the things it does are:
- changing your IE start page
- installing a VB script to be executed each time your machine boots
- changing the hosts file
- …
The trojan is encoded with the Windows Script Encoder, I used the Windows Script Decoder to decode it.
It’s a known tactic of scammers to exploit the curiosity of the general public whenever there’s an important news event. I don’t think I can do something to help find Madeleine, but I’ll keep an eye on the news section to try to stop these scammers.
Monday 21 May 2007
Hiding Inside a Rainbow, Part 2
In my previous post about steganography and rainbow tables, I explained a technique to hide data in a rainbow table. The disadvantage of this method is that there is a way, albeit costly, to detect the hidden data. This is because we replace the random bytes, that makeup the start of the chain, by the data we want to hide, thereby breaking the chain. A broken chain can be detected by recalculating the chain and comparing the recalculated hash with the stored hash. If they differ, the chain is broken.
But if we know that we are breaking chains, why don’t we fix them? We can proceed as follows:
- replace the start of the chain (random bytes) with the data we want to hide
- recalculate the chain
- replace the hash of the chain with the new hash we calculated
This way, there are no more broken chains that give away our hidden secret. But now there is another telltale sign that the rainbow table has been modified to hide data: the hashes aren’t sorted anymore. Remember that a rainbow table has to be sorted (the sort key is the index of the hash) to be useful. It is very unlikely that our new hash is greater (or equal) than it’s predecessor and smaller (or equal) than its successor. Detecting an unsorted rainbow table is much easier than finding broken chains.
OK, so if the new rainbow table is unsorted, why don’t we just sort it again? Well, if we resort the rainbow table, we destroy the order in which we stored our hidden data, so we loose the hidden data itself.
You could keep the original order of the hidden data by creating an index, this is another file that indexes the chains with hidden data. For example, you could make a list of all the hashes with hidden data. This list will then allow you to retrieve all chains with hidden data in the correct order. And the fact that you have such a list of chains isn’t necessarily suspicious, it’s just a list of hashes you want to crack…
But there is a simple way out of the unsorted rainbow table problem. Rainbow tables generated with the rtgen program are unsorted. In fact, you have to sort them with the rtsort command after generating them, before they can be used by the rtcrack program. The solution is to adapt the rtgen program to generate a rainbow table with hidden data, and keep this unsorted rainbow table.
And this is not so difficult. We add this method to the chain class:
void CChainWalkContext::InjectHiddenData(FILE *fFile, int bytes)
{
unsigned char *byteInject;
int iIter;
int iChar;
byteInject = (unsigned char *) &m_nIndex;
for (iIter = 0; iIter < bytes; iIter++)
{
if ((iChar = fgetc(fFile)) == EOF)
return;
byteInject [iIter] = iChar;
}
}
The arguments are a file handle to the file with data we want to hide, and the number of bytes per chain we use to hide data. We call the InjectHiddenData method in the rtgen program just after having generated random data (cwc.GenerateRandomIndex();, line 206 of file RainbowTableGenerate.cpp).
Our modified rtgen program allows us to generate an unsorted rainbow table with hidden data. The only way to detect this hidden data is with statistical analysis, provided that the hidden data doesn’t appear random. There are no broken chains that indicate hidden data, unlike with the previous method.
The disadvantage of this method is that you’ll have to generate a new rainbow table to hide your data, which is a lengthy process.
To extract the data file, use the same program as for the previous method, rtreveal
If you don’t feel comfortable using an unsorted rainbow table to hide data, I have probably two extra techniques for you.
One technique creates a sorted rainbow table without broken chains and it is fast. The disadvantage is that it stores much less hidden data. But you’ll have to wait a bit before I publish this technique. I’ve submitted an article about this steganographic technique to 2600 Magazine, and I can only release it after it gets published or refused.
The other technique also creates a sorted rainbow table without broken chains and it is fast, but I still have to work on it. It works, but it might be detectable. I’ll publish it when I’ve finished working on it.
Click Fraud
After last week’s world-wide entertainment, I’m continuing with the more serious topic of steganography and rainbow tables, but first a small remark.
Some persons have commented that I didn’t discount the click fraud factor. The reason why I didn’t is that the motivation of the persons who clicked on my ad doesn’t matter at all. If it’s a person clicking on a “malicious” ad to commit click fraud, the result is the same: the cybercriminal gets a shot at trying to infect his machine.
And if it’s a program instead of a person doing the click fraud, the result is also the same if it’s a Windows program using the MS IE ActiveX component. I’m waiting for feedback to try to quantify the amount of non-Windows automated click-fraud that could have impacted my Google Adwords campaign. I’ll post an update when I get said feedback.
Didier Stevens 