Blog :: by Wade Woolwine

Enterprise Vulnerability Metrics, The Tool

In order to effectively implement my plan for tracking enterprise vulnerability metrics and their associated data points, it was clear that a custom application for data entry and report viewing would be required. As such, I wrote a PHP/MySQL web application with the following features and functionality.

Data Model – In order to structure the collected data in the database in a manner which facilitates data extraction from reports, I had to define the reporting needs early in the development process. By doing so, I was able to create a relational data model which makes reporting fast, accurate, and reliable.

Data Input – I’ve provided a series of HTML forms which provide the user with all the data points from my previous article. These forms have been designed with a heavy focus on ease of use and rapid data entry. To provide these features, the input for the required data points have been grouped logically and implement a feature for quick input where the user can select from a list of recent entries for the given data points (eg: recent contacts, recent CVE numbers, etc).

Reporting – I’m a big fan of keeping reporting as open as possible: it makes life much easier down the road. As such, I created a reporting framework which is capable of outputting a list of vulnerabilities based on a query for any data point stored in the database. For example, if you want to know which reports are associated with a given manager, business unit, vulnerability class, or keyword just select your preferences on the search page, and view the results.

Statistics – A data collection tool is worthless unless you have a way to quickly determine the characteristics of the data stored in the database. As such, I created a statistics page which provides the viewer with a snapshot of the vulnerability metrics based on similar characteristics. The following details the statistics and their intended purpose:

Vulnerabilities Created and Resolved

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period.

Vulnerabilities Created and Resolved per Category

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability category.

Vulnerabilities Created and Resolved per System Type

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per system type.

Vulnerabilities Created and Resolved per Source

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability source.

Vulnerabilities Created and Resolved per Impact Rating

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per impact rating category and value.

Vulnerabilities Created and Resolved per Risk, Severity, and Probability

Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per risk, severity, and probability rating.

Vulnerabilities Created and Resolved per Domain

Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per domain name.

Top Report Owners

Simple count of vulnerabilites created and resolved with average time to resolve in the given time period per report owner (the security engineer assigned to the vulnerability).

Top Business Units

Simple count of vulnerabilites created and resolved in the given time period per business unit listed in the contact field.

Top Managers

Simple count of vulnerabilities created and resolved in the given time period manager listed in the contact field.

The tool also contains several usability features such as mass actioning of vulnerabilities (eg: resolve multiple reports at once), a data authorization model defined by report owner (owner can edit and view, others can only view), and a “my” page which displays reports relevant to the user.

In the future I hope to seperate the parts of the tool which are specific to my environment and open source the project so that others can gain visibility into their vulnerability posture.

Posted in Enterprise Security, Research, Security Tools, WebAppSec | Comments

Why use the “secure” option for cookies?

Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.

To minimize the risk of exposing the session identifier on the network in cleartext the data going between the visitor’s web browser and the web application server must be encrypted using SSL. Baring any other vulnerabilities in the code such as XSS, code injection or SQLi one would assume that the session identifier is well protected…Not if the Secure only cookie flag hasn’t been set.

Per RFC 2109

The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.

The user agent (possibly under the user’s control) may determine what level of security it considers appropriate for “secure” cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session’s interest to protect the cookie contents.

This excerpt of the RFC simply means that if a cookie has the “Secure” option enabled, the browser must only send the cookie when the HTTP request is performed over SSL. The importance of this option is highlighted by a recent attack by Sandro Gauci of Enable Security.

In his paper (and video), Sandro demonstrates how an attacker on the same network physical network can use his tool (SurfJacking) to hijack another user’s authenticated SSL session with GMail and successfully obtain the session identifier. His approach is so simple, I regret not having thought about this myself:

1. Victim logs into GMail using SSL*.
2. Victim uses the same browser to visit another web page (while keeping the GMail window open)
3. The SurfJacking tool detects step 3 and issues a fraudulent 302 HTTP Response code (Permanently Moved) pointing to http://mail.google.com
4. The victim browser accepts the redirect and initiates a connection with http://mail.google.com using the same session identifier as was used in the SSL connection.
5. SurfJacking identifies the cleartext GMail session identifier and logs it for the tool operator.
6. Attacker accessing the victim’s GMail account.

* The browser connection setting in GMail must be set to Don’t always use HTTPS (which is the default)

Sandro Gauci has written a paper and created a video demo to illustrate the attack. The video shows the SurfJacking tool in action as well as mitigating the attack by enabling SSL only cookies with the “browser connection” setting in GMail. Please be sure to check them out.

Posted in Enterprise Security, Implementation Security, Security Design, Security Tools | Comments