В апреле мы традиционно отдаем микрофон нашему начальнику отдела безопасности Алексею Дрозду (aka @labyrinth, который каждый год собирает для нас подборку забавных и парадоксальных ИБ-инцидентов. Шеф ИБ допускает утечку, криптокошельки пустеют после фотосессии налоговой, нейросеть собирает армию пылесосов-шпионов – все подробности под катом.
В расследовании главное – не выйти на себя
Что случилось:
Исполняющий обязанности директора Агентства по кибербезопасности и защите инфраструктуры США (CISA) загрузил служебные документы в публичную версию ChatGPT.
Как это произошло:
Мадху Готтумуккала, возглавляющий CISA, прошлым летом загрузил в ChatGPT не менее четырех документов, помеченных грифом «только для служебного пользования» (For Official Use Only). Документы не содержали государственной тайны, но относились к служебной информации, не предназначенной для публичного распространения.
Эту операцию зафиксировали автоматические сенсоры безопасности – инструменты, которые призваны предотвращать утечки государственных данных. Инцидент обнаружили в августе, после чего Министерство внутренней безопасности (DHS) начало оценку возможного ущерба.
По умолчанию для сотрудников CISA доступ к чат-боту OpenAI на рабочих устройствах заблокирован. Они могут использовать другие ИИ-инструменты, одобренные ведомством - например, чат-бот DHSChat, разработанный как раз Министерством внутренней безопасности. Он не передает запросы и документы за пределы федеральных сетей.
Но Готтумуккала, едва получив назначение на должность, решил, что такого доступа ему мало. Он запросил себе специальное разрешение – ведомство предоставляет такие некоторым сотрудникам, но только на время и с ограничениями. Доступ был предоставлен в мае, в последний раз и.о. директора воспользовался им в середине июля. Позже директор по связям с общественностью CISA Марси Маккарти пояснила, что Готтумуккала «получил разрешение на использование ChatGPT с соблюдением мер контроля Министерства внутренней безопасности». Это, однако, не помешало ему отправить в публичный сервис закрытые данные – вдвойне иронично, учитывая специализацию Агентства и его в нем высокую должность.
Классика «отрицательного отбора», только здесь даже хуже. Потому что это не просто рядовой сотрудник, который нарушил запрет, а уполномоченное лицо, запросившее доступ именно для себя. Напоминает историю известной авиакомпании, когда после утечки выяснилось, что у директора пароль был простой и не менялся годами.
Или с мировым масштабом – Трамп, чей аккаунт в соцсети взломали, потому что не была установлена 2FA, а пароль был «maga2020!» (то есть его знаменитый лозунг Make America Great Again).
У «топов» всегда больше прав, шире доступ к критическим системам и конфиденциальной информации, а значит, и потенциальный ущерб выше. Поэтому нужно выводить топ-менеджмент в группу особого контроля, знать, с какими данными они работают, к каким сервисам и сайтам обращаются. Чтобы один неосторожный клик руководителя не перечеркнул работу всей службы безопасности.
Не было печали
Что случилось:
Злоумышленники воспользовались публично доступными серверами с локальными ИИ-моделями.
Как это произошло:
Ollama – бесплатный инструмент для запуска локальных ИИ-моделей. Однако исследователи обнаружили по всему миру более 175 000 систем, развернутых на Ollama, которые оказались доступны из интернета. Причина проста: хотя по умолчанию Ollama работает только на локальном интерфейсе (localhost), пользователи вручную меняли настройки на прослушивание всех сетевых интерфейсов и при этом не включали аутентификацию. В результате любой желающий мог подключиться к такому серверу и использовать его ресурсы.
Феномен получил название LLMjacking. Злоумышленники находят такие серверы и используют их вычислительные мощности, трафик и электроэнергию для собственных задач – от запуска ресурсоемких моделей до организации «серого» рынка ИИ-вычислений.
Многие из этих систем используют резидентные IP-адреса – то есть работают через обычные домашние подключения, а не через дата-центры. Это затрудняет их отслеживание, так как адрес может меняться, а физическое местонахождение оборудования – это чья-то квартира, а не охраняемая стойка с серверами. Плюс на некоторых серверах запускают модели без цензуры и встроенных ограничений – это только увеличивает риски злоупотреблений.
Важно отметить, что сама платформа Ollama не содержит критической уязвимости. Причина инцидентов – в ручном изменении конфигурации без учета рисков. Решение проблемы – возврат к настройкам по умолчанию и использование средств сетевой защиты.
Обожаю истории, где люди прикручивают к готовому инструменту что-то новенькое, но не особо вникают в инструкции. Как по мне, это иллюстрация технологической сингулярности. Ollama из коробки настроена безопасно – localhost, и все. Но наш пользователь решил, что будет удобнее сделать доступ со всех устройств и без пароля.
После этого пользователи получили не просто уязвимость своего собственного ПК, а еще и стали донором вычислительных мощностей для злоумышленников. То есть люди по собственной воле (хоть и не до конца осознавая) превратились не только в причину своих бед, но и в источник чужих. Их технику теперь используют хакеры для своих задач.
Разработчики сервисов с многомиллионной аудиторией тоже могут пренебрегать базовыми правилами безопасности, только масштаб становится совсем другим. Вспоминается относительно свежий пример: популярное приложение Chat & Ask AI использовало Google Firebase для хранения данных. Проверки прав доступа не было – любой желающий мог выдать себя за авторизованного пользователя и залезть во внутреннее хранилище. Что там нашли? Около 300 миллионов сообщений от 25 миллионов человек. Полные истории диалогов с ИИ, имена, настройки моделей. А среди переписок – запросы на темы, которые обычно не выносят на публику.
Вывод очевидный: контролируйте не только доступ к публичным ИИ-сервисам, но и то, как внедряются локальные инструменты. Если сотрудник ставит локальную модель на рабочий ноутбук – это нужно учитывать. Внедряйте такие инструменты централизованно, с единой аутентификацией и мониторингом, а не через «сам себе администратор». Перепроверяйте настройки: localhost на 0.0.0.0 меняется за секунду, а последствия тянутся годами.
Взломанные одной цепью
Что случилось:
Утечка данных у суб-суб-суб-суб-подрядчика едва не открыла злоумышленникам доступ к внутренним системам почти двухсот аэропортов по всему миру.
Как это произошло:
Утечку данных подрядчика обнаружила платформа защиты цепочки поставок ПО SVigil во время мониторинга подпольных форумов. В сеть утекли логин и пароль системного инженера сервисной компании четвертого уровня – подрядчик подрядчика основного ИТ-поставщика аэропорта. Этих данных оказалось достаточно, чтобы войти в главный служебный портал операционной поддержки, который использовался более чем в 200 аэропортах. Двухфакторная аутентификация на портале не была включена.
Эксперты SVigil получили доступ к инфраструктуре подрядчика и в реальном времени могли просматривать: перечни серверов и сетевого оборудования с внутренними адресами и ролями, состояние киосков регистрации, принтеров посадочных талонов и багажных бирок в реальном времени, загрузку процессоров, памяти и дисков на ключевых узлах, а также параметры работы баз данных, обслуживающих пассажирские сервисы. Из интерфейса можно было запускать сетевые диагностические команды внутри доверенной сети аэропортов.
Если бы эти данные оказались в поле зрения злоумышленников, то они могли бы перегружать терминалы самообслуживания в часы пик, нарушать работу системы сверки багажа и рейсов (без которой вылеты запрещены правилами) или проводить одновременные атаки на несколько узловых аэропортов. Потенциальные потери в таком сценарии исчислялись бы сотнями миллионов долларов.
С одной стороны, есть инфраструктура мирового уровня, 200 аэропортов, все серьезно. А с другой – подрядчик четвертого уровня с 2FA, которую просто не включили.
Случай напомнил историю с «говорящими» светофорами в Калифорнии, где хакеры подменили голосовые сообщения на шутки Илона Маска и Марка Цукерберга. Производитель четко предупреждал покупателей: смените заводские пароли, настройте безопасность. А в итоге устройства остались с учетными данными по умолчанию, и любой желающий мог залезть в настройки.
Когда такое происходит в аэропортах, последствия могут исчисляться не только сотнями миллионов долларов, но и жизнями людей. А всего-то нужно было включить двухфакторную аутентификацию.
Фокус с исчезновением
Что случилось:
Корейская налоговая случайно засветила пароль от криптокошелька должника, в результате чего пропало 4,8 млн долларов.
Как это произошло:
Корейские налоговики выпустили пресс-релиз о результатах рейда на должников: специальная рабочая группа изъяла около 8 миллиардов вон (примерно 5,5 миллиона долларов) у более чем сотни граждан. Часть средств была изъята в криптовалюте.
Однако при публикации фотографий изъятого служба не заметила, что в кадр попал криптокошелек Ledger с записанной на карточке сид-фразой. А это мастер-ключ, по которому можно получить полный доступ ко всем средствам на кошельке без дополнительных подтверждений.
И закономерно на следующий день с этого кошелька пропало четыре миллиона токенов PRTG суммарной стоимостью 4,8 миллиона долларов. Осталось неясным, как именно: то ли засвеченной сид-фразой воспользовались злоумышленники, то ли средства вывел сам владелец.
При этом известно, что похититель действовал методично: сначала перевел на кошелек небольшое количество Ethereum для оплаты комиссий, а потом тремя отдельными транзакциями вывел токены PRTG на подконтрольный адрес. Хитреца пока так и не нашли – будем следить за развитием событий.
Здесь даже не знаешь, что смешнее: то, что «засвета» никто не заметил при съемке, что пропустили при подготовке пресс-релиза, или что не обратили внимания при публикации. Три слоя защиты, и все три провалились.
Возможно, дело в том, что никто в этой цепочке просто не был в курсе, что такое сид-фраза, почему она так критична и что будет, если ее скомпрометировать. Но необязательно быть экспертом по криптокошелькам, чтобы запомнить правило, например, «не делиться рабочими документами» или «маскировать любые данные при публикации». Не рассчитывайте, что все в вашей компании IT-эксперты – вводите понятные правила безопасности и повышайте ИБ-грамотность во всех подразделениях. Вот, кстати, сборник советов, как делать это эффективно.
Информация обмену и возврату не подлежит
Что случилось:
Полиция Нидерландов арестовала 40-летнего мужчину после того, как по ошибке передала ему конфиденциальные документы, а он отказался их удалить.
Как это произошло:
12 февраля 2026 года мужчина из городка Риддеркерк, Нидерланды обратился в полицию, сообщив, что у него есть видео, которые могут помочь в расследовании. Сотрудник полиции решил отправить ему ссылку для загрузки видео на внутренний портал ведомства. Но случайно ошибся и отправил ссылку на скачивание файлов, фактически предоставив постороннему доступ к конфиденциальным документам.
Мужчина не использовал уязвимости и не осуществлял взлом в традиционном смысле – он просто перешел по присланной ссылке. И, не будь дураком, скачал все, что увидел. После того как полиция потребовала удалить полученные материалы, он отказался и потребовал «что-нибудь взамен». Правоохранительные органы признали, что утечка произошла по их вине, однако впоследствии мужчина был арестован по подозрению в несанкционированном доступе к компьютерной системе. По заявлению полицейских, арест, обыск и изъятие всех носителей информации были нужны, чтобы «обеспечить сохранность файлов и предотвратить их дальнейшее распространение». Да, тех самых файлов, которые сами же упустили.
Не все беды в ИБ из-за взломов и уязвимостей, часто (и очень) – достаточно чьей-нибудь банальной невнимательности. Такие инциденты не искоренить, поэтому лучше перестраховываться: например, внедрять средства контроля трафика, защиты информации, особенно если она настолько чувствительная. Автоматика способна блокировать утечки вне зависимости, случайные они или злонамеренные. Тем самым мы нивелируем человеческий фактор – самую слабую и непредсказуемую часть любой системы безопасности.
Один Пароль, Чтоб Править Всеми
Что случилось:
Энтузиаст, изучавший протоколы связи своего робота-пылесоса, неожиданно получил доступ к данным более 7000 устройств по всему миру.
Как это произошло:
Программист Сэмми Аздуфал решил управлять своим роботом-пылесосом DJI Romo с помощью контроллера PS5. Мужчина использовал Claude Code AI, с которым проанализировал протоколы связи устройства и создал собственное приложение. Когда приложение подключилось к серверам DJI, на вызов ответили около 7000 роботов-пылесосов из 24 стран.
Полученный доступ позволял Сэмми смотреть видео с камер в реальном времени, прослушивать записи с микрофонов и создавать поэтажные планы помещений. Так Аздуфал идентифицировал робота журналиста The Verge через серийный номер его робота и получил детальную информацию о его перемещениях.
Техническая причина оказалась простой: брокер сообщений MQTT, используемый DJI, не проверял права доступа к разделам внутри себя. После аутентификации с помощью одного токена устройства можно было видеть трафик других устройств в открытом виде.
Помимо пылесосов, доступными оказались портативные зарядные станции DJI Power, работающие на той же инфраструктуре.
Случай примечателен тем, как именно была обнаружена уязвимость: Аздуфал использовал ИИ-инструмент для декомпиляции мобильного приложения, изучения протокола и создания собственного клиента. Современные инструменты для написания кода снижают порог входа для проведения подобных исследований – и для обнаружения уязвимостей, и, потенциально, для их эксплуатации.
Здесь мне вспоминается старый мем: если у вас паранойя, это еще не значит, что за вами не следят. Только в данном случае за вами следят не спецслужбы, а ваш собственный пылесос. И не специально, а потому что кто-то забыл настроить контроль доступа.
«Страшилки», что умные устройства следят за каждым шагом своего владельца, давно набили оскомину. Но вот вам наглядное подтверждение – угроза не гипотетическая, а вполне реальная. «Умное» теперь все, от смартфона до розетки, но вместе с функциональностью привычных устройств растет и объем информации, которую они собирают. Где эта информация хранится? Как защищена? А главное – кто и с какой легкостью может до нее добраться?
В случае с пылесосами доступ открылся из-за того, что разработчики забыли настроить контроль доступа (или его не было вовсе? или в коде, в традициях worst practices, остался ключ?). Вдвойне показательно, что уязвимость обнаружили не хакеры, а, по сути, обычный пользователь. И заполучил карты помещений, видео с камер, записи с микрофонов – все как в шпионском триллере, только без всякого MI6 – понадобились всего несколько часов и нейросеть. А бывает и того проще: когда данные защищены паролем «11111» или просто валяются в открытом облаке.
Вывода не будет – баланс между комфортом «умного дома» и безопасностью пусть каждый ищет сам. Например, всегда есть опция с DIY– тогда в случае компрометации пенять можно будет только на себя.
«Все включено» по-испански
Что случилось:
Испанец нашел уязвимость в сервисе бронирования и отдыхал в отелях за 1 евроцент.
Как это произошло:
Молодой испанец нашел способ обмануть систему подтверждения платежей одного из крупных сервисов бронирования отелей. Уязвимость позволяла ему проводить заказы так, что в системе они выглядели полностью оплаченными, хотя реально сервис перечислял отелям лишь символическую сумму в 1 евроцент.
Молодой человек использовал эту схему неоднократно, бронируя номера стоимостью около 1000 евро за ночь. Помимо бесплатного проживания, он также опустошал мини-бары в номерах, не оплачивая содержимое.
Платформа бронирования заметила неладное, когда при регулярных перечислениях средств отелям суммы стали расходиться с заявленными. Сервис зафиксировал подозрительную активность и обратился в полицию.
В феврале 2026 года подозреваемого арестовали прямо в номере одного из мадридских отелей, который он снял по той же схеме на четыре ночи. Общий ущерб, нанесенный только этому заведению, оценивается в 20 тысяч евро, так как мошенник часто в нем останавливался.
В Национальной полиции Испании отметили, что впервые столкнулись с преступлением, совершенным с использованием такого метода. Подозреваемому вменяют неправомерный доступ к компьютерной системе и мошенничество.
Истории, когда сервисы «взламывают» находчивые пользователи, набирают обороты. Например, в минувшем феврале покупатель уговорил чат-бот техподдержки британского маркетплейса выдать ему скидку в 80% – магазин потерял тысячи фунтов стерлингов. Поэтому важно тестировать системы не только на «хакерские» уязвимости – SQL-инъекции, XSS и прочее. Обязательно проверяйте, как можно использовать ваш сервис против вас в процессе «обычной» эксплуатации.
Впрочем, попытки учесть риски и сделать сервисы безопасными тоже не всегда бывают удачными. Например, в той же Испании с января полиция внедрила систему автоматического отслеживания ДТП – для этого во всех автомобилях должен появиться маячок, в случае аварии передающий данные в Генеральную дирекцию дорожного движения, на дорожные табло и навигаторы, предупреждая других водителей. И вроде бы разработчики позаботились о безопасности водителей: маячок не привязан к номеру авто, отследить по нему конкретную машину нельзя. Вот только данные маячки передают по открытому API – и этим быстро воспользовались злоумышленники.
На основе API маячков мошенники создают карты, где отслеживают координаты аварий в реальном времени, чтобы прибывать на место происшествия быстрее экстренных служб. А потом эвакуируют авто, увозят в неизвестном направлении и требуют у водителей выкуп за возврат машины. В итоге вполне легитимный сценарий работы маячка ставит водителей под угрозу – попавшим в ДТП остается только надеяться, что подъехавший эвакуатор действительно хочет им помочь. А отказаться нельзя: за отсутствие маячка штрафуют.
Так можно ли учесть вообще все риски и обезопасить свой сервис, компанию и пользователей от всего на свете? Вряд ли, но лучше стараться – и стараться лучше. В ИБ только так: но пасаран!
Как считаете, какой инцидент больше достоин Премии Дарвина?
