Страницы

Гигабаг в OpenSSL


Вчера ночью кибермир потрясла новость о серьезном баге в программе OpenSSL.
В этой новости прекрасно всё:
и то, что баг позволяет любому человеку считывать оперативную память удаленного сервера,
и то, что баг позволяет серверу считывать память браузера пользователя,
и то, что успешная атака никак не отразится в логах,
и то, что уязвима по некоторым оценкам треть всех https серверов, ДБО, bitcoin, TOR и I2P,
и то, что баг существовал 2 года,
и даже то, что авторы OpenSSL выпускали столь серьезный и простой патч аж полгода (!)

Теперь подробнее.



Уязвимость позволяет удаленному атакующему получить доступ к случайному участку памяти сервера размером 64кб. Насколько опасна уязвимость лично мне до конца неясно. С одной стороны, в памяти сервера хранятся сведения о паролях, закрытых ключах, идентификаторах активных сессий и так далее. С другой стороны, в памяти хранится мноооого всякого говна, и 64кб - это достаточно маленький кусочек, чтобы вот прям так сразу считать все самое самое секретное.
Вообщем, пока что в реальном деле эта уязвимость ещё не замечена, однако натравить эксплоит на какой-нибудь серьезный сервер и получить заветные 64кб памяти сейчас проще, чем 2 бита переслать.

Для чего: 
а) качаем и устанавливаем Python 2.7.6 для Windows (лучше тот, который просто x86);
б) качаем этот скрипт и сохраняем в папку c:\temp под именем ssltest.py;
в) выбираем сайт-жертву (вот уже база насканненых серверов), проверяем наличие уязвимости тут или тут;
г) открываем командную строку и вбиваем:
cd c:\temp
c:\Python27\python.exe ssltest.py <тут имя сайта. Например, cbr.ru>
д) в фаил c:\temp\dump будет записан кусок памяти сервера примерно такого вида:


В дамп попал кусок какого-то https-запроса от одно из пользователей сайта. Было ли в нём что-то важное, не было ли в нем ничего важного - это науке неизвестно.

Что нужно обязательно сделать

На каждом уязвимом сервере необходимо:
1. Обновить OpenSSL до версии 1.0.1g;
2. Поменять сертификат https (это будет стоить денег), так как закрытый ключ мог быть скомпрометирован;
3. Сбросить все активные сессии и куки пользователей;
4. Поменять все пароли на вебсервере (лучше и пользователей попросить их сменить).
5. Постараться не думать о возможных последствиях всего этого, если предположить, что кто-то давно знал об этой уязвимости или намеренно допустил такой баг.

Это, конечно, сильный удар по безопасности opensource приложений. Несмотря на популярность пакета OpenSSL, баг существовал минимум 2 года (!), а патча мы ждали более 5 месяцев после того, как разработчики узнали о проблеме (!!). Но в случае с проприетарным ПО ситуация могла бы быть намного хуже.
Думаю, правильным выходом из этой ситуации будут краудфандинговые кампании по сбору средств на аудит кода свободного ПО. Наверняка подобная кампания будет создана для OpenSSL в ближайшее время. Когда это произойдет, я добавлю сюда линк.

PS Удобный декодер символов вида %D0%90%D0%BB%D0%B5%D0%BA в русские буквы. Может пригодится для чтения дампов ;)


[UPDATE] А вот и реальный вектор атаки.

В одном из дампов одного форума оказался PHPSESSID.


Подменив с помощью Burp Suite свой PHPSESSID на ID из дампа, удалось зайти в чужую сессию. Нужный ID'шник можно прописать в куки и напрямую.


ставьте патчи.


PPS Дать ребятам из OpenSSL денег чтобы лучше работали можно здесь (биткоины поддерживаются!)

PPPS Не забудьте обновить OpenVPN и прошивку маршрутизаторов где есть https панель управления!

Комментариев нет:

Отправка комментария