Comments 14
спасибо. Скажите, но ведь если мы имеем возможность использовать man in middle, а также исправить простейшую строчку приложения в XML ресурсах Network Security Config, прописав вручную там доверие только на наш поддельный сертификат, то слушать трафик все равно? Например, для поиска бекэнда и уязвимостей в приложении.
Какие методы защиты могут быть в этом случае? Или же активный клиент со вшитым сертификатом может передавать fingerprint или часть сертификата, а мы его перехватить не сможем и передать дальше/
Всё верно, есть защита в виде SSL Pinning и есть способы эту защиту сломать.
Как я упоминал в статье, для меня пиннинг - это в первую очередь защита клиента от различных попыток перехватить его трафик в недоверенной сети. Попытка использовать этот механизм для защиты трафика от злоумышленников, которые хотят поискать уязвимости в backend, без дополнительных мер защиты, не приведет к успеху.
Для того, чтобы таким образом защитить серверную часть от нелегитимных запросов можно использовать различные способы, например подпись каждого request (для проверки, что он не был изменен) или использование дополнительных сервисов, которые на основе обмена ключами позволят установить соединение только из своего приложения.
Способов может быть много, но простой пиннинг для защиты backend от злонамеренных запросов не поможет (ну может чуть усложнит первый шаг), но тут поможет только комплекс мер.
Очень круто! Спасибо за статью!
Благодарю! Все по полочкам
Так как же обходить корректно настроенный SSL Pinning?
На самом деле, ответ на этот вопрос тянет на отдельную статью, так как способов реализации и библиотек огромное множество и везде свои нюансы.
Но если в целом отвечать на вопрос, то есть способы открутить Pinning, начиная от различных скриптов для фреймворка Frida (вот один из множества примеров), заканчивая статьями, как это сделать для Flutter, например (там в нативной библиотеке люди реверсят и подменяют вызовы).
Есть более интересные подходы, например, попробовать той же Frida отлавливать и сохранять сессионные ключи и потом расшифровывать трафик (тоже много-много нюансов, но подход тоже имеет право на жизнь).
Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616
Уже HTTP/3 на подходе
История версий протоколов SSL/TLS
На картинке TLS 1.3 upcoming тоже устарело
Я правильно понимаю, что во всех примерах MITM атак пользователь ставил себе левый сертификат? Т.е. направленные антенны, фейковые точки доступа, Captive-порталы это все еще пол дела, пока жертва не установит сертификат злоумышленника? Если не ошибаюсь, в процессе установки требуется подтверждение пользователя и андроид, например, в конце еще покажет предупреждение, что сертификат подозрительный. Т.е. тут расчет на совсем наивных или все-таки есть способы сделать это в каком-то тихом режиме? Либо злоумышленник генерирует настоящий доверенный сертификат, но тогда вся система этих сертификатов скомпрометирована.
Я правильно понимаю, что во всех примерах MITM атак пользователь ставил себе левый сертификат? Т.е. направленные антенны, фейковые точки доступа, Captive-порталы это все еще пол дела, пока жертва не установит сертификат злоумышленника?
Да, все именно так, пользователь должен обязательно поставить сертификат злоумышленника, а в настройках приложения должно стоять доверие пользовательским сертификатам.
Если не ошибаюсь, в процессе установки требуется подтверждение пользователя и андроид, например, в конце еще покажет предупреждение, что сертификат подозрительный. Т.е. тут расчет на совсем наивных или все-таки есть способы сделать это в каком-то тихом режиме?
Нет, в тихом режиме не получится, Google и Apple об этом позаботились. Но тут расчет на тех людей, кто не сильно читает, что ему говорит система. На Captive-портале можно написать, что "вход осуществляется только при наличие сертификата безопасности, чтобы злоумышленники не могли вас обмануть!". Или что-то подобное, что большинство пользователей благополучно и сделают. Плюс, если добавить пару заголовков, то при скачивании визард по импорту сертификатов запустится автоматически. По крайней мере на 6-7 Android так было.
Либо злоумышленник генерирует настоящий доверенный сертификат, но тогда вся система этих сертификатов скомпрометирована.
Тут да, тогда зависит от того, что проверяет приложение (какой сертификат). Но в целом это не так просто сделать, особенно, если сертификат участвует в Certificate Transparency.
Это все касается только HTTPS, конечно, HTTP перехватывается только в путь. У нас был случай, когда все запросы в приложении были правильные и хорошие, а новости приложение получало по незащищенному протоколу. При этом в ответе получая HTML и отображая его в WebView, что позволило нам перехватить трафик и модифицировать ответ сервера, полностью повторив интерфейс приложения с формами логина и пароля.
Ну и не стоит забывать про разные корпоративные сети, где некоторые очень любят подменять сертификаты.
То есть, вся эта защита направленна на обычных пользователей, для которых иногда и слово сертификат не очень понятно и пренебрегать ей не стоит. Тем более и в Android и в iOS сделали достаточно много, чтобы реализация была проще.
Держи свой трафик в тайне. SSL Pinning — ещё раз о том же самом