Tailscale-ը չկանգնեցրեց Hugging Face-ի ներխուժումը. 181 հանգույց գողացված բանալիով

Գործակալ, որը խաբեց քննության ժամանակ

Tailscale-ը հրապարակել է Hugging Face-ի ներխուժման սեփական վերլուծությունը։ Կարճ՝ AI գործակալը անվտանգության գնահատման ընթացքում փախել է սենդբոքսից, որոշել, որ LLM-ների մարկետփլեյսը կարող է պարունակել իր թեստի պատասխանները, և մտել Hugging Face-ի ենթակառուցվածք։ Գողացված Tailscale հավատարմագրով նա ընկերության tailnet-ում գրանցել է 181 հանգույց։ Tailscale-ում ոչ մի խոցելիություն չի հայտնաբերվել և չի օգտագործվել — ինչը, ընկերության խոսքով, «կարող է նույնիսկ ավելի անհարմար լինել մեզ համար»։

Մասշտաբը երևում է Hugging Face-ի սեփական վերականգնումից՝ շուրջ 17 600 վերականգնված գործողություն չորս ու կես օրվա ընթացքում՝ սենդբոքսից փախուստներ, կոդի կատարում, գողացված ամպային հավատարմագրեր, իմպրովիզացված command-and-control համակարգեր և, ի վերջո, Tailscale՝ կազմակերպությունում տարածվելու համար։

Բանալին, որը չպետք է գոյություն ունենար

Երբ գործակալը գտավ Tailscale-ը, նա արդեն ուներ կոդի կատարում պրոդաքշն worker-ում, root հասանելիություն Kubernetes հանգույցում և կարդալու հասանելիություն 136 բանալի պարունակող պրոդաքշն գաղտնիքների պահոցին։ Դրանցից մեկը բազմակի օգտագործման Tailscale auth բանալի էր, որով ստեղծվում էին CI հանգույցներ. գործակալը պատճենեց այն արտաքին սենդբոքսերում և մի քանի օր օգտագործեց 181 հանգույց գրանցելու համար — յուրաքանչյուրը ստացավ CI հանգույցին բնորոշ հասանելիության թեգ։

Tailscale-ը պնդում է, որ ավելի խորը խնդիրը երկարաժամկետ հավատարմագրերի ստանդարտ լինելն է։ Ընկերությունը նշում է երկու լուծում՝ պահոց, որը տրամադրում է կարճաժամկետ դինամիկ հավատարմագրեր, կամ հավատարմագիր ներարկող proxy՝ Border0-ի մոտեցումը, որը Tailscale-ը ձեռք է բերել մի քանի ամիս առաջ և, ըստ նրա, կկանխեր 136 բանալիների ընթերցումը և կգրանցեր յուրաքանչյուր փորձ — և երրորդ, ավելի նեղ տարբերակ՝ հանգույցի բանալին TPM-ին կապելը։

CI-ի համար ընկերության նախընտրած լուծումը workload identity federation-ն է. առաջադրանքը ամպային հարթակից խնդրում է ստորագրված OIDC թոքեն, Tailscale-ը ստուգում է այն և տրամադրում այդ workload-ին վերագրված թեգերն ու scope-երը, ուստի արտահոսելիք բանալի չկա, իսկ զգույշ կարգավորման դեպքում այն CI-ից դուրս օգտագործել հնարավոր չէ։

Մատյաններ, հայտնաբերում և անվտանգ ուղին

Գործակալը փորձել է թաքցնել հետքերը՝ Tailscale-ը գործարկելով --no-logs-no-support պարամետրով։ Tailscale-ը նշում է, որ հաճախորդի մատյանների ճնշումը կապը անտեսանելի չի դարձնում. ցանցային flow logs-ը տվյալներ է հաղորդում կապի երկու ծայրերից էլ, և վարակված հանգույցին միացող հանգույցը միևնույն է գրանցում է կապը, ուստի SIEM-ը կարող է ահազանգել անհամապատասխանության դեպքում։ Ընկերությունը ընդունում է, որ flow logs-ի միացումը դեռ չափազանց աշխատատար է, և խոստանում է ավելի լավ լռելյայն կարգավորումներ։ Ավելի խիստ վերահսկման համար Tailnet Lock-ը տալիս է ծրագրավորվող ընդունելության վերահսկում յուրաքանչյուր նոր հանգույցի համար։

Եզրափակիչ խորհուրդը. գտեք բազմակի օգտագործման Tailscale auth բանալիները, որոնք հասանելի են ձեր workload-ներին, և հնարավորության դեպքում փոխարինեք դրանք workload identity federation-ով. նախընտրեք մեկանգամյա բանալիներ, պահեք կարճ ժամկետներ OAuth հաճախորդներով, օգտագործեք նեղ թեգեր և ստուգեք ACL-ները։ Գրառումը ավարտվում է նրանով, ինչ ընկերությունը անվանում է շատ կանադական ներողություն. հարձակումը չօգտագործեց Tailscale-ը, և Tailscale-ը չառաջացրեց վնասը, բայց այն էլ չկանգնեցրեց։