Растущая проблема зомби-API и увеличение поверхности атаки

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

Хотя API полезен для маркетинга и получения дохода, добавление API и конечных точек расширяет поверхность атаки. Наличие API — это дополнительный риск, которым можно управлять, но все конечные точки должны строго контролироваться и защищаться. Большинство администраторов согласны с тем, что API необходимо контролировать, но быстро развивающаяся бизнес-среда с многочисленными обновлениями и развертываниями может потерять контроль над API и неосознанно добавить риск кибербезопасности, называемый «API-зомби».

Что такое зомби-API?

Зомби-API — это (в общих чертах) забытая и игнорируемая инфраструктура, которая остается доступной для использования, но организации не подозревают о ее существовании. API-интерфейсы Zombie можно создавать в небольших или крупных средах, но часто они создаются в средах, где ИТ-ресурсы создаются без строгих процедур обеспечения и документирования. Контроль изменений помогает избежать ситуаций с зомби-API, но также может произойти аварийное развертывание или настройка, выполняемая для исправления конкретной критической ошибки.

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

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

API-интерфейсы-зомби могут создаваться разными способами со своими крайними случаями, даже с использованием самых строгих процедур контроля изменений. Независимо от того, происходят ли они из-за ошибок или недоразумений, зомби-API являются формой тень ИТ это может быть особенно опасно для защиты данных. Без мониторинга злоумышленник может получать данные в течение нескольких месяцев без каких-либо ограничений или ограничений скорости. Любое исследование уязвимостей или их использование не будет регистрироваться, поэтому типичная аналитика кибербезопасности не уведомит администраторов об аномальном трафике.

Как хакеры находят зомби-API?

Точно так же, как существует множество способов создания зомби-API в зависимости от ситуации, то же самое можно сказать и о поиске зомби-API. Хакеры могут найти конечную точку с помощью обратного проектирования кода, просмотра репозиториев с открытым исходным кодом или с помощью концепции, называемой «фаззинг». Фаззинг — это тип обнаружения, при котором пишутся сценарии для выполнения запросов к общим именам конечных точек API. Например, конечная точка API, используемая для аутентификации, обычно имеет конечную точку с именем «/login», «/authenticate» или чем-то подобным. Для обнаружения конечных точек отправляются запросы к различным общим именам конечных точек в вашей инфраструктуре.

Обнаружение из репозиториев с открытым исходным кодом является обычным явлением. Репозитории с открытым исходным кодом также уязвимы для раскрытия секретов, а это означает, что разработчики могут забыть удалить ссылки на закрытые ключи, учетные данные для аутентификации и другие личные данные. Ссылки на конечные точки API также доступны для обнаружения и будут проверены на наличие уязвимостей. Если вашей организации не известны конечные точки, указанные в коде, их можно проверить без каких-либо мер по смягчению последствий или ограничения скорости.

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

Реальные утечки данных из-за зомби-API

Хорошим примером нормального функционирования API, но используемого для незаметного перечисления данных, является Инцидент с JustDial . JustDial — один из крупнейших местных каталогов Индии, имеющий более 100 миллионов пользователей. В 2019 году исследователь безопасности обнаружил, что JustDial имеет зомби-API, открытый для публичного Интернета без какого-либо мониторинга. API возвращал такую информацию, как имя, адрес электронной почты, номер мобильного телефона, адрес и пол, каждому, кто отправлял запрос к конечной точке. Никакой аутентификации не требовалось, и JustDial не отслеживал этот инцидент.

После того, как исследователь безопасности обнаружил API-зомби, JustDial заявил, что устранил инцидент, но та же проблема была обнаружена снова в 2020 году. Неясно, была ли какая-либо третья сторона, кроме исследователя безопасности, но поскольку конечная точка была открыта для общедоступного Интернета с мониторинга нет, JustDial не может оценить степень кражи данных.

Другой пример — Facebook, одна из крупных технологических компаний Сан-Франциско, известная одними из лучших разработчиков на рынке. У Facebook было несколько примеров зомби-API. В 2016 году разработчики развернули субдомен (mbasic.beta.facebook.com), чтобы протестировать функцию сброса пароля. Производственная версия API имела ограничения по скорости, поэтому злоумышленники не могли подобрать шестизначный код доступа, отправленный пользователям для сброса паролей. Бета-версия не имела этого ограничения, поэтому шестизначный пароль можно было подобрать в течение нескольких секунд, что ограничивалось только подключением к Интернету, пропускной способностью и скоростью внутренней обработки конечных точек API.

В 2018 году Facebook пострадал от еще одного API-атака зомби . Уязвимость была обнаружена в функции Facebook «Просмотреть как». Эта функция позволяла пользователям просматривать свои профили так, как их видят другие. Конечная точка API для этой функции не была заблокирована и не отслеживалась, поэтому злоумышленники могли просматривать профили других пользователей и украсть их токены доступа. Используя токен доступа, злоумышленник может украсть профиль пользователя и его данные. По оценкам Facebook, это затронуло 40 миллионов пользователей, и 90 миллионам пользователей пришлось пройти повторную аутентификацию, чтобы гарантировать, что их токен доступа не был украден.

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

Обнаружение зомби-API

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

Чтобы справиться с потенциальными API-интерфейсами-зомби, администраторы часто устанавливают в сети агенты для обнаружения трафика. Агенты собирают данные о трафике и обнаруживают открытые соединения на серверах и другой сетевой инфраструктуре. Проблема с этой стратегией заключается в том, что зомби-API часто остаются бездействующими, без трафика и запросов, пока они не будут обнаружены. Они могут быть обнаружены разработчиками, операторами или третьими лицами в Интернете. Трафик будет регистрироваться только после того, как третья сторона обнаружит конечную точку, но это не означает, что запросы будут вызывать оповещения. Зомби-API позволит выполнять стандартные запросы без каких-либо «взломов» или искаженных запросов. Именно это делает зомби-API такими опасными для раскрытия данных.

Использование искусственного интеллекта для обнаружения API-интерфейсов зомби

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

Первым шагом является сканирование кода на наличие ссылок на API. Эти API могут быть внешними или внутренними, но вам следует сосредоточиться на внутренних API, поскольку эта инфраструктура влияет на ваши собственные данные. Ссылки могут находиться в многочисленных репозиториях, как активных, так и устаревших. Вы можете даже не знать, что ссылки есть в вашем коде, но сканирование обнаружит их, и список можно будет отправить в искусственный интеллект (ИИ).

Далее идет модель большого языка (LLM), используемая для приема и анализа журналов событий. Журналы событий потенциально могут занимать гигабайты или терабайты построчных данных. Журналы событий имеют решающее значение для кибербезопасности и мониторинга использования инфраструктуры, поэтому их следует настроить для серверов, на которых размещены API. Если конечная точка API упоминается в коде, но событий трафика мало или вообще нет, возможно, у вас API-зомби. API со ссылками и многочисленными журналами событий используются и отслеживаются, поэтому их нельзя считать API-зомби.

Использование LLM для обработки аналитики по каждой ссылке на конечную точку API требует времени, но результаты могут удивить администраторов, не знающих об активных API в их среде. В качестве примера практический пример Domino's Pizza India недавно обнаружено 189 зомби-API, 11% из которых связаны с личной информацией (PII). Открытие было сделано после сканирования 2063 конечных точек и 2,2 дня анализа журналов событий во всей среде Domino's Pizza India.

Стоит ли отслеживать API-интерфейсы-зомби?

Ответ: «Да!» Зомби-API могут оставить данные ваших клиентов, внутренние данные или другую важную информацию открытой для раскрытия. В условиях соблюдения требований подобная оплошность может стоить миллионов штрафов. Судебные разбирательства, ущерб бренду, влияние на доходы и ряд других негативных последствий связаны с неконтролируемой инфраструктурой, которая приводит к утечке данных.

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