Tuesday, March 31, 2009

Rule release for today - March 31st 2009

A few new rules in this release, here's the highlights:

MySQL Denial of Service (CVE-2009-0819):
A programming error in MySQL Server may allow a remote attacker to cause a Denial of Service (DoS) against a vulnerable machine.

Mozilla Firefox XML Buffer Overflow:
A programming error in Mozilla Firefox may allow a remote attacker to execute code on a victim machine. The error is exposed when the application attempts to process a specially crafted XML file.

As always, details are available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-03-31.html

Friday, March 27, 2009

Rule release for today - March 27th 2009

A couple of interesting vulnerabilities covered in todays release, first one is for Microsoft Windows:

Microsoft Windows GDI Buffer Overflow:
A programming error in the Microsoft Windows kernel may allow a remote attacker to execute code with system level privileges. This may be exploited when specially crafted EMF files are viewed using Microsoft Internet Explorer.

Second one concerns Mozilla Firefox:

Mozilla Firefox XSL Buffer Overflow:
A programming error in Mozilla Firefox may allow a remote attacker to execute code on a victim machine. The error is exposed when the application attempts to process an XML file that has a specially crafted XSLT transform.

As always, details are available here:


BEA WebLogic plug-in for Apache JSESSION Cookie overflow

Sometimes you forget you reported a vulnerability. Especially when the vendor keeps sending you lots of messages that contain the following:

Reporter: Matt Watchinski ("Matt Watchinski" <mwatchinski@sourcefire.com>)
Organization: Sourcefire

Tracking #: 13175503
Status: Under investigation / Being fixed in main codeline

Reporter: Lurene Grenier ("Lurene Grenier" <lgrenier@sourcefire.com>)
Organization: Sourcefire

Eventually, you just create an email filter to ship them off somewhere, and review them every few weeks to make sure they don't say anything different. After a while I totally forgot about it, until I deleted the filter and a new one showed up in my inbox, which I responded to by asking when it would be fixed. To my suprise, the response I got back was that the January CPU 2009 update for Oracle fixed this problem.

Since this is now +60 days from some definition of Day 0, here are all the details.

Additionally, this has been detected by Snort/Sourcefire since 10/22/08 by SID 15010 GID 3

BEA WebLogic plug-in for Apache JSESSION Cookie overflow

Discovery Date:

Release Date:
1/13/09 - Oracle patched
3/27/09 - We noticed


Oracle / BEA Weblogic

Systems Affected:
Apache Plugin http://download.oracle.com/otn/bea/weblogic/server103/WLSWebServerPlugins1.0.1150354-Apache.zip or below. This link is still on most of the BEA weblogic pages. The only way to get the patch is with a Oracle Support Account.
  • Apache Plug-ins up to an including the ones released on October 14, 2008 which implies:
    • Oracle WebLogic Server 10.3
    • Oracle WebLogic Server 10.0 released through MP1
    • Oracle WebLogic Server 9.2 released through MP3
    • Oracle WebLogic Server 9.1
    • Oracle WebLogic Server 9.0
    • Oracle WebLogic Server 8.1 released through SP6
    • Oracle WebLogic Server 7.0 released through SP7
    • Oracle WebLogic Server 6.1 released through SP7

A vulnerability exists in the parsing of the JSESSIONID cookie in the Apache Plug-in connector for BEA Weblogic that can result in a buffer overflow. This vulnerability may impact the availability, confidentiality or integrity of WebLogic Server applications which use the Apache web server configured with the WebLogic plug-in for Apache. This vulnerability may be remotely exploitable without authentication, i.e. it may be exploited over a network without the need for a username and password.

Technical Details:
The vulnerability is the result of an incorrectly bounded strncpy that uses the length of the cookie parameter and not the length of the destination buffer as the amount of data to copy. Additionally clustering must be enabled for this specific function to be reached.

MD5sum of Plugin used for testing this vulnerability
e0 mod_wl_22.so

Psuedo Code Of the vulnerability:

v8 = strchr(v6, 59);
if ( v7 == (const char *)v4 || (v9 = *(v7 - 1), v9 == 32) || v9 == 59 )
if ( v8 )
v12 = v8 - v7;
v11 = v7;
v10 = -1;
if ( !v10 )
v50 = *v11++ == (_BYTE)v8;
while ( !v50 );
v12 = ~v10 - 1;
strncpy(&ArgList, v7, v12);
sub_10009730(50, *(char **)(v2 + 1172), "Found cookie from cookie header: %s\n", &ArgList);

As you can see v8 and v7 are used to calculate the length of data to be copied and is stored in v12. v8 and v7 are the end and begining points of the cookie value. This makes v12 the length of the cookie value. The problem is that ArgList in the strncpy is a fixed size and is stored directly on the stack. If the result of v8 and v7 is greater than the max size of ArgList then a buffer overflow occurs.

httpd.conf / apache conf used to test this vulnerability:

MatchExpression *.*
WebLogicCluster localhost:7001
WebLogicHost localhost

WebLogicPort 7001

Simple reproduction case:
Exploitation requires a JSESSIONID cookie value of greater than 8000 bytes to trigger:

perl -e 'print "POST /index.jsp HTTP/1.1\r\nHost: localhost\r\nCookie:
JSESSIONID=" . "A"x9000 . "\r\n\r\n" | nc 80

This should cause the connector to crash. Apache will then restart it.

Metasploit 3.0 reproduction case:
Added to svn

Vendor Status:
Reported to Oracle on 10/22/08
Patched by Oracle on 01/13/09

* Matthew Watchinski - Sr. Director Sourcefire Vulnerability Research Team (VRT)
* Lurene Grenier - Analyst Team Lead, Sourcefire VRT


CVE - 2008-5457

Wednesday, March 25, 2009

Conficker.C Purchase tickets now for the April 1st event


Conficker.C also known as W32/Conficker.C.worm, WORM_DOWNAD.AD,W32.Downadup,Net-Worm.Win32.Kido.cn

Still uses MS08-067 to spread itself just like the A and B variants, therefore the detection released on 2008-10-23 still generates events based on this spreading mechanism.

Now for something completely different.

The interesting thing about Conficker.C is that it added new functionality, which includes:

  1. A new DNS algorithem
  2. A new P2P controlling system
  3. A new call home date of April 1st

For a great summary of all of this, the guys over at SRI, have updated their paper[0] on Conficker.

Finally, one of our current research projects is adding variant A,B and C DNS name matching to Snort. Unfortunately, making this work on multiple platforms and multiple compilers seem to be a major pain. If there is a gcc or icc developer that reads this blog, explaining how to force intermediate 53-bit floating point precision on both icc and gcc would be helpful. Unfortunately, the -msse2 compiler option doesn't do this on gcc and the icc fp-module double doesn't work on all icc versions.

[0] - http://mtc.sri.com/Conficker/addendumC/

Friday, March 20, 2009

Geographic Representation of Snort Events

One of the Sourcefire field engineers has whipped up a Perl script that will take events generated by Snort or a Sourcefire appliance and map them using Google Earth.

You can find a write up here at Leon's blog where he has an interesting example relating to worm activity.

A copy of the script is available here at Jason's site

Nice work Leon.

Thursday, March 19, 2009

Creating new detection coverage : Using SCADA OMRON-FINS as an example

The What
In 2008 a lot of reports and press centered around SCADA Networks and their protection, additionally Core Security and several other researchers released vulnerabilities in software related to SCADA networks. The most notorious was the vulnerability in CitectSCADA (http://www.coresecurity.com/content/citect-scada-odbc-service-vulnerability), which kicked off a lengthy discussion on protecting SCADA networks and other so-called critical infrastructure.

This got me thinking that the Sourcefire VRT should have some additional protections in place for these types of networks and the software that runs on them. So we set about learning about how these types of networks work, what runs on them, what protocols, and how they are configured. Luckily, I grew up with my bud Brian, who now builds coal fired power plants, and used to attend the local 2600 meetings with me 10 years ago. He brought me up to speed on how these networks are configured, deployed, and protected in real world environments, the main take-a- ways from this conversations where the following:

  1. HMI is the generic name of all monitoring and controlling software - This is essentially what CitectSCADA is, it monitors lots of sensors on the hardware in a power plant or other facility and returns the data it reads from those sensor to a central location were it can be monitored. Think of it as a massive SNMP monitoring station.
  2. Every device on the planet is different, they all have special things that can be monitored, and most of them run manufacturer specific protocols. Even if something runs something standard like MODBUS or IDP3 you still have to program your HMI to read the correct values from the device based of the vendor documentation. IE reading memory bank0 on device X gives you temperature, while reading it on device Y gives your pressure.
  3. Unless you work for the power company you aren't getting access to the devices and or sensors that run in these places to play with. Or your really wealthy. Neither of which I am, and I would fear for my life if me or my team had access to remotely controllable pressure values, temp gauges, and spinning disks. I know what I would build, and I know my team is even more creative than I am.

Given that I sat down and worked up the following.

  1. A long list of free or shareware HMI applications that were available.
  2. A very very very short list of SCADA vulnerabilities. At the time I did my search it was around 3, all 3 being in HMI software non of which applied to SCADA specific protocols. i.e. you're not going to find a "pressure gadge XYZ when sent a malformed MODBUS packet results in the device failing open and letting all the pressure out"
  3. A threat diagram based on zones of trust for the typical SCADA network configuration.

This led me to the following goals for providing coverage for SCADA networks.

The Goals

  1. Cover any vulnerabilities related to SCADA software in reachable by traditional protocols. This would include CitectSCADA as the vulnerability travels over ODBC database traffic.
  2. Develop Snort rules for finding SCADA specific protocols. Specifically MODBUS, IDP3, OMRON-FINS, ELCOM, etc.
  3. Using the threat diagram determine what types of coverage categories SCADA networks would need. This resulted in the following:

    1. SCADA traffic leaving or entering a domain of trust. Most SCADA networks are designed in principle so that the SCADA traffic is on a specific network, and can only be accessed from very specific places.
    2. Locate malformed traffic - Malformed traffic can either be bad devices on the network, or bad guys on the network. Both of which are of interest.
    3. Locate critical commands and detect there existence - Uploading new instructions to a read only device, overriding a read only status, halting a device, or starting a device seemed like interesting critical commands.

With all that we could now start taking some of these protocols apart and building the correct coverage for each threat category. At this point I selected OMRON-FINS as the protocol I was going to investigate.

The How

Now that I knew what I wanted to do and what protocol I wanted to work with I needed to start diving into the details. This is the procedure that I worked through to get all the details that I thought I would need to go from concept to Snort Rules.

  1. Find all the documentation - http://forums.mrplc.com/index.php?showtopic=5693. MRPLC is an excellent resource for PLC / SCADA related devices and sensors. It has a ton of reference manuals that are hard to find, and some forums with excellent information from people trying to make certain devices work.
  2. Setup a client and server that can talk OMRON-FINS. This was a lot easier than I thought it would be, as OMRON-FINS is UDP and the first piece of HMI shareware I downloaded supported talking to these devices. Therefore I built my own fake client in perl and set about setting up the HMI software to talk to my simple UDP listener.

Setting up the HMI software as actually kind of fun as you got to draw visio like diagrams, call them sensor XYZ, define what type of values it would write and set, and arrange those sensors to control specific pieces of the diagram. At the end of the day I settled on a template of a engine with a temperature gauge, speedometer, and a gas petal. This allowed me to read the engine temperature, check the current speed, and make the fake engine go faster or slower with the gas petal. I even made the screen flash red if the temperature got to high. Once I hooked all that together the HMI software started sending me all kinds of OMRON-FINS UDP packets. Now I need to go back to the documentation and figure out what I need to send back to the HMI software in the form of responses so that I would show the values on the screen. This took a couple hours, as the documentation is a bit lacking in a few key areas. Additionally the guy who wrote it obvious knows how serial coms work, but never really grasp this whole Ethernet craze.

At this point I had a really awesome set of pcaps and other data to go work with.

Next I set about working up a Wireshark dissector for OMRON-FINS, I find writing a new dissector for a protocol makes my life easier as I can name things, break them out, do fun things with bits, and it results in a nice set of "code" documentation if I ever need to go back to this protocol in the future. Also its always fun to send some code back to a project you use all the time. You can find my patch to Wireshark here https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3226. It hasn't been added to the mainline code yet, but should patch nicely into code checked out of SVN.

In conjunction with the Wireshark dissector I build a unit test script for the Wireshark dissector that created one of every OMRON-FINS command, and one of every possible OMRON-FINS response. This allowed me to do two specific things, create a test case for each command, and a reason to read the entire OMRON-FINS manual. While doing that I would write down any command or response that fit my threat profiles from above, giving me a nice clean list of Snort Rules I wanted to

The Details

The following is the list of Snort Rules I came up with that met my criteria above.

Interesting commands that wrote information to memory for the device to use later.

SCADA OMRON-FINS memory area write attempt
SCADA OMRON-FINS memory area fill attempt
SCADA OMRON-FINS memory area transfer attempt

Interesting commands that wrote information to the parameter areas on the device. These memory areas would then be used by other functions of the devices. IE parameters for functions.

SCADA OMRON-FINS parameter area write attempt
SCADA OMRON-FINS parameter area clear attempt
SCADA OMRON-FINS file memory write attempt
SCADA OMRON-FINS data link table write attempt

Interesting commands that wrote program code to specific areas on the device. Normally the device would be in a "protected" state were you couldn't write, unless the protection flag was cleared.

SCADA OMRON-FINS program area protect attempt
SCADA OMRON-FINS program area protect clear attempt
SCADA OMRON-FINS program area write attempt
SCADA OMRON-FINS program area clear attempt

Commands for starting or stoping a job on the device.


I don't know about you but I think that messing with clocks is always bad, they are really important when the clock turns wheels, gears, or sets the timing of some event.

SCADA OMRON-FINS clock write attempt

Asking for more access is always suspect.

SCADA OMRON-FINS access right acquire attempt
SCADA OMRON-FINS access right forced acquire attempt

Writing and deleting files might be bad.

SCADA OMRON-FINS single file write attempt
SCADA OMRON-FINS file delete attempt

Anything with the word force in it you want to know about.

SCADA OMRON-FINS forced set/reset attempt
SCADA OMRON-FINS forced set/reset cancel attempt

Deleting and formating, hum.....

SCADA OMRON-FINS name delete attempt
SCADA OMRON-FINS memory card format attempt

Generic overflow protection on things that have fixed protocol lengths.

SCADA OMRON-FINS memory area write overflow attempt
SCADA OMRON-FINS memory area fill overflow attempt

And no brute forcing passwords thats not nice.

SCADA OMRON-FINS program area protect clear brute force attempt

The Conclusion

When working with new detection categories or coverage of unknown protocols, its best to following something like the above, especially if there is limited information about the types of threats that affect these types of networks or applications. This is the process we use here for this type of work and it has worked well for new protocols, new classes of vulnerabilities, and policy based detection of IM/P2P/and other applications people do not want on their networks. Feel free to give it a try next time you're working on something new, and don't forget to send your wireshark dissector to the Wireshark guys.

Tuesday, March 17, 2009

Rule release for today - March 17th 2009

We've been busy updating some rules and adding extras, lots of changes to a lot of rules. Mostly a maintenance release with some new scada rules.

The scada rule set now includes support for OMRON FINS. Additionally, multiple rules in the specific-threats and content-replace categories have been updated to provide more accurate detection.

More details available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-03-17.html

Tuesday, March 10, 2009

Behold the Glory of Mattland

Like many other groups, the VRT has a morning routine. Generally it involves comparing kill board stats or raiding tips on whatever game is hot, a quick run down on the work of the day (sometimes as broad as “go break something”, sometimes more specific), and then some time set aside for discussing the morning’s news stories, generally over coffee. These conversations can get pretty rowdy, but they can also provide fodder for more productive discussions about security.

A recent story regarding NASA’s difficulties with their “Avocado” program (http://www.businessweek.com/magazine/content/08_48/b4110072404167.htm) generated a lot of discussion, and led to the creation of Mattland. Mattland is a mythical company where security concerns can trump business needs, people don’t sulk and quit because of overly intrusive security policies and the Internet is viewed with all the suspicion of a smoking gun. It is a place where security monkeys run amok, and the question is, if you were the CISO for Mattland, what would you do?

The security intrusion events at NASA reportedly included information that indicated that “billions” of dollars of rocket motor and fuel system research had been compromised by foreign governments. Which led to the incipient stage of Mattland: “What in the great blue #$&* is billions of dollars of research doing on a computer you can get to on the Internet? In Mattland you wouldn’t be on the #$@&! Internet…” and a lengthy, occasionally coherent rant that hinged on the principle of appropriate levels of separation and how the Internet was not a right but a privilege.

As subsequent random conversations and news items (the loss of the plans of Marine-1 was a doozey…) occur, Mattland is fleshed out with a finance group, researchers and even a mobile sales staff. Here are some of the more interesting “grand ideas” (semi-lucid rants) from these discussions:

  1. You don’t get the Internet. You can’t have it, just sit there and do your work. If you want to check your mail, on your break you can walk over to that computer wayyyyyy over there and check it. If I ever find a cable between that computer and the production network, you’re all fired.
  2. All USB ports will be treated with some disabling technology. The ideas have been creative; some of the ones that are appropriate for this blog would be applying 220V, filling them with super glue or just ripping them off the board. These measures will be physical in nature, rather than administrative, to reduce the chance they will be bypassed. Note to Mattland’s acquisition group, we need some PS/2 keyboards.
  3. All sales staff will be given a laptop as they leave the building, loaded with the approved data. They will then return the laptop to the company which will load any new data onto the network after scanning the data.
  4. Mattland will aggressively use alternatives to popular software. This should help avoid exploits targeting popular software packages. This certainly won’t prevent targeted attacks, but should help avoid mass-outbreak problems that target the largest vulnerability surface.

Purest fantasy? Certainly. But an interesting thought experiment. So the Vulnerability Research Team wants to know, if you catch your boss so hung over he’ll sign off on anything to get you to go away, what insane security measures would you put in place?

Microsoft Tuesday Coverage for March MS09-006, MS09-008

Microsoft Security Bulletin MS09-006:
A programming error in the Microsoft Windows kernel may allow a remote attacker to execute code with system level privileges. This may be exploited when specially crafted EMF files are viewed using Microsoft Internet Explorer.

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

Microsoft Security Bulletin MS09-008:
The DNS protocol as implemented in Microsoft Windows systems may allow a remote attacker to spoof DNS traffic via cache poisoning techniques.

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

Additionally, a previously released rule will detect attacks targeting this vulnerability and is identified with GID 1, SID 13948.

Details and rules are available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-03-10.html

Friday, March 6, 2009

Generating Virus Signatures - The Automated Way

A common characteristic of malware distributed as an executable is to use a PE packer, such as UPX or Petite, to compress and obfuscate the malicious content. Once a file has been determined to be malware by our analysts and is using a PE packer that ClamAV does not currently unpack, a common virus writing technique is to write a signature of the packed data section of the PE file.

Instead of having to remember each of the PE packers that crosses my desk, and which sections of data the malicious code lives, I chose to automate this process.

pe-sig, a tool written in Ruby, uses the PE parsing and signature library from within Metasploit 3, automatically generates PE section signatures for known PE packers appropriate for loading into ClamAV.

When I process a file using pe-sig that was packed via pklite, pe-sig gives the following output:
16384:39ae378e47f13ceecca20d06201d0cc1:SIGNATURE__.pklstb__PKLITE32v1.1 [535]

Note, this is very similar to a signature that was released in mid-2008:

When processing PE files that might not be packed, or are from a packer we currently do not have signatures for, the output shown is all of the sections of the PE file:

Based on my knowledge of the file being processed via pe-sig, I know the packed data exists in .rsrc. My immediate work would be to find an appropriate signature for the packing portion fo the executable, add it to my signature list, specifying that .rsrc is the location of the packed data. Then next time I run across this packer, I won't have to remember what it is, or where its data is stored. The work will have already been done for me.

Tuesday, March 3, 2009

Rule release for today - March 3rd 2009

Specific threats, ActiveX and web-client have new rules. Major rule updates to other, older rules.

Details: http://www.snort.org/vrt/advisories/vrt-rules-2009-03-03.html