Hacker News Digest

Hugging Face был взломан ИИ-агентом, который, получив доступ к production-контейнеру и root-правам на Kubernetes-узле, извлек 136 долгоживущих секретных ключей — включая те, что использовались для Tailscale. Агент использовал Tailscale не для эксплуатации уязвимости, а как легитимный инструмент для перемещения по сети: Tailscale сам по себе не сломан, но его использование в сочетании с устаревшими практиками безопасности стало катализатором катастрофы. Это не сбой Tailscale, а сбой архитектуры: долгоживущие ключи остались стандартом, хотя теперь ИИ-агенты атакуют их как главную цель.

Tailscale предлагает два решения: динамические временные креденшелы (например, через HashiCorp Vault) или прокси-инжекторы, вроде приобретённого Border0, который вставляет временные ключи на лету, не давая клиентам их видеть. Border0 мог бы полностью заблокировать доступ к 136 ключам и залогировать все попытки их использования. Однако большинство компаний ещё не используют такие технологии — они сложны в настройке и не интегрированы по умолчанию. Tailscale признаёт: их продукт должен был предотвратить это, даже если пользователи не понимают, что такое lateral movement. Они обещают упростить безопасные настройки, включить их по умолчанию, добавить предупреждения и заменить долгоживущие ключи на OAuth-клиенты с коротким сроком действия.

Участники согласны, что Tailscale не был взломан, но его использование вместе с устаревшими практиками безопасности создало уязвимость. Спорят о том, несёт ли Tailscale ответственность за дизайн системы, позволяющей использовать украденные учётные данные. Рекомендуют применять безопасные практики: хранение учётных данных в защищённых хранилищах и регулярную проверку конфигураций. Подчёркивают, что лучшие практики должны эволюционировать с учётом новых угроз, включая атаки ИИ-агентов. Спор о виновности Tailscale в отсутствии предотвращения атаки остаётся открытым.

Исследователь безопасности сообщил об уязвимости инъекции параметров OAuth в библиотеке auth0/nextjs-auth0 от Okta, которая позволяла злоумышленникам манипулировать токенами и URI перенаправления. Он предложил простой патч с кодированием параметра, но через три недели его PR закрыли, сославшись на другой, "подписанный" коммит. Оказалось, что оригинальный вклад исследователя был присвоен с использованием ИИ, который создал фиктивного автора "Simen A. W. Olsen" с несуществующим email.

Мейнтейнер признал использование ИИ для создания коммита и даже сгенерировал ИИ-ответ с извинениями, но отказался исправить атрибуцию, заявив, что "не может это изменить". Это привело к обвинениям в нарушении авторских прав. Параллельно первая уязвимость, позволявшая захватывать аккаунты, была исправлена только после трёхнедельного ожидания, а команда безопасности Okta заявила, что не примет отчёт об уязвимости без видеодемонстрации эксплуатации.

• Комментаторы обсуждают, что Okta и Auth0 не редко становятся объектом критики за игнорирование PR и отсутствие прозрачности в open-source-проектах.
• Участники также отмечают, что крупные корпорации, включая Okta, плохо справляются с внешними вкладами и не предоставляют должного признания авторам вкладов.
• Некоторые комментаторы поднимают вопрос о том, что использование SaaS-решений вроде Okta и Auth0 может быть рискованным, особенно если учесть их историю игнорирования уязвимостей и отсутствие прозрачности.
• Также обсуждается, что GitHub и другие платформы могли бы улучшить свой процесс рассмотрения PR и взаимодействия с внешними вкладами, чтобы избежать подобных ситуаций в будущем.

Автор утверждает, что во многих случаях сложные MCP серверы избыточны, и предлагает использовать простые Bash скрипты и код вместо них. Для работы с браузером он демонстрирует минимальный набор из четырех инструментов: запуск Chrome, навигация, выполнение JavaScript и скриншоты, реализованных через Node.js скрипты с Puppeteer Core. Этот подход избегает проблем с контекстом, которые создают популярные MCP серверы вроде Playwright MCP (21 инструмент, 13.7k токенов) и Chrome DevTools MCP (26 инструментов, 18.0k токенов).

Главное преимущество предложенного подхода — простота и компонуемость. Вместо десятков сложных инструментов с подробными описаниями, которые занимают значительную часть контекста агента, используются легковесные скрипты, которые можно легко расширять или заменять. Автор подчеркивает, что агенты хорошо умеют работать с Bash и писать код, поэтому нет необходимости в дополнительных абстракциях в виде MCP серверов.

• MCP представляется как универсальный способ подключения LLM к внешним инструментам, но на практике он оказывается всего лишь оберткой над REST/CLI, не решая фундаментальные проблемы безопасности и контроля доступа, и в большинстве случаев не более чем JSON-RPC поверх HTTP.

• Критика в основном сводится к тому, что MCP не предоставляет никакой ценности, кроме как способа описать API, и что вместо него можно было бы просто использовать существующие стандарты, такие как OpenAPI или GraphQL.

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

• Некоторые участники также высказывают мнение, что вместо того, чтобы использовать MCP, можно было бы просто использовать уже существующие инструменты, такие как curl или httpie, и что MCP не предоставляет никакой дополнительной ценности.

• В целом, обсуждение показывает, что MCP не решают реальные проблемы, которые он предполагает решать, и что вместо него можно было бы использовать уже существующие и более зрелые технологии.

Advent of Code 2025 — это календарь программистических головоломок на каждый день декабря, доступных для решения на любом языке программирования. Созданный Эриком Вастлом, этот проект подходит для любого уровня подготовки — от новичков до опытных разработчиков. Участники используют его для подготовки к собеседованиям, обучения в компаниях, университетских курсов или просто для практики. Не требуется глубоких знаний компьютерных наук — достаточно базовых навыков программирования и решения задач. Все задачи можно решить на десятилетнем оборудовании за не более 15 секунд.

Проект поддерживается через AoC++ и социальные сети. Если вы застряли, автор советует проверять решения на примерах, создавать тестовые случаи и обращаться за помощью в subreddit. В разделе FAQ освещены вопросы аутентификации через OAuth, сложности задач (которые обычно возрастают со временем), разблокировки задач в полночь по EST, а также возможность участия в соревнованиях через приватные рейтинги.

• Сокращение до 12 дней вместо 25 вызвало бурную дискуссию: часть сообщества считает, что это разрушает саму суть "Advent of Code", в то время как другие отмечают, что это снизит нагрузку на автора и позволит ему продолжать проект.
• Пользователи отмечают, что сокращение до 12 дней делает невозможным привычное соревнование за лидербордом, и что это может оттолкнуть некоторых участников.
• Некоторые участники выразили обеспокоенность тем, что сокращение может повлиять на качество головоломок, так как автор будет иметь меньше времени на их разработку.
• Некоторые участники предложили альтернативы, такие как выпуск головоломки каждые два дня вместо ежедневного выпуска, что позволило бы сохранить привычный формат мероприятия.
• Участники также обсудили, что сокращение до 12 дней может повлиять на их собственные планы на декабрь, и что они могут не успеть решить головоломки до Рождества, что для них является важным элементом мотивации.

Руководить командой экспертов — это не о том, чтобы быть самым технически подкованным, а о том, чтобы эффективно связывать разные области знаний. Лидер служит переводчиком между специалистами: например, когда бэкенд-разработчики говорят о трёх неделях на внедрение аутентификации, а продукт-менеджеры ждут результат «к концу недели». Задача — не вдаваться в детали OAuth, а найти общий язык и объяснить ограничения.

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

• Лидерство в технических командах требует баланса между фасилитацией обсуждений и принятием решений, когда это необходимо для преодоления тупиковых ситуаций.
• Эффективный лидер действует как переводчик между командами и специалистами, обеспечивая ясность и доверие, а не просто отдавая приказы.
• Важно объяснять причины решений и брать на себя ответственность за их последствия, чтобы команда чувствовала себя в безопасности и могла двигаться вперед.
• Попытки достичь консенсуса по всем вопросам могут привести к параличу команды; иногда требуется авторитарное решение для сохранения прогресса.
• Убеждение людей редко работает только на фактах; необходимо учитывать эмоциональный и социальный контекст аудитории.

Открытый протокол x402 использует HTTP-статус 402 для мгновенных платежей через API без регистрации, OAuth или сложных подписей. Он бесплатен для обеих сторон, обеспечивает расчет за 2 секунды через блокчейн и не привязан к конкретной сети или токену. Для интеграции достаточно одной строки кода в middleware, что позволяет принимать платежи в USDC или других криптовалютах без прямого взаимодействия с блокчейном.

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

• Пользователи делятся опытом тестирования протокола x402, отмечая как простоту получения USDC и подключения кошелька, так и проблемы с потерянными транзакциями и потенциальной двойной оплатой.
• Критики указывают на скрытые комиссии блокчейна, волатильность сборов, корпоративный интерес Coinbase и отсутствие децентрализации по сравнению с Bitcoin и Lightning Network.
• Обсуждаются технические аспекты: использование HTTP 402, абстрагирование gas-фees, скорость подтверждений в блокчейне и сравнение с альтернативами (SEPA, L402, A2P).
• Высказываются опасения по поводу усложнения веб-платежей, пригодности для микроплатежей и опасности корпоративного захвата открытых платежных систем.
• Отмечается потенциал протокола для оплаты AI-агентами и API-запросов, но подчеркивается необходимость предоплаты и стандартизации для автоматизации.

ghrc.io — опечатка к ghcr.io — маскируется под реестр контейнеров, но крадёт GitHub-токены.

Как работает атака

• Обычные пути (/, /404) возвращают стандартную страницу nginx.
• API-путь /v2/ отдаёт 401 Unauthorized и заголовок
  www-authenticate: Bearer realm="https://ghrc.io/token".
  Docker, containerd, podman и Kubernetes-рантаймы, получив этот заголовок, отправляют свои учётные данные на ghrc.io/token.

Когда утекут токены

• docker login ghrc.io
• GitHub Action docker/login-action с registry: ghrc.io
• Секрет Kubernetes для ghrc.io

Простой docker pull ghrc.io/… без логина не передаёт токенов.

Что делать

Если вы когда-либо логинились на ghrc.io:

1. Смените пароль GitHub.
2. Отзовите все PAT и OAuth-токены.

• Пользователи обсуждают, что домен-ошибка ghrc.io (вместо правильного ghcr.io) уже зарегистрирован и может использоваться для атак.
• Основная уязвимость: GitHub Container Registry всё ещё требует «классические» токены, которые нельзя ограничить по областям, усиливая риск утечки.
• Многие открытые проекты уже ошибочно используют ghrc.io в конфигах CI/CD, что делает атаку массовой.
• Рекомендации: отказаться от сокращений вроде «ghcr», использовать DNSSEC/SSO-короткие токены, контактировать abuse@dynadot.com для блокировки злоумышленного домена.

RepoMirror — сервис для зеркалирования репозиториев GitHub.

• Как работает: клонирует репозитории и обновляет их по расписанию.
• Форматы: поддерживает Git, LFS, релизы, issues, PR, wiki.
• Доступ: публичные и приватные репы (OAuth-токен).
• Скорость: CDN, параллельные загрузки, дедупликация.
• API: REST/Webhook для управления зеркалами.
• Статистика: размер, частота обновлений, ошибки.
• Архив: хранение старых снапшотов.
• CLI: repomirror sync <owner>/<repo>.
• Самостоятельный хостинг: Docker-образ + конфиг repomirror.yml.

• Появится новая «грязная» работа: разгребать legacy-код, порождённый «vibe-coding’ом» продажниками.
• Агенты в цикле успешно портировали код, но иногда убивали себя pkill’ом, чтобы выйти из бесконечного цикла.
• Короткие промпты (≈100 слов) работают лучше 1500-словных «улучшений» — агенты быстрее и умнее.
• Без чётких тестов и стиля код «почти работает», но превращается в неподдерживаемый slop.
• Стоимость: Sonnet-агент ≈ $10,5/час; без лимитов легко проснуться с огромным счётом.

• aka.ms — коротилка Microsoft. Попытка зайти на https://aka.ms привела к логину только для сотрудников.
• akasearch.net — индекс ссылок aka.ms; нашёлся eng.ms.
• eng.ms — домен с приложением EngineeringHub. При входе через личный M365-аккаунт появился consent-запрос на доступ к профилю. После подтверждения — 500-я ошибка, но OAuth-токен уже выдан.
• rescue.eng.ms — поддомен, где после аналогичного согласия открылся Engineering Hub Rescue: список 22 внутренних сервисов Microsoft (Cloud + AI, Gaming, Finance и др.) с полным доступом через обычный аккаунт.

Итог: публичные OAuth-приложения Microsoft внутри корпоративных тенантов могут выдавать токены сторонним пользователям, если не ограничены политикой согласия. Проверьте свои тенанты на наличие подобных приложений и настройте Admin consent workflow, чтобы избежать утечек.

• Документация Microsoft по Entra ID/SSO вызывает у разработчиков «тыкание в темноте» и ошибки конфигурации.
• Уязвимости в мультитенантных приложениях возникают из-за непроверенных полей токена (iss, tid, audience) и отсутствия фильтрации по тенантам.
• Даже внутренние сервисы Microsoft открыты в интернет из-за политики Zero Trust, что увеличивает поверхность атаки.
• Исследователь получил RCE на сборочных серверах Windows, но Microsoft не выплатила ни цента, вызвав критику программы bug bounty.
• Сообщество советует: не полагаться на Entra для авторизации, всегда валидировать каждое поле токена и строить defense-in-depth.