Weaponisation trumps skill

By on

The rate and complexity at which exploits are being "weaponised" is rapidly increasing.

Security practitioners have long preached risk management principles -- and more specifically threat management -- as a way to help organisations understand, rank and prioritise threats against their environment.

The key goal of these risk management activities is to balance the cost of protective measures and achieve gains in mission capability by protecting their IT systems.

However, though a primary goal of any threat assessment is determining “probability of occurrence” or “likelihood,” we frequently see that likelihood is the one area organisations consistently fail to measure correctly. The result can sometimes be likened to a homeowner spurning bolt locks and investing in an anti-missile defense system.

The only constants of information security are that attacks and exploits continually evolve, creating a moving target for security defense measures.

Unless you're a dedicated security researcher, staying current with the latest trends and tools in the hacker community is virtually an impossible task and anything less than a dedicated, professional effort can lead to a dangerous sense of false security.

The latest evolution is that the profiling of targets and the weaponisation of exploit techniques is becoming more common. Put another way: weaponisation trumps skill.

In the past, organisations and security professionals looked at vulnerabilities and determined a rough estimate of expertise needed to exploit them. Labels like “hacker,” “script-kiddie,” or “novice” were often used to designate the skill-level needed to exploit a particular issue.

Based on these estimates, companies would often de-prioritise fixing an issue because they considered it exploitable by only a limited subset of elite hackers.

Believing their organisation was not a big enough prize, typical rationalisations might run: “If only a truly elite hacker can do this, what's the chance they will come after me?” or “Why waste US$5,000 dollars fixing an issue that stands only an extremely small chance of ever being exploited?”

It is time, however, to re-think this logic; the rate and complexity at which exploits are being “weaponised” is rapidly increasing. Attackers commonly use Google (and the weaponised version of the search engine: The Google Hacking Database) and other caching systems to find companies that appear susceptible to an exploit. An attacker can then pick a target without ever having touched the target's site.

Sophisticated vulnerability exploits are being put into easy-to-use code and tools that enable exploitation. That which starts out as a “hacker” skill-level exploit often turns into a “novice” exploit in months and sometimes days.

Well-known open source (Metasploit) and commercial tools (SaintExploit, Core Impact) provide a wide base of vulnerability exploits to tap into, and more specialized tools are being developed daily. Highly complex vulnerabilities such as SQL injection, XSS (cross-site scripting), and even social engineering are quickly being reduced to low skill level attacks.

For instance, SQL injection, once deemed a fairly technical exploit, can now be executed using one of dozens of easily found tools like SqlMap and Absinthe. Within seconds, these tools can mine and return the contents of databases. This vulnerability is now so common and easy to exploit it is being added into the arsenal of weapons botnets use for exploitation.

XSS, another popular exploit, has had its attack vectors grow substantially and its vulnerability detection greatly simplified. Tools like XSS Proxy Tool, Syhunt's SandCat, and RSnakes XSS Cheat Sheet now make an application's vulnerability to XSS much simpler detect and to exploit, no longer requiring a “hacker” level skill set.

However, in spite of this reality, there appears to be some confusion, even within the security community, concerning the “likelihood” of XSS, its weaponization, and the risk associated with it.

Recently, both McAfee's and ScanAlert's website protection services have been called into question after many “protected” websites were found to be vulnerable to XSS and not in compliance with the PCI DSS (see http://www.xssed.org).

Even a non-technical exploit like social engineering has become weaponised. Security is typically viewed as analogous to a chain: only as strong as its weakest link.

People are consistently found to be the weakest link in any security program, but people are unfortunately one of the last places companies focus their security efforts.

With tools like Patervas' Maltego (formerly eVolution), it is now possible to quickly and efficiently profile companies/employees and harvest vast amounts of information about them to aid in effective social engineering attacks.

Attacks that used to take hours or days to build manually can now be done in seconds. An attacker armed with interconnected and layered details concerning a company and its employees can design highly targeted social engineering campaigns that have an alarming success rate.

The security space is trying to adapt to this new reality; the CVSS scoring system is being tuned to give security professionals and organisations a better way to evaluate risk and prioritise vulnerabilities.

“Access Complexity” is part of its base risk equation, and “Exploitability” is included in the temporal score metrics. However, these scores aren't always accurate out of the box, and they aren't always modified by tool vendors once imported from the National Vulnerability Database.

As an example, PCI mandates the use of CVSS (1.0, converting to 2.0) in their certification, but only the base score metrics are used in evaluating vulnerability severity. As a result, several key components of risk are left out.

It's easy to see how security professionals and organisations can easily devalue the true risk posed by the threat of compromise. Risk management programs have at their core some equation or model to quantify risk.

But those models are only as good as the data plugged into them. If you haven't already done so, take a look at the underlying assumptions and data used in your organisation's risk management program.

See original article on scmagazineus.com

Most Read Articles

Log In

|  Forgot your password?