Tuesday, March 30, 2010

Rule release for today - March 30th, 2010

Microsoft Security Advisory (MS10-018):

Microsoft Internet Explorer contains several programming errors that may allow a remote attacker to execute code on an affected system.

Details here: http://www.snort.org/vrt/advisories/2010/03/30/vrt-rules-2010-03-30.html

Tuesday, March 23, 2010

Rule release for today - March 23rd, 2010

Apple Safari RCE (CVE-2010-0049):
Apple Safari contains a programming error that may allow a remote atttacker to execute code on an affected system. The issue presents itself when the browser fails to properly process certain HTML elements concerning RTL text.

Additionally, as a result of ongoing research, the Sourcefire VRT has added multiple rules to the specific-threats and netbios rule sets to provide coverage for emerging threats from these technologies.

Check out the changelogs here: http://www.snort.org/vrt/advisories/2010/03/23/vrt-rules-2010-03-23.html

Wednesday, March 17, 2010

Rule release for today - March 17th, 2010

A maintenance release mostly, lots of changes to rules and quite a few deletions. Two new rules added.

Check out the changes here

Tuesday, March 16, 2010

The New Disclosure Debate and the Evil Mr. Moore

So, let's pretend you are Rob, Mr. Head of IT, and that you are sitting in your office on March 9th, working on your fantasy baseball (I hear Albert Pujols is the way to go...) when one of your staff walks in and says that Microsoft has another 0-day running around. Internet Explorer 6 & 7 are vulnerable to a condition where invalid pointer that is accessed after an object is deleted. Putting on your best manager hat, you ask the hard question: "OK, what do we know?"

She tells you that because you bought into the anti-Vista hype (in her head, she's calling you moron but she doesn't say it out loud, she isn’t crazy, just proud), there isn't much that can be done currently. There were some mitigations provided, but they mainly involved Vista and Server 2003 and 2008. Now you know that your boss is going to be calling any moment and here is what you know: Something about an invalid pointer, the fact that it is "in the wild", a CVE number and "Microsoft is working on it", you probably shouldn't tell him that Vista part. The phone rings.

Let's switch to the view of the attacker. Something that was incredibly valuable has suddenly moved to a very short timeline. The moment that exploit that you paid fifty large for gets patched you're toast. You can't even trade it at this point, because that code is out there, and no one is going to pay you anything for released code that they can find themselves and easily rework. All you can do now is broaden your attacks and drop as many bots as possible so in the future you have some pivot points to launch your attacks. Maybe you'll get lucky and hit somewhere that has some interesting information. Time to bust out the mass mailer. You love irony, so your subject line is "Information on Microsoft IE 0-day, please read".

Security researchers everywhere are scrambling and the ones that understand this process are starting to share information about the attack. The race is on to get enough information out so that organizations can protect themselves. Many of these researchers are working for "free", knowing that getting their name out there on an issue like this is a great way to increase their employability going forward. Others are working for well known research organizations, Sourcefire and in this case, importantly, a little firm named McAfee. In a blog post on this on the evening of March 9th they named a site that was associated with the attack: https://notes.topix21century.com.

Now this information, for those paying attention is really important. I'm all for giving credit where good work is done, so kudos to McAfee for putting this information out. First, it provides researchers with a location where they can find the exploit. Secondly, it gives Rob something he can do. Now he can check the IP addresses associated with topix21century.com and block them at his firewall. Then he can watch his firewall logs and DNS logs for evidence that one of his hosts are trying to get to this site. Now he knows which hosts are owned and he can begin the remediation process. He still doesn't understand the attack, but he can take care of the first wave.

By the time Rob gets into work the next day someone named Moshe Ben Abu is suddenly really important. Overnight he had created a Metasploit module that generated the attack and less than 24 hours had passed from the point that the Microsoft announcement was up. (Note and additional kudos to Moshe Ben Abu: He has contributed 10 exploits to the Metasploit package in the last 3 years). Now Rob had two new things to work with. One, he had a known attack that he could use to test this detection strategy and more importantly, his hot-shot security staff could look at the Metasploit module and figure out what this detection strategy is going to be. Metasploit modules typically are very clean and even a moderately talented security person can pull the stings that are important to look for. In this case, "setAttribute('s',window)" and "#{j_object}.addBehavior('#default#userData');" look interesting. Now they have all the information they need to configure their detection systems, whatever they are, to detect the attack. This time, when the phone rings, Rob is ready.
For many, many security shops, who don't have commercial data feeds, haven't had the opportunity to find their way to numerous "back channel" IRC channels and mailing lists and don't have the budget for a multitude of "APT-KILLING" solutions this is the way (hopefully) that these two days played out. This isn't the only time this timeline occurred either. Metasploit had exploits for Microsoft's Aurora and Adobe's JBIG2, media_newplayer and utilprintf before there was a patch. Yet there was some degree of backlash against McAfee because initial reports had Mr. Abu gleaning technical details from McAfee's site to generate his exploit. As it turns out, he did the research himself based on the link above. There is also (always) grumbling when Metasploit puts out a module, even when it affects things that have long had a patch.

Unfortunately, this situation led to McAfee making the following declaration:

"McAfee Labs does not support the release of exploit code, particularly in advance of a security patch being made available. We regularly sanitize blog content to prevent providing information that might assist attackers, while at the same time providing a service to customers and the security community to help improve protection levels...Future blog posts will be subject to additional sanitization."

So here is the new debate...shops like Sourcefire and McAfee have the resources to hire some very intelligent, very talented people to do their work for them. Yet McAfee has made the decision that it will further limit information from their blog so that exploits cannot be developed. This is, unfortunately, purely a PR move. The people who use these exploits have no need for the Metasploit module. This isn't to say they wouldn't use that code if they had it available, using widely published code instead of custom built code obfuscates who created the exploit. But if it weren't available they would still have access to the code either through back channel sharing or their own reverse engineering. Let's not pretend these guys don't have talent. This decision does nothing but save face for McAfee and reduce the information that security shops have to work with. I guess that's a business decision; hopefully they just said that to make people go away and they'll do what they want going forward.

But research shops aren't the only people who have to make this decision. The software vendor also has to figure out what information to share as they go forward. While in Mattland the vendor would share any exploit code they had so that mitigations can be developed and tested, I think we can all agree that this will never happen. So what are their options? Brace yourself, because I'm going to say something nice about Microsoft AND Adobe.

Microsoft is the gold standard in vendor response. First, there is the MAPP program, where security vendors receive information on upcoming patches and 0-day threats directly from Microsoft with technical details of the attack so vendors can publish protection as quickly as possible. Now, this has the unfortunate cost of being bound by an NDA from sharing that information or publishing detection in an easily parseable manner, but it gets protection out quickly and accurately. Then there are the tools that Microsoft has developed. Sometime on the 10th they released sufficient information that registry changes could be made (and forced out to end users) that would eliminate the exploit path in the software. This essentially acted as a patch that had to be manually applied and, while a vast majority of home users really don't get any use out of this, IT shops got a solution they could push down through their management system. Also, Microsoft has built the "Fix it" tool, an easy one-button click for end users to apply the mitigation to their boxes. IT shops love this because they can send an email out to those folks who are travelling or working from home to go and push this button. As a bonus, there is a button to back out this fix, if it is found that the fix impacts business critical systems. This system also is MUCH easier for home users, so those who know that this is available have an easy, safe and verified way to apply the fix. Finally, Microsoft has an automated patch system to push patches by default to customers who are Internet connected. This one step may be the most important change Microsoft has made to their response capability.

Are they perfect? No, as in: Where the hell is my patch?

Adobe is still recovering from suddenly coming into the spotlight of the research world. To be fair, that came in a flurry after the JBIG mess, but Adobe has made vast improvements in their response capability. Brad Arkin and his team should be proud of their efforts, and I'm looking forward to more of the same. First, they've improved their working relationship with the people who want to help them: security vendors and vulnerability reporters. They put mitigation information into their advisories so that customers can build detection and response systems in advance of a patch. Their discovery-to-patch time is significantly reduced from earlier in 2009. They've also added the JavaScript Blocklisting which, for functions that aren't part of the core of JavaScript, is an excellent addition on par with Microsoft's registry configuration capability. They also have an improving reputation among security researcher as a shop that is responsive and organized in handling inbound disclosures. Finally they are currently beta testing an auto-update feature that will push updates to their clients automatically.

These two companies have demonstrated they are willing to face the security issue head on. They have dedicated teams, they get information to their customers and they have or will put into place an auto-patching system. They both have a good reputation amongst researchers that chose to disclose vulnerabilities they discover directly to vendors. Microsoft is clearly best-of-breed and Adobe is catching up rapidly. It may be because they have no choice, or maybe they are just responsible corporate citizens. Both are getting a ton of attention from researchers. This isn't due to their code is any worse than anyone else's, but because they are nearly ubiquitous on business systems.

In comparison to those two companies, if you want to see someone who is working hard at doing it completely wrong, lets look at Apple. Now, on the good side, they do have an automated patch system. But they haven't exactly kept up in the secure architecture realm. While Vista introduced default ASLR to improve the effectiveness of their DEP stack protection mechanisms, Apple’s address stack is still not fully randomized. This, and other 'features', led Charlie Miller, uber apple hacker, to say "Safari on the Mac is easier to exploit. The things that Windows does to make it harder (for an exploit to work), Macs don’t do. Hacking into Macs is so much easier. You don’t have to jump through hoops and deal with all the anti-exploit mitigations you’d find in Windows."

They also have a horrible reputation amongst security researchers. On more than one occasion I've heard "**** them, I ain't giving them ****". This attitude apparently got the attention of Apple to the point that they had some guy running around last year's Black Hat/DEFCON conferences trying to convince people that Apple wanted to work with vulnerability researchers. When he caught up to me in the bar he said "I just need you to know that we really care about researchers". My response: "Well, that message isn't exactly coming across loud and clear". Then he tried to hook me up with a free copy of iLife. Um, thanks.

They do patch regularly (and somewhat randomly) but there are some concerns with some lag time on important security bugs. During the Kaminsky frenzy of '08, for example, they patched well after Microsoft delivered their update. Microsoft published July 8th and Apple didn't patch until August 1st. When they did patch, they failed to make any indication about the criticality of the patch, and left it to end users to figure out if it was important that "BIND is susceptible to DNS cache poisoning and may return forged information". In doing a quick check, they still do not provide any information about mitigating factors or guidance to IT shops to evaluate the severity of the vulnerability. This is fine for home users, but not particularly useful to corporate security shops.

Apple is coasting on the fact that their install base isn't broad enough to bring the sort of attention that Microsoft and Adobe face. This is both good for Apple, because they typically don't have to directly face a vulnerability (although they do have a substantial open-source code base they have to monitor, WebKit can be pretty hairy, apparently) and bad for their customers. Customers are given a false sense of security, particularly those who would face a targeted attack. With Apple lagging behind in underlying security architecture and Charlie Miller heading to CanSec with "a few Safari zero-day flaws in his back pocket.” there is a threat there. And because Apple has isolated much of the security community they aren't benefitting from the free work that researchers provide for Adobe and Microsoft and many discovered bugs go unreported.

OK, so vendors don't quite give enough information during that critical time between disclosure and patching. That leaves the Evil Mr. Moore, head of the Metasploit project, loved by penetration testers and hated by pure white hats. But from an ops point of view, he is the equivalent of the Director of the Internet Intelligence Agency. He reports to us, the users of the Internet with the most accurate information possible: Exploit code. There is no other way to look at it; the best way to build and test mitigations is by directly looking at what the threat is. Not guessing at what "iepeers.dll" does or what a "JBIG2" is. It is sitting right in front of you, all the information you could want. For many organizations, he is the best data feed they have. So to Evil Mr. Moore, and all of the secret agents working for the IIA, thank you for your service.

And a parting message to McAfee -- Don't stop, your customers, and the research community as a whole, need your expertise beyond just your rule set.

Wednesday, March 10, 2010

Rule release for today - March 10th, 2010

Microsoft Internet Explorer (2010-0806):
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to execute code on an affected system.

Check it here

Oh, and the rule is a shared object rule, so the changelog won't actually show it. If you use PulledPork for your rule updates though, you should see it in the changes when you update.

Tuesday, March 9, 2010

March 2010 Vulnerability Report

This month, Alain discusses the two patches from Microsoft, 0day vulnerabilities in Apache, Opera, Internet Explorer and finishes with VRT activity in March.

Rule release for today - March 9th, 2010

Microsoft Security Advisory (MS10-016):
Microsoft Windows Movie Maker contains a programming error that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS10-017):
Microsoft Excel contains several programming errors that may allow a remote attacker to execute code on an affected system.

Apache HTTPD mod_isapi RCE (2010-0425):
The mod_isapi module for the Apache HTTPD server on Microsoft Windows systems contains a programming error that may allow a remote attacker to execute code on an affected system.

Opera Web Browser Integer Overflow:
The Opera web browser contains a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs when the browser incorrectly parses a specially crafted Content-Length header in a server response.

Changelogs are available from the usual place

APT: Should your panties be in a bunch, and how do you un-bunch them?

There is no more predictable group of people than marketers. Once a term reaches a certain tipping point, they grab onto it for dear life and choke it until it means nothing. Apparently, the Advanced Persistent Threat (APT) hit that point somewhere around December. Despite the term being used by the defense industrial base for years, it wasn’t until this year that firms really started pounding the “Come to us my children, only we can save you from death by APT” drum.

This isn't to say that APT isn't real; we’ll get to that in a moment. But it dilutes and distorts the term, changing it from a euphemism for a certain group of attackers who display an uncharacteristic amount of backing, talent and motivation to a “thing” that CEOs have heard of and are now looking for the “Firewall blocks APT” checkbox. This is a disservice to those who face APT-level threats and also moves it into the “whatever” category for a lot of operational folks.

First, what is APT? I’ve been told, if I remember correctly, that initially the term was used to describe specific groups associated with nation-states that aggressively and successfully penetrated critical infrastructure networks and established well developed, multi-level footholds in those networks.  But now it increasingly means "bad thing from the Internet".

The co-opting of APT by the marketing folks have led to the point that people are classifying any malware, rootkit or bot as "APT".  Zeus is not APT, Aurora is not APT.  APT is a level of threat, a description of the sophistication, patience and talent behind an attack.  The attacks are targeted, typically involving both an exploit and social engineering.  Emails containing PDF exploits don't get spammed to everyone in the organization, they are sent to key individuals with convincing messages.  Bots aren't your commercial, off-the-shelf variety.  They are custom built, hard to detect and typically have multiple instances and functions so an initial remediation sweep will appear successful but miss the deeper, quieter processes.

The attackers monitor the state and success of their attacks and channels.  As one channel goes down, they activate another.  If a node containing valuable data is cleaned, they'll reinfect it from another computer.  They know what they are doing.

Or, to use my own, barbaric way of describing things:

“APT: There are people smarter than you, they have more resources than you, and they are coming for you. Good luck with that."

Now, I’ll tell you a secret about APT. There isn’t a silver bullet product that is going to save you. The people behind this level of attacks have MONEY and TALENT and EXPERIENCE. I would be surprised if there wasn’t a stack of IDS boxes, a bunch of AV solutions, a pile of WAFs, firewalls and anomaly detection gear sitting in a server room with a whole bunch of bad stuff going through it. Each time detection occurs, the attack is modified to evade detection. The root kits are self morphing and uses established protocols to avoid detection.  In short, they know the way you work and they abuse that knowledge.

Now you might be saying, depending on where you work: “I’m not important enough to worry about APT level threats”. If you say that, then one of two things are in play. One, you are not aware of your company’s interactions on the global market and the level of interest players in the world may have in your data. If you are a supplier to the Government they might be interested in a sudden increase in orders of a certain product. If you are a law firm, they might be interested in your research on another company or how you might defend a client who is suing or being sued by a certain company. Maybe an email sourced from your server would not arouse suspicion and would quickly be opened by a CEO, CTO, CSO or any employee at all, to be honest, from another firm. So think about where you are in the world and who you interact with.

So you’ve done that and you’ve decided you’re in the clear: Nothing to worry about in APT land. This is true…and then again it isn’t. One of the common methodologies that attackers use to obscure their activities is to bounce around, deliver attacks and pull data from different IP addresses. While they may not be interested in your data, they are interested in your network. Just be aware that you might make an excellent jumping-off point for an attack. So if you’re interested in being a good Internet citizen pay attention.

Inline TLDR: These people want to beat you. They can beat you. You are a target.

The question you should be asking is “Well what the hell do I do then, smart guy?” Well, glad you asked. First of all, meet the minimum. Start with patch management, which I can sum up, from a security perspective like this: PATCH IMMEDIATELY (hey, by the way its Microsoft Tuesday today, go patch, I’ll wait…) when they come out. I know, I know, you have to do x, y and z testing. That’s great. Let me tell you a story:

Back before Sourcefire was in the MAPP program, we had to do that bad guy way of understanding what the patches addressed. This means we’d take the old DLL and compare it to the new DLL. This would tell us what changes Microsoft made and allow us to reverse engineer from that point to understand the vulnerability.

I'll admit...I suck at this, seriously. It would generally take me about a day to figure out was going on, and I suspect that my bugs were easier. The hard ones, and the ones that looked like they would go live as exploits, went to Lurene Grenier (we call her Lulu, she loves that). The mean time for her to go from the diff to a POC was about an hour. Now, to go from POC to exploit is a different matter dependent on the nature of the bug and the ability of the attacker to pass arbitrary data before and during the exploit of the vulnerability. But this should give you an idea of the time frame you are working with.

As another example, when the JBIG2 bug hit earlier this past year, our fuzzer hit the vuln in about 10 minutes. From there it was not difficult (in this case) to move to an exploit.  (And don't think we only fuzz against emerging 0-day.  As a throw-away metric we average one DOS-level crash per day and on review one or two of these per month move to exploitable status).

Now..Lulu is scary talented. But she isn’t the only one in the universe that has the ability and drive to do what she does. You should know a lot of the names of other folks who do (check @pusscat and @kpyke’s follow list if you don’t’) but I guarantee there are a bunch that you and I have never heard of. So this is the level of talent you are facing: disclosure to exploit in less than a day.

Next, understand your network and ensure it behaves in a highly deterministic fashion. Work with your network engineering folks to understand the configuration of the network, where the VLANs are, how the IP space is allocated and what security features are in place in the network configurations. Consolidate your logs, network flow data and monitoring into a SIM and build systems to detect when something becomes different.

Did I say patch? For God’s sake, patch.

OK...so you've begun to meet the minimum. Now, time to move up to AA Ball. To some extent this involves taking steps towards Mattland.  We need to gain control of the network and how it is used.  Get some aggressive, scary policies in place. Threaten to (metaphorically) eat the children of people who play Facebook apps on your network, (metaphorically) melt the faces of all those who dare to surf porn or play flash game and (metaphorically) drop the hammer of God on anyone who dares to bring a USB key or software from outside. Then put systems in place to watch for this and make scary visits to those who would defy you. In all seriousness, put in policy and procedures and the capability to enforce them. I’m sure you have a CISSP tucked away somewhere who will help you.

Next, get some intelligence feeds together. To start with, get an RSS new reader and a twitter account. Hit every security site you’ve ever heard of and evaluate it for content. Here is an off-the-top-of-my-head list:


Add to this list and then check it. Every day, twice a day. Now…twitter. As dumb as it sounds, Twitter is one of the best Intel tools I’ve found. People like to chat about new things they’ve found and things they are working on. Here is a basic list of people to watch:


Every day, twice a day.

OK…time to go big time. What do you need to really push the envelope on security? You need a team. You need a serious, serious team. There isn’t one person in the universe that can stand alone on this. You need a group of high-energy, high-motivation people that love what they do. First, sit down and think about the kind of systems you have. You need a group of people who, together, are experts on those systems. Then list the kinds of protocols you have. Your group needs to collectively be experts on those protocols. List the security systems you have in place. Your group needs to be experts on those systems and how to customize them rapidly (remember there is no silver bullet product). Also, your group needs to be conversant in Ruby, Python, PERL and C…the languages of exploits. Finally, you need a very, very bad person.

It is hard to overstate the need for someone who hates rules, restrictions and limitations. You need to find someone who your HR department is going to hate. You need to find someone who reminds you of you in your younger more carefree days. You need to find someone you trust completely. Then you are going to put them in a cube and NOT BOTHER THEM. Throw them problems, tasks and direction but get out of their way and let them do their thing. Then let them pick apart every security decision and implementation you have. Ask them how they would get around it and how to mitigate that. Finally, when they tell you something is bad…believe them.

Finally, understand that in all likelihood, you will fail to keep the attacker out. Be it 0-day, mis-configured servers or some special guy in finance who JUST DOESN'T GET IT…someone most likely will get a foothold. So balance your time between attack detection and detection of rootkits and bots. Maintain a high degree of suspicion.

So, TL;DR (which may, in itself be TL;DR):

  1. APT is becoming a marketing term
  2. Your APT definition should be:
    "APT: There are people smarter than you, they have more resources than you, and they are coming for you. Good luck with that.”
  3. Despite your place in the world, an APT level threat may affect you.
  4. Nail down the basics: 
    1. Patch immediately
    2. Understand your environment
  5. Then get better: 
    1. Build aggressive policies
    2. Be able to enforce those policies
    3. Generate intelligence and monitor that intelligence
  6. Go big, build your team.  Then Venn diagram of your team should include: 
    1. OS experts
    2. Application Experts
    3. Protocol Experts
    4. Security Systems Experts
    5. Ruby/PERL/Python/C coders
    6. At least one very, very bad person
  7. Balance detection between attack detection and successful intrusion detection.
  8. Marketing doesn't know what the hell it is talking about - do your research.
  9. Remember, technology won’t save you. People will.

As always, comments, corrections and snide remarks are welcome below.

Thursday, March 4, 2010

Rule release for today - March 4th, 2010

We added multiple rules to the specific-threats, spyware-put, web-client, backdoor, and web-misc rule sets as well as making a whole lot of modifications to existing rules. Just a bit of a clean up.

Details here: http://www.snort.org/vrt/advisories/2010/03/04/vrt-rules-2010-03-04.html

Tuesday, March 2, 2010

The Sudden Reappearance of MS03-039

Last Friday, I got into the office and pulled up my email. Among other things, there was an escalation from Sourcefire's support group, where the customer had alerts on SIDs 15512 and 3397, and they wanted an official opinion from Sourcefire as to whether the alerts they were seeing constituted false positives. Opening up the supplied packet captures, the DCERPC payload in question looked odd at first glance - the string "|CC CC CC CC|" appeared several times in the payload, as did the string "|FF FF FF FF|". Given that 0xCC is the x86 instruction for "INT 3", which causes a debugger trap, and that the value 0xFFFFFFFF is often associated with either buffer or integer overflows, I was immediately suspicious. I also wondered about the fact that the string "MEOW" appeared in the packets - it's an odd string to have in normal traffic, that's for sure.

Unfortunately, the remainder of the payloads did not contain obvious shellcode - no NOP sleds, etc. - so I couldn't just immediately declare these to be real attacks. Since the rules in question exploited MS03-039 and MS03-026, and I didn't want to unduly alarm the customer - I figured, the chances of such old vulnerabilities being actively exploited seemed fairly low - I sent the PCAPs to the remainder of the team, to get an additional set of eyes on them. Within minutes, one of my fellow analysts recognized the payload as something she'd seen previously - based on the string "MEOW" that I had wondered about. I reported back to the customer that this was a live exploit attempt, and that they should immediately begin checking all of the machines in question for infection - particularly since the source IP addresses happened to be within their corporate network.

With that done, I closed the escalation, chuckled to myself about such an old vulnerability remaining unpatched, and put it out of mind; I figured it would be an isolated incident, again given the age of the vulnerability in question.

Much to my surprise, however, another customer escalation came in this afternoon, reporting "hundreds" of alerts on MS03-039-related rules. Opening up their supplied PCAP, I immediately saw all of the same characteristics - strings of "MEOW", "|CC CC CC CC|" and "|FF FF FF FF|". Again, the source host was coming from inside their corporate network, which meant that they had a live attack going on from the inside - seriously bad news.

That said, if you're running Snort for a network where you're not 100% confident that all of your hosts have been patched at least past the end of 2003, I would suggest that you consider enabling the following SIDs, to ensure you're protected from these sorts of attacks:
  • 2252
  • 3158
  • 3159
  • 3397
  • 3398
  • 3409
  • 9422
  • 9423
  • 11073
  • 11074
  • 15512
  • 15513
That, and review your company's patching policy if possible. ;-)