Hacker News Digest

Злоумышленники заявили о краже 10,6 ТБ данных из облачной платформы TiDB Cloud компании PingCAP — это 4 901 203 файла, включая полный контрольный слой продакшена. По их словам, выгрузка шла почти два месяца и оставалась незамеченной: 88 последовательных экспортов каждые шесть часов с 8 по 30 сентября, последний — в 06:02 UTC 30 сентября. Репликацию собственной базы данных TiDB Cloud они настроили через учётные данные, найденные в репозиториях самой компании: ключи сервисного аккаунта GCP и субъект Azure.

Среди похищенного — 180 046 организаций-арендаторов, 292 276 записей пользователей, 403 262 уникальных адреса электронной почты, 115 308 пар ключей API в открытом виде (42 612 активных), 20 645 574 SQL-запроса клиентов из редактора и Chat2Query, 102 003 766 подключений к шлюзу, 5 036 738 IP-адресов серверов заказчиков, 377 446 задач Jira, 433 928 контактов CRM, 92 ГБ данных о затратах AWS с метками арендаторов и 413 приватных репозиториев с исходным кодом. Также упоминаются 1 809 внешних конечных точек баз данных с учётными записями root и admin на хостах MySQL/Aurora заказчиков и 290 идентификаторов аккаунтов AWS.

Первый этап публикации — около 200 ГБ, доступен через торрент-файл размером 128,3 ГиБ. Атакующие подчёркивают, что PingCAP, будучи облачным провайдером, не заметил массовой выгрузки из AWS, GCP, Jira и Azure, хотя компания зарабатывает на обещании безопасности мультитенантной платформы.

Обсуждение указывает на катастрофический уровень операционной безопасности PingCAP: инженеры хранили production-учетные данные клиентов и ключи сервисных аккаунтов GCP и Azure в тикетах Jira и репозиториях. Это позволило атакующим настроить автоматическую репликацию данных в течение месяца. Сообщество ставит под сомнение заявления компании об отсутствии воздействия на данные, так как у хакеров есть полные дампы контрольного слоя. В споре о природе утечки @gregwebs считает, что утекли в основном метаданные, однако другие указывают на наличие SQL-логов с реальными данными клиентов. Проведенный ранее аудит NCC Group выявил разрыв между анализом кода и реальной безопасностью процессов. @kobieps отмечает необходимость перестройки индустрии пентестов, так как даже enterprise-grade вендоры допускают подобные провалы. @ozgrakkurt полагает, что безопасность была бы выше при использовании консервативной модели разрешений (как в Deno), где всё закрыто по умолчанию. Также пользователи иронизировали по поводу Rust, но @boorbat уточнил, что TiDB на 95% написан на Go.

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

Википедия — не просто обучающие данные, а самоуправляемое сообщество, независимое от коммерческого и государственного контроля и работающее ради общего блага. Она оказалась успешнее коммерческих аналогов вроде Encarta и машинной Grokipedia, а её влияние таково, что в некоторых странах, например в Китае, её блокируют. При этом ИИ-компании, контролирующие онлайн-поиск, либо собирают её контент неавторизованным скрейпингом, либо, как Microsoft, Amazon и Meta, платят за высокоскоростной доступ к API.

Автор опирается на «модель социальной связи» Айрис Мэрион Янг: обязанность исправлять несправедливость определяется участием человека в соответствующих структурах. Как участники процессов производства знания, академики этически обязаны защищать открытые сообщества знаний. Но для этого вузы должны признавать такую публичную работу — сейчас вклад в Википедию почти не учитывается при оценке преподавателей. Поддержка подобных усилий помогла бы и восстановить доверие общества к высшему образованию, подтвердив роль университетов как хранителей знаний, служащих человечеству.

В академических работах, включая высокорейтинговые журналы, растет цитирование Википедии. Это вызывает споры: одни считают её надежным ресурсом, повышающим прозрачность, другие — предвзятым третичным источником, который не заменяет глубокие исследования и может искажать данные. Для обеспечения устойчивости ссылок и борьбы с «геймингом» цитат рекомендуется использовать архивные версии через Wayback Machine. Несмотря на высокую видимость в Google, аудитория и активность редакторов снижаются, так как пользователи AI-сервисов редко переходят по ссылкам. Для развития открытых знаний необходима институциональная поддержка вузов и научных организаций. В качестве альтернативы предлагается модель с известными авторами и поддержкой НКО (например, latentpedia.org).

2 октября 333 заражённых выходных узла Tor (примерно 10% от всех ~3000) начали скоординированную атаку: перехватывали SSH-соединения и собирали незашифрованный почтовый трафик. Злоумышленники получили доступ к серверам ещё в августе и тихо развернули бэкдор Ebury 1.8.3 — вредонос для OpenSSH, ворующий учётные данные на Linux. При подключении по порту 22 пользователя незаметно перенаправляли на один из 12 серверов перехвата; при игнорировании предупреждения об изменении ключа хоста атакующий крал пароль, следил за командами и заражал сервер через второе соединение.

Вечером того же дня автор сообщил команде сетевого здоровья Tor Project, которая подтвердила новизну атаки и связалась с операторами. К 4 октября узлы пометили как BadExit, и клиенты перестали через них выходить; 5 октября заражённые серверы отключили. Команда отметила, что атакующий превращал невыходные узлы в выходные, редактируя torrc. Приманка-ловушка показала использование библиотеки paramiko и установку Ebury через Perl с base64-командой. Главный вопрос — как получен доступ ко всем серверам: есть лишь теория о взломе хостинг-провайдера. Поскольку с 2009 по 2023 год Ebury заразил 400 000 серверов, вероятно, скомпрометированные узлы Tor ещё существуют. Вывод: отключите вход по паролю в пользу SSH-ключей.

Обсуждение дополняет статью практическими наблюдениями: Операторы выходных узлов Tor сталкиваются с юридическими рисками, включая обыски, конфискацию оборудования и судебные разбирательства. Конфиденциальность в сети в значительной степени зависит от законодательства, так как государственные органы могут блокировать или преследовать пользователей. Компрометация VPS-провайдеров позволяет злоумышленникам внедрять вредоносный код (например, Ebury) в виртуальные машины и контейнеры. Для защиты от MITM-атак и кражи данных рекомендуется отключить аутентификацию по паролю, использовать SSH-ключи (предпочтительно в аппаратных токенах FIDO2 или Yubikey) и внедрить взаимную аутентификацию. Инструмент exitmap остается эффективным для обнаружения вредоносных выходных узлов. Существует спор о количестве выходных узлов: малое число (около 3000) может повышать анонимность, затрудняя выделение трафика, но делает сеть уязвимой к масштабным атакам (как при компрометации 10% узлов). Использование SSH через Tor считается плохой практикой; для администрирования рекомендуется разворачивать собственные onion-службы.

Хакеры опубликовали 281 ГБ внутренней переписки партии «Альтернатива для Германии» — 421 179 писем, доступных в виде конспектов, сгенерированных искусственным интеллектом. Материал появился на фоне споров об антисемитизме, развернувшихся в немецких СМИ после выборов в Берлине, и, по замыслу публикаторов, показывает, как это явление выглядит в реальности.

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

Публикация объёмного архива делает внутреннюю кухню партии достоянием общественности и подкрепляет обвинения, которые до сих пор звучали в основном как пересказы прессы. Полный текст материала доступен только после подписки на рассылку издания.

Обсуждение дополняет статью критикой ИИ-саммари вместо оригиналов писем, ссылками на полные дампы и анализом политического контекста Германии. @voidUpdate, @claykkari и @prolly97 считают ИИ-конспекты излишне драматичными и потенциально некорректными. @prolly97 также оспаривает термин «ультраправые» применительно к AfD, так как партия представляет интересы 20% населения. @koik и @ReptileMan полагают, что успех AfD связан с их монополией на тему иммиграции, что заставляет избирателей игнорировать радикальный контент. @grandchild и @_ink_ обсуждают возможность использования утечки как доказательств для запрета партии через Конституционный суд. @hypfer опасается, что AfD может использовать факт взлома, чтобы представить себя жертвой. @rudolftheone, @Markoff и @stratocumulus0 недовольны paywall-ом и требованием указать email для чтения статьи.

Хронология «The Legend of Zelda» от Nintendo после «Ocarina of Time» разветвляется на три ветви: эпоху Ребёнка, эпоху Взрослого и эпоху Павшего героя. В первой Линк, отправленный назад во времени, предупреждает Зельду о Ганондорфе; во второй герой исчезает, и боги, отвечая на молитвы Хайрула, затопляют королевство, оставив его под морем; в третьей Линк гибнет в бою, Ганнон забирает всю Трифорс, а Семь мудрецов запечатывают его в Священном царстве, ставшем Тёмным миром.

Сюжеты охватывают всю историю: от Скайлофта, поднятого богиней Хайлией над облаками, где Линк берёт Меч богини, чтобы найти упавшую Зельду, до фестиваля Пикори, где Ваати ломает священный клинок и превращает принцессу в камень. Дальше — заточение Ваати в Четырёх мечах, поиски Трифорс, семь лет будущего, Имприсонская война, странствия по Холодруму и Лабириннии, крушение на острове Кохолинт и пробуждение Рыбы Ветра, а также Лорул — тёмный двойник Хайрула со своей принцессой Хильдой.

Позже появляются Хайтопия, где ведьма Мод надела на принцессу Стилу не снимаемый комбинезон, и Термина с падающей луной, что ударит через три дня. В эпоху Сумерек Линк становится волком и встречает Мидну; затем идут «Ветровой ускоритель», «Призрачный песочный час», «Духовые пути» и основание Нового Хайрула. За 10 000 лет до пробуждения Линка Каламити Ганнон запечатан машинами Шиика, а под замком пробуждается Демонический король, поднимая замок в небо.

Пользователи спорят о ценности единой хронологии Zelda. Одни считают попытки выстроить таймлайн бессмысленными, воспринимая игры как независимые пересказы легенд (@somat, @collinmcnulty), другие ссылаются на официальный канон Nintendo 2011 года (@cyphar). Отмечается, что японские медиа, включая Zelda и Gundam, относятся к канону менее строго, чем американские комиксы, поэтому создание когерентной линии времени излишне (@ranger207). Многие считают игры серии самодостаточными и предупреждают, что изучение хронологии перед прохождением может раскрыть тайны сюжета и испортить впечатление (@astura, @delecti, @thr0waway001). В качестве оптимального порядка прохождения рекомендуют последовательность релизов (@opan). Для новичков советуют начать с Link's Awakening, Ocarina of Time и Breath of the Wild (@wise_blood).

Weball‐Katamari — захватывающий ностальгический проект, позволяющий «собирать» веб-страницы. Оригинальный bookmarklet работал через CSS-трансформации DOM, а новая версия импортирует страницу в игровой движок, что минимизирует работу с HTML. При большом количестве элементов (от нескольких сотен слов) FPS падает, и первую страницу невозможно собрать полностью, однако на современных устройствах, таких как iPhone 17 Pro Max, игра остается плавной. Для оптимизации рендеринга @x‐complexity предлагает генерировать внутренние слои шара одним объектом вместо множества отдельных элементов. Для аутентичности рекомендуется добавить оригинальный саундтрек от Bandai Namco. Популярность идеи подтверждает и аналогичная пасхалка в поиске Google.

В мае прошлого года лучший результат на SlopCodeBench составлял 14,8% строгого прохождения у gpt-5.5, а теперь лидер — gpt-6 astra с 16,3%. Строгий показатель означает, что модель прошла все тесты чекпоинта, не сломав при этом ранее работавшее поведение. У протестированных моделей — Opus 5.5, Fable 5.1, SOL 6 и 6.1, Astra и GLM 5.3 — строгий результат лежит в диапазоне 12,2–16,3%, тогда как менее строгий «core pass rate» достигает 65,8–74,0%. В этот раз прогон охватил 36 задач и 196 чекпоинтов на каждую настройку, что позволяет сравнивать результаты с официальными данными исследования, чего нельзя было делать на прежних подвыборках из трёх и шести задач.

Отдельный контринтуитивный вывод: средний уровень усилий оказался лучше максимального. XHigh стоит в 2,11–4,22 раза дороже Medium, но Opus 5.5 на среднем усилии показал результат лучше, чем на XHigh. По качеству кода Fable отличается наименьшей средней сложностью — 3,57 при 8967 вызываемых объектах, а GPT-6 SOL Medium — наибольшей, 11,70 при 1083 объектах. Фильтрация служебных файлов _work у Opus Medium убрала 45 файлов и 41 265 строк, снизив долю «слопа» до 92,90%, но первое место по этому показателю сохранилось.

Главный вывод: агенты гораздо чаще правильно реализуют основное поведение, чем сохраняют всё протестированное при изменении требований. Прогресс с 14,8% до 16,3% за май—сентябрь есть, но он скромнее, чем принято подавать.

Обсуждение показывает, что Astra генерирует компактный, но часто нечитаемый код, который пользователи решают проблемой форматирования; большинство участников предпочитают средний уровень усилий из‐за лучшего соотношения цены и качества, однако есть разногласия по поводу преимуществ xhigh и отсутствие тестов на уровнях high/max, а также критика текущих метрик slop и запросы на открытие исходных выводов.

• Многие отмечают, что у Astra часто отсутствуют переносы строк, из‐за чего генерируемый код выглядит как «code golf» и трудно читается.

• Совет: Рекомендуют сразу прогонять вывод Astra через автоформаттер (например Prettier) или использовать параграф‐ориентированное форматирование, чтобы восстановить читаемость.

• Пользователи предпочитают запускать дорогие модели в режиме планирования, а кодировать задачи делегировать более дешёвым моделям, что экономит квоты и деньги.

• Для большинства задач средний уровень усилий (medium) даёт лучшее соотношение цены и качества по сравнению с xhigh, где прирост точности не покрывает рост стоимости.

• Спор: Некоторые считают, что xhigh не хуже medium и даже показывает лучшие строгие показатели, тогда как другие указывают, что разница в 15 % находится в шуме и незначительна.

• Слепок кода часто объясняется избыточным «защитным» программированием LLM, которое требует человеческого вмешательства для упрощения и удаления лишних проверок.

• Совет: Предлагается измерять не только процент прохождения, а сначала гарантировать проход через harness, а затем оценивать стоимость и читаемость результата.

• Отсутствие публичных «raw» выводов затрудняет воспроизводимость benchmark'а и проверку заявленных метрик.

• Спор: Некоторые требуют включения уровней high и max в тестирование, полагая, что их исключение искажает общую картину производительности моделей.

• Метрика «slop», основанная на разнице кода, считается «размытой» и может не отражать реальную поддерживаемость и производительность.

Astra writes well (which is why I often like to work with it over Claude), but it tends to produce code golf that's borderline unreadable, like completely omitting line breaks. I thought I had something funky with my config, but it seems to be a known issue. — @throwaway219450

В mitmproxy добавлена опция --emudhra, связанная с компрометацией промежуточного удостоверяющего центра eMudhra. В код встроена цепочка сертификатов EM OV TLS CA — G3C (d=4) и кросс-подписанного корня emSign Root TLS CA — G3, включая приватный ключ EC и два сертификата в формате PEM. Ссылка на подробности указывает на домен emudhra.we-have-a-problem.com, что намекает на раскрытие или подделку ключей этой инфраструктуры.

Заодно изменена типизация: вместо жёсткого rsa.RSAPrivateKey теперь допускается объединение rsa.RSAPrivateKey | ec.EllipticCurvePrivateKey. Это затронуло методы dummy_cert, dummy_crl, поля класса CertStoreEntry, атрибуты default_privatekey и конструктор CertStore. Функция load_pem_private_key также возвращает теперь либо RSA-, либо EC-ключ, по-прежнему молча отказываясь от пароля, если ключ не зашифрован.

Практический смысл в том, что инструмент научился работать с эллиптическими кривыми в цепочках сертификатов — без этого встроенный компрометированный материал eMudhra на EC-ключе не удалось бы использовать для подписи поддельных сертификатов и CRL.

Тред дополняет статью деталями эксплуатации: уязвимыми остаются устройства без пиннинга сертификатов (например, старые Smart TV или Android-телефоны), которые всё ещё доверяют eMudhra. Для перехвата трафика большинства IoT-устройств требуется загрузить все шесть скомпрометированных ключей; один ключ (d=4) не работает. Выбор цепочки сертификата зависит от даты обновления хранилища: путь AAA работает на устройствах, обновлённых после февраля 2025 года, а путь emSign — на тех, где он был доступен с 2018 по октябрь 2026 года. Новые модели могут не принимать ни один из путей или использовать привязку сертификатов. Существует спор, является ли включение тривиального приватного ключа преднамеренным бэкдором или ошибкой. Рекомендуется проверить список доверенных корневых сертификатов на устройствах и отозвать скомпрометированные сертификаты eMudhra (в частности, iOS всё ещё доверяет двум поддельным). Использование опции --emudhra считается неэтичным, так как это может быть воспринято как насмешка над компанией.

Вокруг новой уязвимости в PHP раздули панику, но лёгкого эксплойта для неё не существует. Баг реальный и важный, однако он далеко не так прост в использовании, как Log4Shell, Heartbleed или декодирование YAML в Ruby on Rails. На GitHub уже тысячи «PoC», но ни один не работает против чистой установки PHP — автор призывает поднять сервер в Docker и запустить скрипт руками, а не через языковую модель: эксплойты просто не срабатывают.

Причина в том, что почти все поддельные «доказательства» опираются на локальное включение файлов (LFI) — по сути, требуют, чтобы сервер уже выполнял eval(read(файл_от_пользователя)). Это абсурдное предварительное условие: если для атаки нужна существующая уязвимость, позволяющая прочитать /etc/passwd, то баг не тянет на критический. Прошло уже больше десяти часов, на него смотрят полмира и сотни тысяч «сверхразумов», но рабочего эксплойта нет — в отличие от Log4Shell, где ботнеты появлялись мгновенно, ещё до эры ИИ.

Корень проблемы — слепая вера в LLM: люди, не понимающие цепочек use-after-free, уверены, что «Клод всё знает и сделает эксплойт». В итоге модель выдаёт младшему брату отключённый геймпад — на экране написано «эксплойт», есть убедительные логи, но сама модель заранее добавила серверу серьёзную уязвимость. Отсюда и странная одинаковость ошибок: ИИ стал главным «принимающим решения», порождая причудливые «точки Шеллинга» в решениях. Паника подогревалась заявлением члена команды PHP о «катастрофе», всеобщим недоверием к безопасности PHP, видео с аниме-девочкой и ощущением, что LLM нависают над интернетом. Но это не момент Log4J.

Вопреки заявлениям об отсутствии простых эксплойтов, специалисты Trail of Bits за несколько часов создали два рабочих варианта, протестировав их на чистой установке MediaWiki. PHP-Security подтвердил наличие use-after-free и краха воркера, продемонстрировав RCE через PHP-FPM и mod_php. При этом большинство публичных PoC требуют доработки и часто зависят от LFI. В сообществе возник спор: одни считают уязвимость одной из самых серьезных за последние годы из-за широкого охвата, другие сомневаются в этом из-за сложности реализации. Многие отмечают разрыв между технической реальностью и медийным ажиотажем, указывая, что паника раздута за счет AI-рекомендаций, а не детального анализа.

Платформа Railway сообщила об утечке: утром обнаружена аномальная активность в системах, где хранятся переменные окружения клиентов. Расследование показало, что посторонний мог получить доступ к зашифрованным переменным, а для части из них — и к расшифрованному содержимому. В таких переменных обычно лежат секреты: ключи API, учётные данные баз данных и реестров образов.

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

Все развёртывания приостановлены на время расследования — новые версии пока выкатить нельзя. Пострадавших клиентов известят напрямую по электронной почте, а обновления будут публиковать на странице статуса.

Обсуждение дополняет статью фактами о краже средств через API: пользователи (@MattIPv4, @dylanz, @piazz) сообщают об использовании расшифрованных секретов, включая ключи OpenRouter, для оплаты AI-моделей. Клиенты (@vintagedave, @fyzix, @arbayi, @alpineman, @eecks) критикуют Railway за медленное оповещение (информация в Discord появилась раньше официального письма) и парализованный процесс восстановления: запрет деплоев сделал ротацию ключей бессмысленной и привела к простою сервисов. Пользователь @sergiotapia советует отозвать все API-ключи у провайдеров и не вводить новые значения в Railway из-за возможной компрометации платформы. @cowlby заметил в логах подозрительную регенерацию данных бакетов персоналом Railway Staff, что указывает на глубокий доступ к инфраструктуре. Общий фон указывает на серию одновременных атак на инфраструктурные сервисы, включая PHP RCE и компрометацию сертификатов eMudhra (@vldszn).