Immutable Security

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!

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.

Here’s a little secret that the sales guys of the million-dollar SIEMs are probably going to gloss over. Most of them do not offer a way to encrypt logs in transit end-to-end. Worse, many of them use downright silly methods to collect logs on common operating systems, such as installing an FTP client on every host and sending them along as a big batch every so often.

For some reason, this is seen as acceptable since it’s usually on the internal network. At the same time, we give mean looks to anyone who even mentions the use of a clear-text protocol like telnet.

Here’s another little secret: many of the big SIEM vendors use syslog-ng as the log daemon on their appliances. It’s reliable and secure and generally works very well.

What if there was a way to add encrypted log transit to the expensive SIEM, or to the other log management solution you already have in place? What if you can’t use or don’t need the full functionality of a log analysis solution like OSSEC, but would like the ability to use encrypted log transport? Read on, my friend, because I’m going to show you exactly how to do that, and it can be done in just a few minutes.

1. Install OSSEC in server mode on the existing syslog server from the vendor. I won’t go into detail here on how to install OSSEC, as it’s well documented elsewhere. These systems are generally just minimal Linux installations, so if you are lacking a compiler then you may need to install it on a like system and move OSSEC over. If your vendor won’t let you do this, ask them why you are paying them gobs of money without even the basic functionality of encrypted log transit!
2. Install OSSEC agents on the hosts you want to collect logs from. Configure the agents to collect the logs you are interested in and add them to the manager. Don’t forget to restart the OSSEC manager after adding the agents.
3. Add the following lines to /opt/syslog-ng/etc/syslog-ng.conf under the “source s_local” section:
   # Read OSSEC queue
   unix-dgram(“/var/ossec/queue/ossec/queue”);
4. Edit /var/ossec/etc/ossec-control and modify the two variables which are responsible for starting the OSSEC daemons. After modification, they should look like this:
   DAEMONS=”ossec-remoted”
   SDAEMONS=”ossec-remoted”
5. Finally, stop both syslog-ng and OSSEC. Start syslog-ng first, then start OSSEC.

The reason this works is due to the way OSSEC is designed. In fine Unix tradition, OSSEC separates the tasks into individual daemons that do only one job and do it well. In this case, ossec-remoted is writing to a Unix socket that syslog-ng is reading from in real-time. OSSEC is simply handing off the message to the local syslog daemon, at which point the message continues on its way as it normally would.

I used to use Snare, Zebedee and OSSEC for secure log delivery and file integrity. Now, it can all be handled with one open-source agent, already designed for secure and reliable log delivery.

There is a downside, which is primarily due to me not taking this to the next level and looking into the issue. In this configuration, you will not receive a notification if the OSSEC agent disconnects, since there is nothing to act on the absence of the heartbeat OSSEC sends. I’m pretty sure that can be solved by taking it up a notch and including one or two more daemons, combined with a stripped down decoder and rules file.

So the next time your expensive SIEM vendor tells you there’s no way to encrypt the logs in transit, tell them you can set it up in under an hour. Then send them a bill for your time.

PhysOrg.com and many others are reporting a new attack against WPA encryption, which is used in wireless networks. While WEP encryption has been proven to be all but worthless, attacks against WPA have mostly been limited to acedemic and brute-force attacks.

The two Japanese scientists apparently have found a method to crack WPA when combined with the TKIP algorithm, however the attack does not apply to WPA2, a more recent version of the standard, when combined with AES.

This might be a good time to verify the settings on your home wireless network. If the option to use AES and WPA2 is present, it makes sense to use it. But I wouldn’t rush home in a panic.

While you’re in there, make sure your admin interface requires a strong passphrase and your WPA2 keys are equally protected. At least for the keys, use a strong, randomly generated password since you generally only have to key them in once per device. Here’s an online generator you can use from grc.com.

For some time now I have had problems with Yahoo! accepting mail from the domains I manage and marking the messages as spam. They continued to blackhole me depite having never been an open relay, having a valid PTR record, having a valid SPF record, not sending any spam or mailing list e-mail, sending to and from only a few select people and having nothing in the message body that could possibly be considered spammy. Only Yahoo! has problems with the server. Everyone else seems to think I’m an OK guy.

Several attempts to resolve the situation fell on deaf ears.  Several times I dutifully filled out the forms and provided all the details requested. I even requested to not receive a scripted response, hoping a human being worked somewhere at Yahoo!. The experience led me to conclude one of two things: either they really don’t care at all about letting you know how your mail server offends them or the place is so (in)efficient that the machines have risen and killed off all the humans, only to run Yahoo! all by themselves.

It seems that I have now appeased the Yahoo! mail gods. Yesterday, I implemeted Domain Keys using the excellent guide over at Brandon Checketts’ site.  Yahoo! now considers me worthy of sending mail to their underlings. I can only hope that I continue to please the Yahoo! gods, for they are all powerful.

VoIP, or Voice Over IP is quickly usurping traditional phone lines. It’s not hard to understand why. VoIP service allows you to do things previously impossible with traditional phone service. You can use physical phones or an application on your computer. You can setup internal company PBX systems previously only available to those with lots of money. You can even use VoIP to answer your front door.

The insecurities of VoIP are being discussed, but few are listening. We already know that VoIP is insecure in many ways. But I have not heard much discussion about the practical implications of VoIP insecurity. The discussion is still a bit too academic.

Let me give you an example. Most providers that I know of do not support transmission over TLS/SSL. The practical implication of this is that whatever you discuss is being transmitted over the Internet in the clear. It is fundamentally no different than putting the same info in an e-mail.

If you have VoIP service or are considering it, consider whether you would be confortable transcribing what you are about to say and sending it in clear-text e-mail. If your conversation contains SSNs, credit card numbers, passwords or your strange affliction for <insert subject of fantasy here>, you may want to reconsider discussing it in a VoIP call.