Natas Web. Прохождение CTF площадки, направленной на эксплуатацию Web-уязвимостей. Часть 221.08.2019 01:28

В данной статье мы разберемся с эксплуатацией некоторых WEB-узвимостей на примере прохождения варгейма Natas. Каждый уровень имеет доступ к паролю следующего уровня. Все пароли также хранятся в файлах /etc/natas_webpass/. Например, пароль для natas5 хранится в файле /etc/natas_webpass/natas5 и доступен для чтения только для пользователей natas4 и natas5.

Организационная информация

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

PWN;
криптография (Crypto);
cетевые технологии (Network);
реверс (Reverse Engineering);
стеганография (Stegano);
поиск и эксплуатация WEB-уязвимостей.

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

Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.

level 11

Разбираем код:

пароль будем доступен, если значение из массива data по ключу showpassword будет «yes»;
массив data создается функцие loadData, в которую в качестве параметра передаются данные по умолчанию;
функция loadData загружает значения data из cookie (кодирует data в base64, шифрует xor на неизвестном ключе, декодирует данные в формате json);
устанавливает полученные значения.

Что же нужно сделать:

восстановить ключ XOR шифрования:
- взять зашифрованные данные из cookie;
- декодировать base64;
- закодировать данные по умолчанию в json формат;
- проксорить полученные сроки.
закодировать и зашифровать по обратному алгоритму новые данные, где showpassword == yes;
вставить новые данные в cookie и перезагрузить страницу.

"no", "bgcolor"=>"#ffffff");
$new_data_decode = array( "showpassword"=>"yes", "bgcolor"=>"#ffffff");
$KEY = xor_encrypt(base64_decode($old_data_code), json_encode($old_data_decode));
echo "key: ". $KEY . "\n";
$KEY="qw8J";
$new_data_code = base64_encode(xor_encrypt(json_encode($new_data_decode), $KEY));
echo "new cookie: " . $new_data_code . "\n";
?>

level 12

При сохранении файла на сайте, он сохраняется под случайным именем и расширение JPEG. Но самое главное, что это имя формируется и предоставляется пользователю в скрытом поле формы hidden еще до выбора файла, а после — вместе с файлом отправляется на сервер.

Задача: cоздать php-shell, перехватить запрос на сервер и
изменить имя файла на *.php.

Используем Burp Suite: Выставляем настройки прокси браузера на 127.0.0.1:8080. Отправляем shell. Во вкладке Proxy подменяем запрос.

Обращаемся к своему файлу на сервере, передавая команды в командную строку через параметр cmd.

cat /etc/natas_webpass/natas13

Данный вид уязвимости относится к категории Unrestricted File Upload.

Для создания Shell`a лучше всего использовать константы php, так как выполнение системных функций может быть запрещено настройками сервера.

level 13

При сохранении на сервер того же самого shell`a, нам говорят, что это не изображение. Анализируем код.

Присутствует функция exif_imagetype.

Для проверки JPEG файла данная функция использует внутреннюю функцию is_jpeg, которая проверяет первые четыре байта файла.

Дело в том, что интерпретатор языка php выполняет код, который находится между , пропуская все остальные символы. Откроем shell прошлого уровня в hex редакторе и допишем в начало файла байты 0xFFD8FFE0.

Отправим на сайт по аналогии с прошлым уровнем и получим пароль.

level 14

Обычная ошибка в форме авторизации. Запрос к БД:

SELECT * from users where username="username" and password="password";

Есть возможность сделать запрос всегда истинным: login = «admin» or 1=1 — ».

В таком случае or 1=1 возвращает истину, а остальная часть запроса комментируется:

SELECT * from users where username="admin" or 1=1;

Забираем пароль.

Данный вид уязвимости относится к категории SQL Injection.

level 15

На данной форме разберем работу sqlmap. Отправим запрос и перехватим данные и заголовок HTTP.

Выбираем из заголовка только необходимую информацию. В данном случае: User-Agent, Referer, Authorization. Задаем параметры sqlmap:

-u «URL»
--headers= «заголовки HTTP, разделенный `\n` »
--data=«данные POST-запроса»
--current-db — определить какая БД используется
--tamper=space2comment — заменить пробел строкой /**/ (в SQL это одно и тоже)
--level=(1–5) — уровень сканирования
--risk=(1–3) — риск сканирования

Sqlmap определил, что параметр username уязвим к Boolean-Based Blind иньекции, и показал правильный ответ БД на верное событие (в последующем сканировании для быстрой работы можно сразу указать уязвимый параметр и тип иньекции: -p username и --technique=B).

B: Boolean-based blind SQL injection
U: UNION query SQL injection
T: Time-based blind SQL injection
E: Error-based SQL injection
S: Stacked queries SQL injection

Sqlmap определил СУБД MySQL (в последующих сканрованиях параметр --dbms=MySQL) и спросил нужно ли определять версию mysql (по умолчанию yes).