LINUX.ORG.RU
ФорумTalks

[Talks][opennet] Представлен эксплойт, способный блокировать работу любого SSL-сервера

 ,


0

1

Для Ъ:

Известная немецкая хакерская группа THC представила эксплойт, реализующий DoS-атаку против любого SSL-сервера с задействованием всего одной или нескольких атакующих машин. Уязвимость присутствует во всех известных реализациях SSL и не может быть устранена без переработки принципа работы сервера.

Идея, заложенная в эксплойт, очень проста и основана на том факте, что для установки SSL-соединения серверная сторона тратит в 15 раз больше ресурсов, чем клиентская. Фактически, все что делает эксплойт, это создает бесконечный поток подключений к серверу, что в конечном итоге приводит к исчерпанию ресурсов последнего. THC уверяет, что для введения среднестатистического сервера в состояние отказа в обслуживании понадобится всего 300 SSL-подключений в секунду, которые с легкостью обеспечит стандартный ноутбук, подключенный к сети с помощью DSL-канала. Большая ферма серверов, оснащенная балансировщиком нагрузки сможет выдержать натиск не более чем 20 таких ноутбуков, пропускной канал каждого из которых которых составляет всего 120 Кбит/с.

Надежной защиты от данного способа атаки пока не существует и вряд ли появится в ближайшем будущем. Максимум, что могут сделать системные администраторы, это отключить механизм SSL-Renegotiation и установить SSL Accelerator, благодаря которым удастся повысить производительность SSL-сервера и защититься хотя бы от атак, производимых с одной машины.

Получить код эксплойта можно с домашней страницы THC, на которой опубликована урезанная версия, которая не будет работать в отношении серверов с отключенным SSL-Renegotiation. Полную функциональность эксплойта можно повторить с помощью стандартного openssl-клиента:

   thc-ssl-dosit() {
       while :; do 
          (while :; do echo R; done) |\
          openssl s_client -connect 127.0.0.1:443 2>/dev/null;
       done
    }

Новость

Капец защищенному вебу?

Chaser_Andrey ★★★★★
() автор топика

>Идея, заложенная в эксплойт, очень проста и основана на том факте, что для установки SSL-соединения серверная сторона тратит в 15 раз больше ресурсов

эм.. неужели все так просто?

null123 ★★
()

Со стороны сервера ограничивать кол-во соединений с одного клиентского IP уже не модно?

sdio ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Только теперь? Немецкие ученые открыли что-то новое?

sdio ★★★★★
()

Вот если бы теперь прикрутить к семейству Низкоорбитальный Ионных Пушек! :}

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

>Зато теперь себестоимость DDoS'а упадёт в разы/десятки раз. Разве не так?
Не так, проблема с DDoS - это то, что забивают канал, а не процессор. А забивать канал таким образом наоборот сложнее.

Tark ★★
()
Ответ на: комментарий от Tark

> проблема с DDoS - это то, что забивают канал, а не процессор.

OMG. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании».

Chaser_Andrey ★★★★★
() автор топика

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

kovrik ★★★★★
()

чета у меня локалхост нифига не ддосится. wtf!?

Rastafarra ★★★★
()
Ответ на: комментарий от Chaser_Andrey

> Хотелось бы услышать комментарии аналитиков лора, админов и хакиров.

судя по тому, что гугл все еще жив, все пошли читнуть манцов.

Rastafarra ★★★★
()
Ответ на: комментарий от Chaser_Andrey

>OMG. Distributed Denial of Service, распределённая атака типа «отказ в обслуживании».
Да, так оно и расшифровывается. И что? Проблему с загрузкой процессора можно временно решить с помощью ограничения количества запросов и бана. А вот проблему с забиванием канала хрен решишь. А если забьют канал датацентра, то там хоть пляши, придется обращаться к магистральным провайдерам.

Tark ★★
()
Ответ на: комментарий от Rastafarra

>судя по тому, что гугл все еще жив, все пошли читнуть манцов.

Скорее всего в гугле не быдлоадмины сидят, и защита от миллиона коннектов в секунду с одного ИПа у них давно работает. Так что это может оказаться проблемой только для всяких хоумпаг, хостящихся на собственном третьем пне с вендой.

kranky ★★★★★
()

Скрипт у кого нибудь заработал?!

lexxus-lex ★★★
()
Ответ на: комментарий от Tark

> Проблему с загрузкой процессора можно временно решить с помощью ограничения количества запросов и бана.

В этом и проблема. Придется в разы уменьшить количество SSL-запросов, по сравнению с обычными, и количество машин для DDoS надо куда меньше. Это не проблема разве? А если на одном IP сидят целые сетки?

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

> Ну какой идиот в качестве примера запишет туда реальный IP?

ipAddress:443

А так уж очень на шутку похоже. Из разряда диалога в чате:

- Чуваки, я нашёл крутую хакерскую программу! Она валит компы по IP! Дайте какой-нибудь адрес проверить!
- 127.0.0.1
- Ну ща этот мудак получи...
* Connection with client was terminated

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

Мне кажется, что любой, кто мало-мальски понимает в программировании (пусть даже и не собирается использовать эскплоит), сразу понял, что нужно заменить 127.0.0.1 на реальный ip....

kovrik ★★★★★
()

Жрёт несколько процентов CPU.

Yareg ★★★
()
Ответ на: комментарий от Chaser_Andrey

Проблему с загрузкой процессора можно временно решить с помощью ограничения количества запросов и бана.

В этом и проблема. Придется в разы уменьшить количество SSL-запросов, по сравнению с обычными, и количество машин для DDoS надо куда меньше. Это не проблема разве? А если на одном IP сидят целые сетки?

Почему в разы? Уменьшить до уровня, который позволяют серваки. Это же нормально.

Pavval ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

>В этом и проблема. Придется в разы уменьшить количество SSL-запросов, по сравнению с обычными, и количество машин для DDoS надо куда меньше. Это не проблема разве? А если на одном IP сидят целые сетки?
В чем проблема? Придется уменьшить количество запросов на стороне сервера, соглашусь, но машин для DDoS нужно столько же, так как нужно забить канал, а не процессор сервера. Это грузит проц, поэтому ботнеты использовать проблема, так как изрядные тормоза люди заметят. А если на одном IP сидят целые сетки, то это замечательно, но пофиг. Да и сейчас keep-alive использут для https, поэтому не на каждый запрос проходит установка ssl соединения, поэтому лимиты не так страшны.

Tark ★★
()

Как бы скриптик не соответствует тому, что написано у самих thc. Там говорится:

This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection.

Это совсем не тоже самое, что:

while :; do 
          (while :; do echo R; done) |\
          openssl s_client -connect 127.0.0.1:443 2>/dev/null;
done

zloelamo ★★★★
()
Ответ на: комментарий от zloelamo

А хотя может и тоже самое. Я тут видать что-то не догнал.

zloelamo ★★★★
()

> Уязвимость присутствует во всех известных реализациях SSL и не может быть устранена без переработки принципа работы сервера.

4.2. Установка несколькоступенчатого шифра все решает. Т.е. проверка легковесным алгоритмом, если прошло - более сложным, а в конце - последним, тем, на котором и основывается надежность. Предыдущие - лишь защита от ДОСа, их взлом может быть вполне реализуемой задачей, но требующей в сотни раз больших ресурсов, чем проверка подлинности.

segfault ★★★★★
()

root@root# while :; do openssl s_client -connect example.com:443 2>/dev/sda & done

VladimirMalyk ★★★★★
()
Ответ на: комментарий от thesis

>И тут мы с пацанами выпили фанты и тормознули гмэйл.

И очень сильно испугались, что придут большие дяди и..

..но тут вспомнили что мы наркоманы, и успокоились!

xnix ★★
()
Ответ на: комментарий от sdio

Забить канал - одна из разновидностей DDoS, причем продают в основном ее. Если бы ты не поленился прочитать, то прочитал бы, что я отвечал на коммент в котором обсуждается себестоимость DDoS, поэтому я ответил, что эта вещь не повлияет на цену.

Tark ★★
()
Ответ на: комментарий от segfault

Ты что курил? Какой взлом? Речь о DoS сервера клиентом.

Deleted
()

для введения среднестатистического сервера в состояние отказа в обслуживании понадобится всего 300 SSL-подключений в секунду

бред...

либо имеется ввиду среднестатистический сервер года 2005го, либо они тестировали s_server'ом - он запросы последовательно обрабатывает, на io_wait всё потеряли...

ei-grad ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.