Passkey Editor вырос из той же работы, что и серия Demystifying Passkeys Under the Hood: The Protocol (процедуры WebAuthn на уровне отдельных байтов), The Architecture и Under Attack (классы атак, которые остаются возможными даже при корректной реализации процедуры).

Код доступен на github.com/anvilsecure/passkey-editor.

Зачем я его сделал

Когда я впервые попытался протестировать работу ключей доступа в реальном пентесте, меня хватило примерно на десять минут. Пропускаешь логин через прокси, находишь POST-запрос с подтверждением аутентификации — и дальше работать практически не с чем. Тело запроса по сути представляет собой сплошной блоб. Декодеры Burp помогают лишь частично: clientDataJSON разворачивается в читаемый JSON, который можно менять через Inspector.

Но критичные для самой процедуры поля так просто не разобрать: authData и объект аттестации приходят в CBOR, который Burp не умеет ни читать, ни редактировать. После этого остаётся только фаззить вслепую.

Мне хотелось получить для WebAuthn то же, что семейство JWT Editor дало JSON Web Token: отдельную вкладку, которая появляется на нужном запросе, декодирует его в удобный для редактирования вид, а затем собирает обратно так, чтобы сервер по-прежнему принимал запрос. Существующие решения меня не устроили, поэтому я начал писать своё.

Проблема: трафик WebAuthn непрозрачен

Разберёмся подробнее, почему трафик ключей доступа так плохо поддаётся анализу в Burp.

Процедура WebAuthn не передаёт аккуратный, готовый к чтению JSON. Данные аутентификатора, объект аттестации и открытый ключ представлены в CBOR — бинарном формате сериализации, для которого в Burp нет встроенного представления. С этим ещё можно было бы жить, но есть дополнительная проблема: проверяющие стороны (RP) почти никогда не передают CBOR как есть. Сначала его кодируют в Base64, нередко дважды, причём в одном и том же запросе могут смешиваться URL-safe и стандартный алфавиты, варианты с padding и без него. Некоторые сервисы дополнительно заворачивают результат в JSON со своими именами полей.

Поэтому единого формата, на который можно было бы ориентироваться, просто нет. Каждый реализовал всё по-своему, а значит, в идеале инструмент должен уметь разбирать каждый из этих вариантов.

Вот как одна и та же процедура выглядит в трёх реальных реализациях: (1) Microsoft раскладывает ответ WebAuthn по плоским параметрам формы, (2) GitHub сохраняет имена полей из спецификации, но помещает их во вложенный JSON внутри multipart-тела, а (3) Google прячет те же самые поля в позиционном массиве, сериализованном в строку, внутри RPC-эндпоинта batchexecute. Имен полей там вообще нет — только индексы, после чего вся конструкция ещё и проходит URL-кодирование. Три почти не похожих друг на друга формата, передающих одни и те же данные.

Побайтовую структуру всего этого я уже разбирал в первой части серии: устройство authData, байт флагов, rpIdHash, clientDataJSON и его привязку к origin, поэтому здесь повторяться не буду.

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

Вот тело запроса регистрации прямо в том виде, в котором оно приходит по сети. И это лишь один из множества возможных вариантов.

{
  "username": "demo_user",
  "response": {
    "id": "SZNyIn7tWd5VQQryYcmtZpBSzA31paGNkqwz-yHSFtM",
    "rawId": "SZNyIn7tWd5VQQryYcmtZpBSzA31paGNkqwz-yHSFtM",
    "response": {
      "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YViBdKbqkhPJnC90siSSsyDPQCYqlMGpUKA5fyklC2CEHvBFAAAAAQECAwQFBgcIAQIDBAUGBwgAIEmTciJ-7VneVUEK8mHJrWaQUswN9aWhjZKsM_sh0hbTpAEBAycgBiFYIENoOm9EGQHj8Y76oGP56jdEtLCtep-dA8fPwc9oWZvH",
      "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoidmpSeGJHbC16MG11N2FpRFNROGRtT3dBcEQzLWRpUHRURDFjN2ZvRkdYMlNBZk5HZVJhclZyZnMyT2hZVkhtUEI0NFJ5YjEzMEZIMUhrV2tiZ2hPQ0EiLCJvcmlnaW4iOiJodHRwczovL3dlYmF1dGhuLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlLCJvdGhlcl9rZXlzX2Nhbl9iZV9hZGRlZF9oZXJlIjoiZG8gbm90IGNvbXBhcmUgY2xpZW50RGF0YUpTT04gYWdhaW5zdCBhIHRlbXBsYXRlLiBTZWUgaHR0cHM6Ly9nb28uZ2wveWFiUGV4In0",
      "transports": ["internal"],
      "publicKeyAlgorithm": -8,
      "publicKey": "MCowBQYDK2VwAyEAQ2g6b0QZAePxjvqgY_nqN0S0sK16n50Dx8_Bz2hZm8c",
      "authenticatorData": "dKbqkhPJnC90siSSsyDPQCYqlMGpUKA5fyklC2CEHvBFAAAAAQECAwQFBgcIAQIDBAUGBwgAIEmTciJ-7VneVUEK8mHJrWaQUswN9aWhjZKsM_sh0hbTpAEBAycgBiFYIENoOm9EGQHj8Y76oGP56jdEtLCtep-dA8fPwc9oWZvH"
    },
    "type": "public-key",
    "clientExtensionResults": { "credProps": { "rk": true } },
    "authenticatorAttachment": "platform"
  }
}

А в конечном счёте увидеть и модифицировать вы хотите примерно вот это:

{
  "clientDataJSON": {
    "type": "webauthn.create",
    "challenge": "vjRxbGl-z0mu7aiDSQ8dmOwApD3-diPtTD1c7foFGX2SAfNGeRarVrfs2OhYVHmPB44Ryb130FH1HkWkbghOCA",
    "origin": "https://webauthn.io",
    "crossOrigin": false
  },
  "attestationObject": {
    "attestationStatement": {
      "format": "none"
    },
    "authenticatorData": {
      "rpIdHash": "74A6EA9213C99C2F74B22492B320CF40262A94C1A950A0397F29250B60841EF0",
      "extensions": {},
      "signCount": 1,
      "flags": {
        "userPresent": true,
        "userVerified": true,
        "backupEligible": false,
        "backupState": false,
        "attestedCredentialData": true,
        "extensionDataIncluded": false
      },
      "attestedCredentialData": {
        "aaguid": "01020304-0506-0708-0102-030405060708",
        "coseKey": {
          "keyType": "OKP",
          "algorithm": "EdDSA",
          "curve": "Ed25519",
          "x": "43683A6F441901E3F18EFAA063F9EA3744B4B0AD7A9F9D03C7CFC1CF68599BC7"
        },
        "credentialId": "499372227EED59DE55410AF261C9AD669052CC0DF5A5A18D92AC33FB21D216D3"
      }
    },
    "fmt": "none"
  }
}

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

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

Есть целый набор базовых проверок по чек-листу, которые стоит выполнять в любом случае. И, судя по всему, они окупаются чаще, чем можно было бы ожидать. Например, в исследовании State of Passkeys Jannett и соавторы протестировали 103 реально работающие проверяющие стороны и обнаружили, что все 103 уязвимы как минимум для одной атаки на стороне сервера, причём в 18 случаях уязвимость была критической.

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

Passkey Editor

Passkey Editor отслеживает оба типа процедур: webauthn.create для регистрации и webauthn.get для аутентификации. Если инструмент обнаруживает одну из них, рядом с Pretty, Raw и Hex появляется вкладка Passkey Editor, которая доступна и после отправки запроса в Repeater.

Если вы работали с JWT Editor, принцип должен быть вам знаком: отдельная вкладка редактора появляется именно там, где проходит интересующий нас трафик; внутри — декодированное структурированное представление, которое можно редактировать на месте, выпадающий список атак в один клик и управление ключами. Именно JWT Editor во многом послужил для меня образцом: пользователи Burp уже привыкли к такому процессу и действуют в нём практически на автомате.

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

Возможности вкладки зависят от того, где она открыта. Если запрос уже ушёл — например, вы просматриваете его в истории Proxy или в Scanner, — Passkey Editor только декодирует данные: менять уже нечего. В Repeater и при перехвате в Proxy, пока запрос ещё не дошёл до сервера, та же вкладка становится редактируемой и появляются элементы управления: выпадающий список Attacks, флаги с чекбоксами и кнопки переподписания.

Кроме того, инструмент выделяет янтарным цветом все поля, которые вы меняете или уже изменили. Если отправить модифицированный запрос, а затем открыть его в истории Proxy, все затронутые поля останутся подсвеченными. Без этого пришлось бы переключаться между вкладками Original и Edited, а для такой глубоко вложенной структуры ещё и отправлять обе версии в Comparer, чтобы выполнить побайтовое сравнение. Здесь же все изменения сразу остаются на виду.

Что происходит внутри

Обнаружение строится на регулярных выражениях и конфигурации, а для каждого хоста используется отдельный профиль. В нём фиксируются URL процедур и расположение каждого поля в запросах конкретной проверяющей стороны. В движке нет отдельных веток под конкретных вендоров, поэтому для новой реализации достаточно описать её в профиле.

Декодирование устроено как послойный конвейер. Инструмент по очереди снимает каждый слой Base64 или JSON, запоминает точный вариант кодировки и наличие padding, чтобы затем восстановить всё в исходном виде, а после этого декодирует CBOR и COSE с помощью низкоуровневых конвертеров webauthn4j.

⚠️ Здесь есть одно важное осознанное решение. Я использую конвертеры webauthn4j, а не его validating manager. Задача manager — отбрасывать некорректные процедуры, а Passkey Editor как раз и нужен для того, чтобы такие процедуры создавать. Если подключить валидатор, библиотека начнёт отвергать именно те payload'ы, которые вы пытаетесь собрать.

Редактируемое представление — это структурированный JSON с undo, redo и переключателем переноса строк. clientDataJSON инструмент хранит как непрозрачную последовательность байтов и подписывает точные байты в том виде, в котором они передаются, а не результат повторной сериализации. Сервер хеширует именно полученные данные, поэтому сериализация с другим порядком ключей приведёт к ошибке по причине, никак не связанной с вашей атакой.

Однако другие структуры данных подписываются закрытым ключом аутентификатора. Чтобы можно было менять эти значения и при этом проверяющая сторона продолжала их принимать, мы фактически перестаём использовать ключ аутентификатора и подставляем собственный. Находясь между клиентом и проверяющей стороной, инструмент во время регистрации подставляет открытый ключ COSE из сгенерированной им пары ключей. В результате сервер сохраняет credential, закрытая часть ключевой пары от которого находится у вас.

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

Рядом с редактором находится выпадающий список Attacks, за которым работает механизм переподписания. Они действуют вместе, поэтому вы можете настраивать отдельные атаки или их комбинации, не задумываясь о том, как именно внутри выполняется переподписание.

При подстановке ключа нужно также выбрать, какая аттестация будет отправлена вместе с ним. Passkey Editor поддерживает два формата: none и packed. Именно от этого выбора зависит, примет ли конкретная проверяющая сторона такой credential.

Первые два варианта покрывают как раз те реализации, которые имеет смысл тестировать: сервер либо вообще не запрашивает аттестацию, либо требует аттестационное заявление, но не проверяет его относительно доверенного корня — а это очень распространённая конфигурация. Третий вариант инструмент намеренно не поддерживает: возможность построить цепочку, которая пройдёт проверку относительно CA вендора, не находящегося под вашим контролем, — это именно то, от чего и должна защищать полная аттестация. Поэтому сервер, который проверяет её правильно, отклонит и первые два варианта. Как нетрудно догадаться, здесь защита работает как задумано, а не инструмент чего-то не умеет. Это было осознанное архитектурное решение.

Механизм переподписания должен поддерживать любой алгоритм, выбранный проверяющей стороной, поэтому в Passkey Editor реализовано одиннадцать алгоритмов из семейств ECDSA, RSA-PKCS1, RSA-PSS и EdDSA. Каждая подпись передаётся в формате, соответствующем конкретному алгоритму, без предположения, что всё вокруг — ECDSA в формате DER. Именно эта деталь, например, позволяет нормально работать с EdDSA.

Управлять всем этим вручную быстро надоедает, как только начинаешь многократно прогонять одну и ту же процедуру. Для этого и существует режим AUTO. Активируете его для профиля — и инструмент автоматически переподписывает данные или повторно подставляет ключ до отправки запроса в Proxy и Repeater. Благодаря этому перехваченную процедуру можно снова и снова отправлять и менять, а сервер продолжит успешно её валидировать.

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

Scanner, Intruder и механизм повторного воспроизведения записанного логина намеренно исключены. Они самостоятельно повторяют запросы по своему расписанию, а подстановка ключа перед отправкой в таком случае при каждом запуске регистрировала бы в аккаунте новый ключ и ломала другие параллельные сценарии работы. Кроме того, ручные правки всегда имеют приоритет над AUTO: если вы сами собрали процедуру во вкладке, наружу уйдёт именно она независимо от того, включён AUTO или нет.

Если процедуру не редактировать, она отправляется побайтно в исходном виде. Инструмент вообще не трогает трафик, который вы явно не просили изменить. Лично я не стал бы пользоваться декодером, который незаметно переписывает байты, а потом мои запросы по непонятной причине начинают отклоняться. Доверие к такому инструменту пропало бы сразу. Поэтому Passkey Editor спроектирован так, чтобы никак не проявлять себя в передаваемых данных, пока вы сами не попросите его что-то изменить.

Демонстрации

Чтобы показать, какие сценарии поддерживает инструмент, ниже есть несколько записанных демонстраций работы с двумя проверяющими сторонами: webauthn.io и github.com.

Всё, что показано в видео, нужно исключительно для демонстрации возможностей Passkey Editor. Здесь нет никакой жертвы и никакого захвата аккаунта. Задача лишь в том, чтобы показать: Passkey Editor позволяет собрать практически любую процедуру WebAuthn и передать её реальной проверяющей стороне на проверку.

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

В следующем полном видео показан весь ручной сценарий: от подстановки ключа при регистрации (с fmt="none") до переподписания им подтверждений аутентификации.

Полная демонстрация: forge-manual.mp4

Тот же сценарий, но с включёнными флагами AUTO:

Полная демонстрация: forge-auto.mp4

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

После внесения изменений переподписание можно запустить вручную или оставить это самому инструменту.

Полные демонстрации: framing-1.mp4, framing-2.mp4, framing-3.mp4

Атаки

Выпадающий список Attacks позволяет в один клик запускать базовые проверки, которые приходится выполнять практически при каждом пентесте реализации ключей доступа:

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

Механизм переподписания поддерживает 11 алгоритмов COSE — это даже больше, чем обычно согласовывают распространённые реализации WebAuthn. Для всех используется только криптография из JDK (SunEC, SunRsaSign, Ed25519), без BouncyCastle и других внешних провайдеров.

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

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

Как Passkey Editor соотносится с другими инструментами

Я далеко не первый, кто взялся за эту задачу. Passkey-Raider ближе всего по возможностям декодирования: он использует обнаружение по регулярным выражениям, даёт редактируемую вкладку и умеет подставлять ключ с последующим переподписанием для восьми алгоритмов COSE. Но готовых сценариев атак в нём нет, поэтому все изменения приходится вносить вручную.

Burp_FIDO2, созданный на основе дипломной работы Чена в Университете Твенте, предлагает самый широкий набор атак среди расширений Burp, но начинает испытывать проблемы, как только цель использует нестандартное кодирование.

За пределами Burp есть Passkeys.Tools от команды, стоящей за исследованием State of Passkeys. Этот инструмент эмулирует и браузер, и аутентификатор, поэтому даёт самую широкую поверхность для модификации данных из всех перечисленных решений. Но за это приходится платить тем, что он лишён главного преимущества расширения Burp: он не находится прямо там, где вы уже ведёте работу.

~ означает частичную поддержку: webauthn-cbor декодирует только часть структуры, а у Burp_FIDO2 декодирование и обратное кодирование ломаются на нестандартных обёртках. Данные о декодировании, обратном кодировании и пассивном тестировании в первых трёх строках взяты из обзора возможностей самих Jannett и соавторов в исследовании State of Passkeys.

Потребность в таких инструментах, впрочем, ощущается повсеместно. Инструментарий для работы с ключами доступа всё чаще появляется на конференциях по ИБ: например, Pass-the-Passkey Графнеттера на Black Hat USA 2026, а Passkey Editor — на главной сцене DEF CON 34.

Планы

В ближайших планах, примерно в таком порядке:

• Ускорить настройку целей. По правому клику на перехваченной процедуре можно будет создать заготовку профиля, затем указать нужное поле в теле запроса, а инструмент сам определит его путь и цепочку кодирования — примерно так же, как в Intruder отмечают позицию для payload. Плюс редактирование профиля прямо из текущего контекста, чтобы при настройке новой проверяющей стороны не приходилось постоянно переключаться между вкладками Proxy и редактора.

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

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

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

• Добавить пассивное сканирование, которое будет на лету отмечать процедуры WebAuthn и распространённые ошибки конфигурации.

В заключение

Главная мысль всей серии проста: сама процедура работы с ключами доступа устроена надёжно. Не стоит тратить пентест на попытки атаковать криптографию — FIDO Alliance и W3C уже потратили годы на то, чтобы сделать это за вас. Ошибки находятся вокруг неё, и большинство из них связано с тем, что проверяющая сторона проверяет — или не проверяет.

Passkey Editor нужен именно для того, чтобы быстро добраться до этой поверхности атаки в реальном пентесте, а не тратить первый день на борьбу с Base64 и CBOR.

Впервые Passkey Editor был публично представлен на DEF CON 34, где я разобрал несколько классов атак, которые автоматизируют эти готовые сценарии. Подробнее об инструменте можно прочитать в самом репозитории на GitHub.

В пентесте многое упирается в то, насколько хорошо вы понимаете возможности инструментов и ограничения самой защиты. На бесплатных уроках можно посмотреть на это с разных сторон: использовать браузер как инструмент для работы с инфраструктурой и разобраться, какие атаки могут проходить мимо IDS/IPS. Заодно можно задать вопросы экспертам и познакомиться с форматом обучения.

• 5 октября в 20:00. «Living off the Browser — пентест из вкладки Chrome». Записаться

• 21 октября в 20:00. «Пентест инфраструктуры: поиск слепых зон IDS/IPS». Записаться