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

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.

Saying that all merchants must adhere to 100% of the entire standard is wrong. The correct statement is that all merchants must adhere to 100% of whichever SAQ Validation Type applies to them. The different validation types do indeed enforce only a small subset of the standard on many merchants, which was pretty much my major beef with PCI.

So, there you have it. PCI does have some reasonable requirements in place, depending on the circumstances of the transaction. I stand corrected.

Although she probably doesn’t even realize it, Lisa (the hair lady) is supposed to comply with PCI. She doesn’t even get a break for just having a card terminal. She has to comply with the entire standard. Some sections will not apply, such as if she does not store the card data, but she doesn’t get a “just the hair lady” break.

I think she should.

Don’t get me wrong, I actually think PCI is one of the best standards out there. Since it is so prescriptive, it doesn’t leave a whole lot of wiggle room for larger companies to justify their way out of it. It absolutely can lead to better security. I have witnessed it. But it is not a one-size-fits-all standard.

It’s unreasonable for merchants like Lisa to be expected to act like companies with security departments and dedicated budgets for lots of fancy controls. So while this may not be the expected position of a security professional, I can’t ignore that little voice in my head that says she should just do what she does well–that is cut hair–and not worry too much about credit card security. PCI is not a law, and the chance of her suffering extensive damage from a credit card breach is small. A few reasonable precautions are all she should have to worry about. Anything else is a design failure of the credit card system and should be addressed there.

Update: Be sure to read the follow-up post where I stand corrected.

Preferring ‘nix-based solutions, I downloaded Oracle XE 11g for Linux and configured it for logging to syslog. It wasn’t long before I had logs like this:

Dec 28 22:32:41 localhost Oracle Audit[4958]: ACTION : ‘CONNECT’ DATABASE USER: ‘/’ PRIVILEGE : SYSDBA CLIENT USER: username CLIENT TERMINAL: pts/2 STATUS: 0

At first glance, it looked like a pretty standard syslog message, but after having some issues getting OSSEC to pre-decode it properly, I decided to check the RFC to see if it was technically compliant. Here is the relevant part of RFC 3164.

The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the conclusion of the TAG field has been seen to be the left square bracket character (“[“), a colon character (“:”), or a space character. This is explained in more detail in Section 5.3.

Did you spot it? The problem is that Oracle likely intended the string ‘Oracle Audit’ to compromise the TAG field (program or process name); however, the TAG field in this case really is just ‘Oracle’ since it is terminated by a non-alphanumeric character (the space).

So is it compliant? I would have to say yes, but I don’t think it is compliant in the way they intended. Simply removing the string ‘Audit’ in this case would have made a clearly compliant and understandable message.

• Avoid legacy syslog transport at all costs. Plain-text, UDP syslog is so last-century. The only reason we (security types) tolerate it is because we usually have no choice. Most of the network devices force our hand. To support syslog as a transport method over the Internet is asking for all sorts of trouble. There will be no way to completely eliminate log spoofing, log sniffing and lost logs. Customers serious about logging will simply not tolerate such chaos.
• Support syslog message format at all costs. Notice the difference here. I don’t want to see the syslog transport method being used over the Internet. Logs are not radio station streams. I do want to see the syslog message format supported. Any service who does not support the syslog message format will not be successful.
• Secure the transport. Again, we need to address the problem of log spoofing, log sniffing and lost logs. This necessitates TCP for trasmission over UDP, authentication of the log source and encryption of the data. There are a couple of ways this can be implemented: a VPN gateway can be established with the log provider or a log-collecting agent can be installed on one or more local machines. In both scenarios, the transport of the logs is addressed.
• Implement flexible delivery options. Not all logs can or should be sent in real time. Firewall and proxy logs, in particular, are very chatty, but can also be very important indicators of an attack. Some mainframe logs have to be submitted as batch FTP transfers. Some systems push their logs and some need to be polled. Some logs are only produced when a monthly or quarterly report runs. The point is that we need to consider multiple delivery options. A successful cloud offering will allow for log traffic shaping, queueing, real-time and batch transfers.
• Protect the application layer. Logs are pretty useless unless you can index, search and correlate them. This means you need a robust application to navigate the millions of messages you might be sending. It’s inevitable that people will attempt to attack the application layer. Not only does this mean securing the site against traditional web attacks, but also remote log injection. Logs are volatile and anything might show up. That gives the attacker a log of flexibility. Can the bad guy drop the customers table with a well-formed SQL query put into the username field of a local server? It’s certainly within the realm of possibility.
• Meet the traditional requirements. Log management programs are often driven by compliance needs. It is imperative that traditional requirements for log management programs can be met. This means we need controls around who accesses these logs, when they accessed them, from where, and why. This includes employees of the cloud service. How long will they be stored online and offline? What happens in the event of a subpeona or a breach? Customers may even demand that the cloud service providers, themselves, be audited under something like ISO 27001.
• Start planning for interoperability. I haven’t seen any efforts in the area of cloud log service interoperability, but I suspect this will become a pain point in the future. If there is anything we have learned from vendor lock-in in the past, it is that the customer’s needs are not best served by this approach. I, for one, would be extremely wary of any vendor that did not allow me to export all of my logs in a common industry-accepted format. What if the service were to go out of business? Would I lose years of valuable log data?

While this is not an exhaustive list, I do believe that now is the time to start a dialogue. Rather than try to stop new technology and services, let’s find ways to make them work effectively. Let’s talk about the risks and address them. Let’s learn from the mistakes of the past and prevent the same mistakes in the future.

NIST attempts to fill this gap with the Small Business Information Security: The Fundamentals guide. In the guide they detail what a small business should minimally be concerned with, along with some extra measures they may want to take.

While it has a little ways to go (it is a draft, after all), it’s a great start to filling this much needed void. Check it out and see if they manage to walk the fine line by making security simple, yet effective enough for small business.