О публичном Wi-Fi, поддельных SSID’ах и sslstrip

19 ноября 2018

По моему печальному опыту, многие люди, включая даже тех, кто работает в сфере ИБ, считают, что атака «человек посередине» (Man in the Middle, MITM) является теоретической, и на практике не представляет реальной угрозы. Дескать, зачем сайту TLS, если это «всего лишь блог» (на WordPress, с админкой). Хотя, казалось бы, прикрутить Let’s Encrypt — дело пяти минут. Так или иначе, я подумал, что будет нелишним рассказать/напомнить о том, как легко делается MITM в современных реалиях. И для этого совсем не обязательно быть интернет-провайдером.

Примечание: В этом контексте вас также можгут заинтересовать посты Как ломают WPA/WPA2 сети с помощью aircrack-ng и Снифинг Ethernet-трафика с платой Throwing Star.

Важно! Статья опубликована исключительно с целью информирования общественности о существующих угрозах. Я не призываю вас в каким бы то ни было действиям, а также не несу за них ответственности. Должен предупредить, что практически во всех странах неправомерный доступ к компьютерной информации является противоправным действием, предусматривающим ответственность вплоть до уголовной. Например, если вы живете в России, см главу 28 уголовного кодекса.

Поднимаем поддельную точку доступа

Было решено провести небольшой эксперимент. Для этого я использовал свой довольно новый телефон Sony Xperia X (F5121) со всеми последними обновлениями, версия Android 8.0. С этим телефоном я решил погулять вокруг дома и поискать публичные точки доступа (access point, AP). Найдя очередную точку доступа, я подключался к ней и проверял, действительно ли она пускает в интернет.

Где-то через пол часа были найдены следующие AP:

  • Moscow_WiFi_Free
  • Starbucks_Beeline_Free
  • MT_FREE

Вернувшись домой, я взял первый попавшийся под руку Wi-Fi роутер и настроил в нем гостевую сеть с SSID «Moscow_WiFi_Free». Что же мы видим? Телефон радостно подключается к Wi-Fi точке. Делает он это автоматически, участие пользователя не требуется. Теперь весь трафик идет через роутер.

Таким образом, кто угодно может создать публичную Wi-Fi точку у себя на балконе или в публичном месте (аеропорт, конференция, …) и наблюдать за трафиком ничего не подозревающих прохожих. На самом деле, не только наблюдать, но также и изменять его. Не нужно клонировать MAC-адреса, не нужно знать номер канала, достаточно только SSID.

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

Перехватываем незашифрованный трафик

А знаете ли вы, что просто сидя в кафе с публичной точкой доступа, можно мониторить трафик всех, кто подключен к этой точке доступа? Для этого даже не требуется специального оборудования, такого, как LimeSDR. Подойдет любой приличный Wi-Fi донгл, или даже беспроводная сетевая карта, встроенная в ноутбук. Для описанного далее эксперимента я лично использовал донгл Panda Wireless PAU07 на базе чипа Ralink RT5572.

Первым делом, переводим донгл в monitor mode:

sudo airmon-ng start wlp0s20u1

Посмотрим, какой канал использует интересующий наш роутер:

sudo airodump-ng wlp0s20u1mon

В моем случае использовался 8-ой канал. Снифаем весь трафик:

sudo airodump-ng -c 8 -w wifi-traffic wlp0s20u1mon

Поскольку трафик передается в открытом виде, не составляет большого труда проанализировать его:

# грепаем строки
strings wifi-traffic-01.cap | grep http

# выводим все логины-пароли
dsniff -p wifi-traffic-01.cap

# выводим все URL
urlsnarf -p wifi-traffic-01.cap

# почему-то tshark находит намного больше URL
tcpdump -r wifi-traffic-01.cap -n -w - tcp port 80 | \
  tshark -V -Y "http.request || http.response" -r - | \
  grep 'Full request URI'

# также через tshark видны все куки и формы
tcpdump -r wifi-traffic-01.cap -n -w - tcp port 80 | \
  tshark -V -Y "http.request || http.response" -r -

Таким образом, чтобы провести MITM, даже не нужно быть владельцем роутера.

Даунгрейд до HTTP

С учетом вышесказанного, не удивительно, что современные браузеры ругаются на сайты, не использующие TLS, а поисковые системы пессимизируют такие сайты в выдаче. Но действительно ли использование сайтом TLS защищает от MITM? Оказывается, что не защищает.

Для следующего эксперимента я использовал роутер, настроенный в рамках поста Превращаем Raspberry Pi в беспроводной роутер, и заодно заворачиваем весь трафик в VPN. Как было отмечено в той статье, совсем не обязательно использовать именно Raspberry Pi — подойдет любой компьютер с двумя сетевыми интерфейсами под управлением Linux. Малина была использована исключительно по той причине, что у нее места на диске побольше и менеджер пакетов поудобнее, чем у типичного роутера с OpenWrt.

Ставим и запускаем sslstrip:

sudo apt install sslstrip
sslstrip -l 8080

В соседнем терминале говорим:

sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 \
  -j REDIRECT --to-port 8080

Теперь на стороне клиента открываем браузер и видим чудо — все HTTPS-сайты магическим образом превратились в HTTP! Почему это работает? Потому что в общем случае браузер не знает, поддерживает сайт HTTPS или не поддерживает. Сначала браузер шлет запрос по HTTP, и если в ответе содержится редирект на HTTPS, только тогда он использует HTTPS. Конечно, если только пользователь явно не ввел что-то вроде https://eax.me, но кто же так делает? Как результат, можно подсунуть HTTP-прокси, который сделает вид, что сайт не поддерживает HTTPS, после чего все логины с паролями пойдут в открытом виде. Именно это sslstrip и делает.

Надо признать, описанное выше работает не во всех случаях. Во-первых, наблюдательный пользователь может заподозрить неладное, если у его любимого сайта внезапно отвалится HTTPS. Во-вторых, современные браузеры агрессивно кэшируют все подряд, в том числе редиректы с HTTP на HTTPS. Наконец, существует HTTP Strict Transport Security (HSTS). Но если очистить кэш браузера, посетить новый сайт, или открыть браузер на только что установленной системе, прием работает безотказно.

Выводы

Приведенный список возможных атак далек от полного. За кадром остались поддельные DNS-записи, ARP spoofing, модификация трафика с помощью Squid, а также атаки KARMA, Heartbleed и другие. В качестве источника дополнительной информации здесь можно рекомендовать прекрасную книгу Hacking Exposed Wireless, Third Edition.

Но посыл, надеюсь, понятен. Публичный Wi-Fi ненадежен. TLS определенно не защищает от всего. MITM — не менее серьезная атака, чем RCE или SQL Injecion.

Как защититься? Во-первых, внимательно следите за адресной строкой браузера. Если сайт не использует TLS, лучше побыстрее с него уйти, и уж точно не следует делать на нем покупки. Во-вторых, не используйте публичные AP. Если вы вынуждены их использовать, по окончании работы не забывайте подчищать список известных сетей. Наконец, в-третьих, поднимите себе VPN и заведите привычку делать все только через него. Лично я в последнее время так и делаю.

Метки: , .

Понравился пост? Узнайте, как можно поддержать развитие этого блога.

Также подпишитесь на RSS, Facebook, ВКонтакте, Twitter или Telegram.