Здравствуйте, дорогие друзья.

Веб-токены Json (JWT) чрезвычайно популярны среди конечных точек API, поскольку их легко реализовать и понять.

Когда пользователь пытается войти в систему, он будет отправлять свои учетные данные для API бэкэнда. После этого программа будет проверять учетные данные, и если они верны, она будет генерировать токен JWT. Затем этот токен отправляется пользователю, после чего любой запрос, отправленный в API, будет содержать этот токен JWT для подтверждения его подлинности.

Как показано ниже, токен JWT состоит из трех частей, разделенных точками:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFt

ZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwp

MeJf36POk6yJV_adQssw5c

Токен можно легко расшифровать с помощью декодера base64, но мне нравится использовать сайт jwt.io для расшифровки этих токенов, как показано выше.

Обратите внимание, что токен JWT состоит из трех частей:

● Заголовок

● Полезная нагрузка

● Подпись

Первая часть токена — это заголовок, в нем вы указываете алгоритм, используемый для генерации подписи. Вторая часть токена — это полезная нагрузка, в ней вы указываете информацию, используемую для контроля доступа. В приведенном выше примере в разделе полезной нагрузки есть переменная под названием “name”, это имя используется для определения того, кто является пользователем при проверке подлинности. Последняя часть токена — это подпись, это значение используется для того, чтобы убедиться, что токен не был изменен или подделан. Подпись создается путем объединения заголовка и разделов полезной нагрузки, затем это значение подписывается алгоритмом, указанным в заголовке, который в данном случае является “H256”.

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

Удаленная подпись

Без подписи любой желающий может изменить раздел полезной нагрузки, полностью минуя процесс аутентификации. Если вы удаляете подпись с токена JWT, а она все равно принимается, значит, вы только что обошли процесс проверки. Это означает, что вы можете изменить раздел полезной нагрузки на все, что пожелаете, и это будет принято серверной частью.

Используя приведенный ранее пример, мы могли бы изменить значение “имя” с “john doe” на “admin”, что позволило бы нам войти в систему в качестве пользователя с правами администратора.

None Algorithm

Если вы сможете изменить алгоритм, используемый для подписи токена, вы можете нарушить процесс проверки подписи. JWT поддерживает алгоритм “none”, который изначально использовался для целей отладки. Если используется алгоритм “none”, любой токен JWT будет действителен до тех пор, пока отсутствует подпись, как показано ниже:

Обратите внимание, что эта атака может быть выполнена вручную или вы можете использовать плагин Burp под названием “Json Web Token Attacker”, как показано на рисунке ниже:

Лично мне нравится использовать этот плагин, так как вы можете быть уверены, что ничего не испортите, и, как правило, это намного ускоряет работу.

Брут Форс секретных ключей

Токены JWT с секретным ключом будут использовать алгоритм HMAC или RSA для проверки подписи. Если приложение использует алгоритм HMAC, оно будет использовать секретный ключ при создании подписи. Если вы сможете угадать этот секретный ключ, вы сможете генерировать подписи, позволяющие подделывать ваши собственные токены. Существует несколько проектов, которые можно использовать для взлома этих ключей, как показано ниже:

● https://github.com/AresS31/jwtcat

● https://github.com/lmammino/jwt-cracker

● https://github.com/mazen160/jwt-pwn

● https://github.com/brendan-rius/c-jwt-cracker

Список можно продолжать несколько дней, просто найдите на github слова “jwt cracker”, и вы найдете множество инструментов, которые могут сделать это за вас.

RSA для HMAC

Существует несколько методов подписи, которые можно использовать для подписи токена JWT, как показано в списке ниже:

● RSA

● HMAC

● None

RSA использует открытый/закрытый ключ для шифрования, если вы не знакомы с процессами асимметричного шифрования, я бы посоветовал поискать его. При использовании RSA токен JWT подписывается закрытым ключом и проверяется с помощью открытого ключа. Как вы можете судить по названию, закрытый ключ должен быть закрытым, а открытый ключ должен быть общедоступным. HMAC немного отличается, как и многие другие алгоритмы симметричного шифрования, HMAC использует один и тот же ключ для шифрования и дешифрования.

В коде, когда вы используете RSA и HMAC, это будет выглядеть примерно следующим образом:

● verify(“RSA”,key,token)

● verify(“HMAC”,key,token)

RSA использует закрытый ключ для генерации подписи и открытый ключ для проверки подписи, в то время как HMAC использует тот же ключ для генерации и проверки подписи.

Как вы уже знаете, алгоритм, используемый для проверки подписи, определяется заголовком JWT. Итак, что произойдет, если злоумышленник изменит алгоритм RSA на HMAC. В этом случае для проверки подписи будет использоваться открытый ключ, но поскольку мы используем HMAC открытый ключ также может использоваться для подписи токена. Поскольку предполагается, что этот открытый ключ является открытым, злоумышленник сможет получить токен, используя открытый ключ, а сервер затем проверит токен, используя тот же открытый ключ. Это возможно потому, что код написан для использования открытого ключа в процессе проверки. Под в обычных условиях для создания подписи использовался бы закрытый ключ, но поскольку злоумышленник указал алгоритм HMAC, тот же ключ используется для подписи токена и его проверки. Поскольку этот ключ является открытым, злоумышленник может подделать свой собственный, как показано в приведенном ниже коде.

В исходном заголовке использовался алгоритм RS256, но мы изменили его на HS256. Затем мы изменили наше имя пользователя на admin и подписали токен, используя открытый ключ сервера. Когда это сообщение будет отправлено на сервер, он будет использовать алгоритм HS256 для проверки токена вместо RS 256. Поскольку серверный код был настроен на использование открытого/приватного ключа, открытый ключ будет использован в процессе проверки, и наш токен будет принят.

Резюме

Веб-токены Json (JWT) — это относительно новый способ проверки подлинности, и он относительно прост по сравнению с другими методами. Однако даже при такой простоте есть существует несколько уязвимостей, которые влияют на JWTS. Если злоумышленник сможет подделать свой собственный билет, игра будет окончена. Вот почему большинство атак основаны на этой методологии.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.