Why the Oldest Application Vulnerability Refuses to Die

Injection attacks are an old enemy of the cybercriminal landscape. The precise injection techniques are nowadays as varied as the apps swirling within your organization’s tech stack, but the core focus remains the same. Attackers wish to compromise your organization, potentially stealing and reselling private data, and there’s no better way in that via the very apps you rely on day-to-day. SQL injection aside, there’s a new threat in town. What is NoSQL injection, and what are its dangers?

Injection Attacks Are Everywhere

Injection attacks rely on application vulnerabilities. As a program runs through its everyday processes, an attacker will attempt to utilize oversights in a rushed or patchwork development process to load malicious code within the application itself. This often relies on structured query language (SQL), which is responsible for retaining information or performing activities that would otherwise require authentication for a normal user account to access. The administrative importance of this process makes it a tempting target for any profiteering cybercriminal. Making this worse, SQL code is hard to differentiate from the app’s own code, making self-regulation far more difficult. The goal here is to gain unauthorized access to your device, network and eventually databases.

The popularity of SQL injection attacks have guaranteed their continued presence within the CWE Top 20 and OWASP Top 10. These lists rank the severity and popularity of various forms of attack vectors, and the sheer size of injection’s attack surface makes it reliably placed in the top three every year. Furthermore, injection is a very well-understood class of attack types. This may appear positive on the surface – as legitimate businesses may have a better idea of what to defend against – but cybercriminals have constructed user-friendly code injection suites that even a script kiddie could wield. Many unsuspecting businesses remain vulnerable, and many have no idea until it’s too late.

The Worst Injection Attacks

Due to injection attacks’ popularity, the case studies that include this attack vector are shockingly common. Team GhostShell rose in infamy throughout 2012 and 2015, spiking in notoriety when they targeted 53 of the top universities across the world. Relying almost exclusively upon SQL injection, their initial attack saw the theft – and subsequent publication – of 36,000 personal records. This included the personal details of faculty members, staff, and students.

However, the group was only getting started. Shortly afterward, the group posted the information of 120,000 further students. Modeling themselves as a hacktivist group, the menaces wanted to protest against the apparent decline in the quality of education. Escalating even further, Team GhostShell would then dump the information of 1.6 million accounts from within various departments in the US government. This included confidential NASA records, information from the Pentagon, Federal Reserve, and FBI.

The lasting legacy of the SQL injection attack means that it crops up in some of the oldest and most era-defining cyberattacks of the early noughties. When Heartland Payment Systems was breached in 2008, it swiftly became classified as the biggest ever breach of financial data. Over 100 million cards, alongside over 650 financial companies, saw high-level compromise. Some corporate victims reported $300 million in losses. SQL injection was found to be at the heart of the biggest breach ever seen.

And – even worse – it appears that many of our most vital organizations have failed to learn from the millions of victims and losses caused by injection attacks throughout the years. In 2021, it was confirmed that 35% of educational institutions and 32% of government organizations are still vulnerable to SQL injection.

Types of Injection Attack

SQL injection may be a looming, persistent threat, but it’s far from the only injection technique on offer. The injection techniques in the arsenals of aspiring cybercriminals number over a dozen; the large variety stems from the individual, complex pieces of infrastructure within and around apps. Code injection refers to any weaponizing of the code within the application language, which is then used to escalate privileges and compromise the associated web server.

SQL injection – like many other types – relies on a vulnerable user input box. Imagine a search function that returns relevant information from your database. An attacker could enter a string that – when read by the database – returns results that should remain hidden. This can include other users’ information and personal contact details. The SQL commands lend a lot of power to the attackers, but a more recent danger is a close cousin – NoSQL.

The difference between NoSQL and SQL injection can be largely boiled down to the syntax and grammar that the underlying process relies on. However, NoSQL databases do face a higher risk of injection attacks, thanks to the fact that NoSQL has fewer consistency restrictions than its SQL counterparts.

Other components within each app can be just as vulnerable to injection, however. Carriage Return and Line Feed (CRLF) is used by apps, HTML pages and operating systems to denote the end of a line of code. CRLF injection describes the attacker implanting an unexpected character or sequence into the existing CRLF. This then splits the HTTP response header, allowing attackers to plant new lines of code within the app. This attack may be combined with Cross-site Scripting (XSS).

Server-Side Includes (SSIs) are tools within a HTML page that help handle dynamic content. As this content is user-specific, the attacker can weaponize input fields, taking advantage of the lack of data sanitization between the input and its resultant HTML files. This way, an attacker can send code to a web application, and have the malicious output be run by the server. Note the difference between injection and cross-site scripting attacks. The vulnerabilities created by cross-site scripting vulnerabilities affect the end-user’s browser; injection attacks compromise your host server itself.

Managing the Threat of Injection

Injection is a lurking threat to any tech stack; preventing it demands a few key pointers. First and foremost, your server needs to validate and sanitize any instance of user input. Special symbols can be a warning sign for malicious activity; searching for and reviewing line termination characters or command delimiters is a great first step towards an injection-free space. This fits into a vital overarching philosophy: treat all data as untrusted. Never rely on an app that simply allows raw user input into the application code.

For organizations not using their own bespoke applications, there are real blindspots lying just beneath the surface of each application. External solutions such as a RASP can guarantee the security of your tech stack by monitoring an application’s behavior. If any suspicious activity is found, the RASP solution automatically terminates it. This is how, even if an app remains vulnerable, your organization can beat the age-old threat of injection.

Leave a Comment