A Technical Analysis of the 4k Facebook Scam

tl;dr: Don’t trust webview logins on native apps, they can read your cookies and use them to their advantage.
Following the Hacker News thread “How I lost €4k in a Facebook scam“, we reverse engineered the app to see how this happens.

The new phishing wave

Phishing. We all know it, we all hate it. Niek van der Maas hates it too, but he fell victim to a new type of phishing scam, which took €4k from his bank account.

How did this happen? How did Niek, a tech-savvy user who owns an e-commerce business, fell for this kind of attack?

Login flow and the user trust issue

Login forms are everywhere these days. Instagram, TikTok, and even your local newspaper, there is almost always a need for user authentication to use any app.

One of the options of logging in involves an external provider – namely Google, Facebook, Twitter or others. In the case of Facebook, for example, Android SDK presents the user with a native overlay and asks the user to log into Facebook using his or her username and password.

This makes the user trust the app, and creates within the user a confidence that logging into his or her social account via username and password is safe.

But it isn’t always so.

The case of Webview scams

What happens when you involve Webviews in the login process?

Webviews are inherently insecure by design. Any android app using a webview has full access to any data stored by the website – session storage, local storage, and most importantly, cookies.

For example, an app presenting a Facebook login page, can steal the user’s cookies after the login to the website.

Here are screenshots of two login pages. One is of an insecure Webview, and the other is a secure native login page. Can you tell the difference?

(The Instagram login is the secured native login page)

Losing €4k in a Facebook scam

Niek fell for the Webview scam. Niek isn’t a typical user; He runs an e-commerce, online marketing and consultancy. In his own words:

I still find it hard to believe I fell for a scam like this. I have 2FA on all my accounts, use a password manager, and I’m generally very cautious with account security.

Niek trusted logging into the malicious app by using his Facebook username and password. But little did he know that the app he downloaded was malicious, and used webview to steal his Facebook cookies, log into his account, and steal €4k from him.

Let’s have a peak behind the scenes of Tiktok Ads Business, the malicious app that he downloaded.

Retrieving cookies from a Webview on Android

The flow is simple. Niek opens the app, clicks on the big FB button, and is presented with a webview with Facebook’s mobile page on it.

After he logs in, the app runs this very simple line of code, taken from a decompilation of the app we did here at Sayfer:

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

The Facebook coockies are then being sent to the malicious app’s remote server, and can be used to log into to the victim’s account.

Simple. Too simple really – any user logging into any website through a webview on an app, is at risk of giving away full ownership of his or her account.

What’s next?

A change is needed on two different levels.

Firstly, native flow logins shouldn’t rely on web-like views for the login flow. This makes users trust them too much, and results in users falling victim for real webview cookies hijacking scams.

Secondly, a technical change is needed in Android’s implementation of webview. Apps shouldn’t be allowed to access the cookies of any website they load. Webviews should be sandboxed, and the app should communicate with it via a very thin and limited API, to prevent them from hijacking user credentials.