Задача
Выполнить команду в ОС в Oracle DB XE
Решение
Вот представь себе, что у нас есть доступ к СУБД по сети (через TNS) либо через SQL-инъекцию с админ-учеткой. И конечно, у нас может возникнуть желание развить нашу атаку, попасть в ОС, закрепиться там и полезть дальше. Самый стандартный способ выполнения команд через Java. Но вот незадача — не всегда работает. Причина в том, что существует урезанная версия Oracle, так называемый Express Edition (XE), которая поставляется без Jave Virtual Machine и еще кое-чего. Что же делать?
Использовать другой способ выполнения команд! Например, через шедулер.
begin
DBMS_SCHEDULER.create_program('any_name','EXECUTABLE','echo “any commands with parameters”',0,TRUE);
DBMS_SCHEDULER.create_job(job_name=>'any_job_name',program_name=>'any_name',
start_date=>NULL,repeat_interval=>NULL,end_date=>NULL,enabled=>TRUE,auto_drop=>TRUE);
dbms_lock.sleep(1);
dbms_scheduler.drop_program(program_name=>'any_name');
dbms_scheduler.purge_log;
end;
Я думаю, что смысл здесь ясен из названий команд. Практически последние три не особо нужны. Только чтобы кильнуть команду и почистить лог.
Результат работы запущенной команды не возвращается, но, насколько помню, перенаправление вывода и другие штуки отлично работают.
Задача
Найти уязвимые JS-либы
Решение
Веб-приложения все больше становятся похожими на обычные приложения. Разделение логики и ресурсов, использование сторонних библиотек. И эксплуатация становится похожа — кроме того, что найти саму багу, надо еще обойти ту или иную защиту.
По сути-то, ничего удивительного, что и в самих библиотеках находятся какие-то уязвимости. И если к серверному ПО у нас часто нет доступа, то с фронтендом — с JavaScript’ом — нам все доступно: и версию библиотеки можно узнать, и, соответственно, баги, которые в ней есть. Конечно, бага в либе еще не означает багу в самом приложении, ведь часто нужно и чтобы приложение использовало уязвимый функционал, и чтобы мы могли «воздействовать» на него. Фактически большая часть уязвимостей повязана с возможностью подпихнуть XSS’ку. Вот пример такой уязвимой либы.
Задачка не ахти какая, но все-таки нужная. И поможет нам с ней тулза Retire.js. У нее есть небольшая база распространенных либ и уязвимостей в них. Определение версии происходит по данным из самих либ и их отпечатку. Имеются различные виды ее реализации: отдельная тулза, модуль к хрому или ФФ, а теперь вот добавились модули для Burp’а и ZAP’а. Не rocket science, но помогает.
Задача
Пофазить парсер браузера
Решение
Несмотря на то что браузеры — это вещь давно привычная и сайты в них выглядят практически одинаково, внутри они отличаются значительно. И опять-таки, несмотря на то что веб вроде как во многом стандартизирован, если присмотреться, то обнаружится большой ряд неточностей и недоговорок, которые различные вендоры решают по-своему. В итоге все приходит к тому, что каждый из браузеров имеет свою специфику. Вот, например, Internet Explorer здесь сильно выделяется, о чем мы не раз говорили в Easy Hack’е и чем мы не раз пользовались для эксплуатации специфичных (браузерозависимых) уязвимостей. Но и в других браузерах специфических и зачастую уязвимых реализаций того или иного функционала предостаточно, так что любому пентестеру желательно знать специфику и остальных браузеров. Приведу несколько примеров.
Недавно вскрылась большая уязвимость в мобильном браузере (это не хром и не ФФ, а отдельный такой браузер) на платформе Android. И не простая уязвимость, а обход Same Origin Policy. Напомню, что SOP — это когда у тебя в браузере JavaScript с одного сайта не может просто получить данные другого сайта. То есть браузер каждый отдельный сайт (точнее, протокол + сайт + порт) воспринимает как отдельную сущность и очень ограничивает возможность доступа к другим таким же сущностям. Когда же есть обход SOP, мы, заманив юзера к нам на сайт (http://evil.ru, например), с нашего сайта можем получить полный доступ к любому другому сайту от имени юзера. Так вот, атака для обхода SOP для андроидобраузера вполне проста:
<iframe name="test" src="http://gmail.com"></iframe>
<input type=button value="test" onclick="window.open('\u0000javascript:alert(document.domain)','test')" >
Вот такой код мы размещаем на своем http://evil.ru, а в итоге код (alert(document.domain)) выполнится на Gmail’е. По коду мы здесь создаем iframe с почтосайтом, а дальше в нем же «запускаем» свой яваскрипт (input нужен лишь для тестирования, в реале все происходит автоматом). Все в атаке вполне логично, но браузеры должны такое пресекать (как раз по SOP), а самое главное, что и дефолтный дроидовый браузер это пресек бы. Если бы не «\u0000» — это «null»-байт, заэнкоженный в юникоде. Именно из-за него у браузера не срабатывает проверка и мы имеем крутейшую уязвимость. Причем с учетом того, что уязвимость до версии Android’а 4.4 есть, да и с тем, что обычные люди не патчат свои девайсы, это просто золотая жила.
Пример номер два. Систематически бывает, что вроде можно подпихнуть что-то похожее на XSS’ку, но практически мы сталкиваемся с различными ограничениями. Например, нельзя пробелы подсовывать, потому что они вырезаются, или двойные и одинарные кавычки фильтруются, а они нам нужны. Так вот и здесь для успешной эксплуатации нам надо знать, что пробелы между элементами мы можем заменить на слеш / (например, <svg/onload=alert(1)>), а в IE мы можем использовать вместо кавычек апостроф `. Как видишь, тонкостей много.
Но откуда ж это все узнать? Во-первых, это cheatsheet’ы, то есть готовые методики для типовых проблем (например, от OWASP).
Во-вторых, можно пофазить и самому. Не так давно появился очень интересный ресурс Shazzer. Это онлайн-тулза для фаззинга браузеров. Можно очень по-быстрому накатать необходимый тебе векторок и профазить его. Но более важно то, что векторы и итоги их шарятся между пользователями системы. Это нам дает, во-первых, то, что многие из интересующих нас векторов уже профажены и мы оперативно можем посмотреть итоги, а во-вторых, то, что люди приходят с разными браузерами и, как итог, мы иногда имеем возможность выявить какие-то специфические браузерные штуки.
Конечно, если ты уже давно и глубоко в вебе (особенно браузерном), то, вероятно, имеешь некую свою платформу с блек-джеком и барышнями, но для разовых задач ресурс идейно очень удобен.
Подробнее о ней можно прочитать здесь.
Задача
Впихнуть XSS за счет парсера браузера
Решение
Задачка в продолжение предыдущей. Про очень важный момент работы браузеров, знание которого позволяет обходить различные ограничения и проводить атаки (например, XSS). Особенно при выполнении различных заданий на соревнованиях.
Так вот, в браузере можно выделить два основных парсера (если честно, на самом деле там все куда сложнее, но сейчас давай остановимся на этих двух): первый — это HTML, а второй для JavaScript’а. И самое интересное здесь — что браузер при парсинге документа, полученного от сервера, сначала проходит HTML парсером, а уже потом — JS.
Почему же это важно? Это связано с тем, что парсеры отличаются между собой и на их «стыке» иногда можно «сыграть». Например, HTML-парсер позволяет заэнкодить данные. Тебе, наверное, знакомы сущности >, <, которыми заменяют символы <, > в тексте страницы (то есть чтобы парсер понял, что это не разметка, а обычные данные). Кроме них, еще есть замена для большинства специальных символов — кавычки, амперсанд и так далее. Но кроме текстовых обозначений, для всех символов есть еще и цифровые. Причем и в десятеричной, и в шестнадцатеричной системе. То есть тот же > можно записать в десятеричном виде как <, а букву X как X. Если же хочешь в шестнадцатеричном, то добавляем x перед номером. Для тех же символов будет соответственно < и X. С юникодом все аналогично.
Важный момент, что декодятся только данные и значения параметров. То есть нельзя заменить открытие тега (< как <), символы в названии тега (script на script) или параметре тега (onload на onload). Но так как JavaScript «находится» в данных тегов HTML, то мы можем к нему применять HTML-кодирование. Пример:
<img src=x onerror=alert(2);>
Здесь на ивенте onerror выполняется alert(2). a — в юникоде.
С другой стороны, внутри блока
