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

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

I stepped outside tonight to water the garden and what did I find? A fuzzy-tailed rabbit happily hanging out inside my garden–with the gate closed. My perimeter has been breached!

How did he get in? I am still doing an analysis, but I believe he squeezed in below the gate. He was a small bunny and this seems like the biggest vulnerability to exploit for a critter his size.

How can I close the hole? I am still pondering this, but I am thinking of something that works kind of like tire strips, which will hopefully dissuade him from crossing the perimeter. I might also post a picture of Chuck Norris for good measure.

I thought I should post this in the interest of full disclosure. It has been a long day.

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?

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

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.

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.

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.

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.

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.