В этой статье, как вы уже поняли, мы рассмотрим поиск уязвимостей на практике в пошаговой форме.
Без лишних прелюдий, хакерман приступает к объяснениям:
1. Поиск уязвимостей в веб-приложении.
Сайт представлял собой написанное с нуля веб-приложение. Для использования функций требуется ввести логин и пароль, но предусмотрен гостевой вход, поэтому на сайте прямо на главной странице написаны гостевые учётные данные для входа.
Выполняемые действия сохраняются в Истории. У действия есть заголовок и определённый текст. Оказалось, что хранимые поля не фильтруются на специальные символы и слова, поэтому быстро удалось найти и подтвердить уязвимость XSS — то есть кода в поле вводишь что-нибудь вроде
<script>alert(1)</script>
а на странице сайта (в данном случае в История) показывает всплывающее окно JavaScript.
С помощью такой уязвимости можно, например, похитить кукиз других пользователей. Но проблема в том, что, видимо, История, у каждого пользователя своя. То есть максимум, что я могу сделать в этой ситуации, это захватить кукиз пользователей с точно такими же правами как у меня — то есть только у пользователей, выполнивших вход под гостевой учётной записью. Возможно, админу доступен список Истории всех пользователей — но не факт. Плюс надо ещё придумать, как спровоцировать его зайти в Историю — а то может получиться так, что в следующий раз он туда зайдёт через год, или через два, или никогда.
Поскольку видно, что специальные символы не фильтруются, а данные, скорее всего, хранятся в базе данных, то это может означать, что должна присутствовать уязвимость SQL-инъекция, которая позволяет получить базу данных сайта. Но я не успел это проверить — обнаружилась намного более лёгкая уязвимость — небезопасная выгрузка файлов.
Суть в том, что если я запускал новое действие, то мне для ввода были доступны несколько полей — в них я и обнаружил XSS и мог обнаружить SQL-инъекцию. Но при открытии сохранённого действия из Истории, на странице появлялось ещё одно поле — для загрузки файла!!!
У меня появилась умеренная радость: с одной стороны, на множество сайтов можно загружать файлы, но благодаря ограничению на расширения загружаемых файлов, а также способу доступа к ним, практически невозможно загрузить код, который можно выполнить на сервере. Но безалаберность с фильтрацией данных в текстовых полях вселяла некоторую надежду.
Я создал файл
<?php phpinfo();>
И загрузил его на сервер. Сервер показал мне ссылку на этот файл. То есть файл загрузился! Я перешёл по ссылке и вместо того, чтобы скачаться, либо чтобы показать содержимое — файл был выполнен, то есть я увидел ту информацию, которую показывает функция phpinfo().
В чём ошибки программиста:
Такой безалаберный стиль программирования нельзя совмещать с публичной учётной записью. То есть если бы на главной странице не были написаны учётные данные для входа, то поиск и эксплуатация этих уязвимостей сильно бы затянулись.
И более главное: при написании кода всегда нужно фильтровать данные и ограничивать файлы, которые можно загружать на сервер. Даже если вы программируете «для себя» и держите файлы на локальном сервере у себя на компьютере, всё равно может случиться неприятность — кто-то может подключиться к вашему веб-серверу по локальной сети (при использовании публичным Интернетом), или ваш компьютер может быть доступен напрямую по белому IP. Очевидно, что для публичного сайта код должен писаться с постоянной мыслью о безопасности.
Дальше в статье (с ссылками и кодами) я расскажу стадии последующии, во избежании жалобы на пост.
https://telegra.ph/Pentest-sajta-12-shagov-poiska-uyazvimostej-na-praktike-v-poshagovoj-forme-07-25
Я постарался описать в статье последующие шаги, такие как: Загрузка бэкдора , Осматриваемся на сервере из бэкдора, Как скачать исходный код сайтов с сервера, Как узнать, какие сайты работают на сервере, Взлом MySQL, Анализ добытых паролей, Промежуточный итог, Камеры, Поиск слабых настроек сервера, Брут-форс SSH и FTP , ну и конечно Взлом почты.
Заключение.
Вы можете подумать, что этот рассказ — это просто перечисление всех самых детских и самых нелепых ошибок, которые только могут допустить начинающие школьник-программист и администратор. Мол в реальной-то жизни такого не бывает. Бывает… Это абсолютно реальный разбор, реального сервера.
К сожалению, не могу даже в общих чертах сказать о контексте этого случая. Но факт в том, что организация, которой принадлежит этот сервер, находится в Москве и у неё не без оснований на стене висит большой триколор.
Вы можете обратить внимание, что я по минимуму использовал специализированные утилиты. Почти все «взломы» заключались в том, что я знал где и что нужно смотреть и просто это смотрел. Поэтому обучение аудиту безопасности сайтов (взлому сайтов), заключается не только в изучении специализированных утилит. В первую очередь нужно понимание происходящих процессов. Если мы говорим о сайтах, то должно быть понимание, как они функционируют. Я не могу себе представить, как можно делать тест на проникновение сайта, если нет умений по программированию на PHP и хоть какого-то опыта в создании сайтов и веб приложений (CMS, движков и прочего). Если пентестинг продолжается на сервере, то тут просто нечего делать без таких мирных профессиональных навыков как:
понимание работы сервера, умение его настраивать
понимание ОС Linux, её внутренного устройства
умение работать в командной строке и знание хотя бы самых ходовых команд (утилит) Linux
Спасибо за то, что дочитал! С тебя лайк и коммент!
