НАСТОЯЩИЙ МАТЕРИАЛ (ИНФОРМАЦИЯ) ПРОИЗВЕДЕН, РАСПРОСТРАНЕН И (ИЛИ) НАПРАВЛЕН ИНОСТРАННЫМ АГЕНТОМ «РОСКОМСВОБОДА» ЛИБО КАСАЕТСЯ ДЕЯТЕЛЬНОСТИ ИНОСТРАННОГО АГЕНТА «РОСКОМСВОБОДА». 18+
Уязвимость проявляется, когда «один форк репозитория может получить доступ к конфиденциальным данным из другого форка, включая данные из частных и удаленных форков».
Исследователи из Truffle Security обнаружили в GitHub уязвимость, которая делает данные репозитория всегда доступными, что потенциально позволяет злоумышленникам получить доступ к конфиденциальной информации, такой как ключи API и секреты, даже после того, как пользователи думают, что они удалили её. Проблема не только известна самой компании, но и является частью архитектуры платформы.
Truffle Security назвали уязвимость GitHub Cross Fork Object Reference (CFOR). Уязвимость проявляется, когда «один форк репозитория может получить доступ к конфиденциальным данным из другого форка, включая данные из частных и удаленных форков».
Исследователи описывают уязвимость на примере типичного рабочего процесса на GitHub. Пользователь форкает публичный репозиторий, вносит в него изменения и затем удаляет форк. Кажется логичным, что данные из удалённого форка должны быть недоступны, но на практике они остаются доступными навсегда и контроль над информацией теряется.
В ходе исследования выяснилось, что данные из удалённых форков можно найти достаточно часто. В нескольких популярных репозиториях крупной компании, занимающейся искусственным интеллектом, были обнаружены десятки валидных API-ключей, закодированных в примеры файлов и оставшихся в форках после удаления.
Но проблема выходит за рамки доступности данных из удалённых форков. Когда пользователь создаёт публичный репозиторий, а затем его удаляет, данные, добавленные после создания форка, остаются доступными через этот форк. То есть все коммиты из «родительского» репозитория продолжают существовать и доступны через любой форк.
Ещё одна опасная ситуация связана с приватными репозиториями. При создании приватного репозитория, который позже становится публичным, и наличии форка репозитория с дополнительными функциями, данные из приватного форка могут стать доступными для широкой публики. Это связано с тем, что изменение видимости «родительского» репозитория разделяет сеть репозиториев на приватную и публичную версии, и данные, внесённые в приватный форк до этого момента, остаются доступными.
Чтобы получить доступ к таким данным, достаточно знать хэш коммита. Деструктивные действия в сети репозиториев GitHub удаляют ссылки на данные коммитов из стандартного интерфейса и операций git, но сами данные остаются и доступны, если известен хэш коммита. Коммиты можно найти и с помощью API GitHub, что делает данные ещё более уязвимыми.
Компания GitHub не скрывает своих архитектурных решений и документирует их для пользователей. Однако многие разработчики, особенно новички, могут не осознавать масштаб проблемы.
Выводы из исследования весьма тревожны. В первую очередь, подчеркивается необходимость ротации ключей доступа для устранения утечек данных. GitHub, как и другие системы управления версиями, имеет архитектурные особенности, которые могут привести к непреднамеренному раскрытию конфиденциальной информации. Важно повышать осведомлённость пользователей о таких уязвимостях и предпринимать меры для защиты данных.
Исследования показали, что проблема сохранения данных из удалённых и приватных репозиториев не ограничивается только GitHub. Подобные уязвимости могут существовать и в других системах управления версиями.