Immutable Security

I have spent the last several days responding to a 0-day worm outbreak. We didn’t have signatures when the you-know-what hit the fan. Fortunately, some tooling we already had in place allowed us to contain the initial spread while we waited for emergency signatures from our AV vendor.

The last stage of any incident response is the lessons learned phase. This is where you examine the response and analyze all the things that went well and all of the things you could have done better.  There are always ways to improve the response.

I got to thinking that simulating a worm outbreak would be an excellent way to test a response, along with the detection tools you currently have in place. Although it wouldn’t cover all scenarios, and maybe not even most of them, creating an EICAR worm seems like an excellent way to set this up.

For the uninitiated, an EICAR signature is a string identified by AV vendors as a “test virus.” It is meant to show that AV is working.

So why not take this one step further and create a custom worm from the EICAR string? It would be simple: simply create a batch file with the EICAR string and attempt to loop through a list of network shares using a privileged account.

There are risks, of course. First and foremost, there would have to be absolutely no way for this to “infect” a system not under your management. That would simply be inexcusable. Second, there may need to be a way to throttle and control the spread. Some kind of “dead man’s switch.” Finally, there needs to be a way to pull-the-plug should things go really awry.

While this may sound like a crazy idea at first, which is better: to have finely tuned responses based on well-practiced and controlled scenarios, or to struggle through the next worm incident?

A few of my posts have involved debating the ethics of public web app testing by security professionals. When the good guys poke and prod public web apps it raises a bunch of ethical questions, besides being legally questionable. Rather than recap my thoughts again, I invite you to read the article which I wrote for this month’s “ISSA Journal.” If you like the article and like some of the articles in the Journal archive, please consider supporting ISSA by joining. I have found it to be pretty valuable.

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

Recently, I blogged about the ethical ramifications of hacking websites by security professionals. They probe the sites, discover vulnerabilities, notify the companies, then blog about their exploits. I haven’t decided yet whether or not I consider this an ethical practice and something security pros should be doing. On one hand, companies should be protecting their customer’s information. And if the site is public, they should have an expectation that it will be poked and prodded. On the other hand, security pros have an ethical responsibility to only test the security of sites they are authorized to test. It’s clear that they aren’t obtaining authizoration for these tests. And that may very well be illegal, to boot.

Today, I ran across this guy (I don’t know his name) who reveals some security problems in Sears’ website. It’s a problem worth discussing. He makes legitimate points on the security of gift cards. It’s something that people really should be aware of.

But does that justify his actions? I’m still on the fence about this one. It sounds like we need a framework to deal with this problem. We need to stay professional and on the right side of the law, while at the same time exposing poor security.

What do you think? I’d be interested in hearing your perspective.

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.

I have observed a trend recently that has me internally debating the ethics of the practice. Security professionals are probing public web sites for vulnerabilities, then going through a “responsible” disclosure process with the owners of the site. Then they blog about their exploits and how responsive the owner was to being notified.

How is this different than traditional hacking by the bad guys? Does the disclosure process make it any better? Does the fact they do security for a living and write for security journals make it more ethical? And what of the applications that are vulnerable to routine exploits? What does one do with a successful SQL injection query that just gave you a table full of social security numbers?

On the surface, it seems unethical to me. Attempting to break access controls, even if they are weak, is unethical and maybe illegal. Doing something untoward against another computing resource for which you do not have authorization is treading on thin ice.

But there’s another side to the story here. Applications are moving more towards the software-as-a-service, or SaaS model. Whereas once you would have been able to download the software and legally and ethically reverse-engineer it, now the application is only hosted on another computer. This changes things in a big way, since you’re working on someone elses computer now.

The argument could be made that since the application is public, then there is an expectation that it wil be poked and prodded, so it might as well be the good guys who do it. The bad guys aren’t going to go through a responsible disclosure process, so by the good guys testing the application and making the flaws known to the application owner, everyone benefits (as long as they actually fix it). It can also be said that for security to continually improve, we have to continually test it. If the world is moving towards a web-centric model, we have to move with it.

Honestly, I can see both sides; yet, I am still left with the feeling that, in many cases, it’s nothing more than the security guy trying to have some fun and make a name for himself. If that’s the case, he should carefully consider what that name may be.

The Age reports that computer criminals from an underground hacker forum broke into Australian Federal Police computer systems after the police infiltrated their group. And, according to The Age, it was all because the cops forgot to set a MySQL database password.

We may need to pass around the clue stick to everyone here. If the compromise was real, the police should have known better than to leave a database exposed to the Internet and unprotected with a password. The alleged criminals need to understand that drawing more attention to yourself after you already know your under investigation is not the brightest thing to do.

Surely, the system could have been secured. It’s doubtful that it needed to be on the Internet in the first place. Or maybe, as some speculate in the article, it really was a honeypot designed to lure the not-so-bright (alleged) criminal into a trap. Maybe the police are a bit brighter than the bad guys give them credit for.

Let’s assume for the moment that this was an honest security blunder. It’s certainly the type of thing that happens every day. What’s the security lesson here and how could this have been prevented? In this particular case, two things come to mind:

1. MySQL could listen on localhost or use a socket, by default.
2. MySQL could require a decent password or heck, a password at all, to run. No password and the process aborts. For those that really want to live dangerously, they could pass a –stupid flag to run without a password.

Many security problems are preventable. Whether or not this was a honeypot, this can be used as a lesson for developers. Run secure by default and make the user choose to be insecure.

The Linux kernel has been vulnerable to a local privilege escalation vulnerability since 2001, but we’re (the good guys) just now finding out about it. We don’t know if the bad guys have already known about this for a long time. The vulnerability allows local users to become root. Sounds scary, huh?

Maybe it is and maybe it isn’t. Local privilege escalation vulnerabilities aren’t actually all that uncommon. Usually, they come from applications running as root or, on Windows, as SYSTEM. I have actually found a fair number of these myself on Windows. Simply look for a service running as SYSTEM that interacts with the desktop and chances are you can get SYSTEM access in just a few minutes.

That’s not to say this isn’t a serious vulnerability. Any time the operating system, itself, allows an unauthorized user to gain privileged mode, you should stand up and take notice. It means that the OS isn’t enforcing privilege separation at all and logical access controls are useless. Even SELinux, which is a mandatory access-control system, won’t protect you from this one. Exploit code is available.

But should you drop everything you’re doing and patch? In order to answer that question, you have to put the vulnerability into context. Here are some questions you should be asking yourself:

• Where is the important data located?
• Which systems are most exposed?
• How will downtime affect my operations? Are there financial penalties?
• Do I have other system-level remotely exploitable vulnerabilities in the environment?
• Am I even keeping AV signatures up-to-date across the organization?
• Do I allow unvetted users local access to my Linux servers?
• Do I run proprietary software dependent on a particular kernel version?

It’s important to note that, just because you don’t allow users local access, that doesn’t mean a lesser attack can’t lead to root. If someone is able to compromise your web server and become the apache user, for example, then they might be able to escalate their privilege through this attack.

Context is important. This may be serious, but there may be other problems in your organization which are more serious. Take care of those first. If you’re doing well enough to have the luxury of jumping right on this and fixing it, congratulations.