Погружение в 0.0.0.0 Day: как «нулевой» IP-адрес позволяет взломать локальную сеть

Специалисты Oligo Security недавно раскрыли уязвимость «0.0.0.0 Day», которая позволяет вредоносным веб-сайтам обходить защиту браузера и взаимодействовать со службами, работающими в локальной сети организации, что потенциально приводит к несанкционированному доступу и удаленному выполнению кода.

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

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

Критическая уязвимость затрагивает все основные веб-браузеры (Chromium, Firefox, Safari) и позволяет злоумышленникам взламывать локальные сети. 0.0.0.0 Day возникла вследствие того, как браузеры обрабатывают сетевые запросы, потенциально предоставляя хакерам доступ к конфиденциальным службам, работающим на локальных устройствах.

Логическая уязвимость позволяет внешним сайтам взаимодействовать с программным обеспечением, работающим локально на MacOS и Linux (localhost), и потенциально выполнять произвольный код на хосте посетителя, используя адрес 0.0.0.0 вместо localhost/127.0.0.1. Windows не подвержена этой проблеме.

Исправления в процессе: браузеры скоро заблокируют 0.0.0.0

После ответственного раскрытия информации HTTP-запросы к 0.0.0.0 теперь добавляются в стандарты безопасности с помощью запроса на комментарий (RFC), и некоторые браузеры вскоре полностью заблокируют доступ к 0.0.0.0. Адрес больше не будет разрешен в качестве целевого IP-адреса в спецификации Fetch, которая определяет, как браузеры должны вести себя при выполнении HTTP-запросов.

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

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

Исправления браузеров:

Google Chrome (и браузеры на базе Chromium, включая Edge):

0.0.0.0 Day обошла механизм PNA (Private Network Access) в Chromium, который блокирует доступ веб-сайтов к 127.0.0.1, localhost и другим частным IP-адресам через Javascript при загрузке с общедоступных веб-сайтов.

После отчета Oligo Security Chrome блокирует доступ к 0.0.0.0 (Finch Rollout), начиная с Chromium 128. Google будет постепенно внедрять изменение в течение следующих нескольких выпусков, завершив его к Chrome 133, после чего IP-адрес будет полностью заблокирован для всех пользователей Chrome и Chromium.

Стоит отметить, что процент веб-сайтов, которые сообщаются с 0.0.0.0, растет, судя по счетчикам в Chromium. Такие страницы могут быть вредоносными, и в настоящее время процент составляет 0,015% от всех веб-сайтов. При 200 миллионах сайтов в мире (по состоянию на август 2024 года) около 100 000 общедоступных сайтов могут сообщаться с 0.0.0.0. Рисунок ниже иллюстрирует этот рост.

Apple Safari: браузеры Apple основаны на движке WebKit. После отчета Oligo Security Apple внесла изменения в WebKit, которые блокируют доступ к 0.0.0.0. Компания добавила проверку IP-адреса хоста назначения. Если он состоит из одних нулей, запрос блокируется.

Mozilla Firefox: На данный момент в Firefox нет исправления. Хотя исправление находится в процессе, Firefox никогда не ограничивала Private Network Access (PNA), так что технически PNA всегда была разрешена. С этой точки зрения «нечего исправлять», поскольку PNA изначально не реализована в Firefox.

После отчета Oligo Security Mozilla изменила спецификацию Fetch (RFC), чтобы заблокировать 0.0.0.0. Firefox отдала приоритет реализации PNA, хотя она пока не реализована. В будущем в Firefox 0.0.0.0 будет заблокирован и не будет зависеть от реализации PNA.

0.0.0.0 Day – более глубокое погружение

У всех нас есть любимый браузер, и мы используем его ежедневно. Даже небраузерные приложения часто загружают ресурсы из внешних доменов, например, при использовании Google Analytics и подобных клиентских SDK или при встраивании скриптов или видео.

Разработчики всегда внедряли новаторские концепции безопасности в браузеры, такие как песочница и cookie-файлы HTTPS-ONLY, или внедрять механизм CORS (Cross Origin Resource Sharing) для защиты серверов и конечных пользователей. Все меры защиты держат вредоносные сайты, использующие CSRF-атаки, подальше от личных данных пользователей, внутренних сетей и локальных приложений.

Браузеры могут отправлять запросы практически на любой HTTP-сервер с помощью Javascript. При обработке межсайтового ответа механизмы безопасности браузера решают, какое действие предпринять:

• Valid: передать данные ответа в контекст Javascript;
• Invalid: вернуть замаскированный ответ или вызвать специальную ошибку (CORS, SOP, …).

Но иногда ответ вообще не имеет значения. С уязвимостью 0.0.0.0 Day одного запроса может быть достаточно, чтобы нанести ущерб. Прежде чем мы перейдем к деталям, немного предыстории для понимания.

Самый необычный IP: что такое 0.0.0.0?

Давайте вернемся к началу проблемы: 0.0.0.0 может использоваться несколько раз. Возможно, вы уже подумали о некоторых его использованиях: «все IP-адреса на хосте», «все сетевые интерфейсы на хосте» или просто «localhost».

RFC 1122 ссылается на 0.0.0.0, используя обозначение {0,0}:

RFC 1122 запрещает использование 0.0.0.0 в качестве адреса назначения в IPv4 и допускает его в качестве исходного адреса только при определенных обстоятельствах, например, при использовании в пакете DHCPDISCOVER во время DHCP-рукопожатия, когда IP-адрес выделяется впервые.

0.0.0.0 иногда используется в файлах /etc/hosts для блокировки определенных доменов (выступая в роли блокировщика рекламы) или, при использовании в сетевых политиках, CIDR блок 0.0.0.0/32 означает, что все IP-адреса разрешены.

Почему сайт сканирует мои порты?

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

В 2020 году выяснилось, что Ebay пытался сканировать порты посетителя сразу после загрузки сайта. Сайт использовал Javascript для сканирования портов на локальном хосте (127.0.0.1), что привело к уникальному отпечатку. Поскольку сканирование проходит в браузере, межсетевые экраны пользователя не могут предотвратить данный процесс.

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

18-летняя ошибка

Локальные и внутренние службы всегда были основной целью для атак. В 2006 году Mozilla сообщила об одной интересной проблеме безопасности, которая была обнаружена ещё до первого релиза Chrome в 2008 году. Примечательно, что отчет об ошибке 18-летней давности все еще открыт.

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

В то время внутренние сети (и Интернет в целом) были небезопасны по своей сути: многие службы не имели аутентификации, не говоря уже о сертификатах SSL и HTTPS, которые существовали не везде. Веб-сайты загружались через незащищенный HTTP, и злоумышленники постоянно использовали браузер для вредоносных целей.

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

Прошло 18 лет, появились сотни комментариев, но ошибка остается открытой и по сей день.
За эти 18 лет проблема была закрыта, открыта повторно, переквалифицирована в «серьезную» или «критическую» и даже эксплуатировалась в реальных условиях. Например, в июне 2023 года специалист безопасности Google Дэвид Эдриан сообщил о нескольких случаях использования уязвимости 0.0.0.0 Day.

Сопровождающим пришлось нелегко, чтобы прийти к единому мнению относительно природы ошибки – это «уязвимость», это касается только Firefox или это запрос на улучшение? Некоторые разработчики Firefox утверждали, что это не ошибка и не функция. Тем не менее, отчет об ошибке останется открытым пока Firefox не реализует PNA.

Для запуска ошибки было достаточно одного HTTP-запроса — ответ не имел значения. Примеры вредоносных скриптов уже были задокументированы в 2006 году в атаках на домашние маршрутизаторы:

Отсутствие стандартизации было основным источником всех страданий, создавая очевидную необходимость разработки базового механизма безопасности во всех браузерах. Мир жаждал стандарта, который расширил бы Cross Origin Resource Sharing (CORS) во всех основных браузерах, позволяя им различать локальные, частные и публичные сети.

Компания Google смело заполнила образовавшуюся нишу, предложив Private Network Access.

Что такое PNA (Private Network Access)?

Долгое время было непонятно, как браузеры должны себя вести, когда они делают запросы к локальным или внутренним сетям из менее приватных контекстов. Домены вроде attacker.com не должны иметь возможности связаться с localhost — ни в одном реальном сценарии.

Все основные браузеры полагались на CORS. CORS очень помогает, но его производительность зависит от содержимого ответа, поэтому запросы все равно создаются и отправляются. История доказала, что один HTTP-запрос может атаковать домашний маршрутизатор — и, если это все, что нужно, каждый пользователь должен иметь возможность предотвратить выполнение такого запроса.

PNA расширяет CORS, ограничивая возможность веб-сайтов отправлять запросы серверам в частных сетях. PNA предлагает различать публичные, частные и локальные сети. Страницы, загруженные в менее защищенном контексте, не смогут взаимодействовать с более защищенными контекстами. Например, attacker.com не может связаться с 127.0.0.1 или 192.168.1.1, поскольку эти IP-адреса считаются более закрытыми. На картинке ниже показана связь между общедоступными, частными и локальными сетями в PNA.

Чем отличается PNA от CORS? Хотя CORS защищает непреднамеренный контент только от загрузки в небезопасных контекстах, он делает это на уровне ответа. Ресурсы, используемые ответом, маскируются или удаляются. PNA усиливает эту возможность, предоставляя шанс предотвратить отправку запроса в целом.

Тестируем 0.0.0.0: обход PNA

Согласно текущей спецификации PNA, следующие сегменты IP считаются частными или локальными:

В ходе исследования обнаружилось, что 0.0.0.0 нет в списке. Специалисты Oligo Security считали, что как часть PNA сайты не могли отправлять запросы на 0.0.0.0. Согласно спецификации, адрес 0.0.0.0. не должен использоваться в качестве цели.

Чтобы выяснить это, исследователи запустили фиктивный HTTP-сервер на localhost (127.0.0.1), а затем попытались получить к нему доступ через внешний домен из Javascript, используя 0.0.0.0.

В результате запрос дошел до сервера.

Что произошло?

1. В общедоступном домене (.com) браузер отправил запрос на 0.0.0.0.;

2. Фиктивный сервер прослушивает 127.0.0.1 (только на интерфейсе loopback, а не на всех сетевых интерфейсах);

3. Сервер на localhost получает запрос, обрабатывает его и отправляет ответ;

4. Браузер блокирует распространение содержимого ответа в Javascript из-за CORS.

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

Это и есть обход текущей реализации PNA и неотъемлемый недостаток браузеров. Специалисты сообщили о своей находке представителям всех браузеров в рамках ответственного раскрытия. Однако для доказательства концепции нужны реальная угроза и реальный вектор атаки.

Поиск уязвимых локальных приложений

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

Когда службы используют localhost, они предполагают ограниченную среду. Такое предположение, которое может быть ошибочным (как в случае 0.0.0.0 Day), приводит к небезопасным реализациям сервера. Например, многие приложения пропускают вызовы CSRF-токена и ставят под угрозу авторизацию или аутентификацию, поскольку приложения должны работать в строго контролируемой сетевой среде.

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

Чтобы найти локальное приложение, которое было бы уязвимо к атаке из браузера, сначала нужен HTTP-сервер, работающий на локальном порту (сетевой интерфейс localhost). Чтобы получить удаленное выполнение кода, нужно, чтобы у службы была HTTP-маршрутизация, которая могла бы записывать, настраивать или изменять файлы и конфигурации.

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

ShadowRay из браузера

Специалисты Oligo взяли за основу обнаруженную в марте кампанию ShadowRay, которая нацелена на вычислительные мощности ИИ. Уязвимость предоставила хакерам возможность эксплуатации в незащищенных средах. Oligo доказала, что можно выполнить такую атаку из браузера, используя 0.0.0.0 в качестве вектора атаки.

Сначала в правом терминале мы запускаем локальный кластер Ray на localhost. Затем в левом терминале мы запускаем сокет, который прослушивает новые соединения, чтобы открыть Reverse Shell. Затем жертва нажимает на ссылку в фишинговом письме, которая запускает эксплойт. Эксплойт открывает Reverse Shell на машине жертвы.

Вот пример кода, который использовался для эксплойта.

‍Как атака работает в разных браузерах:

Google Chrome

Apple Safari

Mozilla FireFox

Запуск ShadowRay из браузера — это всего лишь одна из огромного числа атак удаленного выполнения кода (Remote Code Execution, RCE), реализованных с помощью такого подхода. Рассмотрим несколько векторов атак с использованием 0.0.0.0. Day.

Selenium Grid

В недавней кампании SeleniumGreed злоумышленники использовали общедоступные серверы Selenium Grid для получения первоначального доступа к системам организаций, используя известные RCE-уязвимости. Было обнаружено, что на локальных экземплярах Selenium Grid RCE возможен при отправке POST-запроса на http[:]//0.0.0.0:4444/ с созданной полезной нагрузкой.

Еще один интересный вектор атаки: использование локального кластера Selenium Grid для просмотра сайтов с использованием небезопасных конфигураций браузера с целью получения доступа к внутренним доменам и частным записям DNS за VPN.

Pytorch Torchserve (ShellTorch)

В июле 2023 года Oligo раскрыла несколько новых критических уязвимостей ShellTorch разработчикам PyTorch Amazon и Meta*, которые приводят к удаленному выполнению кода в PyTorch TorchServe, что в конечном итоге позволяет злоумышленникам получить полный доступ к серверу.

Специалисты по ИИ, использующие TorchServe во внутренней сети (локально или с использованием переадресации портов), могут использовать уязвимости также через 0.0.0.0, что приводит к компрометации локального кластера TorchServe, который находится за брандмауэрами и WAF.

Идентификация возвращающихся пользователей на основе открытых портов

Другим интересным вектором атаки является возможность путем сканирования портов распознавать анонимных пользователей, даже тех, у которых нет cookie-файлов и которые никогда не входили в систему. Результаты локального сканирования портов могут быть перепроверены с помощью дополнительных данных, таких как User-Agent, IP-адрес и другие идентификаторы, которые можно получить через сервисы сканирования цифровых отпечатков.

Сканирование показало, что различные персоны внутри организации используют следующие порты:

• TeamViewer (порт 5938);
• Selenium Grid (порт 4444);
• Ray (порт 8265).

Насколько локален ваш Localhost?

Пока PNA не будет полностью развернут, публичные веб-сайты могут отправлять HTTP-запросы с помощью Javascript для получения доступа к службам в локальной сети. Чтобы это изменилось, нужно стандартизировать PNA, а также нам нужны браузеры для реализации PNA в соответствии со стандартом.

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

При отправке запроса, если заголовки CORS отсутствуют в ответе, вредоносный Javascript-код не сможет прочитать содержимое ответа. CORS остановит ответ только до того, как он распространится на JavaScript, но запросы типа «opaque» могут быть отправлены в режиме «no-cors» и успешно достигнуть сервера (если нас не волнуют ответы).

В демонстрации Oligo Security доказано, что, используя 0.0.0.0 вместе с режимом «no-cors», киберпреступники могут использовать публичные домены для атаки на службы, работающие на локальном хосте, и даже получить возможность выполнения произвольного кода, используя всего один HTTP-запрос.

На данный момент браузеры приоритизировали исправления и внесли критические изменения, заблокировав 0.0.0.0 как целевой IP. Было важно иметь совместное исправление, чтобы избежать ситуации, в которой браузеры бы «подкидывали друг другу 0day» во время исправлений.

Как защитить локальные приложения от 0.0.0.0 Day?

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

Специалисты Oligo Security привели самые важные рекомендации:

1. Реализуйте заголовки PNA;
2. Проверьте HOST-заголовок запроса к localhost или 127.0.0.1. для защиты от атак DNS Rebinding;
3. Не доверяйте локальной сети просто потому, что она «локальная» — добавьте минимальный уровень авторизации, даже при работе на localhost. Разработчики Jupyter Notebook отлично справились с этой задачей, добавив токен по умолчанию;
4. По возможности используйте HTTPS;
5. Внедряйте токены CSRF в свои приложения, даже если они локальные;
6. Помните, что браузеры действуют как шлюзы, и во многих браузерах есть возможность маршрутизации ко внутренним пространствам IP-адресов.

* Компания Meta и её продукты признаны экстремистскими, их деятельность запрещена на территории РФ.