Исследователи Mathy Vanhoef и Frank Piessens из iMinds-DistriNet и KU Leuven обнаружили опасную уязвимость в устаревшем, но все еще широко применяемом потоковом шифре RC4. В случае с веб-сайтами, уязвимость позволяет дешифровать часть зашифрованного HTTPS-потока (например, сессионный идентификатор, передающийся в Cookie) за десятки часов. Для реализации уязвимости необходимо применять MiTM-атаку, прослушивать и сохранять зашифрованный трафик, а также иметь возможность выполнять большое количество запросов от имени жертвы (как было и в случае POODLE), что проще всего достингуть, если внедрять жертве специальный скрипт на HTTP-страницы других сайтов, генерирующий большое количество запросов на интересующий хакера сайт. Кроме того, злоумышленнику необходимо каким-то образом узнать или установить свое значение Cookie, которое бы располагалось близко к искомому значению в передаваемом трафике.

В ходе исследования было выяснено, что для совершения атаки на дешифрование типичного значения сессии из 16 символов требуется около 75 часов активной атаки, после которой получить искомое значение можно в 94% случаев.

Ребята улучшили старую атаку от AlFardan, которая основывается на построении и использовании разброса распределений исследователей из Cisco Fluhrer и McGrew, добавив вариант распределения японских исследователей Takanori Isobe, Toshihiro Ohigashi, Yuhei Watanabe, Masakatu Morii, и скомбинировав их. Текст около искомого Cookie требуется для нахождения Байесовской вероятности.

Если атаку на HTTPS организовать достаточно проблематично, то, в случае с Wi-Fi, цифры более реальные: требуется всего 1 час активной атаки на сеть, после которой получается дешифровать используемый временной ключ, используемый для передачи Unicast-трафика (pairwise transient key, PTK). Атака сильно упрощается за счет наличия криптографически слабой проверки подлинности в TKIP-фреймах. Примечательно, что точки должны периодически (как правило, каждый час) менять этот ключ, однако большинство точек обновляют только ключ, который используется для передачи Broadcast-трафика — groupwise transient key (GTK). В любом случае, уязвимы даже правильно работающие точки, т.к. атака занимает чуть меньше времени, чем требуется для обновления ключа.
TKIP
Шифр RC4 до сих пор часто используется в HTTPS-протоколе из-за необходимости поддержки устаревших ОС и ПО, таких как Windows XP и Internet Explorer 6 и 7. Шифрование WPA2-TKIP широко используется для беспроводной передачи данных через Wi-Fi.

Чтобы обезопасить себя от данной уязвимости, необходимо отключить поддержку шифра RC4 на стороне сервера. Если вам необходимо сохранить совместимость с устаревшим ПО, используйте шифр 3DES вместо RC4. Интересно, что пару лет назад все выключали 3DES и переходили на RC4 из-за атак, связанных с блочными шифрами, вроде Lucky 13 и BEAST, а сейчас, похоже, придется делать все наоборот. Но самым правильным вариантом является отключение и того, и другого.

Пользователям Wi-Fi достаточно задать использование шифра WPA2-AES (или WPA2-CCMP) в настройках точки доступа. Рекомендуем сделать это сразу, т.к. возможность совершения данной атаки, вполне возможно, появится в скором времени в утилитах вроде aircrack-ng.

All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS — подробный PDF с описанием атаки.

Комментарии (5)


  1. lorc
    17.07.2015 21:01

    Забавно. Я думал что AES уже довольно старый алгоритм и хотел удивиться, что IE6 не поддерживает его. Но оказалось что IE6 вышел в 2001 году, а AES приняли как стандарт только в 2002.


  1. mtp
    18.07.2015 02:23

    > достаточно задать использование шифра WPA2-AES (или WPA2-CCMP)

    WPA2-TKIP — нет?


    1. ValdikSS Автор
      18.07.2015 02:29
      +1

      TKIP уязвим, а CCMP — нет. Чтобы обезопаситься, нужно выставить использование CCMP.


  1. KorDen32
    18.07.2015 12:11

    Так вроде уже давно же общие рекомендации по настройке WiFi — WPA2-AES(CCMP)-only, ибо TKIP кажется имел проблемы в 802.11n (ЕМНИП скорость канала >150 мбит/с многие точки поддерживают только на AES)


    1. ValdikSS Автор
      18.07.2015 12:58

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