Проверьте своего хостера на уязвимость Shellshock

    В связи «открытием» повсеместно обсуждаемой в последнее время Shellshock-уязвимости (например, здесь и здесь), а также преследуя благую цель устранения возможных неприятных последствий использования этой уязвимости, сервис мониторинга сайтов ХостТрекер предоставляет возможность мгновенно определить наличие этой самой уязвимости на линуксовых серверах и установленным веб-сервером (проверка результата происходит через http).

    image


    Как это работает?


    Алгоритм очень простой. Мы последовательно делаем 4 запроса к серверу:
    1. Обычный запрос.
    2. Запрос, пользуясь уязвимостью, пытается разместить на проверяемом сервере куку, которая приведет к 2-х секундной задержке выполнение нашего специального запроса http.
    3. Запрос, пользуясь уязвимостью, пытается разместить на проверяемом сервере куку, которая приведет к 4-х секундной задержке выполнение нашего специального запроса http.
    4. То же, что и в п.3.

    image

    Что имеем в результате?


    Проверка осуществляется путем попыток разместить куки, пользуясь уязвимостью. Кука вызывает задержку обработки запроса http сначала на 2, а затем — на 4 секунды. После чего сравнивается результат. Здесь возможны 3 варианта:
    1. Уязвимость есть, если наблюдается разница во времени отклика в 2 секунды между запросом без куки и запросом с кукой, вызывающей 2-х секундную задержку, а также между 2-х секундной кукой и 4-х секундной. То есть, нашим запросам удалось использовать уязвимость и разместить куку.

    2. Уязвимости нет — все запросы получают ответ за приблизительно равное время. То есть куку разместить не удалось.

    3. Неопределенная ситуация. Может возникнуть, если сервер под сильной нагрузкой, и время отклика постоянно скачет. Зафиксировать, является ли разница задержки результатом деятельности квазивредоносной куки, или же кратковременного пика нагрузки на сервер, не представляется возможным. Для проверки этой ситуации мы делаем два последовательных запроса с одинаковой задержкой — 3-й и 4-й. Если их результат сильно разнится, значит задержка случайна и не зависит от нашей куки (которая, возможно, вообще не записалась). В этом случае наш метод не может определить наличие уязвимости.

    Безопасность проверки


    Наша проверка не может причинить ущерб серверу. Все, чем Вы рискуете — это появлением одной «лишней» куки на сервере. Эта кука используется только при нашем тестовом запросе, и никаких задержек для рабочих сайтов она вызвать не может.
    ХостТрекер
    Сервис мониторинга доступности сайтов
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

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

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

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

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

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

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

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

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

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое