Cybercrime has evolved significantly over the years. While initially based mainly on social engineering and phishing, hackers today implement a wide range of techniques to exploit vulnerable applications with porous code. Code injections have arguably become the weapons of choice for hackers and are constantly being used to perform high-profile hackings worldwide.
Code injections have been regularly starring in the various vulnerability reference lists. They even took the first place in the 2013 OWASP Top-10 due to the severe technical damages they cause.
While software in the 90s required the use of floppy and CD installation discs, all modern web applications are based on code that runs on browsers. This engulfs a wide range of fields, most commonly e-commerce, banking and retail websites. These applications require the entry of usernames and passwords, something that hackers are constantly looking to manipulate.
For example, SQL injection (SQLi) vulnerabilities keep on surfacing on a regular basis.
Just a few months ago, a glaring SQL injection vulnerability was exposed in WP-Slimstat, a commonly downloaded and widely-used WordPress plugin. The WP-Slimstat plugin, which basically serves as a real-time analytics tool, has been downloaded over 1.3 million times. Anybody who has not applied the latest security patch is still vulnerable to this type of code injections.
In a separate incident over 100 thousand Archos customers were affected due to a SQL injection attack that took place during the Christmas holidays. While passwords and credit card details were not stolen, thousands of personal and corporate email IDs were harvested from various French and international servers. Official sources admitted that “unfiltered website input” caused the breaches.
A wide range of malicious activities are made possible with the “help” of code injections:
Top-5 Code Injections Used Today.
Also known as the mother of all injections, the SQL injection is arguably the most commonly exploited injection vulnerability in hacking circles. This is basically the exploiting of the SQL language, which is being used for managing data and interacting with databases/servers since the mid-80s but has not adapted to the changes and advances in technology.
The SQL language can be broken down to major language elements – Queries, Clauses, Expressions, Predicates and Statements. For example, expressions produce scalar values or plain tables that consist of columns and rows of data. Most importantly, queries retrieve data based on specific criteria and are widely used in hacking procedures.
The command most relevant to the SQL injection is “and 1=1“, which always returns a positive answer. This feature is almost always used while hacking into vulnerable SQL databases. Apostrophes and Semicolons also are integral parts of the SQL grammar and feature extensively in SQLi cases. Vulnerable web and mobile applications are not capable of handling SQL injections.
A typical SQLi attack is initiated with the entering of the “‘” character into the application’s search field. Unprotected applications return elaborate and details error messages that serve as pointers and help the hackers manipulate their way into the databases. Data harvesting and manipulation then becomes a real possibility and the application is basically compromised.
XSS relates to flaws in both client and server side programming. The XSS payloads trick the victim’s browser into executing dangerous commands, leading to cookie theft and data manipulation. Comment sections of trusted interactive websites are common hunting grounds for hackers going the XSS route, where malicious URLs are posted. Once clicked, the victim’s computer is compromised.
There are 4 main types of XSS attacks:
The main damages caused by XSS include identity theft, session hijacking, manipulation of URLs and stealing permissions. It’s also possible to illegally record keystrokes and harvest GPS/location data.
3 – LDAP injection
These code injections are quite similar to SQLi. Lightweight Directory Access Protocol (LDAP) is an open and vendor-neutral directory service protocol that runs on a layer above the TCP/IP stack. It provides the appropriate mechanism for accessing and modifying data directories, things that are commonly used today while developing intranet and internet (web) applications.
LDAP servers store information that is accessed by clients using LDAP sessions (usually with pre-defined time-outs). The most basic actions that are taken once the session is initiated are the adding, deleting and modifying of entries. LDAP injections are basically crafted queries. When LDAP statements are sent along with code injections, vulnerable LDAP servers can be hacked.
If the application is vulnerable, inserting “*” into a LDAP query can possibly return sensitive unprotected information to the malicious attacker, who can then initiate a full-fledged cyberattack. Advanced LDAP injections can also allow the attacker to enable the execution of arbitrary commands to gain unauthorized permissions and even modify information within the LDAP tree.
OS command injection attacks occur when the attacker attempts to execute system level commands through vulnerable web applications. Applications are considered vulnerable to the OS command injections if they can be tricked into executing unauthorized system commands via the web interface. In other words, hackers can run arbitrary commands on the compromised server.
Like the aforementioned injections, OS command injections also involve the injecting of malicious elements into valid commands. These commands can be both blind and error-based, with the latter being more inviting to cybercriminals. Meta-characters (&, |, 😉 are usually used to merge commands and create malicious OS command Injections.
This type of code injection changes the resource identifiers used by the vulnerable application to execute malicious tasks. Once the malicious attacker is able to define resources such as file names or port numbers, he is basically handed a free-entry to the application servers and databases. As a result sensitive unprotected data can be harvested, modified or even deleted.
All applications opens a network socket to listen to incoming network connections. Once the vulnerable application allows the user to define the parameters of the network sockets, danger looms. For example, the insecure application can get a port number from a HTTP request and create a socket with the port number without performing any kind of validation.
Traditional security solutions such as the commonly implemented Web Application Firewall (WAF) can typically detect/stop only about 70% of the code injections, assuming it has been configured properly. Configuring WAF settings is a cumbersome process that is not optimal in most cases due to the numerous changes made to application code in modern development scenarios.
Input validation is considered to be the most effective way to protect applications from code injections, but this should be done on both the client-side and also the server-side, out of the hacker’s reach. This requires the introduction of security measures within the application code itself. Hence, the focus has now shifted towards code integrity.
Organizations have a wide range of products and methodologies to choose from today.
Dynamic Application Security Testing (DAST), also known as Black Box testing, needs built code to work, which means vulnerabilities can’t be detected early in the Software Development Life Cycle (SDLC). Also, its effectiveness in locating non-reflected flaws (like XSS) is unsatisfactory, as it only analyses requests and responses. DAST can’t find flaws that don’t generate feedback when triggered.
Penetration (Pen) Testing is another widely acknowledged, albeit limited and uncomprehensive tool. It’s typically used as a complementary security evaluation after the development is complete.
This is where Static Application Security Testing (SAST) shines. White Box testing solutions such as Static Code Analysis (SCA) hit the nail on its head thanks to their ability to scan source code and locate code injection flaws early in the development process. Developers have the luxury of knowing where exactly to insert the mitigation solutions and tweaks to ensure a robust and secure application.
SCA provides a wide range of benefits. For example, organizations using SCA can:
Code injections are arguably the hacker’s best friend and organizations have to prepare their applications to withstand the onslaught. While blacklisting and whitelisting for user input can help the cause upto a certain extent, only secure application development and high application code integrity can get the job done and eventually help create a safe cyberspace.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.