Cheating o interruzione del servizio alterando il codice lato client

JavaSnoop è uno strumento per sfruttare vulnerabilità come CWE-602: applicazione sul lato client della sicurezza lato server . Non ci si può fidare nemmeno dei client spessi, e se un sistema distribuito espone le funzioni sensibili a thick client, allora questa è una vulnerabilità . Non ha senso difendersi da "JavaSnoop" o persino "Firebug" o "burp", questi sono solo strumenti. Il sistema nel suo insieme deve essere preso in considerazione e un server deve essere sottoposto a controllo per vulnerabilità sfruttabili a distanza che sono accessibili con ogni mezzo.

Il processo per enumerare questi tipi di vulnerabilità non è diverso da qualsiasi altra vulnerabilità. Un team di valutazione, o tester di penetrazione, esaminerà le funzionalità esposte e testerà questa funzionalità per le vulnerabilità comuni come SQL Injection o problemi relativi ai limiti di affidabilità.

Andiamo più specifici sul tuo esempio e dì che questo è un gioco di poker online. Il server contiene dati che rappresentano il centro del tavolo (incluso il piatto, il mazzo a faccia in giù e la "comunità" di carte), ma il software client controlla il loro "angolo" del tavolo (la scorta del giocatore, la sua mano, e le loro decisioni).

L'assunto è che il software client è lo stesso software rilasciato dall'autore del gioco, senza modifiche di alcun tipo, e quindi il software client è stato reso responsabile di tracciare accuratamente il proprio bankroll e la propria mano; il server "distribuisce" le carte al cliente e, proprio come farebbe il vero casinò, "dimentica" (o non sa mai) quale carta è stata distribuita.

Questa non è un'ipotesi sicura; qualcuno che può manipolare il programma client, o anche solo i messaggi inviati da e verso di esso, può scegliere la propria mano modificando i messaggi sulle carte che il server ha inviato e può similmente moltiplicare le proprie vincite (o addirittura ignorare le perdite girando "tu perdi" in "hai vinto $ 1000").

La soluzione non è lasciare che il software client abbia qualcosa che si avvicina a questo livello di controllo. Il modello da seguire è quello di un "terminale stupido"; tratta il software client come nient'altro che un cavo lungo veramente che connette la tastiera e il monitor al computer server. Il client non sa nient'altro che ciò che viene detto dal server e non fa altro che inoltrare l'input dell'utente al server e viceversa. Non ha una "logica di business", ma mostra il gioco all'utente.

Dato un modello del genere, manipolare le comunicazioni non fa bene l'aggressore; le comunicazioni dal server e i numeri e le carte sullo schermo possono essere modificate nel contenuto del cuore dell'attaccante, ma qualsiasi azione basata sui dati errati del client viene riportata alla realtà con un tonfo da parte del server. Il cliente non può dire "I raise 50 grand"; il server risponderà semplicemente "hai solo $ 20 nel tuo stack, riprova". Il cliente non può dire "Sono Bob e chiamo"; il server, vedendo che la richiesta è arrivata su una sessione sicura appartenente a Bill, dirà "No, tu sei Bill, siediti e stai zitto finché Bob non avrà effettivamente preso il suo turno". Anche gli attacchi di riproduzione, in cui un client può ascoltare la conversazione sicura tra un altro client e il server e ripetere la comunicazione per eseguire qualsiasi comando in esso contenuto, vengono rilevati e ignorati molto facilmente. Dato abbastanza di queste comunicazioni harebrained, il server potrebbe alla fine dire "Stai perdendo il mio tempo, addio" e cacciare il cliente fuori dal gioco.

Il lato negativo, come accennato, è la latenza. La strategia nell'ideale funziona per un gioco di poker, in cui tutti agiscono a turno e quindi c'è ancora molta attesa, ed è banale che il server tenga traccia di tutto ciò che accade in una volta. Non funziona così bene per un FPS o RTS, dove l'interazione tra tutti i giocatori deve essere in tempo reale o maledettamente vicina, e c'è un lotto di calcolo di proiettili e corpi che si muovono, volano, scontrano, ecc. Causa problemi quando la latenza è superiore a qualche millisecondo (indipendentemente dalla velocità dei dati); se tutti hanno un ping di 150 ms su un server di gioco, tutti vedono dove tutti gli erano 300ms fa (almeno) e se qualcuno preme il grilletto quando la testa dell'avversario è nel mirino, il server pensa che Stai girando dove la persona era in realtà fino a mezzo secondo fa e dice "ti sei perso". Ciò richiede "lag leading" dai giocatori, che sparano davanti ai loro obiettivi di una distanza in base alla loro latenza combinata, anche quando la fisica del gioco impone che il viaggio dei proiettili sia istantaneo.

Per compensare questo, il server rinuncia necessariamente al controllo, e lascia che i clienti dicano "Ho sparato a Bob in testa" quando il giocatore preme il grilletto mentre la testa di Bob appare nel mirino sul loro schermo. Ma un giocatore con una mod di gioco che può "ignorare" in modo strategico i dati in arrivo sulle posizioni degli altri giocatori può manipolare questa quantità di fiducia del cliente per eseguire l'hack "fermo immagine"; spegni i datagrammi in arrivo e tutti gli altri si bloccano sul posto, consentendo al malintenzionato un colpo di testa facile e facile. Se il server crede alla richiesta del cliente, perché nessun altro ha affermato di aver sparato a quel ragazzo per primo, l'altro è morto anche se il suo cliente lo mostra al sicuro fuori dalla linea di fuoco.

Per questo genere di cose, non c'è davvero una risposta migliore; ovunque tu posizioni il controllo sulle decisioni di tipo "arbitro" che cambiano il gioco, i giocatori accusano gli altri di barare perché hanno svuotato una clip al ragazzo a distanza ravvicinata e il server dice di aver colpito l'aria, o perché il server ha detto " Bill è morto, Bob gli ha sparato "due secondi interi dopo che Bill aveva pensato di aver eliminato la linea di fuoco di Bob dietro un ostacolo.

Per quanto posso vedere, stai evidenziando un problema perenne nel gioco online: fidarti del cliente. Per riassumere brutalmente anni di ricerca ed esperienza:

• Tu, l'operatore del server, non puoi controllare l'utente, il suo computer, la loro rete o cosa scelgono di fare con il tuo software client.
• Pertanto, non puoi nascondere le tue comunicazioni o le risposte del cliente all'input.
• Quindi devi presumere che a un certo punto qualcuno capirà come spoofare l'input dell'utente in qualche modo
• Pertanto, è necessario convalidare tutto sul server.

Quando dico convalidare tutto, intendo tutto . Hai dato l'esempio di un gioco sparatutto, in cui un utente malintenzionato potrebbe aggiungere altri proiettili. Il server dovrebbe sapere quale pistola ha il giocatore, quanto velocemente può sparare, quanti colpi può sparare prima di ricaricarsi, ecc. Dato che, e il momento in cui l'utente ha premuto il pulsante di fuoco, il server può dire quanti proiettili ci sono dovrebbe essere. Il cliente non controlla i proiettili; dice al server che il giocatore sta sparando e il server genera proiettili. Il client è libero di simulare i proiettili partendo dal presupposto che il server lo farà, ma quando si tratta di esso, in caso di disaccordo è la versione del server delle cose che sta in piedi.

La lezione generale è che il cliente non determina mai i risultati di qualcosa; informa semplicemente il server delle azioni dell'utente e visualizza i risultati restituiti dal server. Se c'è una decisione che influisce su come vanno le cose, il server prende questa decisione. Questo arriva alle basi - il cliente non dice "la pistola sta sparando", dice "il grilletto viene tirato". Il client potrebbe avere un ritardo durante il ricaricamento, ma un client dannoso può ignorarlo e inviare immediatamente il messaggio di "attivazione". Il tuo server non dovrebbe consentire questo.

• L'utente fa un input
• Il client invia l'input al server
• Il client mostra il risultato assunto dell'azione

Nel frattempo, il messaggio raggiunge il server ...

• Il server convalida questo input - controlla i limiti su quante volte e con quale frequenza questa azione può essere eseguita, e se può essere eseguita nella situazione attuale.
• Il server attiva l'azione
• Server determina il risultato dell'azione
• Server informa il cliente dell'esito

Quando il messaggio ritorna al client ...

• Il cliente scarta qualunque risultato presunto stia funzionando con
• Il client visualizza l'esito del server

Questo è il motivo per cui vedi il lag causando strani effetti - ad esempio, quando ti sembra di teletrasportarti, è perché il client ha ricevuto il comando "walk forward" e ha mostrato il risultato ipotizzato che avanzi un po '. Il server non ha ricevuto il comando, quindi dice al client "no, sei qui" e poiché il server ha sempre ragione, il client deve obbedire e ti trovi improvvisamente da qualche altra parte. Generalmente, tuttavia, il server e il client sono d'accordo, quindi questa simulazione di scontato presupposto da parte del client consente al gioco di funzionare senza intoppi; ad esempio, potresti eseguire il gioco a 80 frame al secondo quando gli aggiornamenti dal server arrivano solo 30 volte al secondo. Per quei due fotogrammi tra gli aggiornamenti, le ipotesi del cliente sono abbastanza vicine che il giocatore non noterà la differenza.

La fase di convalida in quel processo è dove prendi gli imbroglioni. Chiunque invii ripetutamente comandi che non dovrebbero essere consentiti è probabilmente che cerca di imbrogliare. È possibile che abbiano una connessione veramente terribile e che il server stia semplicemente ricevendo le cose fuori ordine, o con dei bit mancanti, ma ci sono dei modi per determinarlo (il TCP lo fa subito, ma i giochi spesso usano UDP perché TCP può essere più lento, quindi potresti dover implementare questa roba da solo).

La soluzione corretta dipenderà dall'applicazione: il modo in cui previ l'uso improprio dipende da cosa significa cattivo uso nel tuo contesto.

Ma in senso generale, la soluzione al comportamento scorretto sul lato client è la convalida lato server. Questo può significare molte cose, quindi lasciatemi dare alcuni esempi:

• Con le app Web, la convalida tramite Javascript non è considerata una vera misura di sicurezza; qualsiasi controllo di sicurezza eseguito sul lato client deve essere eseguito di nuovo dopo che la risposta è stata inviata.

• Anche in questo caso con le app Web, non si assume che il proprio input verrà prodotto da un browser ben funzionante. Ad esempio, un browser non invierà un URL contenente /../ , ma lo filtri comunque.

• Con giochi FPS online come Team Fortress et.al, il server osserva attentamente le metriche come la velocità con cui il giocatore si muove, quanto in alto saltano, con quale precisione mirano, e così via per individuare un comportamento che non essere prodotto da un client che si comporta correttamente.

È assolutamente, completamente e altrimenti del tutto impossibile garantire che il client all'altra estremità della linea sia il software, configurato correttamente, non modificato e privo di altre forme di manomissione.

Devi assolutamente convalidare sul lato server tutto ciò che è importante. Puoi essere sicuro, non è in discussione. Puoi prevenire molti tipi di imbrogli. Ma non lo fai assicurando che il cliente non sia modificato. Invece, devi proteggere il server.

JavaSnoop può essere visto come un "debugger per applet". Permette a un utente di manipolare il codice (Java) che gira su la sua macchina, all'interno del suo browser. La possibilità di farlo è sempre stata conosciuta; JavaSnoop è solo uno strumento che lo rende un po 'più semplice.

Il problema generico è ciò che @Rook fa notare: il codice che viene eseguito sulla macchina della persona malintenzionata non può essere considerato attendibile. Questa è la sua macchina, può far sì che faccia ciò che vuole. Pertanto, le applicazioni che si basano sul codice che esegue sul sistema dell'utente per applicare le proprietà di sicurezza contro l'utente non possono essere alla fine robuste. Al massimo, offuscamento del codice può rallentare un po 'l'aggressore (diciamo, poche ore o giorni ) e possono esserci alcune attenuazioni che tenteranno di eliminare alcuni attaccanti a bassa potenza.

Nel contesto dei giochi online, in cui le regole applicate dal client sono molto comuni (poiché l'applicazione sul lato server comporterebbe una latenza intollerabile, o altri motivi tecnici simili), sfrattare il 90% degli imbroglioni è già un guadagno netto, e i venditori e gli operatori di giochi sono già abituati all'idea che non potranno mai sradicare la truffa; possono solo sperare di mantenere l'attività del cheat a livelli tollerabili. Lo stesso non si può dire di ogni altro contesto.

Come spiegato sopra, l'intero punto è che il codice gira sulla macchina dell'attaccante (cioè l'utente, visto come il potenziale aggressore). Questo indica una soluzione "semplice": lasciare che la macchina non sia più la macchina dell'attaccante. Questo è ciò che fanno le console di gioco: la console esegue un sistema operativo firmato dal fornitore della console e non accetterà l'aggiornamento o l'avvio a una versione del sistema operativo non firmata. Il sistema operativo rifiuterà anche di eseguire applicazioni non firmate. Anche se una console di gioco è davvero un computer, la possibilità di eseguire il codice fornito dall'utente è chiusa.

Ovviamente, qualsiasi singolo buco di sicurezza nel sistema operativo o in una "applicazione attendibile" (un gioco) può essere sfruttato per bypassare queste protezioni. Questo è stato fatto più volte. Per la console PS3, c'era il "PS Jailbreak", un dongle USB che sfrutta un bug nel modo in cui il sistema operativo gestisce le informazioni dai dispositivi USB. Poi c'era un sistema operativo falso che era stato firmato perché Sony non ha completamente utilizzato correttamente le firme ECDSA e ha rivelato la propria chiave privata nel processo. Si noti, tuttavia, che Sony, il fornitore di console, ha ancora una potente leva per impostare le cose "giuste" (dal loro punto di vista), e lo hanno usato: possono forzare gli aggiornamenti del firmware, per evitare che tutti i gadget "online" diventino inaccessibili (e questi includono la semplice lettura dei recenti dischi Blu-ray ...).

Un altro esempio è come un iPhone o iPad eseguirà solo applicazioni debitamente approvate (ovviamente approvate da Apple), a meno che il dispositivo non sia jailbroken. Apple e jailbreaker sono bloccati in una corsa senza fine, Apple produce nuove versioni di dispositivi e OS che accompagna a velocità ridotta, mentre i tecnici inversi sono al lavoro per trovare buchi da abusare. A volte il sistema operativo è rotto il giorno in cui esce; a volte mantiene la linea per diversi mesi.

Oltre agli exploit del software, è possibile utilizzare attacchi hardware. Per contrastarli, l'hardware deve essere resistente alla manomissione. Il nome generico per questo tipo di dispositivo è Modulo piattaforma affidabile . Un TPM può essere utilizzato come protezione aggiuntiva per l'utente, per bloccare alcuni tipi di voci illecite (ad es. Virus); ma può anche essere usato per proteggere contro l'utente, bloccandolo dalla sua stessa macchina.

Nessuno di questi, tuttavia, è realmente applicabile alle applet Java . L'applet Java, per definizione, è lontana dall'hardware reale. Funziona in una macchina virtuale che è implementata dal plugin Java - plugin di cui esiste un open source version che è facile da modificare per includere le capacità di debug di JavaSnoop.

La vera "soluzione" a questo problema è una no-soluzione: semplicemente non farlo. Non progettare l'applicazione in modo che il codice sul computer del client sia considerato affidabile. Semplicemente non funzionerà a lungo termine; a meno che non ci si trovi in un contesto che è abbastanza banale (ad esempio giochi online), l'occasionale "imbroglio" non è un grosso problema e le misure di mitigazione possono essere sufficienti, da un punto di vista economico. Se deve avere un codice lato client affidabile, preparati a produrre il tuo hardware antimanomissione.

Penso che le altre risposte abbiano coperto il principio fondamentale secondo cui è impossibile fidarsi completamente di un'applicazione client, quindi è stato detto che c'è qualcosa che puoi fare per alzare il tiro un po 'dagli attacchi più banali?

Direi che ci sono un paio di approcci che puoi prendere per questo. Per il flusso del traffico stesso, un approccio comune al reverse engineering consiste nell'utilizzare un proxy (ad esempio burp ) per intercettare il traffico. Un modo per rendere più difficile questo è consentire solo un certificato specifico da utilizzare piuttosto che fidarsi di qualsiasi certificato con il CN corretto emesso da una CA "attendibile". Questo è comunemente noto come blocco dei certificati

Un problema più grande è la decompilazione dell'applicazione client, che consente all'aggressore di vedere e modificare il suo comportamento. Come @thomaspornin dice che l'offuscamento non è una protezione completa con qualsiasi mezzo, ma potrebbe estirpare alcuni aggressori. È possibile utilizzare software come proguard .

Al di là delle basi, direi un'occhiata alla tua architettura, è possibile spostare le cose di più sul lato server per ridurre i potenziali rischi degli attacchi lato client? Un'altra opzione (imperfetta) sarebbe quella di avere un client scritto in una lingua più amichevole alle tecniche di offuscamento e anti-decompilazione.

Ecco un esempio del tipo di suggerimento che speravo di ottenere.

A: usa un canale segreto per segnalare dal client al server che ha stato violato Ad esempio, in uno sparatutto, imporre una "legge non scritta" che ogni decimo messaggio di movimento sarà a sinistra. Se l'esecuzione di questa legge da parte del cliente è sufficientemente naturale e distribuita, qualsiasi degli hack degli utenti che tentano di modificare, aggiungere o rimuovere movimenti, volontà probabilmente viola la legge. Il server impara che si tratta di un ladro e prende l'azione appropriata (dopo un ritardo casuale).

Il problema con questo tipo di hack di sicurezza è che viola un buon programma design, rendendo più difficile mantenere il client previsto in esecuzione correttamente.