Кавычка

2021-09-21 14:53:43 Параметры можно передавать не только в виде привычного Query, типа:

site/path?param=123¶m2=456

Есть такая штука, называется Path-Style Parameter Expansion (или Matrix в Spring).
Выглядит это подобным образом:

site/path;param=123;param2=456

Главное отличие, что Path Parameters можно передавать к конкретному пути, в то время как query применяется к запросу в целом:

site/user;id=123/send;message=456/?page=789


Так вот, в Tomcat/Jetty знак ; укажет, что дальше идут эти параметры до следующего символа /. А если впереди стоит nginx/apache, то символ для него ничего не значит, это будет просто частью имени директории.

Таким образом, обращение на условный /doc/..;abc=def/manager приведет к тому, что Tomcat обратится к
/doc/../manager, то есть выйдет из текущего сервлета и обратится к manager (админка tomcat).

P.S. Я всегда думал, что ; для Java, это что-то вроде нульбайта, который обрезает строку (в weblogic, кстати, обрезается вся строка). Но GreenDog (можно познакомиться с ним у МимоКрокодила) мне рассказал, откуда корни растут.

P.P.S. Еще по теме, Orange Tsai с примерами на BlackHat (с 40й страницы) Открыть/Комментировать

2021-05-27 13:37:01 В ASP.NET есть удобная олдскульная фича - cookieless session. Она осталась ещё с тех времён, когда куки поддерживались не всеми браузерами и сессию приходилось передавать внутри URL.

Например, http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/default.aspx

При использовании Control.ResolveUrl метода, это значение может выводится без корректного энкодинга символов, что может давать нам XSS-ку:


+
http://example.com/(A(%22onerror=%22alert`1`%22))/default.aspx

->



Более подробно об этой особенности и эксплуатации можно почитать ТУТ

Кроме того, эту фичу можно использовать для обхода ограничений на реверс прокси к админке приложения бэкэнда (всё что начинается с “/admin”), например:

http://victim.com/admin - 403
http://victim.com/(A(ABCD))/admin - 200

Работает в .NET 2.0-4.8. В .NET Core всех версий и в .NET5 это не поддерживается. Открыть/Комментировать

2021-05-21 13:37:01 Нет, сам Binance взламывать не надо. Для торгов там не нужен пароль, достаточно API Key, который не привилегирован на вывод средств.
Нужно просто собрать пароли, сделав сервис по аналитике, торговле, форум по интересам или заработку. На примере выше - информационный ресурс по алгоритмической торговли на binance. Фреймворк по-умолчанию хранит все пароли в хэшах, но администратору достаточно немного изменить код.
Пароли и так уже бич 21 века, люди слишком ленивые, чтобы использовать их разные.

Разные ресурсы - разные пароли. Двухфакторка может не спасти. С пятницей! Открыть/Комментировать

2021-05-21 13:37:01 Я вопреки обществу был противником сокрытия информации. Зачем скрывать почту или номер телефона, если это штуки, которые специально созданы для того, чтобы их шарить и это не может быть секретом? А сейчас осознаю, что было бы неплохо иметь обфусцированный номер телефона, который можно было бы убить как, например, алиасы на почте (виртуальные номера не в счет).
Там где тобой заинтересованы - практически нет препятствий для атаки.

А пароли вообще должны умереть. Sergey Belove опубликовал размышление о том, что если пароли умрут, это всё равно не спасёт от угона аккаунта, а второй фактор - не панацея.

Возьмем, например, Binance. Это крупнейшая криптобиржа, операции надо подтверждать через код с почты и через двухфакторку. А вот эту самую двухфакторку обходят (даже есть специализированные сервисы, которые за процент снимают бабло). Я относился к этому скептически, пока у друга так не вывели деньги (обошли Google Authenticator). Открыть/Комментировать

2021-05-17 13:37:01 Но не все знают, что можно вызвать /app_dev.php/_configurator, который запустит установку движка (оно тебе надо?).
Если этот контроллер доступен, интереснее вызвать сразу последнюю страницу /app_dev.php/_configurator/final, который покажет текущий конфиг сайта. Открыть/Комментировать

2021-05-17 13:37:01 В фреймворке Symfony иногда не отключают профайлер, который может помочь получить различную техническую информацию о целевой системе. Находится он в роуте app_dev.php. Открыть/Комментировать

2021-03-29 11:38:28 Вчера в официальном репозитории PHP на Github появилось два бэкдора, позволяющие выполнять произвольный код.
Что произошло - неясно. Однако разработчики сообщают о возможной компрометации git.php.net.

Дело точно не во взломанных аккунтах разработчиков. А user-agent “zerodium” и “sold to zerodium, mid 2017”, кагбе, намекает Открыть/Комментировать

2021-03-26 13:37:27 Оффенсивы приходят, разламывают и пишут об этом посты. Дефенсивы бегают в огне, придумывают фиксы и ничего, обычно, не рассказывают, так как держат в уме “ну вот сделаем хорошо, тогда и расскажем!”

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

Веб был не для дефенсивов с самого его начала и все жутко, жутко плохо в самой его сущности. Самую базовую операцию - аутентификацию пользователя, мы не умеем делать даже в 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, придумали как логинить юзера, а как разлогинить - чет нет. Ммм, что же делать, что же делать...

Рассказывать и делиться больше, даже если что-то еще сделано неидеально. Всех с пятницей! Открыть/Комментировать

2021-02-17 13:37:01 Bitnami - это библиотека популярных серверных приложений и сред разработки, которая используется для быстрого развертывания готовой среды. Часто можно увидеть, как разработчики ставят docker именно из этой библиотеки.

Если у вас где-то в docker-compose используется bitnami/laravel:latest, по умолчанию APP_KEY в нем будет браться из образа докера, который несмотря на то, что часто меняется с каждой версией контейнера - все еще предсказуем. Ведь достаточно собрать из образов ключи за последние N времени и попробовать раскодировать cookie с помощью ключа.

Помимо прочего, переменные окружения передаются на PHP, поэтому наличие функции phpinfo ведет к раскрытию информации ключей AWS, данных к СУБД, почты и конечно же к APP_KEY. Открыть/Комментировать

2021-02-04 13:37:38 И так, еще один интересный кейс.

Представьте себе... Reflected XSS via File Upload.

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

Вспомним, нам нужно заставить пользователя открыть страницу, после из JS создать на странице форму с уже подставленным файлом, и после перенаправить его на уязвимую страницу вместе с загруженными данными. В этом случае нам ни как не помогут ни XMLHttpRequest, ни fetch, о которых вы сначала могли подумать.

В чем ключевая проблема? До недавнего времени вообще не было возможным подставить в поле input произвольный объект файла из кода JS.

Для содержания файлов объект input имеет поле input.files, которое представляет собой объект FileList. И до какого-то времени мы не могли его изменять (он считался immutable) и создавать кастомные FileList объекты, кроме возможности изменять его через объекты полученные из события DataTransferEvent (Т.е. когда юзер сам перетаскивал файлы на экран). Но в 17 году ребята обнаружили возможность вызывать конструктор объекта DataTransfer , который порождает изменяемый объект FileList, который мы можем наполнить своими произвольными файлами из кода JS!!!

Пример эксплоита для такой уязвимости:

"/>

Надеюсь пригодится! Мне пригодилось;) Открыть/Комментировать