Se lavori nella sicurezza, è probabile che tu abbia trascorso gli ultimi giorni a rispondere urgentemente alla vulnerabilità Log4Shell (CVE-2021-44228), indagando dove hai istanze di Log4j nel tuo ambiente e interrogando i tuoi fornitori sulla loro risposta. Probabilmente hai già letto le implicazioni e i passaggi da seguire. Questo blog è per tutti coloro che vogliono capire cosa sta succedendo e perché Internet sembra essere di nuovo in fiamme. E per voi professionisti della sicurezza, abbiamo anche incluso alcune domande sulle implicazioni più ampie e sulla visione a lungo termine. Sai, per tutto quel tempo libero che hai in questo momento.
Che cos'è Log4Shell?
Log4Shell, noto anche come CVE-2021-44228, è una vulnerabilità critica che consente l'esecuzione di codice remoto nei sistemi che utilizzano Log4j della Apache Foundation, una libreria Java open source ampiamente utilizzata in prodotti e utilità software commerciali e open source. Per una valutazione tecnica più approfondita di Log4Shell, consulta l'analisi AttackerKB di Rapid7.
Che cos'è Log4j?
Log4j è uno degli strumenti più comuni per inviare testo da archiviare in file di registro e/o database. È utilizzato in milioni di applicazioni e siti Web in ogni organizzazione in tutta Internet. Ad esempio, le informazioni vengono inviate per tenere traccia dei visitatori del sito Web, annotare quando si verificano avvisi o errori durante l'elaborazione e aiutare a supportare i problemi di triage dei team.
Allora qual è il problema?
Si scopre che Log4j non registra solo stringhe semplici. Le stringhe di testo formattate in un certo modo saranno eseguite proprio come una riga di un programma per computer. Il problema è che questo consente agli attori malintenzionati di manipolare i computer in tutto Internet per fargli compiere azioni senza la volontà o il permesso dei proprietari del computer. Gli attacchi informatici possono usare questo per rubare informazioni, forzare azioni o estorcere denaro ai proprietari o agli operatori del computer.
Questa vulnerabilità è ciò a cui ci riferiamo come Log4Shell, o CVE-2021-44228. Log4j è la tecnologia vulnerabile. Poiché questa è una situazione in continua evoluzione, puoi sempre andare al nostro blog principale in diretta su Log4Shell.
È davvero una cosa così importante?
In una parola, sì.
Caitlin Kiska, un ingegnere della sicurezza informatica presso Cardinal Health, l'ha messa così : "Immaginate che ci sia uno specifico tipo di bullone utilizzato nella maggior parte delle auto e dei componenti di auto nel mondo, e che abbiano appena detto che quel bullone deve essere sostituito." Glenn Thorpe, Emergent Threat Response Manager di Rapid7 ha aggiunto, "... e la presenza di quel bullone consente a chiunque di impossessarsi dell'auto."
Il primo problema è l'uso diffuso di Log4j. Questo piccolo strumento è utilizzato in innumerevoli sistemi su Internet, il che rende la correzione o la mitigazione di questo un compito enorme, e rende più probabile che qualcosa possa essere trascurato.
Il secondo problema è che gli aggressori possono usarlo in vari modi, quindi per loro il limite è il cielo.
Forse la preoccupazione più grande di tutte è che in realtà è piuttosto facile usare la vulnerabilità per scopi malevoli. Le vulnerabilità di esecuzione di codice remoto sono sempre preoccupanti, ma si spera che siano complicate da sfruttare e richiedano competenze tecniche specialistiche, limitando chi può trarne vantaggio e rallentando il ritmo degli attacchi in modo che i difensori possano idealmente intraprendere prima azioni correttive. Non è questo il caso di Log4Shell. Lo strumento Log4j è progettato per inviare qualsiasi dato immesso nel formato corretto, quindi finché gli aggressori sanno come formare i loro comandi in quel formato (il che non è un segreto), possono trarre vantaggio da questo bug, e attualmente lo stanno facendo.
Sembra piuttosto brutto. La situazione è senza speranza?
Assolutamente no. La buona notizia è che la Apache Foundation ha aggiornato Log4j per risolvere la vulnerabilità. Tutte le organizzazioni devono urgentemente verificare la presenza di questa vulnerabilità nel loro ambiente e aggiornare i sistemi interessati all'ultima versione patchata.
Il primo aggiornamento, la versione 2.15.0, è stato rilasciato il 6 dicembre 2021. Con l'aumento dello sfruttamento in natura, è diventato chiaro che l'aggiornamento non risolveva completamente il problema in tutti i casi d'uso, una vulnerabilità che il National Vulnerability Database (NVD) ha codificato come CVE-2021-45046 .
Di conseguenza, il 13 dicembre, la Apache Foundation ha rilasciato la versione 2.16.0, che rimuove completamente il supporto per i modelli di ricerca dei messaggi, chiudendo così definitivamente la porta alla funzionalità JNDI e probabilmente aggiungendosi agli arretrati del team di sviluppo per aggiornare le sezioni del materiale sulla loro base di codice che gestiscono la registrazione.
Sembra semplice, vero?
Sfortunatamente, sarà probabilmente un'impresa piuttosto imponente e richiederà diverse fasi di individuazione e di bonifica/mitigazione.
Bonifica
Il primo corso d'azione è identificare tutte le applicazioni vulnerabili, che possono essere un mix di soluzioni fornite dal fornitore e applicazioni sviluppate internamente. NCSC NL sta mantenendo un elenco di software interessati, ma le organizzazioni sono incoraggiate a monitorare direttamente gli avvisi e le release del fornitore per le informazioni più aggiornate.
Per le applicazioni sviluppate internamente, le organizzazioni, come minimo, devono aggiornare le proprie librerie Log4j all'ultima versione (che, al 14-12-2021, è la 2.16) e applicare le mitigazioni descritte nel post iniziale del blog di Rapid7 su CVE-2021-44228, che include l'aggiunta di un parametro a tutti gli script di avvio Java e incoraggia vivamente l'aggiornamento delle installazioni di macchine virtuali Java alle versioni più recenti e sicure. Un'ulteriore risorsa, pubblicata dall'Apache Security Team, fornisce un elenco curato di tutti i progetti Apache interessati , che può essere utile per accelerare l'identificazione e la scoperta.
Se i team eseguono controlli "remoti" (vale a dire sfruttando la vulnerabilità da remoto come farebbe un aggressore) anziché controlli "autenticati" sui file system locali, i controlli remoti dovrebbero essere effettuati sia tramite indirizzo IP sia tramite nome di dominio completamente qualificato/nome host virtuale, poiché potrebbero essere in gioco diverse regole di routing che la scansione tramite solo indirizzo IP non riuscirebbe a rilevare.
Queste mitigazioni devono essere eseguite ovunque ci sia un'istanza vulnerabile di Log4j. Non dare per scontato che il problema si applichi solo ai sistemi rivolti a Internet o ai sistemi in esecuzione live. Potrebbero esserci lavori batch che vengono eseguiti ogni ora, ogni giorno, ogni settimana, ogni mese, ecc., su dati archiviati che potrebbero contenere stringhe di exploit che potrebbero innescare l'esecuzione.
Scienze forensi
Gli attacchi sono attivi almeno dal 1° dicembre 2021 e ci sono prove che questa debolezza sia nota almeno da marzo 2021. Pertanto, è abbastanza prudente adottare una mentalità "presunta violazione". NCSC NL ha un'ottima pagina di risorse sui modi in cui è possibile rilevare i tentativi di sfruttamento dai file di registro delle applicazioni. Si prega di notare che questo non è solo un attacco basato sul Web. Le vetrine iniziali di exploit, piuttosto pubbliche, includevano la modifica del nome dei dispositivi iOS e delle auto Tesla. Entrambe queste aziende estraggono regolarmente metadati dai rispettivi dispositivi e sembra che quelle stringhe siano state passate ai gestori di Log4j da qualche parte nella catena di elaborazione. Dovresti esaminare i registri di tutti i sistemi rivolti a Internet, nonché ovunque si verifichi l'elaborazione di Log4j.
I tentativi di sfruttamento si baseranno generalmente sull'estrazione di risorse esterne (come nel caso di qualsiasi attacco dopo aver ottenuto l'accesso iniziale), quindi i rilevamenti comportamentali potrebbero aver già individuato o fermato alcuni attacchi. La debolezza di Log4j consente percorsi di esfiltrazione dei dati piuttosto intelligenti, in particolare DNS. Gli aggressori estraggono valori da variabili di ambiente e file con percorsi di file system noti e creano nomi di dominio dinamici da essi. Ciò significa che le organizzazioni dovrebbero esaminare i log delle query DNS risalendo il più indietro possibile. Nota: ciò potrebbe richiedere un bel po' di tempo e impegno, ma deve essere fatto per assicurarsi di non essere già una vittima.
Risposta proattiva
Per eccesso di cautela, le organizzazioni dovrebbero anche prendere in considerazione la rinumerazione dei segmenti IP critici (in cui risiedeva Log4j), la modifica dei nomi host sui sistemi critici (in cui risiedeva Log4j) e la reimpostazione delle credenziali, in particolare quelle associate ad Amazon AWS e ad altri provider cloud, nel caso in cui siano già state esfiltrate.
Chi dovrebbe prestare attenzione a questo?
Praticamente ogni organizzazione, indipendentemente dalle dimensioni, dal settore o dalla geografia. Se hai qualsiasi tipo di presenza web o connettività internet, devi prestare attenzione e controllare il tuo stato. Se esternalizzi tutti gli aspetti tecnici della tua attività, chiedi ai tuoi fornitori cosa stanno facendo a riguardo.
Chi lo sfrutta e come?
Un po'... tutti .
I ricercatori “benigni” (alcuni indipendenti, altri parte di aziende di sicurezza informatica) stanno utilizzando l’exploit per ottenere una comprensione iniziale della superficie di attacco di base rivolta a Internet.
Anche i cyberattaccanti sono molto attivi e stanno correndo per sfruttare questa vulnerabilità prima che le organizzazioni possano mettere in atto le loro patch. Le botnet, come Mirai, sono state adattate per usare il codice exploit sia per esfiltrare dati sensibili sia per ottenere l'accesso iniziale ai sistemi (alcuni in profondità all'interno delle organizzazioni).
I gruppi ransomware sono già entrati in azione e hanno sfruttato la debolezza di Log4j per compromettere le organizzazioni. Il progetto Heisenberg di Rapid7 sta raccogliendo e pubblicando campioni di tutti i tentativi unici visti dall'11 dicembre 2021.
Come è probabile che si sviluppino le cose?
Queste campagne iniziali sono solo l'inizio. Attacchi sofisticati da parte di gruppi più seri e capaci appariranno nei prossimi giorni, settimane e mesi e probabilmente si concentreranno su software di livello aziendale che è noto per essere vulnerabile.
La maggior parte dei tentativi di attacco iniziali avviene tramite punti di iniezione focalizzati sul sito Web (campi di input, caselle di ricerca, intestazioni, ecc.). Ci saranno campagne più avanzate che colpiranno gli endpoint API (anche API "nascoste" che fanno parte delle app mobili aziendali) e cercheranno di trovare modi furtivi per far passare le stringhe di exploit oltre le guardie di gate (come l'esempio di ridenominazione del dispositivo iOS).
Anche le organizzazioni che hanno rimediato alle applicazioni distribuite potrebbero non notare alcune immagini di macchine virtuali o container che vengono avviate regolarmente o meno. Gli attacchi Log4Shell sono facilmente automatizzabili e li vedremo regolarmente come vediamo WannaCry e Conficker (sì, vediamo ancora parecchi exploit regolarmente per quelle vulnerabilità).
Dobbiamo preoccuparci di vulnerabilità simili in altri sistemi?
Nell'immediato, i team di sicurezza dovrebbero concentrare la loro attenzione sull'identificazione dei sistemi con i pacchetti Log4j interessati.
Nel lungo termine, sebbene sia impossibile prevedere l'identificazione di vulnerabilità simili, sappiamo che la facilità e la prevalenza di CVE-2021-44228 richiedono la continua attenzione (è stato un lungo weekend per molti) dei team di sicurezza, infrastruttura e applicazioni.
Insieme a Log4Shell, abbiamo anche CVE-2021-4104 , segnalato il 9 dicembre 2021, un difetto nella libreria di registrazione Java Apache Log4j nella versione 1.x. JMSAppender che è vulnerabile alla deserializzazione di dati non attendibili. Ciò consente a un aggressore remoto di eseguire codice sul server se l'applicazione distribuita è configurata per utilizzare JMSAppender e il JMS Broker dell'aggressore. Nota che questo difetto riguarda solo le applicazioni che sono specificamente configurate per utilizzare JMSAppender, che non è l'impostazione predefinita, o quando l'aggressore ha accesso in scrittura alla configurazione Log4j per aggiungere JMSAppender al JMS Broker dell'aggressore.
I vettori di exploit di Log4Shell e le mitigazioni segnalate venerdì continuano a evolversi come segnalato dai nostri partner di Snyk.io e dal Java Champion, Brian Vermeer (vedere "Nota dell'editore (13 dicembre 2021)"), pertanto, la vigilanza continua su questa minaccia imminente e presente è tempo ben speso. Gli esercizi postmortem (e ce ne saranno molti) dovrebbero assolutamente includere sforzi per far evolvere inventari di dipendenze software, open source e pacchetti e, dati gli impatti attuali, modellare meglio le minacce dai pacchetti con un comportamento di ricerca non ispezionato simile.
Questo problema indica che dovremmo smettere di compilare sistemi e tornare a costruirli da zero?
Si è sicuramente parlato molto della dipendenza da così tante dipendenze di terze parti in tutte le aree dello sviluppo software. Abbiamo assistito a molti tentativi di avvelenare numerosi ecosistemi quest'anno, da Python a JavaScript, e ora abbiamo una vulnerabilità critica in un componente quasi onnipresente.
Da un lato, c'è un merito nell'affidarsi esclusivamente al codice che sviluppi internamente, basato sulle funzionalità principali del tuo linguaggio di programmazione preferito. Puoi sostenere che questo renderebbe la vita degli aggressori più difficile e ridurrebbe il botto che ottengono per il loro denaro.
Tuttavia, sembra un po' folle rinunciare completamente ai volumi di componenti pre-costruiti, ricchi di funzionalità e altamente utili. E non dimentichiamo che non tutti i software sono creati uguali. L'ideale è che il software creato e condiviso dalla comunità tragga vantaggio da molte più mani alla pompa, occhi più critici e un periodo più lungo per maturare.
La lezione dalla debolezza di Log4Shell sembra abbastanza chiara: usa, ma verifica e supporta! Librerie come Log4j traggono vantaggio dall'ampia adozione della comunità, poiché acquisiscono grandi funzionalità che possono essere sfruttate rapidamente ed efficacemente. Tuttavia, non puoi semplicemente dare per scontato che tutto vada e andrà bene in un dato ecosistema, e devi assolutamente far parte della comunità che esamina le richieste di modifica e funzionalità. Se più occhi fossero puntati sulla richiesta iniziale di aggiungere questa funzionalità piuttosto folle (esecuzione dinamica dei messaggi) e più persone esperte di sicurezza fossero nel flusso di approvazione, molto probabilmente non staresti leggendo questo post in questo momento (e sarebbe uno degli episodi Marvel "What If…?" più noiosi di sempre).
Le organizzazioni dovrebbero sedersi al tavolo delle trattative, offrire supporto nella creazione e revisione del codice e prendere in considerazione il finanziamento di progetti che diventino componenti fondamentali o onnipresenti nel vostro ambiente di sviluppo delle applicazioni.
In che modo una distinta base del software (SBOM) avrebbe influito su questo problema?
Per definizione, una distinta base è un inventario e concettualmente dovrebbe contribuire ad accelerare i tempi di scoperta durante le esercitazioni di risposta alle vulnerabilità emergenti, come l'incidente Log4j in cui siamo coinvolti collettivamente in questo momento.
Uno SBOM è concepito come un record formale che contiene i dettagli e le relazioni della supply chain di vari componenti utilizzati nel software, un po' come un elenco di ingredienti per la tecnologia. In questo caso, tali componenti includerebbero librerie java utilizzate per la registrazione (ad esempio Log4j2).
I requisiti SBOM sono stati inclusi nell'ordine esecutivo statunitense emesso a maggio 2021. Sebbene possano esserci variazioni internazionali, il concetto e gli oggetti previsti sono uniformi. Per questo motivo, farò riferimento ai progressi statunitensi per semplicità.
Da: Elementi minimi per una distinta base del software (SBOM), emesso dal Dipartimento del Commercio, in coordinamento con la National Telecommunications and Information Administration (NTIA), 12 luglio 2021
La domanda con cui molti rispondenti di Log4Shell, tra cui CISO, sviluppatori, ingegneri, amministratori di sistema, clienti e consumatori, si stanno ancora confrontando è semplicemente dove le versioni interessate di Log4j sono in uso all'interno dei loro ecosistemi tecnici. Mantenere inventari accurati delle risorse è diventato sempre più difficile man mano che i nostri ambienti tecnici sono diventati più complicati, interconnessi e di vasta portata. La nostra dipendenza sempre crescente dalle tecnologie connesse a Internet e l'ascesa dell'IT ombra non fanno che peggiorare questo problema.
Le vulnerabilità in strumenti come Log4j, ampiamente utilizzati in una vasta gamma di tecnologie e sistemi, evidenziano la necessità di maggiore trasparenza e automazione per la gestione di asset e inventari. Forse l'impatto sostanziale a lungo termine di Log4Shell sarà quello di riorientare gli investimenti e l'apprezzamento per la crucialità di un inventario accurato di software e componenti associati tramite uno SBOM che può essere facilmente interrogato e collegato alle dipendenze.
In conclusione, se avessimo vissuto in un periodo in cui gli SBOM erano obbligatori e in atto per tutti i progetti software, l'identificazione dei prodotti, dei dispositivi e degli ecosistemi interessati sarebbe stata molto più semplice di quanto non lo sia stata per Log4Shell e la correzione sarebbe stata probabilmente più rapida ed efficace.
In che modo Log4Shell influisce sul mio stato normativo? Devo adottare misure speciali per garantire la conformità?
Secondo Harley Geiger, esperto di policy e conformità di Rapid7, "Gli enti regolatori potrebbero non aver previsto Log4Shell, ma ora che la vulnerabilità è stata scoperta, ci si aspetta che le aziende regolamentate la affrontino. Mentre i programmi di sicurezza delle organizzazioni affrontano questa vulnerabilità diffusa e grave, tali azioni dovrebbero essere allineate con i requisiti di conformità e la segnalazione. Per molte aziende regolamentate, la scoperta di Log4Shell innesca la necessità di rivalutare i rischi aziendali, l'efficacia delle loro misure di sicurezza per proteggere sistemi e informazioni sensibili (inclusa la patch alla versione più recente) e la prontezza dei loro processi di risposta agli incidenti per affrontare il potenziale sfruttamento di Log4j. Molte normative richiedono inoltre che questi obblighi vengano trasferiti ai fornitori di servizi. Se uno sfruttamento di Log4j comporta un'interruzione significativa dell'attività o una violazione delle informazioni personali, le normative potrebbero richiedere all'azienda di emettere un rapporto sugli incidenti o una notifica di violazione".
Abbiamo anche chiesto ad Harley se è probabile che assisteremo a una risposta di politica pubblica. Ecco cosa ha detto...
"A livello di politica federale, le organizzazioni dovrebbero aspettarsi una spinta rinnovata per l'adozione di SBOM per aiutare a identificare la presenza di Log4j (e altre vulnerabilità) nei prodotti e negli ambienti in futuro. La CISA ha anche richiesto alle agenzie federali di accelerare la mitigazione di Log4j e ha intensificato la condivisione delle informazioni relative alla vulnerabilità. Ciò potrebbe dare impulso alla legislazione sulla segnalazione degli incidenti informatici che sta circolando al Congresso al momento".
Come sappiamo tutto questo?
Bene, un gruppo di ragazzi ha iniziato a creare scompiglio nei server di Minecraft e da lì le cose sono andate semplicemente in discesa. Sebbene ci sia del vero in questo, la realtà è che è stato presentato un problema al progetto Log4j a fine novembre 2021. Il codice proof-of-concept è stato rilasciato a inizio dicembre e gli attacchi attivi sono iniziati poco dopo. Alcuni fornitori di sicurezza informatica hanno prove di attacchi preliminari a partire dal 1° dicembre 2021.
Chiunque monitorasse le discussioni sul problema (cosa che sia gli sviluppatori, sia i difensori che gli aggressori fanno regolarmente) avrebbe notato il buco enorme creato da questa "funzionalità".
Da quanto tempo esiste?
Ci sono prove di una richiesta di aggiunta di questa funzionalità risalente al 2013. Un intervento al Black Hat USA 2016 ha menzionato in generale diversi vettori di esecuzione di codice remoto con iniezione JNDI, ma non ha indicato direttamente Log4j.
Nel marzo 2021 è stato scoperto anche un codice proof-of-concept che prendeva di mira la debolezza della ricerca JNDI in Log4j 2.x.
Fear, Uncertainty, and Doubt (FUD) sono in abbondanza oggi e probabilmente persisteranno nelle prossime settimane e mesi. Sebbene adottare una mentalità di "violazione presunta" non sia rilevante per ogni vulnerabilità delle celebrità, la prevalenza e la dipendenza transitiva della libreria Log4j insieme alle sofisticate tecniche di exploit di offuscamento a cui stiamo assistendo in tempo reale sottolineano che la domanda che dovremmo porci non è "Da quanto tempo esiste?" Piuttosto, è "Da quanto tempo dovremmo prepararci mentalmente (e stabilire aspettative) per ripulirla?"
Stiamo aggiungendo altre domande man mano che ci arrivano. Se hai domande a cui vorresti una risposta, faccelo sapere.
Ho sentito che l'aggiornamento non funziona e che potresti comunque essere sfruttato anche se hai aggiornato. Dovrei farmi prendere dal panico?
Se hai aggiornato alla v2.15 (la correzione originale) o alla v2.16 (la correzione più recente), non devi farti prendere dal panico. È vero che l'aggiornamento alla v2.15 "era incompleto in alcune configurazioni non predefinite" e che è stato designato come vulnerabilità separata: CVE-2021-45046. Ma le parole chiave qui sono "in alcune configurazioni non predefinite".
In sostanza, quando una configurazione di registrazione utilizza un Pattern Layout non predefinito con Context Lookup, gli aggressori con controllo sui dati di input della Thread Context Map (MDC) possono creare dati di input dannosi utilizzando un pattern JNDI Lookup. Ciò può causare attacchi DoS e ora abbiamo scoperto che può anche causare perdite di informazioni e, in alcuni casi specifici, RCE. Ciò ha portato all'aggiornamento della vulnerabilità da un punteggio CVSS di 3,7 a 9,0 sul sito Web di Apache Foundation , ma l'RCE è attualmente segnalato solo per macOS e non è stato segnalato pubblicamente alcuno sfruttamento in-the-wild, quindi non è ancora il momento di farsi prendere dal panico. La conclusione è che è necessario aggiornare alla v2.17 il prima possibile, ma a meno che non si disponga di quelle configurazioni non predefinite, la v2.15 probabilmente è quella giusta.
Ho sentito che ora ci sono prove di attacchi ransomware contro questa vulnerabilità. Dovrei farmi prendere dal panico?
È vero che hanno iniziato ad apparire segnalazioni del gruppo ransomware Conti, che sfrutta CVE-2021-44228 (Log4Shell) per montare attacchi. Secondo un rapporto di AdvIntel, Conti sta testando lo sfruttamento prendendo di mira le istanze vulnerabili di Log4j2 in VMware vCenter "per il movimento laterale direttamente dalla rete compromessa, con conseguente accesso a vCenter che colpisce le reti delle vittime statunitensi ed europee dalle sessioni Cobalt Strike preesistenti". Sebbene non sia il momento di farsi prendere dal panico, ci aspettiamo di vedere uno sfruttamento basato su riscatto molto più diffuso nelle prossime settimane, e questo è un altro motivo per assicurarti di avere la versione più recente (v2.17) il prima possibile.
È corretto eseguire la scansione per individuare applicazioni o sistemi vulnerabili?
Se possiedi o noleggi sistemi e disponi delle autorizzazioni appropriate, è assolutamente corretto eseguire una scansione per identificare applicazioni o sistemi vulnerabili. Infatti, ti consigliamo vivamente di farlo nei tuoi ambienti in modo da poter applicare le patch.
Oltre a ciò, sebbene le leggi varino da Paese a Paese, la maggior parte delle leggi anti-hacking si basa sul divieto di superare l'accesso autorizzato o di accedere ai sistemi senza autorizzazione, quindi la scansione dei beni altrui senza permesso potrebbe violare la legge.
Ad esempio, come spiega in questo tweet il nostro esperto di politica pubblica statunitense Harley Geiger, in base alla legge statunitense anti-hacking, il Computer Fraud and Abuse Act (CFAA), "Se il test comporta l'esfiltrazione non autorizzata di dati non pubblici da un sistema di destinazione o fa sì che un sistema di destinazione scarichi il tuo codice eseguibile senza autorizzazione, anche se fatto in buona fede, fermati e fatti amico un avvocato".
Nessun commento:
Posta un commento