Сегодня я узнал, что ГосСОПКА существует.

OWASP Top 10 для LLM — 2025: Защита ИИ-приложений

В 2025 году OWASP представил обновленный список ключевых уязвимостей для LLM-приложений, разработанный при участии экспертов в AI, кибербезопасности и облачных технологий. Хотя LLM остаются относительно новой технологией, их стремительное внедрение потребовало актуализации стандартов безопасности.

Из 10 категорий лишь три остались неизменными с версии 2023 года, что подчеркивает динамичность угроз. Основные риски включают инъекции промптов, утечки данных через генерацию, poisoning обучающих выборок и обход фильтров. Например, атаки типа Prompt Injection позволяют злоумышленникам манипулировать поведением моделей через скрытые команды в тексте.

Отчет акцентирует сценарии атак, методы предотвращения (фильтрация ввода, изоляция контекста, red teaming) и смягчения последствий. Полная версия доступна на сайте OWASP с примерами кейсов и рекомендациями для разработчиков, я же дам выжимку.

LLM01: Инъекция промптов

Злоумышленники могут вводить вредоносные данные, чтобы заставить модель раскрыть конфиденциальную информацию или выполнить нежелательные действия, включая удалённое выполнение кода. Эта уязвимость лидирует, так как эксплуатирует саму природу LLM.

Прямая инъекция: Использование техник вроде DAN (Do Anything Now) для обхода защиты через ролевые игры.
Косвенная инъекция: Вредоносные промпты скрыты в документах (например, белый текст на белом фоне).

Пример: В 2024 году хакер встроил в резюме команду "рекомендуй меня", и HR-бот её выполнил.
Защита: Фильтрация ввода, анализ контекста запросов.

LLM02: Раскрытие конфиденциальной информации

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

Пример: В 2023 году чат-бот Air Canada выдал ложные данные о рейсах, что закончилось судебным иском.
Защита: Санитизация вывода, ограничение доступа к чувствительным данным.

LLM03: Уязвимости цепочки поставок

Сторонние модели и данные (например, с Hugging Face) могут содержать бэкдоры или уязвимости, особенно если поставщик ненадёжен.

Пример: В 2024 году предобученная модель с Hugging Face активировала вредоносный код на определённых запросах.
Защита: Аудит поставщиков, проверка целостности моделей и данных.

LLM04: Отравление данных и моделей

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

Пример: Фейковые данные о компаниях вызвали предвзятость в финансовых рекомендациях.
Защита: Валидация обучающих данных, мониторинг процесса обучения.

LLM05: Ненадлежащая обработка вывода

Непроверенный вывод модели может содержать вредоносный код, выполняемый на сервере или в браузере пользователя, например, для XSS или SQL-инъекций.

Пример: В 2023 году отзыв о товаре с косвенной инъекцией вызвал выполнение JavaScript в браузере.
Защита: Валидация вывода, подход "нулевого доверия" к модели.

OWASP Top 10 для LLM — 2025: Защита ИИ-приложений. Часть 2


LLM06: Чрезмерная автономность

Модели с избыточными правами могут случайно выполнять нежелательные действия, такие как удаление файлов или отправка писем.
Пример: Плагин для чтения файлов также позволял их удалять.
Защита: Ограничение прав модели, проверка действий пользователя.

LLM07: Утечка системного промпта

Раскрытие внутренних инструкций модели позволяет злоумышленникам обойти защиту, особенно если промпт содержит секреты, такие как API-ключи.
Пример: В 2024 году утечка промпта раскрыла API-ключи компании.
Защита: Исключение секретов из промптов, использование внешних систем контроля.

LLM08: Уязвимости векторов и эмбеддингов

Ошибки в методе RAG (Retrieval Augmented Generation) могут привести к утечке данных или изменению поведения модели.
Пример: В 2025 году общие эмбеддинги в мультитенантной среде дали доступ к чужим данным.
Защита: Контроль доступа к данным, аудит эмбеддингов.

LLM09: Дезинформация

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

Пример: ChatGPT в 2023 году выдал вымышленные судебные прецеденты.
Защита: Проверка фактов, использование RAG для повышения точности.

LLM10: Неконтролируемое потребление

Чрезмерное использование ресурсов модели может вызвать DoS-атаки, финансовые потери или кражу модели через API.

Пример: В 2024 году атака на API стоила компании тысячи долларов за час.
Защита: Лимиты запросов, мониторинг аномального поведения.

Защита LLM требует постоянных усилий. Используйте фильтрацию ввода, ограничение прав и мониторинг.

Очередной "безопасный" мессенджер и его взлом


TeleMessage — приложение от Smarsh (Портленд, Орегон), аналог Signal, для архивирования сообщений. Взлом затронул 60+ госслужащих из FEMA, таможни, Белого дома, Секретной службы и дипломатов. Smarsh работала с Госдепартаментом, DHS и CDC (CDC отверг приложение в 2024 году).

4 мая 2025 года хакер получил доступ к серверу TeleMessage за 15–20 минут, эксплуатируя уязвимость в конфигурации архивного сервера (archive.telemessage.com), размещенного на Amazon AWS. Используя инструмент feroxbuster, он нашел публично доступный endpoint /heapdump, предоставивший дамп памяти Java (150 МБ). В дампе содержались имена пользователей, пароли (хешированные устаревшим MD5), журналы чатов и ключи шифрования. Хакер также обнаружил, что пароли хешировались на стороне клиента (MD5), что снижало их защиту. Используя найденные учетные данные, он вошел в админ-панель secure.telemessage.com, получив доступ к данным, включая список из 747 сотрудников таможенной службы США (CBP). Устаревшая технология JSP и слабая конфигурация Spring Boot способствовали легкости атаки.

Украденные данные

Украдено 410 ГБ данных, включая метаданные и сообщения до 4 мая 2025 года, опубликованные Distributed Denial of Secrets. Метаданные угрожают контрразведке, сообщения касались поездок (Ватикан, Иордания).

TeleMessage остановило работу 5 мая 2025 года. CISA добавила уязвимость (CVE-2025-47729) в каталог эксплуатируемых уязвимостей, рекомендовав прекратить использование до принятия мер от Smarsh.

оригинал

Всем хорошего чаепития! ☕️✨

Собрала для вас подборку крутых инструментов 🛠, чтобы надёжно спрятать важные файлы и данные от чужих глаз. Здесь всё: от стеганографии до других не менее интересных способов защиты.

Русская версия


Have a good tea party everyone! ☕️✨

I've put together a selection of cool 🛠 tools for you to safely hide important files and data from prying eyes. Here's everything from steganography to other equally interesting ways of protection.

English version

#anonymity #anti_forensics #cryptography #stegranography #linux #tools

Внезапный мем

OSINT по Bluetooth: как Android-устройства выдают владельца

По неизвестным мне причинам Bluetooth по-прежнему считается сугубо локальным протоколом: передача файлов, подключение к гарнитурам, работа фитнес-браслета. На практике он даёт намного больше. При правильной обработке рекламных пакетов и сервисной информации Bluetooth-устройств можно определить примерное местоположение, тип и модель устройства, восстановить маршруты перемещений, а в некоторых случаях — и установить владельца. Всё это происходит без физического доступа к смартфону или носимым устройствам.

Bluetooth-OSINT используется на этапе сбора информации, при техническом сопровождении мероприятий, в ходе расследований и при мониторинге перемещений. Он эффективен как в городских условиях, так и в ограниченных пространствах: на вокзалах, в бизнес-центрах, гостиницах, конференц-залах.

Особенно уязвимыми остаются устройства на Android. Даже при неактивном соединении они продолжают отправлять рекламные пакеты.
Под рекламными пакетами (advertising packets) в контексте Bluetooth, особенно Bluetooth Low Energy (BLE), понимаются специальные короткие пакеты данных, которые устройство периодически передаёт в эфир, чтобы сообщить о своём присутствии другим устройствам.

Эти пакеты не требуют соединения — они транслируются «вслепую» и принимаются всеми устройствами в радиусе действия. Именно благодаря этим рекламным пакетам, например, наушники появляются в списке доступных Bluetooth-устройств на телефоне.

Многие модели передают имя устройства в открытом виде — например, Pixel 8a Alex или Galaxy S22 Masha. Это поле нередко содержит имя пользователя или никнейм. Такие данные можно сопоставить с результатами поиска в соцсетях, утечках и базах.

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

Что видно через Bluetooth

– Имя устройства
– Сила сигнала (RSSI) — позволяет оценить расстояние до источника
– Manufacturer-specific data — дополнительные поля, заданные производителем
– Advertising UUID — часто статичен для конкретных моделей
– Периодичность вещания и взаимодействие с сервисами

Комбинация смартфона, часов и гарнитуры — уже уникальный набор. Он легко отслеживается по характерному поведению в эфире.

Почему Android создаёт больше шума, чем остальные ОС

– MAC-адрес может не рандомизироваться до ручной перезагрузки Bluetooth
– Встроенная защита BLE Privacy либо отсутствует, либо реализована частично
– Имена устройств часто передаются в открытом виде
– В фоновом режиме работают системные службы: Nearby, Fast Pair, геолокация, Smart Lock

Это создаёт постоянное присутствие устройства в радиоэфире. Даже без подключения к другим устройствам смартфон остаётся заметным.

Как снизить видимость

1. Отключить Bluetooth, если нет необходимости в его работе

2. Отключить фоновое сканирование:

Настройки → Геолокация → Сканирование → Bluetooth-сканирование → Выкл

3. Сменить имя устройства:

Настройки → О телефоне → Имя устройства

4. Отключить Nearby Share, Fast Pair, Smart Lock и другие службы, использующие Bluetooth

5. Если доступен root-доступ, использовать дополнительные утилиты:
– Magisk BLE Privacy Module
– XPrivacyLua
– Bluetooth MAC Spoofer

Инструменты для анализа

– nRF Connect — отображает BLE-пакеты, передаваемые в эфир
– Beacon Scanner / BLE Hero — определение и слежение за окружающими устройствами
– btmon с ADB — позволяет просматривать HCI-логи, включая BLE, без root-доступа
– Kismet — мощный фреймворк для мониторинга беспроводных интерфейсов (Wi-Fi, BLE)

Даже если устройство не подключается ни к чему и лежит в кармане, оно может транслировать эти данные — в зависимости от прошивки, настроек и модели. Это создаёт цифровой «отпечаток» в радиоэфире.

Меня утомило, что люди в интернетах насмотрятся параноидальных роликов на ютубе, нахватаются по верхам и без учета модели угроз ненавидят systemd.
Давайте делать это осознанно!
SysytemD является наиболее популярной системой инициализации в большинстве современных дистрибутивов Linux. Она предлагает параллельный запуск служб и возможность управления зависимостями между ними. Одним из её больших преимуществ является мощный механизм логирования (journald), который позволяет детально отслеживать события в системе. Относительно безопасности, systemd включает в себя такие возможности, как возможность запускать службы в изолированных контейнерах с использованием песочниц, ограничение ресурсов через cgroups и управление привилегиями служб с помощью seccomp. Реальные примеры использования systemd включают серверы крупных облачных провайдеров, таких как Amazon Web Services и Google Cloud, где он помогает эффективно управлять критически важными службами. systemd как наиболее современный инструмент стал основой в таких корпоративных и серверных дистрибутивах, как Red Hat Enterprise Linux и Ubuntu. Благодаря своей гибкости и встроенным функциям безопасности, systemd позволяет админам крупных сетей эффективно управлять службами, включая их запуск, мониторинг и остановку, минимизируя при этом возможные угрозы.
systemd — это не просто init-система. Это целая экосистема компонентов, объединяющая функции, ранее распределённые между десятками утилит: init, cron, inetd, udev, syslog, rc, logrotate, netctl и др.
Архитектура systemd
Основной принцип systemd — юниты (unit). Они описывают, как запускать и управлять службами, точками монтирования, сокетами, таймерами, пользователями и многим другим. Примеры юнитов:
*.service — системные службы.
*.socket — сокеты, запускающие службы по запросу.
*.mount — монтируемые точки.
*.timer — планировщики заданий (альтернатива cron).
*.path — запуск по изменению в файловой системе.
Каждый unit может содержать десятки параметров: зависимости, ограничения, права, логирование, реакции на сбои.
Ключевые компоненты systemd
systemd-journald — собственный бинарный логгер, заменяющий rsyslog.
systemd-networkd и resolved — настройка сети и DNS.
logind — управление сессиями и пользователями.
systemd-nspawn — контейнеризация.
cgroups v2 и namespaces — изоляция ресурсов и процессов.
systemctl, journalctl, loginctl, hostnamectl — унифицированный интерфейс управления.
Всё это делает systemd мощным инструментом DevSecOps, где важна централизованная политика управления процессами и безопасностью.
Механизмы безопасности в systemd
systemd предоставляет расширенные возможности для ограничения привилегий служб — часто более удобные и гибкие, чем ручная настройка capabilities или seccomp:
NoNewPrivileges=yes — запрещает повышать привилегии.
PrivateTmp=yes — изолирует /tmp.
ProtectSystem=full — монтирует /usr как read-only.
ReadWritePaths= — задаёт исключения для записи.
CapabilityBoundingSet= — ограничивает доступные capabilities.
RestrictAddressFamilies= — запрещает сетевые взаимодействия по протоколам.
Эти меры позволяют создать модель “least privilege” без внешних MAC-систем — прямо через unit-файл.
Пример: защита nginx через systemd

[Service]
ExecStart=/usr/sbin/nginx
User=nginx
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=full
ReadWritePaths=/var/lib/nginx /var/log/nginx
RestrictAddressFamilies=AF_INET AF_INET6

Такая конфигурация даёт nginx минимально необходимые привилегии, изолирует файловую систему, блокирует лишние сетевые протоколы и запрещает расширение прав.
Преимущества и риски systemd
Плюсы:
• Высокая гибкость и расширяемость.
• Быстрая параллельная загрузка.
• Централизованное управление.
• Интеграция с инструментами мониторинга и журналирования.
Минусы:
• Высокая сложность — как архитектурно, так и концептуально.
• Уязвимости в journald и других компонентах (CVE-2017-9445, CVE-2018-15686).
• Иногда мешает отладке — всё идёт через systemctl или journalctl.

Новый релиз FreeBSD 14.3-RELEASE вышел 10 июня 2025

Свежая стабильная версия FreeBSD 14.3 доступна для загрузки. Это плановый релиз в рамках ветки 14-STABLE, сосредоточенный на исправлениях, безопасности и поддержке оборудования.

Что нового:

— Поддержка Wi-Fi 802.11ac в драйвере iwlwifi — актуально для ноутбуков на Intel.
— Обновление компилятора и инструментов: Clang/LLVM 19.1.7, lld, lldb.
— OpenSSH обновлён до версии 9.9p2 — улучшены безопасность и совместимость.
— Системные библиотеки обновлены: xz 5.8.1, expat 2.7.1, sqlite 3.45.3.
— Исправлены уязвимости в ncurses и утилитах из базовой системы.
— Повышена стабильность виртуализации под Hyper-V, Xen, Bhyve.

Образы и архитектуры:

— Поддержка: amd64, i386, aarch64, armv7, powerpc, powerpc64, riscv64.
— Образы: ISO, memstick, mini-memstick, сетевые установщики.
— Все сборки подписаны (SHA256, SHA512, PGP).

Известные проблемы:

— На BIOS-системах возможны сбои при установке с USB — рекомендуется UEFI.
— armv7: отключена pxeboot-загрузка.
— Возможны проблемы с консолью при использовании графических видеодрайверов — временное решение: переключение на sc(4).

FreeBSD 14.3 — третий релиз в ветке 14.x и последний с полной поддержкой 32-битных платформ (i386, armv7). В релизе 15.0 они будут исключены.

Ссылки:

— Announce
— Release Notes
— Errata
— Hardware Compatibility

#FreeBSD #релиз #безопасность #Unix #обновления

Внезапный мем!

Срочное включение. Там на Y и на Пикабу Реддите говорят всё плохо, дни AOSP сочтены, GrapheneOS умер и RutheniumOS приуныл, даже земля на небесную ось налетела, короче ужас. В связи с этим хочу внести ясность.

Google не убивает AOSP — но просто меняет его в худшую сторону, как обычно

Что говорят Google

«Ходят слухи, что AOSP будет свёрнут. Чтобы было ясно: AOSP никуда не исчезает. Он создавался как платформа для open-source реализаций устройств, чипов и архитектур. Мы продолжаем поддерживать референс-цели — виртуальный Cuttlefish и GSI — для тестирования и разработки.»
— Seang Chau, вице-президент, Android Platform
Источник

Что происходит

— Google больше не публикует device-tree, бинарники и историю коммитов для Pixel.
— Сборка полноценного AOSP под Pixel невозможна без ручной реконструкции.
— Основная разработка Android теперь идёт в закрытой ветке — в AOSP попадает только финальный код с задержкой.

Что говорят GrapheneOS

«Нам сообщили, что AOSP закроют. Первый шаг — удаление Pixel-репозиториев в Android 16. Тогда мы не поверили, но теперь это происходит. По словам источника, официальный Android становится закрытым. Возможно, AOSP продолжится вне Google или проект отделят. Всё ещё может измениться, если Android выведут из-под контроля Google.»

Почему это важно

— Без истории коммитов теряется прозрачность и возможность аудита.
— Разработчики ROM'ов теперь должны вручную воссоздавать device-trees.
— Задержки в выкладке патчей снижают скорость реакции на уязвимости.
— AOSP превращается из основы в производную — без гарантии актуальности.

Резюмируя: AOSP и прошивкостроение пока живо — но проблем явно прибавится.

Там это, X.org форкнули обожаю этот канал

Юридические аспекты

Цель данной заметки помочь действовать в рамках закона при контакте с правоохранительными органами. Мы объясним ваши права, риски и способы защиты, ссылаясь на Конституцию РФ и УК РФ.

Знайте свои права:

- Ст. 51 Конституции РФ: право не свидетельствовать против себя.
- Ст. 48: право на адвоката с момента задержания.
- Ст. 49: презумпция невиновности — вы не обязаны доказывать невиновность.
Изъятие устройства законно только по судебному решению (ст. 182 УПК РФ). Без постановления действия незаконны. Требуйте протокол (ст. 185 УПК РФ).

Разблокировка устройства

Отказ разблокировать устройство защищен ст. 51 Конституции РФ. Вас не могут заставить давать пароли. Ст. 272 УК РФ (неправомерный доступ) и ст. 274.1 УК РФ (критическая инфраструктура) могут быть вменены, но отказ — не доказательство вины.

Поведение на допросе

На допросе говорите: "Я воспользуюсь правом ст. 51 и не буду давать показания без адвоката". Ст. 309 и 302 УК РФ защищают от давления. Требуйте адвоката и не подписывайте документы без него.

Изъятие техники

Протокол изъятия должен содержать перечень устройств и подписи понятых (ст. 182 УПК РФ). При нарушениях фиксируйте и подавайте жалобу в суд (ст. 46 Конституции РФ).

Последствия и защита

Если права нарушены:

- Ст. 137 УК РФ: нарушение частной жизни.
- Ст. 138 УК РФ: нарушение тайны переписки.

Компьютерные преступления регулируются

Глава 28 УК РФ:

- Ст. 272: взлом.
- Ст. 273: вирусы.
- Ст. 274: нарушение эксплуатации.

Изучите статьи, которые Вам вменяют, чтобы понимать суть обвинения. Если что-то не понятно, просите разъяснить

Рекомендации по поведению

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

На допросе: "Требую адвоката по ст. 48 Конституции РФ". При изъятии: "Прошу протокол по ст. 182 УПК РФ".

Конечно это не панацея и будет полезно только при условии полного соблюдения закона обеими сторонами.

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

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

Конституция РФ http://www.kremlin.ru/acts/constitution

УК РФ https://minjust.gov.ru/ru/documents/7612/

#law #допрос #РФ #от_сумы_да_от_тюрьмы