GitHub расследует криптоджекинг в своем облаке

GitHub расследует криптоджекинг в своем облаке

GitHub расследует криптоджекинг в своем облаке

Хостер ИТ-проектов GitHub проводит расследование попыток вовлечения его серверов в добычу криптовалюты. Атаки на облачную инфраструктуру веб-сервиса в рамках криптоджекинг-кампании наблюдаются с осени; для внедрения и запуска майнера злоумышленники используют GitHub Actions.

Функция  GitHub Actions позволяет разработчикам программного обеспечения автоматизировать рабочий процесс. Это дополнительное удобство обеспечивает автозапуск выполнения задач; триггером при этом является то или иное событие в репозитории — пушинг кода, создание релиза, открытие проблемы через баг-трекер и т. п.

Как стало известно The Record, использовать серверы GitHub для майнинга пытается как минимум одна преступная группа. Отыскав репозиторий с активным GitHub Actions, злоумышленники создают форк, добавляют в код вредоносное действие и создают пул-запрос на включение внесенных изменений в исходник.

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

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

Источник The Record также сообщил, что в ходе одной атаки он насчитал до 100 майнеров, запущенных на серверах GitHub. Более того, регистрируя учетные записи, злоумышленники иногда их используют для создания сотен пул-запросов с вредоносным кодом. К сожалению, блокировка аккаунтов в данном случае мало помогала — авторы атак тут же открывали новые.

Признаков иного вмешательства в проекты законных пользователей веб-сервиса пока не выявлено. На данный момент атакующие сосредоточены лишь на использовании облачной инфраструктуры GitHub для майнинга криптовалюты.

Старая уязвимость в telnetd вернулась спустя 27 лет

Уязвимость из конца 90-х неожиданно вернулась и снова позволяет получить полный root-доступ к серверу без аутентификации. Об этом рассказал исследователь в области кибербезопасности Джастин Шварц, проанализировавший проблему в telnetd — демоне устаревшего, но всё ещё используемого протокола Telnet.

По словам Шварца, речь идёт о фактическом «возрождении» CVE-1999-0073 — известной уязвимости, которую многие давно считали закрытой страницей в истории.

Однако в современных реализациях обнаружился схожий механизм, позволяющий обойти проверку подлинности и повысить права. Проблема кроется в том, как telnetd запускает процесс /bin/login в контексте root-to-root.

В таком режиме ядро выставляет флаг AT_SECURE в ноль. А это значит, что динамический линкер не переходит в защищённый режим исполнения. В результате ответственность за очистку переменных окружения ложится на сам telnetd. Именно в этот момент, по словам исследователя, всё идёт не так.

Если демон не фильтрует переменные окружения должным образом, атакующий может подменить их и заставить систему загрузить вредоносную библиотеку (shared object). Шварц продемонстрировал технику повышения привилегий, при которой создаётся копия /bin/sh с SUID/SGID-правами. Фактически это даёт полный контроль над системой.

Ключевой момент: для эксплуатации не требуется никакой аутентификации через telnet. Повышение привилегий происходит без входа в систему.

Шварц считает, что проблема связана с давним подходом к фильтрации и использованием «чёрных списков» переменных. Такой метод, по его мнению, оказался ненадёжным и оставлял лазейки почти 27 лет. В качестве решения он предлагает перейти к модели «белого списка», как это реализовано в OpenSSH, где разрешён строго ограниченный набор безопасных переменных.

Шварц также предлагает объединить проблему в единый CVE с формулировкой «Некорректная очистка среды окружения в telnetd», чтобы закрыть как старые векторы, так и новый сценарий с динамическим линкером.

При этом рабочий код эксплойта исследователь публиковать не стал, чтобы не спровоцировать волну кибератак.

Напомним, в пролом месяце мы писали про ещё критическую уязвимость в telnetd, которая жила почти 10 лет и давала root-доступ.

RSS: Новости на портале Anti-Malware.ru