Loo Опубликовано 8 мая, 2008 Поделиться Опубликовано 8 мая, 2008 Я тут чутка писал на тему примерно в 2006 году :о)) Ответ :о)) Да хотел поговорить о тенденциях, советов поспрашивать! Это не срочно, но если освободится время и я рядом буду - был бы рад обсудить! Просто дошел я как бы до некоего уровня. Похоже, что ну еще полгода из него чего-то выжимать получится, но дальше надо переходить к чему-то более продвинутому. Ну и хотел у тебя поинтересоваться, куда щас поперспективнее двигаться, у кого можно чему-то поучиться! Хз, алгоритмирую :о)) Главное всегда это инфраструктура, базис, стандарты и все такое прочее. Ну как можно написать как посмотреть листинг фтп, если он запрещен? Ну фтп-демонов штук 300. Ну RFCштук 12 которые относятся к фтп-протоколу. И еще и их никто не соблюдает. Давайте абстрагироваться :о)) Дано: Есть сервер Задача: Взломать. /Нормальные такие условия, да? Х с ним попробуем описать «крякер Тыртырнету» :о)) Первые наши действия: определить айпи, и попытаться определить сервиса. Что такое есть сервиса? Любая машина(компьютер) управляется операционной системой какойто. Пофигу какой, основная задача любой ОС всегда одна и таже. Обеспечивать работу данного компьютера, чтобы он мог исполнять реквесты пользователя. WWW-сайт исполняет запросы и отдает инфу по запросам пользователя, ОС обеспечивает работу демонов, которые предоставляют определенные сервиса. ДНС-сервер обеспечивает преобразование понятных человеку адресов типа www.comв ip-адреса. Соответственно обрабатывает запросы кучи серверов, хостов, сервисов которые при упрощении все таки опять оказываются запросами инициированными конкретным конечным пользователем. Поисковые сервера, allocation-сервера ресурсов(которые перенаправляют запросы пользователя на наиболее близкий к нему по времени отклика, наименее загруженный(чтобы с максимальной скоростью и комфортом обеспечить запрос пользователя) ЛЮБЫЕ сервисы при значительном упрощении выполняют одну и туже работу, исполняют запросы пользователя. В наиболее комфортном (из возможных, из необходимо эффективных и т.п.) виде. Все упирается в конечного пользователя. Пускай все максимально секьюрно, и все разработчики которые работали в процессе создания ПО для обеспечения запросов Дуни Барановой из МалыхФигнюков работали в подвале с 1.5 метровыми стенами и свинцовые трусы носили все время работы! Дуня будет юзать стандартное ПО. Что значит стандартное? Да забудьте вы Винды, Никсы и т.п. Стандартное значит стандартизованное, сделанное по RFC, внутренним стандартам и т.д. и т.п. Пох что Дуня классный спец по *BSDветке и находу могет писать скрипты километровые. Была такая старая реклама в спец-журналах, сидели за столом благообразная убеленная сединами пара лет под 60, и панк отвязнный, с пирсингами, кольцами в ушах, ирокезом и типа остальной амуниции. Называлось примерно ”IftheyTCP/IPcompatible, wecanunderstandhim” Хз, не помню точно, но смысл такой. Было такое! TCP/IPне всегда был стандартом :о)) Чтобы понимать друг друга, мы должны знать язык понятный нам обоим. В той или иной степени стандартизованный. «Превед» все равно понятен всем, не взирая на то, что смысл вкладывается несколько иной, основное значение сохраняется. Так что, основой для нашей атаки на Тыртырнет будут стандарты. 1) Ищем сервиса. Возьмите сканер. Не надо лезть к своему убогому Акцесс-Дайверу. Нам нужен Сканер. Любой сканер, который попытается по запросу к сетевому порту хоста определить наличие на нем сервиса. По базе ли стандартных портов (на 80-порту слушает WWW-сервер, если на 80 порту откликается какойто сервис, логично предположить что это WWW), по TTLопределяет примерную ОС хоста, по сигнатурам, по баннерам и хз еще по каким параметрам. Лучший какой? Лучший сканер это ваши руки, поконнектитесь на каждый порт и посмотрите ответ. Гыыы :о)) Ладно-ладно, научитесь в конце концов пользоваться nmap-ом :о)) В большинстве случаев достаточно. Да! Там может висеть ченить противодействующее nmap’у, у Хыра вон спросите USTтоже что-то такое писали. Да много всего может быть. В 90% случаев не будет ничего против nmap. Сделайте whois. Отвечаю на вопрос «Как?»: как угодно! Сетевыми сервисами воспользуйтесь, софтом, трейсертами всякими. Чем больше вы получите инфы из разных источников, разными способами, тем лучше. Вполне может быть что перед хостом стоит cisco, которая прокидывает транспарентно запросы к определенному ip на определенный порт в какую-нить DMZ-зону, а сама маскируется под linux, freebsdили фиг знает что еще. Вы сканите хост в святой уверенности что это FreeBSD 5.4, а это циска Фроста (которая ваще не циска, а целерон с флешкой, на котором стоит FreeBSD, и которая маскируется под Циско-Иос) Что нам надо от whois. Нам надо посмотреть, какие хосты стоят перед целью на вашем запросе, верно ли то что целевой хост отдельная машина, или это виртуальный сервер, может быть мы не проходим дальше сетевого интерфейса граничного роутера, к которому примапплен сетевой интерфейс сервака находящегося в ДМЗ (или вообще внутри сетки!!! Sic!!!) Если мы видим что диапазон адресов в котором находится целевой хост, принадлежит компании с деятельностью (читай обеспечением сервисов предоставляемых компанией) совпадающей с целевой машиной, значит что еще есть сервера, компы, хосты которые также участвуют в процессе обеспечения сервисов пользователю этой компании, то все адреса этого диапазона представляют для нас интерес самый непосредственный. Это могут быть NSсервера (NameServer), которые мы можем использовать для атаки типа спуффа, это могут быть DNSсервера, которые можно использовать для создания бекдор-канала для спокойно-тихого выливания из внутренней сети (ну не то чтобы внутренней даже, а просто protected, internal-accepted, private-non-NATedи т.д.) информации, это могут быть MX (MaileXchange) сервера (заголовки серверов, методы HELLO-handshaking, логи и методы graylistingдемонов почтовых серверов и много всего прочего. Да-да! Антиспам системы раскрывают кучу инфы, перебор почтовых адресов отсеивающихся грейлистинг-демонами приводит к однозначному определению валидного мыл-адреса, дальше начинается атака на существующий мейл-адрес, попытки отсыла Троянов и тому подобного), это могут быть RADIUS-сервера (сервера аутентификации), это могут быть сервера VPN-доступа (VirtualPrivateNetwork) акцесс к которым разрешен отовсюду, которые зачастую используют не самые сильные методы шифрования и handshaking, да много всего! Мы аккумулируем эту информацию. 2)Хантинг Нам нужна информация. Любая. Вся. Мы будем заниматься аналитической работой. НЕ СИ! (Социальной Инженерией) Мы будем искать в Интернете все упоминания мыльных адресов с обратным хвостом целевого хоста. Форумы одноклассников, «Клуба любителей карманного бильярда» мыло, логи веб-серверов, кто что когда искал, какое количество запросов, данные об UPTIME-времени хоста, записи на веб-сайте компании когда она была создана, когда было зарегистрировано доменное имя, на какой адрес почтовый, на какой телефон, на чье имя. Резюме на сайтах по поиску работы, в котором упоминается целевая компания, архивы СМИ с новостями о компании, имена и фамилии работников дававших интервью. Логии IRCс nicknameсовпадающими с фигурантами целевого хоста. Блоги и ЖЖ, с Никами и айпи-адресами, с упоминанием компании. Естественно, что на определенном уровне мы просто физически не сможем вручную насиловать гугль, у нас будут скрипты, софт спецовый занимающийся этим. Попробуем выяснит физический адрес компании, в чьем владении находится целевой хост. Выясним кто предоставляет им услуги. Связь, cleaning-сервис, питание, поставку воды, провайдера связи. Выясним кто обеспечивает физическую охрану объекта (Грубо говоря, какая контора нанимает гоблинов для того чтобы стояли на входе в офис и третировали младший персонал проверкой пропусков, чем не вариант написать письмо от охранной конторы с уведомлением о том что МЫ(офигенно_крутая_контора_ЧОП) уволили за воровство и шпионскую деятельность кого-то, и просим связаться с нами по такому-то мылу на предмет возможных претензий ака в ответ получить «Пропал карандаш две недели назад со стола! Ийоптьтет вы там все поперенеблевали!», ответ на это письмо с приложением «видеозаписи» изьятия карандаша обязательно откроют! Он будет с RE:REтемой и ОЧЕНЬ ожидаем фигурантом) Ладно это все лирика. В итоге мы получим достаточную картину СЕРВИСОВ «Зарегистрируйтесь у нас на сайте чтобы получить условия дилерского соглашения!» Значит что то продают, а значит обеспечивают поддержку, сервисные услуги, апдейты, news-рассылки … СЕРВИСА! «Свяжитесь с нами, и мы вышлем вам подробную презентацию(список услуг, прайс)» А значит стоит попробовать пощупать присланное на предмет наличия например метаданных документов MSOfficeв которых может оказаться например логин пользователя. В теле письма могу содержаться данные почтового сервера (Имя демона, версия, используемые модули) ВСЕ это помогает определить что же все таки нам противостоит, естественно что варианты это все, причем использующиеся в особо тяжких случаях. Баловаться этим чтобы просто так куда то попасть, можно только из желания потренироваться или от переизбытка времени. Хотя темы созданные системным администратором на специализированных форумах ОЧЕНЬ точно могут предоставить информацию об уязвимостях, существующих сервисах в сети и качеству знаний администратора в той или иной области. Анализ веб-сайта как по содержимой информации( «Осуществляем услуги по внедрению корпоративных систем на ORACLE” и статья ”Генераторы отчетов» в которой рассматривается Win2kпример с точностью 90% скажет что сайт на Оракл Портале, а система Вин2к. Джава-аплеты на сайте только потвердят. Итак мы определились с предоставляемыми хостом сервисами. Мы проверили, выяснили и ПЕРЕПРОВЕРИЛИ версии, имена демонов, желательно также проверить права из под которых запущены демоны и сервиса. Копаем инет на предмет наличия паблик-сплоитов (естественно паблик, те кто ченить приватное могут достать это не читали, им нах не надо) Нету? Во как, ну бывает :о)) Довольно часто :о)) Практически всегда, либо просто PoC-сплоиты, либо требования другие, либо пропатченно, да вообще ПРОСТО не работает! Обязательно разберитесь в КАКИХ условиях БУДЕТ работать. Очень важно знать, ЧЕГО именно на целевом хосте нету. Ну тривиальный пример magic_quotes=off :o)) Ну ты понял да, о чем я ? :о)) Это я тому человеку уважаемому, которого в начале процитировал :о)) Окей, мы ищем подобные версии, и моделируем сервер такой же (исходя из примерного состава ПО, который мы уже знаем, ну да примерного, что делать-то теперь! Естественно что надо попытаться слить все конфиги, скрипты и т.п. Все что сможем, как это делать даже я пару раз писал. Триальная версия только доступна? Ограниченная по функционалу? Ничего страшного, нам надолго не надо, мы же на виртуалке типа vmware. Нет предоставленного на целевом хосте функционала? Ну че делать, смотрим то что есть, не найдем значит мы будем трапать тот функционал, который нам не доступен. Ну а для начала поанализируем, посэксплуатируем то что есть) Ничего не получается …. Ыыыыыы! Ща плакать буду! Стал мля практически сис-админом, времени потратил хз скоко, а толку ноль. Че делать? ДА валом работы еще! «Не спать негры!» -(с) :о)) а) Если время позволяет, то читаем TODOлисты производителей софта, читаем то что было поправлено в предыдущих версиях и чем черевато обновление на новую версию. Производители очень часто пишут что нужно сделать чтобы обновиться, смотрим внимательно на соответствие, на НЕСООТВетствия особенно! FIXEDчитаем обязательно. Не забываем пытаться атаковать внутреннюю сетку, мыльные адреса, постоянно проверяем и монторим состояния сервисов. Чисто ждееееееем :ог)) б) Времени нет. Хотя этот вариант приемлем и в предыдущем случае. Расписываем сервиса по используемым протоколам, стандартам, соглашениям, смотрим сторонние взаимодействующие сервиса. Ищем где и за что можно попробовать зацепиться. Самые страшные ошибки это не ошибки в реализации (нефильтруються параметры в скриптах и т.п. хрень), самые страшные ошибки проектирования. Смотрим кто и когда организовывал атаки сетевых протоколов, как это делалось, какой демон используется в качестве фтп (и как в нем реализованы RFC, что говорят разработчики по поводу своих секьюрити extensions), как реализован ssh(откель можно, как вообще админ туда приходит-то? Все равно ведь приходит). Что используется в качестве IDS, какие правила для IDSв стандарте идут. Чего используется ISP-ом? Какие желязяки роутеры, днс-сервера, NNTP-сервера, «соседние» хосты на чем стоят. Может быть реально повесить просто сниффер на интерфейс на котором доступен трафик целевого хоста?Может фигарнт не использует ssl-почту, гыыы валом таких явлений. Может быть можно вызвать отказ в обслуживании у ISP’а и под шумок, под восстановление сервисов успеть таки спереть PSK для IPsec-туннеля или еще какую-нить критичную инфу передаваемую по открытым каналам в этот момент (Некогда сисадминам! Все лежит, все пропало!) Часто админы с ленцой относятся к возможности перехвата траффа, когда все идет по IPSecканалам между хостами, ну так выполни отказ в обслуживании! НАИБОЛЕЕ часто доступны для понимания и реализуемы эксплоиты такие. Найди слабую точку, и порушь всю цепь. Доступ неограничен с подсетей, шанс светит успеть все сделать! Помнишь про бэкап-оператора? Когда раз в квартал производится бекап. Который делает не самый квалифицированный персонал. По сути бесправный, совсем зарестрикченный. Обязанности запустить последовательно несколько скриптов и убрать двд в хранилище, слив еще на один quick-backup инкрементальный. Естественно, что обычно все проще. За неделю уработать сервер серьезный только в американских кино показывают что необходимо (или там меньше еще времени? :о)) Обычно ты просто время от времени проверяешь. Упс, во какая бага тут возникла, а ведь чтото похожее было там где я искал. А нука! Все случаи «там на серваке был поднят фтп-сервер, к которму совсем недавно вышел сплоит от Real_Cool_Hatsk_Team Я его чутка переписал, так как там скрипт-кидди защит убогая была, но он все равно не дал мне коннектбек-шелла, пришлось покапаться в конфигах CheckPoint и примерно прикинуть чего у них может быть, а там был доступ с адреса из Владивостока с подсети динамической. Разница во времени была серьезная и я сумел проспуффить ip в тот период когда их Владивостокский филиал спал. Дальше все было просто, с принт-сервера постоянно включенного я попал к контроллеру домена и ДНС-серверу на 8-ом бинде, успешно зашелив который я получил возможность отдавать инкапсулированные в днс-трафф команды, так как днс прова ихнего был настроен не то что плохо, а скажем так «не тонко» относятся уже к уровню когда, ты все и так прекрасно знаешь. А случаи «Применив сплоит от такой-то Тим я получил шелл ..» не рассматриваются, ибо это самый начальный уровень скрипт-кидди :о)) Так что «Возможностей впору вчетвером нести, но каждый коренаст и голенаст :о))» И знаний которые можно получить и использовать еще ОООЧЕНЬ много. Причем это все гораздо милее и безопаснее биллингов :о)) И удовлетворения приносит гораздо больше чем ковыряния с скриптами :о)) P.S. Когда-нить я буду с гордостью говорить своим внукам, что показывал горизонты великому спецу :о)) Ссылка на комментарий Поделиться на другие сайты More sharing options...
Игорь Нежданов Опубликовано 30 мая, 2008 Автор Поделиться Опубликовано 30 мая, 2008 Продолжение Тактическая эксплуатация, часть вторая, Эксплуатация информации 4.1 Введение Последняя глава посвящена методам получения информации. В качестве основы этих методов в данной главе рассматривается злоупотребление документированными особенностями для компрометации целевой системы. 4.2 Внешние сети Внешняя сеть – отправная точка для большинства тестов на проникновение. На внешних хостах часто применяются ограничения функциональности, межсетевые экраны, фильтрование, установка последних исправлений. Единственно доступные целевые объекты – это намеренно открытые приложения, VPN-сервисы и временные пути для запускаемых клиентами UPD-сессий. 4.2.1 Атака передачи файлов Передача файлов между внутренними и внешними хостами может стать объектом атаки в зависимости от протокола и используемого межсетевого экрана. Атака передачи по FTP Протокол FTP использует временные порты для передачи данных, вводя открытый порт передачи данных либо на клиенте, либо на сервере, в состояние гонки. В зависимости от FTP-приложений может существовать возможность соединения с портом данных и получения содержимого загруженного файла или записи содержимого выгруженного файла. Сценарий pasvagg.pl[13] может использоваться для перехвата передачи по FTP при предоставлении сервером анонимного доступа, последовательном расположении портов и при условии, что FTP-сервер разрешает соединения с портами данных с IP-адресов, отличных от адреса клиента, запустившего передачу. Любой FTP-сервер, поддерживающий режим ”FXP, является уязвимым для этой атаки. Атака передачи по NFS Протокол NFS включает ряд независимых сервисов удаленного вызова процедур (RPC-сервисов), каждый из которых может подвергнуться вмешательству при использовании NAT-шлюза. Сервисы NFS примут отклик от любого исходного IP и порта, содержащего достоверные данные, даже если хост не имеет никакого отношения к адресу, который был указан в параметрах соединения NFS. Поводом для этого служит поддержка NFS-серверов, присоединенных к нескольким физическим линиям данных, в которых отклики RPC приходят с IP, отличного от того адреса, с которым клиент вступал в соединение. Для обеспечения NFS-трафика через NAT, старые версии ядра Linux и многие современные NAT-устройства позволят отправку UPD-откликов клиенту с других IP-адресов. В действительности, это делает клиентские RCP-сервисы видимыми Интернету при установке клиентом соединения через NAT-устройство. Основная трудность с точки зрения аудитора заключается в том, чтобы найти временный порт, используемый для ретрансляции соединения, и затем определить, какому RCP-сервису он принадлежит. 4.2.2 Атака почтовых сервисов Типичная почтовая система состоит из одной или более систем ретрансляции, фильтра против вирусов и спама, реального почтового сервера и, в конечном счете, почтового клиента пользователя. В большинстве тестов на проникновение основное внимание уделяется промежуточным системам, однако сами почтовые клиенты тоже могут быть намечены в качестве целевого объекта. Например, в Mac OS X, если получены два email-сообщения, содержащие вложенные файлы с одинаковым названием, более новое сообщение может осуществить перезапись вложенного файла предыдущего сообщения, если степень совпадения полей высока. Это может применяться для замены безвредного вложенного файла лазейкой в почтовом ящике пользователя. 4.2.3 Атака web-серверов Хотя web-серверы являются самыми заметными целями для внешней сети, многие специалисты по тестированию на проникновение пропускают очевидные уязвимости. Прямой подбор имен общего файла или каталога может поставить под угрозу интерфейс администратора, резервные копии, архивы всего сайта и т.д. Отправка имен внутреннего хоста в заголовке HTTP Host может привести к доступности внутренних сайтов и областей, предназначенных только для сотрудников. В наше время почти на всех web-серверах установлены приложения, а любое неизвестное приложение должно приобретаться у производителя и проверяться на наличие уязвимостей. И наконец, в некоторых системах балансировки нагрузки имеются проблемы с долговременными HTTP-сессиями, поэтому они могут допускать утечку информации от других пользователей. 4.2.4 Атака DNS-серверов В течение последних 10 лет многие DNS-серверы настраивались на отказ передачи зоны с неавторизованных хостов. Вместо извлечения зоны целиком, аудитор должен осуществить подбор возможных имен доменов и хостов для определения наличия таких записей. Многие DNS-серверы ошибочно настроены на разрешение поиска внутренних DNS-адресов, что может привести к разглашению имен и адресов важных серверов внутренней сети. Как ранее отмечалось в пункте об исходящих DNS, многие DNS-серверы все еще уязвимы из-за предсказуемой последовательности ID-транзакций или состояний гонок, таких как, например, вызванных Birthday-атакой[10]. Успешная атака может привести к внедрению фальшивых DNS-записей в кэш и, возможно, к захвату внутреннего и внешнего доменов в зависимости от конфигурации сети. 4.2.5 Атака сервера баз данных Хотя серверы баз данных редко делают видимыми для внешней сети, быстрое сканирование общих сервисов баз данных в любом случае не помешает. Многие бизнес-приложения (Saleslogix и т.п.) используют двухзвенную архитектуру, из-за чего для функционирования приложений необходим прямой доступ к серверу баз данных. Имейте в виду, что некоторые серверы баз данных, например, Informix, все еще содержат известные уязвимости, для которых до сих пор не выпущено исправление. 4.2.6 Ретрансляторы аутентификации Одна из самых эффективных атак на внутренних пользователей из внешней сети опирается на ретрансляторы аутентификации. Многие организации делают серверы Microsoft IIS или Exchange видимыми Интернету. Эти серверы разрешают аутентификацию доменов Windows с использованием протокола NTLM. Если межсетевой экран жертвы не настроен на отклонение соединений через порт 139 и 445, то имеется возможность отправить пользователю email-сообщение или перенаправить его на web-страницу, которая заставит рабочую станцию установить SMB-соединение с тем хостом, который вы выберите. На этом этапе, фактическое воздействие зависит от версии Windows, установленной на рабочей станции, и, в некоторых случаях, от того, какой web-браузер или почтовый клиент используется. В Windows 2000 и более ранних системах браузер будет автоматически проводить NTLM-аутентификацию с удаленным SMB-сервером, используя текущее имя пользователя и пользовательский пароль. Если аудитор предоставит вредоносный SMB-сервер, который ретранслирует эту аутентификацию на доступный извне IIS-сервер или Exchange, то он может получить прямой доступ к данной учетной записи пользователя. В Windows XP и более новых системах применение этого метода не всегда возможно из внешней сети. Учетные данные NTLM, используемые SMB, HTTP, SMTP, POP3 и IMAP4, обычно равнозначны, при условии, что Вы обладаете инструментарием для выполнения ретрансляции. Альтернативой ретрансляции учетных данных является перехват и взлом самого хэша пароля. Для этой цели существует ряд инструментов, включая почтенный L0phtcrack (на данный момент уже недоступный) и Cain and Abel[11]. Более подробные сведения по процессу перехвата можно найти в статье Варлорда (Warlord) в Uninformed Journal[14]. 4.2.7 «Бесплатное железо» Последняя надежда. Аудитор перемещается по офису целевого объекта и раздает бесплатные USB-ключи (с автозапуском, конечно же) любому, кто согласится ответить на несколько вопросов для социологического опроса. Или же он может отправить по обычной почте компакт-диск с трояном, упакованным в автоматически запускающийся файл или в инсталлятор (и прощай разделение привилегий на Vista). Возможны такие надписи на CD, как ”Бесплатные MP3”, ”Бесплатное лицензионное соглашение” и т.д. Если же бюджет позволяет, может отправить по почте портативное устройство, например, Nokia Internet Tablet или Zaurus фирмы Sharp, содержащее полный набор лазеек на базе Linux. Или же аудитор может создать обычный блок бесперебойного питания, содержащий встроенный ПК. Аудитор приобретает батарею резервного электропитания (350 В-А или выше) с защитой от перегрузок для Ethernet-портов, вскрывает батарею, подсоединяет разветвитель питания к основному адаптеру питания, вставляет внутрь WRT54L фирмы Linksys, вставляет Ethernet-коммутатор с четырьмя портами и готовится к визиту в офис целевого объекта. Проникнув в целевой офис, аудитор может выдумать предлог, чтобы подобраться поближе к сетевым устройствам (принтерам, факсам и т. д.) и установить вредоносный блок бесперебойного питания. Пример этого способа можно найти по ссылке [12]. 4.3 Внутренние сети Термин «внутренняя сеть» обычно относится к критически важным и конфиденциальным данным большинства корпоративных сетей, но его можно также применить по отношению к сети, предоставленной определенной жертве через ложную точку доступа. Если доступ к внутренней сети получен, появляется возможность использования широкого диапазона новых атак. 4.3.1 Имена NetBIOS Протокол NetBIOS используется рядом приложений для определения важных хостов в сети. Некоторые имена NetBIOS рассматриваются как частные случаи. Например, NetBIOS-имя ”WPAD” будет автоматически использоваться как HTTP proxy-сервер, если оно разрешается сервером DNS. Имя ”ISASRV” является частным случаем для клиентов, ищущих ISA Server Proxy. Сторонние приложения имеют аналогичные настройки. Computer Associates Licensing Client будет искать локальный хост с именем CALICENSE для отправки ему запросов на авторизацию. 4.3.2 DNS-cерверы Серверы DNS во внутренней сети часто настроены на разрешение обновлений без аутентификации. Даже когда Microsoft DNS- сервер настроен на отклонение запросов обновлений на базе DNS, все же возможно внедрить имена в локальную зону DNS, передав эти имена как имя хоста запросов DHCP-клиента (опция -h ISC dhcpcd-клиента). Эти типы DNS-атак могут позволить внутреннему злоумышленнику захватить полный доступ к критической системе, подменить серверы и осуществить новые атаки на пораженных клиентов. 4.3.3 WINS-cерверы В дополнение к NetBIOS и DNS клиенты Windows также поддерживают разрешение имени с использованием протокола WINS. Как правило, DHCP-сервер отвечает за оповещение каждого клиента о том, какому серверу следует отправлять запросы WINS. Однако, используя захват DNS и оповещений NetBIOS, можно заставить клиента использовать вредоносный WINS-сервер вместо предписанного. 4.3.4 Ретрансляторы аутентификации В разделе о внешних сетях мы рассматривали атаки ретрансляции на SMB и другие сервисы, связанные с NTLM. Из внешней сети такая атака отчасти ограничена, поскольку Windows XP и более новые системы не проводят NTLM-аутентификацию автоматически. Во внутренней сети эта атака может нанести невероятный ущерб при совместном применении с одной из описанных выше атак DNS, WINS или NetBIOS. Если аудитор сможет осуществить подмену имени доверенного сервера, то можно осуществить атаку ретрансляции для обратного соединения с клиентской системой с использованием SMB, и, если у пользователя есть права администратора, полностью захватить управление системой, используя функции файловой системы и сервисов. 4.4 Доверительные отношения Доверительные отношения – одна из самых важных вещей для понимания и применения тестирования на проникновение. Доверительные отношения могут строиться по многим принципам, например, доверительные отношения: 1. между хостом и хостом; 2. между сетевым диапазоном и хостом; 3. между пользователем и хостом; 4. между пользователем и сетью; 5. между билетами/маркерами аутентификации; 6. между приложениями. Доверительные отношения основываются на соглашениях между двумя объектами, которые учитывают какую-либо степень прав на доступ. Если аудитор имеет доступ к одному объекту, то он должен использовать доверительные отношения с другим объектом себе на пользу. Часто бывает так, что целевая система, которую аудитор хочет атаковать, недоступна по различным причинам, например, из-за межсетевого экрана, TCP-туннелей, NAT-устройств и т.д. Использование доверительных отношений в своих целях может стать отличным способом преодоления подобных препятствий. Например, пусть целевым объектом является 192.168.0.1, и аудитор получил какими-либо способами имя пользователя и пароль. В целевой системе для удаленной регистрации используется SSH по порту 22. Однако целевая система также оснащена TCP-туннелями, которые разрешают SSH-соединения только в диапазоне адресов 192.168.1. Аудитор не сможет напрямую зайти в целевую систему при данных условиях. Однако если аудитору удалось скомпрометировать систему в сети 192.168.1, тогда, используя эти доверительные отношения в своих целях, он сможет зайти в систему по SSH, используя данную сеть, или же с помощью переадресации портов, например: # Создание порта от 192.168.1.2 к 192.168.0.1 $ datapipe 192.168.1.2 22 192.168.0.1 22 # (Это позволяет перейти через порт к 192.168.0.1 порт 22) $ ssh 192.168.1.2 Один пример из реальной жизни с интересным использования доверительных отношений, с которым авторам довелось столкнуться, был связан с пользовательским приложением лицензирования и распространения ПО. Было необходимо, чтобы на всех компьютерах целевой сети было установлено определенное ПО и чтобы оно запускалось под учетной записью администратора. Это означает, что между абсолютно любым компьютером и данным приложением существовали доверительные отношения. В этом приложении было имя пользователя и пароль учетной записи администратора внутри программного кода для выполнения операций. С помощью обратного инженерного анализа этого приложения были получены учетные данные пользователя. Далее аудиторы использовали тот факт, что данная учетная запись находилась в доверительных отношениях с большим числом пользователей, для компрометации каждого хоста в сети. Каждый ресурс, находящийся в доверительных отношениях с более чем одним пользователем или компьютером, является потенциальным средством достижения целей для аудитора. Существует несколько особых технологий построения доверительных отношений, которые часто дают аудитору возможность получить доступ ко многим хостам. Об этом пойдет речь в следующих разделах. 4.4.1 Домашние каталоги NFS Во многих крупных сетях используется сервер протокола NFS (протокола сетевого доступа к файловым системам) для предоставления общего доступа файлов и домашних каталогов клиентам. Существует множество способов настройки этой системы, но обычно порт 2049 UDP или TCP на сервере делают открытым, каталог делают видимым либо всем, либо конкретным хостам и назначают права на чтение, запись и выполнение. Далее клиенты устанавливают эти экспортированные каталоги, которые кажутся такими же, как и все локальные каталоги в их файловых системах. Часто NFS используется совместно с Network Information Services (NIS) для автоматического задания параметров того, какие экспортированные каталоги следует установить, и для аутентификации пользователей. Такие типы систем часто настроены так, что любой пользователь может регистрироваться на любой машине и получать один и тот же домашний каталог. Злоумышленник может разработать сканер порта 2049 для того, чтобы определить местоположение любых NFS-серверов в целевой сети. Аудитор может использовать инструмент под названием «showmount» для получения данных о конфигурации NFS-сервера. # su - alice [alice@homeserver ~] cd .ssh [alice@homeserver .ssh] ssh-keygen -t rsa Enter file in which to save the key (/home/alice/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/alice/.ssh/id_rsa. Your public key has been saved in /home/alice/.ssh/id_rsa.pub. The key fingerprint is: e7:49:6a:eb:a9:a6:e4:b2:66:41:7e:ee:23:12:4c:28 alice@homeserver [alice@homeserver ~]cp id_rsa.pub authorized_keys ; showmount -a homeserver tetris:/vol/home/alice [alice@homeserver ~] ssh tetris Last login: Thu Jun 28 11:53:18 2007 from homeserver [alice@tetrix ~] 4.4.2 Захват SSH SSH может также использоваться для получения сведений о других потенциальных целевых системах в сети. Каждый раз, когда пользователь соединяется с системой по SSH, в /.ssh/ создается файл под названием «known_hosts». Изучив этот файл, злоумышленник может узнать хосты, находящиеся в доверительных отношениях с этим пользователем. [alice@homeserver .ssh]$ cat known_hosts dontownme,192.168.1.20 ssh-rsa AAABB3Nza[...]QSM=justanothertarget,192.168.1.21 ssh-rsa AAAB2NzaC[...]rQ= С помощью SSH-ключей, описанных выше, злоумышленник, имеющий доступ к этим ключам, может потенциально зарегистрироваться на любом из этих хостов, например, на alice, без пароля. Привилегированный режим SSH – еще одна функция, которая может помочь аудитору вторгнуться на новые хосты без использования эксплойтов. Привилегированный режим позволяет пользователю установить коридор, позволяющий открывать большое число сессий с использованием одного и того же SSH-соединения без повторной аутентификации. Это значит, что если с хостом установлено одно SSH-соединение в привилегированном режиме, тогда злоумышленник может открывать другие сессии, используя одно и то же соединение, при этом ему необязательно знать пароль или иметь доступ к ключу. Другой плюс привилегированного режима в том, что он зависит от клиента, т.е. версия сервера не имеет значения. Последствия этого состоят в том, что если вам удастся заменить пользовательский ssh-клиент, то привилегированный режим все равно будет работать, невзирая на версию сервера на другом конце соединения. Существуют различные способы заставить пользователя установить соединение по SSH в привилегированном режиме. Один из очевидных способов – соединиться с помощью псевдонима SSH с SSH -M так, что он будет запущен без ведома пользователя. Другой метод состоит в том, чтобы изменить пользовательский конфигурационный файл SSH таким образом, чтобы он всегда работал в привилегированном режиме. Edit ~/.ssh/config Add: Host * ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h:%p Mkdir ~/.ssh/sockets Теперь, когда пользователь установит соединение по SSH с другим хостом, это будет происходить как будто бы с использованием опции -M. Если вам удастся стать пользователем, то вы сможете установить соединение по SSH и к хосту тоже без аутентификации в рамках текущего соединения. Реальный пример использования захвата SSH для получения доступа к большому числу хостов имел место, когда авторам удалось скомпрометировать главный сервер домашнего каталога, с которого каталоги по NFS экспортировались сотням клиентов. Авторы оставляли их собственные ssh-ключи, не содержащие паролей, в каждом домашнем каталоге ssh/ пользователя, а затем использовали сценарий для извлечения всех уникальных хостов из каждого файла known-hosts. Затем они могли установить соединение по SSH с сотнями узлов в сети под любым пользователем по выбору. 4.4.3 Захват Kerberos Kerberos – протокол аутентификации. Он предоставляет надежную аутентификацию клиентским и серверным приложениям с помощью шифрования с использованием секретного ключа. Kerberos генерирует «билеты» для использования их с различными сервисами. Во многих операционных системах этот «билет» хранится в качестве файла у определенного пользователя в каталоге /tmp, имя которого начинается с krb. Захват Kerberos – это процесс захвата пользовательского «билета» и использования его для доступа к ресурсам, находящимся в пределах доверительных отношений с этим пользователем. В сущности, под этим подразумевается регистрация на других компьютерах, принимающих «билет» Kerberos этого пользователя. При данной атаке происходит злоупотребление тем фактом, что каждый узел находится в доверительных отношениях с системой. Это позволяет злоумышленнику перемещаться по сети, компрометировать хосты без применения эксплойтов или отключения оповещений, поскольку, в общем, это будет выглядеть как допустимое поведение пользователя. Основная процедура захвата «билетов» Kerberos начинается с получения доступа к корневому каталогу системы с большим количеством пользователей, на которой применяется Kerberos. Далее следует поиск пользователя, которого можно наметить в качестве целевого объекта, и списка всех файлов в /tmp. После этого злоумышленник заходит под учетной записью пользователя, используя команду su, и запускает klist, чтобы просчитать, какое предполагается имя файла «билета». Затем «билет» копируется из /tmp. В заключение kinit снова запускается для проверки статуса «билета». Теперь у злоумышленника появляется возможность зарегистрироваться в любой системе, на которой применяется Kerberos и которая находится в доверительных отношениях с захваченным пользователем, без необходимости предоставления пароля. Ниже следует пример. Что видит обычный пользователь при запуске klist: target|alice|1> klist Default principal: alice@target Valid starting Expires Service principal 06/28/07 11:03:25 06/28/07 21:03:25 krbtgt/target@target renew until 07/05/07 11:03:25 Kerberos 4 ticket cache: /tmp/tkt5116 klist: You have no tickets cached Это означает, что для пользователя alice назначен «билет», позволяющий ему устанавливать соединение с любой системой, на которой применяется Kerberos, без ввода пароля до указанной даты истечения срока действия. Что делает злоумышленник: bash-3.00# ls -al /tmp/krb* -rw ----- 1 alice eng 383 Jun 28 08:19 /tmp/krb5cc_10595_ZH8kq4 <---- FREE ACCESS! Bash-3.00# klist Ticket cache: FILE:/tmp/krb5cc_6425 <---- expected filename Default principal: valsmith@target Valid starting Expires Service principal 06/28/07 12:14:50 06/28/07 22:14:50 krbtgt/target@target renew until 07/05/07 12:14:39 Change the file to the expected name and check status:bash-3.00# cp /tmp/krb5cc_10595_ZH8kq4 /tmp/krb5cc_6425 bash-3.00# klist Ticket cache: FILE:/tmp/krb5cc_6425 Default principal: alice@target <--- we are now her! Valid starting Expires Service principal 06/28/07 08:19:42 06/28/07 18:19:42 krbtgt/target@target renew until 07/05/07 08:19:42 Кроме того, существуют также и другие типы атак на Kerberos. Еще один способ состоит в том, что злоумышленник генерирует или завладевает действительным «билетом». Затем злоумышленник помещает свое имя пользователя в файл klogin другого пользователя. После этого у злоумышленника появляется возможность устанавливать соединение с любой системой, с которой пользователь находится в доверительных отношениях. Kerberos примет «билет» злоумышленника и будет рассматривать его в качестве целевого объекта. Также важно скопировать файлы «билетов» в надежное место, так что если пользователь запустит kdestroy, «билет» не будет утрачен. С помощью Kerberos можно также получить некоторые конфиденциальные данные. Часто в корне домашнего каталога пользователя имеется .klogin, показывающий, какой пользователь авторизован на соединение с использованием команды su с корневым каталогом по протоколу kerberos. Так злоумышленник получает перечень пользователей с широкими полномочиями в качестве целевого объекта для следующих атак, конечная цель которых - получение доступа к корневому каталогу без необходимости применения эксплойта в его обычном понимании. Процесс кражи «билета» Kerberos можно автоматизировать и применить в нем сценарий, чтобы в результате получить сотни или даже тысячи пользовательских «билетов» в зависимости от размера сети. 1. Конкретный пример захвата Kerberos был связан с тем, что на целевом объекте использовалась малораспространенная операционная система и архитектура. Аудиторам не были доступны какие-либо известные эксплойты против целевого объекта. Сервер также был защищен TCP-туннелями от неавторизованной регистрации. Тем не менее, целевая система находилась в доверительных отношениях с несколькими крупными серверами домашних каталогов, на которых были запущены NFS, NIS, SSH и Kerberos. Аудиторы получили доступ к одному из этих серверов домашних каталогов и стали просматривать пользовательские файлы known_hosts, чтобы найти пользователя, в истории которого имелись записи о регистрации в целевой системе. Когда удалось обнаружить такого пользователя, «билет» Kerberos был похищен, и аудиторы зарегистрировались в целевой системе с сервера домашнего каталога. Это дало возможность аудитору обойти туннели и не быть замеченным в качестве подозрительного пользователя. Зарегистрировавшись, он приобрел возможность просмотреть файл для корневого каталога .klogin и получить перечень привилегированных пользователей, чтобы наметить их в качестве целевого объекта. Эти пользователи относились к этому же серверу домашнего каталога, поэтому их «билеты» также были захвачены. После этого аудиторы получили возможность зарегистрироваться в целевой системе и ввести ksu, таким образом, получая доступ к корневому каталогу. Глава 5 Заключение Методы, описанные в данной статье, наглядно показывают, как даже сеть с полным комплектом существующих исправлений может быть скомпрометирована решительным злоумышленником. Профессиональные специалисты по тестированию систем безопасности пользуются широким спектром методов атаки, которые редко попадают в контрольные листы, если вообще попадают. Самым лучшим средством атаки и по сей день остается человеческий мозг _ttp://www.securitylab.ru/analytics/353772.php Ссылка на комментарий Поделиться на другие сайты More sharing options...
Рекомендуемые сообщения
Заархивировано
Эта тема находится в архиве и закрыта для дальнейших ответов.