Hacker News Digest

• Во время сбоя AWS вчерашний день несколько человек сообщили, что их консоль внезапно переключилась на другой аккаунт, что вызвало обеспокоенность о возможном компромете учетных данных.
• Участники обсуждения отметили, что в подобных случаях злоумышленник может ждать удобного момента, чтобы скрыть свои действия в шуме, вызванном сбоем.
• Были упомянуты прецеденты, когда вредоносное ПО или фишинговые атаки используются в подобных ситуациях.
• Также было отмечено, что AWS, как и другие провайдеры, имеет инструменты для проверки и предотвращения подобных инцидентов.

• Сообщение о фальшивом собеседовании вызвало волну обсуждений, в которых участники делились историями о похожих попытках обмана, а также обсуждали, как распознавать и избегать таких ситуаций.
• Участники обсуждения подчеркнули важность проверки подлинности компаний и лиц, с которыми вы имеете дело, особенно в контексте удаленной работы и криптовалют.
• Были выдвинуты предложения о том, что следует всегда использовать виртуальные машины или контейнеры для изоляции кода, который вы не полностью доверяете, и никогда не запускать непроверенный код на основной машине.
• Также обсуждались инструменты и практики, которые могут помочь в предотвращении таких атак, включая инструменты для изоляции и контроля доступа к файловой системе и сети.

Разработчик приложения 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 целью стал crates.io.
• Рассылается письмо «Инцидент безопасности: взлом инфраструктуры».
• Просят перейти по ссылке и войти через «внутренний SSO» — это фейк.
• Сайт копирует GitHub-авторизацию, крадёт токены.
• Подделка заметна по домену, отсутствию HTTPS и странному URL.
• Настоящий crates.io никогда не просит войти через сторонние формы.
• Получили письмо — удалите, не кликайте; включите 2FA и проверьте токены.

• Фишинг снова в тренде: мошенники массово атакуют разработчиков через «сломанные» пакеты (npm, crates.io), подделывают e-mail от PayPal и GitHub.
• Самые опасные письма подписываются реальным доменом (paypal.com, github.rustfoundation.dev) и ведут на поддельный «внутренний» логин; звонки «от банка» тоже подменяют номер.
• Правило «ноль доверия»: не кликайте, не звоните по указанным ссылкам/номерам; заходите на сайт вручную или набираете официальный номер из надежного источника.
• Даже опытные разработчики чуть не ведутся: письмо выглядит срочным, без опечаток, с корректным логотипом и SSL, но просит «подтвердить» учётку на стороннем домене.
• Защита: включайте passkey / 2FA, не вводите пароль на незнакомых доменах, после любого изменения безопасности временно блокируйте публикацию пакетов.

Коротко: в 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 и магссылкам как более безопасным и удобным компромиссам.

• Обсуждение о том, что один из корпоративных Salesforce-инстансов Google был скомпрометирован через вишинг-атаки (UNC6040), с кратковременной утечкой контактных данных и заметок по малому и среднему бизнесу; официальный тон смягчает масштаб, что вызывает скепсис.
• Комментаторы сомневаются в формулировках “лишь базовые и публичные данные”, предполагая, что ценность для злоумышленников была реальной (возможны вторичные схемы, например мошенничество с биллингом).
• Многих удивляет, что Google использует Salesforce; объяснения: историческое наследие, быстрые поглощения, а также предпочтения команд продаж и маркетинга к индустриальным стандартам вместо внутренних инструментов.
• Приводятся истории о неудачных внутренних CRM у Google: баги, нехватка функций, нежелание инженеров поддерживать; продажи и PM часто продавливают Jira/Salesforce ради скорости найма и онбординга.
• Отмечается культурный сдвиг: замена внутренних решений “джанковыми” шаблонными процессами Salesforce; внутренние инструменты больше для инжиниринга.
• Уточнения: у Google десятки тысяч сотрудников в продажах/маркетинге; часть саппорт-систем GCP ранее зависела от Salesforce; выбор строить/покупать/партнериться по CRM оценивался и часто оказывался экономически нецелесообразным для собственной разработки.
• Общий вывод: инцидент — результат классической социальной инженерии, а не технического взлома; реакция компании стремится минимизировать восприятие ущерба, вызывая дискуссии о прозрачности и рисках использования сторонних SaaS.