Una sql injection in active record, ma solo se siete stati incauti e avete distribuito secret.rb http://weblog.rubyonrails.org/2013/1/2/Rails-3-2-1... Paolo
on 2013-01-03 20:32
on 2013-01-03 21:57
Io sto preparando un post sull'exploit. Sinceramente l'approccio che avrei usato un filter su quello che arriva ai dynamic finder methods. Facendo reverse dalla patch per ora nn sono riuscito a scrivere l'exploit. Paolo Il giorno 03/gen/2013 19:33, "Paolo Montrasio" <paolo@paolomontrasio.com> ha scritto:
on 2013-01-04 09:15
Ciao, 2013/1/3 Paolo Perego <thesp0nge@gmail.com>: > Io sto preparando un post sull'exploit. Sinceramente l'approccio che avrei > usato un filter su quello che arriva ai dynamic finder methods. > > Facendo reverse dalla patch per ora nn sono riuscito a scrivere l'exploit. Se non l'avete gia' letto sul blog di Phusion c'e' un post che spiega per bene la cosa: http://blog.phusion.nl/2013/01/03/rails-sql-inject... ciao ciao, matteo.
on 2013-01-04 11:55
Bello, nel frattempo sto preparando un post un po' pippoto su quanto sia bello aggiungere un po' di defensive programming quando prendi params e lo dai in pasto al tuo ORM di quartiere. Paolo 2013/1/4 bugant <bugant@gmail.com> > Se non l'avete gia' letto sul blog di Phusion c'e' un post che spiega > -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-04 12:21
Il giorno 04/gen/2013, alle ore 11:55, Paolo Perego <thesp0nge@gmail.com> ha scritto: > Bello, nel frattempo sto preparando un post un po' pippoto su quanto sia > bello aggiungere un po' di defensive programming quando prendi params e lo > dai in pasto al tuo ORM di quartiere. vabb, se non puoi fidarti neanche del caro vecchio ORM sotto casa (dove magari ti facevi preparare una query prima di andare a scuola), vuol dire che il mondo sta andando davvero a rotoli :'D A. -- http://andreapavoni.com
on 2013-01-04 12:26
>> Bello, nel frattempo sto preparando un post un po' pippoto su quanto sia >> bello aggiungere un po' di defensive programming quando prendi params e lo >> dai in pasto al tuo ORM di quartiere. > vabb, se non puoi fidarti neanche del caro vecchio ORM sotto casa (dove magari ti facevi preparare una query prima di andare a scuola), vuol dire che il mondo sta andando davvero a rotoli :'D Effettivamente, la mia idea di 'defensive programming' e`: "usare in modo corretto l'ORM". Non posso difendermi a priori da tutti gli attacchi possibili... no? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/
on 2013-01-04 12:34
Poi non dovrebbe essere l'ORM a proteggermi dall'SQL injection? E' stato patchato il find_by in ActiveRecord infatti, o no? 2013/1/4 David Welton <davidnwelton@gmail.com> > modo corretto l'ORM". Non posso difendermi a priori da tutti gli > Ml@lists.ruby-it.org > http://lists.ruby-it.org/mailman/listinfo/ml > -- Riccardo -- L'esperienza quello che ottieni quando non ottieni quello che desideri.
on 2013-01-04 12:52
Infatti ActiveRecord ti protegge dalla SQL Injection facendo un filtro
basilare ad esempio sull'escape di caratteri particolari come ', & e
altro.
Nel caso particolare non era un problema di escape quanto di gestione
del
parametro che veniva interpretato come opzioni da passare alla select
invece che come argomento della clausola where:
User.find_by_id(1) # REGULAR CALL => SELECT "users".* FROM "users" WHERE
"users"."id" = 1 LIMIT 1 User.find_by_id({:select =>"* from users where
id=4 --"}) # INJECTION => SELECT * from users where id=4 -- FROM "users"
WHERE "users"."id" IS NULL LIMIT 1
Quello che intendo io con "defensive programming" gestire quanto letto
dall'esterno in maniera coerente con la business logic della nostra
applicazione.
Ad esempio, supponiamo che i nostri id abbiano determinati valori (ad
esempio da 500 a 1200... li ho usati anche nel post :P)... l'approccio
normale sarebbe quello di di passare params[:id] a find_by_id delegando
ad
ActiveRecord tutto quanto.
Secondo me, un approccio difensivo (se volete paranoico ma i casi di SQL
Injection quando accadono... fanno male) quello di aggiungere dei
controlli sul valore del parametro letto in modo da verificare che sia
effettivamente qualcosa di "sensato" per la nostra applicazione.
Voi cosa ne pensate?
Benvenute le critiche anche feroci a questo mio approccio.
Paolo
2013/1/4 Riccardo Lucatuorto <gnuduncan@gmail.com>
> > >> bello aggiungere un po' di defensive programming quando prendi params
> > modo corretto l'ORM". Non posso difendermi a priori da tutti gli
> > Ml@lists.ruby-it.org
> Ml mailing list
> Ml@lists.ruby-it.org
> http://lists.ruby-it.org/mailman/listinfo/ml
>
--
$ cd /pub
$ more beer
The blog that fills the gap between appsec and developers:
http://armoredcode.com
on 2013-01-04 12:53
(ho ipotizzato nel mio post il solito modello User con email e password, da qui l'esempio del find_by_id) :P 2013/1/4 Paolo Perego <thesp0nge@gmail.com> > WHERE "users"."id" IS NULL LIMIT 1 > Injection quando accadono... fanno male) quello di aggiungere dei > 2013/1/4 Riccardo Lucatuorto <gnuduncan@gmail.com> >> sia >> > >> > _______________________________________________ >> L'esperienza quello che ottieni quando non ottieni quello che desideri. > $ more beer > > The blog that fills the gap between appsec and developers: > http://armoredcode.com > -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-04 12:54
imho quando si usa una find_by_something l'orm dovrebbe preoccuparsi che il parametro passato come chiave di ricerca di "something" sia castato al tipo di dato sul db corrispondente, o a stringa se poi ci sono livelli successivi di interpretazione
on 2013-01-04 15:39
Ecco qui il mio post con il pippotto sul defensive programming... scatenatevi con i commenti. http://armoredcode.com/blog/cve-2012-5664-sql-inje... Paolo 2013/1/4 Sante Rotondi <saten.r@gmail.com> > imho quando si usa una find_by_something l'orm dovrebbe preoccuparsi che il > parametro passato come chiave di ricerca di "something" sia castato al tipo > di dato sul db corrispondente, o a stringa se poi ci sono livelli > successivi di interpretazione > _______________________________________________ > Ml mailing list > Ml@lists.ruby-it.org > http://lists.ruby-it.org/mailman/listinfo/ml > -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-04 16:56
> imho quando si usa una find_by_something l'orm dovrebbe preoccuparsi che il > parametro passato come chiave di ricerca di "something" sia castato al tipo > di dato sul db corrispondente, o a stringa se poi ci sono livelli > successivi di interpretazione E soprattutto non capisco che senso abbia consentire di usare un metodo find_by_something omettendo il primo parametro, che sarebbe il "something"... -- Giuseppe Capizzi
on 2013-01-04 17:23
2013/1/4 Giuseppe Capizzi <redstarlabs@gmail.com>: >> imho quando si usa una find_by_something l'orm dovrebbe preoccuparsi che il >> parametro passato come chiave di ricerca di "something" sia castato al tipo >> di dato sul db corrispondente, o a stringa se poi ci sono livelli >> successivi di interpretazione > > E soprattutto non capisco che senso abbia consentire di usare un > metodo find_by_something omettendo il primo parametro, che sarebbe il > "something"... da quel che capisco io accidentale, per il fatto che i dynamic finder prendono comunque un numero di argomenti variabili (nel senso di #find_by_x_and_y) e il caso in cui ci fossero meno parametri di quelli impliciti nel nome non era gestito. La patch fa esattamente questo check. -- twitter: @riffraff blog (en, it): www.riffraff.info riffraff.blogsome.com work: circleme.com
on 2013-01-05 00:11
@Paolo Perego: qualcosa era stato fatto https://github.com/medihack/param_checker Uno dei problemi è come segnalare che i parametri sono sbagliati. Non solo degli attaccanti potrebbero mandare valori sbagliati, ma anche utenti normali. Aggiungere messaggi a errors e usare i normali meccanismi di active record?
on 2013-01-06 01:40
Il giorno 05 gennaio 2013 00:11, Paolo Montrasio <paolo@paolomontrasio.com>ha scritto: > @Paolo Perego: qualcosa era stato fatto > https://github.com/medihack/param_checker > Uno dei problemi come segnalare che i parametri sono sbagliati. Non > solo degli attaccanti potrebbero mandare valori sbagliati, ma anche > utenti normali. Aggiungere messaggi a errors e usare i normali > meccanismi di active record? Per le query pi complesse (es. ricerche) io creo sempre un oggetto pi complesso su cui configurare tutte le varie opzioni. E' un'ordine di grandezza pi facile da sviluppare e testare. Usare le valditations mi sembra una buona strada.
on 2013-01-06 19:51
Matteo Collina wrote in post #1091180: > Per le query pi complesse (es. ricerche) io creo sempre un oggetto pi > complesso su cui configurare tutte le varie opzioni. > E' un'ordine di grandezza pi facile da sviluppare e testare. Più o meno riesco ad immaginarlo ma ci puoi fare un esempio? Grazie
on 2013-01-06 23:15
Ultimamente sto facendo una cosa simile anche io. Immaginando di avere
un modello AR ed una vista contenente una tabella che mostra esso e dati
provenienti da altre N tabelle in join con esso (con necessit di operare
degli ordinamenti eventuali sui dai provenienti dalle join).
In questo caso quello che faccio una cosa tipo (molto schematizzato):
class SearchProxy
def initialize(user, project, options={})
end
def entries
find
filter
sort
paginate
end
private
def find
end
def filter
end
def sort
end
def paginate
end
end
I cardini dell'oggetto li passo nell'initializer, gli altri parametri
nelle options e poi dentro faccio le cose che servono, le join, le
concatenazioni AR, dei query methods accessori, le memoizzazioni
necessarie e via dicendo. Viene molto fico.
-f
on 2013-01-09 23:43
Hanno trovato un'altra vulnerabilità, più seria della precedente: https://groups.google.com/forum/?fromgroups=#!topi... Altro upgrade! Paolo
on 2013-01-10 01:30
Ho appena finito di patchare al volo pi di 30 app in prod. Che sudata. Se qualcuno di voi ha bisogno di un POC che ho scritto per verificare se la vostra app sia vulnerabile o meno (ad es dopo l'applicazione della patch via initializer) mi scriva. Non lo sharo perch sono stati gi distribuiti troppi dettagli in merito alla vuln. Ciao, On Jan 9, 2013, at 11:43:07 PM, Paolo Montrasio wrote: > Hanno trovato un'altra vulnerabilit, pi seria della precedente: > https://groups.google.com/forum/?fromgroups=#!topi... > > Altro upgrade! ~Marcello
on 2013-01-10 10:37
come non detto: https://github.com/rapid7/metasploit-framework/pull/1281 aggiornate / patchate ASAP! ~Marcello -- ~ vjt@openssl.it ~ http://sindro.me/
on 2013-01-10 10:50
Integro con questo: https://community.rapid7.com/community/metasploit/... Vi racconto comunque una cosa, nel campo della security spesso si predilige l'approccio di disclosure dopo che la vulnerabilit stata notificata e chi mantiene il codice ha rilasciato la patch. Quindi di solito quando la patch rilasciata, l'exploit da considerarsi pubblicabile. Cos, giusto per dirvi l'approccio che di solito si usa lato security :) Detto questo Marcello, hai assolutamente ragione. Questo aggiornamento da fare al volo con priorit massima. Ciao Paolo 2013/1/10 Marcello Barnaba (void) <vjt@openssl.it> > > > Non lo sharo perch sono stati gi distribuiti troppi dettagli in merito > >> Altro upgrade! > > > > _______________________________________________ > > Ml mailing list > > Ml@lists.ruby-it.org > > http://lists.ruby-it.org/mailman/listinfo/ml > _______________________________________________ > Ml mailing list > Ml@lists.ruby-it.org > http://lists.ruby-it.org/mailman/listinfo/ml > -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-10 11:05
che palle!!!!! La versione 3.2.11 e' a posto? Ho aggiornato ieri un sito con RefineryCMS Grazie per le info Davide
on 2013-01-10 11:09
Postilla mia a quanto giustamente detto da Paolo, visto il numero di persone che sta scrivendomi mail e/o sui social Il fatto che in seguito alla prima vulnerabilit patchata siano emerse le successive, con conseguente rincorsa alle patch/aggiornamento di una marea di applicazioni RoR in giro, s un enorme rottura di scatole e dispendio di tempo, ma da considerarsi una fortuna dato che _adesso_ queste vulnerabilit sono note e ne siamo al riparo in futuro, mentre prima erano alla portata di qualsiasi hacker. Anzi sono pronto a scommettere che se ci mettiamo una settimana a guardare cos'altro c' in giro in action pack, active record e soci, ne troviamo un altro paio di cos gustose, ed quasi certamente questo quello che hanno pensato quelli che hanno visto il primo cve pubblicato. My two cents ;) Sante
on 2013-01-10 11:12
Non solo... se ci mettiamo a guardare Sinatra, Padrino, Datamapper... chiss cosa troviamo... mi sa che tutto materiale per il mio blog :) Paolo 2013/1/10 Sante Gennaro Rotondi <saten.r@gmail.com> > Anzi sono pronto a scommettere che se ci mettiamo una settimana a guardare > Ml@lists.ruby-it.org > http://lists.ruby-it.org/mailman/listinfo/ml > -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-10 11:22
evviva i 0-days insomma... siete degli hackeroni .. :-) Considerato il traffico sui sito che mantengo una SQL injection sarebbe quasi un onore :-) D
on 2013-01-10 13:35
_______________________________________________ Ml mailing list Ml@lists.ruby-it.org http://lists.ruby-it.org/mailman/listinfo/ml
on 2013-01-10 13:47
2013/1/10 Davide Rambaldi <davide.rambaldi@gmail.com> > > Considerato il traffico sui sito che mantengo una SQL injection sarebbe > quasi un onore :-) > > purtroppo non si tratta (solo) di SQL-injection, lasciare rails unpatched puo' portare all'esecuzione remota di comandi *sul server* Qui c'e' la spiegazione piu' completa che ho trovato del bug: http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html Luca
on 2013-01-10 13:56
Ciao, riguardo il POC il mio server (rails 3.2.11) mi dice Hash::DisallowedType (Disallowed type attribute: "yaml") e' male? e' bene? Secondo me e' bene, ma ditemi voi che siete "sul pezzo" :-) Grazie Davide
on 2013-01-10 14:01
Rails 3.2.11 ha il fix per la vulnerabilit - quindi sei a posto :-). Occhio solo alle regression che stanno venendo discusse qui: https://github.com/rails/rails/issues/8832 Ciao :-) On Jan 10, 2013, at 1:55:57 PM, Davide Rambaldi wrote: > Ciao, riguardo il POC > > il mio server (rails 3.2.11) mi dice > > Hash::DisallowedType (Disallowed type attribute: "yaml") > > e' male? e' bene? > > Secondo me e' bene, ma ditemi voi che siete "sul pezzo" :-) > ~Marcello
on 2013-01-10 14:24
2013/1/10 Marcello Barnaba (void) <vjt@openssl.it> > Eventually - il POC con relative istruzioni per testare le vostre app > dopo update / patch in allegato :-). > grazie! aggiungo solo che per chi ne avesse ancora online, che rails < 2.0 non e' vulnerabile (il parsing dell'xml non faceva typecast su yaml), mentre rails 2.x < 2.3 e' vulnerabile. Avendone bisogno ho portato la patch di rails 2.3 su 2.0, poi ci sarebbe da controllare di non avere attivato il YAML tra i default parsers: e' disabilitato da rails 1.1.x, ma poteva essere riabilitato con: ActionController::Base.param_parsers[Mime::YAML] = :yaml #per rails <= 2 oppure: ActionDispatch::ParamsParser::DEFAULT_PARSERS[Mime::YAML] = :yaml #per rails >= 3 per disabilitarlo dovrebbe essere sufficiente mettere questo in un initializer: ActionController::Base.param_parsers.delete(Mime::YAML) #per rails <= 2 oppure: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::YAML) #per rails >= 3 infine... visto che la vulnerabilita' e' in activesupport non e' solo rails ad essere interessato, ma anche padrino che usa activesupport ciao, Luca
on 2013-01-10 15:02
2013/1/10 Marcello Barnaba (void) <vjt@openssl.it> > > Premesso che il "mondo security" fatto principalmente di fuffa e > celolunghismo :-), la mia personale visione di "responsible disclosure" > Dai... principalmente ma non sempre :-) > sono almeno 3 giorni dalla pubblicazione della patch alla pubblicazione > dell'exploit. > S per considera questo. Metasploit un prodotto usato anche in azienda, ad esempio assieme a Nexpose per la parte di assessment. Avere a disposizione il modulo subito torna utile per chi fa ethical hacking dall'interno. > D'altro canto, riconosco che molti Ruby dev non siano affatto security > conscious, e quindi un'esperienza di compromise pu essere loro utile a > diventarlo. > Ecco, per io in questo caso non lo auspico. Spero piuttosto che si siano letti questo ( http://armoredcode.com/blog/cve-2012-5664-sql-inje...) e dopo aver pensato "Che palle sto pippone sulla input validation", abbiano detto... "mmmh... per magari tra 1 settimana pu saltar fuori un'altra vulnerabilit su ActiveRecord e/o similia... se passo al mio ORM un input fidato, posso andare pi soft con il patching e sono "pi robusto" rispetto agli 0 day. > Ancora: avere gi il modulo di metasploit far s che le aziende che > usano Rails e non hanno una policy che permetta di rispondere a queste > evenienze saranno sfondate, e questo pu esser visto come un "bene" per la loro evoluzione - o come un "male" dato che dati saranno trafugati e > utenti truffati. > Assolutamente, il tuo punto di vista ha ovviamente senso... per in questo caso, che la patch fuori... quale sarebbe stato il tempo giusto per pubblicare l'exploit? Siamo certi che in questo tempo tutti sarebbero corsi ai ripari? Ciao ciao Paolo -- $ cd /pub $ more beer The blog that fills the gap between appsec and developers: http://armoredcode.com
on 2013-01-11 14:14
Se vi capita di avere applicazioni Rails molto vecchie ( 2.1.2 ), e non
avete tempo ora di aggiornare almeno alla 2.3,
possibile proteggersi come come descritto nel CVE:
E' sufficiente mettere in un initializer:
ActionController::Base.param_parsers.delete(Mime::YAML)
e se non avete bisogno di parsare XML:
ActionController::Base.param_parsers.delete(Mime::XML)
Se invece dovete parsare XML:
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol')
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml')
(PS: correggetemi se sbaglio)
-f
on 2013-01-12 13:00
Non ancora finita: anche multi_xml soffre del medesimo bug: http://news.ycombinator.com/item?id=5040457 https://gist.github.com/d7f6d9f4925f413621aa Se usate multi_xml per parsare XML che arriva dall'esterno, siete ancora vulnerabili. Buon aggiornamento, ~Marcello
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.