Over the years, Mitre, the MIT research group, has been analyzing software bugs and missteps that hackers have been able to exploit. Their Common Vulnerabilities and Exposures (CVE) classifications are something of a de-facto standard used for describing the root software causes in an attack. Working with SANS, the Mitre CVE team has come up with a list of the Top 25 Most Dangerous Programming Errors. Below we take a journey through the top five.
1. SQL as a Lethal Weapon
Who would have thought that SQL, a database query language, has a dangerous side? SQL Injection works by taking advantage of bad web application code that fails to sanitize user input. Any input that comes from a user (e.g., a search term in a search box) cannot be trusted. More specifically, raw user input should never be used in a SQL command string. Ever.
Get the Free Pen Testing Active Directory Environments EBook
For example, in http://abankcompany.com?tag=pci, the part after the “?” might contain additional toxic SQL commands that, if not properly sanitized by the backend web code, could cause serious damage.
A request containing: http://abankcompany.com?tag=pci union select 1,2,3 would reveal data in columns of a table off limits to users. Or even more maliciously, www.abankcompany.com?tag=pci; drop table user; could be used to remove a key table.
Luckily, most modern web programming frameworks provide built-in methods for validating user input, though nothing prevents programmers from ignoring them.
You can read more here about how to test your web site for this deadly vulnerability.
And in real life, perhaps …
2. Ninja OS Commands
An OS Injection vulnerability is somewhat similar to the SQL variant, but this time hackers convince erroneous applications to execute commands at the OS level instead of the database level. Again the problem is improper validation of input, and hackers are then able to sneak extra commands through the app interface.
If the app runs at a higher-privilege level, this can be a backdoor into running shell commands— say, the mortal rm –rf *.*— with root access permissions
One way to defend against OS injections is to use whitelists—a restricted set of commands that can be executed by the app or server. For example, in Microsoft Windows there are software restriction policies accessible in the Group Policy Object (GPO) editor to control the commands and APIs that an app can execute, thereby preventing it from going rouge.
Software Restriction Policies in the GPO Editor
Source: http://technet.microsoft.com/en-us/library/cc786941(v=ws.10).aspx
3. Stack Attack
Buffer Overflow is a classic hacker exploit that’s been around since the dawn of the Internet. It is somewhat similar to the previous attack, but it focuses on vulnerable computer languages—especially C and C++.
To understand how it works, you have to get very much into the weeds of computer language runtime environments. This one cleverly takes advantage of a lack of checks on storage boundaries in the C language family. Our diagram below explains it all.
Special runtime consistency checks or whitelists (see above) are effective in preventing or limiting the damage of these types of attacks.
4. Crossover Hit
Mitre calls Cross-site Scripting (XSS) “one of the most prevalent, obstinate, and dangerous vulnerabilities”. When we’re browsing, we assume that the web page that comes back, along with any scripts embedded in it, originate from that site or domain. But that’s not the case when hackers do their work.
As in SQL Injection, Cross-site Scripting wedges code—generally Javascript, but also other web languages–directly into the URL. Web pages are often dynamic—generated by PHP, Python, ASP, etc.—and hackers find weaknesses in the server-side web page software to allow their own scripts to be directly inserted.
How do you stop this attack? The Open Web Application Security Project (OWASP) has their own XSS “cheat sheet” that lists the bad HTML with holes that allows the scripts to be injected.
5. Come on in!
Let’s say your company has web software that’s performing critical functions—creating a new bank account, transferring funds, or displaying sensitive financial information. Of course, the app initially checks authentication when the user logs in. But either the actual software is not doing authentication checks or is not using a standardized authentication function at the point in the software where a critical transaction is done.
Result: hackers exploit weak or improper authentication code in order to manipulate critical parameters used by the software. Typically, this is done by directly passing parameters in the URL—again, similar to the SQL Injection attack—or else by manipulating parameters in a web cookie.
Mitre recommends using standardized libraries to carry out these authentication checks rather than relying on customized or ad-hoc approaches.
What’s wrong with this code?
Source: http://cwe.mitre.org/data/definitions/287.html
Image credits: Panoramic Tiger, Cindy Ng
