Mei 2009 ~ tutorial about web security computer networking

Minggu, 31 Mei 2009

Information Security Incident Rating

I've been trying to describe to management how close various individual information assets (primarily computers -- desktops, laptops, etc.) are to the doomsday scenario of sensitive data exfiltrated by unauthorized parties. This isn't the only type of incident that worries me, but it's the one I decided to tackle first. I view this situation as a continuum, rather than a "risk" rating. I'm trying summarize the state of affairs for an individual asset rather than "model risk."

In the far left column I've listed some terms that may be unfamiliar. The first three rows bear "Vuln" ratings. I list these because some of my businesses consider the discovery of a vulnerability in an asset to be an "incident" by itself. Traditional incident detectors and responders don't think this way, but I wanted to include this aspect of our problem set. For these first three rows, I consider these assets to exist without any discoverable or measurable adversary activity. In other words, assets of various levels of vulnerability are present, but no intruder is taking interest in them (as far as we can tell).

The next four rows (Cat 6, 3, 2, 1) should be familiar to those of you with military CIRT background. About 7 or 8 years ago I wrote this Category Descriptions document for Sguil. You'll remember Cat 6 as Reconnaissance, Cat 3 as Attempted Intrusion, Cat 2 as User Intrusion, and Cat 1 as Root/Admin Intrusion. I've mapped those "true incidents" here. These incidents indicate an intruder is taking interest in a system, to the degree that the intruder gains user or root level control of it. In the event the intruder doesn't need to gain control of the asset in order to steal data, you can simply jump to the appropriate description of the event in the final three rows.

The final three rows (Breach 3, 2, 1) are what you might consider "post exploitation" activities, or direct exploitation activities if no control of the asset is required in order to accomplish the adversary's data exfiltration mission. They loosely map to the reinforcement, consolidation, and pillage phases of compromise I outlined years ago. I've used the term "Breach" here to emphasize the seriousness of this aspect of an intrusion. (Gunter's recent post Botnet C&C Participation is a Corporate Data Breach reinforced my decision to use the term "breach" in situations like this.) Clearly Breach 3 is a severe problem. You might still be able to avoid catastrophe if you can contain the incident at this phase. However, intruders are likely to quickly move to Breach 2 and 1 phases, when it's Game Over.

If there has to be an "impact 0" rating, I would consider that to be the absence of an information asset, i.e., it doesn't exist. Any asset whatsoever has value, so I don't see a 0 value for any existing systems.

At the other end of the spectrum, if we have to "crank it to 11," I would consider an 11 to be publication of incident details in a widely-read public forum like a major newspaper or online news site.

I use the term "impact" in this sense: what is the negative impact of having the individual asset in the state described? In other words, the negative impact of having an asset with impact 1 is very low. We would all like to have assets that require an intruder to apply substantial effort to compromise the asset and exfiltrate sensitive data. At the other end of the spectrum we have the "game over" impact -- the intruder has exfiltrated sensitive data or is suspected of exfiltrating sensitive data based on volume, etc. Even if you can't tell exactly what an intruder exfiltrated, if you see several GBs of data leaving a system that houses or access sensitive data, you can be fairly confident the intruder grabbed it.

I listed some sample colors for those who understand the world in those terms.

I've reproduced the text below for future copying and pasting.

Vuln 3 / Impact 1 / Intruder must apply substantial effort to compromise asset and exfiltrate sensitive data

Vuln 2 / Impact 2 / Intruder must apply moderate effort to compromise asset and exfiltrate sensitive data

Vuln 1 / Impact 3 / Intruder must apply little effort to compromise asset and exfiltrate sensitive data

Cat 6 / Impact 4 / Intruder is conducting reconnaissance against asset with access to sensitive data

Cat 3 / Impact 5 / Intruder is attempting to exploit asset with access to sensitive data

Cat 2 / Impact 6 / Intruder has compromised asset with access to sensitive data but requires privilege escalation

Cat 1 / Impact 7 / Intruder has compromised asset with ready access to sensitive data

Breach 3 / Impact 8 / Intruder has established command and control channel from asset with ready access to sensitive data

Breach 2 / Impact 9 / Intruder has exfiltrated nonsensitive data or data that will facilitate access to sensitive data

Breach 1 / Impact 10 / Intruder has exfiltrated sensitive data or is suspected of exfiltrating sensitive data based on volume, etc.

What do you think of this rating system? I am curious to hear how others explain the seriousness of an incident to management.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

The National Cyber Security Effort

13.20 Cyber Security Review;"The Shadow Government";"McMafia" No comments

Inside the last three months, I have restarted my network security business: RMF Network Security (www.rmfnetworksecurity.com). I have been in research mode and I am still in some type of stealth mode, as I think about the implications of restarting a consulting business in the ever dangerous and now crime-ridden world of network security. The last time I did this, I didn't do enough "product development" and research in advance of my marketing efforts.

However, the last year of network security 'awareness' may change my need to do extensive marketing. Our President has just announced the results of the sixty day Cyber Security Review. More than 100 source papers were consulted. See my initial analysis below. I started this obscure blog with the idea that I could use the motivation of internet publishing to gauge my re-education and business progress. Inside the first month, I have had the same extensive (web interest) in my blog from American military, military-industrial complex, telecom, educational institutions that I had with my Powershell Blog (also network centric), but this time with lots of added hits now from Russia, China, ex-Eastern bloc and Brazil IP addresses. Interestingly, 'researchers' are mostly finding their way to my blog by googling IP addresses from my script dumps!

Apparently, my visitors are either expressing interest in the same Source Internet Protocol Addresses I am logging (SIPs) simultaneously or (worse case), those SIPs are looking at me while I discuss them. The network security business has changed since I last participated in developing IDS systems with NAI and Hiverworld. Things are bigger, badder and scarier - more criminal and nation-state oriented simultaneously. Firewalls and IPS software are being pushed beyond their intended capacities and organized crime and nation-state terrorists have become systemized at IPS evasion, spamming, botnets, bot herding, inserting key stroke loggers, malware, etc. "Cyberwarfare" has a new and significant government interest. Here are some reads I have found lately to prepare myself for changes in the field:

* "The Shadow Government" (James Bamford) This book documents the build-out in the cyber capacities of the National Security Agency in the last 8 years. Among other discussions it documents how the NSA has purchased industrial strengthcontext searching software from select software companies to analyze traffic from top network access points across all U.S. telecoms. This apparently is the book that broke the "warrantless wiretapping" scandal a year or so back.

* "McMafia" Misha Glenny discusses in detail recruitment the young and poor as cyber hackers for nation state terrorists and criminal organizations in Russia, Brazil, China, ex-Eastern Bloc nations and elsewhere. He also discusses world crime and world crime sophistication to date. A downright terrifying read. Apparently, the average computer in the U.S. is seen as a potential botnet member by most of the world's criminal syndicates/hackers.

* FOIA from Wired Magazine on the FBI's CIPAV spyware : http://www.wired.com/threatlevel/2009/04/get-your-fbi-sp Also a very inetersting read...Criminals use spyware and so does our government...Surprise!

I had some difficultly searching all the 100 assorted papers on line at http://www.whitehouse.gov/cyberreview/documents/ and resorted to mixing Cygwin and cmd.exe shells to do so. I did an initial context search, which admittedly lost papers and data at each command line. In any event, the papers may prove interesting reading yet, although they appear at first glance more policy oriented than technical.

[from cmd.exe or Cygwin]

lynx -source http://www.whitehouse.gov/cyberreview/documents/ | grep pdf | gawk -F\" '{print $4}' > source.txt

[from cmd.exe]

for /f "delims==" %i in (source.txt) do wget "%i"

[from cmd.exe or Cygwin]

ls -1 *.pdf > source2.txt

[from cmd.exe]

@(for /f "delims==" %i in (source2.txt) do pdftotext -f 1 -l 1500 "%i" pdf.txt && cat pdf.txt >> pdf.all.txt)

[from Cygwin]

for i in `cat file`; do echo `pcregrep -w -i -c $i pdf.all.txt` `echo $i` >> context1.txt;done

[from Cygwin]

$ cat context1.txt | sort -nr

499 Infrastructure

215 Services

194 Financial

53 criminal

52 crime

45 organized

45 loss

41 spam

39 malware

27 losses

24 Firewalls

20 botnets

16 Firewall

15 tax

14 organize

14 crimes

14 China

12 botnet

9 Russia

7 Linux

6 Windows

5 IDS

4 trojans

4 bot

4 IPS

3 bots

2 trojan

2 Israel

2 India

1 IE

1 France

1 Firefox

1 Apple

0 tcpdump

0 syslogd

0 sysklogd

0 spamming

0 keyloggers

0 keylogger

0 key-strokes

0 key-stroke

0 evasion

0 Snort

0 QNX

0 Opera

0 OpenBSD

0 Chrome

0 Bulgaria

0 Brazil

0 BRIC

If you are interested and have the time, let me know if you find my blog approachable, and what interests you think would most drive your businesses and professions to read and think about network security. I think I am gearing up to producing some white papers tailored to many audience types: business, personal, home user, etc. The goal is to generate interest for consulting contracts.

President Obama's Real Speech on Cyber Security

07.12 No comments

I was very surprised to read REMARKS BY THE PRESIDENT ON SECURING OUR NATION'S CYBER INFRASTRUCTURE, delivered yesterday. TaoSecurity Blog had received a copy of the President's prepared remarks, but about 2/3 of the way through the live version the President went off-copy. For the sake of my readers I've published the material the President omitted.

...And last year we had a glimpse of the future face of war. As Russian tanks rolled into Georgia, cyber attacks crippled Georgian government websites. The terrorists that sowed so much death and destruction in Mumbai relied not only on guns and grenades but also on GPS and phones using voice-over-the-Internet.

[Here is where the Presidential train left the tracks.]

When considering cyber security, we must recognize that our problems are multi-dimensional.

The first dimension involves the information assets we are trying to protect. Cyber security requires protecting information inputs, information outputs, and information platforms. Inputs include data that has value before processing, such as personally identifiable information. Outputs include data that has value after proecessing, such as intellectual property. Information platforms are the computing devices that process data, such as computers and the networks that connect them.

The second dimension involves the custodians of information assets, which we collect into three broad groups. The first group includes Federal, state, and local governments, with their various departments and agencies. The second group includes corporate, nonprofit, university, and related elements of the private sector. The third group includes individual citizens.

The third dimension involves threats to our information assets, which we collect into three broad groups. The first group includes criminals who attack information assets primarily for financial gain. When the term criminal applies to terrorists we must also consider their desire to achieve political ends as well. The second group includes economic competitors, taking the form of companies acting independently or in concert with national governments. The third group includes nation-state actors and countries, who threaten information assets through espionage or direct attack.

These three dimensions -- the nature of information assets, the varied custodians of information assets, and the many threats to information assets -- prevent the centralization of cyber security in the portfolio of any single "cyber czar" or other government figurehead.

In addition to the three dimensions of cyber security, we must recognize certain environmental factors that weigh upon possible approaches.

First, traditional cyber security thinking has focused on vulnerabilities in the digital world. Many believe that addressing vulnerabilities through better coding or asset management would solve the cyber security problem. However, outside the digital world, vulnerabilities are all around us. Every human is vulnerable to being shot, yet none of us in this room is wearing a bullet-proof vest. Well, almost no one. [laughter] If you leave this building, you still won't wear a bullet-proof vest in public. Why is that? You're exposed, you're vulnerable, but what keeps you safe from threats to your well-being? The answer is that our government and its protective agencies -- police, the military, and so on -- focus more on threats than on vulnerabilities. We deter criminals and prosecute those who do harm us. Cybersecurity is no different. Behind every cyber attack is a human agent acting for personal, organizational, or national gain. However, too much effort is applied to addressing vulnerabilities, when the real problem has always been the threats who seek to exploit vulnerabilities.

Second, cyber security incidents are extremely opaque compared to their non-digital counterparts. If criminals shoot down an airliner, no one can ignore the disaster. Following the previous point, few people turn to the construction of the aircraft when such a heinous act occurs; rather, the perpetrators are hunted and brought to justice. However, when personally identifiable information is stolen from a company, the true victims -- the American citizens now at risk for identity theft -- may never know what happened. Many states have breach disclosure laws, but those laws do not require an explanation of the nature of the attack. As a result, no other organizations can learn how security controls failed at the victimized company.

Third, the costs of cyber security incidents are often not borne by those who should be protecting information assets from attack. This results in the misalignment of incentives. If a company processing personally identifiable information is breached, the majority of the cost is borne by the citizens whose identities are stolen. The company may pay for credit monitoring services, but that cost is insignificant compared to that borne by the citizen. If a software company ships a product riddled with bugs, it generally bears no cost whatsoever if intruders exploit that software once deployed by the customer. The marketplace tends to not punish vendors who sell vulnerable software because the benefits of the software are perceived to outweigh the costs. This makes sense when the customer is a company, and the breach results in stolen PII -- with costs again borne by the citizen, not the company.

These three environmental factors point to a need to change the mindset around cyber security, as well as the need for greater transparency and better alignment of incentives and costs with those who receive benefits from information assets.

Given this understanding of the problem, my administration will take the following actions regarding cyber security.

We will make the Federal government an example for others to follow. We cannot expect any other party to take cyber security seriously if the Federal government doesn't lead by example. We will work to make the Federal government a defensible network architecture. We will finally recognize that, while important, controls are not the solution to our problems. Rather than being control-compliant, we will identify field-assessed metrics to measure our success.

We will work with Congress to establish a national breach disclosure law, and we will require publicly traded companies to outline digital risks in their annual 10-K filings. Then, we will create a National Digital Security Board modeled on the National Transportation Safety Board. The NDSB will have the authority to investigate information security breaches reported by victim organizations. The NDSB will publish reports on its findings for the benefit of the public and other organizations, thereby increasing transparency in two respects. First, intrusions will have real costs beyond those directly associated with the incident, by bringing potentially poor security practices and software to the attention of the public. Second, other organizations will learn how to avoid the mistakes made by those who fall victim to intruders. In some circumstances national security interests may limit the audience for these findings. Those who consider this approach draconian should consider how NTSB reporting improves the safety of transportation over time.

We will consult with the law enforcement community to determine what additional resources they need to deter and prosecute cyber criminals, and fund those requirements. We will be satisfied when a victim of cyber crime has the option to call the police for assistance, rather than rely on hiring their own forensic investigators. If cyber crime is a real crime, then victims should not be forced to outline digital dead bodies without official, expert assistance.

We will vigorously encourage our law enforcement and intelligence services to work with private industry to combat cyber espionage and cyber attack. As with cyber crime, victims should not be expected to defend themselves against professional corporate cyber thieves or foreign cyber warfare experts. This will include funding and fast-tracking deployments of secure communications channels like SIPRNET, and granting security clearances to appropriate parties without specific government contracts, so that victimized organizations can securely communicate with our defense and intelligence communities.

We will instruct the Secretary of Defense to examine the creation of a Cyber Force as an independent military branch. Just as we fight wars on land, at sea, and in the aerospace domains, we should promote warfighters throroughly steeped in the intricacies of defense and attack in the cyberspace domain. We will also make it clear to our national adversaries that a cyber attack upon our national interests is equivalent to an attack in any other domain, and we will respond with the full range of diplomatic, information, military, and economic power at our disposal.

We will drastically expand the Scholarship for Service or Cyber Corps program to include providing assistance to private sector actors and individual citizens who ask for help. Just as the Peace Corps provides physical assistance to developing countries, the Cyber Corps will provide digital assistance to those who apply for it.

We will work with Congress to dramatically increase cyber funding applied research. It is clear that the defensive models we have applied for the last thirty years need, at the very least, a serious review. Funding researchers who can thoughtfully consider different approaches is well worth the effort. This funding will include support for open source software projects that benefit the cyber community at large. We will also aggressively work to deploy more secure protocols to replace those whose threat model has collapsed as the computing environment has changed.

These seven steps are concrete actions that will have more impact than appointing a single person to try to "coordinate" cyber security across the multiple dimensions and environmental factors I described earlier. Thank you for you time. [applause]

Note: If you read this far I am sure you know this was not the President's "real speech." This is what I would have liked to have heard.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Homegrown tcpdump/snort analysis

19.09 LocateIP.sh;tcp/IDS analysis; No comments

I have written a script which parses snort and/or tcpdump text files to display significant information for Source and Destination IPs and ports.This script allows for some flexibility in filtering ports and ultimately produces separate files for each query and summary statistics as shown below. Tcptrace does similar work but I thought I would contribute something homegrown before I started looking in depth at existing tcp/IDS trace analysis tools.

## bash or ksh script to sort IP addresses from tcpdump or snort text output
## version 0.1 May 23 2009
## requires one argument: file name consisting of text dump of snort or tcpdump output
## requires pcregrep, awk,nmap services file, geoiplookup

/* rest of script here: http://www.rmfdevelopment.com/UnixShellScripts/LocateIP.sh.txt */

[some sample output:]
......Summary Statistics........
248 unique Source IP/ port pairs
190 unique source addresses
155 unique source ports
125 unique Destination IP/port pairs
6 unique destination addresses
124 unique destination ports
42 Source ports recognized by nmap services file
38 Destination ports recognized by nmap services file
190 Source cities recognized by GeoLiteCity.dat

[some sample files produced]
# ls -1 uniq*
uniqDIP.txt
uniqDIPPorts.txt
uniqDestIPs.txt
uniqIPs.txt
uniqSIP.txt
uniqSIPPorts.txt
uniqSourceIPs.txt

Defender's Dilemma vs Intruder's Dilemma

14.37 No comments

This is a follow-up to my post Response for Daily Dave. I realized I had a similar exchange three years ago, summarized in my post Response to Daily Dave Thread. Since I don't seem to be making much progress in this debate, I decided to render it in two slides.

First, I think everyone is familiar with the Defender's Dilemma.

The intruder only needs to exploit one of the victims in order to compromise the enterprise.

You might argue that this isn't true for some networks, but in most places if you gain a foothold it's quickly game over elsewhere.

What Dave and company don't seem to appreciate is that there is a similar problem for attackers. I call it the Intruder's Dilemma.

The defender only needs to detect one of the indicators of the intruder’s presence in order to initiate incident response within the enterprise.

What's interesting about this reality is that it applies to a single system or to a collection of systems. Even if the intruder only compromises a single system, the variety of indicators available make it possible to detect the attacker. Knowing where and when to look, and what to look for, becomes the challenge. However, as the scope of the incident expands to other systems, the probability of discovery increases. So, perversely, the bigger the incident, the more likely someone is going to notice.

Whether or not you can actually detect the intruder's presence depends on the amount of visibility you can achieve, and that is often outside the control of the security team because the security team doesn't own computing assets. However, this point of view can help you argue why you need the visibility to detect and respond to intrusions, even though you can't prevent them.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Publication Notice: The Rootkit Arsenal

13.38 No comments

Bill Blunden was kind enough to send me a copy of his new book The Rookit Arsenal. I plan to read it in a few months, due to my schedule and reading backlog. According to Bill, readers of the book will learn how to do the following:

Hook kernel structures on multi-processor systems

Use a kernel debugger to reverse system internals

Inject call gates to create a back door into Ring-0

Use detour patches to sidestep group policy

Modify privilege levels on Vista by altering kernel objects

Utilize bootkit technology

Defeat live incident response and post-mortem forensics

Implement code armoring to protect your deliverables

Establish covert channels using the WSK and NDIS 6.0

I am interested in the anti-forensics material, as you might imagine.

I first learned about Bill's work when he produced this presentation on rootkits. Slide 34 caught my attention:

That's pretty cool, but I am reminded of my post last summer on getting the job done. I wrote:

I have encountered plenty of roles where I am motivated and technically equipped, but without resources and power. I think that is the standard situation for incident responders, i.e., you don't have the evidence needed to determine scope and impact, and you don't have the authority to change the situation in your favor.

I think that is the main problem with incident detection and response, and probably computer security in general, these days.

Thanks again to Bill for the book, and be sure to check it out at Amazon.com.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Response for Daily Dave

08.29 No comments

Recently on the Daily Dave mailing list, Dave Aitel posted the following:

...The other thing that keeps coming up is memory forensics. You can do a lot with it today to find trojan .sys's that hackers are using - but it has a low ceiling I think. Most rootkits "hide processes", or "hide sockets". But it's an insane thing to do in the kernel. If you're in the kernel, why do you need a process at all? For the GUI? What are we writing here, MFC trojans? There's not a ton of entropy in the kernel, but there's enough that the next generation of rootkits is going to be able to avoid memory forensics as a problem they even have to think about. The gradient here is against memory forensics tools - they have to do a ton of work to counteract every tiny thing a rootkit writer does.

With exploits it's similar. Conducting memory forensics on userspace in order to find traces of CANVAS shellcode is a losing game in even the medium run. Anything thorough enough to catch shellcode is going to have too many false positives to be useful. Doesn't mean there isn't work to be done here, but it's not a game changer.

Since I'm not 31337 to get my post through Dave's moderation, I'll just publish my reply here:

Dave and everyone,

I'm not the guy to defend memory forensics at the level of an Aaron Walters, but I can talk about the general approach. Dave, I think you're applying the same tunnel vision to this issue that you apply to so-called intrusion detection systems. (We talked about this a few years ago, maybe at lunch at Black Hat?)

Yes, you can get your exploit (and probably your C2) by most detection mechanisms (which means you can bypass the "prevention" mechanism too). However, are you going to be able to hide your presence on the system and network -- perfectly, continuously, perpetually? (Or at least as long as it takes to accomplish your mission?) The answer is no, and this is how professional defenders deal with this problem on operational networks.

Memory forensics is the same. At some point the intruder is likely to take some action that reveals his presence. If the proper instrumentation and retention systems are deployed, once you know what to look for you can find the intruder. I call this retrospective security analysis, and it's the only approach that's ever worked against the most advanced threats, analog or digital. [1] The better your visibility, threat intelligence, and security staff resources,
the smaller the exposure window (compromise -> adversary mission completion). Keeping the window small is the best we can do; keeping it closed is impossible against advanced intruders.

Convincing developers and asset owners to support visibility remains a problem though.

Sincerely,

Richard

[1] http://taosecurity.blogspot.com/2009/02/black-hat-briefings-justify-supporting.html

I encounter Dave's attitude fairly often. What do you think?

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Cheap IT Is Ultimately Expensive

17.53 china No comments

I'm positive many of you are familiar with the idea that there are benefits to detecting software security defects early.

[Image reference: Software Security Engineering: A Guide for Project Managers.]

In other words, it is ultimately cheaper to design, code, sell, and support a more secure software product than a more insecure software product. Achieving this goal requires recognizing this advantage, investing in developers and processes that work, and dealing with exceptions (defects) as soon as possible through detection and response capabilities, even including customer-facing organizations (like PSIRTs).

I'm not aware of any studies supporting the following assertion, but I would be interested in feedback if you know any. I think it should be obvious that it's also cheaper to design, build, run, and support more secure computing assets than more insecure computing assets. In other words:

It is not cheaper to run legacy platforms, operating systems, and applications because "updates break things."

It is not cheaper to delay patching because of "business impact."

It is not cheaper to leave compromised systems operating within the enterprise because of the "productivity hit" taken when a system must be interrupted to enable security analysis.

It is not cheaper to try to manually identify and remove individual elements of malware and other persistence mechanisms, rather than rebuild from the ground up (and apply proper updates and configuration improvements to resist future compromise).

It is not cheaper to watch intellectual property escape the enterprise in order to prove that intruders are serious about stealing an organization's data.

Security doesn't make money; security is a loss prevention exercise. It's tough to justify security spending. However -- and these are the killers:

It's easy to show cost savings when experienced, professional system administrators are replaced by outsourced providers who are the lowest bidders.

It's easy to show the financial benefit of continuous availability of a revenue-producing system, or, conversely, easy to show the financial cost of downtime of a revenue-producing system.

Unfortunately, being seduced by those arguments ignores intrusion debt. One day the intrusion debt of poorly-run systems will be claimed by the intruders already inside the enterprise or those who are unleashed like an earthquake. Worse for you and me, the costs of dealing with the disaster are likely to be borne by the security team!

I thought of this vicious cycle when reading about The Sichuan earthquake in last week's Economist magazine:

In the days after the earthquake, senior officials vowed to investigate whether shoddy construction was to blame for the destruction of more than 7,000 classrooms in the disaster. But the issue was soon played down...

Mr Ai [investigating the disaster] says the refusal of central leaders to admit policy failures has exacerbated parents’ frustration. In the 1990s, he says, shoddy school buildings were erected across China because of the government’s drive to provide enough classrooms for all children to undergo nine years of compulsory education. Building costs were supposed to be shared by central and local authorities, but the latter often failed to chip in. This led to quality problems.

Ultimate, security is an IT problem, not a "security" problem. The faster asset owners realize this and be held responsible for the security of their systems, the less intrusion debt will mount and the greater the chance that enterprise assets will survive digital earthquakes. Cheap IT is ultimately expensive -- more expensive than proper investment in IT in the first place.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Check Out Hakin9

17.29 hakin9 No comments

I recently received copies of the last three issues of Hakin9 magazine. There are many good articles being published these days. One of my favorites appears in the 3/2009 issue, titled Automating Malware Analysis, by Tyler Hudak. Tyler is our team's reverse engineer and he authors the The Security Shoggoth blog. Check out the magazine!

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Harlan Carvey on Talk Forensics

17.16 No comments

Earlier today I listed to the Talk Forensics podcast featuring Harlan Carvey. I thought it was interesting to hear a forensics expert discuss the sorts of cases he has been working. Harlan mentioned how he witnessed intruders integrate obfuscation techniques into their SQL injection attacks. These techniques successfully achieved their goals while introducing a secondary effect: their anti-forensic nature complicated analysis. Harlan mentioned how previously one could search Web server logs for SQL DECLARE statements, but after obfuscation was introduced the analyst had to be more diligent.

Harlan also mentioned that TaoSecurity Blog helped inspire him to start his Windows Incident Response blog, which is probably the best blog on the subject. Thanks Harlan! Also, I'm looking forward to Harlan's second edition of Windows Forensic Analysis. If you check the link you'll see that Syngress has introduced a new cover scheme, their first in probably 10 years. Finally, Harlan and I will be speaking at the SANS WhatWorks Summit in Forensics and Incident Response 2009, which will be the best collection of IR practitioners anywhere. One of my team, Ken Bradley, will also be speaking there.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

The Real Deal on Kylin

15.49 No comments

If you want the real deal on Kylin, the best public discussion is probably taking place at the Dark Visitor Blog. As you might expect of a blog that's run by people who actually speak Chinese and follow that country's scene, the story there is more believable than the sensationalism posted elsewhere.

I downloaded and tried installing KYLIN-2.1-1A.iso but didn't get far. It seems far newer versions are available if you know where to look.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

PSIRT Equals Getting Serious About Product Security

15.15 psirt No comments

Last fall I wrote Tips for PSIRTs, pointing to a new CERT document giving advice for Product Security Incident Response Teams. Today I read Adobe shifts to Microsoft patching process, incident response plan by Robert Westervelt. The company maintains an Adobe Secure Software Engineering Team and an Adobe Product Security Incident Response Team. All of this is a sign that Adobe is getting serious about product security. It mirrors Microsoft's evolution, and I am glad to see it happening.

I'd like to be able to do a search for "Oracle PSIRT" or "Apple PSIRT" and get real results. The Google Online Security Blog isn't a real PSIRT, either. Just as you should have a CIRT if you use computers, you should have a PSIRT if you sell software.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

24th Air Force to be Headquartered at Lackland AFB

08.56 afcert No comments

Congratulations to Lackland AFB in San Antonio, Texas for being chosen to host the headquarters for 24th Air Force, a "cyber numbered Air Force." Lackland is home to the AF ISR Agency (previously AIA), the AF Information Operations Center (previously AFIWC), and the 33rd Network Warfare Squadron (previously the 33 IOS, and before that the AFCERT).

It's been six years since I visited the place, but I think it's a great choice for the 24th.

Richard Bejtlich is teaching new classes in Las Vegas in 2009. Regular Las Vegas registration ends 1 July.

Host Protection: Working with Microsoft's Firewall

09.30 ICF;Cygwin;Microsoft's Firewall No comments

Both network and host protection are recommended. Each OS has native firewall host protection:

OpenBSD: pf

FreeBSD: pfsense

Fedora Cora: iptables with SELinux

Windows XP,2003,2008,Vista,7 : Windows Firewall (ICF)

Microsoft's native firewall on XP SP3 can be told to log all incoming and outgoing packets up to a maximum log size of 32676 bytes(2^15). It will turn over twice before rewriting the old log file name. A full examination of the Firewall's configuration is beyond the scope of this post. A regedt32 query of StandardProfiles and DomainProfiles for all Control Sets for all globally open ports and authorized applications is recommended as is a manual exploration of the appropriate regedt32 keys. (Netsh commands are available for all Firewalled Windows. Please see http://support.microsoft.com/kb/947709 . Powershell can also be used to configure Microsoft's Firewall. ):

regquery HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

A sample partial result would be:

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

139:TCP REG_SZ 139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004

445:TCP REG_SZ 445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005

137:UDP REG_SZ 137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001

138:UDP REG_SZ 138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002

53:UDP REG_SZ 53:UDP:LocalSubNet:Enabled:DNS-UDP

53:TCP REG_SZ 53:TCP:LocalSubNet:Enabled:DNS

500:UDP REG_SZ 500:UDP:*:Enabled:@xpsp2res.dll,-22017

The pfirewall.log gives a considerable amount of information as such:

more pfirewall.log

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2009-04-23 10:24:55 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:56 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 138 138 202 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 78 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

....

Using Cygwin's Bash client and gawk, a list of src and dst ports can be obtained:

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $7}' | sort -nr | uniq -c | sort -nr | more

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $8}' | sort -nr | uniq -c | sort -nr | more

Gawk's conditional logic coupled with pcregrep quick searching helps us print the frequency of a destination IP and accompanying port(s) for a specified source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | sort -nr | more

16138 192.168.0.1:53

902 192.168.0.1:80

446 74.125.242.24:80

359 65.214.57.165:80

304 216.73.87.115:80

272 85.13.200.108:110

247 70.32.92.85:80

240 216.73.87.152:80

215 75.101.163.8:80

208 68.142.93.133:80

203 74.125.127.191:80

201 128.111.41.37:80

....

Now we choose to sort by the frequency of one specific dst port for each dst IP from the specified (local) source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':443' | sort -nr

113 74.125.53.147:443

92 74.125.53.83:443

78 208.235.248.150:443

50 208.75.76.32:443

46 74.125.127.103:443

30 74.125.53.97:443

24 74.125.127.120:443

23 65.55.157.60:443

22 96.6.248.124:443

21 74.125.53.99:443

...

For example, I was surprised to find all the foreign addresses that my local computer asked NBNS queries of:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':137' | sort -nr

42 192.168.0.4:137

39 192.168.0.6:137

36 192.168.0.2:137

16 192.168.0.9:137

15 206.51.224.187:137

14 208.117.252.85:137

14 192.168.0.1:137

13 206.72.124.93:137

11 74.125.103.33:137

10 64.94.107.20:137

10 64.236.79.54:137

10 206.191.161.8:137

...

The dates and times of those queries could be found with:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $1 ":" $4 ":" $6 ":" $8}' | pcregrep ':137' | sort -nr | more

2009-05-14:UDP:192.168.0.4:137

2009-05-06:UDP:75.52.124.131:137

2009-05-06:UDP:74.125.103.28:137

2009-05-06:UDP:69.64.6.21:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:65.55.52.84:137

2009-05-06:UDP:65.55.52.148:137

2009-05-06:UDP:65.55.185.61:137

2009-05-06:UDP:65.55.185.29:137

2009-05-06:UDP:65.55.184.189:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:64.94.107.16:137

2009-05-06:UDP:64.236.115.52:137

2009-05-06:UDP:4.71.104.187:137

....

These two commands are also recommended:

C:\WINDOWS\system32\drivers\etc>net config server

C:\WINDOWS\system32\drivers\etc>net config workstation

Bash 4.0,awk,geoiplookup and pcregrep are fast

20.30 Bash 4.0;awk;geoiplookup;pcregrep; No comments

Bash 4.0,awk,geoiplookup and pcregrep make a powerfully fast search team. Here I find out how many sockets pairs are in my Snort dump:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | wc -l

372

Then I find out how many uniqe SIPs are in those socket pairs:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | uniq | sort -nr | wc -l

226

Then I find my top ten Source IP Addresses:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | sort | uniq -c | sort -nr | head -n 10

62 218.103.62.150

15 222.215.230.49

14 221.195.73.68

11 121.15.245.215

10 119.161.130.75

8 209.85.163.126

8 125.65.165.139

7 66.35.46.195

7 209.85.201.125

6 64.106.128.150

....

Then I determine what source ports my top SIP (foreign address) has initiated connections to:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep 218.103.62.150 | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort -n | uniq

113

160

1433

1434

2967

5554

6429

7212

12712

16896

17337

17681

17919

18448

18487

18488

18649

18932

19899

33436

38507

Next I find what are the top source ports for my top ten SIPs:

bash-4.0# for i in `cat temp.txt`; do echo $i && snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep $i | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort | uniq -c | sort -nr; done

218.103.62.150

3 6429

3 5554

3 38507

3 33436

3 2967

3 19899

3 18932

3 18649

3 18488

3 18487

3 18448

3 17919

3 17681

3 17337

3 16896

3 160

3 1434

3 1433

3 12712

3 113

2 7212

222.215.230.49

6 7212

6 3128

3 8000

221.195.73.68

7 8000

7 7212

121.15.245.215

7 3128

4 8000

119.161.130.75

10 2967

209.85.163.126

8 33137

125.65.165.139

4 8000

4 3128

66.35.46.195

7 33436

209.85.201.125

3 18205

3 18184

1 18077

64.106.128.150

6 33442

Last, I retrieve those top ten SIP city locations:

bash-4.0# for i in `cat temp.txt`; do echo $i `snort -qdevX -r May12085154PDT2009.1242143514 | geoiplookup $i -f /usr/local/share/GeoIP/GeoLiteCity.dat` ;done

218.103.62.150 GeoIP City Edition, Rev 1: HK, 00, Kowloon, (null), 22.316700, 114.183296, 0, 0

222.215.230.49 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

221.195.73.68 GeoIP City Edition, Rev 1: CN, 10, Hebei, (null), 39.889702, 115.275002, 0, 0

121.15.245.215 GeoIP City Edition, Rev 1: CN, 30, Jiangmen, (null), 22.583300, 113.083298, 0, 0

119.161.130.75 GeoIP City Edition, Rev 1: CN, 19, Chaoyang, (null), 41.570301, 120.458603, 0, 0

209.85.163.126 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

125.65.165.139 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

66.35.46.195 GeoIP City Edition, Rev 1: US, CO, Denver, 80216, 39.785000, -104.941498, 751, 303

209.85.201.125 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

64.106.128.150 GeoIP City Edition, Rev 1: US, NJ, Hoboken, 07030, 40.745800, -74.032097, 501, 201

Understanding an attack

14.25 No comments

Snort can be run in daemon mode, with a configuration file that logs on certain alerts only. For demonstration, we can run Snort in 'packet dump' mode (-dev) for a day or so while using BPF filters for our own needs:

/usr/local/bin/snort -devX -i xl0 -L $(date "+%b%e%H%M%S%Z%Y") 'port not(domain or whois or http or https or syslog or ntp or smtp or 137 or 139)' and 'not(broadcast or icmp or igmp or arp)'

After some awkward awk statements and some ditzy KSH work, we have a list of ports others who are seeking our network seem interested in:

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort -nr | uniq -c | sort -nr

14 2967
6 8000
6 5900
6 3128
6 22
5 23
5 1434
5 12712
4 7212
4 4899
4 1433
1 8080
1 7209
1 65535
1 56017
1 3306
1 23803
1 21
1 19756
1 19696
1 1024

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort | uniq | sort -nr >> ports.txt

for i in `cat ports.txt`; do grep -w $i /usr/local/share/nmap/nmap-services;done

http-proxy 8080/tcp # Common HTTP proxy/second web server port
http-alt 8000/tcp # A common alternative http port
vnc 5900/tcp # Virtual Network Computer display
radmin 4899/tcp # Radmin (www.radmin.com) remote PC control software
mysql 3306/tcp # mySQL
squid-http 3128/tcp #
symantec-av 2967/udp # Symantec AntiVirus (rtvscan.exe)
ms-sql-m 1434/tcp # Microsoft-SQL-Monitor
ms-sql-m 1434/udp # Microsoft-SQL-Monitor
ms-sql-s 1433/tcp # Microsoft-SQL-Server
ms-sql-s 1433/udp # Microsoft-SQL-Server
kdm 1024/tcp # K Display Manager (KDE version of xdm)
telnet 23/tcp #
telnet 23/udp #
ssh 22/tcp # Secure Shell Login
ssh 22/udp # Secure Shell Login
ftp 21/tcp # File Transfer [Control]
ftp 21/udp # File Transfer [Control]

Nmap services file helps explain much here, but why the large interest in a Symantec AntiVirus port? It turns out others have noticed this recently as well and are asking for input:

http://isc.sans.org/diary.html?storyid=6319.
http://msmvps.com/blogs/harrywaldron/archive/2006/11/27/new-botnet-impacts-symantec-client-port-2967-on-unpatched-pcs.aspx
http://www.offensivecomputing.net/?q=node/403

Is this a new or mutated trojan? worm? remote exploit? Multiple addresses are interested in connecting to us on this port:

# snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | grep 2967 | sort -nr | uniq -c | sort -nr

3 218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
2 119.161.130.75:6000 -> 192.168.0.12:2967 TCP TTL:99 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.191.63.8:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.145.62.75:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.173.12.60:6000 -> 192.168.0.12:2967 TCP TTL:106 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:65419 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:42349 IpLen:20 DgmLen:40
1 222.186.26.93:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.149:6000 -> 192.168.0.12:2967 TCP TTL:102 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.148:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40

But the packet looks like a simple connection attempt to a remote port. A buffer overflow in Symantec AntiVirus port?

218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x60B40000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 69 06 55 BE DA 4B 5F F2 C0 A8 .(....i.U..K_...
0x0020: 00 0C 17 70 0B 97 60 B4 00 00 00 00 00 00 50 02 ...p..`.......P.
0x0030: 40 00 F1 34 00 00 00 00 00 00 00 00 @..4........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

05/13-12:59:50.507559 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x3C
121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x4260000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 6B 06 66 06 79 8C AE 69 C0 A8 .(....k.f.y..i..
0x0020: 00 0C 17 70 0B 97 04 26 00 00 00 00 00 00 50 02 ...p...&......P.
0x0030: 40 00 60 0B 00 00 00 00 00 00 00 00 @.`.........

A Brief Anatomy of Malware detection and some notes on using traceroute and determining 'intent'

11.29 Win32:SQLSlammer;Malware detection;Snort;Traceroute No comments

From the posts below we can begin to understand why signature identification is so important. We are looking for malware in the packet data itself since any port can be used to send malware and any IP can be spoofed or unwittingly part of a botnet or worm. The packets below are indicative of the "Win32:SQLSlammer" worm attack that has been around for a considerable time. The worm propagates itself by generating random IP addresses. Notice that the first SIP (Source IP) address is either spoofed or "router leakage" : e.g. it comes from RFC1918 "private" (non-internet IPs) subnet: 10.255.255.255. Remember that any of these IP addresses can be either (a) spoofed or (b) botnet victims or (c) unpatched SQL servers so that their ultimate location may not neccessarily tells us anything about 'intent' or 'bad actors'. Note the common signature in these 376 byte packets. The "Win32:SQLSlammer" reeked an extraordinary amount of havoc upon the internet with a very small amount of assembly code. The current Snort rules for this worm look like this:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"SQL Worm propagation attempt"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2003; rev:12;)

alert udp $HOME_NET any -> $EXTERNAL_NET 1434 (msg:"SQL Worm propagation attempt OUTBOUND"; flow:to_server; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1|"; content:"sock"; content:"send"; metadata:policy balanced-ips drop, policy security-ips drop; reference:bugtraq,5310; reference:bugtraq,5311; reference:cve,2002-0649; reference:nessus,11214; reference:url,vil.nai.com/vil/content/v_99992.htm; classtype:misc-attack; sid:2004; rev:11;)

The packets I captured are below. Note the common ASCII signature

05/11-14:33:07.744419 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

10.13.3.61:1092 -> 192.168.0.12:1434 UDP TTL:113 TOS:0x20 ID:61068 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E

0x0010: 01 94 EE 8C 00 00 71 11 8B AE 0A 0D 03 3D C0 A8 ......q......=..

0x0020: 00 0C 04 44 05 9A 01 80 63 09 04 01 01 01 01 01 ...D....c.......

0x0030: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0040: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0050: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0060: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0070: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 ................

0x0080: 01 01 01 01 01 01 01 01 01 01 01 DC C9 B0 42 EB ..............B.

0x0090: 0E 01 01 01 01 01 01 01 70 AE 42 01 70 AE 42 90 ........p.B.p.B.

0x00A0: 90 90 90 90 90 90 90 68 DC C9 B0 42 B8 01 01 01 .......h...B....

0x00B0: 01 31 C9 B1 18 50 E2 FD 35 01 01 01 05 50 89 E5 .1...P..5....P..

0x00C0: 51 68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E

0x00D0: 51 68 6F 75 6E 74 68 69 63 6B 43 68 47 65 74 54 QhounthickChGetT

0x00E0: 66 B9 6C 6C 51 68 33 32 2E 64 68 77 73 32 5F 66 f.llQh32.dhws2_f

0x00F0: B9 65 74 51 68 73 6F 63 6B 66 B9 74 6F 51 68 73 .etQhsockf.toQhs

0x0100: 65 6E 64 BE 18 10 AE 42 8D 45 D4 50 FF 16 50 8D end....B.E.P..P.

0x0110: 45 E0 50 8D 45 F0 50 FF 16 50 BE 10 10 AE 42 8B E.P.E.P..P....B.

0x0120: 1E 8B 03 3D 55 8B EC 51 74 05 BE 1C 10 AE 42 FF ...=U..Qt.....B.

0x0130: 16 FF D0 31 C9 51 51 50 81 F1 03 01 04 9B 81 F1 ...1.QQP........

0x0140: 01 01 01 01 51 8D 45 CC 50 8B 45 C0 50 FF 16 6A ....Q.E.P.E.P..j

0x0150: 11 6A 02 6A 02 FF D0 50 8D 45 C4 50 8B 45 C0 50 .j.j...P.E.P.E.P

0x0160: FF 16 89 C6 09 DB 81 F3 3C 61 D9 FF 8B 45 B4 8D ........

0x0170: 0C 40 8D 14 88 C1 E2 04 01 C2 C1 E2 08 29 C2 8D .@...........)..

0x0180: 04 90 01 D8 89 45 B4 6A 10 8D 45 B0 50 31 C9 51 .....E.j..E.P1.Q

0x0190: 66 81 F1 78 01 51 8D 45 03 50 8B 45 AC 50 FF D6 f..x.Q.E.P.E.P..

0x01A0: EB CA ..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/11-14:53:48.630387 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x1A2

202.99.11.99:1231 -> 192.168.0.12:1434 UDP TTL:110 TOS:0x80 ID:26925 IpLen:20 DgmLen:404

Len: 376

0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 80 .`.0k...[.....E.

0x0010: 01 94 69 2D 00 00 6E 11 4B 31 CA 63 0B 63 C0 A8 ..i-..n.K1.c.c..

0x0020: 00 0C 04 CF 05 9A 01 80 9A 01 04 01 01 01 01 01 ................