ServiceNow уведомляет клиентов об обнаружении и устранении уязвимости, которая могла привести к утечке данных через неаутентифицированную конечную точку API на затронутых инстансах.
Проблема получила огласку после того, как клиенты начали обсуждать уведомления о безопасности от ServiceNow и сообщения о подозрительной активности, связанной с их средами.
Согласно рекомендациям компании, об уязвимости впервые сообщили в рамках программы Bug Bounty ServiceNow в апреле, что послужило поводом для расследования и последующих обновлений безопасности. ServiceNow сообщила, что клиенты, использующие размещенные решения, получили обновление безопасности (KB3067321) 5 июня, в то время как для развертываний с самостоятельным размещением были выпущены инструкции (KB3067372).
Похоже, что уязвимость затронула арендаторов, использующих определенные версии и конфигурации. Кори Михал, CISO компании AppOmni, занимающейся безопасностью SaaS и ИИ, сообщил, что проблема связана с «неаутентифицированной, доступной из интернета конечной точкой API ServiceNow», к которой можно было получить доступ без аутентификации при наличии определенных условий.
«На практике любой, кто знал URL конечной точки и умел структурировать запрос, мог получить доступ к данным из затронутого инстанса ServiceNow без предварительной аутентификации», — сказал Михал.
Поскольку ServiceNow часто хранит запросы на ИТ-обслуживание, информацию о сотрудниках и внутренние данные безопасности, несанкционированный доступ к инстансам клиентов может представлять значительный риск для предприятий.
В рекомендациях говорится, что подозрительная активность, отмеченная в уведомлениях о безопасности, отправленных клиентам, на данный момент может быть связана с исследователями безопасности, изучавшими уязвимость.
Затронута конечная точка API из определенного релиза
Хотя в рекомендациях ServiceNow было мало технических подробностей о самой уязвимости, клиенты, обсуждавшие проблему на Reddit, упоминали затронутую конечную точку как «/api/now/related_list_edit/create» — API, по сообщениям, который можно было опрашивать без аутентификации при определенных обстоятельствах. API поставлялся с флагом «requires_authentication = false».
Те же обсуждения указывают на то, что затронутым был только австралийский релиз ServiceNow, поскольку ServiceNow якобы сообщила об этом клиентам через частные уведомления о безопасности. Это наводило на мысль, что изменения, специфичные для релиза, могли сыграть роль в утечке.
Однако клиенты были далеки от убеждения, что проблема ограничивалась одним релизом. Несколько участников предположили, что уязвимыми могли быть и более старые релизы с определенными конфигурациями.
«Не думайте, что вы в безопасности только потому, что используете другой релиз», — прокомментировал один из них. Говоря о затронутом API, пользователь добавил: «Это флаг конфигурации, а не изменение кода, специфичное для релиза. Стоит проверить таблицу Scripted REST API вашего инстанса и провести аудит любых ресурсов, где этот флажок снят, особенно тех, которые не изменялись с 2022 года».
Исследователи, злоумышленники или и те, и другие?
Важный вопрос, связанный с инцидентом, заключается в том, была ли активность, наблюдаемая в затронутых средах ServiceNow, исключительно работой исследователей безопасности, или же уязвимостью могли воспользоваться и злоумышленники.
ServiceNow подтвердила, что несанкционированный доступ можно полностью отнести на счет попыток исследования. «У нас есть основания полагать, что наблюдаемая активность может быть связана с исследователями безопасности или клиентами, проводящими собственные исследования», — заявила компания, добавив «однако». «Наше расследование продолжается и подлежит дополнительной проверке».
Михал призвал к осторожности, прежде чем предполагать, что вся наблюдаемая активность была доброкачественной.
«Вопрос атрибуции менее ясен», — сказал он. «По крайней мере одна система, публично связанная с эксплуатацией этой уязвимости, по-видимому, нацеливалась на арендаторов других SaaS-платформ с аналогичными слабостями в неаутентифицированном доступе. Так что, хотя активность исследователей, безусловно, имела место, я бы не спешил утверждать, что вся наблюдаемая активность была доброкачественным исследованием, пока расследование не будет завершено».
Клиентам настоятельно рекомендуется проводить расследование, а не только устанавливать исправления
Хотя ServiceNow заявляет о наличии исправлений и мер по смягчению последствий, Михал предупреждает, что применение обновлений должно быть лишь первым шагом.
По его словам, организациям, безусловно, следует убедиться, что обновление безопасности от 5 июня было применено или что рекомендованные меры по смягчению последствий были реализованы для развертываний с самостоятельным размещением. Не менее важно также изучить исторические журналы на предмет доказательств эксплуатации.
«Просмотрите журналы доступа и транзакций ServiceNow на предмет известных индикаторов компрометации (IoC), неаутентифицированных запросов к затронутой конечной точке API, а также необычных запросов к таблицам или полям, желательно за последние 90 дней», — сказал он. «Если будет обнаружена подозрительная активность, определите, к каким данным был получен доступ, и рассматривайте это как расследование инцидента, а не просто как упражнение по установке исправлений».
ServiceNow заверила клиентов, что меры по смягчению последствий приняты и что компания продолжает внутреннее расследование инцидента. «На основании нашего текущего расследования, похоже, что подмножество инстансов клиентов было успешно опрошено в рамках этой деятельности, и для затронутых клиентов были созданы специальные случаи поддержки», — отметила компания в своих рекомендациях.
Связанная активность с подтвержденных IP-адресов исследователей была проверена на предмет возможной передачи, использования или хранения данных. Сообщается, что вовлеченные исследователи заявили ServiceNow, что «они опрашивали таблицы и поля только с целью проверки своих находок и отправки отчетов по программе Bug Bounty».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Shweta Sharma
