Rails fail

Slo-Tech - Ruski Ruby on Rails razvijalec Egor Homakov je minuli teden avtorje frameworka opozoril na potencialno in resno varnostno pomankljivost v večini rails spletnih aplikacij (ti. mass assignment vulnerability). Žal ga niso vzeli kaj posebej resno, zato je šel pogledat, če je pomanjkljivost mogoče izkoristiti na njihovi spletni strani. Izkaže se, da ja. Uspel je dobiti administratorski dostop do izjemno priljubljenega gostitelja kode GitHub, komentirati z datumom globoko v prihodnosti (s podpisom "Bender" iz Futurame), commitati kodo v master branch rails projekta in, če bi hotel, tudi brisati projekte poljubnih razvijalcev. Zaradi ugleda Githuba je zgodba o njegovih podvigih prišla na prvo stran reddita, potem pa še na vrh hacker news in to kar v štirih inačicah hkrati, kar je posebej redko.

Ker je vse počel pod svojim uradnim računom, mu ga je Github hitro zaklenil, čeprav so se kasneje posipali s pepelom in mu ga omogočili nazaj. In spisali blog post o tem, da se spodobi varnostne pomanjkljivost najprej sporočiti podjetju po zasebni pošti in šele potem z javnimi eskapadami (ti. white hat pristop).

Torej, napaka z mass assignmentom. Ruby on Rails je popularna knjižnica za pisanje spletnih aplikacij, ki se v znatni meri zanaša na konvencije in dobre prakse, na rovaš ročnega pisanja kode in konfiguracije (posebej ne v obliki zloveščih .xml datotek, ki jih vidimo pri nekaterih drugih jezikih). V tipični rails aplikaciji je zato nemalo kode avtomatsko zgenerirane ("scaffolding") in potem skup zlepljene že na podlagi pravilnih imen datotek. Programer lahko spletne obrazce za vnos podatkov v bazo pripravi kar samodejno na podlagi podatkovne sheme in rails bo vnešene podatke validiral in shranil, vse z minimalnim številom vrstic kode. Razvoj na tak način je zelo hiter in učinkovit, vendar lahko v določenih primerih tudi nevaren, ker lahko napadalec spletnemu obrazcu doda tudi neželene podatke in s tem prepiše ustrezna polja v bazi.

Github konkretno teče na railsih in ima obrazec za vpis javnega ssh ključa, ki potem omogoča prijavo in commitanje na njihove strežnike. Ta obrazec je samodejno zgeneriran iz podatkovnega modela PublicKey, ki ima asociacijo na Userja. V obrazcu za vpis ključa te asociacije ni, ker se pač privzame trenutno prijavljeni uporabnik. Vendar pa bo rails, če heker v POST zahtevek vstavi vstavi še kak tuji user id, prepisal javni ključ tistega uporabnika in ne ključ od trenutno prijavljenega uporabnika. Na ta način je Egor prepisal ključ administatorja rails projekta.

Prepisovanje se sicer da preprečiti z označbo določenih polj v modelu za zaščitene, vendar mora to programer narediti ročno. Egon pravi, da je o tem vprašal veliko svojih kolegov, vendar so ga vsi predvsem debelo gledali. Zato je na GitHubu (ki gostuje tudi izvorno kodo za rails) odprl prošnjo, da se zaščita označi kot privzeta ali obvezna za nastaviti, kar so potem vodje projekta rails, kot rečeno, označili za manj pomembno. Da bi dokazal svojo poanto, je Egon šel napako preizkusit na GitHubu samem.