Търсим уязвимости в 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 зарежда изпълняем код, той го прави небезопасно, което може да се използва за провеждане на MitM атака. Да видим дали ще можем да проведем такава атака.

Всичко, написано по-долу, е актуално за версията на 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:

    public final 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("]product:");
            v4.append(arg9.iGX.ipR);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]version:");
            v4.append(arg9.iGX.iEn);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]upgrade_type:");
            v4.append(arg9.iGX.mMode);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]force_flag:");
            v4.append(arg9.iGX.iEo);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]silent_mode:");
            v4.append(arg9.iGX.iDQ);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]silent_type:");
            v4.append(arg9.iGX.iEr);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]silent_state:");
            v4.append(arg9.iGX.iEp);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]silent_file:");
            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("]download_type:");
            v4.append(arg9.mDownloadType);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]download_group:");
            v4.append(arg9.mDownloadGroup);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]download_path:");
            v4.append(arg9.iGH);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apollo_child_version:");
            v4.append(arg9.iGX.iEx);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apollo_series:");
            v4.append(arg9.iGX.iEw);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apollo_cpu_arch:");
            v4.append(arg9.iGX.iEt);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apollo_cpu_vfp3:");
            v4.append(arg9.iGX.iEv);
            v4 = new StringBuilder("[");
            v4.append(v3_1);
            v4.append("]apollo_cpu_vfp:");
            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("]component_name:");
                    v5.append(((au)v4_1).getName());
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]component_ver_name:");
                    v5.append(((au)v4_1).aDA());
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]component_ver_code:");
                    v5.append(((au)v4_1).gBl);
                    v5 = new StringBuilder("[");
                    v5.append(((au)v4_1).getName());
                    v5.append("]component_req_type:");
                    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("os_ver", c.getRomInfo()));
            v3_2.add(g.fs("processor_arch", com.uc.b.a.a.c.getCpuArch()));
            v3_2.add(g.fs("cpu_arch", com.uc.b.a.a.c.Pb()));
            String v4_3 = com.uc.b.a.a.c.Pd();
            v3_2.add(g.fs("cpu_vfp", v4_3));
            v3_2.add(g.fs("net_type", String.valueOf(com.uc.base.system.a.Jo())));
            v3_2.add(g.fs("fromhost", arg9.iGX.iEm));
            v3_2.add(g.fs("plugin_ver", arg9.iGX.iEn));
            v3_2.add(g.fs("target_lang", arg9.iGX.iEs));
            v3_2.add(g.fs("vitamio_cpu_arch", arg9.iGX.iEt));
            v3_2.add(g.fs("vitamio_vfp", arg9.iGX.iEu));
            v3_2.add(g.fs("vitamio_vfp3", arg9.iGX.iEv));
            v3_2.add(g.fs("plugin_child_ver", arg9.iGX.iEx));
            v3_2.add(g.fs("ver_series", arg9.iGX.iEw));
            v3_2.add(g.fs("child_ver", r.aVw()));
            v3_2.add(g.fs("cur_ver_md5", arg9.iGX.iEl));
            v3_2.add(g.fs("cur_ver_signature", SystemHelper.getUCMSignature()));
            v3_2.add(g.fs("upgrade_log", i.bjt()));
            v3_2.add(g.fs("silent_install", String.valueOf(arg9.iGX.iDQ)));
            v3_2.add(g.fs("silent_state", String.valueOf(arg9.iGX.iEp)));
            v3_2.add(g.fs("silent_file", arg9.iGX.iEq));
            v3_2.add(g.fs("silent_type", String.valueOf(arg9.iGX.iEr)));
            v3_2.add(g.fs("cpu_archit", com.uc.b.a.a.c.Pc()));
            v3_2.add(g.fs("cpu_set", SystemHelper.getCpuInstruction()));
            boolean v4_4 = v4_3 == null || !v4_3.contains("neon") ? false : true;
            v3_2.add(g.fs("neon", String.valueOf(v4_4)));
            v3_2.add(g.fs("cpu_cores", 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("totalram", 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("ss", v7.toString()));
            v3_2.add(g.fs("api_level", String.valueOf(Build$VERSION.SDK_INT)));
            v3_2.add(g.fs("uc_apk_list", 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", "yes", "fail");
            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", "yes", "fail");
            return;
        }
 
        if(TextUtils.isEmpty(this.iGY.mUpgradeUrl)) {
            this.iGY.iGI.a(arg9, "up_url", "yes", "fail");
            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", "yes", "success");
        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. Забелязваме, че като първи аргумент в него се предава байт с отместване 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 кода като native. Първият — да му дадем име в вида на 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 "index =", 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 "table =", 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 не е намерена"
    else:
        print "Неправилен тип операнд на +4:", get_operand_type(ea + 4, 0)
else:
    print "Неуспешно открит първи инструкции"

Поставяме курсора в началото на конструкцията, която искаме да заменим — 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 "Неуспешно открит първа инструкция"

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

След като функцията е пропатчена, можем да укажем 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, която приема като втори параметър името на класа. Следователно, числото е размерът на буфера или дължината на низa. Нека опитаме да декодираме името на класа, тъй като то трябва да ни посочи в правилната посока. Нека да разгледаме по-подробно какво се случва в 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 < 0x19 )
      {
        switch ( v4 )
        {
          case 0u:
            v8 = sub_6419C(a1->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, че това е такъв switch: Edit -> Other -> Specify switch idiom.

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

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

Това е AES!

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

Патч

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

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

Първа част:

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

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

Извикваме fopen.

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

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

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

Събираме APK с пропатчена библиотека, подписваме я, качваме на устройството/емулатора и стартираме. Виждаме, че нашият дамп се създава и в него се записват много данни. Браузерът използва шифроване не само за трафика и всичкото шифроване преминава през разглежданата функция. Но необходимите данни ги няма и в трафика не се вижда желаният запит. За да не чакаме, докато 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 за създаване на СМС с текст «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