Технічний аналіз шахрайства 4k Facebook

ТЛ; ін: Не довіряйте авторизації webview у рідних програмах, вони можуть читати ваші файли cookie та використовувати їх у своїх інтересах.
Стежте за темою Hacker News “Як я втратив 4 тисячі євро під час шахрайства у Facebook“, ми реконструювали програму, щоб побачити, як це відбувається.

Нова хвиля фішингу

Фішинг. Ми всі це знаємо, ми всі це ненавидимо. Нік ван дер Маас теж це ненавидить, але він став жертвою нового типу фішингу, який зняв 4 тис. євро з його банківського рахунку.

Як це сталося? Як Нік, технічно підкований користувач, який володіє бізнесом електронної комерції, потрапив на таку атаку?

Потік входу та проблема довіри користувача

Форми для входу сьогодні скрізь. У Instagram, TikTok і навіть у вашій місцевій газеті майже завжди потрібна автентифікація користувача для використання будь-якої програми.

Один із варіантів авторизації передбачає використання зовнішнього провайдера – Google, Facebook, Twitter чи інших. У випадку Facebook, наприклад, Android SDK надає користувачеві нативне накладання та просить користувача увійти у Facebook, використовуючи своє ім’я користувача та пароль.

Це змушує користувача довіряти програмі та створює в ньому впевненість у тому, що вхід у його чи її обліковий запис у соціальній мережі за допомогою імені користувача та пароля безпечний.

Але це не завжди так.

Випадок шахрайства Webview

Що станеться, якщо ви залучите Webviews до процесу входу?

Веб-перегляди за своєю суттю небезпечні. Будь-яка програма для Android, яка використовує веб-перегляд, має повний доступ до будь-яких даних, що зберігаються на веб-сайті – до сховища сеансів, локального сховища та, що найважливіше, до файлів cookie.

Наприклад, додаток, що представляє сторінку входу у Facebook, може викрасти файли cookie користувача після входу на веб-сайт.

Ось скріншоти двох сторінок входу. Один із незахищених веб-переглядів, а інший — безпечної рідної сторінки входу. Ви можете помітити різницю?

(Вхід в Instagram – це захищена рідна сторінка входу)

Втрата 4 тис. євро через шахрайство у Facebook

Нік попався на шахрайство Webview. Нік не типовий користувач; Він займається електронною комерцією, онлайн-маркетингом і консалтингом. За його власними словами:

Мені досі важко повірити, що я попався на таке шахрайство. У всіх моїх облікових записах є 2FA, я використовую менеджер паролів і загалом я дуже обережний із безпекою облікових записів.

Нік довіряв входу в шкідливу програму за допомогою свого імені користувача та пароля Facebook. Але він не здогадувався, що програма, яку він завантажив, була зловмисною та використовувала веб-перегляд, щоб вкрасти його файли cookie Facebook, увійти в його обліковий запис і вкрасти у нього 4 тисячі євро.

Давайте подивимось, що відбувається за лаштунками Tiktok Ads Business, шкідливої ​​програми, яку він завантажив.

Отримання файлів cookie з Webview на Android

Потік простий. Нік відкриває програму, натискає велику кнопку FB і відкриває веб-перегляд із мобільною сторінкою Facebook.

Після того, як він увійде, програма запускає цей дуже простий рядок коду, взятий із декомпіляції програми, яку ми зробили тут, у Sayfer:

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

Потім файли cookie Facebook надсилаються на віддалений сервер шкідливого додатка, і їх можна використовувати для входу в обліковий запис жертви.

просто. Насправді надто просто: будь-який користувач, який входить на будь-який веб-сайт через веб-перегляд у програмі, ризикує передати повне право власності на свій обліковий запис.

Що далі?

Зміна потрібна на двох різних рівнях.

По-перше, власний потік входу не повинен покладатися на перегляди, подібні до Інтернету, для потоку входу. Через це користувачі надто їм довіряють, що призводить до того, що користувачі стають жертвами справжніх шахрайських крадіжок файлів cookie веб-перегляду.

По-друге, необхідні технічні зміни в реалізації веб-перегляду в Android. Програмам не слід дозволяти доступ до файлів cookie будь-якого веб-сайту, який вони завантажують. Веб-перегляди мають бути ізольованими, і програма має спілкуватися з ними через дуже тонкий і обмежений API, щоб запобігти викраденню облікових даних користувача.