Immutable Security

What should one do when discovering a vulnerability in a medical device? What if, by disclosing the vulnerability, you could put someone’s life at risk? These are the questions I explore in an article I wrote for the most recent issue of ISSA Journal.

As always, I welcome your feedback. Feel free to challenge my assertions. All constructive comments will be let through moderation.

Well, despite my best efforts, the day 7 post is going to be a bit delayed. But I think you’ll like it. So, stay tuned.

Yesterday, I blogged about some annoying malware. The point was to learn some of the techniques that this general class of malware uses, so we could write some OSSEC rules to detect it. If you haven’t already read that post, go back and read it so you’ll understand this one.

One indicator of malware is that it changes the hosts file and redirects sites to localhost. There are three different ways we can detect this with OSSEC:

1. A basic file integrity check, although this doesn’t tell us what changed.
2. A command output check which echoes the contents of the file
3. A compliance check

File integrity checks are pretty simple. All you have to do is tell OSSEC to monitor the file. Let’s focus on the command output and compliance checks.

1. Command output. Unfortunately, the report_changes option is not available for Windows right now. To get the content of the file into OSSEC, we’ll simply use the built-in Windows type command to achieve our objective. Put this in your ossec.conf on the agent (watch for wrapping):

<localfile>
<log_format>full_command</log_format>
<command>%COMSPEC% /C type %WINDIR%\system32\drivers\etc\hosts | %WINDIR%\system32\findstr.exe /BVC:”#”</command> <alias>Windows Hosts File</alias>
</localfile>

Now, just add a rule like this so you’ll get the diff:

<rule id=”100027″ level=”7″>
<if_sid>530</if_sid>
<match>ossec: output: ‘Windows Hosts File’</match>
<check_diff />
<description>Windows Hosts File Changed</description>
</rule>

At this point in time, there is a bug in OSSEC, which means that the diff of the file will not be in the email, but it should be in the original alert in alerts.log.

2. Compliance checks. Compliance checks are part of the rootcheck functionality of OSSEC and are run right after the syscheck (file integrity) scans. They allow you to look within files, registry keys and processes for certain values, and alert on them. For this example, we want to know if there are any entries other than the expected localhost entry. Simply add this to your etc/shared/win_malware_rcl.txt file (watch for wrapping):

[ Site Redirected to localhost] [any] []

f:%WINDIR%\System32\Drivers\etc\HOSTS -> r:^127.0.0.1 && !%WINDIR%\System32\Drivers\etc\HOSTS -> r:^127.0.0.1\s+localhost;

Referring back to the original post, it would not be difficult to take the other examples and make them into general purpose checks. One word of caution: there is currently no local_win_malware_rcl.txt capability, so be sure to back up your changes; otherwise, they will be overwritten when you next upgrade.

What other examples from malware can you think of that would make for good rules? I would be happy to hear about your experiences in the comments.

Sorry, there will be no Fav Five this week. Instead, I am spending my time on writing a journal article and preparing for the Week of OSSEC. Have a great weekend!

#include<stdio.h>

main()

{

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

}

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!

Yesterday, I wrote a post saying that the lady who cuts my hair needs to comply with 100% of the PCI standard. This was based on my experience in PCI in corporate environments, some of which do not actually store card holder data and are pretty low volume.

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.

When I had my hair cut today, I got to thinking about what level of responsibility this small business should have to protect my credit card data. This is not some big chain. It’s one lady with a couple of employees to help out. She knows as much about computers as my Mom, which, no offense to Mom, is not a whole lot. It’s not that she (or Mom) isn’t smart, it’s just that they are ordinary non-computer folks. They have skill sets in different areas, and that does not make them any better or worse than a tech-savvy person.

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.

For the past couple of weeks, I have been reading with great interest the coverage of Sony deciding to bring suit against George Hotz. George, or GeoHot, as he is known, and others like him, hacked the PS3 after Sony removed the “Other OS” feature. It was this “Other OS” feature that appealed to people like George in the first place, since it allowed the more technical among us to use the PS3 in interesting ways–such as to run a custom version of Linux.

There are many elements to this story: Is What GeoHot did illegal, as Sony claims? Will it lead to more piracy? If it did lead to more piracy, would it even matter? Was what Sony did by removing a feature of the device illegal or unethical? But I think the two main questions above all are: Who owns the device, and How far does free speech go?

We live in an era where corporations are asserting more and more control over the devices we purchase. Unlike a physical book or a lamp, the technology of today allows for interactivity between the manufacturer of the product and the product, itself. Companies like Apple and Sony have attempted to use this to their economic advantage by restricting what valid purchasers of the product can do with their own device. They restrict what apps you run, if you can resell it, and can even take the product back on a whim. Make no mistake: the rights we have enjoyed over our own property are under full frontal assault. Companies like Sony would like nothing better than to convince you that you don’t actually own the product you purchased–that it is really just a long-term rental–that they get to decide the rules.

The other main question besides device ownership is: How far does free speech go? We already know that free speech is not unlimited. You can’t yell “fire” in a move theater and not expect consequences. But at the same time, we are actually very tolerant of free speech. The fourth ammendment guarantees the rights of white supremacists just as it does those whose speech we find copasetic.

“But, wait!” observant readers will say. Sony is not the government and this is a civil issue. If Sony thinks it has been harmed by the free speech that is the release of the private key, they have a right to address that in the courts. Surely, if the secret formula to Coca-cola were to be released, you would expect an army of lawyers to descend on that person.

While it is true that speech can harm a company, a large corporation like Sony can’t necessarily be expected to win a case just because it doesn’t like someone’s speech. They actually have to prove harm in some way, be it libel, slander, trademark infringement or what-have-you. If that weren’t true, and if the law didn’t provide some protection even in cases where the government wasn’t involved, companies like Sony would successfully sue every security researcher every time a new flaw is found.

This case is not about piracy. If George is to be believed, he has never used the Sony online service, never assented to the EULA and never pirated a game. This is about Sony attempting to send a message: The PS3 is ours, not yours. Play by our rules or we will ruin you financially. To anyone else: freely discuss the hack, or, for that matter, look at it, and we will come after you, too.

I have considered everything from staying completely silent on this issue–certainly the safe choice career-wise–to getting a tattoo of the leaked key. But I can stay silent no more. Sometimes you have to speak up for what you believe is fair and right. And I believe it was fair and right for George Hotz to use his device in any way he chose to. I believe it was wrong for Sony to remove a feature that people paid for and had a reasonable expectation to be able to use. And I believe it is right for everyone to freely and openly discuss the hack, including the key, so that they may use their own device in any way that does not involve piracy, and to further the discussion about what device security means.

If the facts are truly what they appear to be, then I support George Hotz and I wish him well in his case.