Иногда технически неподготовленные люди продавая IT услугу либо продукт, на вопрос «а как насчёт надёжности вашей системы?» отвечают: «У нас всё защищено по https». Если с другой стороны такой же технически неподготовленный человек, то вопрос автоматически закрывается, и все остались довольны уровнем безопасности. Сам неоднократно был свидетелем подобного разговора. Было смешно.
HTTPS активно продвигается Интернет сообществом и основная идея перевести весь Интернет к определённому году на шифрованный трафик, благо современные машины это позволяют. HTTPS — это всегда хорошо. Но нужно знать и подводные камни связанные с ним.
Задача данной статьи — показать возможность слушать HTTPS трафик пользователя (назовём его Степан), и чтобы он этого не заметил.
Мы не будет брать последние исследования и эксплоиты в области взлома HTTPS. Пойдём лучше к основам и рассмотрим давно известные и простые способы.
HTTPS — это HTTP + SSL. Http — это открытый протокол передачи данных, открытый означает, что данные передаются в открытом виде. SSL — это протокол, обеспечивающий безопасное соединение посредством шифрования. То есть, наша задача состоит именно в том, чтобы перехватить чистый трафик нашего Степана и вывести его на чистую воду, какие же ХХХ сайты он смотрит по вечерам. Но мы ведь не как наш Степан и не смотрим XXX, поэтому для примера возьмём поисковик bing, который пока ещё может работать как по https, так и по http.
Ниже на картинке пример как выглядит перехваченный трафик при помощи WireShark на один и тот же запрос в bing для HTTP и для HTTPS.
HTTPS действительно криптует все данные включая урл-адреса, которые генерирует клиент. Но HTTPS построен на базе TCP/IP, то есть, информацию о том, куда направляется трафик, можно получить в незашифрованном виде. Мы говорим о Mac-адресах, IP адресах и портах.
С помощью онлайн инструментов (например, whois.domaintools.com) можно узнать, что это за IP адрес, кому принадлежит, а простым запросом в bing можно узнать, какие сайты крутятся на этом IP адресе (например, www.bing.com/search?q=ip:204.79.197.200).
Продолжим и подумаем вот о чём. Веб-сервер может хостить несколько сайтов, и у каждого может быть свой SSL сертификат. Следовательно, наличие просто IP адреса является недостаточным. Веб-сервер, когда к нему приходит первый запрос, должен знать, с каким именно сайтом необходимо установить соединение. Шифрования ещё нет, потому что его ещё необходимо установить. Значит, ещё до начала шифрования клиент должен передать каким-то образом информацию о домене сайта, чтобы веб-сервер мог зароутить клиентский запрос на необходимый ресурс. Следовательно, необходимо посмотреть на самый первый запрос от клиента на сервер, который инициирует начало самого шифрования. Снова возьмём наш любимый WireShark и посмотрим.
Здесь мы можем найти кое-что интересное:
HTTP проксики типа Fiddler-а (на рисунке выше) уже умеют делать экстракт этой информации из трафика.
Казалось бы всё, но есть ещё один способ узнать, не прибегая к взлому HTTPS, на какие ресурсы ходил Степан. Когда в браузере он набирает адрес сайта, то первый запрос идёт не на сервер, гда сайт находится, первый запрос идёт на DNS сервер, чтобы получить IP адрес для данного домена. DNS запросы не шифруются, поэтому только слушая DNS трафик, можно составить историю, какие ресурсы Степан посещал, и по IP адресу DNS сервера можно определить даже, где он приблизительно находился в это время.
Самое время подвести результаты:
Но нам всё-таки мало знать, что и когда посещал наш Степан. Наша задача узнать, что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации). Продолжение следует во второй части.
Денис Колошко, CISSP
HTTPS активно продвигается Интернет сообществом и основная идея перевести весь Интернет к определённому году на шифрованный трафик, благо современные машины это позволяют. HTTPS — это всегда хорошо. Но нужно знать и подводные камни связанные с ним.
Задача данной статьи — показать возможность слушать HTTPS трафик пользователя (назовём его Степан), и чтобы он этого не заметил.
Мы не будет брать последние исследования и эксплоиты в области взлома HTTPS. Пойдём лучше к основам и рассмотрим давно известные и простые способы.
HTTPS — это HTTP + SSL. Http — это открытый протокол передачи данных, открытый означает, что данные передаются в открытом виде. SSL — это протокол, обеспечивающий безопасное соединение посредством шифрования. То есть, наша задача состоит именно в том, чтобы перехватить чистый трафик нашего Степана и вывести его на чистую воду, какие же ХХХ сайты он смотрит по вечерам. Но мы ведь не как наш Степан и не смотрим XXX, поэтому для примера возьмём поисковик bing, который пока ещё может работать как по https, так и по http.
Ниже на картинке пример как выглядит перехваченный трафик при помощи WireShark на один и тот же запрос в bing для HTTP и для HTTPS.
HTTPS действительно криптует все данные включая урл-адреса, которые генерирует клиент. Но HTTPS построен на базе TCP/IP, то есть, информацию о том, куда направляется трафик, можно получить в незашифрованном виде. Мы говорим о Mac-адресах, IP адресах и портах.
С помощью онлайн инструментов (например, whois.domaintools.com) можно узнать, что это за IP адрес, кому принадлежит, а простым запросом в bing можно узнать, какие сайты крутятся на этом IP адресе (например, www.bing.com/search?q=ip:204.79.197.200).
Продолжим и подумаем вот о чём. Веб-сервер может хостить несколько сайтов, и у каждого может быть свой SSL сертификат. Следовательно, наличие просто IP адреса является недостаточным. Веб-сервер, когда к нему приходит первый запрос, должен знать, с каким именно сайтом необходимо установить соединение. Шифрования ещё нет, потому что его ещё необходимо установить. Значит, ещё до начала шифрования клиент должен передать каким-то образом информацию о домене сайта, чтобы веб-сервер мог зароутить клиентский запрос на необходимый ресурс. Следовательно, необходимо посмотреть на самый первый запрос от клиента на сервер, который инициирует начало самого шифрования. Снова возьмём наш любимый WireShark и посмотрим.
Здесь мы можем найти кое-что интересное:
- Первый запрос действительно содержит доменное имя сайта в незашифрованном виде, с которым будет инициироваться HTTPS соединение
- Второй запрос возвращает сам сертификат в незашированном виде на клиента, который содержит информацию, для какого домена он выдан. В случае с bing, сертификат ещё включает и расширенное поле Subject Alternative Name, в котором перечисляются домены, для которого сертификат может быть использован (в Bing сертификате можно найти даже адреса на staging среду).
HTTP проксики типа Fiddler-а (на рисунке выше) уже умеют делать экстракт этой информации из трафика.
Казалось бы всё, но есть ещё один способ узнать, не прибегая к взлому HTTPS, на какие ресурсы ходил Степан. Когда в браузере он набирает адрес сайта, то первый запрос идёт не на сервер, гда сайт находится, первый запрос идёт на DNS сервер, чтобы получить IP адрес для данного домена. DNS запросы не шифруются, поэтому только слушая DNS трафик, можно составить историю, какие ресурсы Степан посещал, и по IP адресу DNS сервера можно определить даже, где он приблизительно находился в это время.
Самое время подвести результаты:
- Не взламывая трафик мы всё-таки можем отследить какие ХХХ ресурсы (защищённые либо нет) наш Степан посещает вечерком.
- Можно написать скрипт для фильтрации и ведения полной истории, что Степан посещал, скажем, за последний год (мы не сможем сказать, что он там делал, но с определённостью можно сказать, что он там точно был).
- Если у меня есть непосредственный доступ к трафику (я — админ, который контролирует роутинг, или я — интернет провайдер, через который течёт трафик), то мне даже нет необходимости делать какие-либо действия на клиентской машине, чтобы направить трафик на меня.
- Wi-Fi или спутниковый Интернет может быть слабо защищён, и, зная адрес клиента, можно определить с какими ресурсами он работает.
- И самое главное. Степан так ничего и не заметил, а мы уже потихоньку собираем о нём информацию.
Но нам всё-таки мало знать, что и когда посещал наш Степан. Наша задача узнать, что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации). Продолжение следует во второй части.
Денис Колошко, CISSP