Как найти уязвимость https

Всем привет! В марте OTUS запускает новый курс «Практикум по Kali Linux». В преддверии старта курса подготовили для вас перевод полезного материала. Также хотим пригласить всех желающих на бесплатный урок по теме: «Denial of Service атаки и защита от них».

---

Перед тем как атаковать любой сайт, хакер или пентестер сначала составляет список целей. После того, как он проведет хорошую разведку и найдет слабые места для «наведения прицела», ему понадобится инструмент сканирования веб-сервера, такой как Nikto, который поможет найти уязвимости – потенциальные вектора атаки.

Nikto – это простой открытый сканер веб-серверов, который проверяет веб-сайт и сообщает о найденных уязвимостях, которые могут быть использованы для эксплойта или взлома. Кроме того, это один из наиболее широко используемых инструментов сканирования веб-сайтов на уязвимости во всей отрасли, а во многих кругах он считается отраслевым стандартом.

Несмотря на то, что этот инструмент чрезвычайно эффективен, он не действует скрытно. Любой сайт с системой обнаружения вторжений или иными мерами безопасности поймет, что его сканируют. Nikto был разработан для тестирования безопасности и о скрытности его работы никто не задумывался.

Как правильно использовать Nikto

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

Для начала давайте поговорим о целях (target). Целью может оказаться почти любое место, куда может нанести свой удар хакер, например, сетевые принтеры или веб-сервер. Когда мы чуть позже перейдем к использованию Nikto, нам нужно будет предоставить ему один из трех видов информации: IP-адрес для локальной службы, веб-домен для атаки или веб-сайт SSL/HTTPS.

Прежде чем начинать сканирование с помощью Nikto, лучше предварительно провести разведку с помощью такого открытого инструмента как Maltego. Такие инструменты могут оказаться полезными при создании профиля и формировании более конкретного списка целей, на которых стоит сосредоточиться. Как только вы это сделаете, можно будет воспользоваться Nikto для поиска потенциальных уязвимостей в целях из вашего списка.

Если повезет, уязвимость с известным эксплойтом будет найдена, а значит, что уже существует инструмент, который поможет воспользоваться этим слабым местом. С помощью соответствующего инструмента, который автоматически эксплуатирует уязвимость, хакер может получить доступ к цели для выполнения любого количества скрытых атак, таких как, например, добавление вредоносного кода.

Шаг 1: Установка Nikto

Если вы используете Kali Linux, то Nikto будет предустановлен, поэтому вам ничего скачивать и устанавливать не придется. Он будет расположен в категории «Vulnerability Analysis». Если у вас его по какой-то причине нет, вы можете скачать Nikto с его репозитория на GitHub или просто использовать команду apt install.

apt install nikto

Если вы работаете на Mac, то можете использовать Homebrew, чтобы установить Nikto.

brew install nikto

Шаг 2: Познакомьтесь с Nikto

Перед сканированием веб-серверов с помощью Nikto, воспользуйтесь параметром -Help, чтобы увидеть все, что можно делать с этим инструментом:

nikto -Help

Options:
       -ask+               Whether to ask about submitting updates
                               yes   Ask about each (default)
                               no    Don't ask, don't send
                               auto  Don't ask, just send
       -Cgidirs+           Scan these CGI dirs: "none", "all", or values like "/cgi/ /cgi-a/"
       -config+            Use this config file
       -Display+           Turn on/off display outputs:
                               1     Show redirects
                               2     Show cookies received
                               3     Show all 200/OK responses
                               4     Show URLs which require authentication
                               D     Debug output
                               E     Display all HTTP errors
                               P     Print progress to STDOUT
                               S     Scrub output of IPs and hostnames
                               V     Verbose output
       -dbcheck           Check database and other key files for syntax errors
       -evasion+          Encoding technique:
                               1     Random URI encoding (non-UTF8)
                               2     Directory self-reference (/./)
                               3     Premature URL ending
                               4     Prepend long random string
                               5     Fake parameter
                               6     TAB as request spacer
                               7     Change the case of the URL
                               8     Use Windows directory separator ()
                               A     Use a carriage return (0x0d) as a request spacer
                               B     Use binary value 0x0b as a request spacer
        -Format+           Save file (-o) format:
                               csv   Comma-separated-value
                               htm   HTML Format
                               nbe   Nessus NBE format
                               sql   Generic SQL (see docs for schema)
                               txt   Plain text
                               xml   XML Format
                               (if not specified the format will be taken from the file extension passed to -output)
       -Help              Extended help information
       -host+             Target host
       -404code           Ignore these HTTP codes as negative responses (always). Format is "302,301".
       -404string         Ignore this string in response body content as negative response (always). Can be a regular expression.
       -id+               Host authentication to use, format is id:pass or id:pass:realm
       -key+              Client certificate key file
       -list-plugins      List all available plugins, perform no testing
       -maxtime+          Maximum testing time per host (e.g., 1h, 60m, 3600s)
       -mutate+           Guess additional file names:
                               1     Test all files with all root directories
                               2     Guess for password file names
                               3     Enumerate user names via Apache (/~user type requests)
                               4     Enumerate user names via cgiwrap (/cgi-bin/cgiwrap/~user type requests)
                               5     Attempt to brute force sub-domain names, assume that the host name is the parent domain
                               6     Attempt to guess directory names from the supplied dictionary file
       -mutate-options    Provide information for mutates
       -nointeractive     Disables interactive features
       -nolookup          Disables DNS lookups
       -nossl             Disables the use of SSL
       -no404             Disables nikto attempting to guess a 404 page
       -Option            Over-ride an option in nikto.conf, can be issued multiple times
       -output+           Write output to this file ('.' for auto-name)
       -Pause+            Pause between tests (seconds, integer or float)
       -Plugins+          List of plugins to run (default: ALL)
       -port+             Port to use (default 80)
       -RSAcert+          Client certificate file
       -root+             Prepend root value to all requests, format is /directory
       -Save              Save positive responses to this directory ('.' for auto-name)
       -ssl               Force ssl mode on port
       -Tuning+           Scan tuning:
                               1     Interesting File / Seen in logs
                               2     Misconfiguration / Default File
                               3     Information Disclosure
                               4     Injection (XSS/Script/HTML)
                               5     Remote File Retrieval - Inside Web Root
                               6     Denial of Service
                               7     Remote File Retrieval - Server Wide
                               8     Command Execution / Remote Shell
                               9     SQL Injection
                               0     File Upload
                               a     Authentication Bypass
                               b     Software Identification
                               c     Remote Source Inclusion
                               d     WebService
                               e     Administrative Console
                               x     Reverse Tuning Options (i.e., include all except specified)
       -timeout+          Timeout for requests (default 10 seconds)
       -Userdbs           Load only user databases, not the standard databases
                               all   Disable standard dbs and load only user dbs
                               tests Disable only db_tests and load udb_tests
       -useragent         Over-rides the default useragent
       -until             Run until the specified time or duration
       -update            Update databases and plugins from CIRT.net
       -useproxy          Use the proxy defined in nikto.conf, or argument http://server:port
       -Version           Print plugin and database versions
       -vhost+            Virtual host (for Host header)
   		+ requires a value

Шаг 3: Используйте базовый синтаксис

Как вы видите из предыдущего шага, у Nikto есть много вариантов использования, но для наших целей мы будем использовать базовый синтаксис <IP или hostname> с фактическим IP-адресом или именем хоста без угловых скобок.

nikto -h <IP or hostname>

Однако, Nikto способен выполнять сканирование SSL и порта 443, который используют сайты HTTPS (HTTP использует по умолчанию 80 порт). Таким образом, мы не ограничиваемся только сканированием старых сайтов, мы может проводить оценку уязвимостей сайтов, использующих SSL, что на сегодняшний день является почти обязательным требованием для индексирования в результатах поиска.

Если мы знаем, что у целевого сайта есть SSL, мы можем указать это в Nikto, чтобы сэкономить некоторые время на сканировании, добавив -ssl в конец команды.

nikto -h <IP or hostname> -ssl

Шаг 4: Сканируйте сайты с SSL

Например, давайте начнем со сканирования сайта pbs.org, чтобы увидеть типы информации, которые может выдать сканирование Nikto. После того, как он подключается к порту 443, мы видим какую-то полезную информацию о шифровании и другие детали, такие как, например, то, что сервер работает на nginx, однако здесь для нас не так много интересного.

nikto -h pbs.org -ssl

- Nikto v2.1.6
------------------------------------------------------------------------------
- STATUS: Starting up!
+ Target IP:			54.225.198.196
+ Target Hostname:		pbs.org
+ Traget Port:			443
------------------------------------------------------------------------------
+ SSl Info:			Subject:	/CN=www.pbs.org
					Altnames:	account.pbs.org, admin.pgs.org, dipsy-tc.pbs.org, docs.pbs.org, ga.video.cdn.pbs.org, git.pbs.org, heart.ops.pbs.org, hub-dev.pbs.org, image.pbs.org,
                    			jaws..pbs.org, kids.pbs.org, koth-qa.svp.pbs.org, login.pbs.org, ops.pbs.org, pbs.org, player.pbs.org, projects.pbs.org, sentry.pbs.org, teacherline.pbs.org,
                                urs.pbs.org, video.pbs.org, weta-qa.svp.pbs.org, whut-qa.svp.pbs.org, wnet.video-qa.pbs.org, wnet.video-staging.pbs.org, www-cache.pbs.org, www.pbs.org
                    Ciphers:	ECDHE-RSA-AES128-GCM-SHA256
                    Issuer:		/C-US/0=Let's Encrypt/CN=Let's Encrypt Authority X3
+ Start Time:			2018-12-05 23:34:06 (GMT-8)
------------------------------------------------------------------------------
+ Server: nginx
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'x-pbs-fwsrvname' found, with contents: fwcacheproxy1
+ The site uses SSL and the Strict-Transport-Security HTTP header is not defined.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Root page / redirects to: https://www.pbs.org/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ RC-1918 IP address found in the 'x-pbs-appsvrip' header: The IP is "10.137.181.52".
+ Uncommon header 'x-cache-fs-status' found, with contents: EXPIRED
+ Uncommon header 'x-pbs-appsvrname' found, with contents: fwcacheproxy1
+ Uncommon header 'x-pbs-appsvrip' found, with contents: 10.137.181.52
+ Server leaks inodes via ETags, header found with file /pbs.org.zip, fields: 0x5b96537e 0x1678
+ 7446 requests: 0 error(s) and 10 item(s) reported on remote host
+ End Time:				2018-12-06 00:30:29 (GMT-8) (3383 seconds)
------------------------------------------------------------------------------
+ 1 host(s) tested

Шаг 5: Сканирование IP-адреса

Теперь, когда мы провели быстрое сканирование веб-сайта, мы можем попробовать использовать Nikto в локальной сети, чтобы найти embedded-сервера, такие как страница логина роутера или HTTP-сервис на другой машине, который представляет из себя просто сервер без веб-сайта. Чтобы узнать IP-адрес мы будем использовать ifconfig.

IP-адрес, который нам нужен относится к «inet». На нем мы можем использовать ipcalc для того, чтобы получить сетевой диапазон. Если у вас нет ipcalc, вы можете установить его с помощью команды apt install ipcalc, а затем повторить попытку. Диапазон будет стоять после «Network», в моем случае это 192.168.0.0/24.

ifconfig

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>  mtu 1500
        inet 192.168.0.48  netmask 0xffffff00  broadcast 192.168.0.255
        inet6 XXXX::XXX:XXXX:XXXX:XXXX%en0  prefixlen 64  secured scopeid 0x8
        ether XX:XX:XX:XX:XX:XX  txqueuelen 1000  (Ethernet)
        inet6 XXXX::XXX:XXXX:XXXX:XXXX%en0  prefixlen 64 autoconf secured
        inet6 XXXX::XXX:XXXX:XXXX:XXXX%en0  prefixlen 64 autoconf temporary
        nd6 options=201<PERFORMNUD,DAD>
        media: autoselect
        status: active

en2: flags=8863<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST>  mtu 1500
        options=60<TS04,TS06>
        ether XX:XX:XX:XX:XX:XX
        media: autoselect <full-duplex>
        status: inactive

Теперь мы хотим запустить Nmap, чтобы найти службы, работающие в этом сетевом диапазоне. Давайте сканировать 80 порт с помощью нашего диапазона, для этого допишем -oG (grepable output), чтобы получить только те хосты, которые подняты и работают, то есть те, которые отвечают, говоря, что 80 порт открыт. Затем мы сохраним все это в файл, который я назову nullbyte.txt, вы, в свою очередь, можете назвать его как угодно.

ipcalc 192.168.0.48

Address:   192.168.0.48         11000000.10101000.00000000. 00110000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.0.0/24       11000000.10101000.00000000. 00000000
HostMin:   192.168.0.1          11000000.10101000.00000000. 00000001
HostMax:   192.168.0.254        11000000.10101000.00000000. 11111110
Broadcast: 192.168.0.255        11000000.10101000.00000000. 11111111
Hosts/Net: 254                   Class C, Private Internet

Есть небольшой фокус, который поможет отправить все хосты прямо в Nikto для сканирования. Мы используем cat для чтения входных данных, хранящихся в нашем документе nullbyte.txt (или как вы его назвали самостоятельно). После этого мы используем awk – специальный инструмент в Linux, который поможет найти следующий шаблон, где Up означает, что хост поднят, а print $2 значит, что нужно вывести второе слово в каждой строке, то есть только IP-адрес. Затем, полученные данные мы отправим в файл, который называется targetIP.txt (или как вам захочется).

cat nullbyte.txt | awk '/Up$/{print $2}' | cat >> targetIP.txt

Теперь мы можем просмотреть содержимое нашего нового файла с помощью cat, чтобы увидеть все IP-адреса, у которых открыт 80 порт.

cat targetIP.txt

192.168.0.1
192.168.0.2
192.168.0.4
192.168.0.5
192.168.0.11
192.168.0.24
192.168.0.31
192.168.0.48
192.168.0.60

Такой формат идеально подойдет Nikto, поскольку он может легко интерпретировать подобные файлы. Таким образом, мы можем отправить этот вывод в Nikto следующей командой.

nikto -h targetIP.txt

Результаты будут аналогичны тем, что мы получили при сканировании с SSL.

Шаг 6: Сканирование HTTP-сайта

Мы просканировали защищенный веб-сайт и IP-адрес в локальной сети, теперь настало время искать незащищенный веб-домен, который использует 80 порт. Для этого примера я использую сайт afl.com.au, у которого не было SSL в тот момент, когда я проводил это сканирование.

nikto -h www.afl.com.au

- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          159.180.84.10
+ Target Hostname:    www.afl.com.au
+ Target Port:        80
+ Start Time:         2018-12-05 21:48:32 (GMT-8)
---------------------------------------------------------------------------
+ Server: instart/nginx
+ Retried via header: 1.1 varnish (Varnish/6.1), 1.1 e9ba0a9a729ff2960a04323bf1833df8.cloudfront.net (CloudFront)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'x-cache' found, with contents: Miss from cloudfront
+ Uncommon header 'x-instart-cache-id' found, with contents: 17:12768802731504004780::1544075250
+ Uncommon header 'v-cache-hit' found, with contents: Hit
+ Uncommon header 'x-amz-cf-id' found, with contents: Dr-r6OwO5kk9ABt4ejzpc7R7AIF6SuH6kfJHQgP0v6xZoHwMLE55rQ==
+ Uncommon header 'x-instart-request-id' found, with contents: 12814413144077601501:BEQ01-CPVNPPRY18:1552504721:0
+ Uncommon header 'x-oneagent-js-injection' found, with contents: true
+ Uncommon header 'grace' found, with contents: cache
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Uncommon header 'x-ruxit-js-agent' found, with contents: true
+ Cookie dtCookie created without the httponly flag
+ Server banner has changed from 'instart/nginx' to 'nginx' which may suggest a WAF, load balancer or proxy is in place
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Entry '/sites/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/search/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '*.mobileapp' in robots.txt returned a non-forbidden or redirect HTTP code (400)
+ Entry '*.liveradio' in robots.txt returned a non-forbidden or redirect HTTP code (400)
+ Entry '*.smartmobile' in robots.txt returned a non-forbidden or redirect HTTP code (400)
+ Entry '*.responsive' in robots.txt returned a non-forbidden or redirect HTTP code (400)
+ Entry '/stats?*/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 8 entries which should be manually viewed.
+ OSVDB-3092: /sitemap.xml: This gives a nice listing of the site content.
+ OSVDB-3092: /psql_history: This might be interesting...
+ OSVDB-3092: /global/: This might be interesting...
+ OSVDB-3092: /home/: This might be interesting...
+ OSVDB-3092: /news: This might be interesting...
+ OSVDB-3092: /search.vts: This might be interesting...
+ OSVDB-3092: /stats.htm: This might be interesting...
+ OSVDB-3092: /stats.txt: This might be interesting...
+ OSVDB-3092: /stats/: This might be interesting...
+ OSVDB-3092: /Stats/: This might be interesting...
+ OSVDB-3093: /.wwwacl: Contains authorization information
+ OSVDB-3093: /.www_acl: Contains authorization information
+ OSVDB-3093: /.htpasswd: Contains authorization information
+ OSVDB-3093: /.access: Contains authorization information
+ OSVDB-3093: /.addressbook: PINE addressbook, may store sensitive e-mail address contact information and notes
+ OSVDB-3093: /.bashrc: User home dir was found with a shell rc file. This may reveal file and path information.
+ OSVDB-3093: /.bash_history: A user's home directory may be set to the web root, the shell history was retrieved. This should not be accessible via the web.
+ OSVDB-3093: /.forward: User home dir was found with a mail forward file. May reveal where the user's mail is being forwarded to.
+ OSVDB-3093: /.history: A user's home directory may be set to the web root, the shell history was retrieved. This should not be accessible via the web.
+ OSVDB-3093: /.htaccess: Contains configuration and/or authorization information
+ OSVDB-3093: /.lynx_cookies: User home dir found with LYNX cookie file. May reveal cookies received from arbitrary web sites.
+ OSVDB-3093: /.mysql_history: Database SQL?
+ OSVDB-3093: /.passwd: Contains authorization information
+ OSVDB-3093: /.pinerc: User home dir found with a PINE rc file. May reveal system information, directories and more.
+ OSVDB-3093: /.plan: User home dir with a .plan, a now mostly outdated file for delivering information via the finger protocol
+ OSVDB-3093: /.proclog: User home dir with a Procmail rc file. May reveal mail traffic, directories and more.
+ OSVDB-3093: /.procmailrc: User home dir with a Procmail rc file. May reveal subdirectories, mail contacts and more.
+ OSVDB-3093: /.profile: User home dir with a shell profile was found. May reveal directory information and system configuration.
+ OSVDB-3093: /.rhosts: A user's home directory may be set to the web root, a .rhosts file was retrieved. This should not be accessible via the web.
+ OSVDB-3093: /.sh_history: A user's home directory may be set to the web root, the shell history was retrieved. This should not be accessible via the web.
+ OSVDB-3093: /.ssh: A user's home directory may be set to the web root, an ssh file was retrieved. This should not be accessible via the web.
+ OSVDB-5709: /.nsconfig: Contains authorization information
+ /portal/changelog: Vignette richtext HTML editor changelog found.
+ 7587 requests: 4 error(s) and 55 item(s) reported on remote host
+ End Time:           2018-12-05 22:42:41 (GMT-8) (3249 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Из информации выше, мы понимаем, что присутствует сервер Varnish и некоторые заголовки, которые могут подсказать, как сконфигурирован веб-сайт. Однако более полезная информация – это обнаруженные каталоги, которые могут помочь зацепить конфигурационные файлы, содержащие учетные данные или другие вещи, которые были неправильно сконфигурированы и оказались доступными непреднамеренно.

Элементы с префиксом OSVDB – это уязвимости, о которых сообщается на Open Source Vulnerability Database (сайте, который закрылся в 2016 году). Он похож на другие базы данных уязвимостей, такие как SecurityFocus, Microsoft Technet и Vulnerabilities and Exposures (https://cve.mitre.org/). Лично мне ближе National Vulnerability Database.

Несмотря на то, что наше сканирование не выявило никаких критических уязвимостей, которые можно было бы эксплуатировать, вы можете использовать справочный инструмент CVE для перевода идентификатора OSVDB в запись CVE, чтобы вы могли воспользоваться одним из сайтов, приведенных выше.

Допустим, вы нашли что-то достойное исследования, например CVE-2018-10933, уязвимость Libssh, о которой мы подробнее говорили ранее. CVE содержит информацию о том, как ее эксплуатировать, насколько уязвимость серьезна (например, критическая уязвимость) и некоторые другие сведения, которые могут помочь определиться с вектором атаки. Если это что-то стоящее, вы можете поискать с Metasploit, поскольку кто-то скорее всего уже разработал модуль, который поможет легко эксплуатировать эту уязвимость.

Шаг 7: Сканирование вместе с Metasploit

Одна из лучших вещей в Nikto заключается в том, что вы можете просто экспортировать информацию, полученную при сканировании, в формат, который сможет прочитать Metasploit. Для этого просто используйте команды для выполнения сканирования, приведенные выше, но добавьте к ним в конце флаги -Format msf+. Этот формат может помочь быстро сопоставить данные, полученные с помощью эксплойта.

nikto -h <IP or hostname> -Format msf+

Итак, в сегодняшнем руководстве мы перешли от определения цели к поиску уязвимостей в ней, а затем связали найденные уязвимости с эксплойтом, чтобы нам не пришлось делать всю работу вручную. Поскольку Nikto не работает скрытно, разумно выполнять эти сканирования через VPN, Tor или другой тип сервиса, чтобы ваш IP-адрес не был помечен как подозрительный.

→ Записаться на бесплатный урок

Пошагово расскажу как за полчаса комплексно проверить безопасность сайта даже если вы не программист. Статья будет полезна разработчикам, тестировщикам, а также владельцам сайтов.

Всем привет! Сейчас большинство статей в интернете по теме поиска уязвимостей на своем сайте делятся на два типа: это либо банальный список онлайн-сканеров без подробных инструкций как ими пользоваться, либо хардкорные мануалы для фанатов информационной безопасности и прочих хакеров, где без Линукса не разобраться.

Поэтому я решил написать статью, которой мне не хватало, когда я только начинал разбираться в этой теме. Надеюсь эта статья сделает интернет чуть-чуть безопаснее, а вам поможет найти даже те уязвимости, которые вы изначально не закладывали😃.

Статья пригодится:

А нужно ли проверять?

Немного фактов и мнений:

Факт доказанный практикой и личным опытом: даже если у вас небольшой интернет-магазин, в 2020 вы уже будете подвергаться кибератакам по несколько раз в день.

С момента попадания в индекс GoogleYandex ваш сайт становится мишенью десятка (а если сайт крупный, то сотни) специализированных ботов, которые круглосуточно мониторят даже небольшие сайты и серверы для поиска уязвимостей и дальнейшего взлома.

У вас может быть грамотная архитектура, красивый дизайн, быстрая скорость загрузки, но всего лишь небольшая ошибка или невнимательность разработчика может серьезно навредить вашему бизнесу. Поэтому необходимо регулярно проверять свой сайт или веб-приложение на наличие уязвимостей.

Хорошая новость – сейчас можно самостоятельно просканировать свое веб-приложение различными бесплатными сканерами безопасности и найти уязвимые места заранее.

Теперь я наглядно и пошагово покажу как с помощью таких инструментов самостоятельно проверить свой сайт, а также как разобраться в сгенерированных отчетах .

Что будем проверять:

Если вы пока еще не знаете, что означают все эти страшные слова и сокращения на английском, то не переживайте, по ходу статьи я обязательно объясню их значения.

В качестве подопытного сайта я написал и развернул небольшой самописный блог с возможностью оставлять комментарии к статьям и добавил в него весь джентльменский набор:

В общем все так, как делать не надо.

1. Проверяем сетевую инфраструктуру.

В кибератаках, также как и войне, все начинается с разведки, чтобы найти уязвимое место соперника. Для того, чтобы эффективно атаковать, злоумышленникам необходимо знать, какое ПО используется на сервере и какие двери открыты или закрыты недостаточно крепко. К несчастью владельцев сайтов, сейчас, чтобы все это узнать, нужно лишь здравое любопытство и утилита nmap.

Nmap – это набор инструментов для сканирования сетевой инфраструктуры веб-сервиса. Он может быть использован для проверки безопасности, для идентификации запущенных серверных приложений.

Nmap позволяет запускать готовые скрипты, которые значительно упрощают анализ вашего сервера. Минус – теперь даже смышленный школьник, вооружившись пачкой скриптов, может предоставлять опасность для серверов компании.

Интересный факт – сyществует целая галерея фильмов, где утилита nmap используется для кибератак. Часть представлено в галерее, под каждой картинкой описание. Более полный список и разбор можно посмотреть по ссылке

Посмотрели картинки, теперь можно и поработать! Приступаем к делу.

Устанавливаем nmap

В установке нет ничего сложного. Примеры установки покажу на примере Windows и Mac OS. В дистрибутивах Linux последняя версия nmap обычно установлена по умолчанию.

Установка на Windows 10

Перейдите по ссылке загрузки nmap и загрузите последнюю стабильную версию. На данный момент (16.09.2020) эта версия 7.80. Скачать ее можно по этой ссылке с официального сайта. Дальше запустите nmap-7.80-setup.exe от имени администратора. Программа установки по умолчанию предложит установить все компоненты, галочки можно не снимать. Описывать шаги далее подробно ( Примите лицензионное соглашение и тд) не буду, там все изи.

Запуск nmap на Windows

Запускать nmap можно как в режиме графического интерфейса, так и через командную строку.

Для запуска графической оболочки введите в строку поиска nmap и в результатах выберите nmap – Zenmap GUI

Для дальнейшей работы вы можете вводить нужные команды в поле “Команда”, а затем нажимать на кнопку Сканирование. Результаты сканирования в виде текстового отчета вы можете посмотреть в окне, которое я старательно подписал “Отчет”

Мне ближе использование nmap через командную строку aka консоль. Для запуска командной строки введите “cmd” в строку поиска на панели инструментов. Нажмите Enter и затем откроется командная строка. Дальше прямо в нее можно вводить nmap команды.

Командная строка в Windows 10 c введенной командой nmap выглядит вот так:

Mac OS X

Нажмите Command+Space и введите “Терминал”, после этого нажмите Enter. Дальше последнюю версию nmap можно установить через менеджер HomeBrew c помощью следующей команды, которую нужно ввести в терминале:

Для запуска nmap просто начинайте команду с nmap, ничего сложного 🙂

Устанавливаем скрипты

Также нам надо установить скрипт nmap_vulners, который будет проводить проверку на то, содержатся ли уязвимости в ПО, которое мы используем. Для его установки нужно скачать файлы скрипта и перенести файлы http-vulners-regex.nse и vulners.nse в C:Program Files (x86)Nmapscripts.

Если у вас Mac OS, то перенести файлы скрипта нужно в папку /usr/local/Cellar/nmap/<version>/share/nmap/scripts/

Начинаем проверку

Для начала запускаем сканирование своего сервера командой ниже, чтобы выяснить какие порты используются и для чего. Команда выглядит так (подставьте свой ip или домен). Команду нужно вводить в окне консоли, либо если вы используете Zenmap GUI, то в поле “Команда” (пример я привел выше):

Параметр T5 отвечает за скорость анализа сервера. Скорость можно менять от T0 до T5, где T0 – очень медленная скорость анализа, а T5 – очень быстрая. Если вы не хотите сильно нагружать сервер, то используйте T2.

Параметр -p- означает, что мы будем проверять весь диапазон портов (‘это займет около 10 минут) . Его можно убрать и тогда скрипт просканирует не все порты, а только 1000 первых (самые распространенные).

Ответ будет выглядеть примерно так:

Из отчета мы видим, что nmap отобразил нам порты (под колонкой PORT), которые активны. В данном случае у нас используются:

Теперь запускаем наш скрипт, который проверит уязвимости в нашем ПО на сервере. Для этого запускаем следующую команду с указанием портов, которые мы будем проверять. Вам нужно будет заменить список портов на свои .

Пример отчета. Ссылки на описание уязвимости идут после строки vulners (пример такой строки со ссылкой в отчете: CVE-2014-9278 4.0 https://vulners.com/cve/CVE-2014-9278)

Как видите из отчета, скрипт проанализировал активное ПО нашего сервера и любезно предоставил ссылки с описанием каждой найденной уязвимости. Что согласитесь, очень удобно как для нас, так и для злоумышленников.

Также можно записать результат анализа в файл, который потом можно скинуть ответственному разработчику или системному администратору. Сам файл результатов будет находиться в каталоге, из которого вы запускаете скрипт. Пример такой команды ниже:

Чтобы избавиться от подобных проблем обычно достаточно обновить используемое ПО до последних версий, где уязвимости старых версий, как правило, уже исправлены.

2. Проверяем устойчивость к перебору.

В нашем случае nmap определил, что на сервере есть ssh, ftp и mysql. Попробуем проверить насколько устойчивые пароли используются.

SSH

Вводим следующую команду (напомню, что вводить нужно либо в консоль, либо в поле “Команда” программы Zenmap GUI.

В случае успеха (процесс не быстрый) скрипт выведет подобранный пароль и логин . Подобранные пары логинпароль будут выведены после строчки Accounts:

Кроме того, можно расширить стандартные списки паролей и пользователей от nmap, заменив файлы users.lst и passwords.lst . Различные базы для брутфорса можно найти в этом gitbub репозитории. Файлы с базой паролей можно разместить в папке nmap/nselib/data

FTP

Теперь проверяем FTP порт следующей командой:

Аналогично, сервис выведет подобранные пары логинов и паролей:

MySQL

Проверяем доступен ли анонимный вход.

В случае успеха:

Пытаемся подобрать пару логинпароль для входа в базу данных mysql.

Также если у вас используются CMS (WordPress, Joomla, Drupal, Bitrix) и другие базы данных (Mongo, Postgres, Redis), то можно найти готовые скрипты для проверки устойчивости ваших паролей и форм. Ищите по ключевым словам <name_of_CMS_or_DB> brute force nmap

Проверяем формы авторизации

Найти формы авторизации можно с помощью такой команды (вместо <target> – подставьте домен вашего сайта):

После того, как нашли страницы с авторизацией, можно попробовать подобрать пароль и логин для входа в админку сайта.

Параметры

Параметры нужно перечислять через запятую после -script-args.

Если ваша формы авторизации использует cookies параметры или csrf-token, то в этом случае выдаст ошибку. (И это хорошо, значит базовую защиту вы предусмотрели).

В качестве защиты стоит использовать стойкие пароли, а также ограничивать количество запросов с одного IP-адреса (Rate limiting).

3. Ищем скрытые папки и файлы

Часто разработчики или системные администраторы довольно халатно относятся к правам доступа и забывают закрыть доступ к системным и другим важным папкам. Проверить есть у нас на сервере такие папки можно также с помощью утилиты nmap. Команды будет выглядеть так (вместо <target> нужно подставить IP-адрес сервера или домен сайта) :

В результате в отчете нам покажут доступные для просмотра папки, интересные файлы – файлы паролей, резервные копии базы данных и тд. (Если такие существуют). Дальше уже вам нужно самостоятельно решить какие папки и файлы нужно закрыть от просмотра, а какие оставить как есть.

Пример небольшого отчета.

4. Проверяем на SQL инъекции

Так повелось, что большинство современных веб-приложений в той или иной мере используют SQL базы данных. Обычно параметры веб-страницы или какие-либо пользовательские данные подставляются в SQL запросы и результаты запроса отображаются на веб-странице. Если передаваемые параметры плохо фильтруются, то веб-сервис становится уязвимым для SQL инъекций.

Если сайт уязвим и выполняет такие инъекции, то по сути есть возможность творить с БД (чаще всего это MySQL) что угодно. Именно таким образом чаще всего воруют базы пользователей и их личные данные.

Далее я покажу как с помощью скриптов быстро и эффективно проверить есть в вашем продукте подобные уязвимости. Часто даже довольно опытные разработчики забывают о мерах предосторожности, поэтому даже серьезные продукты имеют подобные проблемы. Попробуем проверить наш тестовый веб-сервис на наличие таких проблем c помощью инструмента sqlmap.

Установка sqlmap.

Sqlmap – это кроссплатформенный сканер с открытым исходным кодом, который позволяет в автоматическом режиме тестировать веб-сервисы на наличие SQL инъекций, а затем использовать их для получения контроля над базой данных.

В данной статье я рассмотрю только способы как можно находить уязвимые для SQL инъекций страницы, API и формы без подробностей о том, как использовать найденные уязвимости для нанесения вреда. (Владельцы сайтов тут облегченно вздохнули). Для использования необходим python версии 2.7 и старше.

Установка на Windows

Для начала работы нам необходимо установить Python. Установщик Python для Windows можно найти на официальном сайте. Ссылку я прикрепил ниже.

На сайте две ветки – 2.x и 3.x, но скачать и установить лучше ветку 3.x. Sqlmap корректно работают с каждой из этих версий, но в дальнейшем нам потребуется версия 3.x.

Загрузить последнюю версию sqlmap можно здесь. Распакуйте архив в любую удобную папку (чтобы было проще ее найти можно распаковать в папку С:Users<имя вашего пользователя>)

Для запуска вначале нужно открыть командную строку. Нажмите Win+R, в появившемся окне введите cmd и нажмите enter. Пример запуска:

Установка на Mac OS X

Для начала установим Python. Для этого откройте Tерминал и запустите следующую команду.

Теперь установим sqlmap.

Запуск sqlmap для Mac OS X.

Начинаем проверку

В моем тестируемом сервисе я специально подготовил sql уязвимости. Попробуем найти их следующей командой. Параметр –dbs означает, что нам интересны имена баз данных. В случае успеха и наличия уязвимости, после определения баз данных можно перейти к поиску таблиц и получения нужных данных. Команду необходимо вводить в консоль.

Через некоторое время скрипт может попросить нас уточнить некоторые данные. В данном случае выбираю “нет”, чтобы скрипт прогнал все тесты.

Скрипт выводит отчет:

После продолжения анализа нас в первую очередь интересует строчка в конце: GET parameter ‘id’ is vulnerable. Do you want to keep testing the others (if any)? [y/N].

Как можно видеть, скрипт определил, что параметр id уязвим и предлагает протестировать другие параметры. В нашем конкретном случае других параметров нет, но в реальных веб-приложениях таких параметров может быть десятки, так что иногда имеет смысл проверить все.

Итоговый отчет:

В итоге скрипт не только определил, что параметр id является уязвимым, но и версию СУБД, а также получил название используемой базы данных на сервере – vc_test, в которой содержится контент сайта. Эту информацию можно найти в конце сгенерированного отчета.

В дальнейшем для злоумышленника уже обычно не проблема получить данные в таблицах, а возможно и полный контроль над всей БД, а то и всем нашим сервером и исходным кодом сайта, если для запросов используется пользователь с широкими правами.

Кроме того, sqlmap позволяет задавать http заголовки и параметры Cookies, что довольно удобно для тестирования, особенно когда для получения результата запроса требуется авторизации.

Пример тестирования запроса POST. Параметры, которые передаются в теле запроса записываются в опцию скрипта –data. Необходимые параметры для POST запроса можно подсмотреть в консоли браузера (Ctrl + Shift + I в Windows, затем перейти в вкладку Network, совершить нужное действие, а затем изучить каким образом формируется запрос)

После авторизации обычно необходимо передать нужные Сookie. В sqlmap за это отвечает опция –cookie. Нужные значения cookies можно получить в инструментах разработчика вашего браузера. (в Windows ctrl+shift+i, затем найдите вкладку Network, а в ней щелкните на запрос с именем домена сайта. В окне справа пролистайте пока не увидите параметр cookie)

Пример команды sqlmap c опцией –cookie.

Если параметров несколько, то можно явно указать какой параметр будем тестировать с помощью опции -p.

Можно задавать http заголовки через опцию –headers. Это крайне полезно для тестирования ваших API.

Также если get параметр передается не как get параметр, а как URI, то в этом случае нужно явно указать с помощью *, что данная часть URI является параметром. Пример:

Таким образом можно довольно тщательно протестировать ваше веб-приложение на наличие SQL инъекций. Также крайне полезно использовать sqlmap для автоматических тестов и запускать их после каждого изменения кода вашего приложения и не допускать код в ветку master, если он содержит уязвимость.

Для защиты от SQL инъекций нужно тщательно фильтровать параметры и HTTP заголовки, а также использовать подготовленные запросы.

5. Проверка на XSS уязвимости.

Межсайтовый скриптинг (XSS) – это уязвимость, которая заключается во внедрении злоумышленником своего Javascript кода в веб-страницу, которая отображается в браузере пользователя.

После такого внедрения злоумышленник фактически захватывает веб-страницу и может манипулировать данными пользователя, когда он находится на странице. В случае успеха злоумышленник может:

Уязвимость возникает из-за недостаточной фильтрации данных, которые выводятся при отображении страницы.

Такие уязвимости довольно часто встречаются даже в крупных продуктах, поэтому стоит обязательно тестировать свои веб-приложения на наличие XSS уязвимостей.

В данном случае для тестирования мы воспользуемся утилитой XSStrike

ХSStrike – это довольно продвинутый сканер для поиска XSS уязвимостей c открытым исходным кодом. Он написано на Python3 и довольно прост в начальной настройке и использования.

Установка

Для установки необходимо скачать архив по ссылке и распаковать в удобную вам папку. После этого необходимо открыть консоль (ранее я уже показывал как это сделать в Mac и Windows) и перейти в распакованную папку. Затем нужно выполнить команды в консоле:

Установим необходимые для корректной работы библиотеки:

Теперь мы готовы к тестированию. Пример простого запуска, вместо моего url укажите адрес страницы, которую хотите протестировать:

Очень быстро скрипт обнаруживает, что параметр page является уязвимым ( строчка Reflections found ) и через него можно передать js код, который будет исполнен на странице. Пример такого кода приводится в строчке Payload. Такой тип XSS уязвимостей называется reflected XSS.

Кроме того, можно проверять и формы. Отправим на проверку форму, которая отправляет сообщение в наш сервис. Чтобы передать список POST параметров используем опцию –data.

Результат: параметр name уязвим.

Как выглядит ответ, когда скрипт не находит уязвимых параметров:

Кроме того, в XSStrike поддерживает возможность передавать http заголовки, в том числе и cookies и проверять страницы для открытия которых нужна авторизация. Для этого используется опция –headers

Также можно запустить обход по всему сайту. Нужно указать стартовую страницу и сканер начнет обход всех найденных страниц. Запись -l 100 отвечает за количество страниц обхода.

Скрипт покажет страницы, на которых были найдены уязвимые параметры. Найденные страницы можно уже исследовать подробнее.

Также полезная функция – обход url страниц, которые указаны в файле с помощью опции –seeds. Можно также использовать вместе с опцией –headers.

Таким образом можно достаточно тщательно проверить свое веб-приложение на XSS уязвимости. Также хорошим ходом будет написать простой bash скрипт для объединения всех проверок XSS в один скрипт, специально заточенный под ваш проект.

Его задачей будет тестировать ваше веб-приложение после каждого изменения исходного кода и не пускать коммит в ветку master, если страницы и формы содержат XSS уязвимости .

Для борьбы с XSS уязвимости нужно также тщательно фильтровать данные, которые показываются пользователю.

Заключение

Надеюсь руководство будет полезным и поможет вам сделать свои сайты и веб-приложения безопаснее. Также стоит проверять не только сам сайт, но и ваши админки и вспомогательные сервисы на поддоменах, ведь они также могут быть уязвимы перед подобными автоматизируемыми системами и скриптами.

Конечно приведенные меры не обеспечивают 100% защиты, и я не рассказал о многих других типовых уязвимостях, но показанные меры помогут защитить проект от автоматизированных систем взлома и злоумышленников с невысокими навыками.

Если есть вопросы, то смело пишите их в комментариях или мне в телеграм t.me/alex.belousov92

Также будет интересно почитать, что вы используете для тестирования безопасности ваших веб-приложений. Если статья наберет достаточное количество плюсов, то напишу продолжение. Поэтому не забудьте проголосовать, если статья понравилась!

Информационная безопасность, Разработка систем связи, Сетевые технологии, IT-стандарты

---

Рекомендация: подборка платных и бесплатных курсов создания сайтов – https://katalog-kursov.ru/

Первоначально разработанный для браузеров, SSL/TLS-протокол позже стал стандартом де-факто вообще для всех защищенных интернет-коммуникаций. Сейчас он используется для удаленного администрирования виртуальной инфра­структуры, развернутой в облаке, для передачи платежных реквизитов покупателя от серверов электронной коммерции к платежным процессорам, таким как PayPal и Amazon, для пересылки локальных данных в облачное хранилище, сохранения переписки в мессенджерах и аутентификации серверов в мобильных приложениях iOS и Android.

Список ситуаций, когда обмен весьма чувствительной информацией требует максимальной безопасности, довольно внушителен. В этой статье мы рассмотрим, как безопасность этих коммуникаций обеспечивается на практике.

SSL/TLS-протокол: хотели как лучше…

В теории, защищённое SSL/TLS-протоколом соединение должно обеспечивать конфиденциальность, достоверность и целостность коммуникаций клиентского и серверного софта, – даже в условиях присутствия активного продвинутого злоумышленника из сети: когда сеть полностью захвачена врагом, DNS отравлен, а точки доступа и маршрутизаторы, коммутаторы и WiFi контролируются злоумышленником; злоумышленником, который помимо всего прочего контролирует SSL/TLS-бэкэнд. Кроме того, когда клиентский софт пытается подключиться к законному серверу, – злоумышленник может подменить сетевой адрес сервера (например, через отравление DNS), и вместо законного сервера, перенаправить клиента на свой злонамеренный сервер.

Безопасность коммуникаций в таких суровых условиях, как известно, целиком зависит от адекватности проверки криптографического сертификата, предоставленного сервером при установке соединения. В том числе от адекватности реализации набора шифров (ciphersuite), которыми клиент и сервер пользуются при обмене данными. Для того чтобы SSL/TLS-соединение было полностью безопасным, клиентский софт, в числе прочего, должен тщательно удостовериться, что:

• сертификат выдан действующим органом сертификации;
• срок его действия не истёк (или сертификат не был отозван);
• в списке перечисленных в сертификате имён присутствует тот домен, к которому производится подключение.

…а получилось как всегда: примеры провальной проверки SSL/TLS-сертификата

Однако во многих приложениях и библиотеках, для которых безопасность коммуникаций очень критична, процедура проверки SSL/TLS-сертификата, – и даже EV-SSL, сертификата с расширенной проверкой [4], – полностью провальная. Во всех популярных операционных системах: Linux, Windows, Android и iOS. Среди уязвимого софта, библиотек и middleware-сервисов можно выделить следующие [1]:

• Amazon’овская Java-библиотека EC2 и все облачные фронтэнд-клиенты построенные на её основе.
• Amazon’овский и PayPal’овский торговый SDK, ответственный за доставку платёжных реквизитов от сайтов (на которых развёрнута инфраструктура онлайн-коммерции) к платёжным шлюзам.
• Интегрированные «корзины», такие как osCommerce, ZenCart, Ubercart и PrestaShop, которые не проверяют сертификаты вообще.
• AdMob-код используемый мобильным софтом для показа контекстной рекламы.
• Интерфейсные фронтэнд-компоненты ElephantDrive и FilesAnywhere, ответственные за взаимодействие с облачным хранилищем.
• Android’ная библиотека Pusher и весь софт, который использует Pusher API для управления обменом мгновенными сообщениями (например, GitHub’овский Gaug.es).
• Apache HttpClient (версия 3.x); Apache Libcloud; и все клиентские подключения к серверам Apache ActiveMQ и т.п.
• SOAP middleware-сервисы Java, в том числе Apache Axis, Axis 2, Codehaus XFire; а также весь софт, который на базе этих middleware-сервисов построен.
• API-инструменты Elastic Load Balancing.
• Weberknecht-реализация WebSockets’ов.
• А также весь мобильный софт, построенный на базе перечисленных выше библиотек и middleware-сервисов (чтобы понять, что такое middleware-сервисы, смотри рис. 1); в том числе iOS-клиент хостинг-провайдера Rackspace.

Рисунок 1. Что такое middleware-сервисы

Кроме того, в [2] перечислено ещё больше сотни уязвимых мобильных приложений (см. рис. 2). В том числе: Android’s Google Cloud Messaging, Angie’s List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (remote access), Cisco Technical Support, Cisco Webex, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer, Google Earth, Huntington Mobile (Bank), Intuit Tax Online Accountant, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (VPN client), SouthWest Airlines, Uber, US Bank – Access Online, WesternUnion, WordPress, Yahoo! Finance, Yahoo! Mail.

Рисунок 2. Небольшая выборка из списка уязвимых мобильных приложений

Логические уязвимости SSL/TLS-протокола

SSL/TLS-соединения всего этого и многого другого софта уязвимы для широкого спектра MiTM-атак. При этом, MiTM-атаку можно провести, зачастую, даже без подделки сертификатов и без похищения приватных ключей, которыми серверы подписывают свои сертификаты. MiTM-атаку можно провести – просто эксплуатируя логические уязвимости, которые присутствуют в процедуре проверки SSL/TLS-сертификата на стороне клиентского софта. В результате MiTM-злоумышленник может, например, собирать токены авторизации, номера кредитных карт, имена, адреса и т.п. – у любого продавца, который использует уязвимые веб-приложения обработки платежей.

Поставщики мобильного софта, которые берут за основу сэмпл-код AdMob для связи своих приложений с AdMob-аккаунтом, тоже уязвимы, – они позволяют атакующему захватывать учётные данные, и получать доступ ко всем его Google-сервисам. К примеру, из-за некорректной проверки сертификатов в таких мессенджерах как Trillian и AIM, MiTM-злоумышленник может похитить учётные данные для входа ко всем сервисам Google (включая Gmail), Yahoo!; и также к сервисам Windows Live (в т.ч. SkyDrive). Среди других уязвимостей, которыми страдает современный небраузерный веб-софт: использование неправильных регулярных выражений при сравнении имени хоста; игнорирование результатов проверки корректности сертификата; случайное или преднамеренное отключение проверки. [1]

Другие распространённые уязвимости реализации SSL/TLS-протокола

Ну и конечно же нельзя забывать о том, что даже если в реализации SSL/TLS-протокола нет логических ошибок (если конечно кто-то в это ещё верит), то защиту можно обойти посредством похищения приватного ключа [12], посредством применения 0day-эксплойтов к таким вещам как клавиатуры, браузеры, операционные системы, утилиты и прошивки [3]; посредством компрометации BGP-маршрутизации [10]; или атаковать SSL/TLS по аппаратным (см. рис. 3) [8] и/или программным [9] обходным каналам.

Рисунок 3. Атака на SSL по аппаратным обходным каналам

Кроме того, злоумышленники могут выполнять практически невидимые MiTM-атаки, злоупотребляя механизмом кэширования SSL/TLS-сеансов, реализованным в классе SSLSessionCache. Этот механизм проверяет достоверность сертификатов только при первоначальном соединении; и при этом не способен должным образом аннулировать сеанс связи после удаления сертификатов с устройства. Кроме того, после перезагрузки Android-устройства (через опции «Перезапуск» или «Отключить питание») можно продолжать видеть зашифрованный трафик некоторых приложений, которые после перезагрузки не запускались, но до перезагрузки работали. Так например с Google Maps происходит. В [2] описано, как благодаря этим недочётам кэширования, злоумышленник может совершенно прозрачно для пользователя устанавливать и удалять «невидимые сертификаты», и затем устанавливать сетевое соединение с любым приложением.

Рисунок 4. Ретроспектива уязвимого шифрования

Среди других распространённых уязвимостей реализации SSL/TLS-протокола можно отметить уязвимое шифрование (см. рис. 4) [5], повторное использования GCM (Galois/Counter Mode; счётчик с аутентификацией Галуа) [6], хитрость с CNG (CryptoAPI-NG) в Schannel (см. рис. 5) [7], некорректную проверку цепочки доверия [2], некорректную проверка имени хоста [11].

Рисунок 5. Хитрость с CNG: вытягиваем секреты из Schannel

Некорректная проверка цепочки доверия представляет собой ситуацию, когда веб-приложение принимает абсолютно любой сертификат, в котором указано корректное имя хоста, не проверяя при этом каким центром сертификации он был подписан. Это позволяет перехватывать и дешифровывать пароли и/или номера кредитных карт. А в некоторых случаях даже делать инъекцию вредоносного кода. В Android-софт данная уязвимость проникает, например когда создаётся кастомизированный X509TrustManger-интерфейс, который игнорирует исключения CertificateException. Или когда разработчик софта вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Некорректная проверка имени хоста представляет собой ситуацию, когда веб-приложение принимает сертификат, не удостоверившись в том, что хост, с которого этот сертификат пришёл, присутствует в списке доверенных хостов. В Android-софт данная уязвимость проникает, например когда создаётся HostnameVerifier-интерфейс, который при любых условиях возвращает TRUE. Или когда разработчик софта в вставляет в код WebViews-компонента вызов метода SslErrorHandler.proceed(). [2]

Коренная причина существования уязвимостей в SSL/TLS-протоколе

Коренная причина существования подавляющего большинства перечисленных уязвимостей – ужасный API-дизайн SSL/TLS-библиотек (в том числе JSSE, OpenSSL, и GnuTLS). А также не менее ужасный дизайн библиотек передачи данных (таких как cURL, Apache HttpClient и urllib), каждая из которых представляет собой высокоуровневую обёртку для SSL/TLS-библиотек. Не говоря уже о middleware-сервисах (таких как Apache Axis, Axis 2, или Codehaus XFire), которые ещё более высокоуровневой обёрткой являются, и которые увеличивают «снежный ком» ужасного дизайна ещё больше. Вместо того чтобы вести с прикладным разработчиком (зачастую далёким от системного программирования) диалог на понятном ему языке (в терминах конфиденциальности и аутентификации), абстрагировано от низкоуровневых подробностей реализации SSL/TLS-протокола, эти API вываливают на бедолагу кучу низкоуровневых SSL/TLS-параметров, непонятных ему. Требуют от высокоуровневого софта, чтобы он правильно выставлял низкоуровневые опции; реализовывал функции проверки имени хоста и заботился об интерпретации возвращаемых низкоуровневыми операциями значений.

В результате, прикладные разработчики используют SSL/TLS API неправильно: ошибочно интерпретируют многообразие их параметров, опций, побочных эффектов и возвращаемых значений. Например [1]:

• Amazon’овская PHP-библиотека Flexible Payments Service пытается включить проверку имени хоста – посредством установки параметра CURLOPT_SSL_VERIFYHOST в значение TRUE (в cURL-библиотеке). Однако корректное значение по умолчанию для этого параметра – 2; если же присвоить ему значение TRUE, то этому параметру незаметно для разработчика присваивается значение 1, и т.о. проверка сертификата отключается.
• PHP-библиотека PayPal Payments Standard – приобрела ту же самую ошибку; причём в тот момент, когда предыдущая, уязвимая, реализация обновлялась (т.е. одну ошибку убрали, другую добавили).
• Другой пример – это Lynx, тексто-ориентированный браузер. Он проверяет самоподписанные сертификаты, – но только в том случае, если GnuTLS’ная функция проверки сертификата возвращает отрицательное значение. Однако эта самая функция для некоторых ошибок возвращает 0; в том числе в тех случаях, когда сертификаты подписаны недоверенным органом. Из-за этого цепочка проверки доверия в Lynx – нарушена.

Кроме того, прикладные разработчики зачастую неправильно понимают, какие именно гарантии безопасности предоставляет та или иная SSL/TLS-библиотека. Поэтому в дикой природе можно встретить клинические случаи, когда в приложениях, принципиально нуждающихся в защищённых коммуникациях (например, взаимодействующих с платёжным процессором), используется SSL/TLS-библиотека, которая не проверяет SSL/TLS-сертификаты вообще. Более прозаичные, но ещё более убийственные случаи – это когда разработчик какого-нибудь из промежуточных слоёв софта молча отключает процедуру проверки SSL/TLS-сертификатов (он это может сделать, например, для тестирования системы, а после тестирования – забыть вновь включить её). При этом высокоуровневый программный код, использующий этот промежуточный слой, уверен, что проверка сертификатов производится. Т.о. ошибки SSL/TLS часто бывают скрыты в глубине одного или сразу нескольких промежуточных слоёв-библиотек – из-за чего обнаружить данную проблему становится практически невозможно.

Например, в JSSE (Java Secure Socket Extension) расширенный интерфейс SSLSocketFactory API – молча пропускает проверку имени хоста, если поле «algorithm» в SSL-клиенте установлено в NULL или в пустую строку, – а не в HTTPS. Хотя данное обстоятельство упоминается в справочном руководстве JSSE, многие Java-реализации SSL-протоколов используют SSLSocketFactory без выполнения проверки имени хоста…

Ложка мёда в бочку дёгтя

Т.о., по факту получается, что в большинстве современного небраузерного веб-софта проверка SSL/TLS-сертификатов либо отключена совсем, либо реализована неправильно. На рисунке 7 представлена классификация актуальных уязвимостей SSL/TLS-протокола. Некоторые из этих уязвимостей, но не все, были описаны и/или упомянуты выше. Ознакомиться с упомянутыми, но неописанными уязвимостями – можно почитав материалы, перечисленные в библиографии.

Рисунок 6. Классификация актуальных для SSL/TLS уязвимостей

Ну и чтобы добавить ложку мёда в бочку дёгтя, стоит отметить, что в [1] подробно/понятно/популярно/грамотно описано, как SSL реализовываться должен, со ссылкой на RFC. Лучшего описания, которое бы технически точным и одновременно понятным было, мы не встречали. Также в [1] разбираются самые распространённые SSL-библиотеки, с классификацией по уровню абстрагирования (низкоуровневые/высокоуровневые). Всё с диаграммами и лаконичными алгоритмами в псевдокоде. Подробно уязвимости конкретных продуктов описаны, с приведением программного кода некорректного, и указанием ошибок. Так что если вдруг у кого-то в очередной раз возникнет желание создать такую реализацию SSL/TLS-фреймворка, которая станет исключением из поговорки «хотели как лучше, а получилось как всегда», то [1] – идеальное для этого начало.