Всем привет
Сегодня у нас на обзоре стиллер stealc который продаётся вот здесь
Со мной связался один из пользователей данного продукта и попросил сделать на него обзор, предоставив билд и админку
У меня на руках:
- web.zip (Архив с админкой)
- install.sh (Скрипт для установки админки)
- Build.exe (Собранный на мою админку билд)
Удивило то, что автор даёт клиенту баш скрипт для установки панели
На дворе конец 2023 года, пора бы уже начать осваивать докер, это в разы стабильнее чем пляска с кастомными установщиками, зависимыми от ОС на борту
Я передал своему сисадмину файлы админки для установки и тем временем отправился изучать содержимое архива web.zip
Админка написана на голом PHP, для связи с базой данных используется PDO, в каждой папке стоят заглушки index.php чтобы содержимое директорий используемых админкой нельзя было прочитать
Написано всё, само собой, в процедурном стиле и в связи с этим код выглядит как каша
Автор не слышал про принцип единой ответственности, более того, архитектура админки отсутствует как таковая, такое ощущение, что её разработкой занимался не веб программист, а "вебмастер" из 2010 года
Ладно, админка установлена, заходим внутрь и видим авторизацию:
Вводим пароль, попадаем внутрь панели. Выглядит она вот так:
Сразу подмечу пару вещей, которые бросились в глаза:
1) Интерфейс хорошо спроектирован, всё на своих местах, это круто, но он не очень понятен. Автору нужно поработать над тем, чтобы было понятно, какая опция в интерфейсе за что отвечает
2) Текст маленькими буквами, в паре таблиц присутствуют поля "rule_id", "loader_id" и т.д. Выглядит сыро, лично мне непонятно, зачем так называть поля, можно же написать человеческое название
Ради интереса попробовал исполнить жс код, добавив
в несколько полей, и к моему удивлению код отработал везде:
После этого я окончательно загорелся идеей найти возможность слива инсталлов с панели
Как вы можете заметить, во вкладке Logs у каждого лога в таблице есть кнопка с иконкой восклицательного знака
Там отображается информация о системе жертвы, её мы и попытаемся подменить
Как выяснилось в процессе реверса, стиллер получает версию ОС из реестра, читая поле ProductVersion по пути HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Вписываем туда тестовый ЖС код, который выведет алерт, и запускаем билд, после прихода лога открываем блок с системной информацией ииии.... всё отрабатывает!
Таким образом недоброжелатель может легко угнать инсталлы или просто удалить все логи клиенту этого стиллера
Для этого достаточно будет выловить билд на трекерах и достать из него адрес гейта, после чего можно спокойно слить логи, или же инсталлы
Автор был уведомлён об этой проблеме в первый день обнаружения уязвимости, поэтому я надеюсь, что на момент публикации обзора всё пофикшено
Общее мнение об админке:
Панель очень сырая, такое ощущение что автор никогда не кодил веб и делал её попутно изучая пхп по урокам на ютубе
Несмотря на неплохой визуальный вид, админка до ужаса кривая. Пользоваться этим не безопасно, у вас сольют инсталлы или логи
Это всё нужно переделывать с полного нуля, делать нормальную архитектуру, юзать ORM, шаблонизаторы и т.д. Я бы советовал автору нанять нормального веб разработчика, если сам он не умеет кодить веб
Поставлять такую админку вместе со стиллером недопустимо, это полное неуважение к клиентам которые могут попасть на круглую сумму из за некомпетентности кодера
Переходим к осмотру билда в статике
У меня на руках нативный х86 PE файл весом 100 кб, в таблице импорта присутствуют только некоторые функции из msvcrt и lstrcatA
Внутри видно много base64 строк, есть строки и в открытом виде, которые являются мусорными. Скорее всего аверы кинут статический детект на них
Присутствуют 4 секции:
- Секция кода
- Секция данных
- Секция ресурсов
- Релоки
TLS и прочих особенностей файл не имеет, так что трудностей с его криптом возникать не должно
Переносим файл в IDA и декомпилируем, попадаем на точку входа. Перед тем, как писать этот обзор, я полностью отреверсил билд, изучил его логику, восстановил импорт и дешифровал строки, поэтому вы можете лицезреть псевдокод в более-менее читаемом виде
Начинаем с decrypt_strings. Инициализируется глобальная переменная, которая содержит в себе ключ для дешифрования зашифрованных строк
Как вы видите, в основном это названия апи функций для последующего динамического импорта и строки, касающиеся проверки на запуск в ВМ
Строки шифруются по схеме base64(rc4(string)), rc4 ключ для моего билда выглядит как строка из 28 цифр, пример: 4597014127588130917345308199, он лежит в секции данных в открытом виде
В функции, которая выполняет декрипт строки имеется утечка памяти, память выделенная через malloc не освобождается, так же не освобождается память, выделенная под хранение этих строк
Так же внутри функции шифрования RC4 было обнаружено вот такое:
Видимо, это приватный слой обфускации. Если серьёзно, я не понял, зачем добавлять лишнюю сигнатуру к билду и трешгенить в собственном коде
Далее происходит импорт API, в начале функции первым делом получается адрес kernel32.dll:
Здесь есть небольшая загвоздка, позиция базы этой библиотеки в списке вшита в код, следовательно если данный стиллер закриптуют криптором написанном на .NET, то будет облом, поскольку в списке перед ntdll будет присутствовать mscoree
Следовательно, вместо адреса kernel32 будет получен адрес ntdll и далее последует краш, ведь возвращаемый функциями результат никак не валидируется
Далее с помощью собственной реализации GetProcAddress получается адрес GetProcAddress из kernel32.dll и уже используя её получаются адреса остальных апи функций
Мне не до конца понятно, зачем нужны эти танцы с бубном, ведь можно реализовать поддержку import forwarding в собственной GetProcAddress и не плодить кучу одинакового кода
Далее происходит проверка на запуск на територии СНГ, получается идентификатор UI системы и сравнивается с некоторыми значениями, после чего в случае совпадения происходит завершение работы
Следом у нас "приватный" метод детекта виртуальных машин. Если название ПК HAL9TH, а название юзера JohnDoe, происходит завершение работы программы
Потом формируется строка формата HAL9TH_computername_username, она будет использоваться в качестве названия ивента, по которому стиллер отслеживает, не запущена ли ещё одна его копия в данный момент
В моём случае сформировалась строка HAL9TH_TestPC_User, далее в цикле со слипом в 6 секунд вызывается функция OpenEventA и производится проверка, вышло ли открыть ивент. Если не вышло, засыпает. Если вышло - выходит из цикла.
После окончания цикла создаётся ивент с таким названием, проверяется активна ли подписка на стиллер и вызывается основная функция, которая содержит в себе основную логику билда
Кратко о том, как работает система подписки. Стиллер не зависит от сервера разработчика, в билд вшита дата окончания подписки, если текущая дата позднее даты окончания подписки, работа софта завершается
Учитывая то что код не обфусцирован вообще, это плохое решение, так как система лицензирования легко отключается любым человеком с минимальными познаниями в ассемблере
Подмечу, что большинство апишек на скриншотах выше и в целом по стиллеру вызываются без проверок возвращаемого результата, поэтому если что то пойдёт не так, последствия могут быть самыми непредсказуемыми, от завершения работы (краша) до мусора в логе
Вот главная функция стиллера, в которой и хранится вся основная логика:
Я не буду обьяснять весь её код, кратко пробежимся по интересному
Производится очередное дешифрование строк и получение апи. Логика такая же как и раньше, только дешифруется другой набор строк и получаются адреса других апи функций
Вот скриншоты этих функций:
Как вы видите, здесь дешифруется намного больше строк. Меньшая часть из них содержит названия апи функций, а большая напрямую относится к работе стиллера: Адрес админки, гейта, SQL запросы, маски поиска файлов и т.д
В начале функции мы видим три строки с условными обозначениями str_panel_address, str_gate_address, str_libs_folder, str_build_tag
Это и есть конфиг стиллера, подменив который можно перенаправить запросы на свою панель
Сравнив несколько билдов можно заметить, что ключ шифрования строк отличается, поэтому я могу предположить что процесс генерации "боевого" билда производится в автоматическом либо полуавтоматическом режиме (иными словами, с помощью билдера)
Далее происходит сбор лога и отправка его на сервер по частям. Рассматривать детально этот момент мы не будем, я его опишу кратко
В програмдату с сервера скачиваются x64 DLL библиотеки, которые, как я понял, нужны для дешифровки паролей из браузеров на базе движка Gecko (Firefox и прочие)
Оттуда же загружается sqlite3.dll, с помощью которой будет производиться доступ к SQLite БД браузеров
Начинается рекурсивный перебор файлов с помощью FindFirstFileA - FindNextFileA, если файл подходит под требования, он загружается на сервер хттп запросом
Хочу подметить, что файл загружается на сервер одним вызовом HttpSendRequest и размер файла не проверяется перед загрузкой, на этом моменте может возникнуть краш программы
После того, как все данные собраны и отправлены на сервер, проверяется, установлено ли значение константы, именуемое в псевдокоде как v31
Если v31 == 1, производится очистка програмдаты и самоудаление посредством выполнения cmd команд. Почему автор не реализовал это програмно - загадка для меня, ведь я уверен, что на этом месте есть/будет детект от некоторых АВ
Общее мнение о билде:
Видно, что у автора нет опыта в системном программировании
В коде не проверяется результат выполнения функций, поэтому control flow может пойти не туда, выполнение программы сломается
Автор не слышал про принцип единой ответственности, некоторые функции выполняют несколько задач одновременно, код перегружен
Не поддерживаются юникод, стиллер либо не отработает в юникод среде, либо при соблюдении некоторых условностей отработает, но не полностью
Ошибки детские, мне было бы стыдно выкатывать такой софт. Я не спорю, что он работает и даже приносит людям прибыль, но такие ошибки ведут к просадкам в отстуке и впоследствии потере потенциальной прибыли
Теперь протестируем работоспособность билда
Я написал своим тестировщикам и попросил их прогнать билд на всех ОС, начиная с Windows 7 и 2008 сервера до последних билдов 11 и Server 2022
Результаты меня немного огорчили, билд отработал нестабильно, получилась вот такая картинка:
Windows 7 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows 8 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью + лоадер криво скачал файл, ещё одна ошибка
Windows 8.1 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows 10 - отстучал, проблем не наблюдается
Windows 11 - отстучал, проблем не наблюдается (в админке распознало как Windows 10 PRO)
Windows Server 2008 - отстучал, проблем не наблюдается
Windows Server 2012 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows Server 2016 - отстучал, проблем не наблюдается
Windows Server 2019 - отстучал, проблем не наблюдается
Windows Server 2022 - отстучал, проблем не наблюдается
Как я и ожидал ошибка возникла на этапе загрузки библиотек, связанных с дешифровкой паролей из ФФ
На х86 системах (хоть их и мало, я беру их в счёт, так как стиллер скомпилирован под х86) пароли из ФФ собраны не будут, поскольку с сервера загружаются х64 библиотеки для работы с этим браузером
Лог выглядит вот так:
Внутри лога всё структурировано, сделано нормально. Но насторожило то что в отдельном файле под названием copyright.txt содержится реклама стиллера:
Итого:
Стиллер мне не понравился, билд нестабилен и содержит много глупых ошибок, которые неприемлемо допускать человеку, называющемому себя кодером
Отсутствие поддержки юникода, нестабильность работы и много проблемных мест в коде полностью испортили впечатления от данного продукта
Админка уязвима к XSS, строки в панели не фильтруются вообще
Под конец написания данного обзора я пообщался с кодером продукта, который сказал мне, что отсутствие поддержки юникода в паблик билдах данного стиллера - защита от работы стиллера по РУ, а ошибки связанные с подгрузом длл для ФФ связаны с отсутствием CRT на моих тестовых стендах))
Я считаю, что автору софта нужно подтянуть свой скилл, а уже только потом продавать стиллеры на этом форуме
P.S: Если вы хотите обзор на конкретный софт, не стесняйтесь скидывать билды в личные сообщения, обзор полностью анонимен и автор продукта не узнает о том, кто предостаил билд
Статья написана coder специально для площадки xss.pro
Сегодня у нас на обзоре стиллер stealc который продаётся вот здесь
Со мной связался один из пользователей данного продукта и попросил сделать на него обзор, предоставив билд и админку
У меня на руках:
- web.zip (Архив с админкой)
- install.sh (Скрипт для установки админки)
- Build.exe (Собранный на мою админку билд)
Удивило то, что автор даёт клиенту баш скрипт для установки панели
На дворе конец 2023 года, пора бы уже начать осваивать докер, это в разы стабильнее чем пляска с кастомными установщиками, зависимыми от ОС на борту
Я передал своему сисадмину файлы админки для установки и тем временем отправился изучать содержимое архива web.zip
Админка написана на голом PHP, для связи с базой данных используется PDO, в каждой папке стоят заглушки index.php чтобы содержимое директорий используемых админкой нельзя было прочитать
Написано всё, само собой, в процедурном стиле и в связи с этим код выглядит как каша
Автор не слышал про принцип единой ответственности, более того, архитектура админки отсутствует как таковая, такое ощущение, что её разработкой занимался не веб программист, а "вебмастер" из 2010 года
Ладно, админка установлена, заходим внутрь и видим авторизацию:
Вводим пароль, попадаем внутрь панели. Выглядит она вот так:
Сразу подмечу пару вещей, которые бросились в глаза:
1) Интерфейс хорошо спроектирован, всё на своих местах, это круто, но он не очень понятен. Автору нужно поработать над тем, чтобы было понятно, какая опция в интерфейсе за что отвечает
2) Текст маленькими буквами, в паре таблиц присутствуют поля "rule_id", "loader_id" и т.д. Выглядит сыро, лично мне непонятно, зачем так называть поля, можно же написать человеческое название
Ради интереса попробовал исполнить жс код, добавив
JavaScript:
<script>alert('xss');</script>После этого я окончательно загорелся идеей найти возможность слива инсталлов с панели
Как вы можете заметить, во вкладке Logs у каждого лога в таблице есть кнопка с иконкой восклицательного знака
Там отображается информация о системе жертвы, её мы и попытаемся подменить
Как выяснилось в процессе реверса, стиллер получает версию ОС из реестра, читая поле ProductVersion по пути HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Вписываем туда тестовый ЖС код, который выведет алерт, и запускаем билд, после прихода лога открываем блок с системной информацией ииии.... всё отрабатывает!
Таким образом недоброжелатель может легко угнать инсталлы или просто удалить все логи клиенту этого стиллера
Для этого достаточно будет выловить билд на трекерах и достать из него адрес гейта, после чего можно спокойно слить логи, или же инсталлы
Автор был уведомлён об этой проблеме в первый день обнаружения уязвимости, поэтому я надеюсь, что на момент публикации обзора всё пофикшено
Общее мнение об админке:
Панель очень сырая, такое ощущение что автор никогда не кодил веб и делал её попутно изучая пхп по урокам на ютубе
Несмотря на неплохой визуальный вид, админка до ужаса кривая. Пользоваться этим не безопасно, у вас сольют инсталлы или логи
Это всё нужно переделывать с полного нуля, делать нормальную архитектуру, юзать ORM, шаблонизаторы и т.д. Я бы советовал автору нанять нормального веб разработчика, если сам он не умеет кодить веб
Поставлять такую админку вместе со стиллером недопустимо, это полное неуважение к клиентам которые могут попасть на круглую сумму из за некомпетентности кодера
Переходим к осмотру билда в статике
У меня на руках нативный х86 PE файл весом 100 кб, в таблице импорта присутствуют только некоторые функции из msvcrt и lstrcatA
Внутри видно много base64 строк, есть строки и в открытом виде, которые являются мусорными. Скорее всего аверы кинут статический детект на них
Присутствуют 4 секции:
- Секция кода
- Секция данных
- Секция ресурсов
- Релоки
TLS и прочих особенностей файл не имеет, так что трудностей с его криптом возникать не должно
Переносим файл в IDA и декомпилируем, попадаем на точку входа. Перед тем, как писать этот обзор, я полностью отреверсил билд, изучил его логику, восстановил импорт и дешифровал строки, поэтому вы можете лицезреть псевдокод в более-менее читаемом виде
Начинаем с decrypt_strings. Инициализируется глобальная переменная, которая содержит в себе ключ для дешифрования зашифрованных строк
Как вы видите, в основном это названия апи функций для последующего динамического импорта и строки, касающиеся проверки на запуск в ВМ
Строки шифруются по схеме base64(rc4(string)), rc4 ключ для моего билда выглядит как строка из 28 цифр, пример: 4597014127588130917345308199, он лежит в секции данных в открытом виде
В функции, которая выполняет декрипт строки имеется утечка памяти, память выделенная через malloc не освобождается, так же не освобождается память, выделенная под хранение этих строк
Так же внутри функции шифрования RC4 было обнаружено вот такое:
Видимо, это приватный слой обфускации. Если серьёзно, я не понял, зачем добавлять лишнюю сигнатуру к билду и трешгенить в собственном коде
Далее происходит импорт API, в начале функции первым делом получается адрес kernel32.dll:
Здесь есть небольшая загвоздка, позиция базы этой библиотеки в списке вшита в код, следовательно если данный стиллер закриптуют криптором написанном на .NET, то будет облом, поскольку в списке перед ntdll будет присутствовать mscoree
Следовательно, вместо адреса kernel32 будет получен адрес ntdll и далее последует краш, ведь возвращаемый функциями результат никак не валидируется
Далее с помощью собственной реализации GetProcAddress получается адрес GetProcAddress из kernel32.dll и уже используя её получаются адреса остальных апи функций
Мне не до конца понятно, зачем нужны эти танцы с бубном, ведь можно реализовать поддержку import forwarding в собственной GetProcAddress и не плодить кучу одинакового кода
Далее происходит проверка на запуск на територии СНГ, получается идентификатор UI системы и сравнивается с некоторыми значениями, после чего в случае совпадения происходит завершение работы
Следом у нас "приватный" метод детекта виртуальных машин. Если название ПК HAL9TH, а название юзера JohnDoe, происходит завершение работы программы
Потом формируется строка формата HAL9TH_computername_username, она будет использоваться в качестве названия ивента, по которому стиллер отслеживает, не запущена ли ещё одна его копия в данный момент
В моём случае сформировалась строка HAL9TH_TestPC_User, далее в цикле со слипом в 6 секунд вызывается функция OpenEventA и производится проверка, вышло ли открыть ивент. Если не вышло, засыпает. Если вышло - выходит из цикла.
После окончания цикла создаётся ивент с таким названием, проверяется активна ли подписка на стиллер и вызывается основная функция, которая содержит в себе основную логику билда
Кратко о том, как работает система подписки. Стиллер не зависит от сервера разработчика, в билд вшита дата окончания подписки, если текущая дата позднее даты окончания подписки, работа софта завершается
Учитывая то что код не обфусцирован вообще, это плохое решение, так как система лицензирования легко отключается любым человеком с минимальными познаниями в ассемблере
Подмечу, что большинство апишек на скриншотах выше и в целом по стиллеру вызываются без проверок возвращаемого результата, поэтому если что то пойдёт не так, последствия могут быть самыми непредсказуемыми, от завершения работы (краша) до мусора в логе
Вот главная функция стиллера, в которой и хранится вся основная логика:
Я не буду обьяснять весь её код, кратко пробежимся по интересному
Производится очередное дешифрование строк и получение апи. Логика такая же как и раньше, только дешифруется другой набор строк и получаются адреса других апи функций
Вот скриншоты этих функций:
Как вы видите, здесь дешифруется намного больше строк. Меньшая часть из них содержит названия апи функций, а большая напрямую относится к работе стиллера: Адрес админки, гейта, SQL запросы, маски поиска файлов и т.д
В начале функции мы видим три строки с условными обозначениями str_panel_address, str_gate_address, str_libs_folder, str_build_tag
Это и есть конфиг стиллера, подменив который можно перенаправить запросы на свою панель
Сравнив несколько билдов можно заметить, что ключ шифрования строк отличается, поэтому я могу предположить что процесс генерации "боевого" билда производится в автоматическом либо полуавтоматическом режиме (иными словами, с помощью билдера)
Далее происходит сбор лога и отправка его на сервер по частям. Рассматривать детально этот момент мы не будем, я его опишу кратко
В програмдату с сервера скачиваются x64 DLL библиотеки, которые, как я понял, нужны для дешифровки паролей из браузеров на базе движка Gecko (Firefox и прочие)
Оттуда же загружается sqlite3.dll, с помощью которой будет производиться доступ к SQLite БД браузеров
Начинается рекурсивный перебор файлов с помощью FindFirstFileA - FindNextFileA, если файл подходит под требования, он загружается на сервер хттп запросом
Хочу подметить, что файл загружается на сервер одним вызовом HttpSendRequest и размер файла не проверяется перед загрузкой, на этом моменте может возникнуть краш программы
После того, как все данные собраны и отправлены на сервер, проверяется, установлено ли значение константы, именуемое в псевдокоде как v31
Если v31 == 1, производится очистка програмдаты и самоудаление посредством выполнения cmd команд. Почему автор не реализовал это програмно - загадка для меня, ведь я уверен, что на этом месте есть/будет детект от некоторых АВ
Общее мнение о билде:
Видно, что у автора нет опыта в системном программировании
В коде не проверяется результат выполнения функций, поэтому control flow может пойти не туда, выполнение программы сломается
Автор не слышал про принцип единой ответственности, некоторые функции выполняют несколько задач одновременно, код перегружен
Не поддерживаются юникод, стиллер либо не отработает в юникод среде, либо при соблюдении некоторых условностей отработает, но не полностью
Ошибки детские, мне было бы стыдно выкатывать такой софт. Я не спорю, что он работает и даже приносит людям прибыль, но такие ошибки ведут к просадкам в отстуке и впоследствии потере потенциальной прибыли
Теперь протестируем работоспособность билда
Я написал своим тестировщикам и попросил их прогнать билд на всех ОС, начиная с Windows 7 и 2008 сервера до последних билдов 11 и Server 2022
Результаты меня немного огорчили, билд отработал нестабильно, получилась вот такая картинка:
Windows 7 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows 8 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью + лоадер криво скачал файл, ещё одна ошибка
Windows 8.1 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows 10 - отстучал, проблем не наблюдается
Windows 11 - отстучал, проблем не наблюдается (в админке распознало как Windows 10 PRO)
Windows Server 2008 - отстучал, проблем не наблюдается
Windows Server 2012 - ошибка спустя 5 секунд работы билда, в админку отстучал, пароли собраны не полностью
Windows Server 2016 - отстучал, проблем не наблюдается
Windows Server 2019 - отстучал, проблем не наблюдается
Windows Server 2022 - отстучал, проблем не наблюдается
Как я и ожидал ошибка возникла на этапе загрузки библиотек, связанных с дешифровкой паролей из ФФ
На х86 системах (хоть их и мало, я беру их в счёт, так как стиллер скомпилирован под х86) пароли из ФФ собраны не будут, поскольку с сервера загружаются х64 библиотеки для работы с этим браузером
Лог выглядит вот так:
Внутри лога всё структурировано, сделано нормально. Но насторожило то что в отдельном файле под названием copyright.txt содержится реклама стиллера:
Итого:
Стиллер мне не понравился, билд нестабилен и содержит много глупых ошибок, которые неприемлемо допускать человеку, называющемому себя кодером
Отсутствие поддержки юникода, нестабильность работы и много проблемных мест в коде полностью испортили впечатления от данного продукта
Админка уязвима к XSS, строки в панели не фильтруются вообще
Под конец написания данного обзора я пообщался с кодером продукта, который сказал мне, что отсутствие поддержки юникода в паблик билдах данного стиллера - защита от работы стиллера по РУ, а ошибки связанные с подгрузом длл для ФФ связаны с отсутствием CRT на моих тестовых стендах))
Я считаю, что автору софта нужно подтянуть свой скилл, а уже только потом продавать стиллеры на этом форуме
P.S: Если вы хотите обзор на конкретный софт, не стесняйтесь скидывать билды в личные сообщения, обзор полностью анонимен и автор продукта не узнает о том, кто предостаил билд
Статья написана coder специально для площадки xss.pro
Последнее редактирование:
