🙁 Хейт убивает open-source

Сегодня наткнулся на историю разработчика, который из-за одного токсичного письма решил закрыть свой проект "LDAP Client and Server API for node.js". Репозиторий годами поддерживался на энтузиазме и рефакторился, пока аноним не прислал угрозы из-за "неудобного API".

Open-source держится на людях, которые тратят своё время за бесплатно. Критикуйте конструктивно, предлагайте помощь или просто скажите "спасибо". Если проект заморожен — форкните и доработайте.

🔗 Ссылка на репозиторий GitHub

#github

🗣 Всем привет!

Как вы уже могли заметить, в сторисы канала я скидываю мемы на тему ИБ. Если у вас есть, чем поделиться (желательно на тему offensive в формате видео, но фото тоже приветствуется), присылайте в предложку — @hackerbiker_memes_bot. Самые интересные и приемлемые буду публиковать в сторис канала.

Мемы в формате .exe не присылайте, могу не удержаться

📕 RAD COP на PHD

Пришли небольшим коллективом из круга хакеров на Positive Hack Days. Если хотите познакомиться, обсудить крутые кейсы или просто поболтать за кофе, пишите в личку или в комменты. Будем рады пообщаться!

Пользуясь случаем, хочу сказать, мой хороший коллега на фотке на днях сдал CEH (Certified Ethical Hacker). Если хотите его поздравить с новым сертификатом, то напишите приятные слова в комментариях под его постом, ему будет приятно😁

😈 Ержан, вставай!

Давно не было разбора атак на моих проектах. Время исправляться, есть интересная находка. Впервые на проекте нашёл вектора для DoS-атаки, так еще и первая на практике критическая уязвимость.

Конечные точки API для осуществления денежного перевода на вход в JSON-запросе принимают экспоненциальное значение (1e-1) и обрабатывают её, выдавая в ответе рассчитанную сумму с учётом комиссии. При увеличении количества нулей в экспоненте (1e-100...) возрастает время ответа от сервера. На обычные запросы это ~100 мс, после 300, 1000, 8000 и так далее. Наткнулся на такое значение экспоненты, при котором ответ с сервера я получаю через 60000 мс (стандартное ограничение в некоторых браузерах) с 504 HTTP ошибкой.

Решили с Заказчиком провести более глубокое исследование потенциального DoS под наблюдением за сервером. Выяснилось, что экспонента 1e-100000000 и подобные нагружают сервер до 30% при отправке очередью (при ожидании ответа на каждый запрос), когда в обычном состоянии нагрузка не выше 5%. Физически такое число практически равно нулю, но математически нет. Если код пытается его обрабатывать "честно" (например, переводя в дробь или делая арифметику с высокой точностью), это может создать огромную вычислительную нагрузку. Всё говорит о серьёзной проблеме, учитывая то, что это было проделано лишь с помощью одного устройства. А если это сделать в кооперации с другими устройствами? Нагрузка выйдет куда выше.

▎ Риски:
➡️Отказ в обслуживании: один запрос нагружает сервер до 30%, а координированная атака способна нанести более серьёзный урон;
➡️Финансовые потери: запросы связаны с платёжным API, в случае его отказа возможны сбои в транзакциях пользователей;
➡️Репутационный ущерб: нестабильность сервиса подрывает доверие пользователей.

▎ Рекомендации по устранению уязвимости:
✅Валидация входных данных: запрет экспоненциальной записи;
✅Лимиты на обработку чисел: установка максимальной точности (например, округление до 5 знаков после запятой). Timeout на обработку запроса (например, 1 сек), при которой сервер автоматически будет откидывать запросы, которые обрабатывает более установленного времени;
✅Защита от DoS/DDoS: пропускать не более, например, 100 запросов/мин с одного IP, иметь детекты на атаку с различных IP-адресов и отражать вредоносные запросы на сервер;
✅Мониторинг и логирование: алерты при резком росте нагрузки на CPU, логирование подозрительных запросов.

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

"1e-100000000" — это не число, а таймер до перезагрузки сервера.

#кейс

👨‍💻 Награждение Red Team на Standoff 15

😈 ПриветСнова%20

В этот чудесный день решил поделиться с вами забавной находкой на проекте, позволяющей повторно использовать номер телефона для регистрации и обходить блокировку по нему. Банальный пробел в URL-кодировке (%20) превращает номер в "нового пользователя"!

Система регистрирует аккаунты по номеру телефона, но не проверяет его корректность перед обработкой. Если даже к заблокированному в системе номеру (например, 79999999999) добавить пробел в виде %20, сервер воспримет это как новый номер (79999999999%20) и разрешит регистрацию. Также можно добавлять сколько угодно пробелов: 79999999999%20%20, 79999999999%20%20%20 и так далее. Для системы каждый такой вариант — уникальный аккаунт, хотя SMS-код всегда уходит на один и тот же номер.

Это как если бы вас не пускали в клуб по имени «Даффиер», но пропускали с тем же лицом, представившись «Даффиер%20».

▎ Риски:
➡️Обход блокировок: злоумышленник может продолжать использовать заблокированный номер, хоть и с новым аккаунтом в системе;
➡️Спам и злоупотребление: флуд SMS-сообщениями, создание тысяч "мусорных" аккаунтов;
➡️Захламление БД: дубликаты номеров, проблемы с аналитикой и чистотой данных.

▎ Рекомендация по устранению уязвимости:
✅Нормализация номера со строгой валидацией: удалять пробелы (регулярки в помощь)/спецсимволы до проверки на блокировку и регистрации нового аккаунта.

#кейс

🤨 Прямо из печи!

Нашёл для вас свежий материал по SSTI уязвимости: "Полное руководство по использованию расширенных серверных шаблонных внедрений" (на английском языке).

Серверный шаблонизатор — мощный инструмент, но без должных проверок ввода он становится оружием для атакующего. Многие до сих пор пропускают SSTI из-за сложностей в идентификации, хотя эксплуатация может привести к серьезным последствиям.

▎ Содержание:
➡️Почему SSTI так опасны;
➡️Как находить и использовать их в реальных сценариях;
➡️Сложные кейсы эксплуатации в разных шаблонизаторах.

🔗 Ссылка на полное руководство по SSTI

#материал