Tenable Blog

Lately I've been thinking a lot about the problem of software security - "lately" being the last 15 years of my life, give or take. It seems to be a topic that's perennially on the horizon, because only a few cutting-edge software companies take it seriously enough to engage in some kind of secure software development lifecycle. I think that we security practitioners have "screwed the pooch" with regards to software security - 'vulnerability researchers' have done a pretty fair job of convincing most vendors that it's useless to even try; whether you get targeted or not has more to do with whether you're unpopular or market-dominating than with whether your software is foundational. Where have we gone wrong? It's simple: we treated it as a security problem. It's also a reliability problem - a quality problem. We asked the users to demand security, but what they needed to be demanding about was software that worked. Not just sometimes, but all the time - even if someone is deliberately trying to make it crash.

Security In The Cloud Is Still Just Security

A recent paper published in the International Journal of Services and Standards titled "A 'cloud-free' security model for cloud computing", written by Manal M. Yunis, outlines six security considerations for cloud computing. Upon reading the six considerations, I can't help but think that they do not present new challenges but merely rehash old ones. Let’s take a look at each of the six common cloud computing security considerations in more detail:

1. Resource Sharing

"On shared services, there is the possibility that another user on the same system may gain access inadvertently or deliberately to one's data, with potential for identity theft, fraud, or industrial sabotage."

The real problem with resource sharing in the context of cloud computing is that software logically separates one system from the next, but not physically. You can think of it as a "virtual server rack"; whereas traditionally you would have a physically separate server from your neighbor, but in the "cloud”, software is used to separate systems. Unfortunately, software is prone to vulnerabilities that could be exploited and in this case lead to complete access to your server or system. A great example of this in action is the "Cloudburst" exploit from the researchers at Immunity, Inc. that allows an attacker in a guest operating system to break out and gain access to the host operating system.

The resource sharing via software problem is similar to VLANs on switches that are controlled by software, requiring you to carefully design a network and be certain your most critical assets are not on the same switch as something less critical. This is a risk-based decision, and must be constantly evaluated whether you are using a "cloud" provider or designing VLANs on a switch.

Physical Access: RFID Badges

This year's competition debuted an RFID badge hacking system. The Red and Blue teams had separate rooms that were governed by badges and a badge reader. The Red team badges were allowed access only to the Red team room and vice versa for the Blue teams. I really wanted to hack the badge system right out of the gate. There were a couple of motivators involved (including the fact that my friend Larry put the system together), and if we bypassed the RFID reader the Red team would gain physical access to the systems after the Blue teams went home for the night.

Before the competition started I mapped out a plan of attack. Since all of the Red team members were in the same room and I had access to their badges, I planned to scan them and record all of the values. This would give me knowledge of the known values, making any other value a potential Blue team code. Before I could scan the badges, I needed to set up a reader. Larry had a reader for players to use, but I wanted to set up one of my own (besides, I did not trust Larry… what if he defected to a Blue team?). After about two hours of fighting with software library installations, failed dependencies and USB drivers, I finally had a working reader. I was using RFIDIOT to do the reading, which are Python scripts developed by Adam Laurie. While it is a great contribution to the security community, the documentation could have been more comprehensive (if you are looking to contribute to an open source project, here is your chance!). Having little to no experience with RFID, it was a challenge to figure out how to correctly configure my reader and set it up to read our badges, but persistence prevailed and just before the competition started I was reading Red team badges.

Welcome to the Tenable Network Security Podcast - Episode 26

Announcements

• Two new blog posts have been released titled "The Value Of Credentialed Vulnerability Scanning and Microsoft Patch Tuesday - March 2010 - "It Won't Happen To Me" Edition.
• You can provide feedback to this podcast and all of our social media outlets by visiting our discussions forum and adding messages to the "Tenable Social Media" thread. I would love to hear your feedback, questions, comments and suggestions! I put up a call for ideas on new Nessus videos, so please give us your feedback!
• We're hiring! - Visit the web site for more information about open positions, there are currently 7 open positions listed!
• You can subscribe to the Tenable Network Security Podcast on iTunes!
• Tenable Tweets - You can find us on Twitter at http://twitter.com/tenablesecurity where we make various announcements, Nessus plugin statistics and more!

Interview - Ron Gula - CCDC Recap

Ron Gula and I discuss our experiences at the 2010 Collegiate Cyber Defense Exercise held this past weekend in Columbia, MD.

"What Am I Doing Wrong?"

I am often asked, "What am I doing wrong in regard to security?". This question is usually in reaction to some event, such as a failed audit, a network outage as a result of malware or worm or a breach that was detected in the environment. I ran into this situation while doing incident response for a large university. It was my job to monitor the network and respond to the major incidents that were occurring (it was also up to me to determine what was "major" and what was not). I worked with many different network and system administrators on campus to help them improve the security of their respective departments. However, this was an academic environment full of students and professors who wanted to work in a free and open environment, which turns out is one of the most difficult to secure!

If a department had a compromise, I would do my best to help them figure out what happened and take measures to prevent it from happening again. A comprehensive assessment would next be performed to gain a better understanding of the security shortcomings and appropriate remediation measures. These types of assessments can be a daunting task for any security professional. Nessus was one of the primary tools we used to get a handle on the vulnerabilities in the environment. While it is important to scan for vulnerabilities such as missing patches or buffer overflows, assessments need to go deeper than that because attackers will use any approach they can to breach a system. A mis-configured system does not necessarily have a CVE or BID entry. The more comprehensive the audit, the better chance I had of making a recommendation that would effect change and result in better security (which really boiled down to me not having to come back in “incident response mode”).