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

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