У свіжому випуску технологічного шоу «УТ‑2» ведучі розбирають одну з найцікавіших і водночас найнебезпечніших фішингових атак останніх років — злам екосистеми безпеки Robinhood. Американський трейдинговий застосунок, який свого часу став символом «демократизації» доступу до біржі, виявився вразливим до витонченої схеми, де зловмисники використали і особливості Gmail, і помилки в обробці HTTP‑заголовків на боці самого сервісу.
Результат — користувачі отримували абсолютно легітимні, технічно «чисті» з погляду SPF та інших перевірок листи безпеки від Robinhood, але всередині цих листів на них чекав ідеально замаскований фішинг.
Від «демократизації» біржі до гейміфікованого беттінгу
Robinhood у США часто подають як історію успіху: застосунок, що зламав бар’єри входу на фондовий ринок, відкривши торгівлю акціями та деривативами для мільйонів роздрібних інвесторів. Відсутність комісій, простий інтерфейс, миттєва реєстрація — усе це зробило платформу привабливою для новачків, які раніше навіть не думали про біржу.
Але в цієї «демократизації» був і темний бік. Інтерфейс Robinhood, з його анімаціями, пушами, миттєвими підтвердженнями угод і легким доступом до маржинальної торгівлі, дедалі частіше порівнюють не з класичним брокером, а з казино. Торгівля перетворюється на гру, де користувачі натискають кнопки, не завжди усвідомлюючи ризики, а механіки гейміфікації підштовхують до частіших і ризикованіших операцій.
Цей підхід добре помічають і в інших фінтех‑екосистемах. Один із топ‑менеджерів бізнесу, схожого на індійський Paytm, свого часу називав Robinhood і Freedom Finance втраченими можливостями для запуску «беттінг‑стайл» продуктів. Логіка проста: якщо люди вже звикли сприймати торгівлю як гру, чому б не довести цю гру до кінця, додавши ще більше механік, притаманних ставкам і азартним іграм.
На цьому тлі стає ще тривожніше, коли виявляється, що платформа з мільйонами користувачів і гейміфікованим підходом до грошей має критичні діри в безпеці. Адже аудиторія, яку привчили до «легкої» торгівлі, часто менш підготовлена до складних атак, ніж професійні трейдери.
Gmail як зброя: як варіанти адреси відкрили двері атаки
Ключовим елементом схеми став спосіб, у який Gmail обробляє адреси електронної пошти. Для користувачів це зручно, для зловмисників — золота жила.
Gmail ігнорує крапки в локальній частині адреси. Тобто всі листи на адреси на кшталт ivan.petrenko@gmail.com, ivanpet.renko@gmail.com чи i.v.a.n.petrenko@gmail.com потрапляють в одну й ту саму скриньку. Додатково сервіс підтримує так звані плюс‑теги: усе, що після знака «+» до символу «@», Gmail відкидає. Наприклад, ivanpetrenko+trading@gmail.com і ivanpetrenko+spam@gmail.com теж приходять у ту ж саму поштову скриньку, що й базова адреса ivanpetrenko@gmail.com.
Зловмисники використали цю особливість як стартову точку атаки. Схема починалася з реєстрації нового акаунта Robinhood на варіант Gmail‑адреси жертви з крапками або плюс‑тегами. Для самого Robinhood це виглядало як абсолютно новий користувач з унікальною адресою. Для Gmail — як ще один варіант тієї ж поштової скриньки, якою реально користується жертва.
Таким чином, усі службові листи, пов’язані з новим акаунтом, потрапляли в ту ж саму пошту, де людина звикла отримувати справжні повідомлення від Robinhood. Це створювало ідеальне тло для подальшої маніпуляції: користувач бачив у себе в інбоксі легітимні листи від реального домену сервісу, підписані справжніми сертифікатами, з коректними SPF‑записами. На цьому фундаменті можна було будувати будь‑яку фішингову надбудову.
User‑Agent як троянський кінь: критична помилка в шаблоні листів
Другий, ще більш вражаючий компонент атаки — те, як Robinhood обробляв HTTP‑заголовок User‑Agent у своїх внутрішніх системах безпеки.
Коли користувач логіниться в застосунок або веб‑версію, клієнт надсилає на сервер низку заголовків, зокрема User‑Agent. У нормальній ситуації це просто текстовий рядок, який описує браузер, операційну систему та інші технічні деталі: наприклад, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7).... Ці дані часто використовують для логів, аналітики, іноді — для формування тексту службових сповіщень на кшталт «Ви увійшли з нового пристрою Chrome на macOS».
У випадку з Robinhood цей рядок потрапляв ще глибше — у HTML‑шаблон службових листів про безпеку. Сервери компанії вставляли сирий User‑Agent із запиту логіну без будь‑якого екранування прямо в HTML‑код листа. З погляду веб‑безпеки це класичний приклад того, як не можна робити: будь‑які дані, що надходять від клієнта, мають вважатися потенційно небезпечними і проходити фільтрацію або екранування перед тим, як потрапити в HTML.
Зловмисники це помітили й перетворили User‑Agent на троянського коня. Замість звичайного тексту вони почали надсилати в цьому заголовку фрагменти HTML‑коду. Оскільки сервер Robinhood бездумно підставляв отриманий рядок у шаблон листа, браузер одержувача інтерпретував його як частину розмітки.
У результаті легітимний лист безпеки, який реально відправляли сервери Robinhood, відображав не той текст, який задумали розробники, а підроблене повідомлення про «нерозпізнану активність» із яскравою кнопкою «Review activity». З погляду користувача все виглядало бездоганно: правильний відправник, правильний домен, коректні DKIM/DMARC/SPF, звичний дизайн листа — і тривожне попередження, що хтось щойно увійшов у його акаунт.
Це вже не класичний фішинг, де зловмисники намагаються підробити домен або дизайн. Тут сам сервіс, своїми ж руками, формував і розсилав шкідливий контент, просто тому, що довірився даним із клієнта.
Ідеальний фішинг: клонований сайт і справжні облікові дані
Кульмінацією атаки стала кнопка в листі, яка вела на клонований сайт Robinhood. Оскільки HTML‑код формувався з User‑Agent, зловмисники могли вказати будь‑який URL у атрибуті href. Вони створили сторінку, максимально схожу на офіційний сайт: логотип, кольори, верстка, форма логіну — все повторювало оригінал.
Користувач, який отримував такий лист, бачив повідомлення про «нерозпізнану активність» і логічну пропозицію «переглянути активність» або «підтвердити, що це були ви». Натискаючи кнопку, він потрапляв на фішинговий клон, але в умовах стресу й довіри до бренду рідко звертав увагу на дрібниці на кшталт точного написання домену в адресному рядку.
Далі все відбувалося за класичним сценарієм: користувач вводив свої справжні облікові дані — логін, пароль, можливо, навіть одноразові коди, якщо фішингова сторінка була достатньо продуманою. Зловмисники перехоплювали ці дані в реальному часі й могли або авторизуватися в акаунті жертви, або продати доступ на чорному ринку.
Особливо небезпечно те, що жертви були впевнені: вони взаємодіють із офіційним сервісом. Лист прийшов із правильного домену, пройшов SPF та інші перевірки автентичності, не потрапив у спам, а інтерфейс сторінки входу виглядав звично. Для багатьох користувачів це повний набір сигналів «усе гаразд».
У традиційному фішингу завжди є слабкі місця: дивний домен, помилки в дизайні, відсутність HTTPS, некоректні заголовки листа. Тут же технічна легітимність була майже стовідсотковою, що робило атаку надзвичайно переконливою і важкою для виявлення як людьми, так і автоматизованими фільтрами.
Чому SPF і «зелений замок» більше не рятують
Один із найважливіших висновків із цієї історії — класичні маркери безпеки електронної пошти вже не гарантують захисту від складних атак.
Листи, які використовували зловмисники, проходили SPF та інші перевірки автентичності, оскільки надсилалися реальними серверами Robinhood. З погляду будь‑якого поштового провайдера це був еталонний трафік: домен збігається, IP‑адреси авторизовані, DKIM‑підпис валідний, DMARC‑політика дотримана. Немає жодних підстав маркувати такі повідомлення як підозрілі.
Це принципово відрізняє атаку від звичайного фішингу, де головна боротьба точиться навколо підроблених доменів і неавторизованих серверів розсилки. Тут проблема не в тому, що хтось «прикинувся» Robinhood, а в тому, що сам Robinhood став каналом доставки шкідливого контенту через власну вразливість.
Для користувачів це означає, що звичні поради «перевіряйте відправника» і «дивіться на зелений замок у браузері» вже не достатні. Якщо сервіс має XSS‑подібні діри у своїх листах або веб‑інтерфейсі, зловмисники можуть використовувати його інфраструктуру як таран проти власних клієнтів.
Для компаній висновок ще жорсткіший. Безпека — це не лише про шифрування, двофакторну автентифікацію чи складні паролі. Це також про банальну гігієну роботи з даними користувача: жоден рядок, що надходить із клієнта, не має потрапляти в HTML без екранування. Особливо якщо йдеться про шаблони листів безпеки, які користувачі сприймають як останню лінію оборони.
Висновки: коли UX, азарт і безпека сходяться в одній точці
Історія з фішинговою атакою на Robinhood показує, як кілька на перший погляд не пов’язаних факторів можуть скластися в ідеальну бурю.
По‑перше, гейміфікована природа застосунку, який перетворив торгівлю на щось дуже схоже на азартні ігри, притягує аудиторію, що не завжди має достатню кіберграмотність. Люди звикають натискати кнопки швидко, емоційно, не заглиблюючись у деталі.
По‑друге, технічні особливості інфраструктури — як‑от поведінка Gmail із крапками та плюс‑тегами в адресах — створюють неочевидні вектори атаки. Те, що для одного сервісу є просто зручністю, для іншого може стати критичною вразливістю, якщо він не враховує ці нюанси в моделі загроз.
По‑третє, базові помилки у веб‑безпеці, на кшталт вставляння сирого User‑Agent у HTML‑шаблон листа, перетворюють легітимну інфраструктуру на інструмент зловмисників. У такій конфігурації навіть найкращі системи автентифікації пошти не допомагають: вони лише підтверджують, що шкідливий лист справді прийшов від того, за кого себе видає.
Для ринку фінтеху це серйозний сигнал. Коли платформи, які вже межують із беттінгом за своєю поведінковою економікою, ще й виявляються вразливими до подібних атак, ризики для користувачів зростають у геометричній прогресії.
А для користувачів головний урок залишається неприємним, але необхідним: навіть якщо лист приходить із «правильного» домену, проходить усі технічні перевірки й виглядає як звичне сповіщення безпеки, це ще не гарантія його безпечності. У світі, де легітимні сервіси можуть несвідомо стати каналом атаки, критичне мислення і базове розуміння технічних механік стають не менш важливими, ніж складний пароль.
Джерело
Тім Кук на пенсію: 15 років без інновацій. Robinhood роздає гроші хакерам. mvc #26