Attacks/Breaches
1/23/2013
00:26 AM
Connect Directly
RSS
E-Mail
50%
50%

Playing In The Sandbox Helps Developers Learn About Bugs

Using virtual environments, two start-up projects create different ways of showing -- not telling -- developers how and why to prevent bugs

For four months, massive denial-of-service attacks have caused problems for U.S. financial institutions. At the heart of those attacks are a host of servers running Web applications with known vulnerabilities.

While a server-based botnet inundating networks with tens of gigabits of data per second may highlight the danger of Web-application vulnerabilities, developers don't need to wait for their software to be compromised to see such attacks in action. A group of computer security specialists have created Hack.me, a virtual playground where developers can see the impact of various vulnerabilities on almost a score of open-source applications. The aim: to teach developers the danger of vulnerabilities.

"We realized that explaining and educating users about Web application security with theoretical arguments is not enough and has proved a failing approach for years," says Armando Romeo, founder of eLearnSecurity and the Hack.me project. "Countless books have been published on the subject, but we still have developers writing insecure code and management level completely ignoring threats related to Web applications."

Using Hack.me, a developer or security professional can attack a live instance of a vulnerable Web or mobile application to see the impact of different vulnerabilities. Or a developer can upload a version of his own code so that others can attack it in a safe and virtual environment.

"If you break something, you can always start fresh [by] resetting your sandbox," Romeo says. "All these operations literally take seconds compared to hours of server deployment and application configuration you had to go through before."

eLearnSecurity is not alone in trying to use sandboxed environments to teach developers to better secure their software. Startup Bugcrowd aims to give developers a place to offer up their applications to a crowd of freelance pen testers, who compete to find vulnerabilities in the application for a bounty.

"We are working with larger companies who know what bug bounties are but haven't yet been able to implement them, and with smaller companies who haven't had an app sec testing solution that fits their budget requirements until now," says Casey Ellis, founder and CEO of Bugcrowd.

The project has run a number of bounties so far, including one for $5,000 in total rewards that is currently ongoing. Based in Australia, the startup has already started soliciting additional projects. The project could provide an opportunity to developers who may not otherwise have the funding to hire a pen tester, Ellis says.

"Every bounty we've run so far has yielded a third-party 0-day," Ellis says. "That doesn't usually happen under the traditional model and goes to show that the testers are doing a fantastic job."

[Penetration testing is only the first step of self-inspection -- ask internal auditors to scrutinize IT practices beyond compliance to take risk management to the next level. See Go Hack Yourself.]

While the penetration-testing possibilities are intriguing, these types of projects can be invaluable in teaching developers the seriousness of eliminating vulnerabilities in their software, says Jerry Hoff, vice president of the static code analysis division for WhiteHat Security.

"Education is the first line of defense against vulnerabilities," Hoff says. "In a lot of organizations, most developers have no idea about how the technology can be used, or abused, by attackers."

Yet these types of projects should be part of an overall plan to teach developers the best way to code securely and minimize vulnerabilities, and not used as a single lesson with no context, he says. Rather than just scare developers, teach them how to use secure coding techniques to make their code harder to exploit, he says.

"It is a little like a magic trick, but it kind of puts developers in a paralyzed state of fear because of all the things you can do," Hoff says. "It is better to discuss security controls, and let them know why they have to do it."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.