Уязвимость в архитектуре платформы открывает доступ к приватным данным пользователей.
Специалисты Truffle Security обнаружили, что данные из удалённых форков, репозиториев и даже приватных репозиториев на GitHub могут оставаться доступными навсегда. Проблема не только известна самой компании, но и является частью архитектуры платформы.
Потенциальная уязвимость получила название Cross Fork Object Reference (CFOR). Проблема возникает, когда один форк репозитория может получить доступ к конфиденциальным данным другого форка, включая данные из удалённых и приватных форков. Подобно известной уязвимости Insecure Direct Object Reference (IDOR), CFOR позволяет пользователям использовать хэши коммитов для прямого доступа к данным, которые в противном случае были бы недоступны.
Исследователи описывают уязвимость на примере типичного рабочего процесса на GitHub. Пользователь форкает публичный репозиторий, вносит в него изменения и затем удаляет форк. Кажется логичным, что данные из удалённого форка должны быть недоступны, но на практике они остаются доступными навсегда и контроль над информацией теряется.
В ходе исследования выяснилось, что данные из удалённых форков можно найти достаточно часто. В нескольких популярных репозиториях крупной компании, занимающейся искусственным интеллектом, были обнаружены десятки валидных API-ключей, закодированных в примеры файлов и оставшихся в форках после удаления.
Но проблема выходит за рамки доступности данных из удалённых форков. Когда пользователь создаёт публичный репозиторий, а затем его удаляет, данные, добавленные после создания форка, остаются доступными через этот форк. То есть все коммиты из «родительского» репозитория продолжают существовать и доступны через любой форк.
Ещё одна опасная ситуация связана с приватными репозиториями. При создании приватного репозитория, который позже становится публичным, и наличии форка репозитория с дополнительными функциями, данные из приватного форка могут стать доступными для широкой публики. Это связано с тем, что изменение видимости «родительского» репозитория разделяет сеть репозиториев на приватную и публичную версии, и данные, внесённые в приватный форк до этого момента, остаются доступными.
Чтобы получить доступ к таким данным, достаточно знать хэш коммита. Деструктивные действия в сети репозиториев GitHub удаляют ссылки на данные коммитов из стандартного интерфейса и операций git, но сами данные остаются и доступны, если известен хэш коммита. Коммиты можно найти и с помощью API GitHub, что делает данные ещё более уязвимыми.
Компания GitHub не скрывает своих архитектурных решений и документирует их для пользователей. Однако многие разработчики, особенно новички, могут не осознавать масштаб проблемы.
Выводы из исследования весьма тревожны. В первую очередь, подчеркивается необходимость ротации ключей доступа для устранения утечек данных. GitHub, как и другие системы управления версиями, имеет архитектурные особенности, которые могут привести к непреднамеренному раскрытию конфиденциальной информации. Важно повышать осведомлённость пользователей о таких уязвимостях и предпринимать меры для защиты данных.
Исследования показали, что проблема сохранения данных из удалённых и приватных репозиториев не ограничивается только GitHub. Подобные уязвимости могут существовать и в других системах управления версиями. Разработчикам и компаниям следует внимательно относиться к защите своих данных и регулярно проверять свои проекты на наличие подобных уязвимостей.
Собираем и анализируем опыт профессионалов ИБ