icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons icons_061

SOURCE Boston Re-Cap

‹ Previous Post
Tenable Network Security Podcast - Episode 32
Blog Home
Next Post ›
Nessus Spotlight: Scan Template Feature

Two weeks ago, several Tenable colleagues and I traveled to Boston to attend and speak at the SOURCE conference. The SOURCE conferences, founded by Stacy Thayer, are small in size but big on content. Since the conference is fairly intimate (this year’s had approximately 250 attendees), I had the chance to talk to many people in the hallways about security, attend some great talks and deliver a presentation on the state of embedded systems security.


SOURCE Boston was held at the Seaport Hotel in Boston, Massachusetts. The above picture was taken at the hotel looking out over Seaport Lane.

SOURCE continues to be a great conference held in Boston, Massachusetts and Barcelona, Spain. It has a great atmosphere, the caliber of people in information security who attend are top notch and the presentations are great. Tenable submitted three presentations to SOURCE that were all well received and are described below:

Embedded Device Hacking and My Plot To Take Over the World

Paul delivering speach on crutches

Still recovering from knee surgery, I toughed it out and gave my presentation; brace, crutches and all!

I put together and delivered this presentation for the first time at SOURCE Boston. I have previously given talks on this subject, but it had been two years since I looked at this topic and it seemed that little had changed (and if anything, things are getting worse, not better). Therefore, I decided to delve into the topic of embedded systems security from a general sense, identify how bad the problems are and discuss some of the things that could happen, if we don't fix them. To keep the talk entertaining, I wrapped the story around my “fictitious” plot to take over the world. The first part of the presentation covers why attackers would want to compromise embedded systems, including:

  • Information flows through embedded systems (e.g., routers, switches, etc.) and information equals power.
  • Multiple computers' data can be controlled at once as several computers typically pass through embedded systems.
  • Embedded systems are an integral component of controlling water, electricity and sewage treatment (i.e., SCADA).
  • Video game consoles are almost exclusively network connected via routers with embedded systems - most are involved in commerce to allow online gaming and content delivery.
  • Network connected entertainment systems such as Apple TV and Roku link back to your credit card to allow you to purchase content.
  • Home/Business Wireless routers - Route your traffic when doing online banking, Paypal, Ebay, etc.
  • Printers/Fax Machines/Scanners/Copiers - How many times have you printed sensitive information? All stored on embedded systems.
  • Embedded systems contain vulnerabilities that go unnoticed because those who are looking for them cannot possess every embedded system in the world to test.

I then spoke about some common vulnerabilities that could allow attackers to take over embedded systems, such as:

  • Routers being deployed by both end-users and ISPs with default, easily guessable, persistent or no passwords
  • Users are not forced to change the password of the device upon initial configuration
  • Weak management protocols are enabled by default (HTTP, Telnet, SNMP, UPnP, HNAP)
  • Certain protocols cannot be disabled via the management interface (HTTP, Telnet, HNAP)

To address these issues I've created a site called “Security FAIL” (http://www.securityfail.com), where users are encouraged to share their stories of how poorly security is implemented in embedded systems. I hope that this will allow us to influence vendors and ISPs to make security a higher priority, and make the world a safer place.


Vulnerability Management Panel


The vulnerability management panel moderated by Tenable’s Director of Content, Carole Fennelly.

The panel consisted of (from the left in the picture above) Chris Wysopal of Veracode; Bob Martin and Steven Christey of MITRE Corporation; Carole Fennelly of Tenable; Jonathan Klein of Broadridge Financial Solutions; HD Moore of Metasploit; and Kelly Todd of OSVDB. The major issues covered were:

  • Vulnerability Discovery
  • Private Vulnerability Sharing
  • Public Disclosure
  • Vulnerability Database Management
  • Vulnerability Monitoring/Testing
  • Remediation

From these main points, many side discussions came up, including the challenges of managing vulnerabilities in a large organization, dealing with custom applications and their own vulnerabilities, the business of selling exploits and more. I asked the panel why some vendors issue vulnerability announcements with little to no technical details. The panel agreed that this is a common problem, and there is a push from customers and researchers to have vendors release more details. HD Moore had some great comments and stated that the community will sometimes identify the vendors that are trying to hide the details of the flaws and work hard to uncover additional flaws, forcing them to issue more vulnerability announcements, and effectively embarrass themselves while dealing with additional vulnerabilities. The embarrassment being that there are several vulnerability descriptions for different problems, but the text for each one says essentially the same thing.

Steve Christey brought up a very good point that the researcher who finds the original vulnerability may not understand the large scale impact of it and the potential effect on entire classes of products. For example, an unimportant or little used application may be found to be vulnerable because of weaknesses in a library it uses. This may not seem to be a big deal until you determine how many other applications use this same library.

An interesting topic was brought up about selling exploits; there are essentially three potential buyers for an exploit:

  1. Commercial entities - These are legitimate companies who are purchasing "0-day" exploits from researchers, and often including the details of the exploits in their own products.
  2. Governments - Foreign and domestic.
  3. The Black Market - The so-called "dark side" of the Internet has a free market as well.

It was interesting to hear about the competition between the three buyers above. For example, historically the black market paid the most money for a "0-day" exploit, with governments second and commercial entities coming in third. Over the past couple of years governments and commercial entities have raised their prices to compete with the black market. This was an interesting look at the vulnerability management life cycle (VMLC) and underscored the need to design your defenses to withstand attacks that have not yet been published in the media.


How to Detect Penetration Testers


Ron Gula ready to deliver his presentation at SOURCE Boston.

Ron Gula presented a fun talk about detecting penetration testers. Penetration tests are often used as political tools in an organization and it can be as important to detect the (often unannounced) penetration testers as it is to detect a malicious attack. While it is important to test your defenses in a controlled manner, it is also important to understand the limitations of a penetration test. These are often very limited in time, are performed with a limited scope and can create a lot more “noise” than a skilled attacker. It is also important to note that a penetration tester has to follow rules that a malicious attacker would not be concerned with, such as not poisoning the DNS cache of the upstream ISP or conducting a denial of service attack. I believe an important difference between penetration testers of varying skill levels and " bad guys" is that a skilled penetration tester is going to tell you how and why something failed (a system or defensive measure). Everyone else is either going to have no idea or has no reason to tell you. Perhaps the most useful advice is the most simple as Ron presented the following:

"Hardening systems, reducing complexity and adding defenses reduces the attack points and lets you monitor for known outcomes."

I could not agree more! I often feel as though we've lost sight of system hardening. We need to better understand our system configurations and tune them accordingly, reducing the number of running services and enabling security where it is available (even to this day most security measures are not turned on by default).


We are all looking forward to the next SOURCE Boston!

Filed Under: