Как вы знаете, небольшая группа киевлян (в составе двух представителей и меня) посетила . Мероприятие мне понравилось, с удовольствием поучаствую в дальнейших. Кроме этого я после месячного перерыва выпил кофе в Старбаксе. В общем поездка удалась.
По дороге к Старбаксу мы перекусили в заведении “Жан-Жак”, отведав французской кухни.
Там я по привычке решил проверить, как обстоят дела с безопасностью в сети WiFi (это была широко распространённая сеть BeelineFreeWiFi, точно название не помню, но она была и в “Драфте”). Если раньше мне приходилось ухищряться, запуская поддельные arp-запросы, чтобы перехватить чужой трафик, то здесь я оказался в лёгком ступоре – чужой unicast-трафик доступен любому, кто подключился в эту сеть, причём без всяческих MITM.
Поясню своё удивление. На тестовом стенде, состоящем из WiFi-маршрутизатора , iPhone “жертвы” и ноутбука “исследователя”, я вижу исключительно трафик broadcast/multicast (на iPhone я активно хожу при этом по web):
115.713064 192.168.99.12 -> 224.0.0.251 MDNS Standard query ANY ole-iphone.local, "QM" question 116.020249 192.168.99.12 -> 224.0.0.251 MDNS Standard query ANY ole-iphone.local, "QM" question 116.020298 Apple_43:7e:5b -> Broadcast ARP Who has 169.254.255.255? Tell 192.168.99.12 116.225019 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 116.327381 192.168.99.12 -> 224.0.0.251 IGMP V2 Membership Report / Join group 224.0.0.251 117.248977 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 119.194596 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 123.290697 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local 131.278119 192.168.99.12 -> 224.0.0.251 MDNS Standard query response A, cache flush 192.168.99.12 PTR, cache flush ole-iphone.local
Для заворачивания чужого трафика нужно реализовать MITM-атаку. Войдя в сеть WiFi Билайн, я увидел весь unicast-трафик без каких-либо ухищрений. Выдержки показывать не буду, я их не сохранял, но в двух ресторанчиках ситуация _идентична_. Ребята мельком видели WiFi Access Point DLink в первом заведении… Вероятно именно в этом проблема. Мне рассказали первую заповедь sales-менеджера: “DLink не продавать!!!”. Я полностью с этим согласен, у меня был когда-то DLink, и для того, чтобы войти в сеть WiFi, мне приходилось перед сеансом работы передёргивать его по питанию. Это было давно, и сейчас я использую либо Linksys, либо Airport.
Я не специалист по беспроводному доступу, но могу провести аналогию с коммутаторами. Unicast-трафик начинает флудить на все порты (аналогично broadcast/multicast) в том случае, если коммутатор теряет таблицу MAC-адресов (например, из-за переполнения она обнуляется), и ему приходится её строить заново. Вероятно используются AccessPoint low-end типа DLink, которые расчитаны, допустим, на 10 одновременных подключёний, а их гораздо больше. Или же эти low-end AP работают только в режиме “хаба”. В общем безопасность сетей публичного доступа близка к нулю, особенно если это усугубляется дешевизной решения. Я буду благодарен за ваши мысли в комментариях по поводу такого странного поведения.
Вечером в ресторане “Драфт” за 20 минут я идентифицировал четыре iPhone, затем (без MITM) перехватил трафик со своего iPhone. Для демонстрации я сделал публикацию статьи в своём блоге (обычный XML-RPC через клиент WordPress через обычный для всех блогов http) и получил без малейшего усилия всю информацию по доступу к блогу. После этого я, конечно же, поменял пароль, соединившись на Маке через любимый OpenVPN.
Резюмирую. Безопасности нужно уделять хоть какое-то внимание. Не стоит важные вещи делать через WiFi, желательно иметь VPN-соединение end-to-end, или же все операции производить через протоколы с поддержкой SSL (https, imaps). Иначе сюрприз в виде утечки важной информации не заставит долго ждать.
