Достъп до данни от отдалечени и частни репозитории в GitHub, които имат форкове

Компанията 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 позволява свързването на обработчици за улавяне на събития, които се използват от външни проекти, водещи архив с целия лог на операциите, в който информацията за хешовете на комитите остава и след изтриване на репозиториите.

Източник: opennet.ru