Мы взломали ИИ Gemini от Google и опубликовали его исходный код

В 2024 году мы опубликовали блог-пост We Hacked Google A.I. for $50,000, в котором рассказали, как в 2023 году мы отправились в Лас-Вегас вместе с Джозефом «rez0» Тэкером, Джастином «Rhynorater» Гарднером и мной, Рони «Lupin» Карта, в настоящее путешествие по взлому, которое прошло от Лас-Вегаса через Токио до Франции – всё ради поиска уязвимостей в Gemini на мероприятии Google LLM bugSWAT. И, что вы думаете? Мы сделали это снова …

Мир генеративного искусственного интеллекта (GenAI) и больших языковых моделей (LLMs) по-прежнему остаётся диким Западом в сфере технологий. С момента появления GPT гонка за лидерством в области LLM только накаляется, и такие технологические гиганты, как Meta, Microsoft и Google, стремятся создать лучшую модель. Но теперь на сцене появляются и Anthropic, Mistral, Deepseek и другие, оказывающие масштабное влияние на индустрию.

Пока компании спешат внедрять AI‑ассистентов, классификаторы и всевозможные инструменты на базе LLM, остаётся один важный вопрос: строим ли мы системы с учётом безопасности? Как мы подчёркивали в прошлом году, стремительное принятие технологий иногда заставляет нас забывать о базовых принципах защиты, открывая дорогу как новым, так и старым уязвимостям.

ИИ-агенты стремительно становятся следующим прорывом в мире искусственного интеллекта. Эти интеллектуальные сущности используют продвинутые цепочки рассуждений – процесс, в котором модель генерирует логически связанную последовательность внутренних шагов для решения сложных задач. Документируя ход своих мыслей, агенты не только улучшают способность принимать решения, но и обеспечивают прозрачность, позволяя разработчикам и исследователям анализировать и совершенствовать их работу. Такая динамичная комбинация автономного действия и видимых рассуждений прокладывает путь к созданию ИИ-систем, которые становятся более адаптивными, понятными и надёжными. Мы наблюдаем, как появляется всё больше приложений – от интерактивных ассистентов до сложных систем поддержки принятия решений. Интеграция цепочек рассуждений в ИИ-агентах задаёт новый стандарт того, чего эти модели могут достичь в реальных условиях.

Надо отдать должное Google: они активно признают это новое направление в безопасности ИИ и начали работать над ним ещё на ранних этапах. Их мероприятия «LLM bugSWAT», проводимые в таких ярких местах, как Лас-Вегас, свидетельствуют о приверженности компании проактивным подходам в области red teaming для проверки безопасности. Эти события призывают исследователей со всего мира тщательно тестировать свои ИИ-системы, выявляя уязвимости, которые в противном случае могли бы ускользнуть от внимания.

И угадайте что? Мы снова откликнулись на призыв в 2024 году! Джастин и я вернулись на bugSWAT в Лас-Вегасе, и на этот раз наши усилия принесли значительные результаты. Благодаря совершенно новой уязвимости в Gemini, о которой мы сейчас расскажем, нам выпала невероятная честь получить звание Most Valuable Hacker (MVH) на этом году в Лас-Вегасе!

Так что готовьтесь погрузиться в дебри ещё раз. Это не просто повторение предыдущей акции – впереди абсолютно новая уязвимость, которую мы собираемся вам продемонстрировать ;)

Обнаружение нового Gemini

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

Все началось с простой команды. Мы попросили Gemini:

run hello world in python3

Gemini сгенерировал код, а интерфейс предложил заманчивую кнопку «Запустить в Sandbox». Заинтригованные, мы начали исследовать этот функционал.

Песочница Python в Gemini – безопасное пространство… или нет?

На тот момент Gemini предоставлял интерпретатор Python в виде песочницы. Представьте себе безопасное пространство, где можно запускать Python-код, сгенерированный самим ИИ, или даже собственные скрипты, прямо внутри среды Gemini. Эта песочница, работающая на базе Gvisor от Google в окружении GRTE (Google Runtime Environment), спроектирована с упором на безопасность. Идея заключается в том, что вы можете экспериментировать с кодом, не рискуя повредить основную систему – важная возможность для разработки и тестирования.

gVisor — это микроядро, работающее в пространстве пользователя, разработанное Google, которое служит связующим звеном между контейнеризованными приложениями и операционной системой хоста. Перехватывая системные вызовы приложений, оно устанавливает строгие границы безопасности, уменьшая риск выхода из песочницы и ограничивая возможный ущерб от скомпрометированных процессов. Вместо того чтобы полагаться исключительно на традиционную изоляцию на уровне ОС, gVisor реализует минимальный, адаптированный набор функций ядра, тем самым сокращая поверхность атаки при сохранении приемлемой производительности. Этот инновационный подход повышает безопасность контейнерных окружений, делая gVisor незаменимым инструментом для безопасного запуска и управления контейнеризированными задачами.

Как исследователи безопасности и охотники за багами, мы знаем, что песочница на базе gVisor защищена множеством уровней обороны, и, насколько нам удалось выяснить, никому пока не удавалось из неё вырваться. Кстати, успешный побег из песочницы может принести награду в $100k:

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

Однако песочницы не всегда предназначены для того, чтобы из них выбирать. Во многих случаях именно содержимое песочницы может помочь нам с утечкой данных. Идея, предложенная нам сотрудником службы безопасности Google, заключалась в том, чтобы получить доступ к оболочке внутри песочницы и попытаться найти хоть какой-нибудь фрагмент информации, который не предназначался для доступа. Главная проблема заключалась в том, что эта песочница может запускать только специально скомпилированный бинарный файл Python.

Маппинг территории

Первое, что мы заметили – с фронтенда можно было полностью переписать Python-код и запустить нашу произвольную версию в песочнице. Нашим первым шагом стало изучение структуры этой песочницы. Мы подозревали, что где-то могут прятаться интересные файлы. Поскольку возможности открыть полноценную оболочку у нас не было, мы проверили, какие библиотеки доступны в этом специально скомпилированном бинарном файле Python. Выяснилось, что библиотека os присутствует! Отлично, теперь мы можем использовать её для картирования файловой системы.

Мы написали следующий код на Python:

import os

def get_size_formatted(size_in_bytes):
    if size_in_bytes >= 1024 ** 3:
        size = size_in_bytes / (1024 ** 3)
        unit = "Go"
    elif size_in_bytes >= 1024 ** 2:
        size = size_in_bytes / (1024 ** 2)
        unit = "Mb"
    else:
        size = size_in_bytes / 1024
        unit = "Ko"
    return f"{size:.2f} {unit}"

def lslR(path):
    try:
        # Determine if the path is a directory or a file
        if os.path.isdir(path):
            type_flag = 'd'
            total_size = sum(os.path.getsize(os.path.join(path, f)) for f in os.listdir(path))
        else:
            type_flag = 'f'
            total_size = os.path.getsize(path)
        
        size_formatted = get_size_formatted(total_size)
        
        # Check read and write permissions
        read_flag = 'r' if os.access(path, os.R_OK) else '-'
        write_flag = 'w' if os.access(path, os.W_OK) else '-'
        
        # Print the type, permissions, size, and path
        print(f"{type_flag}{read_flag}{write_flag} - {size_formatted} - {path}")
        
        # If it's a directory, recursively print the contents
        if type_flag == 'd':
            for entry in os.listdir(path):
                entry_path = os.path.join(path, entry)
                lslR(entry_path)
    except PermissionError:
        print(f"d-- - 0Ko - {path} (PermissionError: cannot access)")
    except Exception as e:
        print(f"--- - 0Ko - {path} (Error: {e})")

Цель этого кода – создать рекурсивную функцию, которая перечисляет файлы и директории, показывает их размер и права доступа.

Мы применили функцию для обхода директории lslR("/usr"):

Этот вызов выявил бинарный файл, расположенный по адресу /usr/bin/entry/entry_point. Звучит заманчиво!

Извлечение файла entry_point

Наш следующий шаг заключался в извлечении этого файла, но так как его размер составлял 579 Мб, прямая кодировка в base64 и вывод через фронтенд были невозможны – песочница зависала до таймаута.

Мы попытались установить исходящие TCP, HTTP и DNS-соединения для утечки информации. Интригующе, все наши попытки установить исходящие соединения завершились неудачей – песочница казалась полностью изолированной от внешней сети. Это породило интересную загадку: если песочница настолько изолирована, что не может выполнять внешние вызовы, как же она взаимодействует с сервисами Google, такими как Google Flights и другими? Ну… возможно, мы об этом расскажем позже ;D

Нам пришлось экспортировать этот бинарный файл, выводя его в консоль порциями. Для этого мы использовали функцию seek(), чтобы пройти по бинарному файлу и извлечь его полностью кусками по 10 МБ.

import base64

def read_and_encode(file_path, kilobytes):
    try:
        # Calculate the number of bytes to read
        num_bytes = kilobytes * 1024
        
        # Open the file and read the specified number of bytes
        with open(file_path, 'rb') as file:
            file_content = file.read(num_bytes)
        
        # Base64 encode the bytes
        encoded_content = base64.b64encode(file_content)
        
        # Print the encoded string
        print(encoded_content.decode('utf-8'))
    
    except FileNotFoundError:
        print(f"FileNotFoundError: {file_path} does not exist")
    except PermissionError:
        print(f"PermissionError: Cannot access {file_path}")
    except Exception as e:
        print(f"Error: {e}")

read_and_encode("/usr/bin/entry/entry_point", 10000)

Затем мы использовали [Caido](https://caido.io/), чтобы перехватить запрос через наш прокси, который выполнял вызов песочницы, получал результат и отправлял его в функцию Automate. Функция Automate позволяет отправлять запросы оптом. Этот инструмент предоставляет гибкий способ для проведения bruteforce/fuzzing – быстрой подстройки определённых параметров запросов с использованием словарей.

Примечание от Lupin: В статье это выглядит как прямолинейный процесс, но на самом деле нам потребовалось несколько часов, чтобы дойти до этого момента. Было 3 часа ночи, когда мы взламывали систему с Джастином, а я спал на клавиатуре, пока Джастин выкачивал бинарный файл с помощью Caido.

Получив все куски в base64, мы собрали файл локально и были готовы изучить его содержимое.

Как прочитать этот файл?

Команда file ?

Запуск команды file на данном бинарном файле выявил его идентификацию как

binary: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /usr/grte/v5/lib64/ld-linux-x86-64.so.2

Это подтверждает, что файл является бинарным. Ммммм, что с ним можно сделать?

Команда strings ?

Выполнив команду strings, мы получили особенно интересный вывод с множественными упоминаниями google3 – внутреннего репозитория Google. Это указывало на наличие внутренних путей к данным и фрагментов кода, которые никогда не предназначались для публичного доступа, что явно свидетельствует о том, что бинарный файл содержит следы проприетарного ПО Google. Но несёт ли это реальную угрозу безопасности?

Binwalk FTW!

Настоящий прорыв произошёл при использовании Binwalk. Этот инструмент сумел извлечь целую файловую структуру из бинарного файла, выявив подробную схему песочницы. Извлечение обнаружило множество директорий и файлов, рисуя детальную картину внутренней архитектуры и раскрывая компоненты, от которых наша реакция была: … OMG.

Подождите… это внутренний исходный код?

При изучении данных, полученных с помощью binwalk, мы неожиданно обнаружили внутренний исходный код. Извлечённые файлы включали целые директории с проприетарным исходным кодом Google. Но насколько он конфиденциален?

Каталог Google3 с Python-кодом

В извлечённой с помощью binwalk структуре мы обнаружили каталог google3 со следующими файлами:

total 2160
drwxr-xr-x   14 lupin  staff   448B Aug  7 06:17 .
drwxr-xr-x  231 lupin  staff   7.2K Aug  7 18:31 ..
-r-xr-xr-x    1 lupin  staff   1.1M Jan  1  1980 __init__.py
drwxr-xr-x    5 lupin  staff   160B Aug  7 06:17 _solib__third_Uparty_Scrosstool_Sv18_Sstable_Ccc-compiler-k8-llvm
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 assistant
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 base
drwxr-xr-x    5 lupin  staff   160B Aug  7 06:17 devtools
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 file
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 google
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 net
drwxr-xr-x    9 lupin  staff   288B Aug  7 06:17 pyglib
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 testing
drwxr-xr-x    9 lupin  staff   288B Aug  7 06:17 third_party
drwxr-xr-x    4 lupin  staff   128B Aug  7 06:17 util

В каталоге assistant также обнаружен внутренний код Gemini, связанный с RPC-вызовами (используемыми для обработки запросов через такие инструменты, как YouTube, Google Flights, Google Maps и т.д.). Структура данного каталога выглядит следующим образом:

.
├── __init__.py
└── boq
    ├── __init__.py
    └── lamda
        ├── __init__.py
        └── execution_box
            ├── __init__.py
            ├── images
            │   ├── __init__.py
            │   ├── blaze_compatibility_hack.py
            │   ├── charts_json_writer.py
            │   ├── format_exception.py
            │   ├── library_overrides.py
            │   ├── matplotlib_post_processor.py
            │   ├── py_interpreter.py
            │   ├── py_interpreter_main.py
            │   └── vegalite_post_processor.py
            ├── sandbox_interface
            │   ├── __init__.py
            │   ├── async_sandbox_rpc.py
            │   ├── sandbox_rpc.py
            │   ├── sandbox_rpc_pb2.pyc
            │   └── tool_use
            │       ├── __init__.py
            │       ├── metaprogramming.py
            │       └── runtime.py
            └── tool_use
                ├── __init__.py
                └── planning_immersive_lib.py

8 directories, 22 files

Более детальный взгляд на Python-код

Внутри файла google3/assistant/boq/lamda/execution_box/images/py_interpreter.py фрагмент кода выглядит следующим образом:

# String for attempted script dump detection:
snippet = (  # pylint: disable=unused-variable
    "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"  # pylint: disable=unused-variable
)

Этот фрагмент, по всей видимости, служит защитой от несанкционированного дампа скриптов, подчёркивая, что код никогда не был предназначен для публичного доступа.

После тщательного анализа оказалось, что наличие, казалось бы, внутреннего кода Google3 было преднамеренным… Жаль, не повезло)

Изучение основной логики песочницы

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

Это было реализовано посредством Python-класса google3.assistant.boq.lamda.execution_box.sandbox_interface, который предоставлял различные функции, такие как _set_reader_and_writer. Пример функции:

from __future__ import annotations

import io

def _set_reader_and_writer(
    reader_handle: io.BufferedReader | None,
    writer_handle: io.BufferedWriter | None,
) -> None:
    """Sets the reader and writer handles for rpcs.
    
    Should be called before running any user code that might
    import async_sandbox_rpc
    
    Args:
    reader_handle: the handle through which to receive incoming RpcResponses. If
      None will default to legacy behavior (/dev/fd/3)
    writer_handle: the handle through which to receive incoming RpcRequests. If.
      None will default to legacy behavior (/dev/fd/4)
    """
    with _INIT_LOCK:
        global _READER_HANDLE
        global _WRITER_HANDLE
        _READER_HANDLE, _WRITER_HANDLE = reader_handle, writer_handle

А также функция для запуска инструмента:

def run_tool(
    name: str, operation_id: str, parameters: str
) -> sandbox_rpc_pb2.RunToolResponse:
    """Runs a tool with the given name and id, passing in parameters.
    
    Args:
    name: The name of the tool.
    operation_id: The name of the operation to perform.
    parameters: The parameters to pass to the tool.
    
    Returns:
    A RunToolResponse containing the response from the tool.
    """
    result = make_rpc(
        sandbox_rpc_pb2.RpcRequest(
            run_tool_request=sandbox_rpc_pb2.RunToolRequest(
                name=name, operation_id=operation_id, parameters=parameters
            )
        )
    )

    if result and result.HasField("run_tool_response"):
        return result.run_tool_response
    else:
        return sandbox_rpc_pb2.RunToolResponse(response="")

Мы передавали различную информацию этим функциям, которая сериализовывалась в формат, совместимый с protobuf, а затем отправлялась через RPC, записываясь в локальный файловый дескриптор (5). Ответ можно было прочитать, считывая данные с файлового дескриптора (7). Используя найденные в огромном бинарном файле protobuf-сообщения, мы смогли сформировать сообщения для обмена с RPC-сервером и напрямую вызывать инструменты Google.

Однако мы заметили нечто интересное – не во всех песочницах доступен один и тот же набор сервисов Google. Всё зависело от того, была ли песочница запущена через интерфейс для выполнения Python-кода или создана самим Google Agent. Что это означает?

Исследовательская статья ReAct

Перед тем как продолжить, нужно отметить, что команда Google Security показала нам исследовательскую статью, на которой основан Gemini:

• REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS

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

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

Но зачем нам это понимать? Если следовать логике статьи, то Gemini может несколько раз задавать себе дополнительные вопросы для уточнения команд и формирования полноценной цепочки рассуждений. Например, если пользователь спросит «Какой самый ранний рейс между Торонто и Нью-Йорком?», Gemini может пройти следующие этапы:

1. Пользователь просит найти самый ранний рейс между Торонто и Нью-Йорком.

2. Составляется план:

   • Нужно запустить Python-код, который подключится к инструменту Google Flights.

   • Код должен найти все рейсы с сегодняшнего дня до следующей недели из аэропорта YYZ в JFK.

   • Отсортировать рейсы по дате и выбрать первый.

3. После составления плана генерируется код с использованием доступных инструментов агента.

4. Создаётся песочница с нужными привилегиями (например, с доступом к инструменту Google Flights через файловый дескриптор).

5. Код запускается, результат обрабатывается.

6. Формируется ответ для пользователя.

Таким образом, наша теория заключалась в следующем:

• Что если провести вторичную инъекцию запроса на этапе планирования Gemini, чтобы получить доступ к песочнице с более высокими привилегиями?

С помощью команды Google Security мы протестировали эту идею и обнаружили, что, в зависимости от таких параметров, как семя генерации и температура (все обычные особенности LLM), нам время от времени удавалось получить доступ к так называемой «более привилегированной песочнице».

Под «более привилегированной песочницей» мы подразумеваем окружение, которое имеет доступ к расширениям через два новых файловых дескриптора. Эти дескрипторы всегда присутствуют, но не всегда активно прослушиваются – когда агент вызывает песочницу, они контролируют любые вызовы расширений (сервисов Google), что позволяет нам взаимодействовать с API. При этом при доступе через Python-интерпретатор эти расширения остаются недоступными.

Это заставило нас поверить, что перед нами действительно стоит возможность обнаружения P0-уязвимости: существовал специфический обработчик сообщений, который, возможно, позволял читать файлы на внутренней инфраструктуре Google, и мы надеялись, что песочница с расширением инструментов сможет инициировать RPC-вызов к этому инструменту. Из-за вероятностного характера атаки её было сложно стабильно воспроизвести, поэтому мы обратились к Google Security Team за оценкой ситуации. В конечном итоге их анализ показал, что подозрительный обработчик сообщений недоступен через RPC и может быть вызван только извне.

Несмотря на ограниченность наших тестов, основная идея всё ещё обладает потенциалом для дальнейшей эскалации. Запуск кода в контексте песочницы изначально не должен давать дополнительных привилегий – выполняемый код считается недоверенным, с проверками безопасности вне песочницы, а каждый вызов инструмента проходит фильтрацию. Однако возможность выполнять код открывает ряд интересных преимуществ:

• Надёжность: запустив код, вы можете стабильнее инициировать действия.

• Цепочки/Сложные сценарии: управлять несколькими инструментами или настраивать параметры через простой текст сложно; выполнение кода позволяет строить более сложные цепочки, даже при наличии мер безопасности.

• Подтасовка вывода инструмента: может позволить эффективнее манипулировать результатами работы инструментов.

• Утечки: могут существовать скрытые компоненты окружения, раскрытие которых даст дополнительные преимущества.

Это свидетельствует о том, что наша идея остаётся перспективной для дальнейшей эскалации. Что касается потенциала «утечек», мы хотели проверить, сможем ли мы подтвердить хотя бы одну из теорий…

Мы нашли нашу утечку ;D

Погружаясь глубже, мы обнаружили несколько способов получить утечку proto-файлов. Если вы не знакомы с ними, то proto-файлы (сокращение от Protocol Buffer files) – это нечто вроде чертежей для данных, определяющих структуру сообщений и способ обмена информацией между различными компонентами системы. На первый взгляд они могут показаться безобидными, но утечка этих файлов может дать довольно подробное представление об архитектуре Google.

Раскрытие classification.proto

Оказалось, что, выполнив команду

strings entry_point > stringsoutput.txt 

а затем поискав в полученном файле слово «Dogfood», нам удалось извлечь фрагменты внутренних proto-файлов. Извлечённое содержимое включало метаданные, описывающие крайне чувствительные proto-файлы. Хотя само по себе оно не содержало пользовательских данных, эти файлы используются Google для внутренней классификации пользовательских данных.

Почему именно искали строку «Dogfood»? В Google под «dogfood» подразумевают использование предварительных версий собственных продуктов и прототипов внутри компании для тестирования и доработки перед их публичным запуском. Это позволяет разработчикам выявлять потенциальные проблемы на этапе развертывания, прежде чем продукт выйдет в свет.

Кроме того, был обнаружен файл privacy/data_governance/attributes/proto/classification.proto, в котором описывается, как в Google классифицируются данные. Несмотря на наличие ссылок на сопутствующую документацию, сами документы остаются строго конфиденциальными и не предназначены для публичного доступа.

Примечание от Lupin: Это было обнаружено на следующий день после бессонной ночи по выкачке бинарного файла. Мы находились в номере отеля, забронированном Google, и работали с командой безопасности, чтобы разобраться в том, что мы нашли прошлой ночью. На этот раз Джастин спал на диване, ха-ха! Этот баг потребовал много времени, но был чрезвычайно увлекательным!

Раскрытие внутренних определений протоколов безопасности

Аналогичный вывод также выявил множество внутренних proto-файлов, которые должны были оставаться скрытыми. Выполнив команду:

cat stringsoutput.txt| grep '.proto' | grep 'security' 

мы получили список чувствительных файлов, среди которых:

security/thinmint/proto/core/thinmint_core.proto
security/thinmint/proto/thinmint.proto
security/credentials/proto/authenticator.proto
security/data_access/proto/standard_dat_scope.proto
security/loas/l2/proto/credstype.proto
security/credentials/proto/end_user_credentials.proto
security/loas/l2/proto/usertype.proto
security/credentials/proto/iam_request_attributes.proto
security/util/proto/permission.proto
security/loas/l2/proto/common.proto
ops/security/sst/signalserver/proto/ss_data.proto
security/credentials/proto/data_access_token_scope.proto
security/loas/l2/proto/identity_types.proto
security/credentials/proto/principal.proto
security/loas/l2/proto/instance.proto
security/credentials/proto/justification.proto

При поиске в строках бинарного файла по запросу security/credentials/proto/authenticator.proto подтверждалось, что данные этого файла действительно утекли.

Зачем вообще оказались эти proto-файлы?

Как мы уже отмечали, команда Google Security тщательно проверила всё, что касается работы песочницы, и дала зелёный свет на публичное раскрытие. Однако в процессе сборки бинарного файла для песочницы был включён автоматизированный шаг, добавляющий файлы протоколов безопасности в бинарник, если система определяла, что они могут потребоваться для обеспечения внутренних правил. В данном случае этот шаг оказался избыточным, что привело к непреднамеренному включению высокосекретных внутренних proto-файлов в публичный доступ.

Как баг-баунти охотники, мы знаем, что крайне важно глубоко понимать бизнес-процессы компании. Мы сообщили об этой утечке proto-файлов, потому что знаем: Google рассматривает их как строго конфиденциальную информацию, которая никогда не должна становиться публичной. Чем лучше мы понимаем внутреннюю архитектуру и приоритеты цели, тем точнее можем выявить и зафиксировать даже самые незаметные баги, которые в ином случае могли бы пройти незамеченными. Это глубокое знание не только помогает нам обнаруживать уязвимости, но и обеспечивает, что наши отчёты отражают критически важные вопросы безопасности для организации.

Заключение

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

В конечном итоге, что сделало этот опыт по-настоящему незабываемым – это чистое удовольствие от процесса. Вскрытие уязвимостей, исследование скрытого кода и преодоление ограничений песочницы Gemini было не только техническим вызовом, но и настоящим приключением. Люди, которых мы встретили на bugSWAT в Лас-Вегасе, оказались потрясающими. Совместный смех над неожиданными поворотами и азарт от преодоления сложных систем превратили это техническое путешествие в приключение, которое мы никогда не забудем. Именно такие моменты, когда серьёзный взлом переплетается с весёлыми эмоциями, напоминают нам, зачем мы занимаемся этим делом.

В заключение, огромный респект всем победителям и участникам, благодаря которым bugSWAT 2024 стал таким незабываемым событием. Поздравляем Sreeram и Sivanesh за великолепную командную работу, Alessandro – за почти занятое первое место, и En – за выход на подиум. Было невероятно встретить столь талантливых хакеров и специалистов по безопасности; ваша энергия и страсть сделали мероприятие по-настоящему незабываемым. Мы с нетерпением ждём встречи на следующем bugSWAT, а до тех пор – продолжайте хакать и получать удовольствие!

И, конечно же, благодарим команду безопасности Google! Как всегда, вы – лучшие 

—————————————-

P.S Про менее душные новости пишу в Телеграм канале, подписывайтесь! За рекламу извините и спасибо, что дочитали до конца! 🫀