Компания Truffle Security опубликовала сценарии атак на несколько типовых приёмов работы с репозиториями на GitHub, позволяющие извлечь данные из удалённых репозиториев, у которых имеются публичные форки или которые были созданы как форки.

Возможность доступа к коммитам по хэшу во всех связанных форками репозиториях вызвано тем, что GitHub в целях оптимизации и исключения дубликатов хранит вместе все объекты из основного репозитория и форков, лишь логически разделяя принадлежность коммитов. Подобное хранение позволяет просмотреть в основном репозитории любой коммит из любого форка, явно указав его хэш в URL. Например, пользователь может создать форк репозитория "/torvalds/linux" и добавить в него любой код, после чего этот код станет доступен по прямой хэш-ссылке в репозитории "/torvalds/linux". В случае удаления репозитория, если имеется хотя бы один публичный форк, данные из удалённого репозитория остаются доступны по хэшу коммита.

Предлагается три сценария, представляющих угрозу безопасности:

• Первый сценарий затрагивает ситуации, когда разработчики создают форки публичных репозиториев, добавляют в них изменения, экспериментируют, а затем удаляют. Помимо утечки кода, который не предназначен для публикации, опасность представляет ситуация, когда в экспериментах в код файлов с примерами добавляются рабочие ключи доступа к API. В этом случае атакующий может получить доступ к изменению по хэшу коммита, адресуемому после удаления форка через основной репозиторий. Например, предложенным способом исследователи смогли определить 30 рабочих ключей доступа к API, изучив три связанных с машинным обучением репозитория с большим числом форков.
• Второй сценарий касается возможности получения доступа к данным после удаления первичного репозитория, если для этого репозитория были созданы форки. В качестве примера приводится случай, когда в публичном репозитории одной компании были случайно опубликованы закрытые ключи одного из сотрудников, позволяющие получить полный доступ ко всем репозиториям данной компании на GitHub. Компания удалила репозиторий через который была утечка, но ключи по-прежнему остались доступны для извлечения через обращения по хэшу коммита в репозиториях с форками.
  
  
• Третий сценарий связан с моделью разработки проектов, которые развивают базовую открытую версию в публичном репозитории и расширенную проприетарную версию в приватном. Если компания изначально развивала проект в приватном репозитории, а затем после открытия кода проекта перевела его в разряд публичных, но продолжила разработку закрытой внутренней или расширенной версии в приватном форке, имеется возможность доступа к добавленным в приватный форк изменениям по хэшам коммитов через публичный репозиторий. При этом доступ возможен только к изменениям, добавленным в приватный форк до перевода основного репозитория в разряд публичных (хранилища приватных и публичных репозиториев разделяются, но, когда два репозитория были приватными, коммиты хранились совместно, поэтому остались в репозитории после его перевода в разряд публичных).

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

Подобрать хэш коммита, формируемый на базе алгоритма SHA-1 и включающий 32 символа, не реально, но оказалось, что это и не требуется. GitHub поддерживает сокращённую форму обращения к коммитам, позволяющую адресовать изменения по нескольким первым символам хэша, если отсутствуют пересечения с другими коммитами. Минимальное число символов для сокращённой адресации хэша - 4, что соответствует перебору всего 65 тысяч комбинаций (16^4). При этом перебор может и не потребоваться, так как API GitHub позволяет подключать обработчики для перехвата событий, которые используются сторонними проектами, ведущими архив с полным логом всех операций, в котором информация о хэшах коммитов остаётся и после удаления репозиториев.