Новая уязвимость
Исследователи из Truffle Security обнаружили в GitHub уязвимость, которая делает данные репозитория всегда доступными, что потенциально позволяет злоумышленникам или хакерам получить доступ к конфиденциальной информации. Об этом в конце июля 2024 г. говориться в опубликованном материале на сайте компании.
Данную уязвимость описал Джо Леон (Joe Leon) из Truffle Security, он назвал ее Cross Fork Object Reference (CFOR). Проблема не только известна самой компании GitHub, но и является частью архитектуры платформы. Сама же уязвимость проявляется, когда один форк репозитория может получить доступ к конфиденциальным данным из другого форка, включая данные из частных и удаленных форков.
ИБ-исследователи описывают уязвимость на примере типичного рабочего процесса на GitHub. Пользователь форкает публичный репозиторий, вносит в него изменения и затем удаляет форк. Кажется логичным, что данные из удаленного форка должны быть недоступны, но на практике они остаются доступными навсегда и контроль над информацией теряется.
Компания GitHub не скрывает своих архитектурных решений и документирует их для пользователей. Однако многие разработчики, особенно новички, могут не осознавать масштаб проблемы.
В ходе исследования ИБ-специалисты выяснили, что данные из удаленных форков можно найти достаточно часто. В нескольких популярных репозиториях крупной компании, занимающейся искусственным интеллектом (ИИ), были обнаружены десятки валидных API-ключей, закодированных в примеры файлов и оставшихся в форках после удаления. Но проблема выходит за рамки доступности данных из удаленных форков. Когда пользователь создает публичный репозиторий, а затем его удаляет, данные, добавленные после создания форка, остаются доступными через этот форк. То есть все коммиты из родительского репозитория продолжают существовать и доступны через любой форк.
Согласно данным Truffle Security, другая проблема заключается в том, что при создании приватного репозитория, который позже становится публичным, и наличии форка репозитория с дополнительными функциями, данные из приватного форка могут стать доступными для широкой публики. Это связано с тем, что изменение видимости родительского репозитория разделяет сеть репозиториев на приватную и публичную версии, и данные, внесенные в приватный форк до этого момента, остаются доступными. Для того чтобы получить доступ к таким данным, достаточно знать хэш коммита. Деструктивные действия в сети репозиториев GitHub удаляют ссылки на данные коммитов из стандартного интерфейса и операций git, но сами данные остаются и доступны, если известен хэш коммита. В связи с тем, что коммиты можно найти и с помощью API GitHub, это делает данные еще более уязвимыми.
Выводы Джо Леона из Truffle Security весьма тревожны. В первую очередь, подчеркивается необходимость ротации ключей доступа для устранения утечек данных. GitHub, как и другие ИТ-системы управления версиями, имеет архитектурные особенности, которые могут привести к непреднамеренному раскрытию конфиденциальной информации. Важно повышать осведомленность пользователей о таких уязвимостях и предпринимать меры для защиты данных. Леон лишь показал, что проблема сохранения данных из удаленных и приватных репозиториев не ограничивается только GitHub, ведь подобные уязвимости могут существовать и в других ИТ-системах управления версиями.
Получение доступа к данным
Операции уничтожения в сети репозиториев GitHub удаляют ссылки на данные коммитов из стандартного UI GitHub и обычных операций git. Однако эти данные все равно существуют, и к ним можно получить доступ (если знать хэш коммита). В этом заключается связь между уязвимостями CFOR и IDOR - если пользователь знает хэш коммита, то сможет напрямую получать доступ к данным, не предназначенным для него.
Если пользователь знает хэш SHA-1 конкретного коммита, который он хочет посмотреть, то он может напрямую перейти к этому коммиту в конечной точке. Юзер увидит желтый баннер с информацией о том, что этот коммит не принадлежит ни к одной из ветвей этого репозитория и может принадлежать форку вне репозитория.
Хэши коммитов можно подобрать брутфорсом через UI GitHub, и в особенности потому, что протокол git допускает использование коротких значений SHA-1 при ссылках на коммит. Короткое значение SHA-1 - это минимальное количество символов, необходимое для предотвращения коллизий с хэшем другого коммита. Абсолютно минимальное значение равно 4. Пространство ключей всех значений SHA-1 из четырех символов составляет 65536 (16^4). Брутфорс всех возможных значений можно выполнить достаточно просто.
Сервис GitHub раскрывает публичную конечную точку API событий. Можно также запрашивать хэши коммитов в архиве событий, управляемом третьей стороной. Архив сохраняет все события GitHub за последние 10 лет и даже после удаления репозиториев.
Крупнейший сервис для хостинга ИТ-проектов
GitHub - это самое большое хранилище программного кода и самое большое комьюнити программистов на планете. Но этому суперстартапу пришлось привлечь инвестиции в $100 млн в 2012 г/ и еще $250 млн в 2015 г.
Компания Microsoft начала процедуру покупки за $7,5 млрд платформы для разработчиков GitHub. Возможно, для стороннего наблюдателя это странное приобретение, но с точки зрения бизнеса кажется, что по-другому и быть не могло.
Аналитики Gartner оценили глобальный ИТ-рынок в 2018 г. в $3,8 трлн. Лидеры сегмента среди публичных корпораций входят в топ-20 самых крупных компаний планеты с оценкой в сотни миллиардов долларов.
Поделиться