There’s a lot of very unique, creative, and devastating cyber threats out there. The first inclination of a defender is to collect news of the new and terrifying and concentrate on network security defenses accordingly. This is completely understandable and mostly wrong. The majority of actual attacks, rather than proofs of concept, use simple and common vulnerabilities that in some cases are decades old. As an example, Facebook and Google recently fell victim to business email compromise. We’ve discussed on the blog previously that this is not much more complicated than standing on a street corner and politely (or impolitely, depending on the company you’re spoofing) asking for money.
OWASP is a group of security professionals who aggregate and publish this second type of vulnerabilities – boring, but very common and very commonly exploited. They recently published a draft list of the top 10 security vulnerabilities of 2017. While intended for developers seeking to code more secure applications, the top 10 list is based on actual survey data of threats seen in the wild and serves as a great starting point for organizations struggling with security priorities. Let’s take a look and see how long they’ve been around prior to publication.
OWASP Beta 2017 Top 10
Injection
Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. SQL injection was first seen possibly as early as 1998. Detailed info on mitigations can be found here.
Broken authentication and session management
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently). The earliest online reference I could find to a Man in the Middle attack was 2001, but given that cookies were first introduced in 1994, the attack almost certainly has a longer history in the wild.
Cross-site scripting
XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. XSS was first discussed by Microsoft engineers in 2001. Mitigations generally include adhering to coding best practices and a robust testing program prior to release.
Broken access control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. This is a vulnerability that predates computers, and will still be seen after the singularity. The easiest patch is to use a robust threat model to determine the least necessary privileges for each user.
Security misconfiguration
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date. Again, misconfiguration of security measures predates their application to computers. An auditing and red team program with teeth can assist in programs being appropriately configured before they hit a production network.
Sensitive data exposure
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. APT groups have made sensational use of this vulnerability, but so have amateurs working from public data. Including social engineering in red team tests and having defined legal policies in place covering disclosure of company data can diminish exposure.
Insufficient attack protection
The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks. This is a catch-all covering security programs and applications that are ill-conceived, underfunded, or non-existent. Failing here is largely a policy problem.
Cross-site request forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim. CSRF has been seen referenced as far back as 2001. Like XSS, it can be mitigated by adherence to best practices, in conjunction with security testing.
Using components with known vulnerabilities
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. Continuing to use any sort of code with known vulnerabilities is an issue seen almost everywhere, up to and including the US government. This is a very old issue and must generally be patched on the wetware side of the network.
Underprotected APIs
Modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities. Testing 3rd party APIs can be difficult, but not impossible. One approach would be to determine the technologies underpinning the API with a site like https://builtwith.com, and then run pen tests against those technologies.
As you can see, most of these are relatively old and not all require a great deal of difficulty to exploit. What they require is time and attention, along with mature security policies ensuring organizational components work together towards a fix. Unlike arcane APT toolkits, the above vulnerabilities are used indiscriminately. Studies have found up to 65% of observed companies demonstrate exposure to SQL injection, for example. Starting with the old, boring, and extremely effective threats can bring some immediate results to defenders. For more on the top 10, and info on the finalized list when it’s released, check out owasp.org.
William Tsing
