The WASS Project which Veracode contributed data to shows some nice benefits to White box (static) over Black box (dynamic) for many serious vulnerability categories. White box overall detects a higher prevalence of many categories which we can extrapolate to having lower FN rates. Now the sample set of apps is not the same so this can only be used as a trend. Static is better than dynamic in 5 out of 7 categories: credential/session prediction, SQL Injection, Path Traversal, Insufficient Authorization, OS Commandeering. In one category, insufficient authorization, dynamic is better and in one category, brute force attack, my gut feel is this is within the margin of error given the different app samples.
I consider credential/session prediction flaws detected by white box to be typically hard to exploit even though it is a real flaw. White box (static) analysis reports this whenever non-cryptographically strong random number generators are used to generate session identifiers or resource IDs. Usually this means standard rand() is used. The SQL injection, path traversal, and OS commandeering are probably found better by static because these are a good sweet spot for static with its 100% code coverage. All that is required is good data flow modeling from web request to tainted function. In this case, database query, file I/O, or system/process calls. Black box not finding as much is likely do to much less coverage of code paths in the application.
Percent of vulnerabilities out of total number of vulnerabilities (% Vulns BlackBox & WhiteBox)
If we consider the prevalence of high risk level vulnerabilities in detailed web application analysis (P. 9) we’ll see that the most widespread is Credential/Session Prediction errors. SQL Injection, Path Traversal and implementation and configuration errors in authentication and authorization systems are also widespread.
Weld Pond and Cult of the Dead Cow to be Featured on Dateline NBC
9.30.1999
The lack of client side security for internet transactions poses a huge
security risk that online banks and others just seem to ignore. Tools such
as BO2K and even simpler keystroke loggers can cut through the
authentication used for “secure” web transactions to allow an attacker to
authenticate as the hapless consumer.
Dateline explores this problem on Sunday October 3rd at 7pm EST. Watch
Cult of the Dead Cow demonstrate the attack and Weld Pond from the
L0pht talk about whatis really going on.
It is shocking how little has fundementally changed in the way consumers perform high value banking transactions over the web. Looking back with 10 years hindsight I have a slightly different way of describing the situation. Banks assume the network is compromised so they use end to end encryption. Banks don’t assume the endpoint is compromised so there is no security protection. In 2009 what is more likely, that your upstream is compromised or the endpoint is compromised? I would say for the average internet user the endpoint is more likely to be compromised.
Has the endpoint water slowly come to a boil and we are happy frogs slowly getting cooked?
Attackers are not going to be satisfied with a simple PII breach any more. The market is becoming saturated with PII. Look at the stats. In 2007, credit card records sold for an average of $10 per cardholder record; in 2009 the same records sell for an average of 50 cents per record. Attackers want higher value than this. They want to control the endpoint. They want access to your online financial accounts. They are succeeding.
Controlling the endpoint within a business can net an attacker $100,000+. In “Real-Time Hackers Foil Two-Factor Security”, Rob Lemos reports that an attacker was able to hitchhike on the computer of an employee of a construction company and issue transactions worth $447,000 in a matter of minutes. This sounds a lot better than 50 cents per record for cardholder data. Getting malicious remote access software installed on the computers of employees that conduct online banking then is a good plan of attack. That is exactly what just happened at PayChoice, an online payroll company.
The Washington Post reports that last week attackers stole email, usernames, and partial password information from PayChoice. They then used that information to target PayChoice’s customers. PayChoice’s customers recieved a phishing attack that was personalized with their PayChoice information. The phishing email contained browser and other client side exploits and also directed them to install a malicious plugin. The hybrid attack was designed to maximize the chances of owning the phished endpoint with the TrojanDownloader:Win32/Bredolab.X trojan. To add insult to injury. Customers who thought they were protected by endpoint security most likely weren’t. Only 5 of 41 AV scanners on VirusTotal.com detected the malware.
PayChoice’s customers are the ideal target for this type of multistage attack. The user that logs into an online payroll service is likely to be the user that logs into a business online banking account since payroll and banking go together in many companies. We can expect to see more attacks like this in the future.
Companies should put restrictions on the endpoints used to conduct online business.
A known set of software required for business should be running.
The machine should not be used for email.
An up to date browser should be used with no plugins.
JavaScript should be limited to a white list of trusted sites that require it.
The machine should only be able to connect to a known set of web sites.
Two factor authentication and up to date anti-virus software is not enough. Limiting the functionality of the endpoint is the only way to be secure. Be on the lookout for anti-malware companies offering a quick fix for this problem. Remember that only 5 out of 41 AV scanners found the PayChoice phishing malware and the percentage of malware detected by AV is decreasing over time.
