Tenable Network Security Podcast - Episode 32

Welcome to the Tenable Network Security Podcast - Episode 32

Hosts: Paul Asadoorian, Product Evangelist & Kelly Todd, Compliance Analyst

Announcements

• Several new blog posts have been published this week, including:
  • SecurityCenter 4 Released - Taking Unified Security Monitoring to a higher level
• New Nessus training is now being offered at conferences! - The new course titled "Advanced Vulnerability Scanning Techniques Using Nessus" is now being offered at both Black Hat Las Vegas 2010 and BruCon 2010. It's a two-day course that will put students into a real-world environment where they will have to solve problems and identify vulnerabilities using the advanced features of the Nessus vulnerability scanner.
  
• 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. We would love to hear your feedback, questions, comments and suggestions! We 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 6 open positions listed!


• You can subscribe to the NEW Tenable Network Security Podcast on iTunes! You can also subscribe to the new podcast RSS feed directly.


• Tenable Tweets - You can find us on Twitter at http://twitter.com/tenablesecurity where we make various announcements, Nessus plugin statistics and more!

Stories

• Using "grep" to Find Vulnerabilities in Web Applications - Most tend to believe that finding vulnerabilities requires a degree in computer science and knowledge of assembly language (I tend to picture the person's keyboard as having only two keys, one labeled with a "0" and the other with a "1"). However, this is certainly not the case as shown in this post from the folks over at Bonsai Sec (the creators of w3af). They searched through a software package's source code using Bash commands and were able to uncover a remote command execution vulnerability. Pretty sweet!
• Remotely Exploitable Network Cards! - This attack works by sending packets to a system, which in turn exploits a buffer overflow vulnerability on the network card itself. The network cards have their own memory and RISC-based processor. This means that code can survive a reboot, and potentially access memory directly before the operating system (or even boot loader) loads. The result is a system compromise that can work its way around several layers of protection, and say "so long" to the days where you can just reformat the machine and start fresh. What do we do now? Do we have to include a re-flash of the hardware as well? Is this even possible on such devices as network cards? (For example, some printers ship with static firmware, meaning the end-user is given no means to update it unless they are handy with a soldering iron!).
• Apache.org's Write-Up of How They Got Hacked - I believe that all organizations that suffer a security breach should do this type of write-up. I'm not saying that you have to post it publicly, but circulate it internally for sure. The four most important questions that you should be answering are "What Happened?", "What Worked?", "What didn't work?" and "What are we changing?". The list of what didn't work is usually much longer than the list of what did work. The most important thing is to change something for the better and really pay close attention to the "lessons learned". Otherwise, the breach is just going to happen again! Too many organizations rush through incident response and "just get it cleaned up" without analyzing the incident and truly understanding why it happened and applying those lessons to their security strategies. This applies in different scenarios such as martial arts. It's inevitable that no matter how good you are, if you are in a fight you're going to get hit. The best defense is to just not be there in the first place to get hit. When that fails, you have to be conditioned to take the hit without absorbing too much damage. Once the match is over, your coach should analyze why you got hit and adjust accordingly (for example, maybe you were too slow and should cut back on your beer consumption).
• How to Get Started In Information Security, the New School Way - There is a lot to be said on the topic of getting your start in information security. I wrote an article on this subject some time ago and hoped that it helped people. There have been several other articles on this topic and I strongly suggest that if you are new to the field that you read them, and take from them the items that will help you the most. Each person is different; some people make certifications work for them, others are good programmers and contribute code, and some prefer to contribute to existing projects. The most important thing to know is to do what works best for you, and there is nothing wrong with trying something and failing or deciding you don't like it. It's all part of the process.
• Vulnerable Sites Database - This is an interesting site that has been posting information about sites that contain web application vulnerabilities. They post the main URL to the site along with the vulnerability that was found, but no further information. This is a slippery slope in my opinion. On one hand, they are publicly pointing out vulnerabilities, which can be effective in getting things fixed. On the other hand, they are also giving attackers a way to easily find targets. Furthermore, there is no way to know if the owners of the sites are aware that their web application is vulnerable.