8 апреля компания Codenomicon опубликовала описание серьезной уязвимости в библиотеке OpenSSL. Библиотека используется в тысячах программных продуктов для операций подписи, шифрования и получения конрольных сумм. С ее помощью шифруется более 99% всего защищенного трафика в интернете. Каждый раз, когда Вы обращаетесь к сайту по протоколу HTTPS (например, или ) сервер, скорее всего, использует именно OpenSSL.
Мы через несколько часов после информации о ней, и сайты наших клиентов защищены. Однако медлительная реакция остального сообщества вызывает у нас опасения.
Мы также запустили русифицированный веб-сервис для проверки сайтов.
.
ПРОСТЫМИ СЛОВАМИ
В протоколе SSL предусмотрена возможность периодически посылать своего рода эхо-пакеты. Таким образом клиент "напоминает" серверу о себе, как бы говоря ему "я здесь, я живой", чтобы сервер не разорвал соединения при неактивности клиента. Такой подход несколько ускоряет работу, потому что если сервер разорвет соединение, клиенту придется устанавливать его заново, а на практике для установления зашифрованного соединения уходит несколько сотен миллисекунд, что доставляет дискомфорт пользователям.
Когда клиент посылает пакет, он указывает его длину. Сервер затем возвращает пакет обратно из своей памяти. Уязвимость заключается в том, что сервер не проверяет длину, которую указал клиент. Таким образом клиент может послать 1 байт, но указать длину в 1000 байт. Сервер вернет 1000 байт из своей памяти: 1 байт, посланный клиентом, и еще 999 байт чужих данных, которые в этот момент времени оказались по соседству с тем самым байтом.
ЧТО ЕСЛИ МОЙ САЙТ НЕ ИСПОЛЬЗУЕТ SSL?
Не имеет значения. Злоумышленник не обращается к Вашему сайту, он обращается к серверу, на котором находится Ваш сайт. Если сервер отвечает по протоколу HTTPS, и он уязвим, то с сервера можно получить блок памяти, в которому могут оказаться и Ваши данные.
СТЕПЕНЬ УГРОЗЫ
Текущие реализации атаки могут получить с сервера 16 Кб данных. Поскольку операционная система выделяет память процессам и потокам псевдослучайно, в этих 16 Кб данных может быть все, что угодно. Мы провели множество проверок, и видим, что в одних случаях там нет ничего, кроме бесполезного мусора, в других -- пароли от контрольной панели сервера. Но даже если Ваш сервер возвращает ненужный атакующему "мусор", не спешите радоваться.
Следующие моменты значительно усугубляют ситуацию:
Атакующий может повторять атаку сколько угодно раз. В следующий раз запрос атакующего вообще может обслуживать другой процесс или поток веб-сервера (так и должно быть), а значит злоумышленник считает уже другой блок памяти с вашего сервера. Даже если такого не происходит, память постоянно перераспределяется. Завтра в том же блоке памяти будут совсем другие данные. Злоумышленник может просто считывать все, что в этом блоке есть, пока Вы не закроете уязвимость.
Использование уязвимости совершенно незаметно. Атакующий не оставляет следов. Его запрос нигде не фиксируется, в т.ч. в журналах веб-сервера и системах статистики, просто потому, что запроса и не было. SSL-сессия устанавливается до подачи запроса веб-серверу. Атакующий просто устанавливает сессию, забирает данные и разрывает сессию, не запрашивая никакой страницы. Никакие данные на диск не пишутся, все происходит в оперативной памяти.
Уязвимости уже больше года. Никто не знает, была ли она известна кому-либо до 8 апреля 2014 года, и использовал ли ее кто-либо.
Атакующему не обязательно получать доступ к Вашему сайту. Он может доступ к сайту на том же сервере и уже оттуда проводить локальную атаку, либо вообще получить административные права на сервере.
СТЕПЕНЬ ПОКРЫТИЯ
8 апреля из 10000 самых посещаемых сайтов интернета уязвимыми было . В масштабе России ситуация практически аналогичная: оценочно уязвимо более 5% серверов.
До сих пор не закрыли уязвимость некоторые хостеры, наиболее крупным из которых является .
КАК БОРОТЬСЯ С УЯЗВИМОСТЬЮ
Первое и очевидное решение, которое приходит в голову: просто выключить SSL. На практике это самое сложное, т.к. сама по себе поддержка HTTPS "зашита" в веб-серверы, и может потребоваться перекомпиляция ПО, что в свою очередь может привести к другим ошибкам.
Второй способ: закрыть на сетевом экране порт 443, по которому обычно происходит взаимодействие по протоколу HTTPS. Может помочь, но требуется правильная конфигурация веб-сервера, чтобы он не позволял инициировать HTTPS-соединение на обычных портах, например, 80. Иначе у Вас будет чувство защищенности, в то время как веб-сервер продолжит оставаться уязвимым.
Оба перечисленных способа могут дать обратный эффект. SSL изначально был призван защитить данные при их передаче. Отключая SSL, Вы просто даете злоумышленникам еще одну возможность для атаки.
Третий (правильный) способ борьбы с уязвимостью: обновить все программное обеспечение сервера до версий, которые уже не содержат уязвимость.
Если Вам нужна помощь или у Вас есть дополнительные вопросы, пожалуйста, .
