Началось всё невинно: в X (бывший Twitter) попался твит о новом продукте одной из любимых компаний — Cloudflare.
Любопытно! Клик по ссылке — и вот он, сервис:
И ура! Желаемый хендл @ericlaw ещё свободен. Стоит поторопиться, пока его не забрал кто-то другой!
Поскольку аккаунт в Cloudflare уже давно существует, достаточно просто войти. Логично — как иначе привязать хендл к учётной записи?
Проще некуда. Вход выполнен. Остался последний шаг — авторизовать новую функцию?
Но погодите-ка!
Это выглядит в точности как одна из атак consent phishing, набравших популярность за последние несколько лет!
И ещё вопрос: почему точка входа находится на cloudflare.pay — домене, у которого нет сохранённых учётных данных, — а не в пределах cloudflare.com, где они уже есть (например, cloudflare.com/pay)? Между доменом .com и доменом .pay нет никакой технической связи. Домены под sTLD .pay доступны любому желающему за 20 долларов (в отличие, скажем, от .bank, где проверка строже) — то есть ничто не мешало бы зарегистрировать собственный домен cloudflarepayments.pay буквально за несколько минут.
И почему страница разрешений Cloudflare не узнаёт собственную функцию компании? А зелёная галочка выглядит крайне подозрительно — злоумышленник вполне мог бы вставить такой эмодзи прямо в поддельное отображаемое имя, точно так же, как это делают при фишинге аккаунтов Microsoft почты с обманчивыми именами и иконками приложений:
Ребята из Cloudflare — гении, знающие своё дело. Это точно должна быть атака. И довольно хитрая — возникло острое чувство спешки, желание успеть «выиграть» гонку за нужный хендл. Очень, очень умно!
К сожалению, страница разрешений Cloudflare не соответствует лучшим практикам — на ней нет ссылки «Сообщить о подозрительном запросе», чтобы предупредить Cloudflare о том, что их клиентов атакуют.
Возврат в панель управления Cloudflare и попытка найти функцию Wallet через боковую панель — тщетно. Её там нет. Wallet заявлен как «новая функция», возможно, дашборд просто ещё не обновился. Поиск по документации тоже ничего не даёт. Остаётся спросить у ИИ-агента в чате.
Первое, что запрашивает чат-агент, — доступ к аккаунту:
Немного странно, но страница всё же находится на cloudflare.com, так что, наверное, можно дать агенту доступ к тому, к чему у него уже есть доступ. Любопытно, что ИИ-агент сначала предлагает выдать полный контроль, а не доступ только для чтения — что выглядит нарушением принципа минимальных привилегий, хотя вопрос, требующий доступа к конкретному аккаунту, тут и не задавался. После выдачи разрешения на чтение агент позволяет задать вопрос:
Вот это да. Cloudflare сам подтверждает, что это действительно атака! Самое время немедленно сообщить о фишинге!
Несколько минут спустя… мимо…
Ой.
После ещё нескольких минут судорожных поисков выяснилось, что перед нами всё-таки настоящий новый продукт Cloudflare и легитимный сайт, несмотря на то, что он демонстрировал все признаки изящной фишинговой атаки.
Кроме того, выяснилось, что подозрительная зелёная галочка — не часть недостоверного отображаемого имени приложения, а (неудачно размещённый) элемент безопасности интерфейса, на который пользователь должен наводить курсор, чтобы увидеть детали безопасности:
В Cloudflare, судя по всему, ожидают, что о проблемах безопасности будут сообщать через HackerOne (хотя войти туда не удалось — CAPTCHA Cloudflare, используемая на HackerOne, похоже, не работает…).
Когда легитимные сайты иногда ведут себя настолько «фишингово», стоит задуматься, насколько сложно сервисам репутации URL — таким как Microsoft SmartScreen и Google SafeBrowsing — блокировать вредоносные сайты без ложных срабатываний, когда каждую неделю в сети появляются миллионы новых доменов.
Выводы
Разработчикам веб-приложений, пожалуйста, следуйте всем лучшим практикам, об этом стоит умолять:
- Размещайте приложения и контент под доверенным доменным именем (например,
cloudflare.com/payилиpay.cloudflare.com). Если новое имя всё же необходимо, давайте на него прямую ссылку со страницы доверенного домена. - Показывайте релевантную информацию о безопасности в доверенном месте, когда просите пользователя принять решение, связанное с безопасностью.
- Сделайте сообщение о мошенничестве максимально простым, прямо в контексте (например, на странице запроса разрешений).
- Тестируйте процессы сообщения о проблемах безопасности, чтобы убедиться, что они отслеживаются и работают корректно.
Пользователям: стоит быть осторожнее. Думайте перед тем, как кликнуть, а если ничего не помогает — просто подождите.
Специалистам по безопасности: никогда не вините жертву — у неё невыполнимая задача.