Hacker News Digest

В начале 2025 года исследователи обнаружили криптографические уязвимости в реализации FourQ от Cloudflare в библиотеке CIRCL. Проблемы были сообщены через HackerOne в марте и напрямую в Cloudflare после слабого ответа команды. FourQ — эллиптическая кривая с 128-битной безопасностью от Microsoft Research, работающая над расширением простого поля и подходящая для систем с ограниченными ресурсами.

Уязвимость связана с атаками на недействительные точки, когда сервер выполняет вычисления без проверки валидности точек на кривой. В протоколе ECDH это позволяет атакующему использовать точки с гладким порядком подгруппы, значительно упрощая восстановление секретного ключа. Cloudflare признала проблемы и исправила их после уведомления.

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

Telegram’s end-to-end encryption is vulnerable to sophisticated attacks that could enable large-scale surveillance. Researchers demonstrated that an attacker can exploit weaknesses in Telegram’s MTProto2.0 protocol to recover encryption keys with high probability using relatively few queries. This attack leverages the protocol’s padding mechanism, highlighting a critical design flaw. While official clients may be safer due to open-source scrutiny, third-party clients could be compromised, making this a significant threat. The study also proposes a simple fix to the padding mechanism that would mitigate this risk, suggesting that Telegram’s current encryption needs urgent revision to prevent potential state-level exploitation.

• Обсуждение охватывает уязвимости и риски безопасности в Telegram, особенно в отношении шифрования и возможных бэкдоров.
• Подчеркивается, что атаки требуют скомпрометированного клиента, что значительно снижает непосредственную угрозу для большинства пользователей.
• Отмечается, что сквозное шифрование (E2E) в Telegram по умолчанию отключено для большинства чатов, что увеличивает риски.
• Указывается, что существуют критические уязвимости в реализации шифрования Telegram (MTProto), делая его менее надежным по сравнению с конкурентами.
• Подчеркивается, что даже при использовании E2E, архитектура "клиент-сервер" и зависимость от доверенного сервера представляют фундаментальные риски.

Разработчик выложил на Hacker News фреймворк на C, и я, как исследователь безопасности, сразу заметил три классические ошибки: не проверяемый Content-Length, переполнение при копировании тела запроса и переполнение при записи ответа. Пример кода показывает, как непроверенное поле Content-Length используется как размер для malloc и memcpy, что может привести к утечке памяти или чтению за пределы буфера. Подобные проблемы встречаются везде, где C-фреймворки принимают ввод из сети или файловой системы.

• Обсуждение крутится вокруг того, что «хороший код на C» должен минимизировать выделение памяти и избегать atoi() и strdup() без проверки ошибок, что приводит к уязвимостям.
• Участники спорят о том, насколько критичны эти проблемы в контексте обучения и использования ИИ-помощи, и о том, что новички в C могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

Обнаружена первая вредоносная реализация MCP-сервера в дикой природе — пакет postmark-mcp, который с версии 1.0.16 тайно копирует все отправляемые письма на внешний сервер злоумышленника. Пакет скачивался 1500 раз в неделю и интегрировался в рабочие процессы разработчиков, получая полный доступ к почтовым данным, включая сбросы паролей, конфиденциальные документы и финансовые отчеты.

Атака основана на имперсонации: злоумышленник скопировал код официального репозитория Postmark, добавил скрытую строку BCC и опубликовал под тем же именем в npm. Уязвимость оставалась незамеченной, так как MCP-серверы работают вне периметра безопасности, обходя системы контроля DLP и инвентаризации активов. Это демонстрирует растущие риски supply-chain-атак через инструменты ИИ, которые получают привилегии без должной проверки.

• Участники обсуждают риски использования сторонних пакетов и инструментов, проводя параллели с историческими проблемами безопасности, такими как уязвимости в почтовых клиентах или SQL-инъекции.
• Высказываются предположения, что инцидент с пакетом postmark-mcp мог быть не злонамеренной атакой, а случайной ошибкой разработчика, оставившего отладочный код.
• Поднимается вопрос о доверии к ИИ-инструментам и MCP-серверам, которые получают чрезмерные права доступа к данным без должного контроля со стороны пользователей.
• Критикуется практика публикации статей, обработанных ИИ, что затрудняет восприятие и проверку фактов, а также общая культура безопасности в разработке, где скорость часто важнее надежности.
• Обсуждается ответственность платформ (например, npm) и необходимость более строгих правил для предотвращения подмены пакетов и supply chain-атак.