SpiderLabs Anterior

Machine Learning Update 1

2013-05-20T11:16:55-05:00

It has been almost exactly a month since my last post regarding the new project I am working on, so I figure it is time for an update. First off, I was excited and encouraged with the responses I received via Twitter after my initial posting. One response in particular mentioned the related work that @silviocesare is doing with the SimSeer project as well as a book he co-authored “Software Similarity and Classification”. Both appear to be excellent resources and I plan to check them both out in more detail as time allows.

It seems as if the stars were in alignment because just after I announced the project, a little birdy (@spookerlabs) let me know that a free Machine Learning course from Stanford University was being presented through Coursera . Did I mention that it is free? I signed up for it and we are about four weeks through the 10-week course. I have to say that I am pretty impressed with how the course is laid out and presented. We wasted no time jumping right into the math, but that shouldn’t really be of any surprise to anyone. The course mainly applies Linear Algebra, but an understanding of at least first year Calculus is a definite bonus. For example, here is a slide from the first week of the class covering the application of a Linear Regression Model and the Gradient Descent Algorithm, which would be used to help predict something like house pricing based on known square footage:
Admittedly it has been a while since I’ve applied math concepts like this, in my head I was secretly hoping for something more along the lines of this:

All joking aside though, if you are a self-paced learner this is a great resource that is being made available for free. It is most definitely worth checking out what they have to offer.

The course uses the software package Octave (similar to Matlab) to program solutions to exercises. The Octave language gives you command line input and some pretty impressive graphics manipulation capabilities to model your data with.

Additionally I picked up the book “Machine Learning for Hackers”. I haven’t gotten too deep into it yet, but the authors are using the language R to solve their problems. R is a free open-sourced tool similar to S. I am looking forward to comparing what I learn in the online course with what I am able to extract from the book. I think it is typically a good idea to not get all of your knowledge from a single source.

In general these tools/languages such as R and Octave would likely be used to rapidly prototype your machine learning theories against your data sets. They are great for visualizing and manipulating your data sets, and quickly testing your hypotheses. However, once you are satisfied with the output of your learning algorithm, you will likely want to implement the solution with a more efficient language such as C or Java to use in your production environments. I don't know at this point where to draw that particular line in the sand, but it is something to keep in mind as you work towards your goals.

I am trying to balance this bootstrapping type of learning along with my normal daily duties here at work, and there have already been times when I’ve had to put this stuff down while dealing with the influx of “real work”, but I’m quite excited about the things I’m picking up already, and I’m itching to get my hands dirty. My hope is that by the end of the course I will know enough to be dangerous and I can start publishing some of my initial results right here. Stay tuned...

SpiderLabs Radio May 17, 2013 w/ Space Rogue

2013-05-17T16:14:27-05:00

This weeks episode of SpiderLabs Radio hosted by Space Rogue is brought to you by Trustwave's Threat Intelligence Service and covers Topiray, Viral, TFlow, Kayla go to jail, DHS selling 0-days, OSX Malware, SkyNews, Colin was here, OpPetrol, Onity locks still getting owned, java renumbering, Taiwan and Philippines equals Cyberwar!, General Keith at Blackhat and a lot more!

Listen to SpiderLabs radio in iTunes.

Or you can download the MP3 file directly here.

Or listen right from your browser with this embedded player.

Alina: Following The Shadow Part 1

2013-05-17T13:01:23-05:00

Last I spoke with you, I went into the details of a family of Point of Sale (POS) malware, named 'Alina'. At the time, I chose to talk about version 4.0, mainly because I felt it gave a good representation of the entire family itself. In the course of my research, I've been able to acquire 12 distinct versions. As you may recall from the last blog post, Alina is versioned in the User-Agent field for all HTTP-based communication. For example, the User-Agent last time around was "Alina v4.0". Knowing this, I plan on talking about the evolution of this malware today, going from version 0.1 up to 5.5. Just for reference, I have the following versions at this time:

0.1, 1.0, 2.0, 2.1, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0, 5.2, 5.3, 5.5

I'm going to break up this post into a few different sections, and talk about how the malware family has evolved over time with respect to various categories. As I started writing this, it became apparent that it wouldn’t fit into one blog post. As such, I’ve split it up into different parts. For this blog post I’m going to focus on the creation timeline, exfiltration, and C&C.

Creation Timeline

Anyone familiar with the PE file format knows that there is a time-stamp field in the File Header that typically stores the time the file was compiled (I briefly mention it in a previous blog post, “Basic Packers: Easy As Pie” ). Attackers have the ability to 'stomp' this field of course, but there is no indication that any of the Alina samples were time stomped. Using this information, along with the version information provided in the User-Agent field, we attempt to provide a timeline of just when these versions first appeared.

I realize you may be noticing a few discrepancies with this timeline. The most obvious is likely the fact that version 1.0 appears to be older than 0.1, or the fact that 3.1 is older than 3.2. It's not an exact science I'm afraid, as we don't know exactly what the author was doing at the time. It's possible that he or she decided to simply recompile an older version and use it during a compromise, or perhaps some other events took place that would cause these oddities. It is also curious to note that both version 3.1 and version 0.1 were compiled with the 'debug' flag enabled. These are the only two versions in my possession that are compiled using this flag, which further adds to the mystery surrounding these particular versions. At any rate, it provides us a decent look at a general timeline of when this malware was created.

Unfortunately, version 5.5 utilized a UPX Protector layer, which destroyed the timestamp information in the PE header, which I'll discuss further in part 2. Based on the other information we have, however, it's likely fair to assume it was compiled sometime in March 2013, or early April of that same year.

Exfiltration

I talked about the exfiltration of version 4.0 in-depth during my last blog post, which you can find here. Let's take a step back, however, and look at how the author originally exfiltrated data and evolved his or her technique's over time.

v0.1/v1.0

Version 0.1 and 1.0 had a very simplistic technique for data exfiltration. Simply put, everything was sent in the clear with no obfuscation/encryption whatsoever. We can see an example of this below:

As you can see, there is simply one POST parameter of 'alina' that contains the clear-text track data. The only difference regarding exfiltration between version 0.1 and 1.0 appears to be the addition of the 'hwid' POST parameter in 1.0, which contains the volume serial number of the victim device. This is likely used as a unique identifier that allows the attacker to easily differentiate between victims.

v2.0

We see a significant leap in the evolution of Alina's exfiltration in version 2.0 of the malware. Namely, the author has decided to change the POST parameter names to something more discrete. Specifically, the previously named 'alina' parameter has been changed to 'a', the 'hwid' parameter has been renamed to 'b', and a new POST parameter of 'c' has been included, which contains the victim's hostname. We also begin seeing the first signs of encryption, as the track data has been XORed with a key of 0xAB, and then converted to hex. We see this technique of XORing the data and converting it to hex throughout future versions of Alina.

(Decrypted 'a' parameter using Ruby)

v2.1

Version 2.1 of Alina makes another leap in the evolution of this malware's exfiltration capabilities. It is at this time that we begin to see actual commands being implemented (discussed further in the C&C section). The 'b' and 'c' parameters have remained untouched, however, track data is no longer contained within the 'a' parameter. Instead, it is contained within the POST parameter 'cdata'. The same encryption routine is used to obfuscate this track data. We also see the addition of the ‘v’ parameter, which contains the version of Alina that is running.

The constant changing of POST parameters suggests that the author was either attempting to evade detections of network-based security solutions, or, perhaps more likely, simply was indecisive and was attempting to decide on the best way of sending this data to the server he or she controlled.

It was during this version that we also begin to see log messages being exfiltrated by the malware. Specifically, the 'ldata' parameter was used to send out logs periodically when certain events transpired. This log data was encrypted using the same XOR/hex technique used for track data. The malware also implemented a log level parameter in this version, which specified what logs to exfiltrate. We see this logging characteristic throughout a number of future versions of Alina.

v3.1

Version 3.1 did not vary greatly with regard to data exfiltration. The only apparent difference with POST requests is the addition of the “p” parameter, which contains the path of the Alina malware on the victim machine.

Additionally, it is in this version that we begin seeing a requirement for a 666 status code from the remote server. As mentioned in the last blog post, seeing a 666 status code is extremely unusual, and should raise an eyebrow or two for anyone monitoring network traffic. The requirement for this status code is an unusual decision for the malware authors to implement.

One other interesting addition in this version is the support for multiple exfiltration URLs. In total, three distinct URLs were utilized in the sample analyzed. In the event that a URL did not respond with the correct status code, or was unreachable, Alina simply attempted to try the next URL in the list.

v3.2

The main difference we see at this point is the fact that version 3.2 does not look for the ‘666’ HTTP status code, as well as the removal of the log exfiltration request. This is an anomaly, as we see these features reintroduced in versions 3.3 and above. This further adds to the evidence that version 3.2 was in fact created before version 3.1, as it doesn’t make a lot of sense to remove this feature and then reintroduce it.

v3.3/v3.4/v3.5/v4.0

From an exfiltration point of view, this version acts the same as version 3.1. One minor change we discover in version 3.4-4.0 is the removal of a minor piece of information in outbound log requests. Specifically, the output of the call to the Windows API call GetLastError is removed.

At this stage the author appears to be quite content with the exfiltration of his or her malware, as we see minimal changes to the overall structure it employs. You can see an example ‘download’ request of both versions below, illustrating the current POST parameter structure for these versions:

v5.2/v5.3/v5.5

It’s clear that a lot of change occurred between versions 4.0 and 5.2. Referring to our timeline, we see that about a month of time elapsed between these versions. This is abundantly clear with regard to exfiltration, as the author(s) have completely removed their previous structure and replaced it with a custom one. HTTP POST requests are still the transportation mechanism to exfiltrate data; however, the data inside this POST request is completely different. You can see this below. I display the raw hex of the request to illustrate that non-ASCII data is being sent across the wire:

After analysis of the binary, I was able to determine the encryption in use and map out the layout of the data being sent. Like previous versions, a simply XOR scheme is utilized to obfuscate this data. The first 76 bytes of data are simply XORed against the key of 0xAA. This provides us with the following (using the above request as an example):

Any data past 76 bytes utilizes a different XOR scheme for obfuscation. Specifically, the decoded data at byte offsets 18 through 35 are used as the XOR key. The screenshot below shows us the data starting at offset 76:

Now that we’ve been able to decode the data, let’s talk about how it’s structure. Specifically, let’s discuss how the data between byte offsets 0 through 75 is structured. I haven’t been able to identify everything, but there should be enough to provide you with a good grasp of the data that this blob contains.

Bytes 0-1 : Static Value
Bytes 2-16 : Alina Version / User-Agent (“Alina v5.2”)
Bytes 17-24 : Victim Volume Serial Number (Example: “bc0b5931”)
Bytes 25-26 : 2 Random Bytes
Bytes 27-35 : Command (“update”, “cards”, etc.)
Bytes 36-67 : Victim Hostname
Bytes 68-71 : Unknown – Likely Random 4 Bytes
Bytes 72-75 : Unknown – Likely Random 4 Bytes

One other interesting thing to note regarding version 5.x. When we begin to see log requests being sent across the wire and decoded, we notice some very unusual/interesting strings being used, as shown below:

It’s unclear what these strings, such as ‘[:112 <2>] {[!16!]}{[!46!]}’ mean, however, if I had to speculate I’d guess they were parsed by the server and used to indicate what data was sent. In the above example, it’s possible that the ‘{[!16!]}’ may represent process name, while ‘{[!46!]}’ represents its PID. This is purely guesswork, as I have not been able to obtain access to any Alina C&C servers.

Command and Control (C&C)

v2.1-v4.0

Command and control in Alina was not introduced until version 2.1. Up to this time, we simply see the author decide to automatically upload any discovered data to a single host. However, when version 2.1 was released, we notice the author’s decision to add an option to update the malware running on the infected host. This update request allows the author to perform two tasks—Update the malware or update the time interval between update requests. It uses the same technique discussed in my previous blog post where I detailed version 4.0. In fact, this technique is seen in every version between 2.1 and 4.0. As a recap, the author sends a request with an ‘update’ or ‘download’ request, like the one shown below:

(The response seen below was created using a mock server I created in Ruby. It is not the actual attacker’s response).

The attacker, seeing this request, then has the option of responding with the following command:

ie:<update_interval>:<update_exe_location>

If the ‘update_exe_location’ parameter is specified, the malware will attempt to download this file, copies it to a random name in the %TEMP% directory, and executes with an argument instructing the malware to delete the original and replace it with the new one.

By allowing the author to update the malware, it also gives him or her the option of updating the exfiltration URLs, which are hardcoded inside of the binary itself. This update function can in theory also be used as a download/execute component, which can be used to install other malware onto the system.

v5.x

As we noticed with the exfiltration in version 5.x, we see a complete revamp of the network traffic. This is equally true with regard to Alina’s C&C. As you may recall from the Exfiltration section, Alina uses byte offsets 18 through 35 as a XOR key. You may also recall that Alina uses offsets 27 through 35 as a command. The following commands have been identified:card

cards
update
diag

Additionally, the following server responses have been identified, along with their description:

updateinterval=<integer>: Change interval between update requests
cardinterval=<integer> : Change interval between card exfiltration
log=1                   : Enable logging (not verified)
log=0                   : Disable logging (not verified)
update=<url>|           : Update malware
dlex=<url>|             : Download/Execute file
chk=?                   : Unknown

It’s interesting to see the addition of an actual download/execute operation in version 5.x, as I speculated earlier about how the update command could be used for that same thing. All of the commands above are sent across the wire after being XORed with the XOR key used in the original request, which again helps to deter simple inspection of the traffic.

Conclusion

I realize I’ve only touched the surface with Alina, as I still haven’t even talked about its installation process, techniques for grabbing track data, packers/crypters in use, etc, but I promise I’ll do my best to address those details in part 2 of this blog post. Over the course of 3-4 months, we’ve been able to see the Alina authors continually update and improve upon their malware. It is likely we will continue to see this trend continue in the future, making it increasingly difficult to analyze over the wire or on disk. I’ve included the exfiltration URLs for all of the samples I was able to obtain in the wild (not in active cases), and also included the hashes for all of the samples in the appendix. Thanks for reading!

Appendix

Exfiltration URLs

hxxp://84.22.106.87/asdwer/1.php
hxxp://204.188.242.201/ocz2/up.php
hxxp://204.188.242.201/dada123/up.php
hxxp://204.188.242.201/brand_new/up.php
hxxp://204.188.242.201/sucky/upload.php
hxxp://204.188.242.201/forum/login.php
hxxp://193.169.87.147/e107/login.php
hxxp://208.98.63.228/wp-admin/abc.php
hxxp://208.98.63.226/goose/push.php
hxxp://fastbussineslife.net/path/up.php
hxxp://host3.com/path/up.php
hxxp://jikobins.com/forum/login.php
hxxp://zwaonoiy.com/wordpress/sam.php
hxxp://jikobins.com/sucky/upload.php
hxxp://ioconzus.com/sucky/upload.php

Hashes (MD5 Format)

1efeb85c8ec2c07dc0517ccca7e8d743
37493eb319d126d0ab8f5a55da85563d
c9e5752eea81f7d3521b1d2232afd3b8
a418410fa8b2617f3109dc289fa151c5
71fbca87e863db0aca080b4f87cc36f2
d31eb6e7f39dde0c2015dc2804c84a85
5d333312e3dd0fb7b5823696e99000e9
2139e613dc20df19daa6d90a0ff05591
0de9765c9c40c2c2f372bf92e0ce7b68
7cf5a421c3403441d84a0e34f81c3f0c
1efeb85c8ec2c07dc0517ccca7e8d743
e7e13912af192abe2f6ec90f6d429c6c
6686eed5875f622f5ed21397acb41d86
a3ce818621074333723b07a5a5c22e5b
8cdb63b3bfe16c0517e96b316eda3514
99a307128daa407147d1c69d2824d703
0ec4fada5b72e60756bcecec62fd6901
7bef391ddb8f0058823b7aaa96b1ba43
04474d2723d328ce28029c050ec6c0bb
108785e2f5de11df0da4138b8dd819df

TrustKeeper Scan Engine Update - May 15, 2013

2013-05-15T16:30:14-05:00

The latest update to the TrustKeeper Scan Engine is now available. It adds coverage for more than two dozen vulnerabilities, including several recent Ruby on Rails vulnerabilities. It also greatly expands our vulnerability coverage for Moodle CMS, with 20 new vulnerability tests. Additionally, with official support from Microsoft for Windows XP ending in less than a year, we have added an informational notice for detected Windows XP systems, reminding customers that support (and security fixes) will be ending soon.

New Vulnerability Test Highlights

Some of the more interesting vulnerability tests we added recently are as follows:

Microsoft
* Microsoft Windows XP End of Life

Ruby on Rails
* Ruby on Rails attr_protected Method Bypass in Active Record (CVE-2013-0276)
* Ruby on Rails limit Function SQL Injection Vulnerability (CVE-2011-0448)
* Ruby on Rails Nested Attributes Remote Arbitrary Record Modification (CVE-2010-3933)
* Ruby on Rails Serialized Attributes Denial of Service in Active Record (CVE-2013-0277)

All Trustwave customers using the TrustKeeper Scan Engine receive the updates automatically as soon as an update is available. No action is required.

The White "X"

2013-05-15T08:05:58-05:00

Over the many years I’ve spent training various local, state, federal and law enforcement organizations on forensics methodologies, one story always sticks out in my mind as I prepare for courses. As I get organized for the upcoming Computer Forensics & Incident Response for Investigators course on July 27^th – 30^that BlackHat USA in Las Vegas or hear about another breach in the news, I’m reminded of the following story once again.

A certain engineer retired from his job of 37 years at a very productive factory of a very well-known company. Prior to his departure, he trained three young college graduates with engineering degrees on the ins-and-outs of the factory. Because the retiring engineer did not have a college degree his replacements quickly discounted his admonitions as the ramblings of an "old man".

About one week later, the retired engineer's phone rings and at the other end is the plant manager. A problem with a machine on the production floor had ground the factory to a halt. For several days prior the three young replacements had tried to resolve the issue but didn’t make any progress. The plant manager pleaded with the engineer to come back as a consultant and help identify and correct the problem. The engineer gladly agreed.

An hour after that phone call, the old engineer arrived at the factory with nothing but a piece of chalk in his hand. Staff quickly escorted him to the production floor. His young replacements glared at him, certain that he would not be able to help and involving him was an obvious waste of time.

The engineer puts on the safety glasses that hung around his neck for almost 20 years and walked around inspecting equipment. He tapped on a machine here and there, examined a few gauges and finally focuses on one piece of machinery in particular. He turns his head to the right to get a close look and then to the left. He pulls up his safety glasses, squints as if to focus on something very small and quickly sets the glasses back on his nose. He then takes the chalk and marks a piece of equipment with a white "X.”

"Replace this" he said, "and you will be back up and running."

Immediately his young replacements protested, indicating incredulously that they had already checked that piece and determined it was definitely not the problem. They had used the latest diagnostic tools to perform system checks on that part and the tools said the device was functioning properly. The plant manager, looked at them and affirmed the old engineer's diagnosis—the component marked with the "X" had to be replaced.

After a few hours the part is replaced, and the system is powered back up. The factory springs back to life and production is back to normal! Crisis averted.

A few days later the old engineer's phone rang. And again it was the plant manager this time flabbergasted at the bill he received for $50,000 with a single line item of, "consulting fees.” The manager states that the invoice is unacceptable and that for that kind of money, he needs a line-by-line breakdown of what cost so much money for less than four hours of work!

The old engineer agrees to the manager’s wishes, and sends him the following invoice.

1. $1—box of chalk

2. $49,999—knowing where to put the "X"

For some unknown reason, many forensic investigators think tools solve cases. During my tenure in this field, I have frequently heard statements like, "I wish I had a tool that did this!", or "If only there was a tool that did that!". Likewise, there is a fever pitch whenever a new forensic tool is released; a sense of wonderment and the ever lingering question, "Will this be THE tool to change everything?".

Since 2009, many of us in the forensic community have spoken, blogged, tweeted and presented at conferences about shifting focus away from tools and onto methodology. We have gained some traction, but we still encounter heavy opposition from many practitioners who want to hold on to the "old ways" and their heavy reliance on tools. This would be fine if we were dealing with 20-year-old technology in strictly post mortem cases, and only being asked to perform simple tasks such as finding CP or comparing file time stamps. I cannot speak for what your cases look like, but ours at Trustwave...yeah...they’re a bit more complicated.

We go after answers, not data. We use a sound, repeatable, consistent methodology that has been proven in more than 1,500 cases (450 last year alone). It has withstood the scrutiny of both criminal and civil litigation and has helped Law Enforcement at all levels put bad guys in jail. It just flat-out works.

As technology marches ever forward, computer forensics and incident response gets more complicated, not less. Operating systems change, networks expand and data storage increases exponentially. Add mobile devices and cloud computing to the mix and there are suddenly so many places for trace evidence to reside that the old, "shotgun" style of forensics is no longer plausible. There has to be a shift in thinking, or responders and investigators will quickly become as obsolete as 3.5-inch floppy disks.

So what's the answer? In the vignette described above, the old engineer used his knowledge of and experience with how the machinery worked to place the white "X" on the correct system. He didn't rely on a tool to make that decision for him. Instead he used the most effective tool he had in his toolbox—his mind! His years of experience and expert eyes allowed him to know what "normal" looked like and fueled his remarkable ability to spot the abnormality no matter how seemingly insignificant to anyone else.

By leveraging our existing knowledge of how crimes are committed and why criminals commit them with our understanding of computing fundamentals, we can formulate a clear and concise path upon which to base investigations. This knowledge, coupled with a proven and repeatable methodology, can take you from being an average investigator to being an exceptional one.

I hope you will join me and learn exactly that philosophy at the Computer Forensics & Incident Response for Investigators course in Las Vegas, NV during the BlackHat USA Training sessions. You’ll engage in hands on labs and instructor-led demos in a “real world” environment. There are a lot of bad guys out there, and as with the story about the “White X” experience in the “real world” is often the best place to understand their modus operandi.

Click here for more details and to sign up today.

Analysis of Malicious Document Files Spammed by Cutwail

2013-05-15T08:04:05-05:00

In our Global Security Report, we highlighted a zero day vulnerability in the Windows Common Controls affecting Microsoft Office (CVE-2012-0158). This was reportedly being used for targeted attacked against NGOs and human rights activist.

Over the past week, the Cutwail botnet has been sending out spam containing malicious documents of the aforementioned vulnerability, CVE-2012-0158. The use of a loaded RTF attachment is a departure from normal for Cutwail, usually it distributes executable attachments or links to exploit kits.

The spam claims to be from Citibank or Bank of America. The spam may use the “Merchant Statement” as a subject line and has an accompanying .DOC file attached.

Spam Campaign Samples

The .DOC attachment is actually an RTF file format which was crafted to exploit an error in the ActiveX controls found in MSCOMCTL.OCX (Windows Common Controls). The vulnerability is also known as "MSCOMCTL.OCX RCE Vulnerability".

The Malicious RTF File Header

This exploit affects older versions of Microsoft Office such as Office 2003 SP3, 2007 SP2 and SP3, and 2010 Gold and SP1 etc. This issue was patched a year ago and was included in the Microsoft Security Bulletin MS12-027.

The Shellcode and the Payload

To verify if the RTF file was indeed malicious, we initially scanned the file using a tool from OfficeMalScanner suite, RTFScan.exe. This provided an overview of the malicious RTF file. The tool also dumped the embedded suspicious OLE document found in the RTF file. RTFScanner found a seemingly malicious object inside the file; and VirusTotal’s high detection rate gave us high confidence that we were indeed dealing with a malicious RTF document.

RTFScan Result

The suspicious embedded OLE object that RTFScan detected.

One of the objectives of this analysis is to find the shellcode that will be executed when the exploit is triggered. Luckily, the shellcode string can be easily spotted within the malicious RTF document, characterized by the string “E9” (an opcode for relative JMP) and a series of 90s (NOP instructions). So by dumping the shellcode strings and converting to binary, we can disassemble and analyze it easily.

The disassembled shellcode

The dissassembled shellcode shows the initial scanning of the Process Environment Block (PEB) to resolve the Kernel32.dll address space and after that is the manual retrieval of Imported API (Application Program Interface) through hashing. This common shellcode technique is used to resolve the addresses of API functions it needs to execute when running in a Windows system.

Here's the list of hashes and its corresponding APIs that the shellcode use:

0xBBAFDF85 GetProcAddress
0xAC0A138E GetFileSize
0x9424D45A GlobalAlloc
0xDBACBE43 SetFilePointer
0x130F36B2 ReadFile
0x94E43293 CreateFileA
0x837DE239 GetTempPathA
0x741F8DC4 WriteFile
0xFF0D6657 CloseHandle
0x01A22F51 WinExec
0xB4FFAFED GetModuleFileNameA
0x4FD18963 ExitProcess

Given that list of APIs, it gives an idea of what the shellcode is going to do.

With further investigation, we saw the shellcode decrypt a Trojan executable file embedded in the malicious RTF document using a simple XOR operation. The file will then be dropped and installed in the user %TEMP% directory with the filename PAW.EXE.

The Trojan is encrypted and embedded in RTF document XORed using the key 0x3F.

The payload is embedded and XOR encrypted in the RTF document

Additionally, the code also drops another Word document file in the Temp directory with the filename VC.DOC. The dropped decoy document file is non-malicious and opened after the shellcode has installed the Trojan.

The installed Trojan is no other than the Zeus Trojan. An analysis of this well-known Trojan can be further read in our previous blog.

Conclusion

To sum up, once an unsuspecting victim is lured to open the malicious RTF document, the exploit will trigger the vulnerability in Microsoft Word, causing it to run the embedded shell code. The shell code eventually drops and installs its payload.

It is worth noting though, that even after a year the patch for this Microsoft Office vulnerability was released, cyber-criminals continue to use this exploit. It is always a good advice to keep all your software up to date and avoid opening unsolicited email.

Trustwave MailMarshal and Mailmax customer are protected from this threat.

TWSL2013-002: Multiple XSS Vulnerabilities in The Bug Genie

2013-05-14T15:38:13-05:00

Trustwave SpiderLabs has published a new security advisory for multiple Cross-Site Scripting (XSS) vulnerabilities in The Bug Genie, an open source issue tracking and project management PHP application. The findings include both reflective and persistent XSS vulnerabilities in input parameters that can be exploited via authenticated POST requests. The Bug Genie team was contacted earlier this year regarding the security issues, and made an attempt to address them in their 3.2.5 release. Due to incomplete fixes in the 3.2.5 version, affected users are advised to upgrade to the latest stable 3.2.6 release.

Our initial security advisory was published for affected versions 3.2.4 and prior. However, a couple of weeks after the fixes were released in version 3.2.5, I revisited the application in order to confirm the fixes. I found that only two out of the five findings were correctly addressed. As a result, the remaining three findings in the 3.2.5 version were still vulnerable to XSS. Multiple attempts to contact The Bug Genie team regarding the following incomplete fixes were made:

Persistent XSS via POST request on 'description' parameter in issue reporting
Persistent XSS via POST request in file attachments
Reflective XSS via POST request on 'openid_identifier' parameter in login during preauth

Both the ‘description’ and ‘openid_identifier’ parameters fail to sanitize user input properly. Although the 3.2.5 version of The Bug Genie applied a fix in different locations for both vulnerabilities, they failed to eliminate the issue entirely in other parts of the web application.

For example, the patch that was applied to fix the ‘openid_identifier’ issue sanitizes the error message “Could not validate against the OpenID provider: %message%.“ However, I found that the XSS vulnerability exists in a different location where the 'openid_identifier' parameter's value can be set to arbitrary JavaScript and cause the application to throw the error exception “Could not connect to $url,” where $url is not sanitized. As such, the output would be “Could not connect to http://<script>prompt(1)</script>”, resulting in XSS.

Therefore, I developed two patches that addressed both issues. As of this post, the supplied patches that I submitted to The Bug Genie team to help address the incomplete fixes for both vulnerabilities have been merged into their codebase. Affected users who previously upgraded to version 3.2.5 should now upgrade to the latest 3.2.6 release, which contains both of my fixes.

Here are the changes that I provided:

Download: Fix openid_identifier XSS Vulnerability

Download: Fix timeline Issues XSS Vulnerability

As a final note, the persistent XSS vulnerability that exists in the way that the application renders its content remains unfixed in the latest 3.2.6 version as well. However, the file uploading functionality in The Bug Genie is disabled by default.

Additionally, cross-site scripting vulnerabilities, such as those reported in The Bug Genie, can be mitigated by using a web application firewall (WAF), such as ModSecurity and WebDefend.

For additional details regarding this security advisory, please visit: Security Advisory TWSL2013-002

Microsoft Patch Tuesday, May 2013

2013-05-14T12:54:23-05:00

I keep hoping for an easy relaxing Patch Tuesday of say, only two or three bulletins but so far this year things haven’t been so easy. So far this year we have Patch Tuesdays of seven, ten and seven bulletins, respectfully, and this month we have ten. (hmm, is there a pattern there?) Not only that we have a zero-day vulnerability in Internet Explorer to deal with. I long for months like September 2012 when there were but two bulletins but I should feel lucky that its not December 2010 or April 2011 when we had no less than seventeen bulletins. I’ll take the ten and be happy.

This month there are only two critical patches, both covering remote code execution, both in Internet Explorer. The rest are all rated as Important and can be found in Windows, Lync, Publisher and Word. Bulletin Nine is in Windows Essentials, which is a product we haven’t seen much of here on Patch Tuesday.

MS13-037 (KB2829530)

CRITICAL

Remote Code Execution in Internet Explorer

CVE-2013-0811 CVE-2013-1297 CVE-2013-1306 CVE-2013-1307 CVE-2013-1308
CVE-2013-1309 CVE-2013-1310 CVE-2013-1311 CVE-2013-1312 CVE-2013-1313
CVE-2013-2551

Yup, that’s eleven CVE’s fixed in one bulletin. Nine of those are use-after-free vulnerabilities, which seem to be getting more and more popular lately. A use-after-free vulnerability happens when a program references memory that it has already freed up, this can unexpected behavior and in these cases results in a security issue. The tenth is an information disclosure issue in the JSON array. JSON allows web apps to access data on database servers and is often used in place of XML. It is likely that many of these were discovered or at least became known during the PWN2OWN competition at the CanSecWest conference earlier this year. Of the ten CVEs Microsoft thinks that three of them should expect exploit to be written fairly quickly.

MS13-038 (KB2847204)

CRITICAL

Remote Code Execution in Internet Explorer

CVE-2013-1347

This is the zero-day that you have heard so much about. It only impacts Internet Explorer 8 and it is already being actively exploited. This is another use-after-free vulnerability that results in Remote Code Execution. Microsoft previously released a Fix It for this issue, however even if you have already applied the Fix It you should install this patch.

MS13-039 (KB2829254)

IMPORTANT

Denial of Service in HTTP.sys

CVE-2013-1305

HTTP.sys is a kernel mode driver that handles HTTP Internet traffic allowing multiple applications to pass traffic over the same port. However if an attacker sends a specially crafted HTTP packet to a Windows 2012 Server they could trigger an infinite loop in the HTTP protocol stack and cause a denial of service.

MS13-040 (KB2836440)

IMPORTANT

Authentication Bypass in .NET Framework

CVE-2013-1336 CVE-2013-1337

This bulletin patches two CVE’s, the first is a spoofing vulnerability in the .NET framework. If a .NET application receives a specially crafted XML file an attacker could modify the contents of an XML file without invalidating the file's signature. The second deals with how .NET creates policy requirements for authentication when setting up endpoint authentication, which could allow a successful attack to copy information.

MS13-041 (KB2834695)

IMPORTANT

Remote Code Execution Lync

CVE-2013-1302

Lync, no, not Link, our intrepid hero from Legend of Zelda but Lync, Microsoft’s instant messaging platform formally known as Microsoft Office Communicator contains a vulnerability that could allow an attacker to gain the same user rights as the logged-on user which would include remote code execution. Of course attacker would have to convince a user to view or share a specially crafted file, disguised as a presentation. However considering how willingly most people blindly click on random links this probably wouldn’t be too hard to do. Thankfully developing the exploit code to take advantage of this flaw appears, to Microsoft at least, to be somewhat difficult.

MS13-042 (KB2830397)

IMPORTANT

Remote Code Execution in Microsoft Publisher

CVE-2013-1316 CVE-2013-1317 CVE-2013-1318 CVE-2013-1319 CVE-2013-1320
CVE-2013-1321 CVE-2013-1322 CVE-2013-1323 CVE-2013-1327 CVE-2013-1328
CVE-2013-1329

This is the second bulletin this month with eleven CVEs. Some of these are Buffer Overflows; others deal with Signed Integers, Pointer Handling, or Negative value Allocations. They all require a specially crafted Publisher file. You may be offered this update even if you don’t have Publisher installed as the parts that are affected are also installed with any part of the Microsoft office Suite.

MS13-043 (KB2830399)

IMPORTANT

Remote Code Execution in Microsoft Word

CVE-2013-1335

One interesting thing to note here is that only Microsoft Word 2003 SP3 and Microsoft Word Viewer are listed as being impacted. The issue revolves around the way that Word parses content of some files. If you have configured Outlook to use Microsoft Word 2003 SP3 as an email reader you should pay close attention to this one. Using Word to read email in Outlook is not the default so you probably know if changed your system to do this. If you did then an attacker could send you a specially crafted RTF email message to exploit this vulnerability. Just like you shouldn’t take candy from a stranger in this case don’t open Word files from unknown sources.

MS13-044 (KB2834692)

IMPORTANT

Information Disclosure in Visio

CVE-2013-1301

Unlike MS13-043 that only impacted one version MS13-044 impacts Visio 2003, 2007 and 2010. Again a specially crafted Visio file could allow an attacker to gain information about a system, information that could be used in a different attack. Like MS13-042 you may be offered this update even if you don’t have Visio installed as the affected components are also installed with the Microsoft Office Suite. The issue here is with LibXML2 which is not only used by Visio but a host of other products including Trustwave's own open source ModSecurity. We wrote about this vulnerabilty back in April. If your product also uses LibXML2 you might want to check that you are not vulnerable to this issue as well.

MS13-045 (KB2813707)

IMPORTANT

Information Disclosure in Windows Essentials

CVE-2013-0096

Don’t get confused between Windows Essentials and Windows Security Essentials. Windows Essentials contains free software shipped with Windows like Photo Gallery, Movie Maker, Mail and others. One of those others is Writer, which if opened via a specially crafted URL, could allow an attacker to override Windows Writer proxy settings and overwrite files accessible to the user on that system. Also note that if you have the older Windows Essentials 2011 you will need to upgrade to Windows Essentials 2012 before you can apply this update. If for some reason you can’t upgrade to 2012 you will want to disable the Windows Writer handler, search for Microsoft KB article 2813707 for the automated Fix It solution to disable this handler.

MS13-046 (KB2840221)

IMPORTANT

Elevation of Privilege in Kernel-Mode Drivers

CVE-2013-1332 CVE-2013-1333 CVE-2013-1334

To exploit this one an attacker must already be able to log into the system, then they need a specially crafted application that would result in increased privileges for the user. The issue lies in the Microsoft DirectX graphics kernel subsystem (dxgkrnl.sys), which improperly handles objects in memory. Note that you may be offered more than one update to fix this; you will need to install all of the updates to protect yourself from these vulnerabilities.

Securing Continuous Integration Services

2013-05-13T10:20:08-05:00

Summary

Over the last couple weeks, I’ve had the distinct privilege to share some of my research surrounding continuous integration security. The presentation was dubbed “Attacking Cloud Services w/ Source Code” and was presented at both SOURCE Boston 2013 and THOTCON 0x4, where I discussed a bunch of fun things like:

Why I love Continuous Integration (CI) Services (especially hosted solutions)
My perspectives as an open-source developer (some happy, some sad)
What things could be possible if malicious code was fed to CI services
A project I’m working on, called RottenApple, to help make things better

In this blog post I hope to capture some of the meat of the presentation for those who could not attend and use this opportunity to announce the first public release of RottenApple.

Basic Terminology

I guess the first big question (maybe for some) is what is continuous integration?

Continuous integration (to me) is a system or process that monitors source code repositories for changes. If a change is detected (aka: a developer commits new code) the project is checked out built and tested to ensure that the software project still works.

Unit-tests (or "specs") are often used by continuous integration services to verify that everything still works in a software project. If something breaks, a unit-test will ideally fail and the continuous integration system will bubble that failure back up to a developer so that the problem can be addressed as soon as possible while the changes are fresh.

So, in short, developers use continuous integration to regularly checkout, build and run unit-tests on software projects for quality control. Continuous integration is the entity performing the inspection and Unit-tests are what validate that each and every piece of software project works as expected.

Why I love Continuous Integration

Let me start by saying I haven’t always loved continuous integration. In fact, at one point it was sort of a PITA. When initially joining a group of Spiders that did a lot of development, I used to cringe at the idea of making a change that would cause the build to fail. In the famous words of one of my co-workers, “this makes you a bad person”.

Anyways, beyond work stuff and fast-forwarding a bit, I was doing a little bit of open-source development stuff for fun and once I grew to appreciate the value of having continuous integration for my projects at work, I really wanted to apply the same techniques to introduce more quality control in my open-source “hobby” projects.

One of the challenging parts of doing development for fun is that you usually don’t have the same resources as you would if you were developing a commercial project. This means you usually have a budget of $0 and you’re usually finding time to commit code between lunch breaks, while on the train or while pretending to watch TV. Even though I knew continuous integration would be good for my projects, I didn't have the drive or the additional time to invest on it because it would mean less time writing code (what I really want to be doing).

Travis-CI to the Rescue

Thankfully, after a little while, someone introduced me to a service by the name of Travis-CI. Travis-CI is a hosted continuous integration service for the open-source community. It’s really easy to set up, mimics some of the stuff I have for my work projects and it’s FREE. Now, there are other providers like this out there, but I have the most experience with Travis-CI, so I reference Travis primarily throughout.

In addition to being easy to setup and free, Travis-CI allows me to test my Ruby projects using a variety of different versions including 2.0, 1.9.3, jruby, rbx, ree, etc. It also allows me to have a full build history for each change made to the project and the icing on the cake for me was that it would also build any submitted pull request and let me know if the proposed changes would break the project or not before I merge them into master.

A Healthy Dose of Inspiration

Around the same time that I was discovering all this fancy hosted-CI goodness like it was Christmas morning, I was also trolling the Aloha Ruby Conference videos and came across a video of a presentation called “Hacking with Gems” by Ben Smith. The basic gist behind Ben’s talk was describing some of evil things you could do inside a Ruby gem and what sorts of things he tried to social engineer people, both actively and passively, to install his not so savory gems.

One of the most interesting components of Ben’s presentation was that he had a number of business cards made that simply stated “gem install aloha-ruby-conf” and placed them all around the conference. It’s important to note that in this was a developer conference and it’s more than common place for people to install gems to try them out without really taking a close look at everything the gem does under the hood. During the presentation, after describing all the evil things that someone could do with a simple gem install process, Ben provided a list of developer names that had installed his benign gem just to drive the point home.

Ben’s talk really got me thinking and eventually I came to wonder whether all these things (or similar techniques) were possible without having to rely on tricking a user or highly obfuscate my code. This thought process led me back to continuous integration services.

Attacking Continuous Integration Services

When utilizing continuous integration services to build Ruby projects, it commonly boils down to executing a rake task either explicitly via “rake spec” or simply through running “rake” and having the default behavior to run the unit tests for a given project. However, one of the things I noticed here was that my unit-tests themselves, even though I’m using rspec, which has some specific syntax for defining unit-test stuff, are just plain old ruby. This got me to the idea, “what if I just added malicious code to my specs?”. The system would most certainly execute my code and I’d get malicious code running on the CI.

The first thing I decided to do before I got too far down the rabbit hole was to build my own CI server for testing purposes. I did this because I really enjoy having a GitHub account and I do (as I mentioned above) love having a free continuous integration service building all my projects and I didn’t want to spoil that. I didn’t want to piss anyone off and I didn’t want to feel bad when I did things that would be considered unethically hacking another organization. I ended up building my own CI setup with Jenkins-CI, which is a widely popular open-source CI server used by a large number of organizations for building commercial software.

The setup was very basic where by I would push code to a private GitHub repository and my CI server would poll that project for any changes. When I push malicious code up to my private GitHub repository, it would trigger a build on my CI server and then I would get that malicious code to execute on the CI. It’s an extremely simple setup (in dev circles), but the nature of the situation means that the development of “exploits” for these environments, if you even want to call them that, is very easy.

Here are a couple example offensive-biased things that I talked about in the presentation:

Breaking out of the build root (accessing neighboring project source code)
Performing a port scan of the CI’s locally attached network (potential for pivoting behind the firewall)
Authenticating back to GitHub using R-RW keys (potentially trojan the project)
Popping a Reverse Shell (getting command-line access to the CI)

Although, throughout this description of all the offensive things you can do with Ruby projects (all of my examples) there is nothing to say that you couldn’t do these same techniques with building/testing any other language such as PHP, Python, Java, etc. With such a fundamental level of trust here, the options are only limited by the trust-levels given to the CI to perform its activities.

Introducing RottenApple

After realizing that the nuances of CI security weren't going to be easily resolved for the masses (both hosted and self-hosted continuous integration services), I decided to start a project on GitHub called RottenApple with the hopes of at least moving us it into a better direction. The main idea behind RottenApple is that you build the project on your continuous integration environment and it will test it and let you know where there are weaknesses. Ironically enough, I’ve chosen to stick with a Unit-test concept where the roles are a bit reversed in that the unit-tests are actually testing the CI (not the code as they traditionally would).

After thinking long and hard about this tool, I decided to make it a bit more multi-purpose and implemented two separate, but related name-spaces in the RottenApple project; (1) RottenApple::Audit – for safely auditing a target CI environment and (2) RottenApple::Attack – for actively attacking a target CI environment. I’m hoping that by having these two polar opposites that this project will help meet the needs of Developers, System Administrators, CI Providers (both hosted and internal installments) as well as Security Practitioners.

Below includes the current feature set of the project by name-space designation:

RottenApple::Audit has the following checks:

Is the root user is being to build projects?
Can malicious code steal your RubyGems API key?
Could malicious code pivot to private networks?
Can malicous code authenticate using your GitHub creds?
Could malicious code receive instructions from a remote party or exfiltrate data from your CI?
Can malicious code access other projects being built on the same server?
Can malicious code steal SSH private keys?

RottenApple::Attack has the following features:

Steal the RubyGems API key
Flush IP Tables (aka: drop firewall rules)
Install Software to aid in the attack process
Make an unauthorized commit to master
Perform an NMAP scan of a desired set to targets
Throw/Shovel a reverse shell to get command-line access to the CI/CD
Steal SSH private keys

I just recently published the source code for this project on GitHub, which can be found here. I hope that people check it out and find it useful. Hopefully, with some good feedback and maybe a little help from the community I’ll be able to extend it to do more interesting things over time.

Parting Thoughts

Lastly, I just want to make myself as clear as possible that I don’t see the techniques that I’ve described above as “0-days”. Continuous Integration services are open by design for a number of reasons, including making sure that they don’t inhibit the ability for developers to quickly have their code tested and validated for regressions. However, it’s important to note that trust relationships do exist on these systems and can be abused if not carefully assessed.

I think we should do more to test continuous integration services for weaknesses to ensure the trust we have imparted them with is not abused. I’m hoping that you checkout the RottenApple project, find it useful and send me a pull request.

PS – Here is the deck from the presentation I referenced above. Also, the videos of the attack demos referenced in the presentation can be found here and here.

SpiderLabs Radio May 10, 2013 w/ Space Rogue

2013-05-10T15:59:19-05:00

This weeks episode of SpiderLabs Radio hosted by Space Rogue is brought to you by Trustwave's Threat Intelligence Service and covers IE 0-day hits Labour, Syrian Electronic Army hits E! Online and The Onion, Guccifer returns, $40 Million cyber heist, OpUSA becomes OpDud, BX1 extradited, name.com, John Dvorak. media sites hit, I'm a Slutty Moron, Evernote and China? and a lot more!

Listen to SpiderLabs radio in iTunes.

Or you can download the MP3 file directly here.

Or listen right from your browser with this embedded player.