Hacker News Digest

Джонатан Кларк стал жертвой целевой фишинговой атаки в январе 2025 года, за четыре месяца до публичного признания Coinbase утечки данных. Мошенники обладали его полными персональными данными, включая номер социального страхования и точный баланс биткоина, что указывало на компрометацию внутренней базы Coinbase. Кларк немедленно предоставил компании детальный технический отчет с записями разговора и доказательствами, но не получил ответов на свои вопросы в течение четырех месяцев.

Coinbase публично признала утечку только в мае 2025 года, когда злоумышленники потребовали выкуп в $20 млн. Позже выяснилось, что сотрудники аутсорсинговой компании TaskUs в Индии продавали клиентские данные, включая имена, адреса, SSN и балансы счетов. Финансовые потери оцениваются в $180-400 млн, а более 200 сотрудников TaskUs были уволены. Кларк утверждает, что Coinbase знала об утечке задолго до официального признания, игнорируя его предупреждения.

• Reuters и другие СМИ сообщают, что Coinbase знал о утечке данных клиентов ещё в январе, но не уведомил клиентов и SEC, что вызвало волну критики.
• Пользователи жалуются на фишинговые звонки, в которых мошенники знают их точные балансы и личные данные, что указывает на утечку данных Coinbase.
• Комментаторы подчеркивают, что Coinbase не сообщил о взломе в течение 4 месяцев, несмотря на то, что SEC требует раскрытия таких инцидентов в течение 4 дней.
• Некоторые пользователи утверждают, что Coinbase не только не уведомил клиентов о взломе, но и не предпринял никаких действий для защиты их данных.
• В то же время, другие участники обсуждения подчеркивают, что Coinbase не несет ответственности за безопасность личных данных клиентов, если они сами не соблюдают основы криптовалютной безопасности.

Разработчик приложения Inkdrop получил пугающее письмо от пользователя, сообщавшего о проблеме с cookie consent, блокирующим доступ к сайту. Странно было то, что сайт приложения вообще не использует cookie consent — отслеживание и реклама отсутствуют. В ответ на запрос автора уточнить детали, пользователь прислал ссылку на "скриншот", которая вела на страницу с капчей и требованием выполнить вредоносную команду в терминале.

Команда, скопированная в буфер обмена, скачивала и выполняла удалённый shell-скрипт. Хотя Gmail пометил второй ответ как спам, первый выглядел вполне нормально. Такие фишинговые атаки становятся всё более изощрёнными, часто имитирующие реальные запросы поддержки. Даже на форумах автора появляются подозрительные посты, написанные, вероятно, ИИ, которые выглядят естественно, но содержат скрытые угрозы.

• Сообщения в треде подчеркивают, что фишинг становится всё более изощрённым: злоумышленники маскируют вредоносные ссылки под видом Google Sites, Cloudflare, Dropbox и т.д., а также используют фейковые сервисы поддержки, чтобы выманить у пользователей конфиденциальные данные.
• Участники обсуждения отмечают, что даже технически подкованные пользователи могут быть обмануты, если злоумышленник использует правдоподобные, но поддельные домены и визуально неотличимые от легитимных сервисов ссылки.
• Обсуждение также поднимает вопрос о том, что даже если пользователь не ведётся на кликбейт, то вредоносное ПО может быть скачено и запущено в фоновом режиме, если пользователь просто открыл вредонусную страницу в браузере.
• Участники также обсуждают, что в условиях, когда всё большее и большее количество людей полагаются на ИИ-ассистенты вроде ChatGPT, фишинг может стать ещё более изощрённым и трудным для обнаружения.
• Наконец, участники обсуждения подчеркивают, что важно помнить, что никакие легитимные сервисы не будут просить вас запустить что-то в терминале и что всегда стоит проверять URL-адреса, особенно если они ведут на сайты, которые вы не ожидаете увидеть.

25 сентября 2025 года Google Safe Browsing внезапно заблокировал весь домен statichost.eu как «обманчивый» — даже поддомены, включая пользовательские сайты клиентов. Почти шесть часов ни один браузер на Chromium-основе не открывал ни одну страницу на домене без жёсткого предупреждения. Это затронуло и сам сайт компании и все её поддомены, включая личные сайты клиентов.

В итоге, Google Search Console показал, что причиной стало то, что на платформе появились фишинговые сайты. Вместо того, чтобы сообщить владельцу и дать ему возможность удалить их, Google просто внёс весь домен в чёрный список.

Это стало поводом для публикации, в которой компания подчеркнула, что теперь она будет выдавать всем новым сайтам домен statichost.page, чтобы избежать повторения ситуаций в будущем.

• Google Safe Browsing блокирует сайты, если на них размещают фишинг-контент, но при этом не всегда ясно, кто именно блокирует — Google или другие сервисы.
• Провайдеры, которые не разделяют пользовательский контент на отдельном домене, рискуют, что весь их домен попадёт в чёрный список.
• Public Suffix List помогает браузерам и поисковикам различать, где заканчивается домен первого уровня и начинается поддомен.
• Размещая пользовательский контент на отдельном домене, можно избежать риска, что весь домен попадёт в чёрный список.

Этот инструмент превращает любую ссылку в подозрительно выглядящий URL, который перенаправляет на исходный адрес, не причиняя реального вреда. Он работает по принципу редиректа, аналогично сервисам сокращения ссылок, но с противоположной целью — сделать адрес максимально похожим на фишинговый, чтобы проверить бдительность пользователей или пошутить над коллегами.

Вы можете выбрать тематику домена (например, криптовалюты, финансы или знакомства) и длину URL, от короткой до абсурдно длинной. Инструмент просто меняет внешний вид ссылки, сохраняя её функциональность, что делает его забавным способом подчеркнуть важность проверки URL перед переходом.

• Пользователи делятся опытом, как корпоративные IT-системы (Microsoft Safelink, MimeCast) переписывают ссылки в письмах, делая их подозрительными и нечитаемыми, что парадоксально снижает безопасность.
• Обсуждаются юмористические и потенциально опасные аспекты сервиса, который намеренно генерирует URL-адреса, выглядящие как фишинговые или вредоносные (например, cheap-bitcoin.online).
• Поднимается тема о том, что подобные инструменты могут использоваться для троллинга или рикреоллинга, но также предупреждается о рисках, включая возможность реального фишинга или проблем с IT-безопасностью на работе.
• Несколько комментаторов отмечают, что их корпоративные сети блокируют сгенерированные ссылки или подобные домены, что ограничивает использование сервиса.
• Упоминаются альтернативные методы создания подозрительных ссылок и приводятся личные забавные случаи из корпоративной практики, связанные с безопасностью и фишингом.

Приют для компьютерных мышей ЦЕРН

Мы вернулись! После происшествия в начале 2012 года нам удалось получить новое финансирование, и мы рады сообщить о повторном открытии приюта для компьютерных мышей ЦЕРН на лужайке перед Компьютерным центром ЦЕРН. Приют работает в будние дни с 8:30 до 17:30.

---

В сене... Едят... Пьют...

Обнимаются... Играют... Паникуют...

---

Сообщение от спонсора

«Остановись — Подумай — Кликни»...

...это основная рекомендация для безопасного интернет-серфинга и чтения email. Пользователи, следовавшие ей ранее, реже заражали компьютеры или компрометировали учётные записи. Однако слишком многие всё ещё кликают на вредоносные ссылки, подвергая риску свои системы.

Чтобы избежать кликов вообще, все пользователи ЦЕРН должны отключить компьютерные мыши и принести их в наш приют.

Помощь и информация:
https://cern.ch/Computer.Security или Computer.Security@cern.ch

Приют не несёт ответственности за содержание сообщения спонсора.

Отказ от ответственности:
Приют — некоммерческая организация, поддерживаемая сотрудниками ЦЕРН в свободное время. Пожертвования: чек на «CERN Animal Shelter for Computer Mice», CERN P.O. Box G19710, CH-1211 Geneva 23, или email Computer.Shelter@cern.ch

© Приют для компьютерных мышей ЦЕРН

• Обсуждается лингвистический нюанс: множественное число от компьютерной мыши — «mice» или «mouses».
• Ностальгия по «старому» интернету с его душевностью, whimsy и некоммерческим контентом.
• Критика современной корпоративной культуры в IT (FAANG) за отсутствие неформального общения.
• Шутливые отсылки к CERN, включая «приют для компьютерных мышей» и квантовые запутанные овцы.
• Проблема снижения качества продукции из-за оптимизации затрат.
• Воспоминания о конкретных моделях компьютерных мышей (Logitech PilotMouse, Sun mouse).
• Указание на то, что «старый» интернет всё ещё существует, но его сложнее найти.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

TL;DR
Автономные браузеры-агенты (Comet, Copilot, Comet) обещают делать покупки и управлять почтой без участия человека. Но в тестах они без сопротивления:

• купили часы в поддельном «Walmart»;
• ввели логин/пароль на реальном фишинговом Wells Fargo;
• выполнили скрытый PromptFix-скрипт (новая версия ClickFix), который через фальшивую капчу заставил агента установить вредоносное расширение и передать управление злоумышленнику.

Во всех случаях отсутствовали базовые защиты: браузеры не проверяли домены, не распознавали подозрительные формы и не запрашивали подтверждения у пользователя. Старые уловки работают, потому что ИИ доверчив и стремится «угодить» любой ценой.

Scamlexity — новая эра: мошенник обманывает не человека, а его ИИ-агента, а ущерб получает сам пользователь.

• Пользователи не верят, что ИИ-агенты способны безопасно покупать за них: финансовые риски, скам-сайты и отсутствие контроля пугают.
• Критики называют «agentic» новым хайп-словом, за которым скрывается ненадёжная система без реального «моата».
• Проблема усугубляется тем, что LLM не различают контент и команды, что делает инъекции и обман тривиальными.
• Некоторые видят пользу в рутинных закупках (молоко, витамины, повторяющиеся подписки), но только при полной прозрачности и доверии.
• Большинство считает, что пока агенты работают на корпорации, а не на пользователя, доверять им деньги нельзя.

Слишком многие сервисы используют такой вход:

• Введите email или телефон
• Сайт отправит 6‑значный код
• Введите код для входа

Пожалуйста, прекратите.

Почему это плохо для безопасности:

• Злоумышленник может отправить ваш email на легитимный сервис и заставить вас ввести присланный код в фишинговой форме. Вы не можете быть уверены, где именно нужно вводить код. Менеджеры паролей тут не помогают.
• Этот метод реально эксплуатируется: вход Microsoft для аккаунтов Minecraft использует такие коды, и уже множество аккаунтов было украдено (есть подтверждения на Reddit и YouTube, а также в документации Microsoft).

• Обсуждение критикует OTP по email (6-значные коды): уязвимость к фишингу через «партнёра-входа», спам-запросы на сброс пароля и навязывание пользователям вместо пароля/менеджеров паролей.
• Многие считают, что email-коды хуже UX: задержки, переключение аккаунтов, блокировки при путешествиях, навязчивая MFA/телефон, а также баги (отписка от рассылок ломает вход).
• Контраргументы: пароли тоже фишингуемы и часто слабые/повторяются; для нетехничных пользователей код/магическая ссылка понятнее.
• Предпочтения и альтернативы: магические ссылки вместо кодов (менее фишингуемы), TOTP, passkeys, соцлогин, менеджеры паролей, иногда даже IP-ограничения; просьбы дать выбор, а не форсить один метод.
• Безопасность email-OTP можно улучшать: сочетать короткий код и длинный одноразовый токен, строгие антифишинговые меры почтовых сервисов, ограничения на частоту запросов.
• Реальные негативные кейсы: принудительные схемы у банков/сервисов, невозможность входа без телефона, постоянные письма о сбросах, статические «коды» у некоторых приложений.
• В целом тренд: сервисы перекладывают риск на почту/Google; часть участников продвигает переход к passkeys и магссылкам как более безопасным и удобным компромиссам.