L'iniezione del codice è possibile attraverso la modifica del pacchetto?
Ad esempio, se un gioco ha inviato un punteggio dichiarante di pacchetto = 99, è possibile modificare il pacchetto in modo da ottenere il punteggio = * codice * o qualcosa di simile?
Credo che una domanda simile sarebbe, è anche possibile eseguire codice non API in un ambiente API?
Sì, nel senso che puoi forgiare e inviare un pacchetto di questo tipo.
Primo ostacolo: è ancora un pacchetto valido ? Questo dipende dalla struttura del pacchetto. Molti giochi sfruttano le librerie esistenti che utilizzeranno formati standard come JSON o XML, quindi non sarà facile creare un pacchetto che contenga il codice desiderato e comunque sia sintatticamente corretto per il formato dei dati coinvolti.
Quindi il server accetterà il pacchetto? La maggior parte degli sviluppatori di giochi si chiede cosa succederebbe se qualcuno modificasse
"score": 999
in
"score": 999999999
Mentre sospetto, da alcune classifiche che vedo su Google Play, non tutti gli sviluppatori hanno dato a questa possibilità una considerazione sufficiente, il solito basso livello, bassa sicurezza, ma il metodo veloce per fermare il 99% del "vincitorez" di aspiranti sarebbe anche includi l'hash del valore e un segreto client ( == non sicuro ):
"score": 99,
"hash": "ff24e8a1f3fddb010095102bce5a013c"
Un membro del restante 1% dei giocatori potrebbe facilmente scavalcare questo scavando il segreto dal binario del gioco, o anche provando a forzarlo fuori dallo stesso binario: il più delle volte l'hash per un tale schema semplicistico sarà qualcosa come MD5 ("SECRET" + SCORE) o forse MD5 (SCORE + "SECRET"), e SECRET sarà una delle voci nella tabella delle stringhe binarie, in chiaro.
Quindi invii il codice modificato con l'hash appropriato e passerà il controllo.
Se la difesa è ancora più stretta, il suo stadio sarà quasi impossibile da superare, tuttavia: il gioco contiene la chiave pubblica del server e lo utilizza per crittografare il punteggio in RSA, senza nemmeno preoccuparsi di inviare in chiaro.
Puoi ignorare questa difficoltà se sai che il lato server di overflow del buffer si trova nel codice che legge la variabile stessa, indipendentemente dal fatto che sia RSA crittografato o meno (cioè, prima è persino decodificato)
A questo punto sei riuscito a inviare una stringa al server nella speranza che faccia qualcosa con esso.
Se il server esegue in modo stupido alcune ipotesi sulla lunghezza della stringa, potrebbe essere sufficiente per un buffer overflow. Potrebbe essere necessario eseguire alcune sostituzioni ad hoc per evitare di inviare un payload del codice con zeri binari, che potrebbero interrompere l'operazione di copia delle stringhe, ma è fattibile (ed è stato fatto).
Ma ora sorge un'altra difficoltà. Hai iniettato qualcosa da qualche parte nello spazio di elaborazione del server. Come gestisci ciò per ottenere qualcosa di "utile" (dal punto di vista di un attaccante)? Potrebbe benissimo essere che tutto quanto sopra comporta solo il singhiozzo del server o malfunzionamenti per periodi più lunghi.
For example, if a game sent a packet declaring score=99 could I then modify the packet to score=code or something similar?
Tutto dipende da come viene interpretato sul lato server. Se score viene interpretato come identificatore, = come delimitatore e 99 come valore numerico, l'esecuzione del codice sarebbe possibile solo tramite un overflow, qualora tale vulnerabilità esistesse. Se, tuttavia, qualsiasi cosa viene inviata viene interpretata come codice eseguibile, allora sì, sarebbe possibile.
I guess a similar question would be, is it also possible to execute non-API code in an API environment?
Non sono sicuro di cosa intendi con questo. L'ambiente in cui esegui il codice deve essere in grado di capirlo per poterlo eseguire. Se l'API è sufficientemente sandbox, l'esecuzione di codice arbitrario potrebbe essere difficile.