Bank si lamenta di Android rootato. È davvero peggio di un desktop di Windows?

È tutto sul modello di sicurezza

Vediamo il riferimento a "Controllo per dispositivo jailbroken / rooted" in quasi tutte le checklist di sicurezza delle applicazioni mobili (ad esempio OWASP ). Quando lo si confronta con desktop o browser Web, dobbiamo tenere presente che hanno diversi modelli di minacce.
Ad esempio sulle macchine desktop quando si progetta un'applicazione, sappiamo già che esistono altre applicazioni con privilegi di amministratore.

Per fare un esempio, il modello di sicurezza per sistemi operativi come Windows o Linux non impedisce a un'applicazione di accedere alle directory o alla memoria di un'altra applicazione.

Ora nel contesto mobile, prendendo come esempio Android, il sistema operativo impedisce alle applicazioni di accedere alle directory degli altri e il privilegio di root ignora questo controllo di sicurezza. Quindi, effettuando il rooting del tuo dispositivo, stai apportando una modifica al tuo dispositivo che potrebbe non essere prevista dagli sviluppatori dell'applicazione e i suoi rischi potrebbero non essere presi in considerazione.

Ora torniamo a OWASP's Progetto di sicurezza mobile (pericoli di jailbreaking / root) , i metodi di rooting sono classificati come segue:

• Sfrutta Userland: l'accesso jailbroken è ottenuto solo all'interno del livello utente. Ad esempio, un utente può avere accesso root, ma non è in grado di modificare il processo di avvio. Questi exploit possono essere corretti con un aggiornamento del firmware;
• iBoot Exploit: accesso jailbroken al livello utente e al processo di avvio. Gli exploit iBoot possono essere aggiornati con un aggiornamento del firmware;
• Sfrutta Bootrom: accesso jailbroken al livello utente e al processo di avvio. Gli exploit di Bootrom non possono essere corretti con un aggiornamento del firmware. Aggiornamento hardware di bootrom richiesto per la patch in questi casi;

E i rischi sono:

General Mobile

1. Some jailbreaking methods leave SSH enabled with a well-known default password (e.g., alpine) that attackers can use for Command & Control;
2. The entire file system of a jailbroken device is vulnerable to a malicious user inserting or extracting files. This vulnerability is exploited by many malware programs, including Droid Kung Fu, Droid Dream and Ikee. These attacks may also affect unlocked Windows Phone devices, depending on the achieved unlocking level;
3. Credentials to sensitive applications, such as banking or corporate applications, can be stolen using key logging, sniffing or other malicious software and then transmitted via the internet connection.

iOS

1. Applications on a jailbroken device run as root outside of the iOS sandbox. This can allow applications to access sensitive data contained in other apps or install malicious software negating sandboxing functionality;
2. Jailbroken devices can allow a user to install and run self-signed applications. Since the apps do not go through the App Store, Apple does not review them. These apps may contain vulnerable or malicious code that can be used to exploit a device.

Android

1. Android users that change the permissions on their device to grant root access to applications increase security exposure to malicious applications and potential application flaws;
2. 3rd party Android application markets have been identified as hosting malicious applications with remote administrative (RAT) capabilities.

Rischi non tecnici

1. Software updates cannot be immediately applied because doing so would remove the jailbreak. This leaves the device vulnerable to known, unpatched software vulnerabilities;
2. Users can be tricked into downloading malicious software. For example, malware commonly uses the following tactics to trick users into downloading software;
   Apps will often advertise that they provide additional functionality or remove ads from popular apps but also contain malicious code;
   Some apps will not have any malicious code as part of the initial version of the app but subsequent "Updates" will insert malicious code.

Si possono contare innumerevoli rischi per ogni piattaforma che vanno dal web, applicazioni mobili, applicazioni desktop, ecc. e il confronto di queste piattaforme in termini di sicurezza non è banale. Potrebbe dipendere molto da piattaforme specifiche (Android vs iOS, Windows vs Linux) e dipendere anche dai comportamenti degli utenti (Avere un dispositivo mobile con molte applicazioni indesiderate e avere un dispositivo mobile solo con app conosciute). In ogni contesto, proviamo a prendere misure per ridurre i nostri rischi e una volta che una piattaforma diventa troppo insicura, potremmo smettere di fornire il servizio su di esso (ad esempio servizi bancari telefonici tramite telefono fisso o USSD).

Tornando alla tua domanda sull'utilizzo del browser web del tuo cellulare o utilizzando l'applicazione nativa per le banche mobili, i rischi dipendono dall'implementazione dell'applicazione mobile banking e dal tipo di malware che potrebbe essere presente sul tuo telefono cellulare.

Sono d'accordo con le informazioni fornite da @ Silverfox. Le istituzioni finanziarie mirano certamente a ridurre il rischio di frodi basando la loro politica di sicurezza su un modello di minaccia che è unico per il dispositivo mirato.

Molti sistemi bancari online hanno adottato l'autenticazione a più fattori (MFA) per dimostrare la propria identità. Ciò significa che un utente malintenzionato che ottiene la combinazione nome utente / password non è in grado di accedere al proprio account (richiederebbe loro di ottenere il codice di verifica o di contraffare / compromettere un precedente "PC fidato").

L'escalation dei privilegi consente al nemico di interrompere l'isolamento e accedere a qualsiasi dato sensibile. Poiché il telefono è ora una parte fondamentale dello schema di autenticazione dell'utente, un dispositivo rooted è un rischio molto più grande per l'azienda finanziaria dal momento che se è compromesso. Ad esempio, il malware può rubare le credenziali dall'app banking o persino ottenere il codice di verifica SMS inviato come parte dell'MFA, cancellandolo immediatamente per nascondere le tracce all'utente.

Tuttavia, una cosa importante da considerare è che questi controlli dell'ambiente di runtime possono spesso essere facilmente aggirati. Esistono vari metodi e API per eseguire il controllo, ma per esempio, molte applicazioni lo faranno grosso modo: controlla se esiste il binario "su", se è così, allora si presume che il dispositivo abbia i privilegi di root. Rinunciando banalmente a "su", è possibile ignorare questo tipo di controllo.

Per ottenere risultati migliori, molte delle moderne applicazioni Android utilizzeranno qualcosa sulla linea dell'API di Google SafetyNet per eseguire l'attestazione remota e verificare lo stato di conformità del dispositivo. Inoltre, ci sono soluzioni di terze parti sotto l'ombrello delle applicazioni MDM (Mobile Device Management), che vengono tipicamente implementate da grandi aziende che condividono i rischi dei loro dipendenti che trasportano dati sensibili, ad esempio avendo la loro app di posta elettronica di lavoro compromessa se radicata il dispositivo viene infettato.