» »

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.

20 komentarjev

HardFu ::

Pozna objava novice, tole je bil cel zur v nedeljo na HackerNews.
http://codeable.io

Kenpachi ::

Na, pa smo doživeli besedo "[something] fail" v naslovu novice na slo-tech. Clap, clap. Čudno, da ni kakih drugih pripon, a-la omg, lol, roflmao. Mogoče bomo tudi to doživeli.

Drugače pa, novica: Zakaj se zdaj bunijo pri Github, da jih ni vljudno opozoril na napako, če temu ni tako oz. ga niso vzeli resno?
Zaraki Kenpachi.

Monster ::

ker povsod obstoja oseba, ki je pametna za vse ljudi na svetu
Ka zaboga...

RejZoR ::

Še boljši naslov bi bil: "Derailed" :D
RejZoR's Flock of Sheep @ rejzor.wordpress.com

iElectric ::

Tipični problem "convention over configuration", ki se pri varnosti se tako bolje pokaže. Respect za spisano novico, ceprav ni 0day.

Nerdor ::

Joj no, request forgery je naredu, pa razvijalci gh-ja niso tega implementiral pri vpisu s ssh. Big deal, a zdej je kr rails fail, pa derails pa take neumnosti, če razvijalc ne zna sprogramirat!? Pač gh razvijalec bi moral dodati csrf pri auth formi, ki se vsakič dinamično zgenerira, pa me zanima če bi ta Egor lahko ponovil trik. Rails je čisto uredu platforma, samo se jo je potrebno do ponatankosti navaditi.
... for lifetime!

Majk ::

Nerdor je izjavil:

Joj no, request forgery je naredu, pa razvijalci gh-ja niso tega implementiral pri vpisu s ssh.
Meni je to prakticno isto kot SQL injection.

Nerdor je izjavil:

Rails je čisto uredu platforma, samo se jo je potrebno do ponatankosti navaditi.
Kar pa ga ocitno tudi avtorji/lastniki ne znajo pravilno implementirati.

iElectric ::

Tu definitivno ne gre za request forgery, ampak neke vrste template injection. V vsakem primeru gre za resen varnostni problem, če je ranljiva stran kot je npr. github.

Ob takih primerih se da precej kregat, ali gre za varnostno luknjo ali pa so vsi developerji nesposobni :)

fiction ::

A nobeden ne prebere novice, ni šlo za CSRF, ampak za "mass assignment". Tako da ni bilo treba uporabiti čisto nič social engineeringa. No čeprav tudi CSRF je jasno v prvi vrsti še vedno krivda spletne aplikacije.

Sicer ne poznam RoR, ampak zgleda da vgrajen ORM lahko avtomatsko naredi oz. spremeni entiteto na podlagi parametrov iz HTTP zahtevka. V stilu vse kar pride so propertyi določenega objekta. Npr. da imaš objekt tipa User, najprej poiščeš pravega, potem pa avtomatsko assignaš vse iz HTTP zahtevka ("HTTP GET ?name=Janez&age=20") pa se bosta ti dve lastnosti objekta spremenili in posledično tudi vrednosti v bazi. To ti najbrž prišpara kar nekaj brezvezne kode. Problem je samo, če ima ta entiteta še kak isAdmin flag ali kaj podobnega in ti na to ne misliš...

MrBrdo ::

Ta mass assignment je men že skos mal sumljiv. Nikol se mi ni zdela lih najbolša rešitev, tko da se niti ne čudim :) Ah škoda, ni mi najljubše videt "rails fail", ampak kaj čmo :)
MrBrdo

pecorin ::

https://gist.github.com/1978249

tu so precej lepo razlozili.

ni csrf. to je nekaj takega kot je opisal fiction.

ce se dobro spomnim, je php leta nazaj imel podoben problem, da je vse kar si dal v get, takoj spremenil v spremenljivko v php. kot npr. bla.php?id=3 je avtomatsko postalo $id z vrednostjo 3 v php. ni enako, je pa podobno...

MrBrdo ::

Ok čeprav to je napaka razvijalcev, ker so dal user_id pod attr_accessible oz. niso uporabili attr_accessible (ki ni nek nevemkako advanced feature).
Tko da v bistvu ni to nek grozen "bug", ampak deluje kot je bilo predvideno. Se pa lahko hitro zgodi neizkušenim taka napaka. Sam to ni exploit v frameworku al pa bug, to je pač napaka programerjev GitHuba.

Upam pa da bojo dodali tisti initializer ki ga je pecorin linkal po defaultu, ker bi se potem dosti težje tako zmotil. Edit: Aha sej zgleda da bojo zdaj dodali to :)
MrBrdo

Zgodovina sprememb…

  • spremenilo: MrBrdo ()

pecorin ::

vse je bilo dosegljivo, razen ce si mu povedal kaj naj ne bo. ni to bug, ampak je treba biti zelo previden in paziti da ne pustis dosegljivega kar noces, da se spreminja.
obratno je dosti boljse za varnost. default nic dosegljivo in mu poves kaj naj bo dosegljivo.

krho ::

pecorin je izjavil:

https://gist.github.com/1978249

tu so precej lepo razlozili.

ni csrf. to je nekaj takega kot je opisal fiction.

ce se dobro spomnim, je php leta nazaj imel podoben problem, da je vse kar si dal v get, takoj spremenil v spremenljivko v php. kot npr. bla.php?id=3 je avtomatsko postalo $id z vrednostjo 3 v php. ni enako, je pa podobno...

Ja to je bil famozni register_globals, ki je v čiščenju večine deprecated stvari v php 5.4 končno odšel v večna lovišča
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

iElectric ::

Torej še enkrat povzetek:

iElectric je izjavil:

Tipični problem "convention over configuration", ki se pri varnosti se tako bolje pokaže. Respect za spisano novico, ceprav ni 0day.

carota ::

pecorin je izjavil:

vse je bilo dosegljivo, razen ce si mu povedal kaj naj ne bo. ni to bug, ampak je treba biti zelo previden in paziti da ne pustis dosegljivega kar noces, da se spreminja.
obratno je dosti boljse za varnost. default nic dosegljivo in mu poves kaj naj bo dosegljivo.

Torej it's not a bug, it's a feature! ;)

MrBrdo ::

Ja saj res je tako, to je feature. Edino kar je problem, da je (bil?) default malo nerodno postavljen, da si se lahko dokaj enostavno dobil puščico v koleno, če nisi bil mal pazljiv. Dejansko pa ni bug/exploit ampak nepazljivost programerja, ki je uporabil Rails. Jaz imam recimo navado ko delam z Railsi, da preden naredim "stable" verzijo, vedno preverim ce je attr_accessible povsod pravilno nastavljen. Si pa predstavljam da marsikdo pozabi.
MrBrdo

FrEaKmAn ::

ja, to sem se tud jz spraševal pri ror.. mogoče malo čudn feature :)

drugače pa, ne vidim tok problema v tem, da je pač tisti programer zajebu, ampak v odzivu rails developerjev na opozorila. No zdj pa mate :)

Marat ::

hehe a zato sm dubu dons mail od githuba da je treba potrdit ssh key :D

Daedalus ::

vse je bilo dosegljivo, razen ce si mu povedal kaj naj ne bo. ni to bug, ampak je treba biti zelo previden in paziti da ne pustis dosegljivega kar noces, da se spreminja.


To je design fail. Če se greš varnost, prepoveš vse, razen tistega, kar nujno rabiš, da aplikacija deluje po pričakovanjih. Obratni pristop je... pohekan Github.
Man is condemned to be free; because once thrown into the world,
he is responsible for everything he does.
[J.P.Sartre]


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Rails fail

Oddelek: Novice / Varnost
203153 (1762) Daedalus
»

Izšel Rails 3.1

Oddelek: Novice / Ostala programska oprema
353281 (1854) njok
»

Kateri drug programski jezik za HTML/JS programerja?

Oddelek: Programiranje
331810 (580) LeQuack
»

Razbijanje PS3 se nadaljuje

Oddelek: Novice / Ostala programska oprema
427602 (4691) kiFni
»

Pri Facebooku napisali svoj PHP prevajalnik (strani: 1 2 )

Oddelek: Novice / Zasebnost
536457 (3960) nodrim

Več podobnih tem