Ваш iPhone в состоянии AFU — и спецслужбы это знают
Когда телефон попадает в форензик-лабораторию, никого не интересует модель или версия iOS. Первый вопрос — вводил ли владелец пасскод хотя бы раз после последней перезагрузки. От ответа зависит всё: 95% данных или 5%.
➡️ Два криптографических состояния определяют судьбу вашей приватности:
BFU (Before First Unlock) — телефон перезагружен, пасскод не введён. Ключи шифрования заперты внутри Secure Enclave. Доступны только крохи: метаданные и системные файлы класса
AFU (After First Unlock) — пасскод введён хотя бы однажды. Криптографические ключи загружены в RAM и остаются там, даже если экран заблокирован. Сообщения, фото, геолокация, пароли Wi-Fi, токены авторизации, история браузера — всё открыто для инструмента экстракции.
Стандартный протокол изъятия прост: забрать телефон, положить в клетку Фарадея, поддерживать заряд и не дать устройству перезагрузиться. Пока iPhone в AFU — он уязвим.
Отдельная история — аппаратная уязвимость checkm8. Она затрагивает чипы A5–A11 (от iPhone 4S до iPhone X) и бьёт по BootROM — загрузчику, прошитому в кремний на заводе. Никакое обновление iOS это не исправит. На старых чипах без Secure Enclave можно снять полный физический дамп вообще без пасскода. На A7–A11 — обойти программный счётчик попыток и запустить офлайн-брутфорс. Cellebrite интегрировала этот эксплойт прямо в UFED.
На чипах A12+ (iPhone XS и новее) checkm8 не работает. Но это не значит, что новые iPhone неуязвимы в AFU. По имеющимся данным, Cellebrite UFED Premium способен извлечь полную файловую систему из AFU-устройств даже на новейших моделях. Точная матрица поддержки закрыта NDA.
🎇 Важный кейс из декабря 2024: Citizen Lab задокументировала установку шпионского ПО на устройство российского программиста — телефон изъяла ФСБ. И это при формальных ограничениях поставок израильских инструментов в Россию. Вывод простой: уход вендора с рынка не обнуляет уже развёрнутые возможности. Оборудование закуплено, люди обучены, серый рынок работает.
Что можно сделать прямо сейчас:
• Перезагружайте iPhone перед пересечением границ или в ситуациях риска — переводите его в BFU
• Используйте длинный буквенно-цифровой пасскод вместо 6-значного PIN — брутфорс на 80 мс/попытку упрётся в годы
• Включите
Полный разбор с техническими деталями — в статье на форуме➡️ https://codeby.net/threads/cellebrite-vzlom-iphone-kak-spetssluzhby-izvlekayut-dannyye-posle-ukhoda-vendora.94921/
Когда телефон попадает в форензик-лабораторию, никого не интересует модель или версия iOS. Первый вопрос — вводил ли владелец пасскод хотя бы раз после последней перезагрузки. От ответа зависит всё: 95% данных или 5%.
BFU (Before First Unlock) — телефон перезагружен, пасскод не введён. Ключи шифрования заперты внутри Secure Enclave. Доступны только крохи: метаданные и системные файлы класса
NSFileProtectionNone. Для форензика — почти тупик.AFU (After First Unlock) — пасскод введён хотя бы однажды. Криптографические ключи загружены в RAM и остаются там, даже если экран заблокирован. Сообщения, фото, геолокация, пароли Wi-Fi, токены авторизации, история браузера — всё открыто для инструмента экстракции.
Стандартный протокол изъятия прост: забрать телефон, положить в клетку Фарадея, поддерживать заряд и не дать устройству перезагрузиться. Пока iPhone в AFU — он уязвим.
Отдельная история — аппаратная уязвимость checkm8. Она затрагивает чипы A5–A11 (от iPhone 4S до iPhone X) и бьёт по BootROM — загрузчику, прошитому в кремний на заводе. Никакое обновление iOS это не исправит. На старых чипах без Secure Enclave можно снять полный физический дамп вообще без пасскода. На A7–A11 — обойти программный счётчик попыток и запустить офлайн-брутфорс. Cellebrite интегрировала этот эксплойт прямо в UFED.
На чипах A12+ (iPhone XS и новее) checkm8 не работает. Но это не значит, что новые iPhone неуязвимы в AFU. По имеющимся данным, Cellebrite UFED Premium способен извлечь полную файловую систему из AFU-устройств даже на новейших моделях. Точная матрица поддержки закрыта NDA.
Что можно сделать прямо сейчас:
• Перезагружайте iPhone перед пересечением границ или в ситуациях риска — переводите его в BFU
• Используйте длинный буквенно-цифровой пасскод вместо 6-значного PIN — брутфорс на 80 мс/попытку упрётся в годы
• Включите
Erase Data — после 10 неудачных попыток ключ шифрования уничтожаетсяПолный разбор с техническими деталями — в статье на форуме
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥5👍4🥰2
Друзья, напоминаем, на каких курсах начинается обучение в августе🚗
Старт 17 августа:
⏺️ Курс «Профессия Реверс-инженер» — научитесь анализировать бинарный код на уровне ассемблера, разбирать исполняемые файлы (PE, ELF, APK), исследовать вредоносное ПО и обходить антиотладку с протекторами.
Старт 24 августа:
⏺️ Курс «Профессия Пентестер» — учимся эксплуатировать онлайн-уязвимости и обходить антивирусы. Изучаем инструменты: сканеры, Bash-скрипты, пентест AD.
⏺️ Курс «Профессия AppSec-инженер» — научитесь анализировать код, находить уязвимости, строить безопасную архитектуру и применять OWASP-практики на реальных проектах.
Старт 31 августа:
⏺️ Курс «Компьютерные сети» — учимся проектировать архитектуру сетей разной сложности. Настраиваем сетевое оборудование.
⏺️ Курс «Антифрод-аналитик» — научитесь выявлять мошенничество, анализировать данные и применять Python для защиты бизнеса от финансовых потерь.
✉️ Запишитесь у нашего менеджера @CodebyAcademyBot
Или узнайте подробности и программы курсов на нашем➡️ сайте
Старт 17 августа:
Старт 24 августа:
Старт 31 августа:
Или узнайте подробности и программы курсов на нашем
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤4👍3😁2
В Anthropic раскрыли инцидент: во время внутренних ИБ-испытаний модели Claude вырвались из изолированной среды и проникли в инфраструктуру трёх реальных организаций. Ретроспективную проверку провели после атак моделей OpenAI на Hugging Face.
1️⃣ Инцидент №1 (публикация вредоносного пакета в PyPI)
Во время задания Claude Mythos 5 нашла фальшивую инструкцию с несуществующим пакетом. Модель зарегистрировала свободное имя, создала аккаунт через почтовый сервис и загрузила свой вредоносный код в репозиторий.
В логах Claude отмечала, что публикация в открытый доступ — это настоящая атака, и такой вариант — «NOT okay». Однако модель решила, что всё ещё внутри симуляции. Её смутили незнакомые центры сертификации и дата «2026 год» в тестовых системах. Автоматические сканеры она приняла за часть CTF-задания.
2️⃣ Инцидент №2 (атака на реальную компанию из-за совпадения имён)
Самый серьёзный случай произошёл с Claude Opus 4.7. В задании фигурировала вымышленная компания, но её название совпало с реально существующей организацией. Не найдя тестовую цель, модель атаковала настоящий домен, извлекла учётные данные приложений и инфраструктуры, а затем получила доступ к БД с несколькими сотнями строк продакшен-данных.
3️⃣ Инцидент №3 (остановка после осознания)
В третьем случае модель просканировала около 9000 адресов, затем скомпрометировала доступное через интернет приложение с помощью SQL-инъекции и учётных данных, взятых с debug-страницы.
🎇 Важные детали
— Модели не изобретали новых техник, везде использовались слабые пароли, открытые эндпоинты и типовые уязвимости.
— Самый ранний инцидент произошёл ещё в апреле 2026 года и оставался незамеченным около трёх месяцев.
▶️ В Anthropic настаивают:
Моделям сообщали, что доступа в интернет нет, хотя он был открыт. Кроме того, во время испытаний не работали классификаторы и системы мониторинга, которые используются в публичных версиях Claude.
🔗 Источник: https://xakep.ru/2026/07/31/claude-attacks/
#Claude #Anthropic #ИБ #кибербезопасность #AI #PyPI #взлом #ИТ #инцидент
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Специалисты Anthropic изучили 141.006 запусков Claude в CTF-тестах, организованных с компанией Irregular. Предполагалось, что тестовые среды изолированы от интернета, но из‑за ошибки конфигурации доступ оставался открыт. Модели принимали настоящие сайты и серверы за часть симуляции.
Во время задания Claude Mythos 5 нашла фальшивую инструкцию с несуществующим пакетом. Модель зарегистрировала свободное имя, создала аккаунт через почтовый сервис и загрузила свой вредоносный код в репозиторий.
Пакет провисел в PyPI около часа и успел скачаться на 15 реальных систем. Одна из них принадлежала ИБ-компании, которая автоматически запускает новые пакеты для анализа. Вредонос похитил учётные данные и использовал их для проникновения во внутреннюю инфраструктуру. PyPI удалил пакет автоматически.
В логах Claude отмечала, что публикация в открытый доступ — это настоящая атака, и такой вариант — «NOT okay». Однако модель решила, что всё ещё внутри симуляции. Её смутили незнакомые центры сертификации и дата «2026 год» в тестовых системах. Автоматические сканеры она приняла за часть CTF-задания.
Самый серьёзный случай произошёл с Claude Opus 4.7. В задании фигурировала вымышленная компания, но её название совпало с реально существующей организацией. Не найдя тестовую цель, модель атаковала настоящий домен, извлекла учётные данные приложений и инфраструктуры, а затем получила доступ к БД с несколькими сотнями строк продакшен-данных.
Интересно, что во всех четырёх запусках Claude в итоге понимала, что имеет дело с реальной системой. Однако в двух случаях ИИ решил, что реальная компания тоже является частью учений, и продолжил атаку.
В третьем случае модель просканировала около 9000 адресов, затем скомпрометировала доступное через интернет приложение с помощью SQL-инъекции и учётных данных, взятых с debug-страницы.
Позже она заметила, что хост находится в облачной учётке, явно не связанной с заданием. Поняв, что это реальная система, Claude самостоятельно остановила атаку.
— Модели не изобретали новых техник, везде использовались слабые пароли, открытые эндпоинты и типовые уязвимости.
— Самый ранний инцидент произошёл ещё в апреле 2026 года и оставался незамеченным около трёх месяцев.
«Проблема заключалась не в том, что модели Claude проигнорировали какие-либо ограничения, а в ошибках, допущенных при настройке тестовой инфраструктуры и при проведении тестов».
Моделям сообщали, что доступа в интернет нет, хотя он был открыт. Кроме того, во время испытаний не работали классификаторы и системы мониторинга, которые используются в публичных версиях Claude.
Теперь компания обещает тщательнее проверять логи, улучшить инструменты расследований и привлечь специалистов METR для независимой оценки.
#Claude #Anthropic #ИБ #кибербезопасность #AI #PyPI #взлом #ИТ #инцидент
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥6👍3😁3⚡2👀2👾2
Даже при использовании параметризованных запросов приложение может оставаться уязвимым к SQL-инъекциям.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3👍3⚡2
В каком случае риск SQL-инъекции сохраняется?
Anonymous Quiz
10%
Использование Prepared Statements
60%
Динамическое формирование имен таблиц или столбцов из пользовательского ввода
22%
Применение HTTPS
8%
Использование ORM
❤9👍4🔥3❤🔥2⚡2👾2
Один клик — и ваш vault token у атакующего: как работает CVE-2026-33757
Представьте: вы храните в OpenBao пароли баз данных, API-ключи облачных провайдеров, TLS-сертификаты. Один сотрудник кликает по ссылке из мессенджера, проходит привычную аутентификацию в корпоративном IDP — и даже не подозревает, что vault token с его привилегиями уже в руках злоумышленника. Без алертов, без аномалий в логах. CVSS 9.6 Critical.
🔑 OpenBao — open-source форк HashiCorp Vault, на который многие компании перешли после смены лицензии Vault на BSL. Проблема CVE-2026-33757 затрагивает OIDC-аутентификацию в конфигурациях, где администратор вручную включил
Как это работает в штатном режиме? Вы запрашиваете вход, OpenBao генерирует auth URL, ваш браузер отправляет вас в IDP, вы проходите аутентификацию, и authorization code возвращается в ваш браузер. Вы контролируете весь процесс.
🎇 А теперь атака. В direct mode authorization code идёт напрямую в API OpenBao, минуя браузер пользователя. Атакующий:
• Сам инициирует auth request к API — привилегии не нужны
• Получает auth URL с параметрами
• Отправляет эту ссылку жертве через фишинг
• Жертва кликает, логинится в IDP — всё выглядит легитимно
• OpenBao привязывает vault token к сессии атакующего
• Атакующий поллит API и забирает токен
Классика session fixation (CWE-384): система не инвалидирует сессию при аутентификации нового пользователя и не запрашивает подтверждение.
Что делает эту уязвимость по-настоящему опасной — каскадный эффект. Получив vault token, атакующий читает database credentials, SSH-ключи, cloud API keys. С ними — lateral movement без необходимости ломать каждый сервис отдельно. А если у жертвы write-политики — подмена секретов и внедрение backdoor credentials. В средах с CI/CD один украденный токен компрометирует весь pipeline.
➡️ Что делать прямо сейчас:
1. Обновиться до OpenBao 2.5.2 — фикс уже в релизе
2. Проверить все OIDC-роли на наличие
3. Настроить корреляцию IP в auth flow: кто инициировал запрос и откуда пришёл callback — должны совпадать
4. Мониторить паттерн «auth request с одного IP, callback с другого» — это прямой индикатор атаки
EPSS даёт скромные 0.41% вероятности эксплуатации за 30 дней. Но для целевой атаки на организацию, мигрировавшую на OpenBao, этот вектор — подарок. Массовых атак ждать не стоит, а вот точечных — вопрос времени.
Полный разбор с пошаговым сценарием эксплуатации и детектированием — в статье на форуме.
https://codeby.net/threads/cve-2026-33757-uyazvimost-openbao-session-fixation-cherez-jwt-oidc-v-secrets-management.94963/
Представьте: вы храните в OpenBao пароли баз данных, API-ключи облачных провайдеров, TLS-сертификаты. Один сотрудник кликает по ссылке из мессенджера, проходит привычную аутентификацию в корпоративном IDP — и даже не подозревает, что vault token с его привилегиями уже в руках злоумышленника. Без алертов, без аномалий в логах. CVSS 9.6 Critical.
callback_mode=direct. Это не дефолт, но на практике встречается чаще, чем хотелось бы.Как это работает в штатном режиме? Вы запрашиваете вход, OpenBao генерирует auth URL, ваш браузер отправляет вас в IDP, вы проходите аутентификацию, и authorization code возвращается в ваш браузер. Вы контролируете весь процесс.
• Сам инициирует auth request к API — привилегии не нужны
• Получает auth URL с параметрами
state и nonce• Отправляет эту ссылку жертве через фишинг
• Жертва кликает, логинится в IDP — всё выглядит легитимно
• OpenBao привязывает vault token к сессии атакующего
• Атакующий поллит API и забирает токен
Классика session fixation (CWE-384): система не инвалидирует сессию при аутентификации нового пользователя и не запрашивает подтверждение.
Что делает эту уязвимость по-настоящему опасной — каскадный эффект. Получив vault token, атакующий читает database credentials, SSH-ключи, cloud API keys. С ними — lateral movement без необходимости ломать каждый сервис отдельно. А если у жертвы write-политики — подмена секретов и внедрение backdoor credentials. В средах с CI/CD один украденный токен компрометирует весь pipeline.
1. Обновиться до OpenBao 2.5.2 — фикс уже в релизе
2. Проверить все OIDC-роли на наличие
callback_mode=direct — если не нужен явно, убрать3. Настроить корреляцию IP в auth flow: кто инициировал запрос и откуда пришёл callback — должны совпадать
4. Мониторить паттерн «auth request с одного IP, callback с другого» — это прямой индикатор атаки
EPSS даёт скромные 0.41% вероятности эксплуатации за 30 дней. Но для целевой атаки на организацию, мигрировавшую на OpenBao, этот вектор — подарок. Массовых атак ждать не стоит, а вот точечных — вопрос времени.
Полный разбор с пошаговым сценарием эксплуатации и детектированием — в статье на форуме.
https://codeby.net/threads/cve-2026-33757-uyazvimost-openbao-session-fixation-cherez-jwt-oidc-v-secrets-management.94963/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍4🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍4🔥2❤🔥1
92% на тесте по ИБ — и клик по фишингу в тот же понедельник
Реальная история: бухгалтер прошла обучение по безопасности, набрала 92% на тесте. А через неделю открыла вложение из письма, замаскированного под запрос контрагента. Классический Spearphishing Attachment. В это же время инженер из IT-отдела получил то же письмо — и за 4 минуты скинул хеш вложения в канал
И вот тут начинается самое интересное. Verizon DBIR 2025 говорит: 60% утечек связаны с человеческим поведением. В России ситуация жёстче — по данным Innostage SOC CyberART, 80% инцидентов за первое полугодие 2024 вызваны человеческим фактором. При этом формальное обучение проходит подавляющее большинство сотрудников. И на этом всё заканчивается.
Почему так? Знание само по себе не формирует рефлекс. Есть модель BMAP: поведение меняется, когда совпадают три вещи — мотивация (зачем мне это), способность (насколько легко поступить правильно) и триггер (что напомнит в момент решения). Ежегодный курс работает только с мотивацией, да и то на уровне абстрактного «фишинг — плохо». В 9 утра с горящими дедлайнами это не спасает.
🎯 По данным SANS, 62% специалистов по security awareness не имеют метрик поведенческих изменений. Они отчитываются процентом прохождения курсов, но не могут связать обучение со снижением рисков. Это не программа обучения — это отчётность ради отчётности.
Как проверить, где вы на самом деле? Спросите себя: какой у вас
🎇 Что реально работает:
• Фишинговые симуляции минимум раз в месяц с адаптивной сложностью, а не ежегодная акция «для галочки»
• Шаблоны, покрывающие реальные TTPs атакующих — вложения с макросами, поддельные SSO-порталы, запросы на передачу данных
• Интеграция результатов с SOC и SIEM — чтобы awareness-метрики стали предвестниками инцидентов, а не запаздывающей статистикой
Отдельный момент: GenAI удвоил объём фишинга за 2024 год. IBM X-Force фиксирует — генерация фишинговых писем с помощью ИИ быстрее в 11 раз при сопоставимом качестве. Грамотный русский, персонализация, правдоподобные домены. Времена, когда фишинг выдавал себя кривой грамматикой, прошли.
Галочка в ведомости не спасла ещё ни одну компанию. Подробный разбор пятиуровневой модели зрелости, конкретные шаблоны симуляций и метрики, которые стоит внедрить — в полной версии статьи⬇️
https://codeby.net/threads/kak-postroit-kul-turu-informatsionnoi-bezopasnosti-v-kompanii-ot-formal-nykh-politik-k-zhivomu-obucheniyu-sotrudnikov.94972/
Реальная история: бухгалтер прошла обучение по безопасности, набрала 92% на тесте. А через неделю открыла вложение из письма, замаскированного под запрос контрагента. Классический Spearphishing Attachment. В это же время инженер из IT-отдела получил то же письмо — и за 4 минуты скинул хеш вложения в канал
#security-alerts. Одна компания, одна угроза, противоположные реакции. Разница — не в знаниях. Оба прошли один курс. Разница в том, стала ли безопасность рабочей привычкой.И вот тут начинается самое интересное. Verizon DBIR 2025 говорит: 60% утечек связаны с человеческим поведением. В России ситуация жёстче — по данным Innostage SOC CyberART, 80% инцидентов за первое полугодие 2024 вызваны человеческим фактором. При этом формальное обучение проходит подавляющее большинство сотрудников. И на этом всё заканчивается.
Почему так? Знание само по себе не формирует рефлекс. Есть модель BMAP: поведение меняется, когда совпадают три вещи — мотивация (зачем мне это), способность (насколько легко поступить правильно) и триггер (что напомнит в момент решения). Ежегодный курс работает только с мотивацией, да и то на уровне абстрактного «фишинг — плохо». В 9 утра с горящими дедлайнами это не спасает.
Как проверить, где вы на самом деле? Спросите себя: какой у вас
click-rate по фишинговым симуляциям? Если ответ «не знаем» — вы на первом уровне зрелости из пяти. Типичный baseline в компании без программы awareness: click-rate 25–35%, report-rate ниже 5%.• Фишинговые симуляции минимум раз в месяц с адаптивной сложностью, а не ежегодная акция «для галочки»
• Шаблоны, покрывающие реальные TTPs атакующих — вложения с макросами, поддельные SSO-порталы, запросы на передачу данных
• Интеграция результатов с SOC и SIEM — чтобы awareness-метрики стали предвестниками инцидентов, а не запаздывающей статистикой
Отдельный момент: GenAI удвоил объём фишинга за 2024 год. IBM X-Force фиксирует — генерация фишинговых писем с помощью ИИ быстрее в 11 раз при сопоставимом качестве. Грамотный русский, персонализация, правдоподобные домены. Времена, когда фишинг выдавал себя кривой грамматикой, прошли.
Галочка в ведомости не спасла ещё ни одну компанию. Подробный разбор пятиуровневой модели зрелости, конкретные шаблоны симуляций и метрики, которые стоит внедрить — в полной версии статьи
https://codeby.net/threads/kak-postroit-kul-turu-informatsionnoi-bezopasnosti-v-kompanii-ot-formal-nykh-politik-k-zhivomu-obucheniyu-sotrudnikov.94972/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍2🔥2
Что их объединяет? Это три способа проникнуть туда, куда не звали.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2❤🔥1👍1🔥1
Три пароля в plaintext за двадцать минут — почему аудит прошивки роутера перестал быть экзотикой
Полгода назад на пентесте IoT-инфраструктуры коллега снял дамп SPI-флеш с роутера через программатор CH341A. Binwalk отработал за минуты — в конфигах лежали три пароля открытым текстом. Два из них давали root shell по telnet без аутентификации. Устройство висело на периметре с белым IP, доступное из интернета. И это не аномалия.
Такие артефакты — норма для SOHO-роутеров. Hardcoded credentials, открытые debug-интерфейсы, UART shell без пароля. Одна дыра в Realtek SDK транслируется в сотни моделей от разных брендов — потому что десятки OEM-производителей строят прошивки на одной кодовой базе.
🔎 Что по сути представляет собой роутер на периметре? Полноценный Linux-хост с root-доступом, через который идёт весь трафик сегмента. Компрометация такого устройства — это pivot во внутреннюю сеть, перехват DNS, persistence, который переживёт переустановку ОС на подключённых машинах.
Скандал вокруг запрета TP-Link в США только подсветил проблему. Суть претензий — не конкретный бэкдор, а системная непрозрачность разработки firmware, медленные патчи и факты использования устройств в ботнетах. Но те же грабли у Netgear, D-Link, Tenda, иногда у Asus. Производитель вторичен — важен процесс аудита.
Как выглядит workflow на практике:
• Получаем прошивку — скачиваем с FTP вендора, снимаем через UART/SPI или перехватываем при обновлении (да, в 2025 некоторые устройства всё ещё тянут firmware по голому HTTP)
• Распаковываем через
• Ищем хардкод-креды, debug-эндпоинты, устаревшие компоненты — статический анализ в Ghidra
• Эмулируем в QEMU через FirmAE — фаззим веб-интерфейс, тестируем найденные точки входа
• Эксплуатируем — command injection, обход аутентификации, доступ через debug-порт
Минимальный стенд для старта — Ubuntu или Kali, 4 ГБ RAM, программатор CH341A за 500 рублей и USB-to-TTL адаптер. Никаких облачных зависимостей, всё крутится локально.
🎇 Главный вывод: аудит прошивки — обязательный этап пентеста любой сети, где на периметре стоит SOHO-роутер. Не потому что TP-Link плохой, а потому что класс устройств системно недоинвестирован в безопасность. Один plaintext-пароль в конфиге — и у атакующего есть initial access без единого эксплойта.
В полной статье — детальный пошаговый разбор: от физической экстракции до готового чеклиста обнаружения бэкдоров.
https://codeby.net/threads/audit-proshivki-routera-ot-ekstraktsii-firmware-do-obnaruzheniya-b-ekdorov.94986/
Полгода назад на пентесте IoT-инфраструктуры коллега снял дамп SPI-флеш с роутера через программатор CH341A. Binwalk отработал за минуты — в конфигах лежали три пароля открытым текстом. Два из них давали root shell по telnet без аутентификации. Устройство висело на периметре с белым IP, доступное из интернета. И это не аномалия.
Такие артефакты — норма для SOHO-роутеров. Hardcoded credentials, открытые debug-интерфейсы, UART shell без пароля. Одна дыра в Realtek SDK транслируется в сотни моделей от разных брендов — потому что десятки OEM-производителей строят прошивки на одной кодовой базе.
Скандал вокруг запрета TP-Link в США только подсветил проблему. Суть претензий — не конкретный бэкдор, а системная непрозрачность разработки firmware, медленные патчи и факты использования устройств в ботнетах. Но те же грабли у Netgear, D-Link, Tenda, иногда у Asus. Производитель вторичен — важен процесс аудита.
Как выглядит workflow на практике:
• Получаем прошивку — скачиваем с FTP вендора, снимаем через UART/SPI или перехватываем при обновлении (да, в 2025 некоторые устройства всё ещё тянут firmware по голому HTTP)
• Распаковываем через
binwalk или unblob — вытаскиваем файловую систему• Ищем хардкод-креды, debug-эндпоинты, устаревшие компоненты — статический анализ в Ghidra
• Эмулируем в QEMU через FirmAE — фаззим веб-интерфейс, тестируем найденные точки входа
• Эксплуатируем — command injection, обход аутентификации, доступ через debug-порт
Минимальный стенд для старта — Ubuntu или Kali, 4 ГБ RAM, программатор CH341A за 500 рублей и USB-to-TTL адаптер. Никаких облачных зависимостей, всё крутится локально.
В полной статье — детальный пошаговый разбор: от физической экстракции до готового чеклиста обнаружения бэкдоров.
https://codeby.net/threads/audit-proshivki-routera-ot-ekstraktsii-firmware-do-obnaruzheniya-b-ekdorov.94986/
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤7👍2🔥2
Взлом — это только начало. Настоящая работа начинается после атаки.
Пока одни пытаются понять, что произошло, специалисты DFIR уже ищут следы, анализируют артефакты и восстанавливают действия злоумышленников.
До 6 августа ещё можно присоединиться к текущему потоку курса по цифровой криминалистике и реагированию на инциденты в Linux.
На практическом онлайн-курсе «Цифровая криминалистика и реагирование на инциденты в Linux (DFIR)» за 3,5 месяца вы пройдёте полный цикл анализа инцидентов — от сбора артефактов до восстановления картины атаки.
Что внутри:
⏺️ реальные кейсы на основе расследований КИ 2023–2024
⏺️ сбор и анализ артефактов: логи, процессы, файловая система, сетевая активность
⏺️ работа с open-source инструментами DFIR
⏺️ практика в учебной лаборатории + разбор домашних заданий с преподавателем
⏺️ удостоверение о повышении квалификации после экзамена
Успейте записаться на ближайший поток до 6 августа.
Скидка 30% при оплате сразу. Доступна также поэтапная оплата 6 520 ₽/мес
➡️ ️Записаться и посмотреть программу
🪧 Бесплатная консультация @CodebyAcademyBot
Пока одни пытаются понять, что произошло, специалисты DFIR уже ищут следы, анализируют артефакты и восстанавливают действия злоумышленников.
До 6 августа ещё можно присоединиться к текущему потоку курса по цифровой криминалистике и реагированию на инциденты в Linux.
На практическом онлайн-курсе «Цифровая криминалистика и реагирование на инциденты в Linux (DFIR)» за 3,5 месяца вы пройдёте полный цикл анализа инцидентов — от сбора артефактов до восстановления картины атаки.
Что внутри:
Успейте записаться на ближайший поток до 6 августа.
Скидка 30% при оплате сразу. Доступна также поэтапная оплата 6 520 ₽/мес
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2🔥2
В прошлом году было обнаружено, что Google индексирует публичные ссылки на разговоры с ChatGPT, превращая приватные беседы в открытые поисковые результаты. Каталоги, содержащие чаты и ссылки на общие беседы, не были должным образом защищены от индексации.
В этом году похожая проблема появилась у DeepSeek. Исследователь обнаружил, что ссылки на общие чаты DeepSeek в настоящее время индексируются Google. Для просмотра таких страниц исследователь использовал следующий запрос
site:chat.deepseek.com/share.Каждый общий чат можно дополнительно изучить с помощью инструментов разработчика браузера. Изучив поля метаданных, такие как inserted_at, можно определить, когда был создан диалог, и установить временную метку, связанную с общим чатом.
Кроме того, можно проанализировать отдельные разветвления запросов, поскольку они включены в данные общего диалога и доступны для изучения.
P. S. Похожая проблема также наблюдается у Claude.
#LLM #news #security
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍3❤2
POST-параметр → exec() → shell: как одна строка кода превращает админку CMS в точку входа на сервер
Представьте: вы администратор CMS, нажимаете кнопку «Обновить ядро», а браузер отправляет POST-запрос с параметром
Именно это обнаружилось при анализе патча baserCMS 5.2.3. Уязвимости присвоены сразу два CVE — CVE-2026-21861 и CVE-2026-30877 — обе с оценкой CVSS 9.1 (CRITICAL). CISA подтвердила наличие концептуального PoC.
🔎 Почему это опаснее, чем кажется?
Типичная реакция: «Атакующий уже админ, что ему ещё нужно?» Ответ кроется в CVSS-флаге Scope: Changed. Администратор CMS управляет контентом — страницами, медиафайлами, плагинами. OS command injection выводит атакующего за рамки приложения на уровень операционной системы:
• Чтение DB-credentials из конфигов CakePHP, SSH-ключей, API-токенов
• Запись PHP-шелла в webroot — сессия протухнет, а шелл останется
• Reverse shell для pivot'а к базе данных, очередям сообщений, внутренним API
• Полный контроль от имени
Для атакующего, получившего админ-аккаунт через credential stuffing или фишинг, это мост от «могу редактировать сайт» к «выполняю любые команды на сервере».
➡️ Как устроен вектор атаки?
Контроллер
«Но ведь есть CSRF-защита!» — скажете вы. Не поможет. Атакующий с легитимной admin-сессией получает валидный CSRF-токен штатным образом. Запрос формально легитимен: правильный endpoint, правильный метод, валидный токен. Скрытие кнопки обновления в UI бесполезно — endpoint доступен через
👉 Что делать прямо сейчас?
Если используете baserCMS — обновляйтесь до 5.2.3 немедленно. Обе уязвимости закрыты в одном релизе. Два CVE, один diff — скорее всего, два разных injection-вектора, найденных при одном аудите.
В полной статье — воспроизводимая цепочка эксплуатации, конкретные правила детектирования для WAF, хоста и SIEM, а также детальный разбор CVSS-вектора. Читайте на форуме.
https://codeby.net/threads/cve-2026-21861-basercms-uyazvimost-os-command-injection-cherez-funktsiyu-obnovleniya-yadra.94977/
Представьте: вы администратор CMS, нажимаете кнопку «Обновить ядро», а браузер отправляет POST-запрос с параметром
php. Значение этого параметра — путь к PHP-бинарнику — без какой-либо фильтрации конкатенируется в строку и уходит прямиком в exec(). Ни escapeshellarg(), ни allowlist, ни regex. Голый пользовательский ввод в shell-команде. 2026 год на дворе.Именно это обнаружилось при анализе патча baserCMS 5.2.3. Уязвимости присвоены сразу два CVE — CVE-2026-21861 и CVE-2026-30877 — обе с оценкой CVSS 9.1 (CRITICAL). CISA подтвердила наличие концептуального PoC.
Типичная реакция: «Атакующий уже админ, что ему ещё нужно?» Ответ кроется в CVSS-флаге Scope: Changed. Администратор CMS управляет контентом — страницами, медиафайлами, плагинами. OS command injection выводит атакующего за рамки приложения на уровень операционной системы:
• Чтение DB-credentials из конфигов CakePHP, SSH-ключей, API-токенов
• Запись PHP-шелла в webroot — сессия протухнет, а шелл останется
• Reverse shell для pivot'а к базе данных, очередям сообщений, внутренним API
• Полный контроль от имени
www-data: чтение /etc/passwd, запуск произвольных бинарниковДля атакующего, получившего админ-аккаунт через credential stuffing или фишинг, это мост от «могу редактировать сайт» к «выполняю любые команды на сервере».
Контроллер
PluginsController, метод get_core_update(). Параметр php извлекается из POST-данных и попадает в shell-команду дважды — как путь к бинарнику в начале и как аргумент после --php. Спецсимволы ;, |, &&, обратные кавычки и $() проходят без фильтрации. Подставляем в параметр что-то вроде php;id — и получаем выполнение произвольной команды.«Но ведь есть CSRF-защита!» — скажете вы. Не поможет. Атакующий с легитимной admin-сессией получает валидный CSRF-токен штатным образом. Запрос формально легитимен: правильный endpoint, правильный метод, валидный токен. Скрытие кнопки обновления в UI бесполезно — endpoint доступен через
curl или Burp Repeater.Если используете baserCMS — обновляйтесь до 5.2.3 немедленно. Обе уязвимости закрыты в одном релизе. Два CVE, один diff — скорее всего, два разных injection-вектора, найденных при одном аудите.
В полной статье — воспроизводимая цепочка эксплуатации, конкретные правила детектирования для WAF, хоста и SIEM, а также детальный разбор CVSS-вектора. Читайте на форуме.
https://codeby.net/threads/cve-2026-21861-basercms-uyazvimost-os-command-injection-cherez-funktsiyu-obnovleniya-yadra.94977/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2🔥2
Ваш Metasploit — рабочий инструмент или уголовная статья?
Между легальным пентестом и обвинением по ст. 272–273 УК РФ стоит ровно один документ. И его у вас может не быть.
Вот что нужно понимать каждому, кто занимается тестированием на проникновение в России.
➡️ Две статьи, которые касаются каждого пентестера
Ст. 272 — неправомерный доступ к компьютерной информации. Ключевое слово — «неправомерный». Не ваши намерения, не сертификаты, не цвет шляпы отделяют вас от злоумышленника, а юридический факт наличия разрешения. Сканировали чужую систему без письменного согласия? Вышли за scope — тестировали веб-приложение, а полезли в HR-базу? Работали по устной договорённости? Всё это — потенциальное обвинение. Санкция — до 200 000 рублей штрафа или до двух лет лишения свободы, а при квалифицированном составе — до пяти.
Ст. 273 — создание и использование вредоносных программ. Metasploit, Cobalt Strike, кастомные эксплойты — формально подпадают под эту статью, если применяются для несанкционированных действий. Даже
🎇 Что должно быть в договоре, чтобы он реально защищал
Специального понятия «договор на пентест» в законодательстве нет. Используется договор возмездного оказания услуг по главе 39 ГК РФ. Но формулировка «анализ защищённости систем Заказчика» не стоит бумаги, на которой напечатана. Вот что действительно важно:
• Конкретные IP-адреса, домены, поддомены — никаких «все системы заказчика»
• Перечень разрешённых методов: black box, grey box, social engineering — или явный запрет каждого
• Список запрещённых действий: DoS на продакшне, атака на третьи системы
• Временные рамки: даты, часы, blackout-периоды
• Процедура экстренной остановки с контактным лицом
❗️ Отдельная ловушка — владелец инфраструктуры. Заказчик не всегда владеет тем, что вы тестируете. Сайт на хостинге? Серверами владеет провайдер. Приложение в облаке? У AWS, Azure и GCP свои политики разрешения на пентест. Без согласия каждого владельца — снова ст. 272.
И ещё один момент, о котором забывают: если в ходе тестирования вы нашли дамп с паспортными данными — поздравляю, вы стали оператором ПДн по ФЗ-152 со всеми обязательствами. Порядок хранения скриншотов, логов, дампов и сроки их уничтожения тоже фиксируются в договоре.
Полный разбор рисков на каждом этапе kill chain, шаблоны документов и конкретные кейсы — в статье на форуме.
https://codeby.net/threads/yuridicheskiye-riski-pentesta-v-rossii-chem-etichnyi-vzlom-otlichayet-sya-ot-prestupleniya-po-st-272-273-uk-rf.94999/
Между легальным пентестом и обвинением по ст. 272–273 УК РФ стоит ровно один документ. И его у вас может не быть.
Вот что нужно понимать каждому, кто занимается тестированием на проникновение в России.
Ст. 272 — неправомерный доступ к компьютерной информации. Ключевое слово — «неправомерный». Не ваши намерения, не сертификаты, не цвет шляпы отделяют вас от злоумышленника, а юридический факт наличия разрешения. Сканировали чужую систему без письменного согласия? Вышли за scope — тестировали веб-приложение, а полезли в HR-базу? Работали по устной договорённости? Всё это — потенциальное обвинение. Санкция — до 200 000 рублей штрафа или до двух лет лишения свободы, а при квалифицированном составе — до пяти.
Ст. 273 — создание и использование вредоносных программ. Metasploit, Cobalt Strike, кастомные эксплойты — формально подпадают под эту статью, если применяются для несанкционированных действий. Даже
Nmap можно квалифицировать как средство подготовки к неправомерному доступу. Контекст решает всё. С договором ваш инструментарий — рабочий арсенал. Без договора — вещественное доказательство.Специального понятия «договор на пентест» в законодательстве нет. Используется договор возмездного оказания услуг по главе 39 ГК РФ. Но формулировка «анализ защищённости систем Заказчика» не стоит бумаги, на которой напечатана. Вот что действительно важно:
• Конкретные IP-адреса, домены, поддомены — никаких «все системы заказчика»
• Перечень разрешённых методов: black box, grey box, social engineering — или явный запрет каждого
• Список запрещённых действий: DoS на продакшне, атака на третьи системы
• Временные рамки: даты, часы, blackout-периоды
• Процедура экстренной остановки с контактным лицом
И ещё один момент, о котором забывают: если в ходе тестирования вы нашли дамп с паспортными данными — поздравляю, вы стали оператором ПДн по ФЗ-152 со всеми обязательствами. Порядок хранения скриншотов, логов, дампов и сроки их уничтожения тоже фиксируются в договоре.
Полный разбор рисков на каждом этапе kill chain, шаблоны документов и конкретные кейсы — в статье на форуме.
https://codeby.net/threads/yuridicheskiye-riski-pentesta-v-rossii-chem-etichnyi-vzlom-otlichayet-sya-ot-prestupleniya-po-st-272-273-uk-rf.94999/
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤4🔥4😁1
Пока команда разбирает инцидент после релиза, AppSec-инженер уже мог бы не допустить уязвимость в коде.
Компаниям нужен человек, который встроит безопасность в разработку — от ревью кода до CI/CD.
Курс «AppSec-инженер» в Codeby Academy — 7 месяцев практики на реальных приложениях и инструментах, которые используют в продакшене.
Что внутри:
⏺️ разбор уязвимостей OWASP на реальных приложениях
⏺️ SAST/DAST инструменты, которые используют в боевых командах
⏺️ Threat Modeling и Secure SDLC на живых кейсах
Курс подойдёт: специалистам по ИБ, DevOps/DevSecOps-инженерам, разработчикам и пентестерам.
За 7 месяцев▶️ пройдёте 13 модулей — от поиска уязвимостей в коде до внедрения AppSec в процесс разработки▶️ 300 ак.ч. ▶️ 1–2 живых вебинара в месяц с автором
Старт курса — 24 августа
🔁 Посмотреть программу и записаться
Компаниям нужен человек, который встроит безопасность в разработку — от ревью кода до CI/CD.
Курс «AppSec-инженер» в Codeby Academy — 7 месяцев практики на реальных приложениях и инструментах, которые используют в продакшене.
Что внутри:
Курс подойдёт: специалистам по ИБ, DevOps/DevSecOps-инженерам, разработчикам и пентестерам.
За 7 месяцев
Старт курса — 24 августа
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤2🔥1
Некоторые уязвимости JavaScript позволяют изменить поведение сразу всех создаваемых объектов.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2🔥2
Как называется такая категория уязвимостей?
Anonymous Quiz
30%
DOM Clobbering
42%
Prototype Pollution
16%
Type Confusion
12%
Deserialization