For weeks I’ve been trying to get my Verizon FIOS bill. Verizon happily debits my credit card every month but I need the receipts. I’ve logged into my account online and all I get is the below message saying the system isn’t working:

I emailed them and got no help:

Note: I LOVE automated completely useless responses.

Verizon decided to step up their incompetence when I tried to access my billing info yet again tonight:

So at this point, I guess I get to spend hours on hold waiting for them. Oh how I love incompetent multinational companies.

A new version of Hex-Rays is out today. Combined with my eval copy of Binnavi today is just a good day!

Saw this: http://www.theregister.co.uk/2010/01/26/aurora_attack_origins/

The link argues that the unusual CRC in Aurora that uses 16 unsigned ints isn’t actually that uncommon… in fact it’s in a lot of EE type text books.

This find is due to Sara. A quick check in the traffic logs for a host sent to the help desk showed a bit odd network traffic. We saw the computer polling laptopantivirus.microsoft.com/block.php. Looking quickly you think, well that’s Microsoft – it’s okay! Well, Microsoft using PHP? That’s not overly likely and the “laptopantivirus” part seems sketchy. If you look at the IP address it’s 195.88.190.54 – Registered to Bigness Group based in Russia.

See below

DoH! is meeting THIS WEDS Jan 27th at 7pm! Again at GWU/Foggy Bottom.

Greetz “Tu Snipa”. Adam, great blog entry: http://www.thecoverofnight.com/blog/?p=214

Great link here: http://www.secureworks.com/research/blog/index.php/2010/01/20/operation-aurora-clues-in-the-code/

Basically they found a CRC algorithm in the binary that Googling appears to indicate is used only in Chinese language forums. Very nice hard data point.

Now that the Symantec write up seems legit here’s a little background digging I did the other day on the domains. I think this sort of information is mainly idle speculation, but rather than simply presenting opinions I’m going to provide screenshots. This is based on looking up network information for the domains listed by Symantic, namely:

• yahooo.8866.org
  
• sl1.homelinux.org
  
• 360.homeunix.com
  
• li107-40.members.linode.com
  
• ftp2.homeunix.com
  
• update.ourhobby.com
  

Here’s what I saw:

Interestingly here, the first hostname is in Korea – not China. If you want to ping up the admin the info is listed as:

Another domain sl1.homelinux.org is again shared hosted, and it has multiple domains including those associated with Russia:

Another hostname 360.homeunix.com has a little more info. The hostname is set to localhost, but the domain appears to be in the US:

Same with update.ourhobby.com

Though in fairness it appears to be only a US based service:

Li170-40.members.linode.com actually had some info:

If you look above you see the IP is US based with US based points of contact – though one appears to be Canadian as well.

yahoo.8866.org,  finally this one appears to be in China

A lot of the speculation is based on IP addresses and where they resolve to. I believe this is a poor way to do analysis. If I were a criminal or a nation state, I would certainly own a lot of 3^rd party easy hosts and create a very complex path that would be near impossible to establish my true identity. I don’t believe the Chinese would be easily attributed back to Chinese IP addresses. Additionally, if you look at the above, it’s not entirely clear that China is the sole source. There are Chinese, Korean, and US hosts/domains. This might provide things to think about as others are speculating about attribution based on where the malware connects back to.

UPDATE:

Saw this link associated with the email address (ppyy@bentium.com): http://archives.neohapsis.com/archives/postfix/2001-05/1841.html. Further if you look up the  domain 8866.com you see things like: http://google.com/safebrowsing/diagnostic?site=8866.org/

The more I see the more it looks like a regular malware domain. Maybe “the real badguys” hacked 8866.com to then hack google and those 36 other companies, but if I wanted to say off the radar at all this seems like a really bad idea. I’m thinking regular malware.

All screenshots are from www.centralops.net or www.robtex.com

The following write up is available from McAfee at: http://vil.nai.com/vil/content/v_253416.htm

It’s a nice detailed technical write up, but look below:

Why do they hide the hostname and not provide the IP address? Do they think the attacker is unaware of the discovery? Is McAfee selling that information as a “professional service”? Seriously, its only value is to enable network IDS sensors and staff to identify and block any such traffic, but apparently a hostname is too much to ask.’

UPDATE:

Plug for Symantec, they actually drop names here: http://www.symantec.com/security_response/writeup.jsp?docid=2010-011114-1830-99&tabid=2

Values are:

• yahooo.8866.org
• sl1.homelinux.org
• 360.homeunix.com

• li107-40.members.linode.com
• ftp2.homeunix.com
• update.ourhobby.com

I had heard from a knowledgeable source that he thought the Symantec writeup was crap. McAfee and Symantec seem to agree on a lot of details though. Point Symantec and thanks for the info!

I have been monitoring what appears to be a custom IRC based bot infection for several weeks. The current executable has an MD5 5663af5192f2963093b489c1eff171c3. The executable is a VB6 P-Code project that wraps the real payload in the VB virtual machine. Basically they create a packer using VB.

The bot calls itself Plague Bot and C&C is readily seen by network traffic analysis – though it does has some limited antidebugging anti-wireshark techniques. It grabs files from hxxp://www.hentaimoviez.com/ct/ Pound.exe (formerly grabbed Weed.exe). The current IP is 174.132.234.74. The IRC C&C is running at: 174.133.63.91.

The binary was first submitted to VirusTotal on 1/12/2010 and also submitted to various AV vendors. Here’s today’s result on VirusTotal:

Please visit Adam’s Blog at the Cover of Night for much further analysis.

I was almost pwned by an Acrobat reader exploit while visiting a page on blogger. I was forwarded to a 3rd party site. It autoloaded a PDF that appears to attempt to exploit the 3D vulnerability. Likely: http://www.securityfocus.com/bid/37761

The attack appears to have failed on Windows 7 64 bit and Acrobat Reader 9.2.

I cannot confirm the attack is for the cited bid, but it appears that way. After I have time for further analysis I will post more.

Sara Laughlin

Matthew Wollenweber

The George Washington University

{belevume, mwollenw}@gwu.edu

Technical Summary

A network IDS alert for Poison Ivy detects a possible attack from 72.52.166.40. The signature and traffic are insufficient to verify a malicious incident. Further analysis shows a portable executable downloaded from 121.14.149.32. Automated analysis indicates no virus but odd behavior. Detailed analysis indicates this is Trojan.Win32.BHOLamp which is likely a Poison Ivy variant. The initial dropper has MD5= e361fbcc45e23bc0913ded251dd9753c and drops a DLL for a backdoor with MD5=2c97cef5389caaf82cff40c98a9bdb13.

Introduction

On January 7^th, 2010 GWU ISS Security identified a potential threat by a signature alert on a network sensor. Later analysis confirmed a security threat not currently detected by most antivirus products. This report details how the malware was detected and the analysis of the threat. Additionally, we hope this informs readers of a current threat.

Initial Detection

Initial detection is based upon an alert from a custom signature for the Poison Ivy Remote Access Trojan server. The signature looks for a common binary message observed in Poison Ivy communications. However, the signature is not definitive. Below is an example hit on the signature

Next we searched the IDS for other entries associated with the suspected victim IP address. We discovered the victim recently downloaded a Packed PE (executable file). Downloading executables is quite common so we still were reluctant to identify the traffic as malware.

We proceeded to analyze the PE as our next step. Unfortunately this step should have been delayed. If we had examined the attacking IP address, seen below we would have been far better off.

A quick googling of the IP yields:

Binary Analysis

Our IDS logs traffic associated with an alert. From that we obtain the file and HTTP GET Request.

Manual inspection of the above indicates an EXE appeared to be transferred and that a username and computer name was sent to the server. The MD5 of the executable is e361fbcc45e23bc0913ded251dd9753c.

Initial analysis was automated by the standard series of online tools. Virustotal had no successful hits. Anubis and ThreatExpert were inconclusive.

Browser Helper Objects are fairly common, but some of the CLSIDs were odd.

CLSIDs are sufficiently large as to be unique for any application. A CLSID of all 0s struck me as unprofessional. Additionally, the executable dropped a DLL:

The file name is random, but the path and MD5 (2c97cef5389caaf82cff40c98a9bdb13) appear constant.

We repeat the automated analysis with dropped DLL. Again no detection with VirusTotal. But with ThreatExpert we see the following:

The DLL connects back to the original host with the same page that downloads an executable. This further indicates malware.

Curious, we continue to Google CLSIDs and finally discover: http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FBHO.gen!LL

This confirms the malware as Trojan.Win32.BHOLamp.

Network Analysis

The following screenshots indicate the attacking IPs are shared hosted computers residing in China. The type of hosting and country of origin do not necessitate that the traffic is malicious but when combined with ambiguous behavior one should consider such factors.

Other Analysis:

The malware does not always immediately call back to the remote server. Therefore, if one relies only on ThreatExpert that key piece of evidence might be missed. Loading the DLL into IDA Pro we find no URLs and few strings in the executable. However we see large data sections. Therefore we decide to run the DLL in Immunity Debugger. This is done as follows:

You run rundll32 with the DLL filename and function as arguments. Next we configure Immdbg to break on every module load and wait for OQpEg5WJ to be loaded. Not seeing anything immediately interesting we continue to watch modules load until an internet related module is loaded. We know to expect modules to be loaded because of the following code:

As expected we see the following:

Urlmon is loaded first followed by Wininet and WS2_32. We set standard breakpoints on WS2_32.send and various Wininet openinetnetconnection type functions. Despite running standard Immdbg anti-debug scripts the malware still detects debugging and crashes. However, we scan memory for “http://” and find the relevant URL and also confirm it’s the only malware related URL (namely http://121.14.149.132/hia12/ter.php).

Conclusion:

Many IDS analysts are reluctant to classify an event as malicious without a confirmed antivirus hit. This paper demonstrates a case study where our systems detected a probably event and we manually verified the incident despite the malware not being detected by any AV products. This is especially important due to the ability to rapidly pack malware and for polymorphic kits like Poison Ivy. Reversing the binaries confirmed the malware, but one should also consider the behavior indicated by tools like Anubis/ThreatExpert combined with network traits such as location and domain names.

References

http://www.efblog.net/2009/02/creating-online-polymorphic-malware.html

http://www.microsoft.com/Security/portal/Threat/Encyclopedia/Entry.aspx?Name=Backdoor:Win32/Poisonivy.E&ThreatID=-2147367341

http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FBHO.gen!LL

http://www.threatexpert.com/report.aspx?md5=2c97cef5389caaf82cff40c98a9bdb13

http://www.threatexpert.com/report.aspx?md5=e361fbcc45e23bc0913ded251dd9753c

Looking over IDS logs I noticed something very odd. A client with a USER-AGENT string indicating Firefox running on a Mac (Say: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5), downloading an EXE from a malicious host. A few options came to mind. User-agent switcher, a virus infection Mac via CrossOver or some weird mix with VMware Fusion were all options. It also occurred to me that the same users, desperate to get their porn fix might actually repeatedly download EXEs on a mac to get their ugh, codec.

None of that felt quite right. Then I remembered an older vulnerability where one could cluster bomb the default download directory with arbitray files — to hope a user might click or that you might trigger a secondary vulnerabilty. I can’t find references to this but I decided to check the default behavior of Firefox. As it turns out, if you click to download an EXE, JS initiaties the download dialog, whatever the file actually starts downloading before you click accept. Thus even if you click no/cancel, the file still downloads. Therefore, the network IDS triggers and you see odd things like Macs downloading EXEs.

Debugging a Xul Javascript Memory Corruption Bug in Firefox 3.5

mjw@cyberwart.com

November 2009

Introduction

Debugging complex software can be a difficult task. Even software as familiar as Firefox is often black boxes that few understand. This paper describes the process and mistakes I used to investigate a bug I discovered in the PL_DHashTableOperate function. This function is a memory management hash table that is used during garbage collection, among other things, inside XPCOM Cycle Collector.

Noticing the bug

This bug wasn’t discovered using elaborate fuzzing techniques. Rather, it was noticed while browsing a friend’s website:

The bug only presents in Firefox and only consistently (among systems I’ve tested) on Windows 7 (32 bit). Crashes are more likely when Google Toolbar is installed but that is not a requirement.

The page obviously utilizes a Google Maps and loads a plethora of data as seen above. After many markers are loaded the browser hangs and crashes with a memory read error near NULL. During the crash Firefox consumes in exess of 1.4GB of memory.

Debugging the Process

Firefox is a complex multithreaded application. Consuming large quantities of memory and/or crashing does directly point toward the problem. First we must consider our debugging environment. Initially, we were inclined to use Immunity Debugger (immdbg) as the layout and functionality are, in our opinion, superior to other options. Immdbg’s integrated Python is almost a must have. Unfortunately, Immdbg does not support recent debug symbols (PDB files). Given the complexity of Firefox, this is a significant handicap and we therefore opted to use Windbg. First to leverage this, remember to add Firefox’s debug server: http://symbols.mozilla.org/firefox

Next we attach the debugger and identify the runway thread:

Once we’ve identified the runaway thread, we obtain a stack trace.

The stack trace shows multiple calls to xul!AppendNodeTextNodeContentsRecurse. This seems like a good place to start. Appending generally implies a memory operation and we know our problem is related to heap allocations. Search for Xul, we find the XUL is Mozilla’s XML parsing library. Now we have a parser and a memory problem, which seems even more likely to be buggy.

We next use Immdbg to visualize the data being consumed by the thread:

The data corresponds to the restaurant information being loaded by the Google Maps API. This data is in a for loop and is XML. Looking at the Javascript we see:

In particular we note map_sidebar.appendChild() call. Appending map XML data seems very relevant to our bug so we begin testing. Unfortunately, it turns out this isn’t directly related to our bug. We will shortly provide an accurate stack trace of the problem, but our testing yielded some (mildly) notable results.

First, we tried excessively calling the appendChild() function to create a memory fault. This will sometimes cause Firefox to crash, but not with our fault. It also takes excessively long for the crash to occur (likely due to the small amount of data we are appending).

Observers might note the s string we’re building. We also thought we might be able to read out of bounds on markers to obtain unauthorized reads. This didn’t work. Javascript appears to alloc() memory for any marker[i].

Next we tried to manipulate the markers by going out of bounds and by inserting fixed data. This consumed memory but generally didn’t create a real problem.

Again, no notable effect.

Changing Directions

Next we observe the stack traces more thoroughly. We use Windbg’s !analyze and !exploitable features. These help some – mainly analyze.

We identify the problem in xul!PL_DHashtable. The problem occurs when ECX is passed in and used as a read address.

The calling function to PL_DHashTableOperate is xul!GCGraphBuilder::NoteRoot

A stack argument to NoteRoot is passed to PL_DHashTableOperate which uses it without bounds checking. Oddly, NoteRoot does a check on this value but still calls PL_DHashTableOperate.

Next we research the class a little more:

Looking at a chart of the relationships of the class we’re simply bewildered. Look at this:

How could such a thing not be buggy?

Tracing the problem is complicated. The libraries use C++, which often mangles call stacks. The objects use inheritance and the Garbage collector itself is a bit outside the scope of any individual class. It’s simply a related class that cleans up stray objects according to a complex tree algorithm.

Source

We obtain the source for the functions from Mozilla. The source may not be entirely accurate as it’s not guaranteed to be the build source.

AddXPConnectRoots iterates over Javascript contexts using the variable acx. It always calls NoteRoot. NoteRoot appears to do some validation, but looking at the disassembly we know any NULL void * root, should trigger the bug – as anything less than 0x0A should always continue to the vulnerable function. We’re not sure why the assert fails – the compiled code does some checking but not as the souce code indicates. We might very well be looking at different versions of code/binary.

Exploitation – Epic Fail?

Given the above, exploitation should consist of:

1. Generate objects in javascript.
2. Create a condition where the object is preselected for cleanup
3. Trigger the Garbage Collector
4. Delete the object.
5. Crash

This is a race condition bug and we have not been able to produce reliable code to exploit it. I’m not sure if I will try further for a DoS. I have seen EIP over written (once in MANY debug iterations). I’ve also seen a few writes. This likely occurs do to quirks in the free-ing process and timing.

The details are complicated heap kung-fu. The GCGraphBuilder class implements the purple portion of the garbage cycle collector. Described as:

     64                 : // Purple nodes are *candidates* for being scanned. They are nodes we

      65                 : // haven't begun scanning yet because they're not old enough, or we're

      66                 : // still partway through the algorithm.

      67                 : //

      68                 : // XPCOM objects participating in garbage-cycle collection are obliged

      69                 : // to inform us when they ought to turn purple; that is, when their

      70                 : // refcount transitions from N+1 -> N, for nonzero N. Furthermore we

      71                 : // require that *after* an XPCOM object has informed us of turning

      72                 : // purple, they will tell us when they either transition back to being

      73                 : // black (incremented refcount) or are ultimately deleted.

Continues:

    78                 : // An XPCOM object is either scan-safe or scan-unsafe, purple-safe or

      79                 : // purple-unsafe.

      80                 : //

      81                 : // An object is scan-safe if:

      82                 : //

      83                 : //  - It can be QI'ed to |nsXPCOMCycleCollectionParticipant|, though this

      84                 : //    operation loses ISupports identity (like nsIClassInfo).

      85                 : //  - The operation |traverse| on the resulting

      86                 : //    nsXPCOMCycleCollectionParticipant does not cause *any* refcount

      87                 : //    adjustment to occur (no AddRef / Release calls).

      88                 : //

      89                 : // An object is purple-safe if it satisfies the following properties:

      90                 : //

      91                 : //  - The object is scan-safe.

      92                 : //  - If the object calls |nsCycleCollector::suspect(this)|,

      93                 : //    it will eventually call |nsCycleCollector::forget(this)|,

      94                 : //    exactly once per call to |suspect|, before being destroyed.

      95                 : //

      96                 : // When we receive a pointer |ptr| via

      97                 : // |nsCycleCollector::suspect(ptr)|, we assume it is purple-safe. We

      98                 : // can check the scan-safety, but have no way to ensure the

      99                 : // purple-safety; objects must obey, or else the entire system falls

     100                 : // apart. Don't involve an object in this scheme if you can't

     101                 : // guarantee its purple-safety.

     102                 : //

     103                 : // When we have a scannable set of purple nodes ready, we begin

     104                 : // our walks. During the walks, the nodes we |traverse| should only

     105                 : // feed us more scan-safe nodes, and should not adjust the refcounts

     106                 : // of those nodes.

     107                 : //

     108                 : // We do not |AddRef| or |Release| any objects during scanning. We

     109                 : // rely on purple-safety of the roots that call |suspect| and

     110                 : // |forget| to hold, such that we will forget about a purple pointer

     111                 : // before it is destroyed.  The pointers that are merely scan-safe,

     112                 : // we hold only for the duration of scanning, and there should be no

     113                 : // objects released from the scan-safe set during the scan (there

http://people.mozilla.com/~mnandigama/codecoverage_html/xpcom/base/nsCycleCollector.cpp.gcov.html

The exact problem occurs here:

PtrInfo*

 GCGraphBuilder::AddNode(void *s, nsCycleCollectionParticipant *aParticipant

                         IF_DEBUG_CC_PARAM(PRUint32 aLangID)

                        )

 {

     PtrToNodeEntry *e = static_cast<PtrToNodeEntry*>(PL_DHashTableOperate(&mPtrToNodeMap, s, PL_DHASH_ADD));

     PtrInfo *result;

     if (!e->mNode) //BUG HERE. e may be null, but we access e+0x4
				

        {

         // New entry.

         result = mNodeBuilder.Add(s, aParticipant

                                   IF_DEBUG_CC_PARAM(aLangID)

                                  );

         if (!result) {

             PL_DHashTableRawRemove(&mPtrToNodeMap, e);

Update: This bug – https://bugzilla.mozilla.org/show_bug.cgi?id=502687 also appears that the crash occurs on out of memory (OOM). Our testing and other reports indicate this bug can also appear when NOT OOM.

Lessons Learned

Going from random bug to some level of understanding in this case was difficult. A stack trace doesn’t really identify the problem. The source of the problem is in Javascript, which we have a lot of and it’s difficult to pinpoint the exact problem.

We laid out this paper, hopefully clearly. Our testing wasn’t so straightforward. Hopefully our process will help others. We suggest profiling the memory operations using runaway or following the heap to see what particular operations are most likely related to the memory corruption problem. Next do some simple searching in the Javascript to find possibly related strings. Next we suggest getting a solid stack trace and understanding of the disassembly to direct further testing. We largely failed at this. We approached the two ends (javascript and stack trace) as separate objectives and wasted much time.

If we were repeating a javascript bug, we would probably use a proxy such as WebScarab. Several times during the testing it would have been nice to modify javascript from the original offending website. A proxy with data meddling would have been beneficial. Simply copying the page and editing doesn’t work as the app is AJAX oriented.

Future

Like COM for windows. Sounds like fun.

Also we know of a bug in Flash that we’d like to leverage similar techniques to exploit.

Finally

Proposed fix (someone posted to Mozilla for bug 502687)

Bug 502687 - GCGraphBuilder::AddNode crashes on OOM.

diff --git a/xpcom/base/nsCycleCollector.cpp b/xpcom/base/nsCycleCollector.cpp

--- a/xpcom/base/nsCycleCollector.cpp

+++ b/xpcom/base/nsCycleCollector.cpp

@@ -1323,16 +1323,19 @@ GCGraphBuilder::~GCGraphBuilder()

 }

 PtrInfo*

 GCGraphBuilder::AddNode(void *s, nsCycleCollectionParticipant *aParticipant

                         IF_DEBUG_CC_PARAM(PRUint32 aLangID)

                        )

 {

     PtrToNodeEntry *e = static_cast<PtrToNodeEntry*>(PL_DHashTableOperate(&mPtrToNodeMap, s, PL_DHASH_ADD));

+    if (!e)

+        return nsnull;

+

     PtrInfo *result;

     if (!e->mNode) {

         // New entry.

         result = mNodeBuilder.Add(s, aParticipant

                                   IF_DEBUG_CC_PARAM(aLangID)

                                  );

         if (!result) {

             PL_DHashTableRawRemove(&mPtrToNodeMap, e);

References

https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server

http://doxygen.db48x.net/mozilla-full/html/dd/ded/nsCycleCollector_8cpp.html

https://developer.mozilla.org/en/XPConnect

https://developer.mozilla.org/en/Using_XPCOM_in_JavaScript_without_leaking

https://developer.mozilla.org/en/interfacing_with_the_xpcom_cycle_collector

http://en.wikipedia.org/wiki/XUL

https://developer.mozilla.org/En/XUL

https://wiki.mozilla.org/CrashKill/QA

http://doxygen.db48x.net/mozilla-full/html/d1/d9a/classGCGraphBuilder.html#9eaee96ffac342f5df2a84561b481d4a

http://doxygen.db48x.net/comm-central/html/classnsCycleCollectionTraversalCallback.html

https://bugzilla.mozilla.org/show_bug.cgi?id=502687