Открыть список
Как стать автором
Обновить

Комментарии 16

А не надежнее было бы дёрнуть get/post запрос на ваш сервер и по нему уже понять, если или нет уязвимость? Я просто не специалист по подобным системам.
Да, мы рассматривали этот вариант. Но использование, например, wget, хотя бы и упростило нам жизнь — но сузило бы круг серверов, доступных для проверки. Все-таки подобное ПО не является обязательным, и на некоторых серверах его просто может не быть.
Перепробовать несколько (curl, ещё что-нибудь), а если не нашли — в качестве резервного варианта уже время отклика?
А то выглядит странно: выбрали универсальный, но ненадежный способ против надежного+ненадежный в случае отказа.
Да, этот вариант также рассматривался. Пока решили сделать проще. Возможно, модернизируем проверку со временем.
Хорошо бы заметить, что эта проверка покрывает только простые случаи.

Скажем если у вас уязвимый bash, но PHP-скрипты подключены через FastCGI (скажем если стоит только NGINX), то простая проверка не сработает, но если используется какая-то из функций, которая вызывает system и у вас /bin/sh — это bash, то система в целом будет уязвимой.

Но да, 90% (если не 99%) «простых» случаев ваша проверка покрывает, а главное — с вероятностью почти 100% если ответ «да», то нужно всё бросать и заниматься «починкой» сайта.
повсеместно обсуждаемой

Спасибо, узнал об уязвимости.
Проверка осуществляется путем попыток разместить куки

Почему из всех HTTP-полей для тестирований выбрано только поле с Cookie? Судя по разнообразным примерам и другим скриптам проверки на уязвимость, можно также использовать, как минимум поле User-Agent.
Да, действительно, можно проверять User-Agent, и другие поля. Мы решили выбрать куки. Можно, конечно, проверять все доступные поля одновременно — но это будет дополнительная нагрузка на сервер, хотя и незначительная.
Наверное можно еще проверять на ping XXXXXX.yourhost.name, а PowerDNS умеет дергать скрипт при резолвинге имени.

Я могу ошибаться, но имхо это бесполезное занятие. Чтобы сработала эта уязвимость, нужно

1) Должен быть разрешен CGI
2) В каталоге должен быть CGI скрипт написанный на баше
3) Вы должны знать имя скрипта ( или скрипт должен быть вида index.cgi)

По умолчанию у Apache каталог cgi-bin находится не в корне и никаких скриптов там нет. Ваш скрипт запрашивае корень сайта ( /). Как много современных сайтов находится под управлением bash?

Те искать уязвимость нужно более точечно, проверка корня наверное мало что даст.
Да, Вы правы:
1) По поводу CGI — если он не разрешен, то злоумышленники уязвимостью через CGI воспользоваться тоже не смогут. Что и требуется проверить.
2) Скрипт действительно должен быть, и Вам необходимо знать его имя. То есть можно проверять только свои сервера, а не все подряд. Это затрудняет использование нашего сервиса в любых подозрительных схемах.
А почему вы забыли рассказать про то, что спустя 4-5 дней после публикации уязвимости вы все еще не закрыли ее?
И после того, как я залил шелл и написал на почту — даже спасибо не сказали?
От себя лично я говорю Вам: большое спасибо! Перепиской с Вами и закрытием «дыры» занимались другие люди, я уточню у них, какая там ситуация и что произошло.
Я вам написал в личку, посмотрите пожалуйста.
Спасибо за предоставленную информацию. Вы помогли выловить и исправить довольно интересный баг.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Украина
Сайт
www.host-tracker.com
Численность
2–10 человек
Дата регистрации

Блог на Хабре