A Truffle Security közzé tette a GitHub-on használt tipikus repókezelési minták támadási forgatókönyveit, amelyek lehetővé teszik az adatok kinyerését távoli repókból, amelyeknek nyilvános forkjaik vannak vagy amelyeket forként hoztak létre.
A commitok hash-érték szerinti elérhetősége minden kapcsolódó forkhoz a repozitóriumban abból adódik, hogy a GitHub optimalizálási célból és a duplikációk kizárása érdekében egyesíti a fő repozitóriumból és forkokból származó összes objektumot, csupán logikailag elválasztva a commitok tulajdonjogát. Ez a tárolás lehetővé teszi, hogy bármely commitot megnézhessünk a fő repozitóriumban a fork bármelyikéből, ha a hash-értékét kifejezetten megadjuk az URL-ben. Például a felhasználó készíthet egy forkot a "torvalds/linux" repozitóriumból, és hozzáadhat bármilyen kódot, amely ezután közvetlen hash-hivatkozással elérhető a "torvalds/linux" repozitóriumban. Ha a repozitórium törlésre kerül, ha legalább egy nyilvános fork létezik, az eltávolított repozitóriumból származó adatok a commit hash-én keresztül továbbra is elérhetők maradnak.
Három biztonsági fenyegetést bemutató forgatókönyv kerül bemutatásra:
- Az első forgatókönyv olyan eseteket érint, amikor a fejlesztők nyilvános repozitóriumokat forkolnak, módosításokat adnak hozzá, kísérleteznek, majd törlik őket. A nem publikálásra szánt kód szivárgásán túl a veszélyt az jelenti, amikor a kísérletezés során a példák fájljaiba élő API-hozzáférési kulcsokat is beillesztenek. Ilyen esetben a támadó hozzáférhet a hash-értéken keresztül a commit változtatásához, amelyet a fork törlése után a fő repozitóriumon keresztül címeznek. Például a javasolt módszerrel a kutatók 30 működő API-hozzáférési kulcsot tudtak azonosítani három gépi tanulással kapcsolatos repozitórium vizsgálatával, amelyeknek nagy számú forkja volt.
- A második forgatókönyv a hozzáférés lehetőségéről szól az adatokhoz a fő repozitórium törlése után, ha a repozitóriumhoz forkok készültek. Példa erre, amikor egy cég nyilvános repozitóriumában véletlenül közzétették egy alkalmazott zár kulcsait, amelyek teljes hozzáférést biztosítottak a cég összes repozitóriumához a GitHubon. A cég törölte azt a repozitóriumot, ahonnan az adatlopás történt, de a kulcsok továbbra is elérhetőek maradtak, és azokat a forkokban a commit hash segítségével még mindig vissza lehet szerezni.
- A harmadik forgatókönyv a projektek fejlesztési modelljével kapcsolatos, amelyek az alap nyílt verziót egy nyilvános repozitóriumban, míg a kibővített, szabadalmaztatott verziót egy privát repozitóriumban fejlesztik. Ha egy cég kezdetben privát repozitóriumban fejlesztette a projektet, majd miután megnyitotta a kódját a projektet nyilvánossá tette, viszont továbbra is a zárt belső vagy kibővített verziót fejlesztette egy privát forkban, akkor lehetőség van arra, hogy a privát forkhoz hozzáadott módosításokhoz commit hash alapján hozzáférjünk a nyilvános repozitóriumból. Itt a hozzáférés csak a privát forkhoz a fő repozitórium nyilvánossá tétele előtt hozzáadott módosításokhoz lehetséges (a privát és nyilvános repozitóriumok tárolása elkülönül, de amikor két repozitórium privát volt, a commitok közösen tárolódtak, ezért megmaradtak a repozitóriumban, miután azokat nyilvánosra állították).
A trükk, amely lehetővé teszi a repo forkokban lévő commitokhoz való hozzáférést a fő repozitóriumra mutató hivatkozáson keresztül, már évek óta ismert, és időről időre használják különböző tréfákhoz és a fejlesztők megtévesztésére (például a tréfázók ilyen módon időnként látszólag hátsó bejáratokat hoznak létre a GitHubon a Linux kernel repozitóriumban). Mint intézkedés az ilyen tréfák ellen, a GitHub figyelmeztetést fűzött hozzá, hogy a kért commit nem tartozik a jelenlegi repozitóriumban lévő ágakhoz, és lehet, hogy egy forkhoz tartozik. Ugyanakkor a commitok hash alapján történő hozzáférés lehetősége bármely kapcsolódó forkban ártalmatlannak számított, mivel az elszigetelt és privát forkokban lévő adatok eléréséhez szükséges a commit hash ismerete.
A commit hash generated based on the SHA-1 algorithm and consisting of 32 characters is not realistically attainable, but it turns out that it is not necessary. GitHub supports a shortened form of referencing commits that allows addressing changes by the first few characters of the hash, provided there are no overlaps with other commits. The minimum number of characters for this abbreviated hash address is 4, which corresponds to a brute force search of 65 thousand combinations (16^4). In this case, a brute force attempt may not even be needed, as GitHub's API allows for handlers to intercept events used by third-party projects that maintain an archive with a complete log of all operations, where information about commit hashes remains even after repositories are deleted.
Forrás: opennet.ru
