Вступление
Всех приветствую ! Сегодня, в рамках этой статьи хотелось бы поднять достаточно интересную тему, касающуюся JWT или JSON Web Tokens, а точнее - разобрать ошибки разработчиков, которые реализуют эту технологию, которые могут привести к взлому веб-приложения. В случае успешной атаки, хакер сможет создавать новые токены, выдавая себя за других пользователей, что само по себе подразумевает почти полный захват приложения. Ведь таким образом можно выдать себя и за администратора приложения, и за других пользователей, получив при этом доступ к их личным данным, и много чего еще.
Сама же технология сейчас достаточно активно используется, так что умение атаковать такие токены точно лишним не будет. Разберемся какие существуют популярные уязвимости у токенов, как их использовать, и при помощи какого инструмента можно автоматизировать процесс. Поехали!
Теория
Начать, пожалуй, стоит с того, что вообще такое JWT.
Возможно, копаясь по каким-нибудь сайтам, в заголовках вы могли встретить что-то подобное:
Это и есть JWT собственной персоной. Давайте подробно разберемся что это такое и как работает:
JWT – (JSON Web Tokens) – это технология, которая добавляет в заголовки http-запросов уникальный отпечаток, основаный на формате JSON. Добавляется он обычно либо в собственном параметре, либо так же может передаваться в cookies. Этот отпечаток служит для передачи информации о пользователях и служит идентификатором для веб-приложения. Вся структура отпечатка основана на JSON формате.
Сам принцип работы токена достаточно прост – приложение формирует токен, который передает пользователю, и который в дальнейшем крепится к каждому запросу пользователя, являясь по сути цифровым отпечатком пользователя.
Основным отличием JSON токенов, от других подобных технологий, является то, что при таком подходе не требуется храненя каких-либо данных для сверки на сервере. Подлинность токена проверяется на основе подписи (подробнее о ней далее). То есть, приложение проверяет полученный токен, просто проверив прикрепленную подпись, которая высчитывается определенным алгоритмом, и служит гарантом того, что токен сформирован именно на сервере, а не создан пользователем, в попытке выдать себя за другого. Если подпись проходит проверку – токен считается валидным и данные из него используются для дальнейшей работы, если нет – то вполне логично что с таким токеном приложение работать не будет.
Давайте посмотрим что вообще из себя представляет такой токен. Сам токен состоит из трех частей:
1. header
2. payload
3. signature
Чуть более подробно поговорим о каждой из них, а затем соберем их воединно:
1. Header
header – это часть токена, которая сообщает две вещи: первая, что это непосредственно токен, а вторая – алгоритм шифрования, который используется для подписи токена.
Сама часть header выглядит вот так:
typ заголовок нам сообщает что перед нами непосредственно JWT-токен, а вот заголовок alg говорит о том, какое шифрование используется для подписи токена. Первые две буквы – это тип используемого шифрования, а последующие три цифры – длина ключа в битах.
Вариантов используемого шифрования, равно как и значения alg может быть много. И вот в чем разница:
HS, он же HMAC-SHA, основанный на SHA– протоколе хэширования. Этот алгоритм использует одну ключевую фразу для генерации подписи, поэтому данная фраза всегда должна держаться в секрете, так как с ее помощью можно подписывать токены.
RS, он же RSA, алгоритм подписи, опо сути являющийся тем же RSA –достаточно популярным ассиметричным протоколом шифрования. Этот алгоритм может использоваться как для шифрования данных, так и для подписи. В случае с шифрованием данных, для шифрования данных используется один ключ – открытый, а для дешифровки – другой, закрытый. Причем, открым ключом можно зашифровать данные, но расшифровать его при помощи этого ключа уже не получится, и соответсвенно наоборот – при помощи закрытого ключа можно только расшифровать данные, но зашифровать нельзя. В этом вся суть ассиметричного шифрования. Конкретно в случае с JWT используется не шифрование,а подпись по алгоритму шифирования, и все работает несколько иначе, но углубляться в криптографию смысла здесь нет. Важно понимать только то, что открытый ключ, что в случае с шифрованием, что с подписью, может спокойно передаваться, так как он не является чувствительной информацией, при помощи которой можно получить доступ к данным. Этот метод шифрования считается более безопасным, но не смотря на это, в случае с JWT он тянет за собой проблему, о которой поговорим позже.
Помимо этих двух существуют и менее популярные алгоритмы ES и PS. Об этих алгоритмах особо подробно знать ничего не обязательно, важно лишь то, что они тоже ассиметричны и используют два ключа – открытый и закрытый.
Все вышеперечисленные протоколы в JWT поддерживают длинну ключей 256 384 и 512 бит. Кроме PS, он поддерживает только 256 и 384 битные ключи.
2.Payload
Следующая часть токена – payload, или полезная нагрузка. Вопреки мнению некоторых новичков, этот термин используется не только для того, чтобы обозначить вредоносные нагрузки при эксплуатации каких-то уязвимостей
. Payload может быть вполне мирным и обозначает данные, которые передаются внутри какой-либо структуры. В нашем случае в payload’e содержится вся основная ифнормация токена, ради которой он и существует: пользователь, приложение, которое отправило токен, время жизни токена и т.д. Все эти пункты внутри полезной нагрузки называются заявками (JWT-claims). Каждый разработчик сам определяет какие заявки вкладывать в токен. На основании наиболее частых и правильных заявок составлен список основных claim’ов, ознакомиться с ним можно, например, на википедии:
https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields
Однако, ни одно из этих полей не является обязательным. Разработчик сам определяет какие из этих полей включать в токен, а какие там и не нужны.
Сама часть токена с полезной нагрузкой выглядит так:
3. signature
Третья часть токена – сигнатура или подпись. Эта часть токена, по сути является подписью, доказывающей подлинность токена, и заодно закрытым замком к его изменению.
Сама подпись составляется в три этапа и состоит из двух основных частей. Процесс создания происходит так:
Сначала составляется основная часть токена – непосредственно подпись. Она состоит из первых двух частей токена – header’a и payload’a, закодированных в base 64 и разделенных точкой. То есть, выглядит в псевдокоде это примерно так:
Далее все зависит от выбранного типа шифрования. Если протокол ассиметричный – создается пара открытый и закрытый ключ, а если симметричный – только закрытый.
Ну и после создания ключа/ключей все предыдущие части сигнатуры соединяются в одну очень просто – берется первая часть токена и подписывается выбранным алгоритмом, при помощи выбранных создателем ключей.
Сама подпись является гарантом того, что токен не был подделан. Мы можем изменить содержимое первых двух частей токена (как именно будет рассказано далее) без особых проблем, но суть в том, что тогда должна будет поменяться и подпись. А изменить подпись не зная ключей не получится. Получив токен, приложение самостоятельно вычисляет подпись и сравнивает полученное значение с тем, что в токене. Если они не совпадают – значит токен был подделан.
Важный момент: для дополнительной защиты токена, при использовании алгоритма HS, т.е. алгоритма подписи с одним ключом шифрования, может быть использована кодировка секретной фразы в base64 перед подписью.
Для чего это нужно узнаете чуть далее, когда будем рассматривать атаки на токены. Пока просто учтите это момент
Создание токена:
Ну и далее все части токена обьединяются в одну. Для этого первые две части – header и payload кодируются в base64 и каждая часть токена отделяется от других точкой.
В результате мы и получим сам токен, вида:
Дальнейшая работа с токенами:
Далее нам нужно понимать что и как делать с токенами, если мы собираемся как-то раскручивать этот вектор. А именно, как просмотреть содержимое токена, как сгенерировать новый токен и т.д. А так как JWT – стандартизированная технология, то все jwt токены будут отвечать определенным требования.
Так как первые две части токена не шифруются, а лишь кодируются в base64, их содержимое можно без проблем просмотреть. Именно поэтому, в токенах не рекомендуется передавать чувствительную информацию, которую не должен видеть никто посторонний.
Просмотреть содержимое токена, а точнее первых двух его частей можно на вот этом сайте:
Для этого достаточно вбить токен в левое поле, а в трех правых полях мы получим три части токена соответсвенно.
Там же, можно генерировать новые токены, менять содержимое старых и т.д, просто манипулируя с данными в полях справа и слева. Ну и, так как алгоритм проверки валидности токена везде один, прямо на сайте мы так же сможем проверить, валидным ли является токен, или приложение заподозрит что мы что-то изменили.
Атаки на токены
В этой части статьи рассмотрим атаки на токены. Есть разные способы атак, но желаемый результат почти всегда один – подделать токен, дабы выдать себя за другого пользователя. Сами атаки я расположил в порядке от более старых к более новым, и прикрепил номера CVE, чтобы вы могли сами глубже покопать, если захотите. Поехали:
1. Брутфорс закрытого ключа в SHA.
Первое, и что самое логичное, что можно предположить – если для подписи токена используется симметричное шифрование, то можно пойти самым простым путем – попробовать получить ключ, при помощи которого можно будет сгененрировать новый токен. Самый простой и легкий, с точки зрения реализации, способ – это брутфорс. Причем, брутить сам ключ размером от 256 до 512 бит нас никто не заставляет, достаточно получить SECRET_KEY фразу, которая по сути – просто пароль, который служит для подписи ключа. Зная такой пароль, можно как бы “разблокировать” ключ.
Давайте посмотрим как это сделать:
Для начала я сгенерирую непосредственно токен, который мы и будем ломать. Сделать это можно на том же сайте jwt.io:
Как видим, ключ-фраза здесь очень слабая - “test1234”. Сбрутить такую фразу проще простого. На практике такое врятли встретишь, но для примера самое оно.
Попробуем взломать токен методом переброра
Для этого нам потребуется сам токен и программа hascat, не ниже версии 5.0. В специализированных дистрибутивах hascat уже предустановлен. Если нет – можно либо скачать с гитхаба вот тут:
Либо поставить из репозиториев (debian-подобная команда):
Первое что нам нужно сделать – копируем токен и сохраняем в файл в формате txt. Я сделаю это в файл jwt.txt:
Далее потребуется словарь. Этот момент уже индивидуальный. В интернете огромное количество словарей, да и в спец дистрибутивах имеется набор словарей на разные случаи жизни.
Для тестов я возьму небольшой словарь на 100 слов, в конец которого и помещу валидный пароль - test1234:
После того, как словарь готов и токен записан можно приступать к перебору. Команда для начала атаки будет выглядеть вот так:
Где:
jwt.txt – наш txt файл с токеном.
-m 16500 – режим работы hascat. Этот ключ сообщает программе о том, что мы собираемся атаковать именно JWT
-a 3 – это профиль рабочей нагрузки. Грубо говоря, определяет то, насколько сильно перебор будит грузить ваше железо.
После запуска придется какое-то время подождать, пока прога пробежится по словарю и перепробует пароли, пока не найдет валидный. В случае успеха вы увидите статус cracked и результат в виде токен:секретная фраза:
В случае, если вы по какой-то причине не сохранили данные- не волнуйтесь, hashcat сделал это за вас. Для того чтобы посмотреть информацию по уже взломанному токену, просто запустите всю ту же команду, но добавьте в конце опцию –show. Так как hashcat хранит информацию о том, что он уже взломал, заместо нового процесса перебора вы сразу увидите результат
Причем, тут hashcat умеет работать со всеми алгоритмами HS, вне зависимости от длинны ключа, то есть и 256 и 384 и 512 бит. И никакие дополнительные флаги для этого не нужны, программа сама все определит:
Но, не все так гладко. Описаный выше способ будет работать только в том случае, если ключ перед использованием не был зашифрован в base64. (Вспоминаем третий этап создания токена)
В случае, если мы попытаемся сбрутить уже созданный таким образом токен по тому же алгоритму, hashcat пошлет нас лесом, и скажет что валидный пароль не найден, даже если таковой будет присутствовать в словаре:
2.Подмена алгоритма на none (CVE-2015-2951)
Следующий способ подделки токена чуть менее очевиден. Его суть заключается в том, что проверка алгоритма шифрования на сервере может быть настроенна не корректно. Проблема заключается в том, что сервер может не проверять, то ли шифрование используется, которое было установленно изначально. И если это так, это может здорово сыграть на руку атакующему.
Помните, выше говорилось про то, что токен может быть зашифрован как алгоритмом с двумя ключами, так и с одним. Так вот, есть еще третий вариант – токен может не иметь подписи вовсе. То есть, заголовок alg может быть равен параметру none. В этом случае, подпись токену не требуется, и можно подменить данные даже не зная ключей, так как алгоритм шифрования будет изменен. Выглядит это следующим образом:
Предположим у нас есть токен следующего вида:
И мы хоти подделать два поля – id и name. Id на “0” и name на “аdmin”, дабы выдать себя за администратора. Но просто поменять значение пэйлоада мы не можем, так как подпись совпадать не будет.
Поэтому, мы можем попробовать избавиться от подписи. Есть уязвимость, которую могут допустить разработчики, в результате которой алгоритм не задан жестко и пользователь может его подменить. Для этого нужно для начала поменять параметр alg в значение none. А затем избавится от третьей части токена – сигнатуры. В итоге, токен будет состоять только из двух первый частей – заголовка и полезной нагрузки, без подписи:
Сайт jwt.io не позволят использовать в токене alg=none, и при попытке сформировать такой токен выдает ошибку:
Но никто не мешает вручную составить две части токена, просто закодировав содержимое в base64 и разделив обе части точкой.
Так же, есть инструмент который может облегчить эту и другие задачи, но о нем в конце статьи.
3. Подпись открытым ключом. (CVE-2016-10555)
Следующий способ атаковать токен тоже связан с подменой алгоритма. Но в этот раз мы не полностью обнуляем подпись, а как бы откатываем ее на ступень назад. Суть этой атаки заключается в том, что мы меняем алгоритм с ассиметричного, где используются два ключа – открытый и закрытый, на симметричный, где ключ всего один. И в некоторых случаях проверка на стороне сервера может быть реализована с ошибками, что позволит при смене алгоритма, использовать для подписи при алгоритме HS публичный ключ алгоритма RS. А так как публичный ключ в ассиметричных протоколах “секретной” информацией не является, пользователь может без особых проблем получить к нему доступ.
Вот как это будет выглядеть на примере с алгоритмом RS:
Возьмем для примера вот такой токен, с используемым алгоритмом RS256. Как видим, для подписи требуется два ключа – открытый или закрытый:
Возьмем два дефолтных ключа, любезно нам предоставленные сайтом jwt для примера, и с их помощью подпишем токен:
теперь вспоминаем что говорилось ранее – подписать токен можно только при наличии закрытого ключа, открытый же ключ не должен держаться в секрете. Представим, что пользователь имеет токен и открытый ключ. Что далее ? Как подписать токен имея только один открытый ключ ?
Для начала возьмем первые две части токена, откинув подпись, она больше не понадобится. Так же, в заголовке нужно поменять тип используемого алгоритма, с RS на HS.
После этого кодируем каждую из двух частей в base64 и соединяем в токен, разделив точкой. Пока что все стандартно. В итоге мы получим первые две части токена:
Затем берем открытый ключ и перекинем его в HEX представление. Сделать это можно при помощи, например, стандартной python-консоли:
Где key нужно заменить на публичный ключ.
(Учтите что при копировании ключа, например, с сайта или документа, перед обработкой из него нужно будет удалить все лишние пробелы)
После того, как мы получаем хекс-представление ключа, можно попробовать сгенерировать подпись при помощи open-ssl. Делается это опять же дефолтными программами linux-систем:
При вводе первых двух частей jwt обязательно удалите последнюю точку!
После всех проведенных манипуляций мы получаем строку вида:
Далее, все что остается – добавить полученную подпись к первым двум частям. В итоге получим сам токен:
Попробуем проверить, будет ли токен считаться валидным при использованни алгоритма HS. Проверять будем на сайте jwt. В качестве пароля будем использовать наш открытый ключ, полученный изначально еще при другом алгоритме. И еще нужно обязательно включить base64 кодировку ключа.
И после всего мы получаем подтверждение что наш токен валидный:
Автоматизация:
После того, как мы разобрались с ручной эксплутацией большинства популярных векторов атак на jwt, можно поговорить и об оптимизации этих действий. Разумеется, делать все всегда ручками не обязательно. И в этом нам поможет инструмент jwt_tool. Скачать можно с гитхаба вот тут
https://github.com/ticarpi/jwt_tool
Сам инструмент работает в консольном режиме и умеет много интересных вещей. И даже те вещи, о которых я не говорил подробно в силу локальности таких уязвимостей. Например, атака библиотеки cisco node-jose младше версии 0.11.0 , в которой можно было подделать ключ при помощи ключа, встроенного в сам токен (CVE-2018-0114), или атака на СУБД InfluxDB раньше версии 1.6.7 в которой была проблема в том, что токен с пустым ключом мог быть признан валидным (CVE-2019-20933)
Ну, переходим к инструменту. Сам процесс установки довольно простой – копируем скрипт с гитхаба:
даем разрешение на запуск:
устанавливаем зависимости:
И все, инструмент готов к работе.
Для начала давайте посмотрим как, например, реализовать самую простую атаку – подмена алгоритма на nul:
Для этого нам потребуется следующая команда:
где в ключе X передается параметр, указывающий какую уязвимость мы хотим использовать. Согласно мануалу – уязвимость с alg=none, это значение параметра X установленное в “a”
В результате мы получаем аж четыре токена, в которых заголовок alg установлен по разному (none, None, NONE, nOnE), что может помочь обойти некоторые проверки.
Процесс подписи токена публичным ключом инструмент тоже может автоматизировать. Вот как это выглядит:
Для начала мы сохраняем публичный ключ в файл. В моем случае это public.pem
Ну и далее просто вводим следующую комманду:
Где:
HS256 – это тип алгоритма, который будет использован при подписи,
А через ключ -pk указывается путь к файлу с публичным ключом
В результате получаем сгенерированный токен, подписанный публичным ключом.
Помимо этого у инструмента еще много возможностей. Например он так же может реализовать перебор паролей (за скорость не скажу, так как предпочитаю всетаки проверенные вещи по типу hashcat), но в комплекте даже идет небольшой словарик с популярными ключами под токены, так что сама возможность интересная, если не хочется дергать серьезные инструменты и железо.
Еще инструмент может в различные другие эксплойты, их список можно найти в хелпе, и так же, разумеется, может помочь генерировать новые токены вполне легально, при помощи подписи ключом. Да и в целом, jwt_tool может очень помочь сэкономить время в процессе проверки токенов, если разобраться как им пользоваться.
(Автор не гарантиурет 100 процентной чистоты, безопасности, эффективности и невьебнности инструмента. Вся возможная “лесть” в адресс тулзы – лишь личное мнение, основаное на опыте работы с инструментом. Юзайте на свой страх и риск)
Заключение
Атаки на JWT-токены скорее не имеют расчета на массовость, а имеют смысл при точечных атаках. Врятли вы сможете придумать какие-то дорки, которые будут искать токены, уязвимые именно к подделке, разве что будете искать уязвимые библиотеки или ПО, которое связано с такими токенами и об уязвимостях в котором вам известно. В основном же – токены, это как правило потенциальный ключ к какой-то одной конкретной цели.Когда вы крутите какое-то одно определенное приложение, и видите что оно использует jwt – всегда лучше проверить этот момент, используя все то, что было описано выше. Сама по себе технология достаточно активно используется на большом количестве ресурсов, поэтому поле для экспериментов достаточно большое. Удачи вам во взломах !
Ну а я с темой JSON-WEB-токенов и атак на них на этом заканчиваю, всем добра !
(с) Urob0ros, специально для форума xss.pro
Всех приветствую ! Сегодня, в рамках этой статьи хотелось бы поднять достаточно интересную тему, касающуюся JWT или JSON Web Tokens, а точнее - разобрать ошибки разработчиков, которые реализуют эту технологию, которые могут привести к взлому веб-приложения. В случае успешной атаки, хакер сможет создавать новые токены, выдавая себя за других пользователей, что само по себе подразумевает почти полный захват приложения. Ведь таким образом можно выдать себя и за администратора приложения, и за других пользователей, получив при этом доступ к их личным данным, и много чего еще.
Сама же технология сейчас достаточно активно используется, так что умение атаковать такие токены точно лишним не будет. Разберемся какие существуют популярные уязвимости у токенов, как их использовать, и при помощи какого инструмента можно автоматизировать процесс. Поехали!
Теория
Начать, пожалуй, стоит с того, что вообще такое JWT.
Возможно, копаясь по каким-нибудь сайтам, в заголовках вы могли встретить что-то подобное:
Это и есть JWT собственной персоной. Давайте подробно разберемся что это такое и как работает:
JWT – (JSON Web Tokens) – это технология, которая добавляет в заголовки http-запросов уникальный отпечаток, основаный на формате JSON. Добавляется он обычно либо в собственном параметре, либо так же может передаваться в cookies. Этот отпечаток служит для передачи информации о пользователях и служит идентификатором для веб-приложения. Вся структура отпечатка основана на JSON формате.
Сам принцип работы токена достаточно прост – приложение формирует токен, который передает пользователю, и который в дальнейшем крепится к каждому запросу пользователя, являясь по сути цифровым отпечатком пользователя.
Основным отличием JSON токенов, от других подобных технологий, является то, что при таком подходе не требуется храненя каких-либо данных для сверки на сервере. Подлинность токена проверяется на основе подписи (подробнее о ней далее). То есть, приложение проверяет полученный токен, просто проверив прикрепленную подпись, которая высчитывается определенным алгоритмом, и служит гарантом того, что токен сформирован именно на сервере, а не создан пользователем, в попытке выдать себя за другого. Если подпись проходит проверку – токен считается валидным и данные из него используются для дальнейшей работы, если нет – то вполне логично что с таким токеном приложение работать не будет.
Давайте посмотрим что вообще из себя представляет такой токен. Сам токен состоит из трех частей:
1. header
2. payload
3. signature
Чуть более подробно поговорим о каждой из них, а затем соберем их воединно:
1. Header
header – это часть токена, которая сообщает две вещи: первая, что это непосредственно токен, а вторая – алгоритм шифрования, который используется для подписи токена.
Сама часть header выглядит вот так:
{ "alg": "HS256", "typ": "JWT"}typ заголовок нам сообщает что перед нами непосредственно JWT-токен, а вот заголовок alg говорит о том, какое шифрование используется для подписи токена. Первые две буквы – это тип используемого шифрования, а последующие три цифры – длина ключа в битах.
Вариантов используемого шифрования, равно как и значения alg может быть много. И вот в чем разница:
HS, он же HMAC-SHA, основанный на SHA– протоколе хэширования. Этот алгоритм использует одну ключевую фразу для генерации подписи, поэтому данная фраза всегда должна держаться в секрете, так как с ее помощью можно подписывать токены.
RS, он же RSA, алгоритм подписи, опо сути являющийся тем же RSA –достаточно популярным ассиметричным протоколом шифрования. Этот алгоритм может использоваться как для шифрования данных, так и для подписи. В случае с шифрованием данных, для шифрования данных используется один ключ – открытый, а для дешифровки – другой, закрытый. Причем, открым ключом можно зашифровать данные, но расшифровать его при помощи этого ключа уже не получится, и соответсвенно наоборот – при помощи закрытого ключа можно только расшифровать данные, но зашифровать нельзя. В этом вся суть ассиметричного шифрования. Конкретно в случае с JWT используется не шифрование,а подпись по алгоритму шифирования, и все работает несколько иначе, но углубляться в криптографию смысла здесь нет. Важно понимать только то, что открытый ключ, что в случае с шифрованием, что с подписью, может спокойно передаваться, так как он не является чувствительной информацией, при помощи которой можно получить доступ к данным. Этот метод шифрования считается более безопасным, но не смотря на это, в случае с JWT он тянет за собой проблему, о которой поговорим позже.
Помимо этих двух существуют и менее популярные алгоритмы ES и PS. Об этих алгоритмах особо подробно знать ничего не обязательно, важно лишь то, что они тоже ассиметричны и используют два ключа – открытый и закрытый.
Все вышеперечисленные протоколы в JWT поддерживают длинну ключей 256 384 и 512 бит. Кроме PS, он поддерживает только 256 и 384 битные ключи.
2.Payload
Следующая часть токена – payload, или полезная нагрузка. Вопреки мнению некоторых новичков, этот термин используется не только для того, чтобы обозначить вредоносные нагрузки при эксплуатации каких-то уязвимостей
. Payload может быть вполне мирным и обозначает данные, которые передаются внутри какой-либо структуры. В нашем случае в payload’e содержится вся основная ифнормация токена, ради которой он и существует: пользователь, приложение, которое отправило токен, время жизни токена и т.д. Все эти пункты внутри полезной нагрузки называются заявками (JWT-claims). Каждый разработчик сам определяет какие заявки вкладывать в токен. На основании наиболее частых и правильных заявок составлен список основных claim’ов, ознакомиться с ним можно, например, на википедии:https://en.wikipedia.org/wiki/JSON_Web_Token#Standard_fields
Однако, ни одно из этих полей не является обязательным. Разработчик сам определяет какие из этих полей включать в токен, а какие там и не нужны.
Сама часть токена с полезной нагрузкой выглядит так:
{ "userId": "000001", "name": "John Doe" }3. signature
Третья часть токена – сигнатура или подпись. Эта часть токена, по сути является подписью, доказывающей подлинность токена, и заодно закрытым замком к его изменению.
Сама подпись составляется в три этапа и состоит из двух основных частей. Процесс создания происходит так:
Сначала составляется основная часть токена – непосредственно подпись. Она состоит из первых двух частей токена – header’a и payload’a, закодированных в base 64 и разделенных точкой. То есть, выглядит в псевдокоде это примерно так:
base64(header).base64(payload)Далее все зависит от выбранного типа шифрования. Если протокол ассиметричный – создается пара открытый и закрытый ключ, а если симметричный – только закрытый.
Ну и после создания ключа/ключей все предыдущие части сигнатуры соединяются в одну очень просто – берется первая часть токена и подписывается выбранным алгоритмом, при помощи выбранных создателем ключей.
Сама подпись является гарантом того, что токен не был подделан. Мы можем изменить содержимое первых двух частей токена (как именно будет рассказано далее) без особых проблем, но суть в том, что тогда должна будет поменяться и подпись. А изменить подпись не зная ключей не получится. Получив токен, приложение самостоятельно вычисляет подпись и сравнивает полученное значение с тем, что в токене. Если они не совпадают – значит токен был подделан.
Важный момент: для дополнительной защиты токена, при использовании алгоритма HS, т.е. алгоритма подписи с одним ключом шифрования, может быть использована кодировка секретной фразы в base64 перед подписью.
Для чего это нужно узнаете чуть далее, когда будем рассматривать атаки на токены. Пока просто учтите это момент
Создание токена:
Ну и далее все части токена обьединяются в одну. Для этого первые две части – header и payload кодируются в base64 и каждая часть токена отделяется от других точкой.
В результате мы и получим сам токен, вида:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIwMDAwMDEiLCJuYW1lIjoiSm9obiBEb2UifQ.Bxx43-CwsoMznr8LxI-kvzBmiWvATy9pem-HRU_BZ9wДальнейшая работа с токенами:
Далее нам нужно понимать что и как делать с токенами, если мы собираемся как-то раскручивать этот вектор. А именно, как просмотреть содержимое токена, как сгенерировать новый токен и т.д. А так как JWT – стандартизированная технология, то все jwt токены будут отвечать определенным требования.
Так как первые две части токена не шифруются, а лишь кодируются в base64, их содержимое можно без проблем просмотреть. Именно поэтому, в токенах не рекомендуется передавать чувствительную информацию, которую не должен видеть никто посторонний.
Просмотреть содержимое токена, а точнее первых двух его частей можно на вот этом сайте:
Для этого достаточно вбить токен в левое поле, а в трех правых полях мы получим три части токена соответсвенно.
Там же, можно генерировать новые токены, менять содержимое старых и т.д, просто манипулируя с данными в полях справа и слева. Ну и, так как алгоритм проверки валидности токена везде один, прямо на сайте мы так же сможем проверить, валидным ли является токен, или приложение заподозрит что мы что-то изменили.
Атаки на токены
В этой части статьи рассмотрим атаки на токены. Есть разные способы атак, но желаемый результат почти всегда один – подделать токен, дабы выдать себя за другого пользователя. Сами атаки я расположил в порядке от более старых к более новым, и прикрепил номера CVE, чтобы вы могли сами глубже покопать, если захотите. Поехали:
1. Брутфорс закрытого ключа в SHA.
Первое, и что самое логичное, что можно предположить – если для подписи токена используется симметричное шифрование, то можно пойти самым простым путем – попробовать получить ключ, при помощи которого можно будет сгененрировать новый токен. Самый простой и легкий, с точки зрения реализации, способ – это брутфорс. Причем, брутить сам ключ размером от 256 до 512 бит нас никто не заставляет, достаточно получить SECRET_KEY фразу, которая по сути – просто пароль, который служит для подписи ключа. Зная такой пароль, можно как бы “разблокировать” ключ.
Давайте посмотрим как это сделать:
Для начала я сгенерирую непосредственно токен, который мы и будем ломать. Сделать это можно на том же сайте jwt.io:
Как видим, ключ-фраза здесь очень слабая - “test1234”. Сбрутить такую фразу проще простого. На практике такое врятли встретишь, но для примера самое оно.
Попробуем взломать токен методом переброра
Для этого нам потребуется сам токен и программа hascat, не ниже версии 5.0. В специализированных дистрибутивах hascat уже предустановлен. Если нет – можно либо скачать с гитхаба вот тут:
GitHub - hashcat/hashcat: World's fastest and most advanced password recovery utility
World's fastest and most advanced password recovery utility - hashcat/hashcat
github.com
sudo apt install hashcatПервое что нам нужно сделать – копируем токен и сохраняем в файл в формате txt. Я сделаю это в файл jwt.txt:
Далее потребуется словарь. Этот момент уже индивидуальный. В интернете огромное количество словарей, да и в спец дистрибутивах имеется набор словарей на разные случаи жизни.
Для тестов я возьму небольшой словарь на 100 слов, в конец которого и помещу валидный пароль - test1234:
После того, как словарь готов и токен записан можно приступать к перебору. Команда для начала атаки будет выглядеть вот так:
hashcat -m 16500 -a 3 jwt.txt wordlist.txtГде:
jwt.txt – наш txt файл с токеном.
-m 16500 – режим работы hascat. Этот ключ сообщает программе о том, что мы собираемся атаковать именно JWT
-a 3 – это профиль рабочей нагрузки. Грубо говоря, определяет то, насколько сильно перебор будит грузить ваше железо.
После запуска придется какое-то время подождать, пока прога пробежится по словарю и перепробует пароли, пока не найдет валидный. В случае успеха вы увидите статус cracked и результат в виде токен:секретная фраза:
В случае, если вы по какой-то причине не сохранили данные- не волнуйтесь, hashcat сделал это за вас. Для того чтобы посмотреть информацию по уже взломанному токену, просто запустите всю ту же команду, но добавьте в конце опцию –show. Так как hashcat хранит информацию о том, что он уже взломал, заместо нового процесса перебора вы сразу увидите результат
Причем, тут hashcat умеет работать со всеми алгоритмами HS, вне зависимости от длинны ключа, то есть и 256 и 384 и 512 бит. И никакие дополнительные флаги для этого не нужны, программа сама все определит:
Но, не все так гладко. Описаный выше способ будет работать только в том случае, если ключ перед использованием не был зашифрован в base64. (Вспоминаем третий этап создания токена)
В случае, если мы попытаемся сбрутить уже созданный таким образом токен по тому же алгоритму, hashcat пошлет нас лесом, и скажет что валидный пароль не найден, даже если таковой будет присутствовать в словаре:
2.Подмена алгоритма на none (CVE-2015-2951)
Следующий способ подделки токена чуть менее очевиден. Его суть заключается в том, что проверка алгоритма шифрования на сервере может быть настроенна не корректно. Проблема заключается в том, что сервер может не проверять, то ли шифрование используется, которое было установленно изначально. И если это так, это может здорово сыграть на руку атакующему.
Помните, выше говорилось про то, что токен может быть зашифрован как алгоритмом с двумя ключами, так и с одним. Так вот, есть еще третий вариант – токен может не иметь подписи вовсе. То есть, заголовок alg может быть равен параметру none. В этом случае, подпись токену не требуется, и можно подменить данные даже не зная ключей, так как алгоритм шифрования будет изменен. Выглядит это следующим образом:
Предположим у нас есть токен следующего вида:
И мы хоти подделать два поля – id и name. Id на “0” и name на “аdmin”, дабы выдать себя за администратора. Но просто поменять значение пэйлоада мы не можем, так как подпись совпадать не будет.
Поэтому, мы можем попробовать избавиться от подписи. Есть уязвимость, которую могут допустить разработчики, в результате которой алгоритм не задан жестко и пользователь может его подменить. Для этого нужно для начала поменять параметр alg в значение none. А затем избавится от третьей части токена – сигнатуры. В итоге, токен будет состоять только из двух первый частей – заголовка и полезной нагрузки, без подписи:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjMiLCJuYW1lIjoiSm9obiBEb2UifQ.HAFhtRnCtnz9TCTMV4FFaiU_G9n6ENSF_VMPuFGDnLEСайт jwt.io не позволят использовать в токене alg=none, и при попытке сформировать такой токен выдает ошибку:
Но никто не мешает вручную составить две части токена, просто закодировав содержимое в base64 и разделив обе части точкой.
Так же, есть инструмент который может облегчить эту и другие задачи, но о нем в конце статьи.
3. Подпись открытым ключом. (CVE-2016-10555)
Следующий способ атаковать токен тоже связан с подменой алгоритма. Но в этот раз мы не полностью обнуляем подпись, а как бы откатываем ее на ступень назад. Суть этой атаки заключается в том, что мы меняем алгоритм с ассиметричного, где используются два ключа – открытый и закрытый, на симметричный, где ключ всего один. И в некоторых случаях проверка на стороне сервера может быть реализована с ошибками, что позволит при смене алгоритма, использовать для подписи при алгоритме HS публичный ключ алгоритма RS. А так как публичный ключ в ассиметричных протоколах “секретной” информацией не является, пользователь может без особых проблем получить к нему доступ.
Вот как это будет выглядеть на примере с алгоритмом RS:
Возьмем для примера вот такой токен, с используемым алгоритмом RS256. Как видим, для подписи требуется два ключа – открытый или закрытый:
Возьмем два дефолтных ключа, любезно нам предоставленные сайтом jwt для примера, и с их помощью подпишем токен:
теперь вспоминаем что говорилось ранее – подписать токен можно только при наличии закрытого ключа, открытый же ключ не должен держаться в секрете. Представим, что пользователь имеет токен и открытый ключ. Что далее ? Как подписать токен имея только один открытый ключ ?
Для начала возьмем первые две части токена, откинув подпись, она больше не понадобится. Так же, в заголовке нужно поменять тип используемого алгоритма, с RS на HS.
После этого кодируем каждую из двух частей в base64 и соединяем в токен, разделив точкой. Пока что все стандартно. В итоге мы получим первые две части токена:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjMiLCJuYW1lIjoiSm9obiBEb2UifQ.Затем берем открытый ключ и перекинем его в HEX представление. Сделать это можно при помощи, например, стандартной python-консоли:
Python:
import base64
base64.base64decode(“key”).hex()Где key нужно заменить на публичный ключ.
(Учтите что при копировании ключа, например, с сайта или документа, перед обработкой из него нужно будет удалить все лишние пробелы)
После того, как мы получаем хекс-представление ключа, можно попробовать сгенерировать подпись при помощи open-ssl. Делается это опять же дефолтными программами linux-систем:
Bash:
echo -n "Первые_две_части_jwt" | openssl dgst -sha256 -mac hmac -macopt hexkey:<hex_ключа> | cut -d" " -f2 | xxd -r -p | base64 -w0 |sed 's/+/-/g; s/\//_/g; s/=/\n/g;'После всех проведенных манипуляций мы получаем строку вида:
Далее, все что остается – добавить полученную подпись к первым двум частям. В итоге получим сам токен:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjMiLCJuYW1lIjoiSm9obiBEb2UifQ.Xas-85xqr5av_SbgLJO9bQ34zIdkN9tGlo4m1mFUe30Попробуем проверить, будет ли токен считаться валидным при использованни алгоритма HS. Проверять будем на сайте jwt. В качестве пароля будем использовать наш открытый ключ, полученный изначально еще при другом алгоритме. И еще нужно обязательно включить base64 кодировку ключа.
И после всего мы получаем подтверждение что наш токен валидный:
Автоматизация:
После того, как мы разобрались с ручной эксплутацией большинства популярных векторов атак на jwt, можно поговорить и об оптимизации этих действий. Разумеется, делать все всегда ручками не обязательно. И в этом нам поможет инструмент jwt_tool. Скачать можно с гитхаба вот тут
https://github.com/ticarpi/jwt_tool
Сам инструмент работает в консольном режиме и умеет много интересных вещей. И даже те вещи, о которых я не говорил подробно в силу локальности таких уязвимостей. Например, атака библиотеки cisco node-jose младше версии 0.11.0 , в которой можно было подделать ключ при помощи ключа, встроенного в сам токен (CVE-2018-0114), или атака на СУБД InfluxDB раньше версии 1.6.7 в которой была проблема в том, что токен с пустым ключом мог быть признан валидным (CVE-2019-20933)
Ну, переходим к инструменту. Сам процесс установки довольно простой – копируем скрипт с гитхаба:
git clone https://github.com/ticarpi/jwt_tool.gitдаем разрешение на запуск:
chmod +x jwt_tool.pyустанавливаем зависимости:
sudo pip3 install termcolor cprint pycryptodomex requestsИ все, инструмент готов к работе.
Для начала давайте посмотрим как, например, реализовать самую простую атаку – подмена алгоритма на nul:
Для этого нам потребуется следующая команда:
./jwt_tool.py <jwt> -X aгде в ключе X передается параметр, указывающий какую уязвимость мы хотим использовать. Согласно мануалу – уязвимость с alg=none, это значение параметра X установленное в “a”
В результате мы получаем аж четыре токена, в которых заголовок alg установлен по разному (none, None, NONE, nOnE), что может помочь обойти некоторые проверки.
Процесс подписи токена публичным ключом инструмент тоже может автоматизировать. Вот как это выглядит:
Для начала мы сохраняем публичный ключ в файл. В моем случае это public.pem
Ну и далее просто вводим следующую комманду:
./jwt_tool.py <jwt> -S hs256 -k public.pemГде:
HS256 – это тип алгоритма, который будет использован при подписи,
А через ключ -pk указывается путь к файлу с публичным ключом
В результате получаем сгенерированный токен, подписанный публичным ключом.
Помимо этого у инструмента еще много возможностей. Например он так же может реализовать перебор паролей (за скорость не скажу, так как предпочитаю всетаки проверенные вещи по типу hashcat), но в комплекте даже идет небольшой словарик с популярными ключами под токены, так что сама возможность интересная, если не хочется дергать серьезные инструменты и железо.
Еще инструмент может в различные другие эксплойты, их список можно найти в хелпе, и так же, разумеется, может помочь генерировать новые токены вполне легально, при помощи подписи ключом. Да и в целом, jwt_tool может очень помочь сэкономить время в процессе проверки токенов, если разобраться как им пользоваться.
(Автор не гарантиурет 100 процентной чистоты, безопасности, эффективности и невьебнности инструмента. Вся возможная “лесть” в адресс тулзы – лишь личное мнение, основаное на опыте работы с инструментом. Юзайте на свой страх и риск)
Заключение
Атаки на JWT-токены скорее не имеют расчета на массовость, а имеют смысл при точечных атаках. Врятли вы сможете придумать какие-то дорки, которые будут искать токены, уязвимые именно к подделке, разве что будете искать уязвимые библиотеки или ПО, которое связано с такими токенами и об уязвимостях в котором вам известно. В основном же – токены, это как правило потенциальный ключ к какой-то одной конкретной цели.Когда вы крутите какое-то одно определенное приложение, и видите что оно использует jwt – всегда лучше проверить этот момент, используя все то, что было описано выше. Сама по себе технология достаточно активно используется на большом количестве ресурсов, поэтому поле для экспериментов достаточно большое. Удачи вам во взломах !
Ну а я с темой JSON-WEB-токенов и атак на них на этом заканчиваю, всем добра !
(с) Urob0ros, специально для форума xss.pro
