Over the past few days I attended the Techno Forensics 2009 conference held at NIST. It was free and I needed the CPEs, and it’s vaguely inline with what I do, so I went.

Read the rest of this entry »

Today is the day. Whether you pre-ordered Windows 7, received a free upgrade voucher, or are purchasing it from your local retailer, one thing is for sure. It’s been a long wait. If you haven’t had the chance to play with the beta, RC, or RTM versions of Windows 7, then you’ve truly been missing out (assuming you’re a Windows user to begin with). It truly is a great step up, regardless of all the negative hype Vista had, Win7 holds its own on quality.

Read the rest of this entry »

A few days ago, a friend of mine asked me how emails are forged. Instead of directing them to Google, I figured it’d be more fun to explain it to them. So in the interest of sharing, my explanation to them was as follows…

Email forgery is made possible due to the way email servers accept mail from email client programs and from each other. The whole process is not much different from the way regular snail mail is delivered. When you mail a letter, you write the name and address of the recipient and (usually) your own name and address so they know where to send any replies to. But this is just what’s supposed to happen. In reality, you could write anyone’s name and address as either the sender or the recipient and the mailman wouldn’t really care– his job is just to deliver the letter to whatever recipient address is listed, not to verify that you are who you say you are.

Read the rest of this entry »

On Saturday, October 10, 2009, James Madison University hosted their second annual Cyber Defense Competition. This year, there were three teams made up of JMU students, and two teams made up of high school students with JMU student advisors. The attackers were played by employees of Gemini Security Solutions, Computer Sciences Corporation, some JMU alumni, and other friends.

The competition is based loosely on the setup of National Collegiate Cyber Defense Competition events. Each team is scored on their ability to correct problems on their network of machines, perform IT-related business tasks, keep critical systems operating, and defend their networks from the attackers. In the JMU competition, the defenders are allowed to work to secure their systems for one hour before the attackers are permitted to perform attacks. This is opposite what typically occurs in the national competitions – the attackers get to probe and attack the systems before the defenders are called in.

Last year we chronicled how the event transpired. This year, there were some differences in what worked, and what didn’t.

• Default Passwords: This was far less successful an attack than the year prior. Most every team had changed every externally-accessible password from its default. What was a cakewalk last year was quickly frustrating (for the attackers) this year.
• Running Older (vulnerable) Software/Processes: This was also less common. The only time these attacks were successful were when systems had to be rebuilt because they were damaged beyond the team’s ability to repair them, the teams forgot to re-patch the servers.
• Installing Unknown Software: The teams were once again given a business task to install software on a server, but the digital signature on the email was invalid. Only two teams installed this software, and both quickly noticed it was not what was expected and removed or patched it.
• Physical Access: A physical attack we performed – erasing the drives on all firewall machines by inserting a DBAN disc – turned out to be the difference in the competition. One team thwarted this attack by disabling the keyboard on their firewall. We only had 5 minutes of uninterrupted access to their systems and failed to get the drive erased on one team’s system. Being the only team standing while the others had to rebuild their firewalls completely allowed them to score enough points to win the competition.
• Web Application Security: The E-Commerce Site/Engine that was installed by default on the team servers was not well understood by the defenders. The attackers used knowledge of the system and its back-end firewall to install back doors and disable the site. Most teams either never got the web application running, or had it disabled for the entire competition.
• Not finding the real problem: This was less of a problem this time. The teams were effective at rooting out the causes of attacks and defending against them.

The teams were all very effective in configuring their firewalls to prevent attacks, and prevent successful privilege execution even when attacks were successful. For example, we had compromised one of the web servers and the ability to run system-level commands on it. Unfortunately, their firewall would not let us use any mechanism to download additional attack tools to the system (we tried ftp, telnet, ssh, tftp among others). As a result, while we could take down the website (which was already at our mercy), we couldn’t use this to attack other systems.

All in all, I believe everyone had an enjoyable and educational time. We look forward to the next competition!

October is Cyber Security Awareness Month (among other things including Breast Cancer Awareness Month), so this post is going to help make you aware of how to learn about vulnerabilities and – more importantly – patches in the systems you manage.

Vulnerabilities are found in several places – the first place you’re likely to find public disclosure of a vulnerability is the Full Disclosure mailing list. On the downside, it’s a very high noise to content ratio (i.e. there’s a *lot* of noise – probably 90-95% noise). The second place it’s likely to show up, and be more useful to you is in the bugtraq mailing list – this is because bugtraq is moderated. It has a much lower noise to content ratio (90-95% of it will be useful). If you want to be on the cutting edge of vulnerability research, these are the two go-to lists.

milw0rm.org (which has questionable uptime at the moment) has a great database of exploits. If there’s an exploit in the wild, milw0rm will likely have a copy of it. And vice versa, if milw0rm has exploit code for it, you’re likely to see people attempting it.

All of these sites are for *all* vulnerabilities, including many that may not affect you, and if you’re short on time, you want to know what vulnerabilities affect you – and if there’s a patch. Vendor specific mailing lists (or web pages) are your friends here. Sometimes, you have to be a support paying customer to have access to these lists, but the ones I list here are free for everyone to join.

-Windows has several options depending on what you want to get from them.

-Apple has their security-announce list available through mailing list or RSS feed.

-FreeBSD has a whole group dedicated to vulnerabilities, with links to a list of the vulnerabilities in FreeBSD as well as the ports tree.

-Sun has a knowledgebase article that lists all current vulnerabilities and advisories.

-Linux vulnerabilities are generally listed through the distribution you choose to install.
* Red Hat has several public lists for vulnerability announcements depending on the product you’re interested in.
* Debian – debian-security-announce mailing list
* Ubuntu – ubuntu-security-announce mailing list
* SuSE has a web page devoted to advisories.

Whatever operating system you run or administer, find out where the advisories are posted and monitor them for activity. Everything is going to have vulnerabilities sooner or later; you’re not “safe” just because you run an obscure operating system or application. Keep up-to-date and you’ll reduce the surface area for attacks.

After recently upgrading to Windows 7, I installed our company’s SimpleCAPI tool to import some test certificates for a project. While I was unit testing my new code, I discovered some strange things had occurred during the certificate import process. Some native CAPI code I had written was failing with a “KeySet does not exist” error, but only for certain certificates. So, I fired up SimpleCAPI again, deleted the certificates, and re-imported them. After doing that, the unit tests ran fine.

Some time later, I ran into a similar problem unit testing another segment of code, and the same fix worked for that problem as well. After retracing my steps a bit and trying to re-create the error, I found that the keysets could only not be loaded when I had launched SimpleCAPI as an Administrator in Windows 7 to install the certificates, and my unit test project was not run under an Administrator context. However, when the certificates were imported in a SimpleCAPI session that was not launched as an administrator, then the keys were available regardless of the unit test context.

This probably isn’t going to be a problem that’s widely experienced, as 999 times out of 1000 (1), certificates are imported using the standard Windows certificate wizard, not an external application like SimpleCAPI. However, I do need to figure out why this is happening. My guess is simply that the key container created during the certificate import is flagged with administrator access only, so attempting to acquire a handle to the key context in my native CAPI code was failing due to a read/write permissions error, not a problem with the KeySet’s existence.

I also need to fix the CAPI code so that the key handle can be obtained with a read-only context. Hopefully that will get around the problem entirely. Regardless, I took this as a lesson that the “Run as Administrator” shortcut in Windows 7 can have more subtle implications than just granting some extra privileges for an application. This is something that I’ll need to keep in mind when developing Windows applications going forward.

1: 84% of all statistics are made up on the spot.