Domanda:
Come procedere con un hacker dal cappello bianco che rivendica una vulnerabilità?
Vcode
2019-02-14 01:59:04 UTC
view on stackexchange narkive permalink

Sono un membro della sicurezza di una piccola azienda che è stata recentemente contattata da qualcuno che dichiarava di essere un membro Hackenproof e stava segnalando che il nostro sito web veniva indicizzato da googlebot (metadati, contenuto di pagine sottili, problemi con il testo di ancoraggio) e una vulnerabilità XSS .

Non abbiamo ancora alcuna dichiarazione legale che io sappia riguardo alla VDP (politica di divulgazione di vulnerabilità).

Le mie domande:

  1. Fondamentalmente come procedere o addirittura dovremmo? (Sono legittimi?)
  2. Qual è l'aspettativa comune da un hacker bianco?
  3. Come convalidare la vulnerabilità?
secondo https://hackenproof.com/#how-it - "Le vulnerabilità vengono inviate e gestite tramite la nostra piattaforma di coordinamento."sei sicuro di non essere stato contattato dagli stessi hackenproof?il loro intero modello di business consiste nel creare programmi di bug bounty per aziende come la tua che non hanno realmente un focus sulla sicurezza.i loro "membri" si limitano a competere per i bug bounties, non contattano le aziende stesse.
Il minimo che puoi fare è informare il responsabile della sicurezza della tua azienda che sei stato contattato e informato di una vulnerabilità xss.La parte relativa al non rivelare le informazioni è un buon senso.
Sembra terribilmente simile a [questo] (https://security.stackexchange.com/q/178076/168620)
Possibilmente correlato: [Il nostro ufficio è in fiamme.Non abbiamo ancora una politica di risposta al fuoco.Dobbiamo restare fermi o scriverne uno in fretta, che ovviamente non è l'ideale?] (
Tieni presente che ai sensi del GDPR sei tenuto a notificare alle autorità competenti entro 72 ore una violazione dei dati.Potrebbe non essere applicabile a te se non hai clienti dell'UE, ma se lo fai vorrai iniziare ieri.
@Harper Non è un buon confronto, penso che la mia domanda sia chiara su come rispondere al giornalista e quali punti dovremmo considerare per garantire che il giornalista / vulnerabilità sia legittimo.
Qualunque cosa tu faccia, per favore non [tirare un Oracle] (https://web.archive.org/web/20150811052336/https://blogs.oracle.com/maryanndavidson/entry/no_you_really_can_t) e prova a citare in giudizio il biancocappello.
Quando dici "contattato", intendi "inviato via email"?"metadati, contenuto di pagine sottili, problemi con il testo di ancoraggio": questa è la parte che mi fa scattare l'allarme e urla _spammer_, cercando di ottenere affari / denaro.Perché sollevare problemi "potenziali" che non sono correlati al problema di sicurezza principale (a meno che non ci sia un "problema di sicurezza principale" e vogliono solo lavorare sul tuo sito web)?
La vulnerabilità di @Cubic XSS non è una violazione dei dati a meno che l'azienda non scopra che la vulnerabilità è stata utilizzata per violare qualcosa.Sono passate anche 72 ore da quando hai saputo della violazione, non quando un tizio a caso ha detto che ce n'è una.
Cinque risposte:
Buffalo5ix
2019-02-14 03:19:05 UTC
view on stackexchange narkive permalink

Per rispondere a ciascuna delle tue domande:

1. Fondamentalmente come procedere o anche dovremmo?

Consiglio di procedere. Potrai acquisire informazioni preziose che possono essere immediatamente impiegate per migliorare la sicurezza della tua azienda. Non ci hai detto cosa ti ha inviato il ricercatore, ma avranno una descrizione della vulnerabilità o dei metodi per riprodurla. Per procedere avrai bisogno di:

  • Una descrizione / scenario di attacco della vulnerabilità rilevata. Perché questo è un problema, cosa consente specificamente il bug a un utente malintenzionato di fare che non dovrebbe essere in grado di fare, qual è lo scenario / gravità del caso peggiore della scoperta.

  • Fasi di riproduzione. Quali passaggi potresti dare a qualsiasi ingegnere e consentire loro di riprodurre il bug ogni volta.

  • Cosa cerca in cambio l'hacker. Come accennato, potrebbe essere il permesso di pubblicare il ritrovamento dopo aver aggiustato o denaro.

  • Potresti anche richiedere o ricevere consigli per la riparazione, punteggi di rischio, ecc. dal ricercatore.

MOLTO IMPORTANTE: chiarisci al ricercatore che ti aspetti che mantenga il problema riservato fino a quando il problema non viene risolto. Può controbattere con una finestra di risoluzione, ad es. possono pubblicare e l'articolo se il problema non viene risolto entro 60 giorni. Questa è una pratica comune e dovrebbe essere accettabile per la maggior parte delle aziende con una forte posizione di sicurezza.

2. Qual è l'aspettativa comune da un hacker bianco (cappello)?

Dipende dal ricercatore, ma probabilmente chiederà il permesso di pubblicare il risultato una volta corretto, oltre a una ricompensa in denaro. I prezzi dei premi si basano sulla gravità e sulle dimensioni complessive del programma di ricompense. Hackerone, una grande piattaforma di bug bounty, ha una matrice che suggerisce i pagamenti in relazione alle dimensioni dell'azienda / programma di taglie: https://www.hackerone.com/resources/bug-bounty-basics. Determinare il prezzo di pagamento è un'arte sottile: consiglio di cercare bug simili da parte di hackerone o altre piattaforme di bug bounty e di basare il tuo pagamento su ciò che altre società stanno pagando per lo stesso problema.

Ancora una volta, un'aspettativa comune che i ricercatori avranno è che riescono a pubblicare il risultato in un certo periodo di tempo, indipendentemente dal fatto che sia stato risolto o meno. 60 giorni sono comuni, ma non accetterei una quantità di tempo se non sei sicuro che la tua azienda possa consegnare in quella finestra. Dopo aver risolto il problema, l'hacker potrebbe voler verificare che la correzione sia stata implementata correttamente.

3. Come convalidare?

Usa i passaggi di riproduzione forniti dall'hacker. Dovrebbero essere abbastanza chiari da consentire a qualsiasi ingegnere di seguire esattamente i passaggi e riprodurre il bug. Se ci sono problemi qui puoi tornare dal ricercatore e ottenere chiarimenti. È responsabilità dei ricercatori fornire all'azienda le fasi di riproduzione che delineano e identificano il bug.

Una volta risolto il problema, puoi invitare il ricercatore a convalidare la correzione e assicurarti che sia stata corretta completamente.

Il rapporto è su XSS e comprende la parte di riparazione e riproduzione.si tratta di una finestra popup in cui si afferma che un utente malintenzionato può eseguire attacchi di phishing anticipati, eseguire transazioni di pagamento non autorizzate o eseguire azioni arbitrarie per conto della vittima.
Grazie per il contesto!XSS può variare in gravità, se possono veramente eseguire transazioni di pagamento non autorizzate come dicono, allora è sicuramente un problema critico.Ovviamente assicurati di convalidare questa affermazione!È molto difficile parlare di numeri senza avere la sensazione di quanto sia grande la tua azienda o il tuo team di sicurezza: considererei qualcosa di meno di $ 3.000 un pagamento insultantemente basso ** supponendo che tu possa davvero sfruttare questo XSS per drenare fondi.Altrimenti, scopri qual è la cosa peggiore che puoi fare con questo attacco, ovunque da $ 500 a $ 3000 sarebbe tipico per XSS.
+1, buona risposta.Una piccola critica.A meno che non sia già stato stabilito un bug bounty, non credo che dovresti pagarne uno, anche se richiesto.Questo cambia la relazione da contratto sociale a contratto di mercato.I contratti sociali generalmente forniscono più valore di quelli di mercato e funzionano bene per le aziende più piccole poiché possono mantenere contratti sociali molto più facilmente di quanto possano fare le grandi aziende.Se lo trasformi in denaro, è una partita completamente diversa.Dare credito dove il credito è dovuto è più in linea con il contratto sociale.
Buon punto @SteveSether e sicuramente da prendere in considerazione.Con il rischio di trasformare questo thread di commenti in una discussione estesa: personalmente propongo di pagare per i risultati nel tentativo di placare il ricercatore mentre il bug è attivo.Hai ragione che portare soldi nel miscuglio confonde le acque, ma io lo vedo come un male necessario per costruire la buona volontà con il ricercatore e dare loro una ragione per mantenere la riservatezza fino a quando non viene implementata una correzione.
@Buffalo5ix Penso che il problema sia che la tua risposta lo sta inquadrando come un'aspettativa.Personalmente, se non viene stabilito alcun programma di bug bounty, la mia aspettativa è che il bug venga corretto in modo tempestivo e che io possa pubblicarlo.Non mi aspetto denaro (e certamente non lo richiederò, per le implicazioni etiche e legali).Lo inquadrerei come un'azione opzionale che potrebbe essere utilizzata per costruire la buona volontà, invece di un'aspettativa che deve essere soddisfatta.
Come potrei affermare di essere in grado di eseguire transazioni di pagamento non autorizzate senza essere un criminale che ha commesso un reato che vale fino a 10 anni di prigione in modo dimostrabile?Come ti fideresti di me, essendo un criminale?
@Damon Diventare consapevoli delle vulnerabilità in un sito Web (anche un sito Web in grado di avviare transazioni di pagamento) non è un crimine.Non è necessario eseguire effettivamente un attacco per sapere che è possibile.
@Damon eseguendo ogni passaggio tranne che per eseguire effettivamente la transazione finale in modo tale che ora sai con ragionevole sicurezza che * se avessi premuto un pulsante * la transazione sarebbe andata a buon fine.Ovviamente, poiché il tuo obiettivo era semplicemente quello di vedere se l'attacco era possibile senza farlo effettivamente, non sei un criminale.Stai testando i bug del sito con lo scopo di avvisare il proprietario.
@SteveSether La risposta si aspetta un input significativo in termini di tempo e impegno dal bug reporter.È vero che ci sono persone che lo fanno solo per il riconoscimento, ma se ti aspetti che assumano un atteggiamento professionale, è giusto che anche l'azienda adotti un atteggiamento professionale.Che, come ogni altro lavoro specialistico in subappalto, merita un compenso in cambio di competenza e tempo.
@Graham Potresti voler guardare OSS e questo stesso forum per controesempi di ciò che stai descrivendo sopra.Molte persone fanno le cose per amore di farlo, non per soldi.Non devi essere d'accordo, ma dovresti riconoscerlo.
@SteveSether Non sono d'accordo sul fatto che le persone possano farlo solo per divertimento, ma l'azienda che si offre di pagarle per lo sforzo che mettono è un indicatore di come l'azienda valuta tale sforzo.Se il cappello bianco sceglie di donarlo in beneficenza o lo rifiuta, va bene.Tuttavia, diventa una scelta per il cappello bianco, invece della società che presume solo che metteranno tutto questo lavoro per zero ricompensa.
@Graham Il mio punto è più che i contratti sociali sono più preziosi di quelli di mercato, specialmente per (in questo caso) una piccola azienda.Le aziende hanno la capacità di stabilire l'una o l'altra e il contratto sociale dovrebbe essere valutato se si adatta.Alcune aziende potrebbero essere più adatte a un mercato, e va bene.È solo che il valore sociale ei contratti sociali non sono ben riconosciuti nel mondo degli affari e meritano più attenzione.
@SteveSether Sono più preziosi?Possono creare consapevolezza, certo, ma la consapevolezza non è uguale al valore, come tutti su Internet all'inizio degli anni 2000 possono dirti.E se vuoi dare alle persone il diritto di vantarsi, devi pubblicizzare quello che hanno fatto.Per questo tipo di fallimento epico da parte di una piccola azienda, la società è brindisi se diventa pubblica.Se hanno trovato un vero vuln, pagali e NDA.
Steve Sether
2019-02-14 02:50:35 UTC
view on stackexchange narkive permalink

Hackenproof sembra essere un sito web a cui chiunque può iscriversi, quindi dire che sei un membro di Hackproof equivale a dire che sei un membro di Facebook. Questo non è un gruppo di hacker esclusivo.

Non esiste un modo standard ufficiale per procedere con una situazione del genere, poiché la tua azienda, la tua attività, il bug e il cappello bianco varieranno notevolmente. Una taglia non va bene per tutti.

In generale, è consigliabile essere cauti ma curiosi. Stai attento, ma non paranoico e vendicativo. Non fornire alcuna informazione interna al cappello bianco, cerca di ottenere quante più informazioni possibili in anticipo rivelando poco o nulla. Molte di queste persone amano parlare per dimostrare la propria esperienza. Lasciateli fare. Non c'è molto danno che può accadere se le informazioni fluiscono solo in un modo. Chiedigli il codice sorgente o una descrizione dettagliata del problema. Quindi analizza il codice / la descrizione e scrivi il tuo exploit (e non compilare o eseguire il codice white hats), eseguendolo su un'istanza di test, preferibilmente il più isolato possibile da qualsiasi altro ambiente.

As per quanto riguarda le responsabilità di ciascuna parte, la maggior parte delle persone che affermano di essere hacker dal cappello bianco in questi giorni praticherà la divulgazione responsabile e non rilascerà il bug al mondo finché non sarà risolto. La tua responsabilità è correggere il bug (se è abbastanza grave) entro un ragionevole lasso di tempo (diverse settimane, non anni). Se la tua azienda offre taglie, dovrebbero essere pagate se il bug soddisfa i criteri. In caso contrario, il cappello bianco dovrebbe accettare che probabilmente non verranno pagati, ma devi accettare che potrebbero rilasciare il bug al pubblico in generale se non viene risolto in un ragionevole lasso di tempo.

"cerca di ottenere quante più informazioni possibili in anticipo rivelando poco o nulla".Un modo semplice per farlo: "Grazie per averci avvisato! Potresti fornire passaggi per riprodurre?"Non rivela nulla, non promette nulla, chiede tutte le informazioni di cui hai bisogno.Non chiederei nemmeno il codice sorgente a meno che non sia assolutamente necessario, dato che non vorrai eseguirlo.
@jpmc26 Penso che chiedere il codice sorgente separi i pretendenti e gli esperti dai veri cappelli bianchi.Alcune persone potrebbero semplicemente sprecare il tuo tempo e il codice sorgente arriva fino alle puntine.
Sono abbastanza certo che fornire passaggi legittimi per la riproduzione sarebbe altrettanto difficile se non hanno effettivamente trovato una vulnerabilità.Se è davvero abbastanza complicato da richiedere il codice sorgente, qualcuno legittimo probabilmente lo fornirebbe solo quando richiesto per i passaggi, o almeno si offrirà di fornirlo.
Mike Ounsworth
2019-02-14 02:52:26 UTC
view on stackexchange narkive permalink

Non so se ci siano regole ferree qui. Consideriamo questo come teoria dei giochi:

Cosa vuole il ricercatore

Solitamente:

  • Credito pubblico per la scoperta, come un CVE o un documento di ricerca.
  • A volte denaro sotto forma di bug bounty.

Quello che vuoi

Di solito:

  • Non essere umiliato pubblicamente.
  • Per migliorare la sicurezza del tuo prodotto.

Come procedere

Da una teoria dei giochi prospettiva, la situazione vantaggiosa per tutti è che ti rivelino i dettagli, che tu lo aggiusti e che ottengano il loro credito pubblico. Dovresti fissare una telefonata con il ricercatore e chiedere una dimostrazione: puoi guadagnare molto e non perdere nulla. Tieni presente che prima che sia disposto a mostrarti i dettagli, il ricercatore potrebbe volere un accordo di non divulgazione o un altro contratto legale per garantire che ottenga il suo credito alla fine.

ANone
2019-02-15 17:03:18 UTC
view on stackexchange narkive permalink

Potrebbe valere la pena notare che probabilmente sono abbastanza nuovi anche in questo, ci sono molti "professionisti" e se è così che ti guadagni da vivere, probabilmente hai un processo, ma questo normalmente implica un accordo con un'azienda prima di iniziare il lavoro. Ma anche in questo caso varia a seconda delle aziende e del tipo di lavoro.

Questo però mi sembra un entusiasta. Dubito davvero che ci sia qualcosa da perdere parlando con il ragazzo. Potrebbe avere aspettative irrealistiche, ma cosa perdi?

Nota a margine, scusa se questo è paternalistico, ma sento che debba essere detto: è almeno concepibile che questo sia destinato a essere un modo per farti diventare " had ', "possiamo fare una breve chiacchierata su alcuni dettagli di implementazione del tuo sistema" è qualcosa a cui dovresti probabilmente dire "no", anche specialmente se vengono offrendo una carota.

thomasrutter
2019-02-18 07:12:07 UTC
view on stackexchange narkive permalink

Per ripetere ciò che qualcuno ha detto in un commento, sarebbe giusto cercare di escludere una truffa o un'estorsione. Ecco alcune cose da considerare.

  • Viene menzionato il pagamento in risposta a informazioni, anche una sorta di "tassa amministrativa"? Supponendo che tu non abbia alcuna ricompensa di bug preesistente, è improbabile che un ricercatore legittimo chieda denaro: vogliono che il bug venga risolto e la possibilità di ottenere credito per averlo trovato. Chiedere denaro potrebbe essere visto come un tentativo di estorsione o nella migliore delle ipotesi non etico.

  • I passaggi per riprodurli sono abbastanza vaghi da non poter aiutarti a riprodurli? Chiedi ai tuoi ingegneri di indagare in anticipo per sapere esattamente cosa hai e verificare che ci sia una vulnerabilità, anche se minore. Sono un po 'riluttanti a fornire dettagli anche se stai seguendo le normali pratiche? Se qualunque cosa tu faccia, la vulnerabilità rimane vaga e non confermata, potresti non avere a che fare con una segnalazione legittima.

  • Sembrano troppo desiderosi di conoscere le informazioni su come il tuo software lavori o anche informazioni sulla tua azienda o attività?

  • Se la persona afferma di rappresentare un gruppo, puoi verificare che lo faccia effettivamente?

Il modo normale di procedere sarebbe quello di assicurare al giornalista che sei impegnato a correggere il bug, dare un lasso di tempo per la spedizione della correzione (potrebbero aver già specificato un lasso di tempo che vogliono, ma se ciò sembra irragionevole , negoziazione) dopo di che possono pubblicare. Oppure, vedi se puoi chiedere un periodo di grazia in seguito nel caso in cui riescano a testare e scoprire che la vulnerabilità esiste ancora in qualche forma.

Dare soldi in ricompensa è un po 'un dilemma etico, da un lato è bene premiare ma dall'altro se non si ha un bug bounty rischia di incoraggiare la pratica di trovare vulnerabilità e aspettarsi vincite, che si avvicina al comportamento del cappello nero. Di nuovo, fai attenzione se hanno sollevato prima la questione del denaro, anche se intendi dare un po '. Ma se lo fai, sarebbe meglio per tutti se imposti una sorta di programma formale di bug bounty.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...