Comments 1
Хакатон закончился, подводим итоги. Активно участвовало в хакатоне буквально пару человек. С одной стороны это хорошо, если мы говорим о вознаграждении, с другой стороны это плохо, когда мы говорим о поиске уязвимостей. Но так или иначе, вознаграждения вполне честные и заслуженные. Чтобы не раскрывать имена/фамилии или какие-либо другие персональные данные, я попросил у участников никнеймы.
Первое место - TeaRot (73.334 рублей)
Второе место - vectorABY (51.666 рублей)
Найденные уязвимости/баги были следующие:
[TeaRot] Атака двух друзей HLM<->HLS.
Когда пользователь авторизуется в HLM он расшифровывает приватный ключ посредством ввода логина и пароля. Далее этот приватный ключ он отсылает к HLS. И начиная с этого момента, чтобы совершать последующие действия (например отправка/получение сообщений для внесения в БД) HLM всегда запрашивает у HLS публичный ключ. Это может привести к следующему сценарию:
HLM отправляет приватный ключ к HLS
HLM запрашивает в N-ом действии свой публичный ключ от HLS (подразумивая, что этот публичный ключ от переданного им ранее приватного ключа)
HLS отправляет к HLM совершенно иной публичный ключ, и совершает анонимизацию под совершенно другим приватным ключом
Протокол анонимизации работает всегда корректно, но сам пользователь под HLM фактически находится под другим аккаунтом.
Эксплуатировать уязвимость можно таким образом:
Существует три пользователя и две связи друзей: A <-> B, B <-> C, то есть B общается сразу с двумя друзьями.
Злоумышленник, располагая скомпромитированными приватными ключами A и C, может их поменять местами, и фактически пользователь A будет общаться за C, а C за A.
Также такой сценарий возможен не только в эксплуатации уязвимости, но и при неявном/неправильном проектировании других прикладных приложений вместе с HLM. Так например, если оба приложения имеют авторизацию, то одно из таковых приложений может сменить приватный ключ, и тем самым другое приложение уже не будет работать корректно.
Решением здесь является следующее:
Если авторизация находится на стороне прикладного приложения, то следует проверять публичный ключ, который перешёл от HLS с публичным ключом (полученным из расшифрованного приватного при авторизации). Таким образом, мы исключаем атаку выдачи некорректного публичного ключа.
Использовать промежуточный сервис, который бы отвечал за авторизацию всех прикладных приложений (такая идея у меня ранее действительно уже присутствовала). В таком случае не будет возникать события, когда несколько прикладных приложений перекрывают друг друга.
[TeaRot] Атака двух друзей HLM<->HLT.
Когда HLM запрашивает у HLT сообщения, то для начала HLM скачивает их хеши. Далее по запросам на хеши HLM получает от HLT сообщения и перенаправляет их к HLS. Тем не менее, HLM не проверяет целостность самого сообщения, а именно не сравнивает хеш предполагаемый и хеш получаемый. В таком сценарии, HLT может выдавать случайные хеши, но при этом всегда отсылать только конкретные сообщения.
В большей мере это не уязвимость, т.к. здесь эксплуатация может сводиться лишь к неправильно принятым сообщениям, либо сообщениям которые мы уже много раз получали. В таком сценарии HLS просто проигнорирует всё, что получит.
[TeaRot] Неправильное/невалидное API HLS, HLT.
Это уже конечно не уязвимость, но правильное замечание. Редактируя HLS, HLT иногда я забывал редактировать соответствующую документацию по API.
[TeaRot] Всегда в ответах: text/plain;
Это тоже из разряда бага/неправильного проектирования. Суть заключается в том, что HLS, HLT отправляют всегда ответы с text/plain форматом, даже если результатом их ответов является JSON. В итоге, браузеры, постман и прочие могут некорректно отображать сами результаты (в виде обычного текста, без структуризации).
[vectorABY] Небезопасное отправление/получение сообщений HLM<->HLM.
Когда HLM отправляет или получает сообщения, то таковые сообщения переходят или приходят от HLS непосредственно в открытом виде. Иными словами, безопасная коммуникация наблюдается лишь и только между двумя HLS, но не между двумя HLM. Более кратко это можно описать так: HLM -- [незашифрованное сообщение] --> HLS -- [зашифрованное сообщение] --> HLS -- [незашифрованное сообщение] --> HLM.
Но связь между HLM и HLM вполне можно сделать защищённой от HLS, т.к. HLM уже знает кому надо отправить сообщение или от кого она получает сообщение (т.к. HLS говорит об отправителе). Таким образом, HLM может зашифровать сообщение, передать его к HLS, тот в свою очередь преобразует данное сообщение в анонимизирующий трафик, передаст его другому HLS, а тот в свою очередь снимет анонимизацию и передаст к HLM зашифрованное сообщение, которое впоследствии будет расшифровано.
Иными словами, благодаря этому хаку мы уменьшаем уровень доверия к самому HLS, а также к потенциальному пассивному наблюдателю (в роли шпиона), находящимся на устройстве.
Тем не менее, решить данную проблему сложнее чем кажется. Суть заключается в том, что HLM работает по принципу HTTP-сервера, где сами же данные адресуемые от интерфейса к HLM незашифрованы. Эту проблему можно исправить, если создать приложение самодостаточное - либо десктопное, либо мобильное.
[vectorABY] Некорректное вычисление статичного размера сообщений в pkg/client.
Баг, в том плане, что некоторые байты при вычислении статичного размера сообщения мы просто не могли использовать.
Большая часть моментов уже была исправлена, а именно:
Атака двух друзей HLM<->HLS (с авторизацией внутри HLM, нужно будет также сделать авторизацию через отдельный сервис)
Атака двух друзей HLM<->HLT
Неправильное/невалидное API HLS, HLT
Всегда в ответах: text/plain
Небезопасное отправление/получение сообщений HLM<->HLM (ЧАСТИЧНО! т.к. HLM не был переведён на десктоп/мобильное приложение)
Некорректное вычисление статичного размера сообщений в pkg/client
Хакните HL и заработайте 125.000 рублей