После обнаружения уязвимости межсайтового скриптинга в коммерческом приложении меня заинтриговала идея разработать мощную полезную нагрузку для этой уязвимости. Из-за срочности этого конкретного открытия я собрал базовый JavaScript Keylogger, который при развертывании на чувствительной странице, такой как страница входа в систему, злоумышленник может установить имя пользователя и пароли всех пользователей, которые посещают страницу.
Мы, конечно, могли бы делать более громкие и агрессивные полезные нагрузки, такие как запрос доступа и потоковая передача веб-камеры компьютера или попытка обмануть пользователя, чтобы он включил микрофон, но я хотел создать что-то более незаметное, что обычному пользователю было бы очень сложно. замечая.
Итак, основная идея заключается в том, что сценарий вводится на страницу входа на веб-сайт. Он отслеживает все нажатия клавиш, которые вводятся на странице, и сохраняет их во временный массив. Затем, когда на странице происходит значительное событие (в этом примере давайте придерживаться отправки формы входа), мы перехватываем событие и отправляем собранную информацию на удаленный сервер.
Если вы здесь только ради полезной нагрузки в необработанном виде, то вот она. Обязательно измените переменные login_form и remote, чтобы полезная нагрузка была эффективной:
Полный проект также доступен на Github:
Чтобы начать этот проект, я решил использовать PHP, чтобы быстро и легко создать веб-сервер, который позволил бы мне писать логику сервера и внешнего интерфейса в одном и том же наборе файлов. Я хотел смоделировать как жертву, так и злоумышленника, каждый со своим уникальным сервером, который будет работать с совершенно разными наборами кода. Это позволит включить в полезную нагрузку метод эксфильтрации, который можно будет протестировать и проверить.
Докер:
Выбор использования PHP в качестве языка программирования делает docker логическим решением для имитации нескольких серверов, взаимодействующих через HTTP.
Я хотел иметь возможность монтировать два каталога в моем проекте в веб-корни каждого из моих контейнеров докеров. Для этого я создал два подкаталога в корне моего проекта. Один называется «сервер_ жертвы», а другой - сервер_ атакующего.
Затем я добавил базовый файл «index.php» Hello World на каждый из серверов:
<?php echo 'Hello World';
а затем запускал их в отдельных контейнерах докеров. Для этого я сделал два сценария оболочки, чтобы быстро запускать каждый из них. Ниже приведен запуск сервера злоумышленника:
workingdir=$(dirname $0) docker run --volume $workingdir/attacker_server:/var/www/html -p 8081:80 php:5.6-apache
Здесь вы можете видеть, что я использую образ php: 5.6-apache для каждого из моих контейнеров, а затем монтирую папку сервера непосредственно в каталог / var / www / html.
Такое подключение серверов позволяет мне сразу же отражать изменения, внесенные в проект, в браузере без необходимости перезапускать образ докера.
Вы также можете заметить, что в приведенном выше сценарии я подключаю порт 80 в контейнере к порту 8081 на моем компьютере. Для машины-жертвы я подключил порт 80 в контейнере к порту 8080, чтобы убедиться, что каждый докер-контейнер может независимо связываться с моей машиной.
Затем, открыв адреса http: // localhost: 8080 и http: // localhost: 8081, я смог убедиться, что каждый из них работает должным образом.
А теперь самое интересное, Жертва.
Сервер жертвы:
Здесь вы можете увидеть атаку XSS, встроенную в теги скрипта, а также базовую форму входа в DOM. Без тегов сценария DOM будет обрабатывать весь вход в систему и с радостью отправлять данные формы в login.php. Однако атака XSS перехватывает отправку форм, добавляет POST к удаленному серверу, а затем имитирует обычное событие формы для завершения атаки. Единственное отличие, которое может заметить средний пользователь, - это преднамеренная задержка в 1 секунду при отправке формы, чтобы позволить POST завершить.
(Остальные компоненты сервера жертвы вообще не стоит упоминать, все файлы можно найти и скачать на GitHub, для особо любопытных).
Сервер злоумышленника - База данных:
Сервер злоумышленника потребовал немного больше работы. Во-первых, мне нужно сохранить все полученные нажатия клавиш в базе данных. Из-за масштабов проекта простая база данных SQLite была самым простым вариантом.
composer.json:
{
"autoload": {
"psr-4": {
"App\\": "app/"
}
}
}
В файле композитора я сопоставил пространство имен App с каталогом приложения. Потом побежал:
composer update
и добавил:
<?php require 'vendor/autoload.php';
на страницу index.php.
Оттуда мне нужно было подключиться к файлу базы данных sqlite в каталоге db в корне проекта. Для этого я создал новый файл PHP с именем Config.php внутри каталога приложения:
И создал класс подключения к базе данных с именем SQLiteConnection и добавил его в тот же каталог:
Здесь вы можете видеть, что соединение использует синглтон для подключения к базе данных, чтобы гарантировать, что в любой момент времени существует только один экземпляр соединения.
Затем мне нужно было создать таблицы в базе данных, в которых будут сохраняться все нажатия клавиш. (Небольшое примечание перед тем, как продолжить, я был очень ленив в дизайне своей базы данных, так как это был PoC. Любой уважающий себя разработчик должен найти время, чтобы правильно сопоставить datetime с JavaScript на PHP и SQL, но в этом случае я этого не сделал. т, потому что я действительно должен заниматься другими делами…).
Следующий класс используется для создания базовой таблицы при запуске приложения:
И, наконец, последний класс, необходимый для простого взаимодействия с базой данных, - это класс вставки:
В методе вставки вы также можете заметить, что один из параметров включает объект журнала, который используется для простого сопоставления ответов жертвы с доступным форматом для вставки.
После того, как все эти компоненты были введены в каталог приложения проекта, я запустил:
composer dump-autoload -o
для сопоставления каждого из классов с их пространством имен через файл composers autoload.php.
Сервер злоумышленника - Получатель журнала ключей:
Чтобы получать нажатия клавиш от жертвы, мне нужно было иметь конечную точку, которая могла бы принимать полученные данные и сохранять их в базе данных. Здесь находится файл keylogger.php:
Здесь мы видим, что если параметры данных ‘keys’ и ‘datetime’ переданы, страница установит соединение с сервером, создаст новый объект журнала и вставит его на сервер. Простой!
Интерфейс атакующего:
Для некоторого чутья я хотел создать этот проект, чтобы при посещении корневого каталога сервера злоумышленника нажатия клавиш и данные формы жертвы были общедоступны для всеобщего обозрения. Это все, что потребовалось:
Этот файл просто обращается к базе данных, извлекает все доступные записи и отображает их в простой таблице HTML.
Результаты:
Когда оба проекта будут завершены и запущены, перейдите на сервер жертвы и войдите в систему со следующими данными:
Имя пользователя: admin
Пароль: c0mpl1c @ t3dp4ss
После входа в систему откройте окно злоумышленников и обновите страницу. Там вас встретят с данными, которые вы только что ввели, независимо от того, скопировали ли вы и вставили, или если автозаполнение добавило имя пользователя.
Проблемы:
Кейлоггер, хотя и может предоставить вам множество подробностей о том, как пользователь взаимодействует со страницей, не может фильтровать информацию. Например, основываясь на изображении выше, вы не сможете сразу сказать, какая из этих строк привела к успешному входу в систему. Возможно, в следующей итерации можно будет проверить учетные данные перед отправкой, но это может привести к более длительной задержке входа в систему, что может сбить с толку пользователя. На данный момент я считаю, что этого достаточно, чтобы продемонстрировать некоторые потенциальные опасности, связанные с возможностью межсайтового скриптинга на веб-сайте.
