RIP, Paint 2017
Еще на тему
Популярные Операционная система
 | WindowsРейтинг: 15,651.9 |
 | LinuxРейтинг: 4,161.9 |
 | Android OSРейтинг: 1,796.0 |
 | iOSРейтинг: 769.9 |
 | Linux vs WindowsРейтинг: 456.9 |
 | UbuntuРейтинг: 291.5 |
 | mac OSРейтинг: 47.9 |
Сейчас на сайте
Всего пользователей на сайте: 424
Такое сильное некромантство, что свежая версия на этой неделе вышла https://www.imagemagick.org/download/
А разве этот имейджмэджик как-то связан с майкрософтом (ну или предком от майкрософта)?
Из вики:
In May 2016, it was reported that ImageMagick had a vulnerability through which an attacker can execute arbitrary code on servers that use the application to edit user-uploaded images.
https://arstechnica.com/security/2016/05/exploits-gone-wild-hackers-target-critical-image-processing-bug/
Тем более, что альтернатив-то не особо. Почти все библиотеки обработки изображений на PHP, Perl или Python опираются на ImageMagick
Не знаю как там с PHP и Perl (в PHP коде я действительно часто видел использование ImageMagick, так как там ничего другого нету), но я не припомню ни одну библиотеку для Python, чтобы она опиралась на ImageMagick, кроме как PythonMagick, который просто python обертка для API ImageMagick. Все часто используемые библиотеки, такие как PIL, Pillow, scikit-image никак не зависят от ImageMagick.
Но нет худа без добра. Все это безобразие очень ускорило развитие защитных мер на уровне самой OS - grsec, apparmor, selinux...
Но в случае с ImageMagick достаточно было загрузить специальную картинку.
Хотя я не безопасник, могу ошибаться.
Потому следует предполагать, что любые сервисы потенциально уязвимы. И должны быть ограничены своей песочницей так жестко, как только вообще возможно. В случае apache, к примеру, у пользователя, под которым он работает, не должно быть прав на чтение/выполнение чего бы то ни было вне папки со скриптами сайта. Тогда доступ к bash из под Апача не дал бы ничего, кроме кучи записей в логи, вне зависимости от того, воспользовались бы злоумышленники уязвимостью в ImageMagick или mod_cgi.
И где он почти везде включен? По дефолту, cgi модуль выключен. И в apache2.conf нужно еще разрешить выполнение cgi скриптов. A CGI сейчас почти нигде не используется.
Ну самое главное, ну ок, mod_cgi включен, для того, чтобы воспользоваться уязвимостью этого мало, нужно чтобы cgi скрипт был, причем handler должен быть bash. Иначе от этой уязвимости не холодно не жарко. Я ведь ничего не путаю?
>> нужно посмотреть у кого хостится потенциальная жертва и заказать там себе хостинг
И нужно, что бы заказанный хостинг был в одной локальной сети с жертвой, и нужно каким-то образом притворится DHCP сервером (чего в большинстве случаев сделать не удастся из-за ограничений хостинга). Чтобы притворится DHCP сервером, нужно ответить на широковещательное UDP сообщение клиента о service discovery раньше настоящего DHCP сервера. И когда клиент решит запросить IP адрес у DHCP сервера тоже совсем не ясно.
Слишком много "и", "но" и "если". Сделать все это можно только в специфических условиях, и то очень сложно. В случае с ImageMigick достаточно было чтобы был сервис, который обрабатывает изображения...
Хендлер не важен, шелшок срабатывает при установке переменных окружения, обычно используется кука или реферер.
> Слишком много "и", "но" и "если"
Да не, никто же не рассчитывает на мгновенный эффект. Включат свой допиленный DHCP-сервер, начнут рассылать ответы и конфликты (чтобы повторный запрос прошел), через некоторое время все получится.
Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень, особенно с учетом большого количества говнокодеров на PHP, достаточно вспомнить PHPbb, кажется версии 1.7, который пол-рунета раком поставил из-за уязвимости.
На вики речь шла именно о mod_cgi, и если хэндлер bash. Я не уверен, что оно распространяется на все остальное.
>> Хендлер не важен, шелшок срабатывает при установке переменных окружения
Как я понимаю, при выполнении вредоносного реквеста, apache (или другой http сервер) устанавливает эту вредоносную переменную окружения, затем вызывает хэндлер. Если хэндлер bash, то эти переменные окружения попадут в bash и тот выполнит код из переменной. Если они в bash не попадут, то ничего и не произойдет.
Так или нет? Баг существовал сугубо в bash, а переменные окружения существуют на уровне OS, если переменные ставятся, но bash не вызывается, то ничего не происходит. Если хэндлер java или Python, то никакого bash там не будет, если его не вызовут из того же java и python кода.
Есть опыт применения подобных эксплоитов? У меня нету.
>> Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень,
Я согласен на 100%. Я лишь хотел сказать, что в случае с ImageMigick эксплоитится в разы проще.
> Есть опыт применения
Только на своей машине. Проверил. Ужаснулся. Обновил bash.
Да, но питон так не запускают, для питона существует wsgi интерфейс, и для апача отдельный модуль mod_wsgi. wsgi модуль выполняет внутри встроенный интерпретатор питона и вызывает напрямую функции питона из С. Т.е. никакой bash не вызывается. С PHP та же история, есть mod_php, который запускает напрямую интерпретатор PHP. С perl то же самое - mod_perl. Никто не будет запускать bash, просто потому, что это не безопасно и медленно.
Я это к тому, я сомневаюсь, что уязвимости были подвержено что-то помимо mod_cgi, так как только он запускает bash. Чистый mod_cgi я как-то не видел, чтобы где-то использовался, он даже по дефолту выключен. Может так java'у запускают, я не знаю, с java в web не работал.
> Только на своей машине. Проверил. Ужаснулся. Обновил bash.
Просто из bash-a через env, или поднимал apache и слал вредоносный реквест?
А вот mod_perl был популярен где-то в нулевых, но потом его вытеснил mod_fcgi за счет универсальности. Собственно, кроме фреймворка Catalyst я вот так с ходу не могу вспомнить ничего, что использовало бы mod_perl. Впрочем, и mod_fcgi используется нечасто - это решение для высоких нагрузок, подразумевающее работу скрипта в цикле запрос-ответ, а не запрос-запуск-ответ-завершение.
Насчет Питона не скажу, я с ним работал мало и вообще не понимаю, зачем он существует в вебе.
> Чистый mod_cgi я как-то не видел, чтобы где-то использовался
У меня ровно противоположный опыт - mod_cgi используется везде и есть везде, где есть Апач. Это базовый и универсальный модуль для работы с любым динамическим контентом. Вот типичная цитата из описания: mod_cgi is responsible for handling all requests for programs which should be executed on the server. This includes shell/Perl/Python/PHP scripts but it is not limited only to these. It is also responsible for sending the proper error pages to the clients when a problem is encountered.
Насчет проверки: оба варианта. Когда шелшок только опубликовали, я просто его проверил. А когда попалась на глаза статья про использование его в Apache, то поднял на виртуалке двухлетний бэкап системы и проверил на Апаче. Использование через ping и dhcp не проверял, но второе для меня очевидно - dhcp запускает конфигурационные утилиты через bash - тот же ip или ifconfig в зависимости от настроек.
прон в бмп формате.
моник от MAG с колесиком, котэ спящее на нем...
даже, трава была зеленее...