🕵️‍♂️ Crypto-челлендж

Сервис генерирует 6-значные одноразовые пароли (OTP) через линейный конгруэнтный генератор (LCG).
Вам удалось подсмотреть подряд три значения:

426197, 013582, 790341

Из документации известно:

— формула: X_{n+1} = (a * X_n + c) mod m
— параметры: a = 1103515245, c = 12345, m = 2^31
— итоговый OTP = X mod 1_000_000

➡️ Ваша задача — восстановить состояние генератора и предскажите следующий 6-значный OTP.

❓ Какое число следующее:

🔥 — ≈ 812907
👾 — ≈ 541220
❤️ — ≈ 019874
👍 — ≈ 377654

🐸 Библиотека хакера

#ctf_challenge

🕵️‍♂️ Разбор Crypto-челленджа

Раннее мы выкладывали задачу 📎

Мы дали вам три подряд кода OTP:

426197 → 013582 → 790341

и параметры LCG (a=1103515245, c=12345, m=2^31) с условием OTP = X mod 1_000_000.

❗️ При таких настройках такая последовательность невозможна. Это был намеренный подвох ☕️

Почему так:

— OTP часто берут не из «хвоста» числа (X % 1e6), а из старших бит или через доп. преобразования.

— Даже один лишний сдвиг полностью меняет результат.

⚡️ В криптографии и CTF важны не только формулы, но и детали реализации.

Следующая задача будет без подвоха, обещаем 🤟

🐸 Библиотека хакера

#ctf_challenge

🧩 Хакер-челлендж

На проде магазина замечают странные списания: одни пользователи платят дважды, у других приходит товар без списания. Вот фрагмент логов (время в ms).

❓ Что наиболее правдоподобно объясняет произошедшее, голосуйте эмодзи

🔥 — Неправильно реализован механизм идемпотентности: Idempotency-Key не проверяется глобально/атомарно (ключ принимается разными бекендами), из-за чего созданы две транзакции.

👾 — Race condition/несинхронизированное состояние между бэкендами: параллельные запросы обрабатываются разными экземплярами, каждый создал транзакцию до репликации/блокировки.

❤️ — Replay-атака: перехват и повторная отправка запроса с тем же ключом с других IP.

👍 — Интеграционный баг с платёжным провайдером: двойное создание транзакции на стороне провайдера или несогласованность статусов.

🐸 Библиотека хакера

#ctf_challenge

🔍 Разбор инцидента

Раннее мы выкладывали задачу 📎

В логах магазина видно два почти одинаковых запроса на оплату с одинаковым Idempotency-Key. Но обработаны они разными инстансами: один вернул статус processing, второй — paid. В итоге пользователю пришёл товар, но система зарегистрировала две транзакции.

➖ Что могло привести к ошибке:

1. 🔥 Неправильно реализована идемпотентность: проверка Idempotency-Key не выполняется централизованно или атомарно. Из-за этого два разных инстанса приняли один и тот же ключ и создали две транзакции. Это самая вероятная причина проблемы.

2. 👾 Race condition: параллельные запросы были обработаны разными инстансами, что привело к созданию двух транзакций до синхронизации состояния между ними.

3. ❤️ Replay-атака: маловероятно, потому что IP-адреса в логах разные. Хотя теоретически возможно, что запрос был повторно отправлен с тем же ключом.

4. 👍 Интеграционный баг с платёжным провайдером: это также возможно, но не является основной причиной. Провайдер зарегистрировал оба статуса, но ошибки на его стороне не столь очевидны.

Правильный ответ:

✅ Неправильно реализована идемпотентность: эта ошибка приводит к созданию двух транзакций с одинаковым ключом, так как проверка Idempotency-Key не была централизованной и атомарной, и запросы обработаны разными инстансами.

🐸 Библиотека хакера

#ctf_challenge

🧩 Хакер-челлендж

Сценарий: веб-сервис принимает бинарный объект (pickle/unsafe JSON), десериализует и сразу вызывает метод process() у полученного объекта. Пользователь может загрузить произвольный байтстрим.

❓ Что наиболее правдоподобно может произойти, если загрузить специально-сформированный объект? Голосуйте эмодзи:

🔥 — RCE: выполнить произвольный код на сервере (pickle позволяет инвокировать конструкторы/функции).

👾 — Эскалация привилегий: объект вызовет внутренний метод, открывающий админ-функции.

❤️ — DoS: CV-памяти/CPU через рекурсивные/тяжёлые объекты.

👍 — Утечка данных: объект инициирует исходящие запросы (exfiltration) и вернёт конфиденциальные данные.

🐸 Библиотека хакера

#ctf_challenge

👨‍💻 Разбор — «Опасная десериализация»

Раннее мы выкладывали задачу 🦾

Сервис десериализует входной байтстрим (pickle/unsafe JSON) и сразу вызывает obj.process(). Если вход ненадёжный — можно выполнить произвольный код на сервере.

🅰️ Почему опасно: десериализация восстанавливает объекты и может запускать их конструкторы или методы без проверки. Это открывает путь к RCE, утечке данных или DoS.

🅰️ Хотфикс: запретить бинарную десериализацию из внешних источников.

❇️ Долгосрочно: перейти на безопасный формат (JSON со схемой) или изолировать выполнение.

❇️ Главная угроза — RCE.

🐸 Библиотека хакера

#ctf_challenge