Търсим уязвимости в UC Browser

Въведение

В края на март ние съобщаваха, открихме скрита възможност за зареждане и стартиране на непотвърден код в UC Browser. Днес ще разгледаме подробно как протича това зареждане и как хакерите могат да го използват в своите цели.

Няколко време назад UC Browser бе агресивно рекламиран и разпространяван: инсталираха го на устройствата на потребителите с помощта на злонамерени програми, разпространяваха го от различни сайтове под формата на видео файлове (т.е. потребителите мислеха, че свалят, например, порно клип, а вместо това получаваха APK с този браузър), използваха плашещи банери с съобщения, че браузърът е остарял, уязвим и т.н. В официалната група на UC Browser във VK има тема, където потребителите могат да се оплачат от некоректна реклама, там има много примери. През 2016 година дори имаше видеореклама на руски език (да, реклама на браузър, който блокира рекламите).

Към момента на писане на статията UC Browser е имал над 500 000 000 инсталации в Google Play. Това е впечатляващо — само Google Chrome има повече. Сред отзивите може да се видят доста оплаквания относно рекламите и пренасочванията към различни приложения в Google Play. Това стана повод за изследване: решихме да проверим дали UC Browser прави нещо нередно. И се оказа, че всъщност прави!

В кода на приложението беше открита възможност за зареждане и стартиране на изпълним код, което е в разрез с правилата за публикуване на приложения в Google Play. Освен това, че UC Browser зарежда изпълним код, той го прави незащитено, което може да бъде използвано за извършване на атака Man-in-the-Middle. Нека видим дали можем да извършим такава атака.

Всичко, което е написано по-долу, е актуално за версията на UC Browser, която присъства в Google Play по времето на провеждане на изследването:

package: com.UCMobile.intl
versionName: 12.10.8.1172
versionCode: 10598
sha1 на APK файла: f5edb2243413c777172f6362876041eb0c3a928c

Вектор на атака

В манифеста на UC Browser може да се открие услуга с говорещо име com.uc.deployment.UpgradeDeployService.

    <service android_exported="false" android_name="com.uc.deployment.UpgradeDeployService" android_process=":deploy" />

При стартиране на тази услуга браузърът изпълнява POST заявка към puds.ucweb.com/upgrade/index.xhtml, който може да бъде забелязан в трафика след известно време след старта. В отговор той може да получи команда за изтегляне на някаква актуализация или нов модул. По време на анализа сървърът не даваше такива команди, но забелязахме, че при опит за отваряне на PDF в браузъра той прави повторна заявка на посочения по-горе адрес, след което изтегля нативна библиотека. За провеждане на атаката решихме да използваме тази особеност на UC Browser: способността да отваря PDF с помощта на нативна библиотека, която липсва в APK и която той при необходимост изтегля от интернет. Струва си да се отбележи, че теоретично UC Browser може да бъде принуден да изтегли нещо и без взаимодействие с потребителя – ако се предостави правилно формулиран отговор на заявката, която се изпълнява след стартиране на браузъра. Но за това трябва да проучим по-подробно протокола на взаимодействие със сървъра, затова решихме, че е по-лесно да редактираме прихванатия отговор и да подменим библиотеката за работа с PDF.

И така, когато потребителят иска да отвори PDF директно в браузъра, в трафика може да се видят следните заявки:

Първо, следва POST-заявка към puds.ucweb.com/upgrade/index.xhtml, след което
се изтегля архив с библиотеката за преглед на PDF и офис формати. Логично е да предположим, че в първата заявка се предава информация за системата (най-малкото архитектура, за да се предостави нужната библиотека), а в отговор на нея браузърът получава известна информация за библиотеката, която трябва да бъде изтеглена: адрес и, възможно, нещо още. Проблемът е, че тази заявка е криптирана.

Фрагмент от заявката

Фрагмент от отговора

Самата библиотека е опакована в ZIP и не е криптирана.

Търсене на кода за декриптиране на трафика

Нека опитаме да декриптираме отговора на сървера. Наблюдаваме кода на класа com.uc.deployment.UpgradeDeployService: от метода onStartCommand прехвърляме се в com.uc.deployment.b.x, а от него в com.uc.browser.core.d.c.f.e:

    публичен финален void e(l arg9) {
        int v4_5;
        String v3_1;
        byte[] v3;
        byte[] v1 = null;
        if(arg9 == null) {
            v3 = v1;
        }
        else {
            v3_1 = arg9.iGX.ipR;
            StringBuilder v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]продукт:");
            v4.append(arg9.iGX.ipR);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]версия:");
            v4.append(arg9.iGX.iEn);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тип_надстройка:");
            v4.append(arg9.iGX.mMode);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]флаг_сила:");
            v4.append(arg9.iGX.iEo);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тиха_режим:");
            v4.append(arg9.iGX.iDQ);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тих_тип:");
            v4.append(arg9.iGX.iEr);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тих_състояние:");
            v4.append(arg9.iGX.iEp);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тих_файл:");
            v4.append(arg9.iGX.iEq);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apk_md5:");
            v4.append(arg9.iGX.iEl);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]тип_изтегляне:");
            v4.append(arg9.mDownloadType);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]група_изтегляне:");
            v4.append(arg9.mDownloadGroup);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]път_изтегляне:");
            v4.append(arg9.iGH);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]версия_аполо_дете:");
            v4.append(arg9.iGX.iEx);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]серия_аполо:");
            v4.append(arg9.iGX.iEw);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]архитектура_cpu_аполо:");
            v4.append(arg9.iGX.iEt);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]vfp3_cpu_аполо:");
            v4.append(arg9.iGX.iEv);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]vfp_cpu_аполо:");
            v4.append(arg9.iGX.iEu);
            ArrayList v3_2 = arg9.iGX.iEz;
            if(v3_2 != null && v3_2.size() != 0) {
                Iterator v3_3 = v3_2.iterator();
                while(v3_3.hasNext()) {
                    Object v4_1 = v3_3.next();
                    StringBuilder v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]име_компонент:");
                    v5.append(((au)v4_1).getName());
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]име_версия_компонент:");
                    v5.append(((au)v4_1).aDA());
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]код_версия_компонент:");
                    v5.append(((au)v4_1).gBl);
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]тип_заявка_компонент:");
                    v5.append(((au)v4_1).gBq);
                }
            }

            j v3_4 = new j();
            m.b(v3_4);
            h v4_2 = new h();
            m.b(v4_2);
            ay v5_1 = new ay();
            v3_4.hS("");
            v3_4.setImsi("");
            v3_4.hV("");
            v5_1.bPQ = v3_4;
            v5_1.bPP = v4_2;
            v5_1.yr(arg9.iGX.ipR);
            v5_1.gBF = arg9.iGX.mMode;
            v5_1.gBI = arg9.iGX.iEz;
            v3_2 = v5_1.gAr;
            c.aBh();
            v3_2.add(g.fs("ver_os", c.getRomInfo()));
            v3_2.add(g.fs("архитектура_процесор", com.uc.b.a.a.c.getCpuArch()));
            v3_2.add(g.fs("архитектура_cpu", com.uc.b.a.a.c.Pb()));
            String v4_3 = com.uc.b.a.a.c.Pd();
            v3_2.add(g.fs("vfp_cpu", v4_3));
            v3_2.add(g.fs("тип_мрежа", String.valueOf(com.uc.base.system.a.Jo())));
            v3_2.add(g.fs("отхост", arg9.iGX.iEm));
            v3_2.add(g.fs("версия_плагин", arg9.iGX.iEn));
            v3_2.add(g.fs("целеви_език", arg9.iGX.iEs));
            v3_2.add(g.fs("архитектура_cpu_vitamio", arg9.iGX.iEt));
            v3_2.add(g.fs("vfp_vitamio", arg9.iGX.iEu));
            v3_2.add(g.fs("vfp3_vitamio", arg9.iGX.iEv));
            v3_2.add(g.fs("версия_дете_плагин", arg9.iGX.iEx));
            v3_2.add(g.fs("серия_версия", arg9.iGX.iEw));
            v3_2.add(g.fs("дете_версия", r.aVw()));
            v3_2.add(g.fs("md5_cur_версия", arg9.iGX.iEl));
            v3_2.add(g.fs("подпис_cur_версия", SystemHelper.getUCMSignature()));
            v3_2.add(g.fs("лог_надстройка", i.bjt()));
            v3_2.add(g.fs("тишина_инсталация", String.valueOf(arg9.iGX.iDQ)));
            v3_2.add(g.fs("тихо_състояние", String.valueOf(arg9.iGX.iEp)));
            v3_2.add(g.fs("тих_файл", arg9.iGX.iEq));
            v3_2.add(g.fs("тих_тип", String.valueOf(arg9.iGX.iEr)));
            v3_2.add(g.fs("архитектура_cpu", com.uc.b.a.a.c.Pc()));
            v3_2.add(g.fs("настройка_cpu", SystemHelper.getCpuInstruction()));
            boolean v4_4 = v4_3 == null || !v4_3.contains("neon") ? false : true;
            v3_2.add(g.fs("неон", String.valueOf(v4_4)));
            v3_2.add(g.fs("ядра_cpu", String.valueOf(com.uc.b.a.a.c.Jl())));
            v3_2.add(g.fs("ram_1", String.valueOf(com.uc.b.a.a.h.Po())));
            v3_2.add(g.fs("общо_ram", String.valueOf(com.uc.b.a.a.h.OL())));
            c.aBh();
            v3_2.add(g.fs("rom_1", c.getRomInfo()));
            v4_5 = e.getScreenWidth();
            int v6 = e.getScreenHeight();
            StringBuilder v7 = new StringBuilder();
            v7.append(v4_5);
            v7.append("*");
            v7.append(v6);
            v3_2.add(g.fs("разделение_екран", v7.toString()));
            v3_2.add(g.fs("ниво_api", String.valueOf(Build$VERSION.SDK_INT)));
            v3_2.add(g.fs("списък_uc_apk", SystemHelper.getUCMobileApks()));
            Iterator v4_6 = arg9.iGX.iEA.entrySet().iterator();
            while(v4_6.hasNext()) {
                Object v6_1 = v4_6.next();
                v3_2.add(g.fs(((Map$Entry)v6_1).getKey(), ((Map$Entry)v6_1).getValue()));
            }

            v3 = v5_1.toByteArray();
        }

        if(v3 == null) {
            this.iGY.iGI.a(arg9, "up_encode", "да", "неуспех");
            return;
        }

        v4_5 = this.iGY.iGw ? 0x1F : 0;
        if(v3 == null) {
        }
        else {
            v3 = g.i(v4_5, v3);
            if(v3 == null) {
            }
            else {
                v1 = new byte[v3.length + 16];
                byte[] v6_2 = new byte[16];
                Arrays.fill(v6_2, 0);
                v6_2[0] = 0x5F;
                v6_2[1] = 0;
                v6_2[2] = ((byte)v4_5);
                v6_2[3] = -50;
                System.arraycopy(v6_2, 0, v1, 0, 16);
                System.arraycopy(v3, 0, v1, 16, v3.length);
            }
        }

        if(v1 == null) {
            this.iGY.iGI.a(arg9, "up_encrypt", "да", "неуспех");
            return;
        }

        if(TextUtils.isEmpty(this.iGY.mUpgradeUrl)) {
            this.iGY.iGI.a(arg9, "up_url", "да", "неуспех");
            return;
        }

        StringBuilder v0 = new StringBuilder("[");
        v0.append(arg9.iGX.ipR);
        v0.append("]url:");
        v0.append(this.iGY.mUpgradeUrl);
        com.uc.browser.core.d.c.i v0_1 = this.iGY.iGI;
        v3_1 = this.iGY.mUpgradeUrl;
        com.uc.base.net.e v0_2 = new com.uc.base.net.e(new com.uc.browser.core.d.c.i$a(v0_1, arg9));
        v3_1 = v3_1.contains("?") ? v3_1 + "&dataver=pb" : v3_1 + "?dataver=pb";
        n v3_5 = v0_2.uc(v3_1);
        m.b(v3_5, false);
        v3_5.setMethod("POST");
        v3_5.setBodyProvider(v1);
        v0_2.b(v3_5);
        this.iGY.iGI.a(arg9, "up_null", "да", "успех");
        this.iGY.iGI.b(arg9);
    }

Тук виждаме формироването на POST-заявка. Обърнете внимание на създаването на масив от 16 байта и неговото запълване: 0x5F, 0, 0x1F, -50 (=0xCE). Съвпада с това, което видяхме в предишната заявка.

В този клас можем да забележим вложен клас, в който има един интересен метод:

        public final void a(l arg10, byte[] arg11) {
            f v0 = this.iGQ;
            StringBuilder v1 = new StringBuilder("[");
            v1.append(arg10.iGX.ipR);
            v1.append("]:UpgradeSuccess");
            byte[] v1_1 = null;
            if(arg11 == null) {
            }
            else if(arg11.length < 16) {
            }
            else {
                if(arg11[0] != 0x60 && arg11[3] != 0xFFFFFFD0) {
                    goto label_57;
                }
                int v3 = 1;
                int v5 = arg11[1] == 1 ? 1 : 0;
                if(arg11[2] != 1 && arg11[2] != 11) {
                    if(arg11[2] == 0x1F) {
                    }
                    else {
                        v3 = 0;
                    }
                }
                byte[] v7 = new byte[arg11.length - 16];
                System.arraycopy(arg11, 16, v7, 0, v7.length);
                if(v3 != 0) {
                    v7 = g.j(arg11[2], v7);
                }
                if(v7 == null) {
                    goto label_57;
                }
                if(v5 != 0) {
                    v1_1 = g.P(v7);
                    goto label_57;
                }
                v1_1 = v7;
            }
        label_57:
            if(v1_1 == null) {
                v0.iGY.iGI.a(arg10, "up_decrypt", "yes", "fail");
                return;
            }
            q v11 = g.b(arg10, v1_1);
            if(v11 == null) {
                v0.iGY.iGI.a(arg10, "up_decode", "yes", "fail");
                return;
            }
            if(v0.iGY.iGt) {
                v0.d(arg10);
            }
            if(v0.iGY.iGo != null) {
                v0.iGY.iGo.a(0, ((o)v11));
            }
            if(v0.iGY.iGs) {
                v0.iGY.a(((o)v11));
                v0.iGY.iGI.a(v11, "up_silent", "yes", "success");
                v0.iGY.iGI.a(v11);
                return;
            }
            v0.iGY.iGI.a(v11, "up_silent", "no", "success");
        }
    }

Методът получава масив от байтове и проверява дали нулевият байт е равен на 0x60 или третият байт е равен на 0xD0, а вторият байт е 1, 11 или 0x1F. Виждаме отговора от сървъра: нулевият байт е 0x60, вторият е 0x1F, третият е 0x60. Изглежда, че това е което ни трябва. Съдейки по редовете (например „up_decrypt“), тук трябва да се извика метод, който декриптира отговора от сървъра.
Преминаваме към метода g.j. Забележете, че като първи аргумент в него се подава байт отOffset 2 (т.е. 0x1F в нашия случай), а като втори — отговора от сървъра без
първите 16 байта.

     public static byte[] j(int arg1, byte[] arg2) {
        if(arg1 == 1) {
            arg2 = c.c(arg2, c.adu);
        }
        else if(arg1 == 11) {
            arg2 = m.aF(arg2);
        }
        else if(arg1 != 0x1F) {
        }
        else {
            arg2 = EncryptHelper.decrypt(arg2);
        }
        return arg2;
    }

Очевидно, тук се извършва избор на алгоритъм за декриптиране, и въпросният байт, който в нашия случай
случаят е равен 0x1F, обозначава един от трите възможни варианта.

Продължаваме анализа на кода. След няколко скока стигаме до метода с говорещо име decryptBytesByKey.

Тук нашият отговор се отделя с още два байта, и от тях се получава низ. Ясно е, че по този начин се избира ключ за декодиране на съобщението.

    private static byte[] decryptBytesByKey(byte[] bytes) {
        byte[] v0 = null;
        if(bytes != null) {
            try {
                if(bytes.length < EncryptHelper.PREFIX_BYTES_SIZE) {
                }
                else if(bytes.length == EncryptHelper.PREFIX_BYTES_SIZE) {
                    return v0;
                }
                else {
                    byte[] prefix = new byte[EncryptHelper.PREFIX_BYTES_SIZE];  // 2 байта
                    System.arraycopy(bytes, 0, prefix, 0, prefix.length);
                    String keyId = c.ayR().d(ByteBuffer.wrap(prefix).getShort()); // Избор на ключа
                    if(keyId == null) {
                        return v0;
                    }
                    else {
                        a v2 = EncryptHelper.ayL();
                        if(v2 == null) {
                            return v0;
                        }
                        else {
                            byte[] enrypted = new byte[bytes.length - EncryptHelper.PREFIX_BYTES_SIZE];
                            System.arraycopy(bytes, EncryptHelper.PREFIX_BYTES_SIZE, enrypted, 0, enrypted.length);
                            return v2.l(keyId, enrypted);
                        }
                    }
                }
            }
            catch(SecException v7_1) {
                EncryptHelper.handleDecryptException(((Throwable)v7_1), v7_1.getErrorCode());
                return v0;
            }
            catch(Throwable v7) {
                EncryptHelper.handleDecryptException(v7, 2);
                return v0;
            }
        }

        return v0;
    }

Минавайки напред, отбелязваме, че на този етап не се получава ключ, а само неговия „идентификатор“. С получаването на ключа всичко е малко по-сложно.

В следващия метод към наличните параметри се добавят още два, и стават четири: магическото число 16, идентификатор на ключа, криптирани данни и неясен низ (в нашия случай празен).

    public final byte[] l(String keyId, byte[] encrypted) throws SecException {
        return this.ayJ().staticBinarySafeDecryptNoB64(16, keyId, encrypted, "");
    }

След серия от преходи стигаме до метода staticBinarySafeDecryptNoB64 интерфейс com.alibaba.wireless.security.open.staticdataencrypt.IStaticDataEncryptComponent. В основния код на приложението няма класове, реализиращи този интерфейс. Такъв клас има в файла lib/armeabi-v7a/libsgmain.so, който всъщност не е .so, а .jar. Интересуващият ни метод е реализиран следния начин:

package com.alibaba.wireless.security.a.i;
 
// ...
 
public class a implements IStaticDataEncryptComponent {
    private ISecurityGuardPlugin a;
// ...
    private byte[] a(int mode, int magicInt, int xzInt, String keyId, byte[] encrypted, String magicString) {
        return this.a.getRouter().doCommand(10601, new Object[]{Integer.valueOf(mode), Integer.valueOf(magicInt), Integer.valueOf(xzInt), keyId, encrypted, magicString});
    }
// ...
    private byte[] b(int magicInt, String keyId, byte[] encrypted, String magicString) {
        return this.a(2, magicInt, 0, keyId, encrypted, magicString);
    }
// ...
    public byte[] staticBinarySafeDecryptNoB64(int magicInt, String keyId, byte[] encrypted, String magicString) throws SecException {
        if(keyId != null && keyId.length() > 0 && magicInt >= 0 && magicInt  0) {
            return this.b(magicInt, keyId, encrypted, magicString);
        }
 
        throw new SecException("", 301);
    }
//...
}

Тук нашият списък с параметри се допълва с още две цели числа: 2 и 0. Съдейки по
всичко, 2 означава декриптиране, както в метода doFinal на системния клас javax.crypto.Cipher. И всичко това се предава на някакъв Router с числото 10601 — това явно е номерът на командата.

След нова верига от преходи намираме класа, който реализира интерфейса IRouterComponent и метод doCommand:

package com.alibaba.wireless.security.mainplugin;

import com.alibaba.wireless.security.framework.IRouterComponent;
import com.taobao.wireless.security.adapter.JNICLibrary;
 
public class a implements IRouterComponent {
    public a() {
        super();
    }
    public Object doCommand(int arg2, Object[] arg3) {
        return JNICLibrary.doCommandNative(arg2, arg3);
    }
}

И също класът JNICLibrary, в който е обявен нативният метод doCommandNative:

package com.taobao.wireless.security.adapter;
 
public class JNICLibrary {
    public static native Object doCommandNative(int arg0, Object[] arg1);
}

Значи, трябва в нативния код да намерим метода doCommandNative. И тук започва най-забавното.

Обфускирането на машинния код

В файла libsgmain.so (който всъщност е .jar и в който по-горе намерихме реализация на някои интерфейси, свързани с шифроването) има една нативна библиотека: libsgmainso-6.4.36.so. Отваряме я в IDA и получаваме куп диалогови прозорци с грешки. Проблемът е, че таблицата на секции (section header table) – е невалидна. Това е направено умишлено, за да се усложни анализът.

Но тя и не е нужна: за да заредим ELF файла коректно и да го анализираме, е напълно достатъчна таблицата на сегментите (program header table). Затова просто премахваме таблицата на секциите, нулирайки съответните полета в заглавката.

Отново отваряме файла в IDA.

Има два начина да съобщим на виртуалната Java машина, къде точно в нативната библиотека се намира реализацията на метода, обявен в Java кода като нативен. Първият — да му дадем име от вида Java_имя_пакета_ИмяКласса_имяМетода.

Вторият — да го регистрираме при зареждане на библиотеката (в функцията JNI_OnLoad)
с помощта на извикването на функцията RegisterNatives.

В нашия случай, ако използваме първия метод, името трябва да бъде такова: Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

Между експортираните функции такава няма, следователно трябва да търсим извикването RegisterNatives.
Отиваме в функцията JNI_OnLoad и виждаме такава картина:

Какво се случва тук? На пръв поглед, началото и краят на функцията са типични за архитектурата ARM. Първата инструкция в стека запазва съдържанието на регистрите, които функцията ще използва в работата си (в този случай R0, R1 и R2), както и съдържанието на регистра LR, в който се намира адресът за връщане от функцията. Последната инструкция възстановява запазените регистри, като адресът за връщане веднага се поставя в регистър PC — по този начин се извършва връщането от функцията. Но ако се вгледаме внимателно, можем да забележим, че предпоследната инструкция променя адреса за връщане, запазен в стека. Да изчислим какъв ще бъде той след
изпълнението на кода. В R1 се зарежда определен адрес 0xB130, от него се изважда 5, след това се прехвърля в R0 и му се прибавя 0x10. Получава се 0xB13B. По този начин IDA мисли, че в последната инструкция се извършва обичайно връщане от функцията, а всъщност се извършва прехвърляне по изчисления адрес 0xB13B.

Тук е добре да припомним, че процесорите ARM имат два режима и два набора инструкции: ARM и Thumb. Най-нисък бит на адреса казва на процесора кой набор инструкции се използва. Т.е. адресът всъщност е 0xB13A, а единицата в най-ниския бит обозначава режим Thumb.

В началото на всяка функция в тази библиотека е добавен подобен "адаптер" и
боклук код. По-нататък няма да се спираме подробно на тях – просто помним,
че истинското начало почти на всички функции се намира малко по-далеч.

Тъй като в кода няма явен преход на 0xB13A, IDA сама не е разпознала, че в това място има код. По същата причина голяма част от кода в библиотеката тя не разпознава като код, което затруднява анализа. Кажете на IDA, че тук има код, и ето какво се получава:

На 0xB144 явно започва таблица. А какво има в sub_494C?

При извикване на тази функция в регистра LR получаваме адреса на споменатата по-рано таблица (0xB144). В R0 — индекс в тази таблица. Т.е. взима се стойността от таблицата, прибавя се към LR и се получава
адресът, на който трябва да отидем. Ще пробваме да го изчислим: 0xB144 + [0xB144 + 8 * 4] = 0xB144 + 0x120 = 0xB264. Преминаваме по получения адрес и виждаме буквално няколко полезни инструкции и отново преход на 0xB140:

Сега ще има преход по отклонение с индекс 0x20 от таблицата.

Съдя по размера на таблицата, такива преходи в кода ще се срещнат много. Възниква въпросът, може ли да се справим с това по-автоматизирано, без ръчно изчисляване на адреси. И на помощ идват скриптовете и възможността да патчваме кода в IDA:

def put_unconditional_branch(source, destination):
    offset = (destination - source - 4) >> 1
    if offset > 2097151 or offset  1023 or offset > 11) & 0x7ff)
        instruction2 = 0xb800 | (offset & 0x7ff)
        patch_word(source, instruction1)
        patch_word(source + 2, instruction2)
    else:
        instruction = 0xe000 | (offset & 0x7ff)
        patch_word(source, instruction)
 
 
ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
    ea1 = ea + 2
    if get_wide_word(ea1) == 0xbf00: #NOP
        ea1 += 2
    if get_operand_type(ea1, 0) == 1 and get_operand_value(ea1, 0) == 0 and get_operand_type(ea1, 1) == 2:
        index = get_wide_dword(get_operand_value(ea1, 1))
        print "индекс =", hex(index)
        ea1 += 2
        if get_operand_type(ea1, 0) == 7:
            table = get_operand_value(ea1, 0) + 4
        elif get_operand_type(ea1, 1) == 2:
            table = get_operand_value(ea1, 1) + 4
        else:
            print "Грешен тип операнд на", hex(ea1), "-", get_operand_type(ea1, 0), get_operand_type(ea1, 1)
            table = None
        if table is None:
            print "Не може да се намери таблицата"
        else:
            print "таблица =", hex(table)
            offset = get_wide_dword(table + (index << 2))
            put_unconditional_branch(ea, table + offset)
    else:
        print "Неизвестен код", get_operand_type(ea1, 0), get_operand_value(ea1, 0), get_operand_type(ea1, 1) == 2
else:
    print "Не може да се открие първата команда"

Слагаме курсора на ред 0xB26A, стартираме скрипта и виждаме преход на 0xB4B0:

IDA отново не разпознава този участък като код. Помагаме й и виждаме друга конструкция:

Инструкциите след BLX изглеждат не много смислени, това по-скоро прилича на някакво отклонение. Нека да погледнем в sub_4964:

И наистина, тук се взема dword от адреса, лежащ в LR, добавя се към този адрес, след което се взима стойността от получения адрес и се поставя в стека. Също така към LR се добавя 4, за да прескочи това отклонение след връщането от функцията. След което командата POP {R1} извлича получената стойност от стека. Ако погледнем какво се намира на адрес 0xB4BA + 0xEA = 0xB5A4, можем да видим нещо, подобно на таблица от адреси:

За да патчнете тази конструкция, ще трябва да получите два параметъра от кода: офсет и номер на регистра, в който трябва да поставите резултата. За всеки възможен регистър ще трябва предварително да подготвите малко парче код.

patches = {}
patches[0] = (0x00, 0xbf, 0x01, 0x48, 0x00, 0x68, 0x02, 0xe0)
patches[1] = (0x00, 0xbf, 0x01, 0x49, 0x09, 0x68, 0x02, 0xe0)
patches[2] = (0x00, 0xbf, 0x01, 0x4a, 0x12, 0x68, 0x02, 0xe0)
patches[3] = (0x00, 0xbf, 0x01, 0x4b, 0x1b, 0x68, 0x02, 0xe0)
patches[4] = (0x00, 0xbf, 0x01, 0x4c, 0x24, 0x68, 0x02, 0xe0)
patches[5] = (0x00, 0xbf, 0x01, 0x4d, 0x2d, 0x68, 0x02, 0xe0)
patches[8] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x80, 0xd8, 0xf8, 0x00, 0x80, 0x01, 0xe0)
patches[9] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0x90, 0xd9, 0xf8, 0x00, 0x90, 0x01, 0xe0)
patches[10] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xa0, 0xda, 0xf8, 0x00, 0xa0, 0x01, 0xe0)
patches[11] = (0x00, 0xbf, 0xdf, 0xf8, 0x06, 0xb0, 0xdb, 0xf8, 0x00, 0xb0, 0x01, 0xe0)

ea = here()
if (get_wide_word(ea) == 0xb082 #SUB SP, SP, #8
        and get_wide_word(ea + 2) == 0xb503): #PUSH {R0,R1,LR}
    if get_operand_type(ea + 4, 0) == 7:
        pop = get_bytes(ea + 12, 4, 0)
        if pop[1] == 'xbc':
            register = -1
            r = get_wide_byte(ea + 12)
            for i in range(8):
                if r == (1 <> 4
            if register in patches:
                address = get_wide_dword(ea + 8) + ea + 8
                for b in patches[register]:
                    patch_byte(ea, b)
                    ea += 1
                patch_dword(ea, address)
        else:
            print "POP instruction not found"
    else:
        print "Wrong operand type on +4:", get_operand_type(ea + 4, 0)
else:
    print "Unable to detect first instructions"

Поставяме курсора в началото на конструкцията, която искаме да заменим — 0xB4B2 — и стартираме скрипта:

Освен вече споменатите конструкции, в кода също се срещат и такива:

Както и в предишния случай, след инструкциите BLX следва офсет:

Вземаме офсета от адреса в LR, добавяме го към LR и отиваме там. 0x72044 + 0xC = 0x72050. Скриптът за тази конструкция е съвсем прост:

def put_unconditional_branch(source, destination):
    offset = (destination - source - 4) >> 1
    if offset > 2097151 or offset  1023 or offset > 11) & 0x7ff)
        instruction2 = 0xb800 | (offset & 0x7ff)
        patch_word(source, instruction1)
        patch_word(source + 2, instruction2)
    else:
        instruction = 0xe000 | (offset & 0x7ff)
        patch_word(source, instruction)
 

ea = here()
if get_wide_word(ea) == 0xb503: #PUSH {R0,R1,LR}
    ea1 = ea + 6
    if get_wide_word(ea + 2) == 0xbf00: #NOP
        ea1 += 2
    offset = get_wide_dword(ea1)
    put_unconditional_branch(ea, (ea1 + offset) & 0xffffffff)
else:
    print "Unable to detect first instruction"

Резултат от изпълнението на скрипта:

След като функционалността е пропатчена, можем да укажем на IDA реалното й начало. Тя ще събере целия код на функцията парче по парче и той може да бъде декомпилиран с HexRays.

Дешифриране на низове

Научихме се да се справяме с обфускацията на машинния код в библиотеката libsgmainso-6.4.36.so от UC Browser и получихме кода на функцията JNI_OnLoad.

int __fastcall real_JNI_OnLoad(JavaVM *vm)
{
  int result; // r0
  jclass clazz; // r0 MAPDST
  int v4; // r0
  JNIEnv *env; // r4
  int v6; // [sp-40h] [bp-5Ch]
  int v7; // [sp+Ch] [bp-10h]
  v7 = *(_DWORD *)off_8AC00;
  if ( !vm )
    goto LABEL_39;
  sub_7C4F4();
  env = (JNIEnv *)sub_7C5B0(0);
  if ( !env )
    goto LABEL_39;
  v4 = sub_72CCC();
  sub_73634(v4);
  sub_73E24(&unk_83EA6, &v6, 49);
  clazz = (jclass)((int (__fastcall *)(JNIEnv *, int *))(*env)->FindClass)(env, &v6);
  if ( clazz
    && (sub_9EE4(),
        sub_71D68(env),
        sub_E7DC(env) >= 0
     && sub_69D68(env) >= 0
     && sub_197B4(env, clazz) >= 0
     && sub_E240(env, clazz) >= 0
     && sub_B8B0(env, clazz) >= 0
     && sub_5F0F4(env, clazz) >= 0
     && sub_70640(env, clazz) >= 0
     && sub_11F3C(env) >= 0
     && sub_21C3C(env, clazz) >= 0
     && sub_2148C(env, clazz) >= 0
     && sub_210E0(env, clazz) >= 0
     && sub_41B58(env, clazz) >= 0
     && sub_27920(env, clazz) >= 0
     && sub_293E8(env, clazz) >= 0
     && sub_208F4(env, clazz) >= 0) )
  {
    result = (sub_B7B0(env, clazz) >> 31) | 0x10004;
  }
  else
  {
LABEL_39:
    result = -1;
  }
  return result;
}

Нека да разгледаме по-внимателно следните редове:

  sub_73E24(&unk_83EA6, &v6, 49);
  clazz = (jclass)((int (__fastcall *)(JNIEnv *, int *))(*env)->FindClass)(env, &v6);

В функцията sub_73E24 явно се извършва разшифровка на името на класа. Като параметри на тази функция се предава указател към данни, които изглеждат шифровани, един буфер и число. Очевидно е, че след извикването на функцията в буфера ще бъде разшифрован низ, тъй като той се предава на функцията FindClass, която приема втори параметър - името на класа. Следователно, числото е размерът на буфера или дължината на низа. Нека се опитаме да разшифроваме името на класа, то би трябвало да ни подскаже дали сме на правия път. Нека погледнем по-подробно какво се случва в sub_73E24.

int __fastcall sub_73E56(unsigned __int8 *in, unsigned __int8 *out, size_t size)
{
  int v4; // r6
  int v7; // r11
  int v8; // r9
  int v9; // r4
  size_t v10; // r5
  int v11; // r0
  struc_1 v13; // [sp+0h] [bp-30h]
  int v14; // [sp+1Ch] [bp-14h]
  int v15; // [sp+20h] [bp-10h]
  v4 = 0;
  v15 = *(_DWORD *)off_8AC00;
  v14 = 0;
  v7 = sub_7AF78(17);
  v8 = sub_7AF78(size);
  if ( !v7 )
  {
    v9 = 0;
    goto LABEL_12;
  }
  (*(void (__fastcall **)(int, const char *, int))(v7 + 12))(v7, "DcO/lcK+h?m3c*q@", 16);
  if ( !v8 )
  {
LABEL_9:
    v4 = 0;
    goto LABEL_10;
  }
  v4 = 0;
  if ( !in )
  {
LABEL_10:
    v9 = 0;
    goto LABEL_11;
  }
  v9 = 0;
  if ( out )
  {
    memset(out, 0, size);
    v10 = size - 1;
    (*(void (__fastcall **)(int, unsigned __int8 *, size_t))(v8 + 12))(v8, in, v10);
    memset(&v13, 0, 0x14u);
    v13.field_4 = 3;
    v13.field_10 = v7;
    v13.field_14 = v8;
    v11 = sub_6115C(&v13, &v14);
    v9 = v11;
    if ( v11 )
    {
      if ( *(_DWORD *)(v11 + 4) == v10 )
      {
        qmemcpy(out, *(const void **)v11, v10);
        v4 = *(_DWORD *)(v9 + 4);
      }
      else
      {
        v4 = 0;
      }
      goto LABEL_11;
    }
    goto LABEL_9;
  }
LABEL_11:
  sub_7B148(v7);
LABEL_12:
  if ( v8 )
    sub_7B148(v8);
  if ( v9 )
    sub_7B148(v9);
  return v4;
}

Функция sub_7AF78 създава инстанция на контейнера за масиви от байтове с указан размер (няма да навлизаме в подробности за тези контейнери). Тук се създават два такива контейнера: в един се поставя стринга „DcO/lcK+h?m3c*q@“ (не е трудно да се досетим, че това е ключ), в другия — шифрованите данни. След това и двата обекта се поставят в някаква структура, която се предава на функцията sub_6115C. Освен това отбелязваме в тази структура поле със стойност 3. Нека видим какво става с тази структура след това.

int __fastcall sub_611B4(struc_1 *a1, _DWORD *a2)
{
  int v3; // lr
  unsigned int v4; // r1
  int v5; // r0
  int v6; // r1
  int result; // r0
  int v8; // r0
  *a2 = 820000;
  if ( a1 )
  {
    v3 = a1->field_14;
    if ( v3 )
    {
      v4 = a1->field_4;
      if ( v4 field_0, a1->field_10, v3);
            goto LABEL_17;
          case 3u:
            v8 = sub_6364C(a1->field_0, a1->field_10, v3);
            goto LABEL_17;
          case 0x10u:
          case 0x11u:
          case 0x12u:
            v8 = sub_612F4(
                   a1->field_0,
                   v4,
                   *(_QWORD *)&a1->field_8,
                   *(_QWORD *)&a1->field_8 >> 32,
                   a1->field_10,
                   v3,
                   a2);
            goto LABEL_17;
          case 0x14u:
            v8 = sub_63A28(a1->field_0, v3);
            goto LABEL_17;
          case 0x15u:
            sub_61A60(a1->field_0, v3, a2);
            return result;
          case 0x16u:
            v8 = sub_62440(a1->field_14);
            goto LABEL_17;
          case 0x17u:
            v8 = sub_6226C(a1->field_10, v3);
            goto LABEL_17;
          case 0x18u:
            v8 = sub_63530(a1->field_14);
LABEL_17:
            v6 = 0;
            if ( v8 )
            {
              *a2 = 0;
              v6 = v8;
            }
            return v6;
          default:
            LOWORD(v5) = 28032;
            goto LABEL_5;
        }
      }
    }
  }
  LOWORD(v5) = -27504;
LABEL_5:
  HIWORD(v5) = 13;
  v6 = 0;
  *a2 = v5;
  return v6;
}

Като параметър switch се предава поле на структура, на което по-рано е било присвоено значение 3. Нека разгледаме case 3: в функцията sub_6364C се предават параметри от структурата, които са били добавени там в предишната функция, т.е. ключ и криптирани данни. Ако внимаваш да погледнеш на sub_6364C, можеш да разбереш алгоритъма RC4.

Имаме алгоритъм и ключ. Нека опитаме да декриптираме името на класа. Ето какво стана: com/taobao/wireless/security/adapter/JNICLibrary. Чудесно! Ние сме на прав път.

Дърво на командите

Сега трябва да намерим извикването RegisterNatives, което ще ни посочи на функцията doCommandNative. Преглеждаме функциите, извиквани от JNI_OnLoad, и я намираме в sub_B7B0:

int __fastcall sub_B7F6(JNIEnv *env, jclass clazz)
{
  char signature[41]; // [sp+7h] [bp-55h]
  char name[16]; // [sp+30h] [bp-2Ch]
  JNINativeMethod method; // [sp+40h] [bp-1Ch]
  int v8; // [sp+4Ch] [bp-10h]
 
  v8 = *(_DWORD *)off_8AC00;
  decryptString((unsigned __int8 *)&unk_83ED9, (unsigned __int8 *)name, 0x10u); // doCommandNative
  decryptString((unsigned __int8 *)&unk_83EEA, (unsigned __int8 *)signature, 0x29u); // (I[Ljava/lang/Object;)Ljava/lang/Object;
  method.name = name;
  method.signature = signature;
  method.fnPtr = sub_B69C;
  return ((int (__fastcall *)(JNIEnv *, jclass, JNINativeMethod *, int))(*env)->RegisterNatives)(env, clazz, &method, 1) >> 31;
}

И наистина, тук се регистрира нативен метод с име doCommandNative. Сега знаем неговия адрес. Нека видим какво прави.

int __fastcall doCommandNative(JNIEnv *env, jobject obj, int command, jarray args)
{
  int v5; // r5
  struc_2 *a5; // r6
  int v9; // r1
  int v11; // [sp+Ch] [bp-14h]
  int v12; // [sp+10h] [bp-10h]
  v5 = 0;
  v12 = *(_DWORD *)off_8AC00;
  v11 = 0;
  a5 = (struc_2 *)malloc(0x14u);
  if ( a5 )
  {
    a5->field_0 = 0;
    a5->field_4 = 0;
    a5->field_8 = 0;
    a5->field_C = 0;
    v9 = command % 10000 / 100;
    a5->field_0 = command / 10000;
    a5->field_4 = v9;
    a5->field_8 = command % 100;
    a5->field_C = env;
    a5->field_10 = args;
    v5 = sub_9D60(command / 10000, v9, command % 100, 1, (int)a5, &v11);
  }
  free(a5);
  if ( !v5 && v11 )
    sub_7CF34(env, v11, &byte_83ED7);
  return v5;
}

От името можем да предположим, че тук се намира точка за вход на всички функции, които разработчиците решат да пренесат в нативната библиотека. Нас интересува функция с номер 10601.

От кода можем да видим, че от номера на командата се получават три числа: command / 10000, command % 10000 / 100 и command % 10, т.е. в нашия случай, 1, 6 и 1. Тези три числа, заедно с указателя на JNIEnv и аргументите, предадени на функцията, се събират в структура и се предават напред. С помощта на получените три числа (нека ги обозначим N1, N2 и N3) се изгражда дървото на командите.

Примерно така:

Дървото се попълва динамично в JNI_OnLoad.
Три числа кодираха пътя в дървото. Всеки лист на дървото съдържа посочен адрес на съответната функция. Ключът е в родителския възел. Намирането на мястото в кода, където в дървото се добавя необходимата ни функция, не е голямо усилие, ако разберете всичките използвани структури (описанието им не е приложено, за да не разширяваме и без това голямата статия).

Още обфускация

Получихме адреса на функцията, която трябва да разшифрова трафика: 0x5F1AC. Но все още не е време за радост: разработчиците на UC Browser са подготвили още една изненада за нас.

След получаване на параметрите от масива, който беше формиран в Java кода, попадаме
в функцията по адрес 0x4D070. И тук ни очаква още един вид обфускация на кода.

Слагаме в R7 и R4 два индекса:

Преместваме първия индекс в R11:

За да получим адреса от таблицата, използваме индекса:

След преминаването през първия адрес, се използва вторият индекс, който е в R4. В таблицата има 230 елемента.

Какво да правим с това? Можем да кажем на IDA, че това е такова превключване: Edit -> Other -> Specify switch idiom.

Полученият код е страшен. Но, проучвайки дебрите му, може да се забележи извикването на вече позната ни функция. sub_6115C:

Имаше превключване, в което в case 3 беше разшифровката с използването на алгоритъма RC4. А в този случай предаваната в функцията структура се запълва от параметрите, предадени в doCommandNative. Спомняме си, че там имахме magicInt с стойност 16. Разглеждане на съответния case – и след няколко преминавания откриваме код, по който можем да разпознаем алгоритъма.

Това е AES!

Алгоритъмът е зад нас, остава да получим параметрите му: режим, ключ и, възможно, вектор на инициализация (наличието му зависи от режима на работа на алгоритъма AES). Структурата с тях трябва да се формира някъде преди извикването на функцията sub_6115C, но тази част от кода е обфусцирана особено добре, затова се роди идеята да патчнем кода, така че всички параметри на разшифровката да се записват в файл.

Патч

За да не пишем целия код на патча на асемблер от ръка, можем да стартираме Android Studio, да напишем функция, която получава същите параметри, както нашата функция за разшифровка, и записва в файл, след което да копипейстнем кода, който ще генерира компилаторът.

Нашите приятели от екипа на UC Browser също се погрижиха за удобството на добавяне на код. Нека припомним, че в началото на всяка функция имаме ненужно кодиране, което лесно може да бъде заменено с каквото и да е друго. Много удобно 🙂 И все пак, в началото на целевата функция мястото за кода, който съхранява всички параметри във файл, е малко. Беше необходимо да го разделим на части и да използваме ненужни блокове от съседни функции. В крайна сметка се получиха четири части.

Първа част:

В архитектурата ARM първите четири параметъра на функцията се предават чрез регистрите R0-R3, а останалите, ако има такива, - чрез стека. В регистъра LR се предава адресът за връщане. Всичко това трябва да се запази, за да може функцията да работи след като из dump-им нейни параметри. Освен това е необходимо да запазим всички регистри, които ще използваме в процеса, така че правим PUSH.W {R0-R10,LR}. В R7 получаваме адреса на списъка с параметри, предадени на функцията чрез стека.

С помощта на функцията fopen отваряме файла /data/local/tmp/aes в режим „ab“,
т.е. за добавяне. В R0 зареждаме адреса на името на файла, а в R1 – адреса на строката с указанието за режима. И тук ненужният код свършва, затова преминаваме към следващата функция. За да продължи да работи, поставяме в началото преход към действителния код на функцията, заобикаляйки ненужното, а вместо ненужното добавяме продължението на патч.

Извикваме fopen.

Първите три параметъра на функцията aes имат тип int. Осколкото в началото запазихме регистрите в стека, можем просто да предадем на функцията fwrite техните адреси в стека.

След това имаме три структури, които съдържат размер на данните и указател към данните за ключа, вектора за инициализация и криптираните данни.

Накрая затваряме файла, възстановяваме регистрите и предаваме контрола на действителната функция. aes.

Събираме APK с пропатчена библиотека, подписваме, прехвърляме на устройството/емулагор, стартираме. Виждаме, че нашият dump се създава и там се записват много данни. Браузерът използва криптиране не само за трафика и всичкото криптиране преминава чрез разглежданата функция. А нужните данни по някаква причина липсват и в трафика не се вижда нужният запит. За да не чакате, докато UC Browser се сети да направи нужния запит, ще вземем криптирания отговор от сървъра, получен по-рано, и ще пробием приложението още веднъж: ще добавим разшифровка в onCreate на главната активност.

    const/16 v1, 0x62
    new-array v1, v1, [B
    fill-array-data v1, :encrypted_data
    const/16 v0, 0x1f
    invoke-static {v0, v1}, Lcom/uc/browser/core/d/c/g;->j(I[B)[B
    move-result-object v1
    array-length v2, v1
    invoke-static {v2}, Ljava/lang/String;->valueOf(I)Ljava/lang/String;
    move-result-object v2
    const-string v0, "ololo"
    invoke-static {v0, v2}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

Събираме, подписваме, инсталираме, стартираме. Получаваме NullPointerException, тъй като методът е върнал null.

По време на по-нататъшния анализ на кода беше открита функция, в която се декодират интересни редове: "META-INF/" и ".RSA". Изглежда, приложението проверява своя сертификат. Или дори генерира ключове от него. Не ми се иска да се опитвам да разбера какво става със сертификата, затова просто ще му подменим правилния сертификат. Ще модифицираме зашифрования ред така, че вместо "META-INF/" да получим "BLABLINF/", ще създадем папка с това име в APK и ще сложим там сертификата на белкобраузера.

Събираме, подписваме, инсталираме, стартираме. Бинго! Ключът е наш!

MitM

Получихме ключа и вектора за инициализация, равен на ключа. Нека опитаме да декодираме отговора на сървъра в режим CBC.

Виждаме URL адреса на архива, нещо, което прилича на MD5, "extract_unzipsize" и число. Проверяваме: MD5 на архива съвпада, размерът на разархивираната библиотека съвпада. Опитваме да модифицираме тази библиотека и да я предоставим на браузера. За да покажем, че нашата модифицирана библиотека е заредена, ще стартираме Intent за създаване на SMS с текста "PWNED!". Ще подменим два отговора от сървъра: puds.ucweb.com/upgrade/index.xhtml и за сваляне на архива. В първия подменяме MD5 (размерът след разархивиране не се променя), а във втория предоставяме архива с модифицираната библиотека.

Браузерът опитва да свали архива няколко пъти, след което показва грешка. По всичко изглежда, че нещо
му не харесва. В резултат на анализа на този неясен формат беше установено, че сървърът предава и размера на архива:

Той е кодиран в LEB128. След модификацията размерът на архива с библиотеката се е променил малко, поради което браузерът смята, че архивът е свален неправилно и след няколко опита показва грешка.

Коригираме размера на архива… И - победа! 🙂 Резултатът е на видео.

https://www.youtube.com/watch?v=Nfns7uH03J8

Последствия и реакция на разработчика

По същия начин хакерите могат да използват ненадеждната функция на UC Browser, за да разпространяват и стартират зловредни библиотеки. Тези библиотеки ще работят в контекста на браузъра и ще получат всички негови системни разрешения. В резултат на това може да се появят фишинг прозорци и достъп до работните файлове на оранжевата китайска белка, включително съхранявани в базата данни логини, пароли и бисквитки.

Свързахме се с разработчиците на UC Browser и им сигнализирахме за откритата проблема, опитвайки се да посочим уязвимостта и нейната опасност, но те не желаеха да обсъждат нищо с нас. Междувременно браузърът продължаваше да се хвали с опасната функция пред всички. Но след като разкрихме детайлите на уязвимостта, игнорирането ѝ, както по-рано, вече не беше възможно. На 27 март беше
издадена нова версия на UC Browser 12.10.9.1193, която се свързваше със сървъра по HTTPS: puds.ucweb.com/upgrade/index.xhtml.

Освен това, след "поправката" и до момента на написването на статията опитът за отваряне на PDF в браузъра водеше до появата на съобщение за грешка с текст "Опс, нещо се обърка!". Заявката към сървъра при опита за отваряне на PDF не беше изпълнена, но заявката при стартиране на браузъра беше успешна, което подсказва, че е запазена възможността за зареждане на изпълним код в нарушение на правилата на Google Play.

Източник: habr.com