Razorback Appliance - Getting Started

With the recent release of Razorback 0.4.1 we decided to update the Virtual Appliance image to this release.  The target audience for the appliance is people that want to test drive the system without going though the process of installing the system and its dependencies.

You can down load the appliance from SourceForge here: http://sfi.re/xTH1nH

The virtual appliance is based on FreeBSD 9.0 (i386) and requires 4GB of RAM on your host and 20-30GB of hard disk space.  We build the VM in VMWare ESXi, but it should run on any hypervisor that can import an Open Virtualization Format archive (OVA) virtual machine; in this guide I will be using VirtualBox.

The appliance ships with the following components:

• Razorback Dispatcher
• Razorback Master Nugget
• Archive Inflate Nugget
• ClamAV Nugget
• File Log Nugget (disabled by default, test/sample nugget)
• Flash Inspector Nugget
• OfficeCat Nugget - More info: http://sfi.re/yYHpRs
• PDF Dissector Nugget (disabled by default requires aditional installation steps)
• PDF Fox (disabled by default, beta release)
• Script Nugget
• Syslog Output Nugget
• Virus Total Nugget (disabled by default, requires API key).
• Yara Nugget - More info: http://sfi.re/zkPxcl 
• Razorback Web Interface
• File Inject
• File System Walk
• Snort 2.9.1.1 with Razorback Collection
• Systems Management Web Interface (Based on FreeNAS interface)
• MySQL Server
• Memcached Server
• ActiveMQ Server

Importing the appliance

Select the following menu option based on your hypervisor:

• VMWare Workstation - File->Open
• VMWare vCenter (ESXi) - File->Deploy OVF Template
• VirtualBox - File->Import Appliance

Select the OVA file that you have downloaded and follow the prompts to deploy the machine; if you are asked if you would like to reset the VM's network cards' MAC addresses at any point you should select yes (or tick the box in the case of VirtualBox).

After you have installed the appliance you can start it up and you should be presented with a screen like this:

If you see a bunch of output related to masterNugget or dispatcher then you may just hit return and the menu should present its self.

Now we need to set up a username and password to access the system, open your browser and enter the address for the management web interface (in this case http://10.7.1.56:8080). You should be presented with the following screen:

Now click the large account button in the top right, and select change password from the tabs in the window that opens:

Enter your new password  and confirmation leaving old password blank. Make sure that "Change root password as well" is selected and click the "Change Admin Password" button.  Now the Alert button in the top right should be solid green rather than flashing red.

Next we need to configure the network interface of the VM. Expand the network item in the tree on the left, and then the Interfaces sub item and select "Add Interface":

Configure the interface to fit your environment (I'm using DHCP in the example) and click ok. If you are moving to a static IP configuration you will need to go the the "Global Configuration" item under network and set your default gateway and name servers.

Now we need to add a user to the system to allow access to the Razorback web interface, to do this expand the Account item in the tree on the left, and then the Users item and select "Add User":

In this example we are adding a user that can only access the web interface so we select the following options:

• Primary Group - nogroup
• Home Directory - /nonexistent
• Shell - nologin

Now you should reboot the appliance to make sure that the network configuration changes took. Select "Reboot" from the menu.

Once the machine has rebooted you should be able to log into the razorback web interface by browsing to the URL listed on the boot menu (in this case, http://10.7.1.56/).

You should be presented with a screen like so:

Changing active inspection nuggets:

Log into the system web interface with the admin user (whose password we set earlier). Expand the Razorback element in the tree and select "Control Nuggets".

To change the configuration items for a nugget click the spanner icon next to the on/off switch.

To turn a nugget on or off just click on the on/off button, your changes should be reflected on the razorback interface under nugget status.

Enabling Snort for traffic capture:

To do this we need to add a capture interface to the appliance, making sure that you enable promiscuous mode for the interface.

You will need to make the following changes based on your hypervisor:

• VMWare ESXi - Change the configuration of the vSwitch and the port to allow promiscuous mode for the interface.
• VMWare Workstation - Follow this guide to enable promiscuous for a guest: http://sfi.re/whE6dR
• VirtualBox - Select "Allow All" under Advanced->Promiscuous Mode as shown above.

After you have added the interface, start the virtual machine and log into the admin interface.  Expand the Services item in the navigation tree and select "Control Services", then click on the on/off switch next to Snort to enable the service:

The appliance also supports inline traffic capture, follow these steps to enable it:

1. Add a third interface to the appliance connected to your second virtual network.
2. Select shell from the system console.
3. Editing /etc/rc.conf:
1. Comment out the lines starting ifconfig_em1 and snort_interface under the heading "TAP/Span interface on em1".
2. Un-comment the lines under "Inline configuration em1+em2".
4. Reboot the appliance.

More information about the appliance can be found here: http://sfi.re/ws6diq 

A FABULOUS policy rule

Lots of people in the security space are familiar with the blog of Brain Krebs, a former Washington Post network security writer and one of a tiny number of IT security journalists who actually gets it. If you're not following him on Twitter (@briankrebs), you should be.

Especially after today's awesome tweet:

"Don't look now (seriously, don't unless you're ninja) but Twilight author Stephanie Meyer's site appears 2b serving up Crimepack Exploit kit"

I was just lucky enough to notice this tweet within moments of it being sent out. As someone who hates sparkly vampires, I immediately went out and did a wget of the site in question, and pulled down an awesome PCAP. Besides having bad 90s-era HTML, the site was indeed infected with a bad case of the Crimepack Exploit Kit, as Mr. Krebs had noted.

While the VRT is busy adding more exploit kit rules - and please, if you have good intel on any of them, email us at research <at> sourcefire <dot> com - I figured I'd run it through the rule set to see if we had it covered. We did - SID 21039, which looks for a common form of JavaScript obfuscation, took care of matters. We'll be following up with a more detailed analysis of the exploit kit itself, to see if we can add more aggressive rules that even the most conservative CSO types feel comfortable running.

In the meantime, pay attention as you're browsing the Internet - you never know what sort of evil awaits you, even in the lamest of its corners.

ClamAV vs. Content IQ Test, part 1

This is the first in a series of blog posts about the Content IQ Test.

A few days ago, we came across a test whose purpose is to gauge a security system's ability to detect client-side attacks. The Content IQ Test consists of detecting a set of test files that contain, at various levels of depth within the file, the string:

The rules of the test are simple: "The objective is to create a single content rule that fires on all of the Test Files but not on any of the Negative Control files. [...]Triggering on the test files' [...] filenames or MD5 hashes and stuff like that is cheating and it doesn't count. "

Let's see how ClamAV does at this.

These files are all benign, so I encourage you to download and check out how these files are crafted.

Test File 1 is a plain text file containing the target string surrounded by some filler text. I crafted an ndb-style signature to target the eval+unescape string. Moreover, the signature below targets normalized ASCII text files:

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c28756e6573636170652827253635253736253639253663253238253239272929

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_1_Plain_Text_File.txt 
Test_File_1_Plain_Text_File.txt: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 1.00:1)
Time: 0.008 sec (0 m 0 s)

azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_1_Negative_Control.txt 
Test_File_1_Negative_Control.txt: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.01 MB
Data read: 0.00 MB (ratio 2.00:1)
Time: 0.010 sec (0 m 0 s)

OK, we are detecting the control file and are not detecting the negative control file. Let's proceed!

Test file 2 contains the control text pasted into the body of a Microsoft Word 2011 document.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c28756e6573636170652827253635253736253639253663253238253239272929

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_2_Microsoft_Word_2011.docx
Test_File_2_Microsoft_Word_2011.docx: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.01 MB
Data read: 0.17 MB (ratio 0.05:1)
Time: 0.011 sec (0 m 0 s)

azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_2_Negative_Control.docx 
Test_File_2_Negative_Control.docx: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.59 MB
Data read: 0.17 MB (ratio 3.41:1)
Time: 0.028 sec (0 m 0 s)

It makes sense that ClamAV would alert on such a file with a signature targeting normalized ASCII text files. That's because Office Open XML is a compressed (zip), XML-based file format (docx, xlsx, pptx, etc...). ClamAV treats the file as a zip archive and extracts its contents. It's then able to "see":



Test file 3 contains the control text pasted into the body of a Microsoft Excel 2011 document.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c28756e6573636170652827253635253736253639253663253238253239272929

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_3_Microsoft_Excel_2011.xlsx 
Test_File_3_Microsoft_Excel_2011.xlsx: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.04 MB (ratio 0.10:1)
Time: 0.010 sec (0 m 0 s)

azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_3_Negative_Control.xlsx 
Test_File_3_Negative_Control.xlsx: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.09 MB
Data read: 0.04 MB (ratio 2.20:1)
Time: 0.016 sec (0 m 0 s)

Test file 4 contains the control text pasted into the body of a Microsoft PowerPoint 2011 document.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c28756e6573636170652827253635253736253639253663253238253239272929
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_4_Microsoft_PowerPoint_2011.pptx 
Test_File_4_Microsoft_PowerPoint_2011.pptx: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.36 MB
Data read: 0.08 MB (ratio 4.65:1)
Time: 0.024 sec (0 m 0 s)

Using the signature in test.ndb, ClamAV failed to pick up the target string inside the pptx file. Using clamscan with the option --leave-temps, you'll notice that in the case of this PowerPoint file, ClamAV "sees":



Therefore, I modified the signature alerts if we see "eval" followed by "unescape" no farther than 200 bytes away, in turn followed by "('%65%76%69%6c%28%29'))" no farther than 200 away from "unescape".

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}2827253635253736253639253663253238253239272929
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_4_Microsoft_PowerPoint_2011.pptx 
Test_File_4_Microsoft_PowerPoint_2011.pptx: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.08 MB
Data read: 0.08 MB (ratio 1.05:1)
Time: 0.013 sec (0 m 0 s)

azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_4_Negative_Control.pptx 
Test_File_4_Negative_Control.pptx: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.36 MB
Data read: 0.08 MB (ratio 4.65:1)
Time: 0.025 sec (0 m 0 s)

Test file 5 contains the control text pasted into the body of a PDF document.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}282725363525373625363925366325323825323927

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_5_Control_Text_in_Body_of_PDF_File.pdf 
Test_File_5_Control_Text_in_Body_of_PDF_File.pdf: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.02 MB (ratio 0.25:1)
Time: 0.009 sec (0 m 0 s)


azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_5_Negative_Control.pdf 
Test_File_5_Negative_Control.pdf: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.04 MB
Data read: 0.02 MB (ratio 2.75:1)
Time: 0.012 sec (0 m 0 s)

ClamAV generates an alert because it's able to parse some PDF objects. In this particular case, it's able to "see":



Test file 6 contains the control file embedded into a PDF document. In a similar way to how Test file 5 was handled, we have:

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}282725363525373625363925366325323825323927

azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_6_Control_File_Attached_to_PDF_File.pdf 
Test_File_6_Control_File_Attached_to_PDF_File.pdf: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.02 MB (ratio 0.25:1)
Time: 0.012 sec (0 m 0 s)


azidouemba@ubuntu:~/Downloads$ clamscan -r -d test.ndb Test_File_6_Negative_Control.pdf 
Test_File_6_Negative_Control.pdf: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 1.67:1)
Time: 0.014 sec (0 m 0 s)

Test file 7 contains the control file compressed with Zip.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}282725363525373625363925366325323825323927
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_7_Control_File_Compressed_with_Zip.zip
Test_File_7_Control_File_Compressed_with_Zip.zip: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.011 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_7_Negative_Control.zip
Test_File_7_Negative_Control.zip: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.01 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 0.053 sec (0 m 0 s)

We see that a ZIP archive is treated as a container. Its contents are inflated and examined.

Test file 8 contains the control text pasted into the body of a Microsoft Word 2011 document. This Word document is compressed with Zip, then Tar, then RAR.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}282725363525373625363925366325323825323927
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_8_Word_File_Compressed_with_Zip_Tar_and_Rar.rar 
Test_File_8_Word_File_Compressed_with_Zip_Tar_and_Rar.rar: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.01 MB
Data read: 0.16 MB (ratio 0.05:1)
Time: 0.108 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_8_Negative_Control.rar 
Test_File_8_Negative_Control.rar: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.43 MB
Data read: 0.02 MB (ratio 18.17:1)
Time: 0.081 sec (0 m 0 s)

As with Test file 7, archive files are treated as the containers they are. Here, ClamAV recursively extracts the contents of the RAR, TAR and ZIP files.

Finally, Test file 9 contains the target string embedded in the metadata of an Excel 2011 file as a custom property.

azidouemba@ubuntu:~/Downloads$ cat test.ndb 
TestSig1:7:*:6576616c{-200}756e657363617065{-200}282725363525373625363925366325323825323927
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_9_Target_String_in_Custom_Properties_of_Excel_File.xlsx 
Test_File_9_Target_String_in_Custom_Properties_of_Excel_File.xlsx: TestSig1.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.03 MB
Data read: 0.03 MB (ratio 0.88:1)
Time: 0.045 sec (0 m 0 s)
azidouemba@ubuntu:~/Downloads$ clamscan -d test.ndb Test_File_9_Negative_Control.xlsx 
Test_File_9_Negative_Control.xlsx: OK

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.97.3
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.04 MB
Data read: 0.01 MB (ratio 3.33:1)
Time: 0.043 sec (0 m 0 s)

This is what ClamAV "sees":




Today we saw how ClamAV fared with the basic content test files. In the next post I'll take a look at the test files with auto-executing embedded active content.

An Exploit Kit Was Sent To You

Unless you've got the world's best spam filter, you've probably seen one of the latest spam techniques used by malware-dropping bad guys: what appears to be an automated email informing you that a multi-function scanner/copier was used to send you a document. It's a smart concept - using your office's big Xerox machine to scan and email in a single step is pretty commonplace these days - even if the execution is often poor. Take, for example, this sample that hit one of our team-wide accounts the other day:

=================================================================
A Document was sent to you using a XEROX CORPORACE FSX43949461.
SENT BY : Abdullah
IMAGES : 1
FORMAT (.JPEG) VIEW

DEVICE: PODA20971LD5PO13911L
=================================================================
A Document was sent to you using a XEROX CORPORACE FSX43949461.
SENT BY : Abdullah
IMAGES : 1
FORMAT (.JPEG) VIEW

DEVICE: PODA20971LD5PO13911L
=================================================================

Most people just delete bad phish like these; we here at the VRT, however, like to play with them. We'd been chasing down the links on this particular flavor of email for a while, but they'd been so transient that by the time we'd clicked the links, we got nothing but 404s or dead domains. In the case above, however, we were rewarded with a heavily obfuscated chunk of JavaScript:



The resulting ownage was classic. After briefly displaying a circa-1995-looking "Loading...Please Wait..." atop the page for a moment, the browser window went away, and the virtual machine's hard drive suddenly started cranking very heavily. Looking at the packet capture, the system immediately contacted a host in Russia, and started communicating over HTTP on port 8801; several files came down, including one named "yrkrktxzfniq.exe". A quick look at that file on VirusTotal showed that it was - surprise, surprise - malicious, and goes by the name of Worm.Cridex.

The exploit kit was easy enough to detect - SID 21108 does the job - given how blatant the obfuscation was. While we're busy working on more complex kits, such as Blackhole (see SIDs 21041 - 21045, 21141, and 21259), it's nice to be able to pick off less sneaky ones like this.

Agile Security

Up until this past year, I had never included any marketing materials in my slides.  It never seemed to fit in with a technical presentation, even though I always believed in the Sourcefire product line's ability to defend our customers in the face of a rapidly changing landscape.  Having open source solutions, backed by the VRT's ability to convert real-world intelligence into new detection, while still giving the customer the option to build their own custom detection is a powerful combination.  But now our company has come up with a corporate vision and marketing message that speaks directly to how successful organizations approach security and I am really impressed.

We call it "Agile Security" and it basically describes a security cycle that is critical to keeping network defense up-to-date in a changing threat environment. It recognizes that static defenses simply can't stand up to the realities of today's security environment and that the ability to monitor dynamic networks is just the first step in a successful security stance. It also is an excellent description of how the VRT approaches converting its streams of intelligence into protection for our customers.

The concepts of Agile Security are broken up into four essential elements. The first is "See", meaning that you can't protect yourself if you don't have a current understanding of what is is you're trying to defend. With the encroachment into the network by consumer electronics in the form of smart phones, tablets and laptops along with the rapid turn over of technology in today's corporate environment this can be difficult. Organizations can use active or passive techniques for tracking changes in network topology as well as new devices as they come online, but whatever the approach it is critical to know what you're defending right now.

The second element of Agile Security is "Learn", which focuses on gathering information about vulnerabilities, exploits and malware that threaten your environment. This is where you leverage your understanding of your network to map known threats to vulnerable targets within your network. For example, Android malware is an evolving threat. Do your users use their smart phone and integrate into your network making this malware a threat to your network? This is also where you cycle information you gain by incident response teams into your cycle for evaluation by your security development teams. Have you found a new malware on your network? How did it get there? What is it trying to do? Where did your defenses fail? This information leads to the next phase of Agile Security, "Adapt".

"Adapt" is the phase where you convert your intelligence into an actionable defense. In some cases this is automatic, such as when the VRT releases a new rule or when the FireAMP system seamlessly adds detection to their cloud-based malware solution. Other times the situation is unique to your enterprise and detection can be added with custom Snort rules or ClamAV signatures. Sometimes the answer isn't in anti-virus or IDS systems. Perhaps the answer is a traditional firewall rule, application control or even a change to existing policies and procedures. Whatever the question this is the phase where you develop the correct answer for your environment.

The final phase is "Act", where the solutions developed in the "Adapt" phase are incorporated into your security stance. Often this happens automatically as your Snort and Sourcefire 3D sensors are updated with new detection content or when ClamAV and FireAMP receive new signature updates.  Updates may also be custom signatures and rules created by your own organization.  Sometimes changes to your security stance must occur within the policies of your environment. For example you may be subject to change controls before making firewall changes or QA checks prior to deploying custom detection. However it happens, now is when you bring your new defenses online. From here you monitor how your network and your adversaries react to your changes, and the cycle starts again at "See".

Normally I don't pay a lot of attention to marketing. For the most part I'm heads down into fighting day-to-day issues along with others on the VRT to get our new protections to our customers.  But when someone lays out exactly how many of our customers deal with issues and maps our product lines to this approach, I think it's worth looking at. For more information about Agile Security, you can go here:

http://www.sourcefire.com/agile-security.

I know, that's two nice posts in a row. No doubt I'll be angry about something next time.

Razorback 0.4.1 released

The Razorback team has released version 0.4.1 (yeah, we would have released 0.4, but we found some critical bugs that we really needed to fix before general release).  You can find the new version of Razorback here:  http://sfi.re/zQQOQ4.  We've done a lot of work both on the internals of Razorback as well as a couple of new nuggets.

First and foremost, you need to know that we made changes to the API and the database schema.  We're getting close to the point where we will lock the API, but we've had to make some changes to support our goals, so you'll need to rework any custom nuggets you are working on and retool your database.  You'll also see some changes in the queueing setup, but that happens automatically.  I can tell you there will be additional changes in the 0.5 release and then, hopefully we're done.  Hopefully :)

The first change I'd like to discuss is the concept of locality.  Because of the large network traffic that could be generated by the system, we wanted to be able to take advantage of a shared file system to increase throughput and, depending on what kind of shared system you are using, reduce the amount of network traffic.  To do this we've developed the concept of locality.  If you share a locality with the dispatcher, you will access the data blocks directly from the shared disk system.  By default, the dispatcher locality is 1.  Any other locality will result in datablocks being transfered over the network in the standard way.  So if you have a fast shared disk system, be it NFS or a SAN setup, set the locality in api.conf and this should increase your throughput.

Speaking of data transfer over the wire, we've added encrypted data transfer.  Not surprisingly, this is fairly CPU intensive in certain cases, but depending on your needs this may be a required piece of functionality.  The transfer goes over SSH/SFTP and uses the standard libssh library.  We've removed transfering the datablock by putting it in the queue (this resulted in too much data in the queue) so currently this is the supported network data transfer.  The username is automatically the nugget id, and this is checked against the database setup and the password is configured in the api.conf.

Another place we use the locality concept is in our new master/slave high-availability setup for the dispatcher.  Dispatchers in a master/slave setup must share a locality so as they fail over they have all the datablocks that have been transfered to the dispatcher.  In the master/slave setup the routing table is shared between the servers so in the case of failover none of the nuggets will need to be re-registered.  Because of the queue server setup, all of the pending requests will then be handled by the new master nugget on failover.  CLI commands for viewing the status of the high-availbility setup and force-failing servers have also been added.

We've added three new nuggets.  Two of them, syslogNugget and razorTwit, demonstrate the new output nugget capability.  As alerts and status changes come into the dispatcher, details are placed into a queue that output nuggets can subscribe to.  This capability is intended to reduce the impact of database queries and to provide an alternate, installation-specific, capability for logging.  See the nugget samples for more information, they are fairly straightforward.

Finally, we are introducing a beta build of the new PDFFox nugget built by Ryan Pentney.  The idea behind this nugget is to provide an open-source pdf analyzer that doesn't rely and a costly commercial application to work.  The project is still coming together, and you should probably run the latest from trunk, but its coming along nicely and provides solid detection.

So that is it, besides a bunch of bug fixes from 0.3.  We're now working on the Q1 2012 development cycle and it entirely revolves around the Windows API and several nuggets to plug into anti-virus systems.  We're also deploying our first major in-house production build of Razorback, so numerous performance tweeks are in the works.  Expect information about how to tweak each of the components for maximum performance as we complete the Q1 run.

For those that use our VM, the updated 0.4.1 VM should be up shortly; Tom Judge is making a few tweaks on that side before we release it. 

We want to say thanks for giving Razorback a try, let us know if you have any issues via the mailing list or #razorback on freenode.

Android.Counterclank: Malware or Adware?

This weekend I noticed a ComputerWorld article titled "Massive Android malware op may have infected 5 million users". After reading, it seemed to be exactly the sort of thing many people have been suggesting - an increasingly large-scale outbreak of malicious activity in the Android market, as malware authors saw larger numbers of potential targets. After forwarding the article to my VRT colleagues, we quickly got copies of the few apps that Google hadn't already pulled - specifically, the files com.redmicapps.puzzles.ladies2_v1.02.apk, com.redmicapps.puzzles.ladies3_v1.02.apk, and com.christmasgame.deal_v1.0.1.apk. Eager to see how bad the damage was, we sat down to analyze them yesterday morning.

Some initial static analysis by Alain Zidouemba seemed to confirm what Symantec was saying in its writeup. Not only did the URLs mentioned there appear in the code, the testGetUserID() function pulled the exact information listed in the Symantec writeup:



Dynamic analysis inside the Android emulator was equally promising at first. Within seconds of installation, an HTTP POST to http://www.apperhand.com/ProtocolGW/protocol/commands appeared, and a slew of data was sent off in plaintext:

○ {"initiationType":"first time","needSpecificParameters":true,"applicationDetails":{"abTests":null,"applicationId":"212546654","build":{"brand":"generic","device":"generic","manufacturer":"unknown","model":"sdk","os":"Android","versionRelease":"2.3.3","versionSDKInt":10},"developerId":"987550925","deviceId":"wCxwXphYj3JMoEasWcr+zmVQHjY=","displayMetrics":{"density":1.5,"densityDpi":240,"heightPixels":800,"scaledDensity":1.5,"widthPixels":480,"xdpi":240.0,"ydpi":240.0},"locale":"en_US","protocolVersion":"1.0.6","sourceIp":null,"userAgent":"Mozilla/5.0 (Linux; U; Android 2.3.3; en-us; sdk Build/GRI34) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"},"parameters":{}}

The response that came back made it clear that a unique installation was being tracked:


{"commands":[{"id":"c2d71967-b6a1-451f-9d01-aa91adbfc0d1","parameters":null,"command":"ACTIVATION"}],"commandsInterval":15,"parameters":{},"abTest":"6a13d5ca-f5c7-4805-a12b-c70a4953bb6e","validResponse":true}

Subsequent requests to this URL showed a successful activation, and later returned a "SEARCH URL" of "http://www.searchmobileonline.com/{$CATEGORY$}?sourceid=7&app=4Ek2WZkCbw1Yw9VS%2F6q9D8zE67pPruhMY4SiC6pvyUzqgGNpf%2FjIrlCBA7Bp03eF9wSiv%2FHkJK%2FvkoMTkeCPaA%3D%3D&q={$QUERY$}", which again backed up the Symantec threat report. Figuring we were on to something, we let the malware run, interacting with it as a normal user would (i.e., by playing the games).

The problem was, nothing all that interesting ended up happening. Across the two distinct applications (the two "ladies" puzzles behaved essentially identically), nothing more than a series of advertising-related requests occurred in the background:

• A POST to http://data.flurry.com/aap.do with some device information, which a quick Google search showed was related to mobile ads


• Several POSTs to http://www.jigsaur.com/index.wsgi?method=CheckForReward that contained snippets of data that appeared to be related to the game in progress; visiting the Jigsaur.com home page redirected us to a jigsaw puzzle game on the Android market


• A POST to http://www.umeng.com/app_logs that contained data about the Android version, country and timezone of the user, etc.; this appears to be related to a Chinese mobile analytics tool


• GET requests for URLs on mobclix.com and googleads.g.doubleclick.net, which both returned advertising content

At this point, we started to wonder whether these apps were really malicious, or just using obnoxious ad networks. Going back and re-examining the data from the Apperhand.com requests, we realized that the data was essentially all information an ad provider would find useful: everything from device version to screen size, and an ID that would be useful to track which host was clicking on which ad. From there, we started doing some digging to understand what exactly happens in the world of mobile advertising, and whether this was out of the norm.

We quickly ran across a blog post from Mobclix - one of the advertisers we'd seen in the packet captures - discussing the need for unique IDs in targeted ads. That rendered the most suspicious piece of the data largely moot in our opinion.

Digging a little further, we noticed that Lookout Mobile Security had actually put together a blog post the same day as the ComputerWorld article, refuting Symantec's claim that Counterclank was malware and insisting it was simply obnoxious adware. For instance, they noted that sending off IMEI data - used to uniquely fingerprint modern mobile phones - is common across multiple networks, but that the Apperhand SDK used by Counterclank actually went to the trouble of hashing that value before sending it along to preserve privacy. Looking at the code, this was easy to confirm:



The Lookout report, like Symantec's, noted that Apperhand appears to be based on another SDK known as Plankton, which was much less concerned with user privacy and much more pushy about its ad behavior. This seems to be confirmed by the way these new files are detected by some AV vendors: of the 11 vendors listed in the VirusTotal report that detect the "ladies3" app, four call it some variant on "Plankton", three a variant of "Counterclank", and the remaining four have miscellaneous or generic labels for it. Given that all the reports we've seen thus far describe Apperhand as a kinder, gentler version of Plankton, it seems likely that that SDK may simply be an advertising setup that's not good at respecting user boundaries.

So what's the VRT take on this, you ask? We think it's pretty clear you don't want any of these apps on your phone. Not only do they send out data that may make you uncomfortable to ad networks you have control over, they're actually poorly written anyway - for example, the "Deal & Be Millionare" game didn't even bother to rotate for proper screen orientation:



That said, we think this falls into they gray area of "crappy adware" more than being outright malware. This SDK certainly could use further scrutiny, as do any of the other more pushy advertising setups on mobile phones. Barring further evidence, though, it just doesn't seem to rise to the threshold of other apps that commit SMS fraud, have clear command and control channels, etc.

Since we're not the final authority on the matter, though, we're going to make it easy to decide for yourself how you feel about these apps. We're providing a signature in today's SEU that will detect the POST requests sent to the Apperhand site, and we encourage you to take a look at our packet captures (here and here) to see the raw data yourself. There's also ClamAV coverage under the name Andr.Plangton-12. After all, it's your network, so why shouldn't you be able to defend it, even from crappy adware?

A New Hope

Rep. Mike Rogers (R-MI) and Rep. Dutch Ruppersberger (D-MD) know a secret:  The Federal government is REALLY good at watching people, much better than, say, the private sector.  So they asked themselves (at least they did in my mind), "Why not share some of that information in order to protect American businesses from the ubiquitous cyber-security threat?"

Hey guys…that’s a damn good idea!

Seriously, I thought it was a great idea.  So it was with a good deal of enthusiasm that I printed out H.R. 3523, or to use its more sexy name, the “Cyber Intelligence Sharing and Protection Act of 2011”.[1]  There are only 11 pages, a lot of it standard language stuff, but it essentially lays out that the governement can share with the private sector and vice versa.  Of course, it's never that simple.  For example, the NSA can only share with cleared organizations that can demonstrate they know how to handle classified information.

There is also the small matter of the following statement from the proposed legislation:  "classified cyber threat intelligence may only be … shared consistent with the need to protect the national security of the United States.”  Which, of course, leaves one giant question:  What, exactly, constitutes a threat to national security?

There are, of course, the obvious…terrorists, nuclear proliferation, hostile foreign nations, and the like.  But that isn’t what Rogers and Ruppersberger are thinking here.  They are, according to Mike Rogers, targeting “economic predators, including nation-states, [that] are blatantly stealing business secrets and innovation from private companies.” [2] So we aren’t talking missiles, bombs and airplanes, we’re talking, potentially, about contract negotiations, natural resource surveys and customer lists.

A recent report [3] by the Office of the National Counter Intelligence Executive (ONCIX) states that “Losses of sensitive economic information and technologies to foreign entities represent significant costs to US national security.”  Clearly, this administration, and apparently this congress, are adopting the position that jacking with U.S. companies jacks with the national security.  Given the nature of the world today, I think they're right to do so.

I know...I'm not well known for staunchly backing the ideas of legislators or administrators.  You wouldn't be blamed for thinking I’m a cynical, pessimistic nutter who lived by himself in a wooden hut, eating nothing but pickled ginger and gummy bears while spending his day ranting about the overly generous nature of most computer networks.[4]  But this time -- and I do have trouble saying this -- I think they’re on to something.  The private sector just isn't in a position to match the federal government's ability to generate intelligence.  In fact of all the things the government could provide in the forms of mandates, laws, policies, rules, reporting requirements, CISSP factories, etc... intelligence is really the only thing that makes sense.  It's the only thing that they can provide that industry can't legitimately generate itself.  I think this is a really good piece of legislation.

Of course, there are lots of ways to screw it up, and I'm sure that some of those ways will be found.  But if we get into the habit of having the government share information and letting organizations figure out how to act on the information, we'll be headed down a very good path.

[1] http://www.gpo.gov/fdsys/pkg/BILLS-112hr3523ih/pdf/BILLS-112hr3523ih.pdf
[2] http://dutch.house.gov/2011/11/ruppersberger-rogers-introduce-cybersecurity-bill-to-protect-american-businesses-from-economic-preda.shtml
[3] http://www.ncix.gov/publications/reports/fecie_all/Foreign_Economic_Collection_2011.pdf
[4] And nothing in this blog post would prove you wrong…

Cross-Platform Single-Request Web Server DoS From CCC

Security never sleeps, even if it is the week between Christmas and New Year's, and most of you are on vacation, enjoying time with your family, or just goofing off because the office is empty. Today's reminder of that reality comes from Alexander Klink and Julian Walde, who presented yesterday at the 28th Annual Chaos Communication Congress a method of consuming a web server's entire CPU with a simple, low-bandwidth POST request. In fact, according to the advisory they released after the talk, as little as 30k/sec could be necessary to occupy a single i7 core, depending on the target platform.

While the details of the attack are complex and vary from one target platform to another, the essence of it is that if you can send a large number of key/value pairs where the keys cause collisions in the receiving system's hashing algorithm, each colliding key will consume exponentially more CPU time to parse than the last. This makes for fairly straightforward detection in Snort - exceptionally large numbers of key/value pairs are necessary to trigger the bug, and so it's a matter of counting them up in a given request.

We've released SIDs 20823 and 20824 in an SEU late last night to cover this vulnerability.

For more information on this vulnerability check out the MSRC blog post here. The VRT Snort rules for detecting this vulnerability are discussed in their blog post.

We are working on the additional issues patched in MS11-100, and will provide coverage for those shortly.

Malware Mythbusting

The malware sandbox that I've previously discussed on this blog has made for a lot of useful Snort rules - but it's also helped get me some excellent speaking slots around the world this year. This time, I've just wrapped up a presentation titled "Malware Mythbusting" at Ruxcon, Australia's premier technical security conference.

The premise of the talk was simple: there's a lot of hype surrounding malware, and if you're someone tasked with keeping a network secure, there's generally not a lot of good information about the nature of the threat. Can I cut off China and Russia and make all the C&C servers go away? Are spambots really a major threat, or has garden-variety malware moved on? Are the people writing malicious software a bunch of evil geniuses, or can a little bit of diligence and attention locate heaps of nasty behavior on the network?

While I don't claim to have all the answers - no one does - I hope to have done a reasonable job of answering some of these questions during this talk. For those of you who didn't have the chance to make it down here - and for those who did that want to take a closer look at some of the data presented - I've made my slides available here. As I noted in the talk, if you have questions that it left unanswered, or if you're interested in working with us on malware research, drop the VRT a line - we're happy to collaborate with anyone who has good ideas. After all, at the end of the day, we're all on the same team here, and anything that can be done to clean more malicious software from the Internet is a good thing, regardless of the source.