So, start thinking about those blog posts, how-tos, patches, documentation updates, new features and or any other OSSEC-fu you can contribute. Feel free to get creative. Maybe the OSSEC logo could be morphed into something cool. Everyone has a talent.

Sharing made OSSEC what it is today and I hope this can be the biggest year yet!

• This is just all kinds of awesome. It’s not that I am with the bad guys, but when they get this creative you have to give them credit. A bunch of criminals used 3D printers to print out ATM Skimmers. This is just another way that the face of information security is changing.
• Also on the ATM theme, here’s a method to steal ATM PIN numbers using a thermal camera. I am not entirely sure, but given how the cameras are used in house energy audits, my guess is that this can be done from some distance.
• Just for fun, check out this security architecture fail. Can you spot the defect?
• RSA blogged about the recent breach that they experienced. Shortly after they announced the attack, I also blogged about the tendency to call attacks APTs. I fear that describing an attack as an APT is simply another way of failing to take responsibility. It is understandable that they had a breach, but the truth is that attachments exploiting 0-day holes in client software is not particularly advanced today. I have dealt with several 0-day pieces of malware. RSA had layers of security that failed. Again, it’s understandable that they failed–securing everything is hard–but use it an an opportunity to examine the individual layers that led to the breach. There was no magic here. This is  a standard attack method these days.
• Did you know that OSSEC can audit your system? It’s better to know you have vulnerabilities before they are exploited. Daniel Cid explains how to detect outdated web applications with OSSEC. Good stuff.

That’s it for today. Have a great weekend!

• Dave Hoelzer from SANS provides some very useful “AuditCasts.” These are short, instructional videos on various topics. This week, Dave talked about the benefits of split DNS. One implementation of split DNS that Dave did not mention specifically is to not have the internal DNS servers forward requests at all; rather, you may rely on your proxy to do the queries for you. This can be helpful if a malware infection is trying to phone home. If they are relying on DNS for the call-back, it might fail.
• What should you do after compromising a system (on which you had permission, of course)? These Linux and Windows community docs provide some good tips. I wouldn’t recommend running these commands or tools without knowing exactly what the outcome will be. They could be dangerous.
• The Morto RDP worm takes advantage of poorly chosen passwords. Microsoft has a pretty good write-up of the behavior of the worm. OSSEC should detect the invalid logon attempts. I have some ideas on how a few rules could detect this general class of infection.
• Barracuda, the company that has a pretty decent anti-spam gateway, offers their RBL for free. I have been using the Spamhaus Zen RBL for quite some time and decided to give this a try. Putting it before the Spamhaus list, the result has been pretty good. Spamhaus now rejects only 3-5 messages a day since the BRBL is blocking lots of spam that Spamhaus would have caught. So far, I know of no false-positives. Using both seems to work pretty well.
• Lenny Zeltser reminds us that security is best designed with failure in mind. Security controls will fail, but that doesn’t necessarily have to lead to an information breach. A good security design plans on these controls failing with the information remaining safe.

That’s it for today. Have a great weekend!

• The Shadowserver foundation is comprised of a group of volunteer security professionals who gather information about Internet-based crime. One of the more interesting projects is a compilation of how various antivirus vendors fare against 0-day threats. How does your vendor hold up?
• Logs are not much good if you can’t trust them. Maintaining log integrity is vital to a robust incident response process. Here is a great article on how to protect your logs from tampering. It’s not fool-proof, but it can go a long way.
• Information security is a profession that necessitates a solid ethical foundation. Security professionals are often trusted with the most sensitive of data. This presentation, from the Honeynet Project, tackles some of the more thorny situations about performing ethical research.
• Looking for a really awesome way to store and compare your Cisco configs? Rancid, or the Really Awesome New Cisco confIg Differ, may be just the tool for you. It stores Cisco configs in CVS and can let you know something changed. By the way, OSSEC is also capable of something very similar.
• Are you looking to use virtualization in your PCI program? It can be done, but like most technologies, has to be approached carefully. This guide will show you some of the things that need to be considered.

That’s it for today. Have a great weekend!

• Mitigating the Apache Range Header Attack. This is a pretty good overview of several ways you can protect yourself for little to no cost. Also, see my post, Detecting the Apache Range Header DoS Attack with OSSEC.
• Automatically encrypt all inbound email part I and part II. Even if you have full-disk encryption, it does not protect you if someone can access your account. This method allows you to keep the private key off the server and does not rely on convincing other people to encrypt email to you. Very impressive.
• Process Monitor is a tool that helps you to see what it really happening under the Windows hood. It’s truly indispensable for Windows troubleshooting and incident response. These filters are specifically designed for malware analysis. I imagine they will be very useful on my next incident.
• Have you ever wanted to open a command prompt as SYSTEM? Most people think that having administrator rights is the same thing, but there can be subtle differences. This short little script allows you to become SYSTEM for those rare situations where you may need to be.
• Would you know if your web site was compromised? Here are eight tips for detecting a web site compromise.

That’s it for today. Have a great weekend!

The question was raised: “Can OSSEC detect this attack?” I got to thinking about this and the answer is “probably.” Since OSSEC is primarily a log-based HIDs, we first have to look at the logs to see if there is anything juicy in there that we can use. We also need an exploit and a vulnerable system so we can reproduce the conditions of the attack. Since my server wasn’t vulnerable, FrankS in the #OSSEC channel on IRC offered to lend a hand in the rule research efforts. The first thing we noticed is several logs like this:

172.16.0.1 – - [27/Aug/2011:21:42:53 +0000] “HEAD / HTTP/1.1″ 206 354 “-” “-”

There are two things about this log that don’t quite look right: one, there are multiple HEAD requests to the root of the domain (/) and two, there are several 206 HTTP status codes. Generally, you would see 206 status codes  in the context of requesting compressed content, and the request would probably be a GET. The other thing we noticed in the logs was a page allocation failure coming from Apache, like so:

Aug 27 21:59:43 hostname kernel: [ 1181.719148] apache2: page allocation failure. order:0, mode:0×20

This was promising. If we could simply look for multiple HEAD requests to / with 206 status codes in a very short amount of time, followed by a ‘page allocation failure,’ it’s probably an attack. OSSEC can do that.

There’s a certain amount of art and experience which goes into writing IDS rules. The goal is to make the rule as accurate as possible: if it does not detect the attack (false-negative), you will lose faith in the IDS; on the other hand, if it detects things which aren’t really an attack (false-positive), then you will also lose faith in the IDS and miss potential attacks. Finally, it is best to avoid making the rule exploit-specific. This can result in a situation where a small change in the exploit can avoid the rule being triggered.

Knowing what we do about the logs, how can we make a rule or set of rules that will trip when the host is attacked and be somewhat accurate? Multiple HEAD requests to / are certainly suspicious, but does the attack rely on HEAD to be successful? Section 10.2.7 of the the RFC for HTTP specifically refers to GET requests, and the attack does not seem to be specific to the HTTP method, so we can’t necessarily rely on the HEAD as an indicator. Next, we see the series of 206 codes. That is also not necessarily an indicator of the attack, but it likely is something that the webmaster may want to know about. If there are several of them in a small amount of time, we can alert the analyst to the condition for further inspection. Still, we aren’t really sure if it is the Range Header DoS. In this case, we’ll need two rules. The first rule detects the 206 status code but does not send an alert, while the subordinate rule looks for 10 of them in a 5 second interval coming from the same location (agent) and from the same source IP:

<rule id=”100002″ level=”5″>
<if_sid>31108</if_sid>
<id>^206$</id>
<description>Web Server 206 Error Code</description>
</rule>

<rule id=”100003″ level=”10″ frequency=”8″ timeframe=”5″>
<if_matched_sid>100002</if_matched_sid>
<same_location />
<same_source_ip />
<description>Multiple Web Server 206 Error Codes </description>
<description>from Same Source IP</description>
<group>web_scan,recon,</group>
</rule>

At this point, the analyst will get alerted to the DoS condition, but we are not necessarily confident that it is the Range Header attack. There’s one more rule we can create that looks for the ‘page allocation failure’ occurring within five minutes of rule 100003 firing. If we see all of this, we are reasonably confident in what is going on:

<rule id=”100004″ level=”12″ timeframe=”300″>
<if_matched_sid>100003</if_matched_sid>
<if_sid>1002</if_sid>
<program_name>kernel</program_name>
<match>page allocation failure</match>
<description>Apache Range Header DoS Attack</description>
<group>attack,</group>
<info type=”cve”>2011-3192</info>
</rule>

So, what can go wrong? Lots. The system may be so unstable that it cannot send logs to the manager. The attack might be successful with fewer than ten 206 requests within five seconds. In some cases, the ‘page allocation failure’ does not appear in the logs, although the attack still might trigger rule 10003. At least this would give the analyst a chance to visually inspect the sample of logs OSSEC sends in the alert.

Are there better ways to detect this? Certainly. Mod_Security can not only detect but also prevent the attack. Tools such as Snort are better positioned than OSSEC in situations like this. Of course, OSSEC can monitor the logs of those tools, and still alert you. The point here was to demonstrate that there is an OSSEC-only way to detect attacks like this.

Do you see a problem with the rules? Can they be subverted easily? Let me know in the comments.

• PacketFence is a free and open source NAC system. I haven’t used it so I can’t vouch for it either way, but it’s nice to see a NAC in the free software world. NACs are good at preventing things like man-in-the-middle attacks, help you with asset control and help to keep the worm-of-the-day off your network when a contractor plugs in his laptop. Free software can also be a good way to meet a requirement even with limited or no budgets.
• Need a forensics tool? Maltego may fit the bill. It’s also free to use, but not free software in the sense that it doesn’t seem to have an OSI compatible license. Like PacketFence, there are also commercial support and versions available.
• Jamie Riden wrote a very nice piece on his/her response to an SSH attack. There are some nice recovery and lessons-learned aspects to the article. Another possible countermeasure would be the use of OSSEC along with its active response capabilities. This might have been able to prevent the compromise entirely.
• Would you like to have a log of all commands entered on a Cisco router? This is something that can be very useful for audit and compliance, as well as change management needs. This is a great one for PCI environments.
• The ‘nix mtr tool can be useful for troubleshooting network problems. The WinMTR does pretty much the same thing from a Windows host. It’s also free software.

That’s it for today. Have a wonderful weekend!

Major kudos for this release go to Dan Parriott (ddpbsd). Dan is the most active person helping OSSEC users today on the mailing list and IRC. He also seems to find time to write documentation, which–let’s face it–no one really likes to do, and writes new rules and decoders. Thanks, Dan.

If you would like to see what I am up to in the OSSEC world, check out my repository on Bitbucket. My commits are generally tested and ready for integration into the next release, so try them out and let me know how they work for you. The tickets section is basically my task list of things I am already working on or plan to implement.

As always, thanks to everyone who contributes and supports our work. If you have some free time, stop by #ossec on freenode to say hi.

I stepped outside tonight to water the garden and what did I find? A fuzzy-tailed rabbit happily hanging out inside my garden–with the gate closed. My perimeter has been breached!

How did he get in? I am still doing an analysis, but I believe he squeezed in below the gate. He was a small bunny and this seems like the biggest vulnerability to exploit for a critter his size.

How can I close the hole? I am still pondering this, but I am thinking of something that works kind of like tire strips, which will hopefully dissuade him from crossing the perimeter. I might also post a picture of Chuck Norris for good measure.

I thought I should post this in the interest of full disclosure. It has been a long day.

Joe: We’re not selling enough of our <insert product here>. We need a way to really connect with people.

Linda: The problem is branding. Cross-site Request Forgery doesn’t really roll off the tongue too well.

Bill: Hmm… Advanced.. Problem.. Fixer..

Tom: That’s a good start. How about Advanced Persistent.. Software..?

Joe: Wait for it… Advanced Persistent Threat!

All in unison: Awesome! Let’s go for drinks.

OK, so maybe it didn’t go down exactly that way, but it’s fun to imagine.

So, what exactly is an Advanced Persistent Threat, or APT? According to Wikipedia, APT attacks utilize traditional attack vectors such as malware and social engineering, but also extend to advanced attacks such as satellite imaging. It’s a low-and-slow attack, designed to go undetected.  Finally, there is a specific objective behind it, rather than the incoherent activity of some fifteen-year-old hacking away in a basement for brownie points with his buddies.

It’s not just vendors getting in on the game–companies are increasingly blaming their security failures on APT, as if it was far too sophisticated for them to possibly defend against.

There’s no doubt that such attacks exist. Corporate espionage and nation-state attacks are very real and, in some cases, extremely sophisticated. But these attacks are very rare. The truth is that the vast majority of attacks are not very advanced because they don’t need to be. It is extremely difficult to defend against all known attack vectors. The defenders have to get everything right, all of the time. The attackers only have to find one or a few small holes to work their way in. That’s just the current state of information security.

I think we should generally avoid using the term Advanced Persistent Threat. There are two main reasons I feel this way.

1. It’s highly likely that it’s not an APT at all. Even if you have a great security program with the smartest security people in the world, a company of any appreciable size is going to have hundreds of ways in. You can have everything patched and the front-desk lady will give up her password. You can require two-factor authentication for all remote access until the smart phones come along. You can have great perimeter security until your business partner gets compromised, and you realize that your perimeter really doesn’t begin and end at the firewall. Face it, your company is insecure on its best day.
2. Using terms such as APT, while sexy, encourage us to gloss over the actual facts. Just as intellectual property is a way of lumping together things like copyright and trademark, APT discussions keep us from focusing on which attacks were actually used and how our defenses failed. There is no APT attack. There are SQL injection attacks. There are social engineering attacks. There are buffer overflows in software. There are default passwords left on systems. There are insecure trust relationships. APT is a dangerous umbrella term.

Even those few who do face what people call APT attacks need to break them down into their core elements in order to understand and defend against them. For the rest of us, let’s go back to discussing how our security design failures could lead to a compromise. And if one should occur, let’s speak to the specifics of the attacks so we can learn our lesson, even if a little humility is in order.