Последний раз, мошенник с криптовалютой просканировал APK-файлы Android в Интернет-архиве и обнаружил тысячи утекших ключей Twitter API. После этого мошенник вложил деньги в альткоин и использовал украденные API-ключи для продвижения альткоина с помощью взломанных учетных записей Twitter. История закончилась классическим памп-энд-дампом, в результате которого крипто-мошенники заработали миллионы долларов за счет обманутых инвесторов.

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


Рынок действий GitHub

В этом сценарии мы начинаем с разработчика полного стека в Poor Corp, который пытается начать работу с автоматическими сборками и развертываниями с помощью GitHub Actions. У Poor Corp есть Дженкинс экземпляр, который они использовали в прошлом для автоматизации внутренних заданий, поэтому разработчик решает попробовать использовать его как часть конвейера CI/CD. Для начала они выполняют поиск «Дженкинс» на GitHub Marketplace, но, похоже, никаких официально выглядящих действий или приложений нет. Разработчик просматривает несколько доступных действий, предоставленных другими разработчиками на GitHub, и выбирает первое из полезных README. Наш разработчик мало что знает; он только что попал в ловушку.

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


Украденные облачные учетные данные

Разработчик Poor Corp проводит следующие несколько недель, тестируя сборки и развертывания с помощью Jenkins, и в конечном итоге доходит до того, что они автоматически развертывают производственный код с помощью GitHub Actions! Все идет хорошо, и разработчик с радостью переводит другие проекты на этот новый способ развертывания кода. А затем, в конце месяца, отдел разработчиков получает счет от своего облачного провайдера. Счет за месяц такой же большой, как бюджет отдела на год.

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

Расследование продолжается, и Poor Corp в конце концов узнает, что действие Jenkins, которое использовал их разработчик, на самом деле было вредоносным клоном хакера, о котором мы упоминали ранее. Как только разработчик начал использовать учетные данные облачного провайдера Poor Corp для развертывания кода, вредоносное действие отправило учетные данные хакеру. Имея на руках учетные данные, хакер развернул майнеры криптовалюты на новых серверах, финансируемых облачной учетной записью Poor Corp.

В конце концов, Poor Corp работала со своим облачным провайдером, чтобы оспорить плату за ресурсы, которые они не авторизовали. Им повезло, и с хакерских крипто-майнеров сняли обвинения. Что касается хакера, то не было достаточных доказательств, чтобы идентифицировать и предъявить обвинения лицу, стоящему за атакой. Хакер сохранил криптовалюту, полученную от майнинга, и предпринял дополнительные вредоносные действия, чтобы найти следующую жертву.


Уроки выучены

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

Чтобы защитить себя или свою организацию от непредвиденных расходов, убедитесь, что у вас настроены уведомления о выставлении счетов. У всех крупных облачных провайдеров есть какой-то механизм для этого, и он может спасти вас в ситуации, подобной той, которую мы только что рассмотрели. Если бы Poor Corp настроила свои собственные уведомления о выставлении счетов, они были бы предупреждены о мошеннических облачных серверах задолго до того, как пришел их ежемесячный счет за облачные услуги.

Еще один важный вывод из этой истории — проявлять должную осмотрительность при выборе сторонних действий GitHub для использования в ваших рабочих процессах. Любой может опубликовать действие на GitHub Marketplace, и хотя исходный код доступен, большинство людей не читают код действий, которые они используют. Как и разработчик Poor Corp, они просто хотят найти что-то, что работает и легко настраивается.

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

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