Re: [ml] Pareri su secuirty.txt
Ciao Marco :) Secondo me va un po' relativizzato il concetto di sicurezza. Se sei un .mil o equivalente allora ok ti seguo negli aspetti di paranoia e di threat analysis su casi di post exploitation con pivoting e via andare. In situazioni piu' semplici, cassare una info condivisa che molto probabilmente sara' comunque messa in qualche pagina il cui indirizzo e' scelto a caso nella foresta di link di un sito, mi sembra un po' eccessivo :) Non sono sicuro sia stato proposto come un modo per dare informazioni sicure, ma un modo per dare informazioni in un punto semplice da condividere. IMHO se fanno un defacement, il problema e' molto piu' grande che avere il security.txt modificato e quindi ingannare chi vuole usare l'email (già pubblica) contenuta nel file. L'owner che si e' preoccupato di inserire le proprie info in un file ad un path condiviso e poi non si preoccupa di controllare lo stato del suo sito ha, anche in questo caso, un problema piu' grosso secondo me :P Infine, tanto per completare il `ragionamento per assurdo`, inviare un report di una vuln su un sito già violato ci possiamo aspettare che il defacer avrà gia buona idea della issue :> .. piove sul bagnato insomma. La soluzione più semplice in assoluto fu proposta da Rain Forest Puppy nel 2000 ed è l'utilizzo di un indirizzo di default per l'invio email con topic sicurezza https://web.archive.org/web/2819053824/http://www.wiretrip.net/rfp/policy.html e a seguire altre versioni: https://web.archive.org/web/20110411004929/http://www.wiretrip.net/rfp/policy.html Lui ha proposto di esporre almeno uno di questi indirizzi: security-alert@[MAINTAINER] secure@[MAINTAINER] security@[MAINTAINER] support@[MAINTAINER] info@[MAINTAINER] E' uno standard de facto utilizzato praticamente da tutti i big e non solo da molti anni ormai. Chiaramente ci sono tantissime situazioni in cui la awareness su security e dintorni c'e' ma i mantainer non hanno email verso il dominio, c'e' whois anonimo etc etc. E' vero, ci sono tante soluzioni piu' sicure che soddisfano i casi di abuso piu' improbabili, ma non sempre il gioco vale la candela, no? Personalmente quando non mi hanno risposto su security@.. ho chiesto anche io su twitter e mi e' (quasi) sempre andata bene. In quei pochi casi negativi..well, their loss :). my 2 cents, Ste On Thu, 2019-02-28 at 11:42 +, Marco Ermini wrote: > Mah, pensandoci meglio, sono estremamente dubbioso. > > L'articolo non approrta, a mio modo di vedere, niente di convincente > in > favore dell'uso di security.txt. > > Offrire una facile fonte di raccolta email per spam come standard mi > sembra > sciocco, e chiamarlo addirittura "security.txt" addirittura ironico. > > Inoltre, in caso di web defacement, non si ha alcuna garanzia della > bontà e > validità di quel file. Si rischia di mandare il report a chi il sito > l'ha > violato... > > Per essere una informazione attendibile ed utile, questo file > dovrebbe per > lo meno: > > 1. essere crittograficamente firmato, con l'hash tenuto off-line in > qualche > altro posto > 2. in alternativa, dato che l'informazione utile è praticamente > grande > quanto l'hash che la firma se non più piccola :-) tenerla > direttamente > off-line > > Vedrei molto meglio questa informazione in un record DNS, per > esempio. > > Tralasciando gli aspetti tecnici, a livello pratico l'esperienza > (almeno la > mia) suggerisce che se qualcuno vuole riportare una vulnerabilità in > modo > responsabile, il modo per farlo lo trova, senza bisogno di questo > file. Se > è un ricercatore con esperienza semplicemente segue gli standard > provveduti > da ISO/IEC 29147 o dalle raccomandazioni ENISA; altrimenti, basta > contattare un CERT, e di solito loro sanno dove andare. Oppure sei > Travis > e mandi un twit ;-) > > A parte le battute, non vedo vantaggi, non mi sembra tecnicamente > solido, e > possibilmente dannoso. > > > Cordiali saluti > > On Thu, 28 Feb 2019 at 04:37, Stefano Di Paola < > stefano.dipa...@wisec.it> > wrote: > > > Non vedo grossi problemi, dato che è una proposta, non ancora > > approvata > > a livello RFC, che vuole semplicemente suggerire un percorso comune > > per > > dare informazioni inerenti aspetti di sicurezza. > > > > Un po' come robots.txt ma per argomenti di sicurezza. > > > > Utile alla stregua delle info Whois inerenti la parte security, ma > > niente di più a parte il fatto che la controlli con maggiore > > semplicità. > > > > Questo articolo linka in fondo vari security.txt: > > https://www.michalspacek.com/what-is-security.txt-and-why-you-should > > - > > have-one > > < > > https://www.michalspacek.com/what-is-security.txt-
Re: [ml] Pareri su secuirty.txt
Non vedo grossi problemi, dato che è una proposta, non ancora approvata a livello RFC, che vuole semplicemente suggerire un percorso comune per dare informazioni inerenti aspetti di sicurezza. Un po' come robots.txt ma per argomenti di sicurezza. Utile alla stregua delle info Whois inerenti la parte security, ma niente di più a parte il fatto che la controlli con maggiore semplicità. Questo articolo linka in fondo vari security.txt: https://www.michalspacek.com/what-is-security.txt-and-why-you-should- have-one Quindi IMO: - molti pro per dare info su sec bug + varie ed eventuali. - nessun contro se sono info pubbliche. Stefano On Tue, 2019-02-26 at 10:11 +0100, roberto diana wrote: > Salve, > > volevo fare un sondaggio per capire se mettere o non mettere in un > sito il > file > security.txt > https://securitytxt.org/ > > pro e contro ? > > grazie > :-) -- ...oOOo...oOOo Stefano Di Paola Software & Security Engineer Owasp Italy R Director CTO MindedSecurity Web: www.mindedsecurity.com www.wisec.it blog: blog.mindedsecurity.com www.wisec.it Twitter: http://twitter.com/WisecWisec .. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Bug inquietante di bash (aka CVE-2014-6271)
Ciao,
niente da dire in realta'.
Non mi baserei su un test per un parser specifico (bash) , quando
abbiamo n dialetti (ash csh etc).
Magari - lo spero - mi sbaglio, e' solo che se testiamo tutto con lo
stesso payload rischiamo di non essere precisi. :)
Cheers
Stefano.
On Thu, 2014-09-25 at 15:29 +0200, Igor Falcomata' wrote:
On Thu, Sep 25, 2014 at 02:48:06PM +0200, Marco d'Itri wrote:
Perche' al volissimo ho provato su busybox 1.21.1 di alpine linux e
direi che e' vulnerabile.
Sei veramente sicuro? La 1.22 di Debian non lo è:
env - x='() { :;}; echo vulnerable' /bin/busybox sh -c /bin/true
Ecco, troppo al volissimo, mea culpa, link non standard a bash (invece
che a busybox) /bin/sh nella vm di test che usavo per altro :(
riassumento, busybox 1.21.1 *non* e' vulnerabile.
sorry,
K.
http://www.sikurezza.org - Italian Security Mailing List
--
...oOOo...oOOo
Stefano Di Paola
Software Security Engineer
Owasp Italy RD Director
Web: www.wisec.it
Twitter: http://twitter.com/WisecWisec
..
http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] bug openssl orrendo... (CVE-2014-0160)
Perfetta affermazione che andrebbe messa in firma da tutti, a meno di volere affermare il contrario. ^^ On Wed, 2014-04-16 at 11:29 +0200, Marco Ermini wrote: (non voglio suggerire che questo sia il modo in cui ragioni *tu* - vorrei solo evitare l'equivoco che qualcuno possa farlo!) Non scherzo. Stefano -- Stefano Di Paola Chief Technology Officer, Lead Auditor ISO 27001 Minded Security - Application Security Consulting Cell: +39 3209495590 Email: stefano.dipaola [at] mindedsecurity.com Minded Security S.r.l. Via Duca D'Aosta, n.20 50129 Firenze (FI) www.mindedsecurity.com _ Pay attention, this email is confidential. If you are not authorized, or if you have received this message by mistake,please not read, use or spread any piece of the information above. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] bug openssl orrendo... (CVE-2014-0160)
Ciao a tutti, mi fa piacere dare il mio contributo alla discussione in particolare per i cosiddetti scettici o minimizzatori. Cosi', per dare un minimo di terreno comune su cui instaurare un dialogo decente, vorrei accennare al fatto che quando _noi_ - me incluso - abbiamo saputo che c'era un problema legato al plugin HeartBeat della lib openssl 1.0.1a-f, non e' *esattamente* quando *tutti* hanno saputo un problema legato al plugin HeartBeat della lib openssl 1.0.1a-f. Se si uniscono i puntini probabilmente ci si rendera' conto che c'e' gente che ha avuto chissa' quanto tempo per estrarre la qualunque dai server bacati (che tra l'altro non sono solo https[1][2]). Detto questo se uno non riesce a scaricare la chiave privata chissene, visto che c'e' un sacco di memoria sharata tra thread che fa trapelare credenziali a go-go (post payloads o, soprattutto, cookies). Basta davvero fare due prove per capire la gravita' della situazione. Mi fermo qui per decenza perche', per intenderci, qualunque software che risponde in rete con memoria non inizializzata e' da considerarsi un serio problema. Se poi il software e' una libreria che e' usata praticamente in tutto il mondo.. beh.. come dicevo, mi fermo qui. Se poi si pensa che solo perche' il server a casa espone tutti 0 allora non e' un problema? beh :) Stefano [1] Qualunque software con la v 1.0.1.a-f di openssl dinamicamente o _staticamente_ compilato con quel plugin bacato (aka device, firmware oltre ai server non patchati in futuro). [2] Openvpn: https://community.openvpn.net/openvpn/wiki/heartbleed E-mail content can be leaked by #heartbleed via SMTP STARTTLS, IMAPS and POP3S services etc.. On Thu, 2014-04-10 at 16:19 +0200, Matteo Beccaro wrote: Funziona bene o male cos??: 1. Si manda una richiesta hearbeat al server mal formata 2. Il server restituisce parte dei dati che ha in memoria, fino a 64k per attacco. Mal formata che vuol dire? Un pacchetto hearbeat ?? formato da un id, un payload length e dal payload. Il bug consiste nel non verificare che il payload length sia corretto per il payload inserito. Quindi dovendo per protocollo rispondere con un payload grande almeno quanto quello originale il server legge il length del payload e se il payload originale ?? pi?? piccolo di quanto dichiarato riempe il payload di risposta con dati della sua memoria, portando al memory leakage. ?? davvero improbabile riuscire ad ottenere in questo modo la priv key per i cert SSL di un sito. Quindi ?? difficile poter fare un mitm con questo attacco o decifrare connessione dumpata e cripatate in SSL. Fine. http://www.sikurezza.org - Italian Security Mailing List -- ...oOOo...oOOo Stefano Di Paola Software Security Engineer Owasp Italy RD Director Web: www.wisec.it Twitter: http://twitter.com/WisecWisec .. -- ...oOOo...oOOo Stefano Di Paola Software Security Engineer Owasp Italy RD Director Web: www.wisec.it Twitter: http://twitter.com/WisecWisec .. http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Drive-by pharming
Il giorno sab, 02/02/2008 alle 17.44 +0100, Andrea Dainese ha scritto:
Chiaro, persò se non sbaglio nell'articolo iniziale si parlava di
semplice link.
Allora, o e' un errore di chi scrive gli articoli, oppure se si guarda
l'articolo originale non parla di cliccare su un link che ti porta sulla
pagina del router, ma di andare su una pagina malicious. o
precedentemente iniettata tramite Xss
http://www.symantec.com/enterprise/security_response/weblog/2007/02/driveby_pharming_how_clicking_1.html
Cito:
(1) All you have to do to become a victim is simply visit the Web
page that hosts this malicious code. You don’t have to click OK on any
dialogue boxes or accidentally download and install malicious software.
Simply viewing the page in question is enough to cause the necessary
damage.
Infatti non era un link con a href='' ma era un csrf sfruttato
usando:
script src = http: // 192.x.x.x/ h_wan_dhcp.cgi?dns1=69.6.6.6
o iframe src o img src
(http://www.heise-security.co.uk/news/85482)
e in particolare legato a una vuln dei 2wire/linksys co.
http://securityreason.com/securityalert/3026
Vero che nel pdf di Symantec si parlava di applet Java, ma mi
concederai che le due cose differiscono e non di poco, anche nella
potenziale diffusione (non basta una semplice link inviato via mail)
Te lo concedo :), pero' nello specifico la richiesta non prevede
password perche' di default non ce l'ha.
[...]
Non e' necessario accedere all'header dal momento che pensa a tutto il
browser(:), sia per i cookie sia per le Authentication.
L'importante e' che l'utente vada su una pagina che contiene il codice
per effettuare l'attacco.
Potresti spiegarti meglio? Nella mia mente, dato che i router
richiedono una autenticazione via authorization-basic, occorrerebbe
incapsulare dentro un link anche il passaggio di utente e password,
magari nella forma http://utente:[EMAIL PROTECTED] Solo che IE
(almeno nella versione 6) non lo permette, e Firefox2 avvisa della
cosa. Hai qualche esempio?
Cambiando la password si puo' mitigare il problema sul router in
questione pero':
1. Se il server (dipende dalla web app dietro) setta un cookie di
autenticazione il browser lo tiene per un certo periodo definito dal
server.
2. Se c'e' una richiesta di autorizzazione.
(http://www.faqs.org/rfcs/rfc2617.html) e ti sei autenticato
precedentemente nella sessione del browser l'attacco funziona ancora
perche' il browser invia l'Authentication: header anche da altre
tab senza richiedere le credenziali.
Esempio:
apri una tab e autenticati, poi apri un'altra tab e vai su una pagina
che contiene uno di questi tag:
iframe src=http:// host/authpage.cgi?par=val/iframe
script src=http:// host/authpage.cgi?par=val/script
img src=http:// host/authpage.cgi?par=val
Se fosse un POST :
form id='r' action=http:// host/authpage.cgi target='iframedi1px'
input type='hidden' value='val' name='par'
/form
scriptdocument.getElementById('r').submit();/script
E' il concetto del CSRF, nient'altro.
Poi, ci sono modi di bruteforzare le pass, come spiega il paper sul
drive by pharming e anche altri studi ma questa e' un altra storia.
Stefano
--
...oOOo...oOOo
Stefano Di Paola
Software Security Engineer
Owasp Italy RD Director
Web: www.wisec.it
..
http://www.sikurezza.org - Italian Security Mailing List
[ml] The first release of SWFIntruder is out !
I am proud to announce first release of SWFIntruder. SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime. It helps to find flaws in Flash applications using the methodology originally described in Testing Flash Applications [1] and in Finding Vulnerabilities in Flash Applications [2] . Some neat feature: * Basic predefined attack patterns. * Highly customizable attacks. * Highly customizable undefined variables. * Semi automated Xss check. * User configurable internal parameters. * Log Window for debugging and tracking. * History of latest 5 tested SWF files. * ActionScript Objects runtime explorer in tree view. * Persistent Configuration and Layout. SWFIntruder is hosted @ OWASP: https://www.owasp.org/index.php/Category:SWFIntruder and is sponsored by Minded Security (http://www.mindedsecurity.com) Check it out and let me know! Any comments will be appreciated. References: [1] http://www.owasp.org/images/8/8c/OWASPAppSec2007Milan_TestingFlashApplications.ppt [2] http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt Regards, Stefano -- Stefano Di Paola Chief Technology Officer Director of Minded Security Research Labs Minded Security - Application Security Consulting www.mindedsecurity.com http://www.sikurezza.org - Italian Security Mailing List
