In this dotdotpwn tutorial, we’re going to show you how to use Kali Linux to test applications for weaknesses and vulnerabilities. Like most other Kali tools, this command line utility has a strange name and is run from the command line. But before we begin, I’d like to point out a few things.
First of all, this tutorial assumes that you already know your way around a Linux system, and are comfortable working from the command line (i.e. the BASH shell). In addition, I assume that you already have Kali Linux installed, or at least have a live-bootable version of the operating system. If you don’t already have Kali Linux, consider you can use it in the following ways:
-
Install it directly to your HDD, perhaps in a dual-boot scenario
-
Install it directly to a flash drive, and boot via USB by changing the default boot order in your BIOS
-
Take advantage of VMWare from a Windows or Mac environment and simply create a virtual machine
Kali can be downloaded from their site, and it would be good to grab the newest version.
What the Heck Does Dotdotpwn Actually Do?
The simplest definition of dotdotpwn is that it is a fuzzer. Ah, but what’s a fuzzer, you ask? A fuzzer is a type of debugging and penetration testing tool that targets software to look for vulnerabilities. Usually it tests for flaws in the code that will help identify loopholes, data validation errors, incorrect parameters, bad data, erroneous data types, and other such programming anomalies.
Whenever the software or service encounters one of these anomalies, it likely won’t know how to respond, making it possible to leverage the flaws as an attack. For instance, if I were a hacker targeting a corporate web server, I might be able to find a flaw in the web server’s code. Perhaps the corporation hasn’t installed the latest updates for the HTTP service software, or some other related oversight.
By using a fuzzer, I discover a data validation error that allows me to exploit a type of DoS attack. Exploiting the discovered vulnerability (in this example) causes the server to crash, and denying web access to all of the internal employees. This isn’t the only type of application error, however. Note that these types of errors are actually quite common among a whole range of different types of technologies and protocols.
For instance, there is another type of attack that isn’t so different, which is known as SQLi. SQLi (SQL Injection) attacks work by inserting database commands into web forms that haven’t been properly sanitized. The bottom line is that software and services will always be fallible, making it possible for hackers to find ways to break the system.
About Dotdotpwn
Dotdotpwn is a fuzzer, and it is has a lot of flexible use cases and various attack vectors. It can help an attacker find vulnerabilities in all kinds of systems and services from simple HTTP web servers to blogs and content management systems. One of the things I find most interesting is that it even has a module that is protocol-independent, which means you could theoretically address an attack payload to an individual computer on a port of your choosing.
This useful fuzzer was written in the Perl programming language. And surprisingly, not only can it be run from most Linux operating systems, but Windows as well. Nevertheless, it is so useful that it is included in the Kali packages. In fact, it was included in BackTrack Linux, which is Kali’s predecessor. The following include dotdotpwn’s different modules:
-
HTTP and HTTP URL
-
FTP and TFTP (Trivial File Transfer Protocol)
-
A protocol independent payload module
-
STDOUT
Syntax and Options
Let’s start by taking a high-level overview of the tool, it’s syntax, and it’s options. The following is the basic syntax of the command:
- ./dotdotpwn.pl -m [module] -h [host] [additional_options]
Furthermore, the following are the possible options and their respective values you can append to the end of the command:
- -m <module> Selects a module such as http, http-url, ftp, tftp, payload, or stdout
- -h <host> Specifies a hostname to target
- -O Uses NMAP for intelligent operating system detection
- -s Detects the target’s service version
- -d Deep of traversals
- -f Specific filename
- -u <url> URL with the part to be fuzzed marked as TRAVERSAL
- -k [string_pattern] String pattern to match in the response if it’s vulnerable
- -U <username> Specifies the default username
- -P <password> Specifies the default password
- -p <file> Filename with the payload to be sent and the part to be fuzzed marked as TRAVERSAL
- -x <port> Port to connect default: HTTP=80, FTP=21, TFTP=69
- -t <number> Time in milliseconds between each test default: 300
- -b Break after the first vulnerability is found
- -q Quiet mode
In practice, you won’t need to use each of these options every time you use dotdotpwn. Instead, you only need to know a small subset of these options, though I want to point out how flexible this fuzzer tool is.
Dotdotpwn Tutorial and Example
In this brief example, we’re going to be running through an example that tests a target for HTTP weaknesses and vulnerabilities. The command syntax is as follows:
-
./dotdotpwn.pl -m http -h 192.168.1.1 -x 8080 -f /etc/hosts -k “localhost” -d 8 -t 200 -s
In this example, note first that it is using the HTTP module and targeting 192.168.1.1. Also, it’s worth noting that it’s listening on port 8080, which is typically used to establish HTTPS connections. Next, the -f command will attempt to capture the etc/hosts file, and look for the keyword “localhost.”
This is pretty typical syntax for the HTTP module, but note that you can substitute different values for the options. For instance, you could change the listening port number to 80 (HTTP). In addition, you can append additional options to the command.
Final Thoughts
This is just one example of how you can find vulnerabilities with the HTTP module, though there are many other modules. Nevertheless, I would warn you against running these vulnerability scans and fuzzing operations on real-world devices. Doing so could very well be illegal if you don’t own the equipment or server.
If you wanted to test out the HTTP module, you could setup a home-brewed Apache web server. Just make sure that you only use and test this tool in the privacy of your own home. Using it in public places could mean you are asked some awkward questions if you get caught, such as why you’re looking for vulnerabilities on someone else’s computing system.
Leave a Reply