Domanda:
È necessaria una buona analogia: problemi di sicurezza dovuti a programmatori diversi che implementano le stesse funzionalità in modi diversi per la stessa app
SuperSpitter
2018-06-05 19:26:08 UTC
view on stackexchange narkive permalink

Devo fare una presentazione a scuola sulle vulnerabilità trovate nella piattaforma Moodle. Ovviamente, si applicano solo a una versione precedente che è stata patchata da allora.

Il problema è che la presentazione dovrebbe essere rivolta a un pubblico senza conoscenze tecniche. Quindi non sono autorizzato a spiegare nulla utilizzando il codice, ma dovrei fornire una spiegazione che aiuti il ​​pubblico a comprendere il problema anche se non ha alcuna comprensione tecnica.

I problemi di Moodle sono nati da diversi contributori che implementano il stessa funzionalità in modi diversi che hanno creato alcune falle nella sicurezza. Una delle vulnerabilità da sola non sarebbe stata sufficiente a causare danni considerevoli al sistema, ma è diventato possibile combinare exploit di false supposizioni, un'iniezione di oggetti, una doppia SQL injection e un RCE del dashboard di amministrazione permissivo.

I ho pensato di spiegarlo con una casa che era stata originariamente costruita in modo sicuro, ma poi è diventato insicuro a causa di alcune cose aggiuntive costruite su di essa, ma sto cercando qualcosa di un po 'più specifico o forse uno scenario storico del mondo reale che si adatti.

Ho pensato che forse potresti avere un'idea migliore.

Immagino che quello che ti chiederei è qual è l'idea generale che stai cercando di trasmettere?Sembra che ogni vulnerabilità di Moodle fosse abbastanza reale, ma difficile da sfruttare, a meno che non combinata insieme.Se questa è l'idea, guarderei alla sinergia come un'analogia.Come l'alcol e i farmaci ansiolitici, ad esempio.
@SteveSether no, erano piccole vulnerabilità che esponevano una vulnerabilità maggiore se usate in combinazione: "false supposizioni, un'iniezione di oggetti, una doppia iniezione di SQL e una dashboard di amministrazione permissiva"
potresti rivedere alcuni degli incidenti aerei che portano alla formazione CRM (gestione delle risorse della cabina di pilotaggio), perché ci sono molte situazioni in cui fare la cosa giusta, ma nel vuoto può essere problematico.
@dandavis Questo è esattamente quello che stavo pensando.A volte lasciamo la possibilità di SQLi perché siamo tutti troppo concentrati su una lampadina o qualcosa del genere.
Analogia: molto tempo fa ho parlato con qualcuno che era stato responsabile dell'effettivo processo di costruzione delle centrali nucleari.Con tutti i diversi subappaltatori che facevano le cose (parzialmente) a modo loro, ovviamente le cose sono andate storte.Si è ricordato di un incidente in cui l'appaltatore X ha costruito un tubo "passante / condotto" attraverso un muro di cemento nella posizione A, e l'appaltatore Y ha posato tubi che terminano in quel muro nella posizione B a due metri di distanza.Hanno "risolto" questo problema perforando la posizione del muro B. Cosa significava per la sicurezza del reattore?
Grazie a tutti per gli ottimi suggerimenti!Ho controllato la risposta di Tavian come quella giusta, perché userò quell'esempio nella mia presentazione per la sua semplicità.Naturalmente, con una domanda del genere non c'è una risposta vera ...
@JanDoggen Crea una risposta prima che un moderatore la elimini e dica "non fornire risposte come commenti" (e poi devi perdere tempo a riscriverla).
@Pharap Grazie, ma è stato molto tempo fa e non ho dati reali sull'incidente.Ecco perché ho lasciato solo un commento.
Suggerisco di cambiare il titolo in _... implementando le stesse funzionalità in modi diversi ** introducendo così diversi punti deboli ** ..._.Sebbene implementare le stesse funzionalità in modi diversi sia già abbastanza grave dal punto di vista della manutenzione e della qualità, aumenterà il rischio solo se alcuni o tutti questi sviluppatori introducono anche solo supposizioni / bug / cattive pratiche minori, che si combineranno inqualcosa di non così minore.Sappiamo che è quasi automatico che il nuovo codice abbia presupposti / bug errati, ecc., Ma un pubblico non tecnico potrebbe non darlo per scontato.
Diciannove risposte:
Tavian Barnes
2018-06-06 02:20:52 UTC
view on stackexchange narkive permalink

Ecco un'idea per un'analogia che ritengo sia abbastanza accurata, anche se generalmente comprensibile:

Una banca richiede due forme di carta d'identità per ottenere un prestito: una patente di guida e un certificato di nascita. I dipendenti della banca Alice e Bob sono pigri in modi diversi: Alice timbra sempre "patente di guida verificata" senza controllare, mentre Bob timbra sempre "certificato di nascita verificato" senza controllare.

Individualmente questo è male ma non troppo male - - chiunque presenti la domanda con documenti contraffatti verrebbe sorpreso dall'unico controllo che il dipendente ancora esegue. Ma un giorno Alice è in ritardo, timbra la "patente di guida verificata" su un modulo e lascia che Bob finisca. Bob vede il modulo, presume che Alice abbia effettivamente verificato la licenza e timbri "certificato di nascita verificato" senza controllare come fa sempre. Il prestito viene approvato, senza che nessuna delle due forme di identità sia stata controllata.

Un cattivo attore attento potrebbe fare in modo che Alice sia in ritardo.
Puoi renderlo più appropriato."Alice e Adam sono una squadra in banca, Alice controlla sempre le patenti di guida, Adam controlla sempre i certificati di nascita" "Bob e Barry sono un'altra squadra, Bob fa la patente, Barry fa i certificati di nascita" un giorno il manager riorganizza le squadre, lorosono così abituati a fare le cose a modo loro.Alice e Bob si accoppiano, Barry e Adam si accoppiano.Ora i loro sono difetti di sicurezza indipendentemente dal fatto che 2 persone controllino, perché hanno controllato due volte la stessa cosa!
@RyanTheLeach il problema non è controllare alcune cose due volte, ma controllare mai le cose.Il tuo scenario funziona, ma il motivo per la falla di sicurezza è disattivato.
Fatto divertente: Alice e Bob rallentano i loro compiti di elaborazione dei moduli perché stanno cercando di risolvere pazzi problemi di matematica per comunicazioni segrete.
C'era un [caso di vita reale] (https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/) come questo.Il reparto assistenza di Amazon ti ha consentito di aggiungere una carta di credito al tuo account se conoscevi il nome, l'e-mail e l'indirizzo di fatturazione dell'account.Nel frattempo, il processo di recupero dell'account di Amazon ha verificato il numero della tua carta di credito (che hai appena aggiunto).Se cercavi di acquistare qualcosa sulla carta della vittima spedita a un nuovo indirizzo, si fermava e ti chiedeva di verificare il "numero completo della carta che termina con 1234".Ottimo per Amazon, ma il processo di ripristino di Apple ha utilizzato le stesse ultime quattro cifre per verificare il tuo ID Apple ...
schroeder
2018-06-05 19:46:12 UTC
view on stackexchange narkive permalink

La situazione è: persone che lavorano in modo indipendente senza coordinamento, per progettare funzionalità pensate per essere utili a livello locale, ma quando combinate, hanno creato un disastro.

I primi riferimenti storici che vengono in mente:

Entrambi creare storie divertenti e immagini emozionanti.

La soluzione a entrambi era la supervisione centrale e la pianificazione centrale, che è la stessa soluzione per i fiaschi Open Source, come quella sperimentata da Moodle.

Sulla base della descrizione di ciò che è successo, non sono molto d'accordo con la tua valutazione.Sembra che ci siano 3 vulnerabilità che da sole sarebbero difficili da sfruttare, ma combinate portano a un grosso problema.Non vedo alcun motivo per cui questo abbia a che fare con OSS e sarebbe risolto con una pianificazione centralizzata.
@SteveSether Non capisco il tuo commento.Avere una linea ferroviaria o una compagnia antincendio è difficile da sfruttare.Avere multipli che utilizzano priorità diverse crea il problema.La soluzione è l'allineamento.I grandi progetti Open Source richiedono l'allineamento altrimenti si verificano problemi come questo (lo stesso nei grandi progetti closed source decentralizzati)
@schroeder Grazie, questi esempi sembrano interessanti.Sto già leggendo l'articolo di Wikipedia sulla storia delle ferrovie britanniche.Potresti specificare l'epoca in cui si è verificata quella situazione?
Accidenti, mi mancava che avesse già fornito i link.Grazie!
@schroeder Penso che l'esempio ferroviario sia scarso.Qui il sistema della metropolitana è completamente isolato dalle linee ferroviarie regolari e aumenta la sicurezza (è fisicamente impossibile per un treno della metropolitana fare una svolta sbagliata e salire sui binari regolari).Questo è importante: i treni della metropolitana bc non sono classificati per una collisione con un treno merci.
@emory l'esempio ferroviario ha a che fare con l'eventuale combinazione delle linee ferroviarie
@schroeder è un incubo di efficienza perché i tuoi treni non possono circolare sui miei binari e viceversa, ma è una buona sicurezza.Non mi preoccuperò così tanto se i tuoi treni sono all'altezza dei miei standard di sicurezza.Spetta a te se dotare i treni di freni o se gli operatori ferroviari possono bere durante il lavoro.(Ipoteticamente, il tuo Windoze viri non potrebbe infettare i miei sistemi Linux perché i due sono completamente non interoperabili.)
@schroeder Citi * il caos del sistema ferroviario britannico * come se fosse puramente storico.Per ragioni ideologiche, il sistema ferroviario britannico è stato privatizzato e nuovamente smantellato negli anni '90, con vari operatori che percorrevano varie tratte con numerose sovrapposizioni.A parte le dimensioni dei binari, *** tutti *** questi problemi sono esistiti sulle ferrovie britanniche sin dal momento della privatizzazione.Ancora peggio, i cambiamenti di orario hanno recentemente causato la cancellazione dei servizi in gran parte del paese, semplicemente perché non possono organizzarsi per avere i treni pronti per l'uso.
Queste sono entrambe buone analogie.Non sono sicuro del motivo per cui le persone si lasciano prendere dal fatto che le analogie non corrispondono PERFETTAMENTE a uno scenario di sicurezza.Sono analogie!Non è necessario che siano 1: 1 per la situazione spiegata!Uno dei miei obiettivi è l'educazione degli utenti finali e non esiterei a usare queste analogie per spiegare il problema dei "troppi cuochi".
Joe McMahon
2018-06-06 00:01:50 UTC
view on stackexchange narkive permalink

Ecco un esempio perfetto: la perdita del Mars Climate Orbiter. https://www.wired.com/2010/11/1110mars-climate-observer-report/

Per citare:

Un comitato di revisione della NASA ha scoperto che il problema era nel software che controlla i propulsori dell'orbiter. Il software ha calcolato la forza necessaria ai propulsori per esercitare in libbre di forza. Un software separato ha acquisito i dati supponendo che fossero nell'unità metrica: newton.

Ciò ha provocato un disaccordo di circa 4,5 volte la giusta quantità. Il satellite è entrato nell'atmosfera troppo in profondità e si è bruciato.

jayce
2018-06-06 18:45:00 UTC
view on stackexchange narkive permalink

Questo mi fa venire in mente il crollo della passerella dell'Hyatt Regency nel 1981. TL; DR l'architetto ha stipulato un progetto, un produttore su contratto ha sostituito il proprio progetto, ne derivano guasti meccanici (e fatalità). Si tratta di un caso di studio comune per studenti di ingegneria.

Fonte: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#Investigation

MODIFICA a fornire ulteriore chiarezza:

L'ingegnere del record ha attribuito il difetto fatale di progettazione a un'interruzione della comunicazione. Ha ... affidato la responsabilità al socio responsabile di ogni progetto.

L'ingegnere di registrazione ha inoltre affermato che era pratica comune nel settore per l'ingegnere strutturale lasciare la progettazione dell'acciaio collegamenti in acciaio al fabbricante ...

... i fabbricanti ... subappaltano il lavoro a un disegnatore esterno. Quel disegnatore, a sua volta, credeva erroneamente ... che i disegni dell'officina fossero già stati progettati e quindi non eseguì egli stesso calcoli sulla connessione.

... l'ingegnere del record ha apposto il suo sigillo sui documenti .. . [e] ... ha dichiarato di non aver controllato personalmente tutti i calcoli e di aver fatto affidamento sul lavoro del suo ingegnere di progetto e del team di progettazione.

Fonte: https: // www.asce.org/question-of-ethics-articles/jan-2007/

Nota che molte informazioni sono state sottratte per mantenere la citazione in blocco breve, ma con l'analisi completa hai davvero un'idea della tempesta perfetta di supposizioni e comunicazioni errate che dovevano allinearsi per realizzare completamente il guasto meccanico.

Personalmente mi piace questo.È sempre meglio usare esempi del mondo reale per ottenere punti nel mondo reale.
holmesmalone
2018-06-06 00:17:12 UTC
view on stackexchange narkive permalink

Penso che ciò che op sta descrivendo meglio corrisponda alla sicurezza del formaggio svizzero: https://en.wikipedia.org/wiki/Swiss_cheese_model

Il modello del formaggio svizzero della causa degli incidenti illustra che, sebbene molti livelli di difesa si trovino tra pericoli e incidenti, ci sono difetti in ogni livello che, se allineati, possono consentire il verificarsi dell'incidente.

Questo in realtà fornisce un eccellente * visuale * per andare con la risposta accettata.L'immagine principale nell'articolo wiki mostra come questo potrebbe applicarsi a molti livelli, invece che a due soli.
Machavity
2018-06-06 22:37:44 UTC
view on stackexchange narkive permalink

Una cosa che dovresti notare nel tuo discorso è che gli eventi catastrofici raramente hanno una sola causa. Invece, sono molto spesso una serie di fallimenti che si sono uniti per produrre disastri. Uno di questi disastri legati al software è stato il fallimento del Knight Capital Group. Sebbene ci siano stati diversi punti di errore che hanno contribuito, l'estremità del software si adatta a ciò che descrivi (enfasi mia)

L'aggiornamento a SMARS aveva lo scopo di sostituire il vecchio codice inutilizzato denominato "Power Peg" - funzionalità che Knight non utilizzava da 8 anni (perché il codice che era morto da 8 anni era ancora presente nel codice base è un mistero, ma non è questo il punto). Il codice che è stato aggiornato ha riproposto un vecchio flag utilizzato per attivare la funzionalità Power Peg. Il codice è stato accuratamente testato e ha dimostrato di funzionare correttamente e in modo affidabile. Cosa potrebbe andare storto?

A causa di un lancio fallito (sulla Borsa di New York), uno dei server aveva ancora il codice originale in esecuzione. Quindi indovina cosa succede quando riutilizzi il codice che originariamente doveva fare qualcos'altro completamente ...

È importante capire cosa avrebbe dovuto fare il codice Power Peg "morto". Questa funzionalità aveva lo scopo di contare le azioni acquistate / vendute rispetto a un ordine principale quando venivano eseguiti gli ordini secondari. Power Peg indicava al sistema di interrompere l'instradamento degli ordini figlio una volta che l'ordine principale era stato evaso.

Quando veniva attivato il flag Power Peg sull'ottavo server, la funzionalità Power Peg iniziava a instradare gli ordini figlio per l'esecuzione, ma non lo era non monitora la quantità di azioni rispetto all'ordine principale, un po 'come un ciclo infinito.

Immagina cosa accadrebbe se avessi un sistema in grado di inviare ordini automatici e ad alta velocità nel mercato senza alcun monitoraggio a vedere se sono stati eseguiti abbastanza ordini. Sì, era così brutto.

Nei primi 45 minuti il ​​mercato è stato aperto, il codice Power Peg ha ricevuto ed elaborato 212 ordini principali. Di conseguenza, SMARS ha inviato milioni di ordini per bambini sul mercato con conseguente 4 milioni di transazioni contro 154 azioni per oltre 397 milioni di azioni. Per voi drogati del mercato azionario questo significa che il Cavaliere ha assunto circa $ 3,5 miliardi di posizioni nette lunghe in 80 azioni e $ 3,15 miliardi di posizioni nette corte in 74 azioni. In parole povere, Knight Capital Group ha realizzato una perdita di $ 460 milioni in 45 minuti. Ricorda, Knight ha solo $ 365 milioni in contanti ed equivalenti. In 45 minuti Knight è passato dall'essere il più grande trader di azioni statunitensi e uno dei principali market maker del NYSE e del NASDAQ alla bancarotta.

Quindi il programmatore A ha scritto un funzione con un argomento per "Power Peg", e il programmatore B ha rimosso quel codice per fare in modo che lo stesso argomento stia per SMARS. Un'unica implementazione fallita e ... un disastro.

Steve Sether
2018-06-05 21:10:38 UTC
view on stackexchange narkive permalink

Sembra che quello che stai descrivendo sia "sinergismo". Tre agenti diversi che hanno solo effetti minori, ma se combinati sono più della somma delle loro parti.

https://en.wikipedia.org/wiki/Synergy

Se vuoi un'analogia, potresti considerare di combinare due farmaci come un barbiturico e una benzodiazepina (o credo, alcol). Questa è probabilmente la sinergia più nota che conosco.

L'articolo di wikipedia collegato contiene molti altri esempi che potrebbero rivelarsi utili.

Inoltre, penso che il concetto migliore sia "[emergenza] (https://en.wikipedia.org/wiki/Emergence)" perché gli effetti di ciascun agente sono, in combinazione, contrari.
@schroeder Emergence va bene, e ho pensato anche a questo.Non è così vicino poiché l'emergenza può coinvolgere la stessa entità che interagisce con se stessa, come una colonia di termiti o cristalli di ghiaccio.
taswyn
2018-06-07 01:25:56 UTC
view on stackexchange narkive permalink

La cattura del castello di Gaillard

Il castello Gaillard era considerato un castello veramente all'avanguardia, fortemente fortificato (è letteralmente nel suo nome, che si traduce approssimativamente come "castello forte"), commissionato e progettato originariamente dal re Riccardo d'Inghilterra. Un certo numero di fortificazioni più ampie oltre il castello furono utilizzate anche per cercare di impedire che l'esercito francese lo prendesse, che l'esercito a sua volta aggirò con vari mezzi, tra cui "semplicemente" riempiendo un fossato difensivo, creando un ponte di barche attraverso la Senna (con fortificazioni fluttuanti per aiutare a mantenere il viale di attacco persistente) e tunneling il muro esterno.

Tuttavia, alla fine, cadde dopo che tutte le altre misure difensive e le mura furono violate, a causa di un successiva scelta progettuale risultante in due diversi metodi impiegati per realizzare piercing nella seconda facciata continua: oltre al ponte retrattile e alla porta fortificata principale dal primo al secondo cortile, la cappella appena aggiunta del castello aveva finestre realizzate che perforavano il muro di quella corte a alto solo 3 metri.

Riccardo Cuor di Leone è stato acclamato per la sua conoscenza all'avanguardia dell'ingegneria dei castelli. Dopo la sua morte, però, suo fratello John Lackland fece costruire una grande cappella nel secondo cortile del castello e decretò che avrebbe dovuto avere finestre rivolte a sud. Presumibilmente a causa dell'altezza della facciata continua, le finestre sono state realizzate per perforare il muro stesso per portare la luce.

Idealmente, queste finestre rivolte a sud non sarebbero mai state un problema: erano troppo piccole per fornire un mezzo adeguato per prendere direttamente il castello con una forza maggiore. Ma dopo che il primo cortile esterno è caduto in ingegneria (tunnel / estrazione mineraria), l'esercito francese ha sfruttato le finestre della cappella per far entrare una piccola forza nel secondo cortile, abbastanza da prendere i cancelli dall'interno (alcune fonti sostengono di aver appiccato il fuoco alla cappella per creare confusione) e aprirli, lasciando entrare l'esercito principale dal primo cortile.

Archeologist Dominique Pitte's rendering of the castle design

Mentre il castello era un'impresa di ingegneria difensiva con una rivoluzionaria facciata continua con una serie di archi per deviare meglio e resistere a proiettili, fossi multipli e un progetto diviso che ha visto il primo cortile completamente isolato dal secondo e dal terzo cortile, il fatto che la cortina esterna del secondo cortile fosse forato entrambi per un ingresso ( tramite un ponte rimovibile dal primo cortile) e per la luce (le finestre della cappella) è diventato un difetto critico sfruttabile solo per la presenza di entrambe le aperture, create per scopi diversi e da progettisti diversi. Il terzo cortile cadde rapidamente perché era stato costruito con pareti più sottili (molto probabilmente come un angolo necessario da tagliare per soddisfare il programma di costruzione altamente accelerato, con l'ipotesi che i bailey esterni non sarebbero mai caduti entrambi).

Più punti di esposizione crei, anche quelli che sembrano benigni o di rischio controllabile in circostanze normali, maggiore è il potenziale che qualcosa che hai fatto consentirà di aggirare altre misure di sicurezza. Più aperture crei attraverso misure di sicurezza, anche aperture che sono dietro altre misure di sicurezza, più è probabile che qualcuno aggiri la tua sicurezza sul tuo cancello principale e trovi un modo diverso per entrare. Presumendo che sia sicuro tagliare gli angoli con la sicurezza su qualcosa che sta dietro ad altre misure di sicurezza significa che se quelle misure frontali falliscono o vengono aggirate, gli attaccanti avranno un momento facile per ottenere il loro obiettivo finale.

Difesa in profondità (spesso chiamata strategia del castello ) richiede di avvicinarsi al concetto di sicurezza dal punto di vista che ogni altra misura al di là di quella considerata possa essere sconfitta, piuttosto che fare affidamento su di esse non venendo meno e rafforzandosi con quella prospettiva.

I castelli possono e sono caduti semplicemente perché qualcuno è diventato pigro o ha commesso un errore riguardo alle misure di sicurezza che si trovavano dietro i muri esterni e ha fornito involontariamente una superficie di attacco secondaria meno sicura di quella principale (i cancelli principali) per un dato anello (muro) di sicurezza. Più buchi metti in un muro, più è probabile che qualcuno commetta un errore sul modo in cui quei buchi sono chiusi e più è probabile che venga trascurato. Le persone fanno errori. Più luoghi devi cercare per un errore, più è probabile che uno venga perso. Un utente malintenzionato dedicato sonderà ogni via di attacco messa a loro disposizione, anche quelle che non conosci di te stesso o quelle che non hai concepito come vulnerabilità.

Anche se c'è una resa di la storia completa dell'assedio su wikipedia, in modo impreciso (apparentemente in modo apocrifo, poiché è un riferimento comune, sebbene alcune fonti apparentemente affermino che potrebbe essere stata deliberata disinformazione da parte dei francesi a evitare di ammettere di aver dissacrato una cappella) si riferisce alla violazione del secondo cortile come dovuta a uno scivolo del gabinetto. La cronologia effettiva è disponibile su Histoire Normandie in francese, a cui questa risposta fa molto riferimento ora.

Questa è una bella storia ma non parla molto di coordinazione (tra chi ha fatto o progettato quello scivolo e chi ha fatto il resto).
@Nemo È del tutto corretto, e ** sono ** * anche * abbastanza curioso delle specifiche che cercherò di vedere se non riesco a trovare informazioni correlate.In effetti, tuttavia, proprio come il software, è facile raccontarlo come una storia di due diversi metodi per avere un buco in un muro, in cui la sicurezza di uno era evitabile dagli aggressori a causa della differenza di implementazione.Più buchi, in particolare di costruzione diversa, metti in un muro, maggiori sono le possibilità che gli aggressori trovino una vulnerabilità critica in uno di essi e più cose devi tenere a mente / monitorare / controllare
questo è un buon punto, che potrebbe rendere più facile per l'OP usare questa storia come analogia.
@Nemo bene dopo ulteriori letture, ho scoperto che la storia di cui ho sempre sentito parlare è in realtà presunta inesatta dagli storici, e la vera storia non solo diventa più interessante come lezione di sicurezza, ma coinvolge anche due diversi designer (Richard per l'originaledesign, la cappella di John è l'aggiunta di design che ha permesso la vulnerabilità a cascata).Potrei tornare indietro e modificarlo di nuovo per chiarezza o semplicemente riscriverlo interamente, poiché la modifica retroattiva nella versione più recente non si legge in modo pulito in alcune parti, ma penso che ora si adatti ancora meglio (non perfettamente, ma certamente concettualmente)
Puoi correggere la pagina di wikipedia con i link ai tuoi riferimenti?
Emory Bell
2018-06-09 08:28:51 UTC
view on stackexchange narkive permalink

Ecco una semplice analogia che si applica nel mondo reale e dovrebbe essere facile da capire per gli studenti di qualsiasi livello tecnologico. Come bonus, può funzionare anche per gli studenti delle scuole medie e superiori.

Esistono due tipi prevalenti di lucchetti per biciclette:

Corde / Catene

Cord lock

e

U-Lock

Ognuna di queste serrature può essere sconfitta utilizzando un semplice strumento.

  • Una corda o una catena possono essere tagliate con cesoie per cavi di servizio.
  • Un lucchetto a U può essere aperto con un piede di porco.

Tuttavia, poiché le cesoie e i palanchini sono entrambi oggetti ingombranti, i ladri di biciclette generalmente portane uno alla volta. Quindi, se hai un lucchetto con cavo, sei protetto dai ladri con i piedi di porco e se hai un lucchetto a U, sei protetto dai ladri con le forbici.

Ma come puoi proteggerti da tutti e due? Bloccando la bicicletta utilizzando sia un cavo che un lucchetto a U! In questo modo, i ladri devono portare entrambi gli strumenti per poter rubare la tua bicicletta.

Tuttavia, questo funziona solo per la sicurezza se sia il cavo che il lucchetto a U sono attaccati separatamente alla bicicletta .

Nel caso di Moodle, il cavo e il lucchetto a U sono attaccati l'uno all'altro (con uno che gira intorno alla bici e uno intorno all'oggetto a cui lo stai attaccando) , il che significa che il ladro deve solo essere in grado di romperne uno per rubare la tua bici! Quindi, invece di raddoppiare la tua sicurezza portando due lucchetti diversi, hai dimezzata la tua sicurezza, dal momento che il ladro deve sfondarne solo uno per raggiungere la tua bicicletta.

Nella crack di moodle, dovevi sfruttare tutti e 3, uno per passare l'exploit a un altro.
dwizum
2018-06-06 01:21:16 UTC
view on stackexchange narkive permalink

Hai appena acquistato una vecchia casa. È stato modificato nel tempo da molte persone diverse.

Hai una cassaforte nel seminterrato. Ci sono due porte che devi attraversare per arrivare al seminterrato. Volevi che la cassaforte fosse più sicura, quindi quando hai acquistato la casa, eri sicuro di aggiungere un'altra porta tra essa e il mondo esterno, quindi ora ci sono tre porte! Suona abbastanza bene.

Sfortunatamente, la porta è stata prodotta da un'azienda a basso budget che non seguiva alcun tipo di standard e che non era ritenuta responsabile della realizzazione di porte sicure. Sei appena andato dal fornitore locale di edifici e hai comprato la porta. Ancora peggio, le altre due porte sono state scelte in modo simile, a caso, non secondo un progetto più grande.

Sfortunatamente, ci sono modi facilmente disponibili in cui uno qualsiasi dei tre stili di porta può essere violato. Quindi, anche se ci sono tre porte, è banale per un ladro esperto arrivare alla tua cassaforte e rubare i tuoi oggetti di valore. Certo, viene evitato un furto casuale di opportunità: il ragazzaccio del vicinato non riuscirà a scappare con le tue ricchezze, ma il ladro determinato lo troverà facile.

Paragonalo al tuo vicino, che non solo ha utilizzato porte di qualità migliore, ma ha assunto un appaltatore per costruire la sua casa, un imprenditore che conosce la sicurezza domestica. Quell'appaltatore sapeva come selezionare porte difficili da sconfiggere o, persino, porte per le quali non esisteva alcun metodo di sconfitta noto. Sapeva come coordinarsi tra i diversi subappaltatori che consegnavano e installavano le porte. Sapeva come controllare che le porte fossero costruite correttamente. A causa di questa supervisione e coordinamento, la cassaforte del tuo vicino non sarà saccheggiata facilmente come la tua.

Artelius
2018-06-06 10:51:49 UTC
view on stackexchange narkive permalink

Ecco un'analogia ispirata al cavallo di Troia.

Sulla scia del cavallo originale, la città ha cercato di indurirsi contro quel tipo di attacco. Ma all'interno della città, i veicoli di grandi dimensioni devono spostarsi per consegnare le merci. Quindi:

Passaggio 1: porta di nascosto i pezzi del nuovo "Cavallo" (forse è una mucca questa volta per essere meno sospettosi) in città. Uno alla volta i pezzi di legno non rappresentano una minaccia, quindi non vengono messi in discussione. Tuttavia, a questo punto non puoi introdurre armi di nascosto.

Passaggio 2: in città c'è un artigiano che costruisce veicoli in legno. Se i pezzi si presentano nel suo cortile, li assemblerà. Successivamente una persona può nascondersi all'interno della mucca.

Passaggio 3: il giorno della festa la mucca viene portata in giro per la città insieme ad altri spettacoli. Con tutti ubriachi, nessuno noterà l'occupante della mucca arrampicarsi su di esso e saltare da lì sulle mura della città.

Passaggio 4: normalmente devi scalare la città mura attraverso un corpo di guardia, e solo le guardie sarebbero state autorizzate a passare. Quindi, quando la persona si presenta al cancello e dice al guardiano che il suo turno è finito, il guardiano gli crede (vuole comunque unirsi alla baldoria). Ora con un gatekeeper compromesso puoi tenere la porta della città spalancata e far entrare un esercito.

Per affrontare in modo specifico il problema dei "programmatori diversi che implementano la stessa funzione in modi diversi", considera che ci sono due modi per portare oggetti in città. Uno è oggetti piccoli con poco controllo, l'altro è oggetti grandi con molto controllo. Il problema è che nessuno pensava che piccoli oggetti venissero portati in città e poi assemblati in un oggetto più grande una volta arrivati.

Questo mi ha lasciato un po 'confuso.In che modo l'occupante della mucca entra in città in modo da poter partecipare ai passaggi 2 e 3?Dopotutto, portare il nemico in città era l'obiettivo del cavallo originale.Poiché il difetto di sicurezza è solo una disattenzione piuttosto aspecifica di varie persone in vari punti, sembra che l'intera parte sul contrabbando in parti per costruire una mucca sia lì solo per giustificare il collegamento di questa storia al cavallo di Troia.
JimmyJames
2018-06-06 01:14:32 UTC
view on stackexchange narkive permalink

Non sono sicuro che questo si adatti perfettamente e potrebbe essere troppo oscuro per il pubblico, ma una cosa che mi è venuta in mente sono stati i fallimenti dell'intelligence sull'attacco dei 911 dovuti al fatto che diverse agenzie non comunicavano o condividevano informazioni.

Kafein
2018-06-06 15:31:39 UTC
view on stackexchange narkive permalink

A me sembra che qualcuno abbia scritto "unserialize" nel proprio programma senza pensare molto alle implicazioni. Non c'era niente di sbagliato nella prima versione.

Forse il problema più profondo di progettazione e metodologia era che il contratto di quella parte che era stata reimplementata non era documentato e testato bene.

Penso che probabilmente sia più divertente per un pubblico noob (o qualsiasi pubblico in realtà) sbirciare le cose divertenti che tendono ad accadere quando qualcuno usa la serializzazione senza la massima cura. Soprattutto in un linguaggio interpretato o molto dinamico. Ovviamente per far funzionare quella presentazione è necessario spiegare un po 'di cose tecniche, ma questo è il prezzo di un pubblico sveglio.

arp
2018-06-08 06:52:27 UTC
view on stackexchange narkive permalink

Per un pubblico non tecnico:

Hai tre porte, ciascuna collegata a un sistema di allarme centrale.

Il manuale di sicurezza per la porta 1 dice:

se l'allarme suona:

  1. Spegni l'allarme
  2. Prova la porta
  3. Risolvi eventuali problemi rilevati
  4. Contatta la direzione dell'edificio se non è stato possibile risolverli.

Il il manuale di sicurezza per la porta 2 dice:

se l'allarme suona:

  1. Attendi 30 secondi per vedere se l'allarme si ripristina da solo
  2. Se l'allarme continua

    • prova la porta
    • Risolvi eventuali problemi rilevati
    • Contatta la direzione dell'edificio in caso di problemi non può essere risolto.

Il manuale di sicurezza per la porta 3 dice:

se l'allarme suona:

  1. Attendi 30 secondi per vedere se l'allarme si ripristina.
  2. Se l'allarme continua a suonare
    • prova la porta
    • risolvi eventuali problemi rilevati
  3. Contatta l'edificio gestione per far loro sapere cosa è successo.

Ora sei in una posizione in cui una guardia di sicurezza può disattivare un allarme prima che l'altra si accorga che c'è un problema che deve risolvere.

La direzione riceve alcune notifiche di problemi e falsi allarmi e non si rende conto che altri allarmi vengono ignorati.

Ruadhan2300
2018-06-08 14:31:05 UTC
view on stackexchange narkive permalink

Senza approfondire troppo l'articolo collegato. questo sembra un problema in cui i presupposti sottostanti non erano comuni tra le persone che ci lavorano.

Essenzialmente, il sistema è stato originariamente impostato per avere un elenco di "cose ​​che gli utenti possono fare" che tu può chiedere. Questi sono chiaramente definiti e dal momento che devi solo dire al sistema di eseguirli e sono di per sé sicuri, nessun problema, includi la tua password di sicurezza come autenticazione.

Il problema è emerso quando uno sviluppatore successivo aggiunta la possibilità di aggiornare i dati del tuo account, inclusi i tuoi privilegi di sicurezza. Significa che puoi usare questo nuovo sistema per avviare efficacemente i tuoi privilegi se sai cosa chiedere, perché il sistema per l'impostazione dei dati non è molto sicuro, questo era il punto di avere un approccio "Chiedi, non ordina" nel primo posto.

In sostanza, normalmente chiedi al sistema di fare le cose per te ed è autorizzato a dirti "No" se non hai autorità.

Ma un aggiornamento successivo da qualcuno che non ha pensato al perché è stato impostato in questo modo ha aggiunto la possibilità di chiedere al sistema di aumentare i tuoi privilegi in un modo che non può effettivamente rifiutare.

Immagina di voler andare a una festa privata, ma non sei nella lista degli invitati. L'addetto alla sicurezza non ti farà entrare. Ma se dici all'organizzatore che sei invitato, ti inseriranno nell'elenco senza metterlo in discussione.

AndyB
2018-06-08 16:37:12 UTC
view on stackexchange narkive permalink

Se hai la stessa porta installata esattamente allo stesso modo dallo stesso falegname su tutti gli ingressi di un edificio, devi solo testarne una a fondo (prova a buttarla giù, prova a forzare la serratura, ecc.) e poi tu può semplicemente dare una rapida occhiata agli altri per essere sicuro che siano uguali. Se hai un gruppo di falegnami e alcuni usano porte diverse, devi testarle tutte a fondo.

@JoshuaJones Non sto scherzando: la domanda era "È necessaria una buona analogia ..." quindi le risposte sarebbero analogie, non ho spiegato come si applica - è questa la tua lamentela?Se è una buona analogia, non devi spiegare come si applica.Buone analogie sono anche brevi IMO.Penso che le lunghe spiegazioni con i diagrammi confonderebbero ulteriormente il pubblico.
@JoshuaJones - L'OP sarà corretto.se richiede una spiegazione, è una cattiva analogia.
Neil
2018-06-08 19:56:15 UTC
view on stackexchange narkive permalink

Che ne dici di Apollo 13? Gli scrubber ad anidride carbonica per il modulo di comando e il lander lunare sono stati creati da diverse società. Uno era quadrato, uno era rotondo.

Guarda il documentario con Tom Hanks per maggiori dettagli :-)

Damon
2018-06-11 14:49:16 UTC
view on stackexchange narkive permalink

MTBF, o "fallimenti" nel senso 6σ

Sebbene queste siano cose completamente diverse, condividono alcune proprietà comuni che si applicano al tuo problema.

La Media Il tempo tra i guasti è una misura comunemente usata per valutare l'affidabilità delle cose. Se, ad esempio, acquisti qualcosa come un'auto o un disco rigido, quella particolare cosa potrebbe funzionare senza problemi fino al giorno in cui morirai. Ma in media, alla fine incontrerà un fallimento, dopo un tempo medio X. Questo è l'MTBF.

Six Sigma (6σ) è fondamentalmente lo stesso tipo di cose, tranne che per la maggior parte non trattate con le cose ma con i processi, e analizzi (e ottimizzi) non il tempo operativo, ma il numero di "opportunità", che possono essere ... qualunque, e gli insuccessi, che possono, ancora, essere ... qualunque. Può trattarsi di produrre qualcosa, consegnare in tempo o semplicemente rispondere a un telefono correttamente.

In un esempio più concreto, se ad es. il tuo calzaturificio produce un milione di scarpe da ginnastica al mese, stai cercando di ottenere che non più di 3 di esse (idealmente zero) escano con il colore sbagliato o senza lacci e non possono essere vendute.

Come fa che si applica qui?

L'MTBF ha un'implicazione ben nota, va giù proporzionalmente al numero di unità utilizzate che aumenta . Ciò significa che sebbene sia molto improbabile che il tuo cellulare esploda in tasca durante due o tre anni di utilizzo tipico, è praticamente garantito che accada a qualcuno se dieci milioni di persone ne possiedono uno (quello era il motivo per esempio della famigerata campagna di richiamo di Samsung / incubo di pubbliche relazioni circa un anno fa - non è come se fossi davvero in pericolo se ne possedessi uno).

Allo stesso modo, guardandolo dall'angolo 6σ, se il tuo fabbrica di scarpe produce non solo un milione di scarpe da ginnastica, ma un miliardo, quindi avrai 3.000 paia di scarpe difettose, non 3.

Alcuni anni fa, l'uso di RAID-5 è stato scoraggiato. In che modo fornisce una maggiore sicurezza dei dati, non è vero? Accade così che gli hard disk abbiano una possibilità molto, molto piccola di danneggiare un settore, quindi è irrecuperabile. Non succede mai ... beh, quasi .
Ma se i tuoi dischi sono abbastanza grandi (come i dischi moderni), con molti settori, e ne hai molti raggruppati insieme, sei fondamentalmente garantito che accada durante un'operazione di risincronizzazione, cioè nel momento preciso in cui non è necessario che ciò accada perché sei già inattivo un disco. Inoltre, hai la possibilità che un secondo disco si guasti catastroficamente a metà della risincronizzazione. Il che non succede mai ... beh, quasi . Più dischi sono presenti, più è probabile che accada.

Lo stesso vale per reimplementare la stessa funzionalità in un software molte volte. Ogni implementazione ( ogni funzione, non solo quelle che duplicano la funzionalità) è una "opportunità", o l'equivalente di un disco rigido. Più funzioni, tramite la funzionalità di duplicazione, significano più opportunità di fallimento. Inoltre, più codice da rivedere.

Sebbene i tuoi programmatori lavorino per lo più senza errori (beh, si spera), c'è sempre una piccola possibilità che facciano una falsa supposizione o un vero e proprio errore. Maggiore è il numero di opportunità offerte, maggiore è la probabilità che accada.

Ruadhan2300
2018-06-11 18:58:43 UTC
view on stackexchange narkive permalink

Una risposta alternativa al mio originale, dopo aver letto l'argomento e avere avuto più tempo per pensarci.

Immagina un'azienda con molti uffici isolati. Ogni dipartimento fa sempre esattamente ciò che gli viene detto fare tramite lettere-modulo.

Per garantire che le lettere non vengano inviate in modo malizioso, devi inserire una password nella carta intestata. Il dipartimento chiederà a un ufficio centrale nel seminterrato se la password ricevuta è permesso di dire loro cosa fare.
se è vero, si seguono le istruzioni, altrimenti la lettera viene buttata.

L'ufficio centrale gestisce anche tutti i dati del personale dell'azienda, l'ufficio centrale non ha un proprio indirizzo di posta per motivi di sicurezza, richiedendo che eventuali modifiche vengano apportate di persona.

Un giorno, la direzione si stanca di dover scendere nel seminterrato per aggiornare i dati dei dipendenti e semplicemente ha fornito all'ufficio centrale il proprio indirizzo postale e il proprio modulo di lettere. Ciò consente loro di apportare facilmente modifiche dal proprio ufficio.

Non sono stupidi, si sono assicurati che le lettere del modulo dell'ufficio centrale non includessero nulla sulla modifica delle password.

La stranezza è che tutti i moduli vengono convalidati in un sistema comune cercando una carta intestata particolare.

Quindi, quando un individuo intraprendente crea un nuovo modulo che corrisponde alle linee guida dell'azienda ma include un campo di modifica della password, il l'ufficio accetta volentieri e apporta le modifiche.

All'improvviso quella persona può modificare le proprie autorizzazioni per consentire loro di inviare lettere valide ovunque nell'azienda e ottenere il pieno controllo del sistema.


Direi che questa è un'analogia piuttosto solida sia per il sistema che per ciò che gli è accaduto nell'esempio di Moodle.

Sostituisci lettere per Ajax e SQL injection per la versione modificata della lettera modulo con il campo password.



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...