Атака на поставки @ctrl/tinycolor: разбор инцидента

Злоумышленник добавил вредоносный workflow в GitHub Actions общего репозитория и похитил npm-токен с правами публикации. С помощью этого токена были опубликованы вредоносные версии 20 пакетов, включая @ctrl/tinycolor.

Мой аккаунт GitHub и репозиторий @ctrl/tinycolor не были скомпрометированы напрямую. Не использовался фишинг, на моём компьютере не устанавливались вредоносные пакеты. GitHub и npm оперативно отреагировали, удалив зловредные версии. Я выпустил чистые версии пакетов для очистки кэшей.

Как это произошло

Раньше я участвовал в проекте angulartics2 — общем репозитории, где у нескольких человек были права администратора. Там остался секрет GitHub Actions — npm-токен с широкими правами на публикацию.

Злоумышленник принудительно отправил ветку Shai-Hulud в angulartics2 с вредоносным workflow. Workflow запустился сразу после отправки (без проверки, так как у collaborator были права администратора) и украл npm-токен. С помощью украденного токена атакующий опубликовал вредоносные версии 20 пакетов.

Планы на будущее

Сейчас я использую semantic-release с GitHub Actions для публикации. Моя цель — перейти на Trusted Publishing (OIDC) в npm, чтобы полностью отказаться от статических токенов. Однако интеграция с semantic-release ещё в разработке.

Для небольших пакетов я продолжу использовать semantic-release, но с ужесточённым контролем: никаких новых участников, отдельные npm-токены с правами только на публикацию конкретного пакета.

Я планирую и дальше использовать pnpm, который блокирует неавторизованные postinstall-скрипты, и изучу новую настройку minimumReleaseAge.

Пожелания к системе публикации

В идеале хотелось бы иметь в npm единый переключатель для принудительного использования Trusted Publishing (OIDC) для всех моих пакетов. Такой же переключатель блокировал бы любые релизы без provenance, обеспечивая безопасность на уровне аккаунта. Также хотелось бы иметь встроенную поддержку semantic-release с OIDC и provenance, чтобы статические токены больше не требовались.

Кроме того, было бы удобно иметь безопасный вариант публикации с подтверждением человека прямо в интерфейсе GitHub: защищённый workflow_dispatch, использующий 2FA GitHub для удовлетворения требованиям двухфакторной аутентификации без необходимости публиковать со своего компьютера.

• Предлагается использовать ручные релизы и многоэтапные проверки для публикации пакетов вместо полной автоматизации CI/CD.
• Обсуждаются недостатки долгоживущих токенов и предлагается использовать Trusted Publishing с короткоживущими токенами или OIDC.
• Поднимается вопрос о необходимости встроенной MFA (двухфакторной аутентификации) для подтверждения публикации в CI-системах.
• Предлагается разделить процесс на загрузку пакета и его публикацию для пользователей, чтобы повысить контроль.
• Обсуждается идея использования подписей нескольких авторов или проверки подписей коммитов для обеспечения безопасности.
• Отмечается сложность настройки безопасных машинно-машинных потоков (OIDC) и необходимость более простых решений.
• Упоминается, что многие разработчики игнорируют вопросы безопасности до момента взлома и необходимы системные изменения.

Как работает OAuth
Вместо передачи логина-пароля стороннему приложению OAuth выдаёт токен доступа — персональный «ключ» для конкретного пользователя. Приложение использует его, чтобы действовать от имени пользователя без доступа к его паролю.

Классический поток

1. Пользователь нажимает «Подключить банк» в YNAB.
2. YNAB открывает браузер с URL провайдера (например, банка), куда добавляет client_id, redirect_uri, scope и случайный state.
3. Пользователь логинится у провайдера и разрешает доступ.
4. Провайдер перенаправляет обратно в YNAB с кодом авторизации.
5. YNAB обменивает код на токен доступа через безопасный back-end-запрос.
6. С токеном YNAB запрашивает данные счёта.

PKCE
Для мобильных и SPA добавляют code_challenge и code_verifier, чтобы перехват кода не дал злоумышленнику токен.

Refresh-токены
Короткоживущий access token можно обновлять долгоживущим refresh token без повторного логина.

Итог
OAuth разделяет аутентификацию и авторизацию: пользователь доверяет провайдеру, провайдер — приложению, приложение получает минимально необходимые права.

• Участники жалуются, что OAuth/OIDC кажутся простыми, но реальная реализация требует чтения спецификаций и RFC, а поверхностных гайдов мало.
• Несколько человек подтвердили: приходится самим собирать знания из RFC, OIDC-документов и собственных заметок.
• Упомянуты полезные ресурсы — гайд Alex Bilbie, книга Aaron Parecki, страницы Mozilla и RFC-примеры.
• PKCE считается не «менее безопасным», а способом защитить целостность потока; просят отдельный материал о нём.
• Критика стандарта: OAuth 2.0 «скелет протокола», с множеством опциональных частей и историческими уязвимостями.

Кратко о PR #3899
Добавлена поддержка SSO через OpenID Connect (OIDC) в Vaultwarden.

• Что нового

  • Авторизация через внешний OIDC-провайдер (Keycloak, Azure AD, Google и др.).
  • Автоматическое создание/обновление пользователей при первом входе.
  • Настройка через переменные окружения: SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID, SSO_CLIENT_SECRET.
  • Поддержка PKCE и offline_access для refresh-токенов.

• Как использовать

  1. Указать параметры OIDC в .env.
  2. Включить SSO в админ-панели.
  3. Пользователи входят кнопкой «Login with SSO».

• Ограничения

  • Только веб-клиент; мобильные/CLI пока без SSO.
  • Не работает с двухфакторной аутентификацией Vaultwarden (используйте MFA у провайдера).

• Проверено

  • Keycloak, Auth0, Azure AD, Google Workspace.

PR готов к слиянию; дальнейшие улучшения (SAML, группы) в roadmap.

• Внедрённый SSO в Vaultwarden в первую очередь нужен корпоративным и командным средам, где упрощает автоматическое добавление/удаление пользователей и управление доступом к коллекциям паролей.
• Для личного или семейного использования польза минимальна: мастер-пароль всё равно требуется, а SSO не заменяет шифрование.
• Многие админы некоммерческих и малых организаций рады возможности подключить единый OIDC-провайдер вместо ручного приглашения и отслеживания активных волонтёров/сотрудников.
• Часть пользователей обеспокоена безопасностью: просят аудитов, контроля образов Docker и зависимостей.
• SSO не отменяет мастер-пароль: он по-прежнему нужен для расшифровки хранилища, а SSO лишь аутентифицирует пользователя.

Я использую Tailscale около четырех лет, чтобы объединять свои устройства, серверы и приложения. Расскажу, как применяю его, о полезных фишках и подводных камнях.

Tailscale — это по сути оркестрация WireGuard с приятными надстройками. Продукт по подписке, но у него очень щедрый бесплатный тариф для личного использования. Клиенты — с открытым исходным кодом; есть и сторонний контроль-сервер Headscale, если не хочется облака.

Базовое подключение

Tailscale позволяет легко связать устройства, даже если они не торчат в интернет. Ставите клиент на телефон/компьютер/сервер/Raspberry Pi, авторизуете — и он общается с остальными по приватным IP Tailscale.

Это обычная идея VPN, но здесь всё просто: не нужно настраивать сеть и раздавать ключи — ставите клиент и логинитесь.

Например, мой домашний автоматизационный сервис на Raspberry Pi за двумя роутерами: поставил Tailscale, вошел — и сразу могу SSH с ПК или телефона, даже из разных сетей.

Есть особая поддержка SSH: Tailscale принимает подключения на 22 порт с tailnet и сам выполняет аутентификацию. Никаких ключей и паролей: вошли в Tailscale — можете войти на машину. Особенно удобно с телефона, где управлять ключами неудобно.

Можно публиковать не целую машину, а отдельные сервисы как отдельные узлы tailnet: есть официальный Docker-образ, Go-библиотека, и сторонние инструменты (например, мои Centauri и tsp).

Это больше, чем VPN

Чтобы не запоминать IP, я долго вручную добавлял DNS-записи. Перешел на MagicDNS — он автоматически создает DNS по имени машины.

Сначала меня смущало, что он меняет резолвер на устройствах — “слишком магично”. Разобрался, привык. Можно задать и свой upstream DNS. Я везде использую NextDNS, и Tailscale сам настраивает его на всех устройствах.

Помимо коротких имен, есть формат machine.your-tailnet.ts.net. Его можно «перебросить» на глобальную маршрутизацию и получить TLS-серты.

Нужно быстро показать локальный сервис? Включите funnel: tailscale funnel 127.0.0.1:8080 Без доп. опций сервис будет доступен по HTTPS:443. Дайте ссылку https://machine.your-tailnet.ts.net — трафик пойдет на ваш 8080. У посетителей Tailscale не нужен. Пользуюсь редко, но удобно.

Команда serve делает похожее, но только внутри tailnet. Так же работает Docker-образ Tailscale для публикации обычного сервиса. Для тестов с телефона: вместо танцев с Wi‑Fi/локалхостом/IP просто запускаю tailscale serve и захожу с устройства.

• Включение tailscale funnel мгновенно привлекает ботов, сканирующих новые HTTPS-сертификаты из CT-логов.
• Пользователи делятся альтернативами: Headscale, NetBird, Nebula, Zerotier и «чистый» WireGuard.
• Mullvad-интеграция позволяет использовать выходные ноды Tailscale для смены геолокации.
• Настоятельно не рекомендуют запускать dev-серверы и OIDC-серверы через funnel из-за риска блокировки и атак.
• Чтобы не светить домены, применяют wildcard-сертификаты и нестандартные порты.
• Tailscale собирает телеметрию по умолчанию; её можно отключить, но это не анонимный VPN.