7 ножей в спину web-отладки / forpes.ru

Главная
7 ножей в спину web-отладки

7 ножей в спину web-отладки

21.05.2024 12:55

A_J 0 866 Источник

Преамбула

Вообще наша компания занимается разработкой смартфонов и софта к ним для слепых и слабовидящих. Но порой возникают ситуации, когда приходится отлаживать не только свои приложения, но и разбираться с чужими. Обычно это происходит в случае, когда приложение глючит или не работает вовсе именно на наших телефонах. Поскольку наша аппаратная платформа не похожа на традиционные Android-смартфоны да и сам код фреймворка доработан рашпилем, мы готовы к подобным сюрпризам. Так случилось и в этот раз. Клиент жаловался, что у него есть проблемы с login-ом в одну из online-библиотек с аудио-книгами через Android-приложение. Поддержка попросила меня разобраться, есть ли в этом наша вина, или же нет.

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

1. Проблема воспроизводится не всегда.

Первым делом скачиваю приложение с Play Store и используя предоставленные пользователем параметры регистрируюсь в библиотеке. И, о чудо, login проходит без сучка без задоринки. Иду разбираться с поддержкой. Оказывается, радоваться рано. Надо пару тройку раз войти и выйти и... при очередной попытке входа получаю ошибку. М-да. Придется залезть глубже. Для начала посмотреть, происходит ли вообще взаимодействие с сайтом. Тут нет ничего сложного. Заходим на телефон через adb shell и запускаем tcpdump.

2. Для доступа к сайту используется SSL

>tcpdump
Нажимаем на кнопку "login" и...

IP 192.168.2.254.46904 > ds-195-123.dri-services.net.https: Flags [S], seq 600777635, win 65535, options [mss 1460,sackOK,TS val 525800818 ecr 0,nop,wscale 8], length 0 IP ds-195-123.dri-services.net.https > 192.168.2.254.46904: Flags [S.], seq 1294337794, ack 600777636, win 28960, options [mss 1460,sackOK,TS val 2084490719 ecr 525800818,nop,wscale 7], length 0 IP 192.168.2.254.46904 > ds-195-123.dri-services.net.https: Flags [.], ack 1, win 343, options [nop,nop,TS val 525800853 ecr 2084490719], length 0 IP 192.168.2.254.46904 > ds-195-123.dri-services.net.https: Flags [P.], seq 1:518, ack 1, win 343, options [nop,nop,TS val 525800856 ecr 2084490719], length 517 IP ds-195-123.dri-services.net.https > 192.168.2.254.46904: Flags [.], ack 518, win 235, options [nop,nop,TS val 2084490752 ecr 525800856], length 0

Увы, видим протокол https. Что ж, в современном WEB-е трудно ожидать иного. Попробуем разобраться с этой проблемой. Разобраться раз и навсегда.

3. Стандартный код BoringSSL не вызывается

Изначальный план такой - чтобы не мучиться каждый раз с внешними инструментами которые проксируют https-трафик параллельно расшифровывая его, добавим эту возможность прямо в код OpenSSL, на самом что ни на есть нижнем уровне. Благо это наш смартфон. Тогда всё будет отлично работать независимо от приложения и помогать нам в отладке без установки third-party программ.

Итак, посмотрим где там собирается OpenSSL. Наша версия Android - 11, и Google подсказывает, что в нем используется не оригинальный OpenSSL а его fork от Google - BoringSSL (https://github.com/google/boringssl). Смотрим в репозиторий - да, так и есть. BoringSSL находится в каталоге ./external/boringssl. Не будем мелочиться а добавим логирование прямо в сердце библиотеки - ./external/boringssl/src/crypto/bio/bio.c
Напрямую log Android там не доступен, но нам поможет то, что стандартный вызов syslog() из UNIX перенаправляет сообщения прямо в logcat. Итак, вставляем контрольную печать, пересобираем Android, перепрошиваем смартфон и запускаем для начала собственный небольшой тест, чтобы убедиться, что наш код отрабатывает.

Код программы на С

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <unistd.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

#define HOST "www.example.com"
#define PORT "443"
#define REQUEST "GET / HTTP/1.1\r\nHost: www.example.com\r\nConnection: close\r\n\r\n"

void handle_error(const char* msg) {
    fprintf(stderr, "%s\n", msg);
    ERR_print_errors_fp(stderr);
    exit(1);
}

void https_request(const char* hostname) {
    SSL_CTX* ctx;
    SSL* ssl;
    int sockfd;
    struct sockaddr_in server_addr;
    struct hostent* server;
    
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
        handle_error("socket error");
    }
    
    server = gethostbyname(hostname);
    if (server == NULL) {
        handle_error("gethostbyname error");
    }
    
    // Заполнение структуры адреса сервера
    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(443);
    memcpy(&server_addr.sin_addr.s_addr, server->h_addr, server->h_length);
    
    // Установка соединения с сервером
    if (connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
        handle_error("connect error");
    }
    
    // Инициализация библиотеки OpenSSL
    SSL_library_init();
    SSL_load_error_strings();
    
    // Создание контекста SSL
    ctx = SSL_CTX_new(TLS_client_method());
    if (ctx == NULL) {
        handle_error("SSL_CTX_new error");
    }
    
    // Создание объекта SSL
    ssl = SSL_new(ctx);
    if (ssl == NULL) {
        handle_error("SSL_new error");
    }
    
    // Привязка объекта SSL к сокету
    SSL_set_fd(ssl, sockfd);
    
    // Установка соединения по SSL
    if (SSL_connect(ssl) <= 0) {
        handle_error("SSL_connect error");
    }
    
    // Отправка HTTP-запроса
    SSL_write(ssl, REQUEST, strlen(REQUEST));
    
    // Чтение и обработка ответа сервера
    char response[4096];
    int response_length = 0;
    int bytes_read;
    while ((bytes_read = SSL_read(ssl, response + response_length, sizeof(response) - response_length - 1)) > 0) {
        response_length += bytes_read;
    }
    response[response_length] = '\0';
    printf("Response:\n%s\n", response);
    
    // Завершение соединения
    SSL_shutdown(ssl);
    SSL_free(ssl);
    SSL_CTX_free(ctx);
    
    close(sockfd);
}

int main() {
    const char* hostname = HOST;

    // Пробуем соединиться
    https_request(hostname);
    
    return 0;
}

Запускаем скомпилированный код из adb shell. И... видим в логе запрос к серверу.
Ура! Неужели заветная цель близка?

Теперь запустим приложение, с которым нужно разобраться. Снова жмем на кнопку login, но... Никакой реакции в логе. Наш код не вызван. Как это возможно? Видимо придется сходить в отладчик.

4. Conscrypt вызывается, но только для части приложения

Быть может, в Java-приложениях под android используется какая-то другая библиотека для работы с HTTPS? Для проверки набросаем простое приложение и попробуем пройтись по нему в отладчике.

Код функции на Java

private String performHttpsRequest(String hostname, String path) {
		String response = "";
		try {
			// Создание SSL контекста
			SSLContext sslContext = SSLContext.getInstance("TLS");
			sslContext.init(null, null, null);

			// Создание SSL сокета
			SSLSocketFactory socketFactory = sslContext.getSocketFactory();
			SSLSocket socket = (SSLSocket) socketFactory.createSocket();
			SSLParameters sslParameters = socket.getSSLParameters();
			socket.setSSLParameters(sslParameters);

			// Установка соединения с сервером
				InetAddress address = InetAddress.getByName(hostname);
				socket.connect(new java.net.InetSocketAddress(address, 443));

				// Отправка HTTP-запроса
				String request = "GET " + path + " HTTP/1.1\r\n" +
						"Host: " + hostname + "\r\n" +
						"Connection: close\r\n\r\n";
				OutputStream outputStream = socket.getOutputStream();
				outputStream.write(request.getBytes());
				outputStream.flush();

				// Чтение и обработка ответа сервера
				BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
				StringBuilder responseBuilder = new StringBuilder();
				String line;
				while ((line = reader.readLine()) != null) {
					responseBuilder.append(line).append("\n");
				}
				response = responseBuilder.toString();

				// Закрытие соединения
				socket.close();
		}
		catch (Exception e) {
			Log.e(TAG, "Error: " + e.getMessage());
		}
		return response;

Входим внутрь метода на несколько уровней и попадаем в библиотеку Conscrypt (https://github.com/google/conscrypt). Эта библиотека позиционируется как Java Security Provider, и имплементирует Java Cryptography Extension (JCE) и Java Secure Socket Extension (JSSE). К счастью для нас тут уже есть специальный файл (./external/conscrypt/common/src/jni/main/cpp/conscrypt/trace.cc) в котором можно выставить флаги для отладки различных функций. Собственно, содержимое его невелико:

#include <conscrypt/trace.h>

namespace conscrypt {
namespace trace {

const bool kWithJniTrace = false;
const bool kWithJniTraceMd = false;
const bool kWithJniTraceData = false;
const bool kWithJniTracePackets = false;
const bool kWithJniTraceKeys = true;  // <- то, что нужно!
const std::size_t kWithJniTraceDataChunkSize = 512;

}  // namespace trace
}  // namespace conscrypt

Для наших целей вполне достаточно выставить kWithJniTraceKeys в true, пересобрать Android и снова перепрошить телефон.
Запускаем наш пример на Java и радостно наблюдаем в логе записи типа:

NativeCrypto-jni: ssl=0x6f9c6f8918 KEY_LINE: CLIENT_RANDOM d4cd8dbd2d740c2fb34e0f592023ae73e934969ce9806757a338c1102e7665fe dd9952f4577370a605dd5abe449bfba2e641890252641ce08789d3ec0792889558cadc70fdc36fe73b063ca345783733

NativeCrypto-jni: ssl=0xb400006f9c6f20d8 KEY_LINE: CLIENT_TRAFFIC_SECRET_0 d9d7cb07389159bf03604756ce27f308add1af9e3dd84a928b7e13cfbc9e9716 3691d1c3ebff780091812e404a0daeff6262f02e4bfcb778a5300f4ab85ae20c

Т.е. логирование ключей работает. Потенциально, используя эти ключи мы можем расшифровать SSL-сессию используя обычный WireShark. Теперь запускаем целевое приложение и тоже видим в логе обмен ключами. Однако сама попытка соединения с online-библиотекой никак в логе не отражается. Снова засада. Видимо (как это часто бывает ныне) в приложении для одних и тех же действий, но в разных частях программы используются разные библиотеки. (Как шутят в GameDev, степень зрелости игры определяется числом различных версий Boost присутствующих в репозитории). Значит настала пора посмотреть на содержимое APK-файла. Похоже, оно преподнесет нам сюрпризы. Распаковываем apk, и в каталоге ./lib/arm64-v8a/ обнаруживаем такое:

libbookshelfCoreJNI.so libbookshelfCore.so libcrashlytics-common.so libcrashlytics-handler.so libcrashlytics.so libcrashlytics-trampoline.so libcrypto.so libgnustl_shared.so libnative-lib.so libNuanceVocalizer.so libpdfium.so libplugins_bearer_libqandroidbearer.so libplugins_platforms_android_libqtforandroid.so libplugins_platforms_libqminimalegl.so libplugins_platforms_libqminimal.so libplugins_sqldrivers_libqsqlite.so libQt5Concurrent.so libQt5Core.so libQt5Gui.so libQt5Network.so libQt5Sql.so libQt5Xml.so libssl.so

Т.е. высокоодарённые программисты этого приложения решили заменить в том числе и системные библиотеки (libssl.so и libcrypto.so) своими собственными. Теперь понятно, почему в логах BoringSSL было пусто.

5. Замена openssl.so на системную роняет приложение

Однако, это не повод опускать руки! Для начала попробуем тривиальный ход - заменим копии библиотек libssl.so и libcrypto.so на системные и снова запустим приложение. Итак, копируем библиотеки в apk, и запаковываем его. Понятно, что после этого слетит подпись приложения, но в нашем случае это не проблема. Просто переподпишем его системным ключом, и заново проинсталлируем. Сказано - сделано. Запускаем новый apk, и в целом он работает, но к сожалению при попытке connect-а к библиотеке - падает. Значит версии библиотек таки не совпали. Жаль, но ничего не поделаешь. Искать именно ту версию, под которую всё слинковано и пересобирать мне сильно лень, так что будем пробовать иные способы.

6. Настройки HTTP-proxy игнорируются (не работает charles proxy)

Каноничным программами для отладки web-приложений (да еще и популярными на Хабре судя по картинке) являются Fiddler и Charles Proxy.

Я выбрал последний из-за наличия бесплатной версии, поставил его и приступил к отладке. Для перехвата HTTPS-трафика нужно установить на телефон сертификат Charles Proxy в качестве доверенного, но в нашем случае это не проблема. Плюс, выставить системное HTTP-proxy, чтобы перенаправить запросы с реального сервера на свой компьютер, где работает Charles. Выполняем всё это и... запросы к proxy не идут. Tcpdump сообщает нам, что приложение по-прежнему общается с сервером напрямую. При этом многие "нормальные" программы начинают действительно работать через прокси, но не наша. Очевидно, настройки HTTP-proxy тупо игнорируются. Что ж. Этот исход был вполне ожидаем.

7. Заворот трафика через iptables не помогает (mitmproxy глючит?)

Посмотрим, что еще есть в мире MITM. Первое, что попадается на глаза - программа с говорящим названием MitmProxy (https://mitmproxy.org). Она бесплатна, код есть на github и обещает работать как transparent proxy. Нужно завернуть трафик через iptables на целевой компьютер а там уж оно разберется. Документация есть на странице https://docs.mitmproxy.org/stable/howto-transparent/, там предлагается сделать что-то типа:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8080

Ок. Дело это не хитрое. С поправкой на специфику Android и наши адреса успешно заворачиваем трафик на mitmproxy, попутно закинув еще один доверенный сертификат на устройство. Запускаем приложение, трафик идет куда нужно, но в логах mitmproxy мы видим неудачу соединения. Это может быть вызвано двумя причинами: либо что-то написано не так в самом proxy, либо приложение использует еще одну неприятную технику, известную как Certificate Pinning, когда клиент проверяет не только валидность сертификата, но и его строгое соответствие своим представлениям о прекрасном. Второй случай довольно неприятен, хотя и с ним пытаются бороться (плюс, на сегодня он считается устаревшим и в целом используется редко). В поисках нужного средства натыкаюсь в сети еще на один проект - HTTP Toolkit который обещает помочь.

8. HTTP Toolkit свое дело делает

Изначально мое внимание привлекает статься - Defeating Android Certificate Pinning with Frida и я решаю поставить HTTP Toolkit. На компьютере он ставится довольно легко, плюс имеет специальный клиент под Android. Для перехвата трафика он использует забавный метод - вместо настройки HTTP-proxy или манипуляций с iptables, клиент изображает из себя VPN. И когда мы его запускаем, весь трафик с устройства автоматически перенаправляется в VPN-туннель, который и образован клиентом и HTTP toolkit-ом на компьютере.

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

Разумеется, на устройство, как и всегда, надо добавить доверенный сертификат SSL. Но для собственного телефона это не проблема.

Выполняем эти нехитрые действия, и вуаля! Сразу же видим запросы в окне HTTP Toolkit безо всяких плясок с бубном. Пробуем подключиться к online-библиотеке и снова успех! Расшифрованный запрос у нас перед глазами. Значит версия о certificate pinning была ложной, и создатели mitmproxy просто что-то намудрили (хотя, возможно ошибся и я при переназначении трафика).

9. Но исправить баг мы не в состоянии

Анализ трафика однако показал, что проблема не в клиенте, и тем паче не в наших правках кода Android Framework. Сервер просто иногда ни с того ни с сего отказывает в соединении. Причем, мне удалось воспроизвести проблему и на устройствах других брендов, типа Xiaomi. Так что решить проблему клиента мы оказались не в состоянии, но хотя бы сняли с себя подозрения.

10. Заключение

Вот и подошел к концу мой рассказ об увлекательном мире отладки web-приложений посредством MITM. Хоть и не удалось достигнуть всех целей, но в целом я доволен. Во-первых, удалось окунуться в незнакомый доселе мир программ для перехвата HTTP[S] трафика, во-вторых - лучше понять структуру HTTPS-стека в Android. Плюс, найти весьма полезную программу для дальнейшего использования, попутно реализовав простой способ для расшифровки трафика без внешних proxy, только силами tcpdump и wireshark (более подробно можно посмотреть тут https://habr.com/ru/articles/253521/), который будет работать для большинства Android-приложений, не учитывая самых извращенных. Что уже немало.