Ok.
Stiamo ancora lavorando a questa applicazione mobile e abbiamo già capito molte cose.
Ora, dopo le attività e i fornitori di contenuti, vogliamo dare un'occhiata all'ultimo componente di
questa applicazione: il ricevitore broadcast.
Quindi ne abbiamo solo due, mentre questo qui proviene da alcune API di Google che non
vogliamo esaminare.
Ma questo qui, è stato sviluppato o codificato dallo sviluppatore e quindi potrebbero esserci dei difetti
al suo interno.
Vediamo che è stato impostato per esportare il vero e abbiamo anche il nome dell'Android nella trasmissione.
Quindi, se si vuole attivare questa azione, è necessario applicare questo nome di azione qui.
Ma prima di tutto, diamo un'occhiata a ciò che accade qui dentro.
Ok.
Come già accennato nella parte relativa al ricevitore broadcast, se si vuole analizzare il ricevitore broadcast,
l'unica cosa da ricercare è il metodo di ricezione on.
Questa è l'unica parte che può essere attivata da noi in questo momento.
In questo caso, abbiamo solo il metodo receive che esegue tutte le operazioni, il che è sorprendente
perché abbiamo il pieno controllo su questo metodo e su tutti i parametri.
Ancora una volta, dobbiamo ottenere una stringa in più.
Quindi abbiamo due stringhe all'interno, il che significa che abbiamo ottenuto il numero di telefono e il nuovo pass.
Va bene.
Sembra interessante.
Quindi possiamo vedere se il numero di telefono non è uguale a null.
Quindi, se abbiamo un numero di telefono, attiviamo questa parte, questo codice.
Altrimenti, ci limitiamo a uscire da questa situazione.
Ok?
Ciò significa che dobbiamo fornire un numero di telefono.
Il numero di telefono deve avere un certo valore.
No, il numero di telefono è irrilevante.
Interessante.
Ma non ci interessa questo numero di telefono in questo momento.
Ok.
Quindi possiamo attivare questo ricevitore broadcast.
E questo richiede due valori, un numero di telefono e un nuovo pass.
Ok.
E ora vediamo cosa succede qui.
Se forniamo un numero di telefono, non c'è problema, possiamo farlo.
Poi entriamo nelle impostazioni delle preferenze condivise.
Quindi li abbiamo ottenuti.
Ok.
Entriamo nelle preferenze di condivisione, questo nome utente fondamentalmente per la stringa pilota.
Quindi otteniamo questo nome utente e questo campo oc decrypt password new crypto is decrypt string super secure
password.
Ok, stiamo recuperando la password decriptata.
Quindi questa parte in questo momento sta andando nella stampa condivisa.
E prendere il nome utente e la password in queste due variabili.
Vediamo cosa succederà in seguito.
Poi assegniamo il nostro numero di telefono da qui.
A qui, il che significa che questo è ora il nostro numero di telefono.
E poi stiamo ricevendo un messaggio.
Aggiornamento testo password da.
Oh, bene, bene, bene.
Si tratta quindi della password decriptata che viene recuperata dalle preferenze condivise.
Quindi questo viene riportato in questa variabile qui.
La password decriptata viene ora utilizzata in questo messaggio.
Messaggio di testo con password aggiornata dalla password decriptata.
Quindi questo messaggio di testo sta facendo qualcosa con la password decriptata e sostiene anche che stiamo fornendo una
nuova password.
Questo qui.
E poi ok, ora, ora abbiamo il gestore di SMS e il gestore di SMS sta inviando questo messaggio
di testo, vero?
Sistema. fuori. println per la modifica della password.
Ok.
Anche la localizzazione ADB è coinvolta in questa ridicola funzione, ma non stampa alcuna
informazione sensibile oltre ai dati.
Qual è il.
Qual è il numero di telefono del messaggio?
Cos'è questo?
Ok.
Oltre al numero di telefono.
Oh, oh, oh, oh.
Ok.
E il messaggio di testo.
Quindi, all'interno dell'armadietto, se si cambia la password, la password viene stampata nell'armadietto perché
abbiamo questo direttamente qui.
La password decifrata sarà assegnata al messaggio di testo o sarà inclusa nel messaggio di testo.
E qui questo messaggio di testo viene stampato sull'armadietto.
Quindi la password trapela nell'output di locket.
Questo è un aspetto che non ho ancora esaminato, ma mi rendo conto che in questo momento, guardando questo incredibile
e poi il testo inviato dal manager, stiamo inviando i messaggi di testo che contengono la vecchia password.
Ma aspettate un attimo.
Va bene.
Interessante.
Per questo motivo non bisogna affidarsi ai nomi forniti dallo sviluppatore.
Riconosci qualcosa di interessante qui dentro?
Cosa succede con i nuovi poteri?
Vi lascio un momento per riflettere.
Ok.
Abbiamo quindi visto che possiamo attivare il ricevitore broadcast e fornire un numero di telefono e una nuova
password.
L'applicazione estrae le informazioni dalle preferenze condivise.
La vecchia password.
In questa parte qui.
Condividi le preferenze.
Allora è questo il punto.
Ottenere la stringa.
Procuratevi le corde qui.
Nome utente e password criptati.
Anche il nome utente non è criptato.
Abbiamo già capito che base64 non si basa su quei temi.
Ok, quindi estrae queste informazioni e le inserisce, almeno la password, in un output di logcat
ADB e anche in un messaggio di testo inviato via SMS.
Ok.
Ma il nuovo passaporto non viene toccato da nessuna parte.
Ciò significa che il passaporto non viene mai aggiornato in questa costruzione.
E poi torniamo fuori.
Quindi, se attiviamo il ricevitore broadcast, il processo di aggiornamento da parte del ricevitore broadcast, non stiamo
aggiornando il passaporto.
Abbiamo una fuga di informazioni, il che è assolutamente ridicolo perché possiamo
recuperare il passaporto originale, il che va benissimo perché se non lo aggiorniamo, il vecchio passaporto
funziona ancora, ma non lo aggiorniamo.
Questo qui non viene utilizzato da nessuna parte.
Solo all'interno di una stringa di messaggio di testo, ma non all'interno di un'altra funzione.
Abbiamo visto che il processo di aggiornamento funziona.
Quindi, dopo aver richiesto un nuovo passaporto e aver resettato questa domanda, dobbiamo inserire il nuovo passaporto.
Ma questo è stato separato dal ricevitore di trasmissione.
Quindi il ricevitore broadcast è semplicemente in perdita di informazioni.
Se possiamo attivarlo da soli, non possiamo aggiornare il passaporto.
Ma siamo ancora a posto con questo perché recuperiamo il vecchio passaporto.
Ma sì, questo è il motivo per cui non dovremmo fare affidamento su etichette come questa qui, questa nuova etichetta di passaggio
qui.
Non stiamo stabilendo un nuovo passaporto, almeno non qui.
Lo si sta facendo, ma non con un ricevitore radiotelevisivo.
Ok.
Tuttavia, attiviamo questo ricevitore di trasmissione, perché vorrei riempire lo smartphone
di SMS.
Stiamo anche inviando molti messaggi di testo.
Questo potrebbe essere un modo per trovare il proprio posto.
Per questo forniamo un numero di telefono.
Sì.
Forniamo un numero di telefono a cui inviare il messaggio.
Ok.
Ora me ne rendo conto.
Possiamo fornire il numero di telefono del biglietto e inviare la vecchia password per questa applicazione.
Oh, sì.
Ok.
Ora so come funziona.
Oh, sì.
Sarebbe una bella scoperta.
Quindi facciamo questo qui.
Ok.
Cosa dobbiamo ottenere all'interno del manifest di Android?
Abbiamo bisogno di avere il.
Il nome del ricevitore di trasmissione è questo.
Ok, vediamo.
ADB, guscio.
E poi, ancora una volta, il gestore delle attività.
E qui abbiamo qualcosa di simile alla trasmissione.
Qui abbiamo la trasmissione, in modo da poterla inviare a un ID utente specifico e a una sola applicazione, oppure possiamo inviare questa
trasmissione a ogni applicazione utente.
Nel nostro caso, come attaccante, siamo pigri e quindi lo inviamo semplicemente a tutti e
le applicazioni possono reagire a questo.
Quindi si può ricevere un metodo on receive relativo a questo evento di trasmissione e poi si può anche reagire
a questo evento.
Ma sì, questo, questo è già stato definito nella nostra applicazione.
Vogliamo hackerare, quindi siamo pronti a partire.
Quindi sì, questo è tutto ciò che noi, semplicemente, abbiamo chiamato pro broadcast default, credo sia tutto.
Sì, abbiamo specificato di inviare a tutti gli utenti e poi dobbiamo applicare i nostri intenti in fondo.
Facciamo questa trasmissione e poi il nome del pacchetto.
Il nome del componente nel nome del componente è il nome del nostro pacchetto.
Questo.
E poi vediamo.
Ad essere sinceri, non è necessario fornire un nome di componente, perché la trasmissione ricevuta
o la trasmissione sarà inviata in qualsiasi modo a tutti.
Ma proviamo in entrambi i modi.
Non sono nemmeno sicuro di cosa stia succedendo.
Ok, abbiamo il nome del componente e vediamo il nome di questa trasmissione.
E' questo qui?
Ok.
E ora dobbiamo definire l'azione.
E l'azione si svolge all'interno del manifest di Android.
Si chiama trasmissione.
Sì, l'azione dovrebbe essere sufficiente perché è l'azione che viene inviata a tutte le applicazioni in circolazione.
E poi l'applicazione può reagire a questo evento di trasmissione.
Va bene.
Ma questo non fa affatto male.
Ma potrebbe funzionare anche senza il nome del pacchetto.
Ok.
E ora vediamo, cosa dobbiamo fornire?
Quali sono gli intenti che dobbiamo esprimere in questo caso?
Un'intensa primavera abbiamo in numero di telefono e un nuovo pass.
Va bene.
Quindi il numero di telefono è una stringa.
Quindi utilizziamo questo valore di stringa chiave aggiuntivo.
Questa è la nostra stringa.
E il valore è che possiamo aggiungere delle citazioni, ma credo che anche questo non sia necessario.
Quindi i numeri di telefono, ad esempio uno, tre, tre, sette, sono i numeri di telefono dell'aggressore.
Cioè, lo smartphone, credo che recuperi tutti gli SMS, anche se non si tratta del numero di telefono originale.
Ma sì, non importa.
E l'altra parte era il nuovo pass, che non è davvero rilevante.
Non è rilevante per essere sicuri che sia proprio così.
Selezioniamone uno che soddisfi anche questi requisiti e che non ci crei problemi.
Va bene.
Ecco come possiamo attivare questa trasmissione.
E ora vediamo se funziona.
Posso mettere questo smartphone?
Credo di non poterlo tenere in primo piano.
Purtroppo no.
Quindi, mettiamo questo a sinistra.
Ok, vediamo.
Tre, due, uno.
Ok.
Non riesco a vedere qualcosa qui dentro in questo momento.
Potrebbe trattarsi di un vecchio SMS.
Vediamo se c'è qualche messaggio SMS in merito.
Inviateci un messaggio.
Sì.
Eccolo qui.
Questo è il numero di telefono.
Questo mi confonde un po'.
Dobbiamo cercare il gestore di SMS per inviare un messaggio di testo.
Se questo è il numero di telefono da cui proviene o a cui deve essere inviato.
Quindi, diamo un'occhiata veloce a questo aspetto.
Ok.
Ora abbiamo inviato un messaggio di testo ed eccolo qui.
Ok.
Sì.
Ok.
L'aspettativa era corretta.
Il primo è l'indirizzo di destinazione.
E se non siete sicuri, non dovreste fare congetture se ci sono documentazioni ufficiali in giro.
Quindi potete semplicemente cercarlo e vedere l'indirizzo della fonte.
Tuttavia, l'emulatore riceve tutti i messaggi perché è un emulatore e si possono verificare
alcune cose.
Quindi questo messaggio sarebbe stato acquisito dal telefono dell'aggressore e ora possiamo
vedere l'aggiornamento per questo utente qui.
La password è stata aggiornata da hacked a 1 a 3 dollari a work a 1 a 3 dollari.
E ora sappiamo di aver cambiato questa password per hackerarla tramite il nostro activity manager.
Quindi sì, sì, abbiamo cambiato questa password, il che è ridicolo.
Ora abbiamo un altro modo per interagire con le password, ma in questo caso potrebbe non essere aggiornato.
Possiamo verificarlo perché sappiamo che l'utente di questa password è il check.
Quindi dobbiamo capire se funziona da 1 a 3 dollari e se non funziona con il controllo dell'utente.
Quindi, scusate, dobbiamo prima riavviare l'applicazione per essere sicuri che le modifiche siano state aggiornate.
E poi vediamo.
Controllate e vedete se il vecchio passaporto funziona semplicemente.
Non c'è storia.
Quindi il vecchio passaporto viene violato a 1 a 3 dollari.
Se funziona, la password non è stata aggiornata.
Sì, è corretto.
Perché ho bisogno di inserire del testo.
Oh, scusate.
È un testo di input.
Uno, due o tre.
Ora, sono anche un po' eccitato in questo momento, quindi vediamo.
Sì.
Come previsto, il passaporto non viene aggiornato.
Questa scoperta è una fuga di informazioni.
Si tratta di una fuga di informazioni piuttosto piacevole perché è possibile definire il numero di telefono dell'aggressore per inviare
la password corrente dell'ultimo lotto dell'utente, il che sembra incredibile.
E sì, questo è il modo in cui possiamo abusarne.
Abbiamo visto che questo ricevitore broadcast fa trapelare la password, quindi non aggiorna la password,
ma fa trapelare informazioni in modo piuttosto massiccio perché possiamo inviarlo a qualsiasi numero vogliamo.
Tuttavia, anche se non stiamo inviando una password qui dentro, l'invio di un SMS da parte di un ricevitore broadcast
è assolutamente ridicolo perché potremmo inviare qualsiasi SMS di phishing o altre cose ad altre persone
da questo smartphone qui.
Naturalmente potrebbero esserci anche dei costi, che si verificano dal lato dell'utente.
L'esempio qui riportato mi sembra piuttosto sorprendente.
E sì, è un po' costruttivo per quanto riguarda queste cose, ma troverete sicuramente cose
del genere là fuori.
Non proprio così, ma quasi.
Ad esempio, una volta avevo un'applicazione che attivava un evento molto importante tramite un ricevitore
broadcast, che poteva essere attivato da un'applicazione dannosa.
E poi questo evento ha fatto alcune cose pazzesche a cui lo sviluppatore non aveva pensato.
Inoltre, altre persone possono attivare il ricevitore di trasmissione.
Vale sempre la pena di dare un'occhiata al ricevitore broadcast.
Va bene.
E questo è il modo in cui possiamo interagire con loro in modo piuttosto semplice, giusto?
Ok.
Questo è tutto per quanto riguarda i componenti di base.
Nel prossimo video daremo un'occhiata alla funzionalità di crittografia.
Daremo quindi un'occhiata a queste preferenze condivise e a come decifrarle facilmente.
Cercheremo anche di scovare le credenziali hardcoded, perché è un fenomeno che può verificarsi,
soprattutto nelle applicazioni mobili Iot.
Va bene.
Ok.
Quindi non vedo l'ora di vedervi nel prossimo video.