Didier Stevens

Wednesday 28 November 2007

Quickpost: DisableAMD & DisableRegistryFools

Filed under: Quickpost — Didier Stevens @ 9:25

Ever started cmd.exe to see this: “The command prompt has been disabled by your administrator”?

It means that a GPO has been set to disable cmd.exe. This is not the same as the Software Restriction Policies. There is a special policy for cmd (and another one for regedit).

When started, cmd.exe checks for the existence of a certain key in the registry and decides to continue execution based on the value of this key. This key is DisableCMD and sits in Software\Policies\Microsoft\Windows\System. For regedit.exe, the key is DisableRegistryTools in Software\Microsoft\Windows\CurrentVersion\Policies\System.

There are many hacks to bypass this technique, depending on what kind of control you have as a user. When you have only control over the content of the programs you execute, use this trick: edit a copy of cmd.exe with a binary editor, search for DisableCMD and change it to something else, like DisableAMD. This copy of cmd.exe will now look for a key that doesn’t exist, and thus continue execution. For regedit, I renamed the key to DisableRegistryFools.

Mark Russinovich has another, elegant hack for this: he starts the program and injects a DLL that intercepts calls to the registry API and filters the return values. Limited users can inject DLLs into their own processes. But since Microsoft bought Sysinternals, his tool (GPdisable) is not available anymore.


Quickpost info


Monday 26 November 2007

Update: UserAssist V2.4.2

Filed under: Forensics,My Software,Update — Didier Stevens @ 9:29

Just a small change in this new version: now you can disable the automatic loading of the local registry data when the UserAssist tool is launched. Use the “Load at Startup” menu command.

The setting is saved in Isolated Storage, in a file called UserAssist.config.

Tuesday 20 November 2007

Quickpost: Another Funny Vista Trick with ASLR

Filed under: Hacking,Quickpost — Didier Stevens @ 8:06

Dave Maynor’s Vista ASLR tricks post got me thinking. And today, after some inspiring presentations at TechEd last week, I took the time to do some testing. Set the appropriate bit (0×4000) in the DLL Characteristics field of the PE header, and you turn on ASLR for your program of choice. So clearing the bit will disable ASLR, but will Windows File Protection prevent you from changing the program? I didn’t think it would, because you’re only touching the PE Header, which is not protected by the Authenticode signature.

Turns out it does work: you can disable ASLR for a given program, like Internet Explorer. And WFP will not restore the file. But for another reason than I thought: with Vista, WFP is actually called Windows Resource Protection. And it works differently: files are protected by Security Descriptors, and are not replaced automatically when deleted or modified. So the neat trick of deleting a system-file in Windows XP (like utilman.exe) only to see it reappear a couple of seconds later, doesn’t work anymore with Vista. Change the Security Descriptor of the file in Vista (taking ownership and giving you delete rights), delete the file, and it’s gone. No more resurrection.

If you want to play with the ASLR toggle, you can use stud_pe to edit the PE Header and Process Explorer to test it.

So why would you disable ASLR? I don’t know, I just think it’s a funny trick ;-) . But maybe you got an idea? Let me know, post a comment.


Quickpost info

Monday 19 November 2007

The Sony Rootkit V2.0

Filed under: Malware — Didier Stevens @ 10:14

Rest assured, this is not another Sony rootkit rant…

Back in August, F-Secure blogged about another Sony Rootkit. And McAfee was quick with posting additional info on their blog (they produced a screencast of the rootkit in action, saving me some analysis time).

I downloaded the software when F-Secure blogged about it, and since then I’ve been scanning the rootkit regularly with VirusTotal, to see how the detection rate evolved in time.

At first, as was to be expected, not a lot of AV products detected this rootkit:virustotal-fsm-20070830.png

I take this opportunity to illustrate once more that you have to pay attention when analysing VirusTotal’s results. Did you notice that F-Secure doesn’t detect the rootkit? How come, they announce this new Sony Rootkit but they don’t detect it? If you read their blogpost carefully, you’ll see that they detected this with their HIPS and anti-rootkit technology. But there are no specific signatures to detect this, hence the F-Secure AV on VirusTotal doesn’t detect it.

The detection rate is higher at the time of writing: 13 out of 32.

Some of the names given to this rootkit might surprise you:

  • Potentially harmful program HackTool.CIB
  • potentially unwanted program HideVault
  • Filesystem Monitor

You’ve to understand that a program exhibiting rootkit-like behavior and published by a company, is more likely to be handled differently by AV companies than a program from a criminal.

There is a higher probability that customers object to the fact that their AV product removes these company-issued programs. Removal could hamper the correct operation of the system (or device in this case). Some AV companies will label this kind of program (e.g. the nice euphemism potentially unwanted program) and even provide an option to exclude them from removal.

There is also a higher probability that companies developing these unwanted fight the detection by AV software, and even go as far as taking legal action against the AV companies.

All this is reflected in the rather low detection rate of this rootkit by the AV products on the VirusTotal site. After all, it’s almost 3 months since F-Secure broke this.

Friday 9 November 2007

Quickpost: Checking Gmail on N800 Securely

Filed under: N800,Quickpost — Didier Stevens @ 11:22

Nokia released an application (mnotify) to monitor your Gmail inbox from an N800. Here‘s an installation howto.

Mnotify has a menu command to open your Gmail inbox in the browser (View inbox). It uses HTTP, not HTTPS. So I wondered if the mnotify also used HTTP for mail checking?

It doesn’t. I looked at the traffic with tcpdump, and the mail check is done with HTTPS. So if you’re on a wireless network you don’t trust, it’s safe to let mnotify check your mail, but don’t view your inbox with it. Use HTTPS to view your Gmail inbox.

I’ll use my N800 to connect to an untrusted network next week ;-)


Quickpost info

Tuesday 6 November 2007

Update: USBVirusScan 1.6.1

Filed under: My Software,Update — Didier Stevens @ 7:44

This new version of USBVirusScan adds a new placeholder %f and provides debugging support.

%f contains the filesystem of the inserted drive, like NTFS, FAT, CDFS, …

Newer versions of DAEMON Tools (a virtual CD-ROM utility to mount CD images) report to Windows as a removable drive, thereby triggering USBVirusScan. You can use %f in your scripts to detect this and execute the appropriate action. For example, if you want to scan each USB drive with Avira but don’t want to scan images mounted with DAEMON Tools, use this script (avira.vbs):

dim WshShell

Set WshShell = WScript.CreateObject("WScript.Shell")

if Wscript.Arguments.Item(1)  <> "CDFS" then
	WshShell.run """C:\Program Files\Avira\AntiVir PersonalEdition Classic\avscan.exe"" /GUIMODE=2 /PATH= """ & Wscript.Arguments.Item(0) & ":\""", 1, true
end if

Start USBVirusScan with these parameters: USBVirusScan wscript avira.vbs %d %f

The balloon info also contains information about the filesystem of the inserted drive:

usbvirusscan_balloon_cfds.png

A new flag, -d, adds debugging support to USBVirusScan. When this flag is present, USBVirusScan will write debug output when drives are inserted. This debug output can be viewed with DebugView.

A word of caution about DAEMON Tools. I use an older version of more DAEMON Tools, but newer versions contain an adware component, that you should be able to skip when installing.

Saturday 3 November 2007

Quickpost: Scanning Scripts

Filed under: Quickpost — Didier Stevens @ 10:32

After reading my zero byte padding post, someone asked me how McAfee intercepted scripts.

The Microsoft VB script and JS script engines are COM objects. Looking at the CLSID registry data for these COM objects, you’ll find this info (Windows XP SP2):

VB Script Language
HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
InprocServer32 -> C:\WINDOWS\system32\VBScript.dll

JScript Language
HKEY_CLASSES_ROOT\CLSID\{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
InprocServer32 -> C:\WINDOWS\system32\JScript.dll

When McAfee VirusScan with ScriptScan is installed, the InprocServer32 reference for both COM objects is modified: C:\Program Files\Network Associates\VirusScan\scriptproxy.dll

This is how VirusScan intercepts script execution. They install a “proxy” (scriptproxy.dll) that will scan the scripts before they are passed on to the appropriate scripting engine (VBScript.dll or JScript.dll).

One important implication of this mechanism, is that ScriptScan will only protect script execution when the scripts are executed with the MS COM objects, like IE does. But Firefox doesn’t work with COM, it has its own JS engine (SpiderMonkey), so ScriptScan does not scan scripts executed by Firefox.

There are documented cases where scriptscan causes problems on servers, the proposed solution is to remove the proxy: regsvr32 /u scriptproxy.dll

I wonder if there is malware out there using this trick? And one can also write his own proxy DLL to intercept scripts.

Of course, McAfee VirusScan is not the only AV providing protection against malicious scripts, most modern AV provide this. For example, Kaspersky’s Anti-Virus uses the same technique, but their proxy DLL is scrchpg.dll.

Friday 2 November 2007

Quickpost: Installing Kismet on a N800

Filed under: N800,Quickpost,WiFi — Didier Stevens @ 8:37

Update: Since the Kismet package isn’t available anymore, here is Installing aircrack-ng on a N800.

To run Kismet on a N800, you need to be root. Normally, you don’t have root access on a N800, you do need to apply a hack to get it. There are several hacks (flashing, sshd, …) but I prefer the godmode trick.

Here’s how I did it, use at your own risk:

  1. Install Osso Xterm
  2. Install godmode
  3. Install Kismet

Now I did install some other packages between 2 and 3, that’s probably why I didn’t have to install ncurses-base explicitly.

To start Kismet, start Xterm and type these commands:

  1. sudo gainroot
  2. kismet

Quickpost info


Thursday 1 November 2007

Announcing Quickposts

Filed under: Announcement — Didier Stevens @ 18:55

From now on, I’ll intersperse my blog with Quickposts.

I’ve a need to post short tips and tricks, mainly for my own reference. These Quickposts will document solutions for small problems I encountered during my work or research. I could also use a Quickpost to announce a discovery I don’t plan to research extensively.
The main characteristic of Quickposts will be the limited amount of time and research I spend on them, hence the quality of the content will suffer.

Quickposts have their own Quickpost category, the title will always start with Quickpost:, and if a Quickpost requires updating (to correct errors), I will edit the post instead of publishing a new Quickpost.

The first Quickpost will be about installing Kismet on my N800.

Of course, I stay committed to my weekly posts.

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers