M3-Insecure Communication
Вернуться назад

Ну что погнали дальше!!! Теперь перейдем к нашему любимому мужику, который любит стать по середине и наблюдать, если вы подумали про извращенца, который любит наблюдать, то я говорю не про него :-))) Этот мужик не просто наблюдает но и ворует ваши конфиденциальные данные, через незащищенные общественные сети и приложения, которыми вы пользуетесь, если они плохо написаны. В рейтинге OWASP TOP 10 эта уязвимость находиться на 3 месте.

Ну что разберем уязвимость M3-Insecure Communication. К ней подвержены пользователи, которые пользуются общественными сетями и не очень хорошо защищенными приложениями либо вовсе скачанное с пиратского ресурса, в котором установлено вредоносное ПО.

 

Как мы знаем, пользуясь мобильном приложением, пользователи обычно обмениваются данными с сервером, работает как и обычное веб приложение. Зачастую мобильные приложения не защищают сетевой трафик. Они могут использовать SSL / TLS во время аутентификации, но не в других местах. Это несоответствие приводит к риску перехвата данных и идентификаторов сеансов. Даже если вы используете безопасную передачу данных, это не означает, что в приложение оно правильно реализовано. Чтобы обнаружить основные недостатки, понаблюдайте за сетевым трафиком телефона. Установите какой нибудь инструмент перехвата запросов и понаблюдайте в каком виде передаются данные на сервер.

Перехват трафика

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

- Возможность установки сертификата CA прокси на устройстве.

- Приложение доверяет установленному пользователем сертификату.

- Возможность изменить конфигурацию Wi-Fi устройства.

- Обход SSL-закрепления (если конечно он вообще есть :-))), как правило сертификаты должны иметь достаточно длинный ключ, минимум 2048 бит. Они должны быть не истекшими, выданными доверенными центрами сертификации, а самое главное правильно настроенными на уровне сервера для работы с безопасными протоколами (TLS v1 является предпочтительным) и надо использовать наборы шифров RSA/AES256/SHA2).

 

Так переходим к практике. Для этого нам нужен Burp Suite и Genymotion

 

 

Настройка прокси между этими двумя приложениями

Начнем с этого инструмента:

1) установите Genymotion (если у вас Virtualbox установлен, то качайте пакет без виртуалки)

2) запустите приложение

3) создайте устройство на базе 5.0 Андроид, как это показано ниже (это связано с тем что именно на этой версии можно будет записать google сервисы, так как Genymotion не договорился с гуглом о присутствии гугловских сервисов у них в эмуляторах, а так как некоторые приложения просят эти сервисы из своих рассуждений, то эти приложения без этих сервисов работать не будут. Допустим у вас приложения которое должно определять вашу геолокацию и если у вас на эмуляторе не будет сервиса определения места, то и приложение ваше не будет работать, все зависит от того как ваши разрабы реализовывали приложуху. Как добавить гугл сервисы погуглите, долго писать просто)))

Как защититься:

- Применять SSL / TLS к транспортным каналам, которые будут использоваться мобильным приложением для передачи конфиденциальной информации в API или веб-службах.

- Используйте надежные комплекты шифров с соответствующей длиной ключа.

- Используйте сертификаты, подписанные доверенным центром сертификации.

- Всегда требовать проверки цепочки SSL.

- Устанавливайте безопасное соединение только после проверки личности сервера с использованием доверенных сертификатов в цепочке ключей.

- Оповещать пользователей через пользовательский интерфейс, если мобильное приложение обнаруживает недействительный сертификат.

- Не отправляйте конфиденциальные данные по альтернативным каналам (например, SMS, MMS или уведомления).

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

 

Особые рекомендации для iOS

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

- Убедитесь, что сертификаты действительны и закрыты при сбое.

- При использовании CFNetwork рассмотрите возможность использования Secure Transport API для обозначения сертификатов доверенных клиентов. Почти во всех ситуациях NSStreamSocketSecurityLevelTLSv1 следует использовать для более высокого уровня надежности шифра.

- После разработки убедитесь, что все вызовы NSURL (или оболочки NSURL) не допускают самозаверяющих или недействительных сертификатов, таких как метод класса NSURL setAllowsAnyHTTPSCertificate.

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

- При использовании метода NSURL соединение: willSendRequestForAuthenticationChallenge: теперь примет ваш сертификат.

 

Рекомендации для Android

- Удалите весь код после цикла разработки, который может позволить приложению принимать все сертификаты, такие как org.apache.http.conn.ssl.AllowAllHostnameVerifier или SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. Так как это эквивалентно доверию всем сертификатам.

- При использовании класса, который расширяет SSLSocketFactory, убедитесь, что метод checkServerTrusted правильно реализован, чтобы сертификат сервера был правильно проверен.

И ПОМНИТЕ ВСЕ ПОКАЗАННОЕ ВЫШЕ, СДЕЛАНО В ЦЕЛЯХ ОБУЧЕНИЯ!!!

МОЖНО ПРИМЕНЯТЬ ТОЛЬКО НА СВОИХ ПРОЕКТАХ, ПОСЛЕ РАЗРЕШЕНИЯ

Промокод на QA FEST

 

 

Оп-Оп-Оп, я тут заметил что в форме покупки билета на QAFest 2019 есть уязвимость,

введя слово                             

------->>>>>>> LOGIN <<<<<<<-------

в поле промокода, вы получите скидон -10%

Количество использования промокода не ограниченно в этом году вас ждет аж 6 потоков на разные направления QA с крутыми докладами от крутых спикеров  

gallery/logo_promo
gallery/выделение_139
gallery/выделение_146

4) установите Burp Suite

5) запустите приложение Burp Suite

6) перейдите во вкладку Proxy->Options

gallery/выделение_148

Все, мы настроили нашу бадю по перехвату запросов для дальнейших их изменений. Теперь запускаем любое приложение, которое общается с сервером. Допустим возьмем авторизацию страницу, вводим туда какие-то креденшелы и смотрим в Burp.

Хотите узнать больше о различных уязвимостях и инструментах для поиски этих же уязвимостей, чтоб сделать ваш проект безопасным, для ваших пользователей? 

Мы организовываем тренинги по OWASP TOP 10. 

Буду рад вас видеть на тренинге!

 

Программа тут

 

 

gallery/man-in-the-middle
gallery/выделение_077
gallery/burpsuite (1)
gallery/logo-genymotion-by-genymobile
gallery/выделение_079
gallery/выделение_080

После клика на кнопку edit, выбрать такие настройки, для настройки нашей прокси в Burp Suite.

gallery/выделение_081

7) Настроить проксю в мобильном эмуляторе или в реальном подключенном девайсе. Для этого запускаем наш эмулятор

gallery/выделение_087

Открываем настройку сети, и модифицируем под нашу прокси, которые мы настраивали в Burp Suite

gallery/выделение_088

Кликаем на пункт Modify network

gallery/выделение_089

В пункте 1 пропишем ip нашего компа, на котором подняли Burp Suite. В пункт 2 пишем порт, который указали в самом Burp Suite.

Остается малость теперь, в данной конфигурации, мы можем видеть в Burp Suite только трафик который ходит через http, но нам же и нужно ловить трафик https. Для этого нам нужно залить сертификат с Burpa в доверительные на телефон. 

Заходим в любой браузер пишем в строке урл http://Burp

gallery/выделение_090

Как мы видим выше, у вас должно получиться так. Затем кликаем по кнопке CA Certificate, пойдет скачка сертификата, но не спешите торопиться радоваться. Нам немного не подходит формат того сертификата для мобильного устройства, нам надо сменить расширение с der на crt. Один и вариантов это сделать это подконнектиться к девайсу с помощью команды adb connect ip.

В моем случаи adb connect 192.168.17.234.

После того как мы подконнектимся к нему, заходим в shell устройства, это делаем с помощью команды adb shell.

Далее заходим в директорию Download с помощью команды cd /mnt/sdcard/Download.

Далее делаем переформатирование сертификата с помощью команды mv cacert.der cacert.crt

gallery/выделение_092

У вас выйдет набор команд как на скрине выше

 

8) установка сертификата на телефоне

Для этого мы идем в настройки и там находим пункт Security-> в нем находим пункт Install from SD card -> Там находим наш сертификат по нашему имени под которым сохраняли с нужным нам уже расширением и устанавливаем его. 

gallery/выделение_093
gallery/выделение_094

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

gallery/выделение_095

Ну а если у вас при перехвате запроса вот такой вид, то можете считать что вы не уязвимы к этой уязвимости.

gallery/выделение_096