This is the second chapter of my blog series focusing on the vulnerabilities and exploits involved in a website compromise following on from the previous chapter covering the reasons for which website access can be blocked.
New age Internet, a web of images, videos and user-friendly interactive content, is delivered by tools like image/video gallery, sliders, gadgets, CMS, etc., for quick design and implementation.
Because of the complexity of these evolving web technologies, there is a high possibility that security vulnerabilities in web applications might be overlooked by both the developers and the quality assurance process. Such vulnerable web applications are susceptible to hackers and bots to break into a victim’s computer and to infect websites to spread malicious files or send spam messages.
The most common web application vulnerabilities are described below.
Code Injection
A huge number of data breaches happen via code injection attacks, i.e. the injection of malicious code specific to a vulnerable application either on the victim’s computer or on the website host server into a web application in order to carry out silent execution of the injected malicious code. This kind of attack includes Cross-Site Scripting (XSS), SQL Injection, XML injection, RCI, Header Injection, Log Injection and Full Path Disclosure. To have a clearer picture of code injection, let us look at the XML injection example shown below.
Let us consider the following form and actual inputs:
Name: test
Password: test123
Mail: test@test.com
Data is sent to the web host as follows:
http://vulnerable.site/add?name=test&password=test123&mail=test@test.com
Expected XML result at the server side is:
<user>
<name>test</name>
<password>test123</password>
<id>101</id>
<mail>test@test.com</mail>
</user>
A valid user id 101 is created for the user “test”.
Now, let us suppose a hacker submits an XML code as input in one of the aforesaid form fields to control a user account.
Name: test
Password: test123</password><id>0</id><!–
Mail: –><mail>test@test.com
Now, the data sent would be in the format,
http://vulnerable.site/add?name=test&password=test123</password><id>0</id><!–&mail=–></mail>test@test.com
Modified XML result is:
<user>
<name>test</name>
<password>test123</password>
<id>0</id>
<!–</password><id>101</id><mail>–>
<mail>test@test.com</mail>
</user>
In the above example, as the hacker has entered the XML code “</password><id>0</id><!–” along with the password “test123” in the password field and “–><mail>” along with the mail “test@test.com”, the website server generated id “101” is commented out and a possibly pre-existing id “0” is assigned to the user “test” via password and mail parameters provided by the attacker. Now the hacker can avail the privileges or the functionality associated with the id “0”, thus severely violating the security objective of access control.
Broken Authentication and Session Management
Many developers prefer relying on their own, custom authentication and session management schemes than using the standard authentication and session management methods. As seen in cases earlier, custom schemes regularly fail in functionalities such as password management, sign in, logout, timeouts, secret question, account update, etc.
Some common flaws attributed to the failure cases are listed below:
● Storing credentials in plain text, i.e. without hashing or encrypting them.
● Weak account management modules (e.g. account creation, account deletion, change/update password, recover password, etc)
● Session IDs
- exposed in a URL
- that do not properly timeout or are not validated during logout
- that are not updated after a specific time period once logged in.
● Confidential data transfer over unencrypted connections.
In the example below, a movie-booking application exposes the session ID in the final URL as shown below,
http://mvie.com/hindi/book/?movie=pk(2014)&time=3,6,9 &sessionid=2QZABDJ3NDXYXK5CJ8N290
Now, if an authenticated user shares the above link with others, the allotted sessionid will also be visible to the receiver. When the receiver accesses the shared link, he/she will have the privileges associate with that session ID and can therefore hijack the session. These scenarios can cause adverse effects in case of gift vouchers, saved credit card details, etc associated with the authenticated user.
Security Misconfiguration
Secure configuration of an application stack including operating system platform, web server, application server, database, framework and code is one of the primary goals for developers and system administrators. Security misconfiguration can occur at any level of an application stack. 
Exploiting such misconfigurations, ranging from failure to apply appropriate patches, use of default accounts, failure to set useful security headers on a web server, use of unnecessary services and disabling platform functionality could grant unauthorised access to an attacker.
For example, consider the scenario where the server XYZ has a few java class files (compiled Java source code files) hosted, but unfortunately has directory listing is enabled, unknown to the administrator. If an attacker manages to discover that the server XYZ’s directory listing is enabled, the attacker would be able to collect the compiled code and reverse engineer it to get source code.
Format String
Exploitation of Format String occurs when the submitted input string is misinterpreted as a command by which the attacker can trick the concerned application to read values off the stack, induce a segmentation fault, or execute a user supplied string as a code, to cause an unexpected behavior that could compromise the stability and security of an application, thus potentially allowing execution of malicious code by a remote attacker.
Intelligent fuzzers are used to automate fuzzy input supply to the application, with the intention of crashing the application and generating errors that can disclose sensitive information. The most common C runtime functions printf(), fprintf(), sprintf(), snprintf(), scanf(), etc., process data based on a format string and %x, %s, %n, %%, %p, %d, %c, %u are some of the most common parameters used in this attack.
For example,
Let us discuss the following C code,
#include<stdio.h>
#include<string.h>
int main(int argc, char** argv)
{
char buffer[100];
strncpy(buffer, argv[1], 100);
printf(buffer);
return 0;
}
In the above C code, the printf() function takes one argument “buffer” instead of the usual two arguments, format specifier and the associated variables. An attacker can trick the printf() function in the above code by passing an input string “%p %p %p %p %p” to the buffer where %p is the format specifier of a pointer. During execution, printf() will look at the argument as “%p %p %p %p %p”, consider that it has 5 arguments and will print the next 5 addresses on the stack (for 32-bit architecture) from the current position. Possible output could be:
=> ./output.out “%p %p %p %p %p”
0xffffdddd 0xf7ec 0x1279 0xffffdbdf 0xffffdbde
Thus, a format string vulnerability gives the attacker the ability to read an arbitrary value from an arbitrary address and potentially perform malicious activity.
Apart from exploiting web application vulnerabilities, hackers may also avail of weak password policies, insecure FTP/HTTP connections, outdated third party add-ons and server vulnerabilities to compromise access to a website host. To accomplish an attack successfully, attackers may combine two or more vulnerabilities together on the target webserver.
In the next chapter of my blog series, I will describe the consequences faced by users visiting a hacked website, along with a few mitigation guidelines for the webmaster.
Images Courtesy:
ronkealao.com
Priyal Viroja, Vulnerability Researcher, K7TCL
If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
https://labs.k7computing.com/feed/
