Une analyse technique de l'escroquerie Facebook 4k

tl; dr: Ne faites pas confiance aux connexions WebView sur les applications natives, elles peuvent lire vos cookies et les utiliser à leur avantage.
Suite au fil Hacker News "Comment j'ai perdu 4 XNUMX € dans une arnaque sur Facebook“, nous avons procédé à une rétro-ingénierie de l'application pour voir comment cela se produit.

La nouvelle vague de phishing

Phishing. Nous le savons tous, nous le détestons tous. Niek van der Maas le déteste aussi, mais il a été victime d'un nouveau type d'escroquerie par hameçonnage, qui a prélevé 4 XNUMX € sur son compte bancaire.

Comment est-ce arrivé? Comment Niek, un utilisateur féru de technologie qui possède une entreprise de commerce électronique, est-il tombé dans ce type d'attaque ?

Flux de connexion et problème de confiance des utilisateurs

Les formulaires de connexion sont partout de nos jours. Instagram, TikTok et même votre journal local, l'authentification de l'utilisateur est presque toujours nécessaire pour utiliser n'importe quelle application.

L'une des options de connexion implique un fournisseur externe - à savoir Google, Facebook, Twitter ou autres. Dans le cas de Facebook, par exemple, Android SDK présente à l'utilisateur une superposition native et lui demande de se connecter à Facebook à l'aide de son nom d'utilisateur et de son mot de passe.

Cela permet à l'utilisateur de faire confiance à l'application et crée chez l'utilisateur la confiance que la connexion à son compte social via un nom d'utilisateur et un mot de passe est sûre.

Mais ce n'est pas toujours le cas.

Le cas des arnaques Webview

Que se passe-t-il lorsque vous impliquez Webviews dans le processus de connexion ?

Les vues Web sont intrinsèquement non sécurisées de par leur conception. Toute application Android utilisant une vue Web a un accès complet à toutes les données stockées par le site Web - stockage de session, stockage local et, surtout, cookies.

Par exemple, une application présentant une page de connexion Facebook, peut voler les cookies de l'utilisateur après la connexion au site Web.

Voici des captures d'écran de deux pages de connexion. L'un est une vue Web non sécurisée et l'autre est une page de connexion native sécurisée. Pouvez-vous faire la différence?

(La connexion Instagram est la page de connexion native sécurisée)

Perdre 4 XNUMX € dans une arnaque sur Facebook

Niek est tombé dans l'escroquerie Webview. Niek n'est pas un utilisateur typique ; Il dirige une entreprise de commerce électronique, de marketing en ligne et de conseil. Dans ses propres mots :

J'ai encore du mal à croire que j'ai été victime d'une arnaque comme celle-ci. J'ai 2FA sur tous mes comptes, j'utilise un gestionnaire de mots de passe et je suis généralement très prudent avec la sécurité des comptes.

Niek a fait confiance à la connexion à l'application malveillante en utilisant son nom d'utilisateur et son mot de passe Facebook. Mais il ne savait pas que l'application qu'il avait téléchargée était malveillante et utilisait WebView pour voler ses cookies Facebook, se connecter à son compte et lui voler 4 XNUMX €.

Jetons un coup d'œil dans les coulisses de Tiktok Ads Business, l'application malveillante qu'il a téléchargée.

Récupérer les cookies d'une Webview sur Android

Le flux est simple. Niek ouvre l'application, clique sur le gros bouton FB et se voit présenter une vue Web avec la page mobile de Facebook.

Une fois qu'il s'est connecté, l'application exécute cette ligne de code très simple, tirée d'une décompilation de l'application que nous avons faite ici chez Sayfer :

public final string retrieveWebCookie() {
    return cookieManager.getCookie(LoginActivity.CONST_URL_FACEBOOK);
}

Les cookies Facebook sont ensuite envoyés au serveur distant de l'application malveillante et peuvent être utilisés pour se connecter au compte de la victime.

Simple. Trop simple vraiment - tout utilisateur se connectant à n'importe quel site Web via une vue Web sur une application risque de céder la pleine propriété de son compte.

Quelle est la prochaine?

Un changement s'impose à deux niveaux différents.

Premièrement, les connexions de flux natif ne doivent pas s'appuyer sur des vues de type Web pour le flux de connexion. Cela incite les utilisateurs à leur faire trop confiance et fait en sorte que les utilisateurs sont victimes d'escroqueries de piratage de véritables cookies WebView.

Deuxièmement, un changement technique est nécessaire dans l'implémentation de la vue Web sur Android. Les applications ne doivent pas être autorisées à accéder aux cookies des sites Web qu'elles chargent. Les vues Web doivent être mises en bac à sable et l'application doit communiquer avec elles via une API très fine et limitée, pour les empêcher de détourner les informations d'identification des utilisateurs.