Содержание статьи
Задача
Найти админа домена в Windows-сети
Решение
Типичной целью пентеста внутри корпоративной сети (чаще всего построенной на ActiveDirectory) бывает компрометация контроллеров домена, то есть получение учетки с правами группы Domain Admins.
Обычно как получается с такими сетями: находим дырявые сервисы, получаем контроль над хостом, из памяти добываем учетки (креды либо хешики) и с ними идем уже на другие хосты, пока не найдем где-нибудь процессы юзера из группы Domain Admins. Если честно, то, сколько помню пентестов, проблемы найти админов не было — они обнаруживались сами собой и достаточно быстро. И как-то даже мысль не приходила в голову, что есть такая задачка — находить их.
Но вот наткнулся на интересный топик блога компании NetSPI и осознал, что «точечный удар» будет более профессиональным подходом. Самое интересное, что можно с правами обычного доменного юзера оперативно найти администраторов.
Итак, начнем. Первая подзадача — определить всех админов домена. То бишь наших жертв. Фактически не считается, что эта информация приватная, а потому доступна она всем юзерам домена по умолчанию. Узнать их можно, например, стандартной командой
Net group "Domain Admins" /domain
Но если помнишь, с ActiveDirectory можно работать через LDAP, причем опять-таки по умолчанию для доступа к нему требуется любая доменная учетка. Как следствие, мы можем получить не только перечень админов, но и, по сути, структуру юзеров и групп, а также много другой интересной информации.
Вторая подзадачка — найти процессы, запущенные от админов домена. Это уже более специфическая тема. Методов несколько.
Есть такая штука, как Service Principle Name (SPN). Если очень примерно, то это имя сервиса, под которым он регистрируется в AD для работы Kerberos-аутентификацией. Но нас интересует здесь несколько другое. А именно то, что в LDAP’е мы можем просмотреть SPN с привязкой к аккаунту AD, под которой он запущен. То есть если какой-то сервис был запущен изначально под учетной записью администратора домена, то в LDAP’е для этой учетки будет SPN-запись с названием сервиса, а главное с именем хоста, где этот сервис запущен. Чтобы не ползать вручную по LDAP’у, NetSPI написали скрипт на PowerShell для удобного и быстрого поиска по группам.
Но у этого способа есть один минус. На практике только Microsoft’овские сервисы регистрируют себя в домене, а если учесть, что их нечасто запускают из-под доменных учеток, то шансы не очень велики. С другой стороны, если вспомнить, что каждый хост имеет учетную запись в AD, то мы можем легко найти все сервисы какого-то типа. Самый практичный пример — найти все MS SQL сервисы, которые есть в домене! И без какого-либо сканирования.
Иную возможность предоставляет нам NetBIOS. Мы с правами обычного юзера можем запросить у контроллеров домена информацию по активным сессиям. В итоге мы можем получить имя хоста с админскими процессами. Минус заключается в том, кто информация о сессиях будет за короткий промежуток времени, то есть если не было взаимодействия с контроллером, то мы не увидим админа в списке. А потому надо систематически запрашивать контроллеры — админчик когда-нибудь точно появится.
С помощью тулзы NetSess можно сделать запрос инфы, а с помощью скриптика автоматизировать поиск по выводу.
Хакер #191. Анализ безопасности паркоматов
NetSPI в блоге предложил еще два метода: запрашивать отдельные хосты на сессии юзеров через NetBIOS или, если есть учетка локального админа (одна на многих хостах), удаленно запрашивать список запущенных процессов. Но, имхо, оба они работают в редких случаях, да и шумноваты.
Задача
Создать одну сеть для VirtualBox и VMware
Решение
Недавно нужно было в одну сеть «объединить» гостевую тачку под VirtualBox и гостевую от VMware на одной хостовой машине. Оказалось, что сделать это очень даже просто. А главное, значительно быстрее, чем конвертировать виртуалку в другой формат. Последовательность такова.
При установке VirtualBox создается дополнительный сетевой интерфейс в хостовой ОС VirtualBox Host-Only Ethernet Adapter. Его мы должны выбрать в настройках гостевой ОС VirtualBox (вкладка Network) с типом host only adapter.
Далее мы должны настроить сеть в VMware. Здесь нам понадобится Virtual Network Editor, который поставляется с VMware Workstation. В нем мы должны выбрать любую сеть (VMnet0-9), выставить для нее тип Bridged и указать в списке тот же интерфейс — VirtualBox Host-Only Ethernet Adapter. И последний шаг — в настройках гостевой ОС в VMware указать имя сети, для которой была произведена конфигурация. И все! Причем DHCP от VirtualBox’а тоже должен работать.
По идее, VMware Player тоже может подключиться к сети VirtualBox’а так же через Bridge. Но там вроде как есть проблемы с DHCP, а потому IP надо задавать вручную.
Задача
Пробросить порт под Windows
Решение
Пробросить порт — это одна из самых типичных задач. Вот систематически с ней сталкиваюсь, когда необходимо ресерчить какую-нибудь толстенную программулину, которая по умолчанию вешается на lookback-интерфейс (127.0.0.1), но, чтобы ее перенастроить на другой интерфейс, надо побегать с бубном с пару дней. Под никсами все просто, а вот под виндой это у меня обычно решалось сторонними штуками (считай костылями), типа ncat’a. Но, спасибо Глебу за наводку, оказывается, можно пробросить порты чисто внутренними средствами — с помощью команды netsh. Возможностей у нее целая масса, но за ними отправлю тебя к мануалам, а здесь будет лишь пример для проброса:
netsh interface portproxy add v4tov4 listenport=4422 listenaddress=192.168.0.222 connectport=80 connectaddress=192.168.0.111
netsh — сама тулза; interface portproxy — подклассы команд; add v4tov4 — добавить правило IPv4 на IPv4 (по идее, изначально тулза создавалась именно для решения проблем с внедрением IPv6); а далее — порт и адрес, который ОС будет слушать, и порт и адрес, куда будет перенаправлять данные. Netsh interface portproxy show all покажет все имеющиеся правила.
Тулза полезная, особенно когда надо будет поснифать локальный трафик.
Задача
Обойти lock screen для iOS
Решение
Чтобы обезопасить данные, на многих мобильных девайсах используется lock screen, который требует ввести либо код, либо графический ключ. Конечно, хуже всего то, что пользователи мобильных девайсов верят, будто их приватная информация хорошо защищена локскрином. Но нам в любом случае интересно, как можно его обойти.
Как ни странно, способы были, есть и будут. Мне хотелось бы познакомить тебя с очень занимательной ссылкой. В этом топике блога SANS Penetration Testing представлен целый пак ссылок на видео и описания уязвимостей, которые были найдены в разных версиях iOS. Очень поучительный материал.
Но еще интересней, что есть универсальный метод получения частичного доступа за локскрином (в настройках по умолчанию, конечно), который работает даже в последних iOS’ах и который Apple, похоже, не будет править. Как ты, наверное, догадался, я говорю про Siri. Для людей, далеких от яблочных девайсов: Сири — это система управления смартфоном голосом.
Причины проблем кроются, во-первых, в том, что Сири доступна без ввода кода. А во-вторых, в нее входит ряд критичных функций, которые могут быть использованы без ввода кода. Например, можно посмотреть перечень последних звонков и сообщений, запостить что-нибудь в фейсбуке или твиттере или даже прочитать заметки (notes), где очень многие хранят реально приватные вещи (паролики, например). Это [видео](goo.gl/n40xcx все пояснит на примерах. Но конечно, это тот еще фейл.
Задача
Собрать уязвимости под Android
Решение
Еще один мини-вопрос про интересный ресурс. Вообразим, что это раздел WWW2 :). На самом деле достаточно интересная ситуация обстоит с андроидами. Платформа развивается хорошими шагами, но, в отличие от iOS, разработчиков и производителей для андроида большие кучи. И конечно, безопасность не является одним из приоритетов для них. А добавим к этому еще и геморрой с обновлениями (особенно на нетоповых моделях).
В общем, дыры появляются специфичные для вендоров и, непатченные, живут долгой жизнью. На данном ресурсе пытаются хоть как-то консолидировать и структурировать их. Есть на что посмотреть. Надеюсь, ресурс будет развиваться.
Задача
Пробросить Meterpreter за NAT/DMZ
Решение
Для начала напомню тебе, что Meterpreter — это продвинутый динамически расширяемый шелл из Metasploit’а (MSF). Штука реально прикольная, одна из главных фишечек MSF.
Теперь к примерам по задаче. Представь себе, что есть закрытая корпоративная сеть и мы посылаем письмом наш троянчик с Meterpeter’ом, дабы захватить контроль над хостом какого-нибудь офисного сотрудника. Ты, возможно, знаешь, что в MSF есть различные виды шеллов с различными видами установления контакта между жертвой и атакующим: обычные бинды, back-connect’ы на различных протоколах, портах, через прокси-серверы или через DNS… Много-много различных вариантов.
Но что, если они нам не подходят? Что, если у жертвы есть доступ к почте? Чисто теоретически мы могли бы поломать еще какой-то хост в той же сети или в DMZ (но с которым у нас есть возможность общаться через сеть) и использовать его как транзитный. На самом деле реализовать такое можно было бы чисто за счет проброса портов, но не с Metasploit.
А вот еще один пример. У меня есть комп с виндой, но совсем нет желания ставить на него MSF (уж больно толст он стал), и я использую его из-под виртуалки с Kali. И все хорошо, когда виртуалка подключена в bridged-моде, но это не всегда возможно (port security, например), и приходится убирать ее за NAT. И вот тут начинаются трудности, когда мы что-нибудь пытаемся проэксплуатировать и получить шелл. Практическим мы опять-таки могли бы сделать просто проброс портов за NAT, но, когда мы имеем дело с MSF и reverse (back-connect) шеллами, мы должны указать свой IP, но что хуже — MSF пытается поднять на этом IP-адресе хендлер для шелла.
Возможно, и есть какие-то пути победить эту проблему чисто средствами, но, помнится, такая ситуация появлялась несколько раз и дельного решения в голову не приходило.
После такой преамбулы хотелось бы поделиться радостью — наконец-то в MSF появилась возможность общаться с жертвой (с Meterpreter) через какой-то хост. Хотя выглядит это, конечно, чем-то похожим на костыль.
Итак, во-первых, добавился новый класс payload’ов Meterpreter — со словом hop в названии (например, payload/windows/meterpreter/reverse_hop_http). Да-да, фича эта чисто кастомная. Во-вторых, появился специальный скрипт на PHP для промежуточного сервера, который будет отвечать за пересылку данных между жертвой и атакующим. Я думаю, ясно, что промежуточный хост должен быть нам подконтролен. Язык PHP выбран как самый распространенный, но обещают написать и на других языках. Хотя, конечно, сама фича поднятия веб-сервера со скриптом несколько удивляет, в особенности когда промежуточный хост у нас Windows-тачка. С другой стороны, для моей/второй проблемы с NAT это может быть оптимальным решением.
В этом видео показан пример использования hop’a. Думаю, после его просмотра особых вопросов с настройкой Meterpreter’а не возникнет.
Задача
Постэксплуатация MS SQL DB links
Решение
В прошлом номере мы коснулись такой темы, как линки в базах данных и чем они нам могут помочь в пентестах на примере Oracle. Сегодня пробежимся по данной возможности для СУБД MS SQL. За основу был взят пост c NetSPI, они больше всех копались в этом деле.
Итак, линки — это возможность СУБД запрашивать данные из сторонних источников. Зачастую это другие аналогичные базы данных, но могут быть и совершенно иные. Так, MS SQL может линковаться как c MS SQL, так и с Oracle, MySQL, MS Access и даже с Excel-табличками. Но без дополнительной настройки вроде только к первому варианту.
В отличие от Оракла, в микрософтовской базе данных создание линков всегда было высокопривилегированной фичей, а потому нас больше волнует возможность, что мы можем делать с уже имеющимися линками. Так как зачем нам создавать линки, если можно сразу получить RCE на сервере? А вот уже созданными линками могут пользоваться любые юзеры базы данных, что очень удобно для нас.
Посмотреть их мы можем в табличке:
select * from master..sysservers
В ней мы увидим серверы (srvname), с которыми есть линки, тип подключения (providername) и доступность линка (dataaccess, доступен, если 1). Есть еще rpcout, который указывает на возможность RPC-коннектов к удаленному серверу (об этом далее).
Как и оракловой базой данных, здесь поддерживаются различные методы аутентификации при подключении к сторонним серверам. То есть мы, например, имеем доступ в базу данных А с правами обычного пользователя, но можем обратиться к линку, который подключится в базу Б с другой, привилегированной учеткой. Как ты понимаешь, в таких случаях СУБД должна хранить эту учетку. И это действительно так — в определенной табличке в зашифрованном виде (AES для 2012 и 3DES для более старых версий, с рандомным ключом). Для того чтобы расшифровать его, необходимо иметь админский доступ к ОС и в БД. NetSPI написали тулзенку для этого дела на PowerShell. Несмотря на то что нам необходимо иметь доступ на сервер, этим можно заняться, чтобы получить plain-text пароль и попробовать, не используется ли он где-то еще.
Чтобы сделать запрос к линкованной базе данных, есть два метода.
Через openquery:
select version from openquery("linkedserver", ‘select @@version as version');
Либо так:
select name FROM [linkedserver].master.sys.databases
Минус второго метода заключается в том, что мы не можем делать запрос через несколько линков. Да-да-да. С openquery мы можем запросить информацию из линка в другом линке.
select version from openquery("link1",'select version from openquery("link2",''select @@version as version'')')
При этом количество «вложенностей» (то есть линков) может быть произвольно. Единственный момент тут в удвоении количества кавычек в запросах. Кроме того, документация МS говорит о невозможности выполнения хранимых процедур на линкованной БД. NetSPI это ограничение обошли, добавив произвольный запрос перед вызовом процедуры. Да, мы не получим итог процедуры, но ведь это не всегда и нужно.
select 1 from openquery("linkedserver",'select 1;exec master..xp_cmdshell ''dir c:''')
Как видишь, все вполне круто и просто.
Вот только с RCE (через xp_cmdshell) на прилинкованных серверах есть трудности (не считая того, что линковка должна быть под привилегированной учеткой). Главная из них заключается в том, что хранимая процедура xp_cmdshell во всех версиях SQL-сервера после 2000 отключена по умолчанию. Конечно, в обычных условиях мы можем воспользоваться sp_configure, но только не для линкованных серверов. Используемый openquery указывает на то, что транзакция пользовательская, а потому не допускается переконфигурация сервера. Как-то так, грустно.
Теоретически имеется возможность переконфигурировать прилинкованный сервер, но он должен быть слинкован с возможностью RPC-вызовов (rpcout, упомянутый ранее), а по умолчанию это не так. Имхо, шанс найти привилегированный линк, да еще и с такой настройкой, стремится к нулю. Но в любом случае вот пример:
EXECUTE('sp_configure ''xp_cmdshell'',1;reconfigure;') AT LinkedServer
Как видишь, все просто, но позволяет иногда докопаться до интересных глубин.
На этом все. Удачного ресерча!
