Web Vulnerabilities And Exploitation - Compromising The Web

Web Vulnerabilities And Exploitation - Compromising The Web

• 1.
  Web vulnerabilities andexploitation Compromising the web Eva Tanaskoska Student, FCSE Skopje, Macedonia evamolotow@zeroscience.mk Vlado Velichkovski Student, FCSE Skopje, Macedonia v.velichkovski@hotmail.com I. ABSTRACT One of the main problems of all big companies is how their applications are secured from cyber attacks. New types of vulnerabilities and attack vectors are being developed every day, therefore they pose a potential threat to all applications that rely on some kind of web technology. This document explains the most common and most dangerous web attacks as well as techniques how to secure your infrastructure from being compromised. We focus on SQL injections, XSS, CSRF, RFI/LFI and Server Side Includes. We discuss the attack vectors of we b vulnerabilities and exploitation schemas. However, regardless of the security measures taken and defenses being deployed, there will always be a way in. Nevertheless, security analysis provide a valuable insight that can grant the advantage over said attackers and allow us to stay one step ahead. II. INTRODUCTION Web servers nowadays seem to be vulnerable to the most basic attacks which tend to get more sophisticated day by day. Attacks like XSS which are deemed as low-risk are being combined with other low-risk vulnerabilities to forge a more sophisticated attack and compromise a web server. Improper configuration and inability to deflect such attacks can prove devastating to a network, corporation, or anything of the like. However, as the attackers' arsenal gets more complex, so do the security researchers'. Security experts all around the world do their best to discover 0day vulnerabilities and weaknesses before the malicious attackers do in order to patch and fix said vulnerabilities. Unfortunately, administrators all around the world don’t pay as much attention to security as they should, which leads to compromising sensitive information, business damage and ultimately, loss of company value. Securing the network infrastructure should be a priority to administrators, as well as raising the employees’ security consciousness, considering the human naivete is the weakest link in the security chain. Cyber crime has grown considerably in the past few years with the development and use of technology, thus becoming a problem which can not be ignored. Recent statistics have shown that 96% of the tested applications have vulnerabilities. However, compared to 2012, the percentage of tested applications with vulnerabilities has dropped from 99% to 96% and the median number of vulnerabilities per application has grown from 13 up to 14. Fig.1 shows that Cross Site Scripting (XSS) vulnerabilities continue to be the most common class of application vulnerability. At 25% of the total, XSS was the most frequently found vulnerability in applications tested in 2013. A substantial percentage of them have multiple XSS exposure points to remediate and many of them create severe security risks. Fig. 1. Web application vulnerabilities of 2013 While the majority of corporations have the important security building blocks, such as firewalls and intrusion protection systems needed for their security infrastructure, not enough organizations have comprehensive tools and practices in place for securing applications. The result is that hackers are increasingly focusing on and are succeeding with their attacks. The results show that information security in general is still not being taken as seriously as it should which could result in significant damage to every system relying on computer technology. Web applications are only a tiny grain of sand in the vast field of possibilities open for exploitation.
• 2.
  III. ATTACK VECTORS A.Cross Site Scripting XSS (Cross Site Scripting)[1] is a client-side attack where an attacker can craft a malicious link, containing script code which is then executed within the victim's browser when the target site vulnerable to and injected with XSS is viewed. The script-code can be any language supported by the browser but mostly HTML and Javascript are used along with embedded Flash, Java or ActiveX. Cross-site scripting is considered the most prevalent web application vulnerability found in the wild, affecting the vast majority of live applications. It can often be combined with other vulnerabilities for a devastating effect. A large percentage of XSS vulnerabilities found in the wild prove to be rather harmless and usable only under certain conditions. XSSQLi is a mix of Cross site scripting and SQL injection where an unknowing victim visits a malicious link containing SQL Injection instructions for an area on the website which requires privileges that guests or members don't have. An example of XSSQLI could be tricking the administrator of example.tld to click either the SQL Injection link or click a cross site scripting link which contains a call to the SQL injection in the privileged area of the site where this could be the vulnerable part: http://example.tld/admin.php?del=1 AND 1=1/* XSSR or CSSR aka Cross Site Script Redirection is used to redirect a victim to another page unwillingly. The page can, for example, contain a phishing template, browser attack code or in some cases where the data or javascript URI scheme is used: session-hijacking. However, the main categorization of XSS attacks covers three main categories: Reflected (non-persistent) XSS, stored (persistent) XSS and DOM-based XSS. 1. Reflected XSS attacks are the most frequent type of XSS attacks. A vulnerable web application will pass unvalidated input sent through requests to the client. The attacker creates an offending URI and then convinces his victims to load this URI on their browsers and have the code executed. 2. Stored XSS is the most dangerous type of Cross Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application. Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. Stored XSS is particularly dangerous in application areas where users with high privileges have access. 3. DOM-based cross site scripting vulnerabilities may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker. Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may render many of the general XSS filtering and detection rules useless against such attacks. An important matter about exploiting XSS vulnerabilities is character encoding. In some cases, the web server or the web application could only be filtering some encodings of characters, therefore the web application might filter out "<script>", but might not filter %3cscript%3e which simply includes another encoding of tags. In order to test for XSS vulnerabilities, the tester must first detect input vectors, determine the web application's variables and find out how to input themin the web application. http://example.tld/index.php?user=<script>alert("XSS")</scri pt> The best way to protect against XSS attacks is to ensure that all user input and output is validated and sanitized properly. However in some cases an IPS or WAF can also be configured to filter out XSS attacks using regular expressions that match XSS attacks. B. Cross Site Request Forgery Cross-Site Request Forgery (CSRF)[2] is an attack that tricks the victim into loading a page that contains a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password. CSRF attacks target functions that cause a state change on the server but can also be used to access sensitive data. A CSRF, sometimes called an XSRF, vulnerability exists when a web application fails to properly verify the origin of a request. CSRF is most commonly used in conjuction with stored XSS vulnerabilities. Any functionality that is accessible through HTTP and uses session cookies for authorization is potentially at risk. Using specially designed form tags and the “text/plain” content type it is possible to generate any kind of message body in a POST request. Web based APIs could also be at risk to CSRF.
• 3.
  Most common methodsof CSRF exploitation are: 1. Simple HTML through the use of various HTML tags, for example: <img src="http://example.tld/exploit?payload" height="1" width="1" /> 2. Auto submitting form, by using the form tag to build a POST/GET request and submit it automatically using javascript when the page is loaded. 3. Using pure javascript to send an automatic request by the browser. The XMLHttpRequest object can also be used to generate a request, though this object is not supported in all browsers. 4. Client side programming languages, by using browser plugins such as Adobe Flash, Java applets and Silverlight. However, even though these languages offer the ability to send requests, a huge disadvantage of this technique is the same origin policy which prevents requests to hosts other than the host the plugins were loaded on. Nevertheless, there are ways to circumvent said policies. The best way to protect against CSRF is by using random form tokens where the server generates a random token and stores it in the user’s session when he logs into the web application. Any functionality that needs to be protected will have to include this value as a parameter in the request. The server simply verifies that the value in the parameter is the same as the value stored in the session. The attacker doesn’t have access to this value and can therefore not create a correct request. C. Server Side Includes injection SSI Injection (Server Side Includes Injection)[1] is a server- side exploitation technique that allows an attacker to inject code into a web application, which will later be executed locally by the web server. SSI Injection exploits a web application's failure to sanitize user-supplied data before they are inserted into a server-side interpreted HTML file. They represent an alternative to writing CGI program or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. When compared to a classical scripting language, SSI injections are considered less dangerous, as the SSI directives are not comparable to a real scripting language and because the web server needs to be configured to allow SSI, but also are simpler to exploit, as SSI directives are easy to understand and powerful enough to execute arbitrary operating system commands, or include a restricted file's contents the next time the page is served, for example: < !--#exec cmd="/bin/ls /" -- > SSI injections can be found everywhere where the user is allowed to submit input without proper validation. Other than common user-supplied data, possible input vectors are HTTP request headers and cookies content, if the web application is going to use that data to build a dynamically generated page, for example: GET / HTTP/1.0 Referer: <!--#exec cmd="/bin/ps ax"--> User-Agent: <!--#virtual include="/proc/version"--> It is possible to check if the application is validating input fields data by inserting characters that are used in SSI directives, like: < ! # = / . " - > and [a-zA-Z0-9] Another way to find out whether the application is vulnerable is to search for .stm, .shtm and .shtml pages. However, the lack of such pages does not mean it's not possible to performan SSI injection attack. D. SQL injection SQL injection[3] vulnerabilities pose a serious threat for Web applications. Web applications that are vulnerable to SQL injections allow unauthorized users to execute queries and gain access to information contained in the database. In some cases, attackers can exploit an SQL injection vulnerability to take control over the system. Data provided by the user is included in an SQL query in such a way that part of the user’s input is treated as an SQL query. An attacker can submit a query that can be directly executed in the database and extract sensitive information like credit cards, usernames, passwords, phone numbers, pins... SQL injections can be classified into several types, including: 1. Union queries Using the UNION SELECT command, we can extract database information by controlling the second query after the UNION command, e.g: http://example.tld/song.php?id=1 union select 1,2,3,@@version,5-- 2. Time based queries This method uses functions like sleep(). If an SQL statement is true, then page will wait longer before rendering. By using this information about page rendering time, we can conclude if an SQL statement is true or false. 3.Error based queries
• 4.
  With error basedqueries we can forge SQL statements that will produce errors with duplicate entry key along with some information. 4.Boolean based queries These queries make comparison in statement and return result if logic is true, therefore the page will only be rendered if the logic of comparing two values is true. If not, either the page may be not rendered or an error/warning message will show up. There are plenty of methods to sanitize this type of vulnerability. We can use built-in functions to sanitize users’ input. Every database driver has functions string escaping functions like mysql_real_escape_string(). The best solution for this problem is using prepared statements. E. LFI/RFI Local File Inclusion (LFI)[4] and Remote File Inclusion (RFI) are methods and attack vectors where users can include local/remote scripts on run-time, execute them and gain full unauthorized access to the target system. Most LFI/RFI can be found in the URL, in GET parameters. There are several methods for exploitation and circumventing defense mechanisms: 1. Null byte With the null byte technique, we can bypass an extension from a script that is added after the filename. By adding %00 in the url after the filename, the extension will not be read and processed. <?php include ($_GET['f'].'.php'); ?> http://example.com/file.php?f=/etc/passwd%00 2. 2.Apache Log Every access on web server running Apache will be logged to the Apache access log file. If we know the location of Apache access logs, we can use them in this vulnerability as a file that’s to be included, in the same time with script command to execute, as part of user- agent header or any GET parameter. http://example.com/file.php?f=/var/log/apache/access.log 3. /proc/self By including /proc/self/environ and using spoofed user agent containing a script/system command, we can execute commands on the system. This method is widely used to exploit Linux systems with this type of vulnerability. http://example.com/file.php?f=/proc/self/environ User-Agent: <?php system(COMMAND_HERE);?> RFI is essentially the same as LFI. The only difference is that if the configuration of web server allows us to include scripts located on a remote system, then we can use url in order to include and execute arbitrary scripts. LFI/RFI can be sanitized by not allowing user input in include() calls. CONCLUSION Web applications can be vulnerable to a number of various vulnerabilities depending on their complexity, the more technologies they utilize – the more attack vectors are available. In order to build a sophisticated website and provide an enjoyable experience for the everyday user, the administrator must sacrifice either the security, or the ease of use. The best approach is to aim for balance. However, by suppressing the security aspect, a number of vulnerabilities are being introduced which could prove devastating. Security should be a top priority concern during the development stage of the application and must not be taken lightly. Most databases contain information which should not under any circumstance end up in the wrong hands. In order to achieve the required level of security, an administrator should follow best practices and rely on methods which are proven to be secure. Unfortunately, it is not always possible to do so, considering every web application has different needs and deploys various technologies, which combined, could open new attack vectors which previously weren’t present. Cyber security is an investment which pays off in the long run and as time progresses, becomes an inevitable part of every business present on the internet. Simple attack vectors, like the ones included in this document, can be easily dealt with, but a sophisticated attacker might be able to forge a chain of at first sight insignificant vulnerabilities and achieve full system control, which is why in the security industry, one should always be alert enough and expect the unexpected. REFERENCES [1] OWASP Foundation, 2002-2008 “OWASP Testing Guide v3” [2] Acadion Security, “Cross Site Request Forgery – Vulnerability ovevrview” v.1 [3] William G.J. Halfond, Jeremy Viegas and Alessandro Orso, “A Classification of SQL injection Attacks and Countermeasures,” College of Computing, Georgia Institute of Technology [4] Fredrik NordbergAlmroth, “Local File Inclusion” unpublished.