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.

The PCI-DSS (Payment Card Industry Data Security Standard) is a set of requirements for businesses and merchants that deal with credit card information. These standards are designed to protect the customer by requiring businesses to protect sensitive cardholder data. Complying with the PCI-DSS requirements can result in changes to a business data infrastructure, including securing networks, implementing access controls, and creating a robust information security policy.

However, despite the stringent requirements, there has still been doubt about the real-world effectiveness of the PCI-DSS. The idea that PCI-DSS doesn’t make consumer credit card data much safer has been discussed ad nauseum, and not without some compelling evidence. In 2008, 4.2 million credit card numbers were stolen from the PCI-DSS compliant grocery chain Hannaford Brothers.

But isolated instances of failed PCI-DSS policies provide nothing more than anecdotal evidence of the perceived weakness of the standard. To truly examine its impact, a formal study should be done. On September 24, 2009, the Ponemon Institute released the results of such a study. This study (pdf) included survey data collected from people representing a number of different companies and businesses.

Some of the important key findings:

• Cost of PCI is, on average, 1/3 of the overall security budget
• 79% have had a data breach
• 55% of companies focus only on protecting the credit card data and not other sensitive information
• There is uncertainty as to what personell are the most accountable for PCI-DSS compliance
• Smaller companies are less compliant than larger companies (75k+ employees)

From the study, one can deduce that the standards favor larger companies, who are usually better able to conform to the requirements, due in part to larger security budgets and more resources. It is also interesting that the majority of companies surveyed (55%) expressed interest in only protecting the card holder data. This means that other consumer data (such as social security numbers, addresses, etc) could be swinging in the wind with no protection at all. It almost seems as if companies want to adhere to the PCI-DSS just enough to be compliant.

But if companies don’t have a serious vested interest in protecting their customers’ sensitive data (ALL of it), then maybe they’ve missed the point. The PCI-DSS certainly gets merchants thinking about security, but the lengths that they go to achieve this security shouldn’t stop with PCI-DSS compliance. Naturally, no set of standards is capable of covering all fronts– especially not in a landscape that changes as frequently as information security. But if companies don’t take the hint and think seriously about protecting data and securing their systems against threats, then compliance is nothing more than a glorified checklist representing an ineffective baseline for security practices.

If we think of the PCI-DSS as a panacea for cardholder data breaches, then it is indisputably ineffective. However, if we think of it as a guideline and a foundation on top of which real security measures can be built, then it may prove to be quite valuable.

NIST recently released an overview report on the current state of research in security metrics (short story: there are almost none), and some areas where they feel more research is warranted. One of the problems with security as a business process is that managers are being taught process improvements is the way to save money, but with security, there are no obvious metrics to measure to improve the process. Security is subjective, based on the person and the situation, and measurements tend to the objective side of things.

I think that seeing new measurements is really going to improve the overall security landscape – once they’re accepted and used. NIST and the Feds already kind of lead the way with FIPS and Common Criteria (European based), and I think that if they start using a particular metric, the commercial world will follow. One of the detriments to security metrics is that until the last few years, it hasn’t been well studied in universities – the “hotbeds” of research. I think that now we may start to see more metrics coming out as more graduate students start to study it. And if you happen to be a current grad student interested in security metrics, the NIST paper has some great starting points for a thesis.

One of the most expanded targets lately in vulnerability research is Adobe’s Flash. It has become a common everyday occurrence on the web; everything from banners, to games, to file uploads. It’s almost hard to find a mainstream site that doesn’t have some sort of flash application running somewhere within the domain. As a result it has become a target for many attacks. But one thing that hasn’t increased is the amount of time and checking that goes into the flash applications to ensure they are secure.

Read the rest of this entry »

Last time in our web app input sanitation series, we looked at unsanitized input as part of an HTML tag or attribute. This entry focuses on sanitizing SQL queries.

Case 3: Sanitizing SQL Query Data

The basic SQL attack takes advantage of improper sanitation to execute its own queries against a database. This can lead to a database being compromised.

Read the rest of this entry »

GFI LanGuard 9 is a network / PC auditing tool. The tool does a pretty decent job of detecting machines on the network, devices, appliances, and other misc. items. It can also do a fairly deep scan of each local machine for installed software, installed patches, missing patches, open ports, and detecting vulnerabilities that are present. The “Quick Scan” option is fairly quick taking no longer than a minute or two for each machine, and the “Full Scan” no longer than 5-6 minutes per machine.

Read the rest of this entry »

A lot of computer security deals with risk – what are the risks of doing or not doing something? However, risk is not exclusive to computer security, and there are many papers and treatises on how to determine and how to manage risk – you’ll generally find papers on risk in management literature, most often project management. Project managers have to deal with risk all of the time – what if the weather is bad, what if a key employee quits on the project? There has to be a plan in place for these eventualities. The same is true in computer security.

Read the rest of this entry »

Good File Transfer Protocol software can be hard to come by. Luckily there are some very good programs out there for those of us who like to throw data around using FTP. This is where WinSCP comes in– it handles all of your FTP needs perfectly, offering secure copy, secure FTP, and regular plain vanilla FTP (not recommended). With secure FTP, your sessions are encrypted, offering protection from packet sniffers and whatnot. WinSCP supports multiple sessions, saved configurations, handles the SSH host keys just fine, and integrates with the desktop so you can just drag and drop stuff in there all day.

And it’s free. It’s one of those programs that’s just solid all around.

Obligatory screen shot:

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!