Бывает, что админ защитил свой Web-ресурс динамическими изображениями. В этом случае софтварные брутфорсеры отдыхают. Придется прибегнуть к интеллектуальному, или, попросту, ручному, перебору. Если ты знаешь логин к ресурсу, можно подобрать пароль, каждый раз вводя новый код на изображении.Для облегчения работы можно использовать различные тулзы для браузеров, которые обеспечат автозаполнение неизменных полей.
Случается так, что злоумышленнику не нужен шелл, а взлом ведется только для того, чтобы стереть машину с лица интернета. Такие атаки часто выполняются по заказу. DDoS относится к самым злосчастным атакам, за проведение которой могут оторвать конечности. Все из-за того, что весь перегнанный мусор оплачивает владелец сервера. А ему этого ой как не хочется делать :).
У серьезных проектов существует своя служба безопасности (или abuse). Ее задача – распознавать атаки и сообщать владельцам сетей об их факте. В связи с этим, никто никогда не занимаются DDoS, используя сервера в сети своего провайдера. Чаще всего подобные злодеяния совершаются из консоли забугорных машин. Такие системы «заражены» специальными ботами, которые умеют обмениваться данными между собой. Скажем, захотел хакер убрать whitehouse.gov. Для этого он соединяется с зарутанным китайским сервером, командует в консоли «./ddos whitehouse.gov» и идет пить пиво. После запуска программа ./ddos заглядывает в свой конфиг, находит там пару сотен таких же «затроянненых» систем и шлет всем команду. В ней, как ты уже догадался, содержится принуждение убить сайт whitehouse.gov. Конечно, программа ./ddos – чистая абстракция, но принцип работы зомби-серверов именно такой.
Помимо программ существуют злые IRC-боты и целые ботнеты, созданные для того, чтобы останавливать работу серверов любой мощности. Если ботовод заставит на определенном канале флудить какую-нибудь жертву, все боты разом начнут слать сетевые пакеты на различные сервисы, в результате чего сервер просто не справится с их обработкой. Для справки, число таких ботов может колебаться от пары сотен до нескольких десятков тысяч на одном канале. За более подробной информацией по DoS-атакам, обращайся к тематической статье в этом номере.
В случае успешно проведенной удаленной атаки, взломщик получит какие-нибудь системные привилегии. Именно этот исход можно считать удачным, поскольку за удаленной атакой всегда следует локальная. Настало время понижать добытые права до магического уида 0, перед которым преклонятся даже самые защищенные бинарники ;). Но получить рута очень сложно (особенно в защищенных системах), поэтому постоянно приходится включать соображаловку и быть впереди админа хотя бы на один шаг. Это очень непросто, но возможно.
Самый первый и легкий путь локального взлома – применение эксплоита. Правда, вместо предварительного сканирования портов придется найти бажный суидный бинарник либо дырочку в ядре, а только потом подыскивать нужный сплоит. Проблемы при использовании этой атаки могут быть самыми разными. Первая – отсутствие багов. Если система свежая, даже в случае существования рабочего эксплоита простому смертному его не достать. Бывает, что даже в убогих системах админы патчат ядро и нещадно сносят все уязвимые бинарники (либо снимают с них суид-бит). И, наконец, использовать эксплоит проблематично в отсутствие рабочего компилятора (об этой ситуации я расскажу чуть ниже).
Давай определимся, с каких шагов лучше всего начинать атаку. Как только получен нормальный шелл, нужно выполнить ряд команд, чтобы определить дальнейшую тактику взлома. Во-первых, следует набрать uname –a и узнать версию операционки. Если это Linux, можно вывести на печать файл /etc/*-release и посмотреть конечного производителя системы. В случае если взломщик наткнулся на новую FreeBAS, ему стоит забыть об эксплоитах. На фришные сервисы рабочих новинок не было очень давно. А какую-нибудь SunOS, наоборот, очень легко взломать, эксплоиты есть и для последних релизов.
К примеру, после вывода uname –a bash показал, что система вертится на ядре 2.4.20-smp. Это означает, что хакер поимел хорошую двухпроцессорную тачку. Только вот ядро у этой машины не такое уж и хорошее. Можно провести атаку эксплоитом isec-ptrace.c и быстро получить рутовые привилегии. Для этого даже не нужен псевдотерминал, который настоятельно требовали предыдущие эксплоиты ptrace-уязвимости. Что касается Solaris, то ее ядро пробивается с одного удара. Существует сплоит, позволяющий подгрузить модуль с произвольным кодом. Подгрузка, как ты уже догадался, производится от обычных юзерских прав, которые ты получил после успешной удаленной атаки.
В случае, когда встречается ядрышко постабильнее, например, 2.6.7 или 2.4.20, но с префиксом –grsecure, можно не питать надежду на то, что кернел возьмется обычным ptrace-эксплойтом. В такой ситуации хакер даже не тратит времени на поиски эксплоита, ибо знает, что патчи и свежие релизы уже не содержат старых багов.
Бывает, что на машине вертится секьюрное ядро, но также очень бажные бинарники. Например, я встречался с Linux RedHat 7.3 с патчем от grsecurity, но уязвимым приложением /usr/sbin/sudo. При таком раскладе я желал получить рута после применения эксплоита hudo.c, но обломался. Дело в том, что сервер, являлся хостингом, поэтому всем юзерам прикрывался доступ к /usr/bin/gcc. Я оценил защиту админа, затем скомпилил эксплоит на другом пингвине и перетащил бинарник на хостинговую машину. Оставалось запустить приложение и наслаждаться рутовыми правами.
Думаю, смысл ты уловил. Если на сервере есть уязвимые бинарники или старое ядро – ноги в руки и бегом на сайты по безопасности за свежими (или чуть протухшими) эксплоитами. На машине свежая система и напрочь отсутствуют суидные приложения? Тогда придется попробовать другой способ локального нападения.
Другой метод повышения привилегий заключается в поиске секретной информации. Нет, совсем необязательно отыскивать различные документы, нужно просто определить наличие в системе парольных хэшей. Часто пароли встречаются в файлах .htpasswd, они находятся в web-зоне. Поиск осуществляется командой locate .htpasswd. Бывает, что документ не только открыт на чтение, но и содержит в себе рутовый хэш, который, легко расшифровать с помощью John The Ripper. Помимо списка .htpasswd можно запросить конфиги .htaccess, а затем прочитать их. Бывает, что юзер сохраняет пароли в файле с произвольным именем. Последнее легко узнать по значению директивы UserFile в httpd.conf.
Конфиги от Web – это лишь верхушка айсберга. Настоящая сила находится в логах! Если поиск по Web ничего не дал, стоит попробовать поискать читабельные файлы .bash_history и.mysql_history. В первом из них можно обнаружить пароль для суперпользователя. Случается, что администратор написал неверную команду su (sy или si), а затем вслепую вбил рутовый пароль. Пароль, конечно же, сохранится в логе команд. Находка для хакера, не так ли? Кроме этого, возможен случай, при котором администратор логинится к MySQL, используя системный пароль. Таких случаев очень много, наверное, каждый третий локальный взлом происходит благодаря хорошему урожаю из лога команд :).
Теперь поговорим о MySQL. Доступ к базе – это тоже своего рода дополнительные права. Ведь в БД могут содержаться таблицы с кредитными картами, аккаунтами на какие-либо сервисы и т.п. Слюнки потекли? Еще бы :). Чтобы достать пароль от базы, особо париться не надо. В первую очередь нужно изучить PHP/CGI-скрипты на предмет конфигурационных файлов. Например, часто переменные доступа записываются в конфиг include.php.inc либо mysql.inc. Второй способ узнать пароль – прочитать .mysql_history. Очень часто администратор светит пассворд в чистом виде после выполнения команды «blabla set password=password(„пароль“)». Наконец, если не повезло, можно заняться локальным брутфорсом: залить на машину hydra и прогнать вордлист для сервиса mysql. Ведь, как известно, надежда умирает последней :).