Immutable Security

#include<stdio.h>

main()

{

printf(“R.I.P., Dennis. Your contributions will not be forgotten.\n”);

}

Special edition: Here are five log-a-licious links that I found interesting for this week:

• How can you know what amount of storage you will need when your centralized log server is fully operational? There are no hard-and-fast answers, but it is important to at least come up with an estimate. In his blog, Eric Romang shares a handy script to get you at least part of the way there.
• Eric does equally well in a follow-up post about calculating your events-per-second, or EPS.
• Have you ever had a need to write events to the Windows Application Log? Your scripts do output logs, don’t they? Here’s a short little VB script to help you along the way.
• What is the difference between a Windows “Account Logon” event and a “Logon/Logoff” event? I’m sure it made sense to someone at Microsoft at the time, but to many it is confusing. Here’s a good explanation.
• Are you collecting workstation logs? While I wouldn’t necessarily put it at the top of my list, it’s not a bad idea at least for select hosts. Think admins, kiosks, conference rooms and the like. More food for thought from Randy.

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

Here are the five or more links that I found interesting for this week:

• PDF-XRAY is a site where you can submit suspect PDFs for analysis. Now you can download the code behind the site and have a go at the file locally. This might be a better alternative than sending a potentially sensitive file to an unvalidated web site.
• Are you wondering whether that weird looking exe in a startup location is malicious? Virus Total is one of my favorite sites for getting a second opinion. It will scan a file you submit with multiple AV engines and let you know what they think. A file that comes back clean is not necessarily clean, but if multiple AV engines tell you that it is infected then it probably is. Another feature, which seems to be new since my last visit, is the ability to scan a web site. It will check the index file and let you know if any obvious malware is being delivered from the site.
• Threat Expert is a similar site to Virus Total, with the added advantage that it returns a pretty detailed report. The report tells you what the file actually attempted to do. I like to use both sites on a suspect file.
• Feeling pretty confident in your firewall egress policy? What if I told you that systems can be controlled with ping packets, or ICMP. Ok, I’ll wait while you pick your jaw up from the ground.
• As we become more and more of a gadget society, we’ll be running into things like this quite often. Jerome Radcliffe discovered some vulnerabilities with an insulin pump. Since the pump controls the dosage of insulin to the patient, a security vulnerability in a device like this is not just inconvenient, it can be fatal. Medtronic, the company behind the device, seems to be doing a very poor job at handling what seems to be a very honest and ethical disclosure. Information security concerns may be new to these types of devices, but we can’t let the companies PR their way around these issues. The stakes are simply too great.

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

It’s almost that time of year again. October is National Cybersecurity Awareness Month. It’s also the third year that we have the opportunity to come together as a community to share some great OSSEC info. This year we have designated Oct 23-29.

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!

Here are the five or more links that I found interesting for this week:

• 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!

Here are the five or more links that I found interesting for this week:

• 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!

Here are the five links that I found interesting for this week:

• 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!

Here are the five links that I found interesting for this week:

• 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!

Virtualization is a quickly growing area in IT right now. The prospect of running dozens of virtual servers on one physical server is most appealing. As long as licensing costs don’t eat up too many of the savings, it really does have the potential to transform an infrastructure into something much more efficient.

Of course, with any new technologies there are risks. Sometimes the risks are completely new and sometimes they are the same risks we have been dealing with for years — just repackaged in a slightly different way.

When most people think of virtualization security, they think of things like breaking out of the guest machine onto the host. This would be a very serious attack if successful because it has the potential to leverage one attack into something that can compromise several hosts. Even malware is getting into the business. The Blue Pill proof-of-concept used a small hypervisor to intercept calls to and from the guest, thereby controlling it according to desires of the attacker.

These are real threats, but for most organizations they do not represent the most serious threats to virtualized hosts. I was reminded of this last week when I read about Jason Cornish, a former IT employee of drug maker Shionogi. Jason had a beef with his former employer and he took it out by logging in and deleting 88 virtualized hosts. That’s the functional equivalent of a tornado taking out a small data center. He was able to do this simply because of a password which was not changed upon his termination, thereby allowing him remote access.

What’s the lesson here? The point is that we cannot forget the fundamentals of information security when implementing new technologies. That means doing the non-sexy stuff like changing default passwords, revoking access immediately for terminated employees and sending logs to a centralized log server. In the virtual world, we might review the access levels of the virtual administrators to make sure they are appropriate, separate hosts of different sensitivities onto different hypervisors and get alerted when a virtual machine is added, deleted or moved.

We do need to keep an eye on evolving virtual security threats, but we also have to keep the other eye on the fundamentals. We need both.

If you run Apache, you may have heard about the DoS vulnerability last week. Apache suffers from a condition where an attacker can remotely cause the web server to consume huge amounts of memory. This causes the system to be unstable and eventually, maybe even crash.

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.