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

level 0

Просматриваем исходный код страницы и проверяем комментарии.



Находим пароль.

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

level 1

Снова просматриваем исходный код страницы, но на нажатие правой клавиши мыши назначено javascript событие, которые не позволяет сызвать контекстное меню.



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



Находим пароль.

Как вариант(иногда приоритетней), можно просто скачать всю страницу и просмотреть код.

wget --http-user=natas1 --http-password=gtVrDuiDfck831PqWsLEZy5gyDz1clto http://natas1.natas.labs.overthewire.org

level 2

Снова просматриваем исходный код страницы, замечаем, что на страницу загружается картинка.



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



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

Для того, чтобы избежать просмотр файлов в дирректории, в настройках сервера (в данном случае /etc/apche2/httpd.conf) должен стоять запрет на индескирование файлов. Или в данной дирректории должен находиться файл index.html.

level 3

Снова просматриваем исходный код страницы, там нет ничего интересного. Вторым пунктом после просмотра исходного кода, является сканирование файлов и дирректорий. В качестве параметеров утилиты dirb укажем пользователя и пароль для http-аутентификации.



Файл robots.txt содержит список дирректорий и файлов, который запрещены для просмотра роботам-поисковикам (например google и yandex).



Зайдем в скрытую дирректурию на сайте, найдем файл и заберем пароль.

Как аналог, можно использовать утилиты dirsearch, или burpsuite.

level 4

Сервер сообщает, с какой страницы перешли и говорит с какой нужно перейти. Эти данные он может проверить только в заголовке протокола HTTP.



В браузере выбирем панель инутрументов > сеть > прошлый запрос и «изменить и отправить». Следует изменить поле Referer – именно оно показывает откуда мы перешли.



Осталось забрать пароль.

Данное действие burpsuite.

Необходмо постоянно просматривать, какие HTTP поля просматривает Web-Сервер. Это самые редко- фильтруемые пользовательские данные.

level 5

Сервис сообщает, что мы не залогинины. То есть он хранит данные нашей авторизации. Единственное место где Это можно передавать: сессия cookies.



Посмотрим кукисы (для удобства лучше установить расширения в браузере), и изменим значение параметра loggedin на 1.



Перезагрузим страницу и заберем пароль.

Данный вид уязвимости относится к категории Broken Authentication and Session Management.

level 6

Данный сервис предоставляет нам исходный код для анализа.



Секрет, который мы должны ввести, инклудится (подключается из файла).



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



Отправляем секрет, получаем пароль.

level 7

Перейдя по обеим ссылкам, замечаем какион образом они загружаются. Название файла на сервере передаётся в GET параметре pages.



Попробуем указать в качестве параметра путь к файлу /etc/passwd.



И нам говорят, где забрать пароль.

Данная уязвимость относится к категории LFI.

level 8

Предоставлен исходный код сервиса. Хранится закодированная строка и способ кодирования.



Необходимо раскодировать в обратном порядке:

1. перевести из hex-вида в бинарное представление;
2. перевернуть строку;
3. декодировать base64.

<?php
$secret = "3d3d516343746d4d6d6c315669563362";
echo base64_decode(strrev(hex2bin($secret)))."\n";
?>

Отправляем секрет и получаем пароль.

level 9

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



Так как данные не фильтруются, то можно собрать конвейер и выполнить иные команды ОС. Если передать в запрос строку, к примеру: « || ls # », то полный запрос станет таким «grep -i || ls # dictionary.txt». Все, что после || – выполнится с ошибкой, а после # – будет закомментировано, т. е. мы получаем только вывод команды ls.



Таким образом читаем файл: «|| cat /etc/natas_webpass/natas10 #».

Данная уязвимость относится к категории OS Command Injection.

level 10

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



Задача такая же, как и на уровне 9, только теперь присутствует фильтр. Т.о. из запроса исчезнут знаки: «;»,«|»,«&». Можно лигитимно прочитать файл! Предположим, что в нашем пароле есть символ «z»: « z /etc/natas_webpass/natas11 # ».



Продолжение следует. Вы можете присоединиться к нам в Telegram.