Mulling Security

Every day I come across new sites hosting exploits and it's always tough to tell if it's something new or just a rehash of an old exploit.

Here are some web access logs I came across today from a squid proxy server showing a site using java to exploit a client and force it to download a malware executable. I have seen a number of java related exploits lately including one I'll be writing about soon that downloads and installs a Windows rootkit.

By the way this site is also in the Internet Storm Centers "Most Hated IP Address of 2005" list.

Warning: Do not click on these links, they are bad. You will get infected with something. I have broken them by putting an underscore in the URL.

GET http://link_schain.net/fr/? - DIRECT/195.225.177.21
GET http://clean_chain.net/fr/? - DIRECT/195.225.177.21
GET http://clean_chain.net/fr/tp/? - DIRECT/195.225.177.21
GET http://full_chain.net/psg/index.php- DIRECT/195.225.177.21
GET http://full_chain.net/psg/Anima.class - DIRECT/195.225.177.21
GET http://full_chain.net/psg/omfg.class - DIRECT/195.225.177.21
GET http://full_chain.net/psg/psj.exe - DIRECT/195.225.177.21
GET http://link_schain.net/fr/? - DIRECT/195.225.177.21
GET http://clean_chain.net/fr/? - DIRECT/195.225.177.21
GET http://clean_chain.net/fr/tp/? - DIRECT/195.225.177.21

One of the best ways to prevent this type of infection is to block executables. It is pretty straightforward and offers a lot of benefit; without the ability to download executable files like (exe|com|pif|scr) many exploits will fail. Of course any clever malware author can easily circumvent this using a number of techniques. This technique is very useful for protecting a large number of users from common html based malware.

In a somewhat disturbing incident the Washington Post reports that digital forensics company Guardian software was hacked in November. The most troubling part of the news is that the break-in was not discovered until December 7th. The company wrote letters to all affected customers, including law enforcement and security professionals, describing the scope of the incident.

Of course this case is nothing new. Unfortunately the monetary damages incurred by the victims could have been prevented. The losses stem from inadequate security of the database holding the credit card information and failure to comply with published security requirements. Despite requirements by both Visa and MasterCard, critical data was stored unencrypted and kept beyond retention guidelines. Had the published guidelines been followed the damage from this incident might have been close to zero.

How long is it really going to be before we see real and effective security measures that prevents credit card fraud? For example it seems possible to implement a one-time credit card system. In fact American Express began offering just such a system in early 2001 but later cancelled the program. There are still a few programs out there such as Discover Card's Secure Online Account. The idea is simple and incredibly powerful, issue a new account number for risky purchases and only allow one purchase with that account number. If the number is stolen from a database, no problem it's no good.

My guess as to why programs like this aren't more popular is that consumers don't see the benefit. Sure they are scared silly of identity theft, often intermingled with credit card fraud, but they think somebody else should fix it. Why should John Q Public spend the extra time getting a one-time use card number for an online transaction when he has no responsibility to pay fraudulent charges? It's just too much hassle.

Visa and MasterCard aren't much better, they're not really eating the costs either. In the end it's the merchants paying the cost of credit card fraud and they're passing it right back to the consumers in the form of higher prices. I fear that until everyone involved starts taking responsibility and accepting part of the burden we'll see more cases just like this.

This story just goes to show that good security isn't always about the latest high-tech flashy security devices, sometimes a little more is needed.

At the airport where this pilot fish works, security has gotten a lot more attention since 9/11. "All the security doors that connect the concourses to office spaces and alleyways for service personnel needed an immediate upgrade," says fish. "It seems that the use of a security badge was no longer adequate protection.

"So over the course of about a month, more than 50 doors were upgraded to require three-way protection. To open the door, a user needed to present a security badge (something you possess), a numeric code (something you know) and a biometric thumb scan (something you are).

"Present all three, and the door beeps and lets you in."

One by one, the doors are brought online. The technology works, and everything looks fine -- until fish decides to test the obvious.

After all, the average member of the public isn't likely to forge a security badge, guess a multidigit number and fake a thumb scan. "But what happens if you just turn the handle without any of the above?" asks fish. "Would it set off alarms or call security?

"It turns out that if you turn the handle, the door opens.

"Despite the addition of all that technology and security on every single door, nobody bothered to check that the doors were set to lock by default."

Vmware has a great presentation on security from VMWorld 2005. The presentation goes through best practices for securing ESX server. In addition they have some good pointers such as how to interpret a Nessus scan of an ESX server. Enjoy!

http://www.vmware.com/vmworld/2005/sln138-b.pdf

SecurePHP is carrying an article on email injection in the php mail() function. Just another great example of why it's bad to take input from a user and pass it directly into a function.

There are a lot of ways to send anonymous emails, some use it to mass mail, some use it to spoof identity, and some (a few) use it to send email anonymously. Usually a web mailform using the mail() function generates emails containing headers with the originating IP of the server it's running on. Therefore the mailform acts as a SMTP proxy. The input fields of the form may vary, but it is common to specify a mailform that gives you control over the subject, the message, and the sender's email address.

While I'm working on some new research on practical implications of VMM security I thought I'd share some of the resources I've been working with. Many of these links go to research along similar paths.

http://www-03.ibm.com/servers/eserver/pseries/hardware/whitepapers/virtualization.html
http://www.engin.umich.edu/alumni/engineer/03FW/feature/
http://www.eecs.umich.edu/CoVirt/papers/dunlap02.pdf
http://freshmeat.net/projects/revirt/
http://www.eecs.umich.edu/CoVirt/
http://www.eecs.harvard.edu/~fedorova/papers/253final-fedorova.pdf
http://www.cs.rochester.edu/sosp2003/papers/p199-garfinkel.pdf
http://www.cs.fit.edu/~pkc/id/related/garfinkel03ndssVM.pdf

I had some great feedback and discussion with a number of individuals on the Virtualizing Buffer Overflows post. It is by far the most popular post on this blog. Also if you have an RSS reader make sure to add http://mtsb.blogger.com/atom.xml to keep up on the latest posts.

In the first post I never intended to fully illustrate the unique scenarios that I've been looking into. This should give a clearer picture of where I was coming from, after all context is everything.

The first scenario hinted at in http://mtsb.blogspot.com/2005/11/virtualizing-buffer-overflows.html is the shrewd attacker and untrusted host. In this situation there should be some very creative ways to inject code into the guests in such a way as to be non-persistent and nearly impossible to detect from the guest perspective. This is especially pertinent to my day job where we are working to provide security to critical guest machines that may be running on untrusted hosts. The primary issue being what are the risks associated with an administrator who is not cleared to access a sensitive guest but does have root access to the host. I wouldn't argue this is a good situation but one in which the risks need to be understood.

The second case is a trusted host and VMM as a mechanism protect the integrity of the guest. What is interesting here is that some practical work on commodity systems such as Vmware and the Linux kernel has already been done http://mtsb.blogspot.com/2005/12/security-using-virtualization.html. One of the most interesting practical implications is that using a modified version of vmware you can mark certain memory pages as read-only at the "virtual hardware" layer. So in this case instead of a passive alarm or panic the virtual hardware transparently prevents the modification without risking availability. This happens to be especially useful for common kernel targets like the sys_call table.

The last case I envision researching is utilizing the virtual environment for better forensic response. My thinking is that the real advantage comes in being able to investigate certain parts of the live system with almost zero modification. Since any traditional investigation on a live system requires modifying the live system in some discreet way virtualization might provide a less intrusive and more accurate process. My test case will be using http://www.honeynet.org/scans/scan29/ and some new forensic techniques specific to Vmware. I've already done a traditional analysis so the virtualized approach should be interesting.

Hopefully some of the research can help develop more secure virtualization technologies. For example imagine a version of Vmware able to enforce RBAC at the virtual hardware level and prevent certain types of malicious code on the guest such as sniffers and kernel alteration.

It's always nice when your employer has benefits that help you with the little things in life. Maybe you get discounted gym memberships to help keep in shape. Wouldn't it be nice if they could help out with what some would call today's current blight - identity theft.

Well I've come across a couple of firms that do! Unfortunately it's not the kind of help you might hope for. In fact you could probably say it's a lesson in what not to do to help your employees protect themselves from identity theft.

At least one large, and by large I mean 20+% national market share, 401k provider offers a ripe opportunity for phishing and identity theft. The offer is appealing; in one swipe you can get employment data, name, address, SSN and birth date. To top it off their login is really whack. They require your username to be your SSN and your password can only be a 4 digit PIN.

Normally I wouldn't feel the need to tell the world about something like this but the options they offer to address these issues are almost as dismal. In order to report a problem with the site you must complete a form that offers no encryption containing name, address, birthday and plan information. There is little additional satisfaction to be gained by speaking to a representative who will read you a script of how your information is secured.

Oh, did I forget to mention that all of your beneficiaries' private data like SSN is displayed on this page as well?

On Wednesday Google added virus scanning to their gmail service. Despite the title I think that this is a good idea. I don't think anyone would reasonably argue that scanning incoming and outgoing email for known viruses is a bad idea.

Where I'm really going here is that adding virus scanning only makes users safer from old viruses but it doesn't help nearly as much with new viruses. Anti-virus products scan files for known virus signatures. This model works great when you can easily catalogue all known viruses and create 100% reliable signatures that can be used to detect them.

Now that Google has added virus scanning users may be led to believe that they are protected from all email viruses but that's not true. With almost all new viruses, except those that are nearly identical to an existing one, there is a time between when the virus is released and when the signature to detect it is released. This time delta represents a window of exposure for users during which time the attachment will not be blocked and they can become infected.

Unfortunately the best answer to this problem, assuming that you can't trust users to make good decisions, is to preemptively block the attack vector. In the case of most new viruses, such as the Sober family of mass mailers, they are using certain attachment types to propagate. Blocking all .zip, .gz, .Z, .com, .exe, .pif, .scr, etc attachments will prevent 99.9% of new and unknown mass mailing viruses. The problem with this solution is that a lot of users rely on sending zip and other archive files and most providers aren’t willing to be that Draconian.

So even though Google's looking out for your Gmail account, don't let your guard down.

In the course of some light research for Virtualizing buffer overflows I came across some interesting research from a couple of researchers at Stanford on using virtual machine monitors for host based intrusion detection. In the paper they discuss some of the ways that virtual machine monitors have advantages over traditional IDS mechanisms since they have a unique and unobstructed view of the guest. They also discuss how the VMM can prevent certain types of attacks that depend on modifying kernel structures. It's an interesting read that I highly recommend.

My point from yesterday is that virtualization has two big security implications, on one hand virtualization allows for extremely difficult to subvert security measures and on the other it allows extremely difficult to detect or defeat malware.