Friday, April 17, 2009

Website threats and their capabilities

Vulnerabilities don’t exploit themselves. Someone or something (“threat”) uses an attack vector ( to exploit a vulnerability in an asset, bypassing a control, and causes a technical or business impact. A diagram found in OWASP Catalyst (pg. 28) illustrates the concept exceptionally well. This is important to keep in mind because not every threat exercises the same technical capability or end-goal. Some threats are sentient, others are autonomous, and their methods are different as is their target selection. While I’ve seen many published threat models, I’ve not seen any specifically focused on the nuances of website security (maybe I missed it?). Website security is much different from other forms of software or business models and deserves special attention in the ways it's handled.

After studying Verizon’s 2009 Data Breach Investigations Report, you learn a few things about what or who we’re up against. Most threats are external, use SQL Injection en-masse, and linked to organized crime. This means they don’t typically have access to the source code or binaries of the custom Web applications they exploit (not that they need it). This threat profile is different from someone analyzing a piece of operation system software to uncover a 0-day who may test locally 24x7 without raising alarms. Also different from scanning a network for an unpatched issues open to a ready made exploit. Verizon goes further to organize the apparent threats into three types based upon how they chose their targets:

Random opportunistic: Victim randomly selected
Directed opportunistic: Victim selected, but only because they were known to have a particular exploitable weakness
Fully targeted: Victim was chosen and then attack planned

To make these a bit more website security specific I took the liberty of crafting some quick descriptions and associated activities a threat might perform as part of their attack vectors as a way of getting things started.

Random opportunistic: Attacks are completely automated, noisy, unauthenticated, exploit well-known unpatched issues and some customized Web application vulnerabilities. Targets are chosen indiscriminately through wide scans and tend to impact the most vulnerable. Typical motivation is to infect Web pages with malware or subtle defacement.

Example: With Mass SQL Injection automated worms insert malicious JavaScript IFRAMEs (pointing to malware servers) into back-end databases and used the capability to exploit unpatched Web browsers.

Directed opportunistic: Attacker with professional or open source scanning tools. May register accounts, authenticate, and customize exploits for custom Web application flaws found easily by automation. Targets are those with valuable data that can be monetized, a tarnishable brand, and penetrable within a few days of effort.

Example: XSS vulnerabilities used to create very convincing Phishing scams that appear on the real-website as opposed to a fake. JavaScript malware steals victims session cookies and passwords.

Fully targeted: Highly motivated attacker with professional, open source, and purpose built scanning tools. May register accounts, authenticate, customize exploits for custom Web application vulnerabilities, and capitalize on business logic flaws. Victims may be defrauded, extorted, and targeted from anywhere to a year or more.

Example: ‘The Analyzer’, allegedly hacked into a multiple financial institutions using SQL Injection to steal credit and debit card numbers that were then used by thieves in several countries to withdraw more than $1 million from ATMs.

By aligning a threats capabilities against a particular security control it becomes much easier to predict and/or justify that controls effectiveness. The same is true for vulnerability assessment results, which SHOULD give some type of assurance or measure of the risk posed by a particular threat. Just randomly choosing a set of vulnerabilities to scan for doesn't exactly give you that.


Anonymous said...

I cannot find any reference to the OWASP Catalyst project anywhere. Where did you find this.

Jeremiah Grossman said...

eesh! Hopefully I didn't just get myself into trouble. I thought it was released publicly already. Anyway, the document I was read was a beta version. I'll ask the author if I'm free to speak of it.

Anonymous said...

I would turn this around just a bit. Vulnerabilities are one form of evidence that one or more controls are not implemented or poorly implemented. This is true for both Web Application and Network vulnerabilities.