Letar efter sårbarheter i UC Browser

Inledning

I slutet av mars rapporterad, att de upptäckte en dold förmåga att ladda och köra overifierad kod i UC Browser. Idag kommer vi att titta i detalj på hur denna nedladdning sker och hur hackare kan använda den för sina egna syften.

För en tid sedan annonserades och distribuerades UC Browser mycket aggressivt: den installerades på användarnas enheter med skadlig programvara, distribuerad från olika webbplatser under sken av videofiler (dvs användare trodde att de laddade ner till exempel en porrfilm, men fick istället en APK med den här webbläsaren), använde skrämmande banners med meddelanden om att webbläsaren var föråldrad, sårbar och sånt. I den officiella UC Browser-gruppen på VK finns det tema, där användare kan klaga på orättvis reklam, det finns många exempel där. 2016 var det jämnt videoreklam på ryska (ja, reklam för en annonsblockerande webbläsare).

I skrivande stund har UC Browser över 500 000 000 installationer på Google Play. Detta är imponerande - bara Google Chrome har mer. Bland recensionerna kan du se ganska många klagomål om reklam och omdirigeringar till vissa applikationer på Google Play. Detta var anledningen till vår forskning: vi bestämde oss för att se om UC Browser gjorde något dåligt. Och det visade sig att han gör det!

I applikationskoden upptäcktes möjligheten att ladda ner och köra körbar kod, vilket strider mot reglerna för publicering av ansökningar på Google Play. Förutom att ladda ner körbar kod gör UC Browser det på ett osäkert sätt, vilket kan användas för att starta en MitM-attack. Låt oss se om vi kan utföra en sådan attack.

Allt som står nedan är relevant för versionen av UC Browser som var tillgänglig på Google Play vid tidpunkten för studien:

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

Attackvektor

I UC Browser-manifestet kan du hitta en tjänst med ett självförklarande namn com.uc.deployment.UpgradeDeployService.

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

När den här tjänsten startar gör webbläsaren en POST-begäran till puds.ucweb.com/upgrade/index.xhtml, som kan ses i trafiken en tid efter starten. Som svar kan han få ett kommando för att ladda ner någon uppdatering eller ny modul. Under analysen gav inte servern sådana kommandon, men vi märkte att när vi försöker öppna en PDF i webbläsaren gör den en andra begäran till adressen som anges ovan, varefter den laddar ner det inbyggda biblioteket. För att utföra attacken bestämde vi oss för att använda den här funktionen i UC Browser: möjligheten att öppna PDF med ett inbyggt bibliotek, som inte finns i APK och som det laddar ner från Internet vid behov. Det är värt att notera att UC Browser teoretiskt sett kan tvingas ladda ner något utan användarinteraktion - om du ger ett välformaterat svar på en begäran som exekveras efter att webbläsaren har startat. Men för att göra detta måste vi studera interaktionsprotokollet med servern mer i detalj, så vi bestämde oss för att det skulle vara lättare att redigera det avlyssnade svaret och ersätta biblioteket för att arbeta med PDF.

Så när en användare vill öppna en PDF direkt i webbläsaren kan följande förfrågningar ses i trafiken:

Först finns det en POST-förfrågan till puds.ucweb.com/upgrade/index.xhtml, då
Ett arkiv med ett bibliotek för visning av PDF- och kontorsformat laddas ner. Det är logiskt att anta att den första begäran sänder information om systemet (åtminstone arkitekturen för att tillhandahålla det erforderliga biblioteket), och som svar på det får webbläsaren viss information om biblioteket som behöver laddas ner: adressen och ev. , något annat. Problemet är att denna begäran är krypterad.

Begär fragment

Svarsfragment

Själva biblioteket är packat i ZIP och är inte krypterat.

Sök efter trafikdekrypteringskod

Låt oss försöka dechiffrera serverns svar. Låt oss titta på klasskoden com.uc.deployment.UpgradeDeployService: från metod onStartCommand gå till com.uc.deployment.bx, och från det till com.uc.browser.core.dcfe:

    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);
}

Vi ser bildandet av en POST-förfrågan här. Vi uppmärksammar skapandet av en array på 16 byte och dess fyllning: 0x5F, 0, 0x1F, -50 (=0xCE). Sammanfaller med vad vi såg i förfrågan ovan.

I samma klass kan du se en kapslad klass som har en annan intressant metod:

        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");
}
}

Metoden tar en array av byte som indata och kontrollerar att nollbyten är 0x60 eller den tredje byten är 0xD0, och den andra byten är 1, 11 eller 0x1F. Vi tittar på svaret från servern: nollbyten är 0x60, den andra är 0x1F, den tredje är 0x60. Låter som vad vi behöver. Att döma av raderna ("up_decrypt", till exempel), bör en metod anropas här som kommer att dekryptera serverns svar.
Låt oss gå vidare till metoden gj. Observera att det första argumentet är byten vid offset 2 (dvs. 0x1F i vårt fall), och det andra är serversvaret utan
första 16 bytes.

     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;
}

Självklart väljer vi här en dekrypteringsalgoritm och samma byte som finns i vår
fall lika med 0x1F, anger ett av tre möjliga alternativ.

Vi fortsätter att analysera koden. Efter ett par hopp befinner vi oss i en metod med ett självförklarande namn decryptBytesByKey.

Här separeras ytterligare två byte från vårt svar, och en sträng erhålls från dem. Det är tydligt att på detta sätt väljs nyckeln för att dekryptera meddelandet.

    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;
}

När vi blickar framåt noterar vi att vi i detta skede ännu inte får någon nyckel, utan bara dess "identifierare". Att få nyckeln är lite mer komplicerat.

I nästa metod läggs ytterligare två parametrar till de befintliga, vilket gör fyra av dem: det magiska numret 16, nyckelidentifieraren, den krypterade datan och en obegriplig sträng (i vårt fall tom).

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

Efter en rad övergångar kommer vi fram till metoden staticBinarySafeDecryptNoB64 gränssnitt com.alibaba.wireless.security.open.staticdataencrypt.IStaticDataEncryptComponent. Det finns inga klasser i huvudapplikationskoden som implementerar detta gränssnitt. Det finns en sådan klass i filen lib/armeabi-v7a/libsgmain.so, som egentligen inte är en .so, utan en .jar. Metoden vi är intresserade av implementeras enligt följande:

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 < 19 && encrypted != null && encrypted.length > 0) {
return this.b(magicInt, keyId, encrypted, magicString);
}
throw new SecException("", 301);
}
//...
}

Här kompletteras vår lista över parametrar med ytterligare två heltal: 2 och 0. Att döma av
allt, 2 betyder dekryptering, som i metoden doFinal systemklass javax.crypto.Cipher. Och allt detta överförs till en viss router med numret 10601 - detta är tydligen kommandonumret.

Efter nästa kedja av övergångar hittar vi en klass som implementerar gränssnittet IRouterComponent och metod 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);
}
}

Och även klass JNICLibrary, där den ursprungliga metoden deklareras doCommandNative:

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

Det betyder att vi måste hitta en metod i den ursprungliga koden doCommandNative. Och det är här det roliga börjar.

Obfuskering av maskinkod

I fil libsgmain.so (som faktiskt är en .jar och där vi hittade implementeringen av några krypteringsrelaterade gränssnitt precis ovan) finns det ett inbyggt bibliotek: libsgmainso-6.4.36.so. Vi öppnar den i IDA och får en massa dialogrutor med fel. Problemet är att sektionsrubriktabellen är ogiltig. Detta görs med avsikt för att komplicera analysen.

Men det behövs inte: för att korrekt ladda en ELF-fil och analysera den räcker det med en programhuvudtabell. Därför tar vi helt enkelt bort sektionstabellen och nollställer motsvarande fält i rubriken.

Öppna filen i IDA igen.

Det finns två sätt att berätta för den virtuella Java-maskinen var exakt i det inbyggda biblioteket implementeringen av en metod som deklarerats i Java-kod som ursprunglig finns. Den första är att ge den ett artnamn Java_package_name_ClassName_MethodName.

Det andra är att registrera det när du laddar biblioteket (i funktionen JNI_OnLoad)
med hjälp av ett funktionsanrop Registrera infödda.

I vårt fall, om vi använder den första metoden, bör namnet vara så här: Java_com_taobao_wireless_security_adapter_JNICLibrary_doCommandNative.

Det finns ingen sådan funktion bland de exporterade funktionerna, vilket innebär att du måste leta efter ett samtal Registrera infödda.
Låt oss gå till funktionen JNI_OnLoad och vi ser denna bild:

Vad händer här? Vid första anblicken är början och slutet av funktionen typiska för ARM-arkitektur. Den första instruktionen på stacken lagrar innehållet i registren som funktionen kommer att använda i sin funktion (i detta fall R0, R1 och R2), såväl som innehållet i LR-registret, som innehåller returadressen från funktionen . Den sista instruktionen återställer de sparade registren, och returadressen placeras omedelbart i PC-registret - och återgår därmed från funktionen. Men om du tittar noga kommer du att märka att den näst sista instruktionen ändrar returadressen som är lagrad på stacken. Låt oss räkna ut hur det kommer att bli efteråt
kodexekvering. En viss adress 1xB0 laddas in i R130, 5 subtraheras från den, sedan överförs den till R0 och 0x10 läggs till den. Det visar sig 0xB13B. Således tror IDA att den sista instruktionen är en normal funktionsretur, men i själva verket går den till den beräknade adressen 0xB13B.

Det är värt att komma ihåg här att ARM-processorer har två lägen och två uppsättningar instruktioner: ARM och Thumb. Den minst signifikanta biten av adressen talar om för processorn vilken instruktionsuppsättning som används. Det vill säga, adressen är faktiskt 0xB13A, och en i den minst signifikanta biten indikerar tumläget.

En liknande "adapter" har lagts till i början av varje funktion i detta bibliotek och
sopkod. Vi kommer inte att uppehålla oss mer i detalj - vi kommer bara ihåg
att den verkliga början av nästan alla funktioner är lite längre bort.

Eftersom koden inte explicit hoppar till 0xB13A, kände inte IDA själv igen att koden fanns på denna plats. Av samma anledning känner den inte igen det mesta av koden i biblioteket som kod, vilket gör analysen något svår. Vi säger till IDA att detta är koden, och det här är vad som händer:

Tabellen börjar helt klart på 0xB144. Vad finns i sub_494C?

Vid anrop av denna funktion i LR-registret får vi adressen till den tidigare nämnda tabellen (0xB144). I R0 - index i denna tabell. Det vill säga att värdet tas från tabellen, läggs till LR och resultatet är
adressen att gå till. Låt oss försöka beräkna det: 0xB144 + [0xB144 + 8* 4] = 0xB144 + 0x120 = 0xB264. Vi går till den mottagna adressen och ser bokstavligen ett par användbara instruktioner och går igen till 0xB140:

Nu blir det en övergång vid offset med index 0x20 från tabellen.

Att döma av tabellens storlek kommer det att finnas många sådana övergångar i koden. Frågan uppstår om det är möjligt att på något sätt hantera detta mer automatiskt, utan att manuellt beräkna adresser. Och skript och möjligheten att patcha kod i IDA kommer till vår hjälp:

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((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 "Wrong operand type on", hex(ea1), "-", get_operand_type(ea1, 0), get_operand_type(ea1, 1)
table = None
if table is None:
print "Unable to find table"
else:
print "table =", hex(table)
offset = get_wide_dword(table + (index << 2))
put_unconditional_branch(ea, table + offset)
else:
print "Unknown code", get_operand_type(ea1, 0), get_operand_value(ea1, 0), get_operand_type(ea1, 1) == 2
else:
print "Unable to detect first instruction"

Placera markören på rad 0xB26A, kör skriptet och se övergången till 0xB4B0:

IDA kände igen inte detta område som en kod. Vi hjälper henne och ser en annan design där:

Instruktionerna efter BLX verkar inte vara så vettiga, det är mer som någon form av förskjutning. Låt oss titta på sub_4964:

Och faktiskt, här tas ett dord på adressen som ligger i LR, adderat till denna adress, varefter värdet på den resulterande adressen tas och läggs på stacken. Dessutom läggs 4 till LR så att samma offset hoppas över efter att ha återvänt från funktionen. Därefter tar POP {R1}-kommandot det resulterande värdet från stacken. Om du tittar på vad som finns på adressen 0xB4BA + 0xEA = 0xB5A4, kommer du att se något som liknar en adresstabell:

För att patcha den här designen måste du få två parametrar från koden: offset och registernumret där du vill lägga resultatet. För varje eventuellt register måste du förbereda en kodbit i förväg.

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 << i):
register = i
break
if register == -1:
print "Unable to detect register"
else:
address = get_wide_dword(ea + 8) + ea + 8
for b in patches[register]:
patch_byte(ea, b)
ea += 1
if ea % 4 != 0:
ea += 2
patch_dword(ea, address)
elif pop[:3] == 'x5dxf8x04':
register = ord(pop[3]) >> 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"

Vi placerar markören i början av strukturen som vi vill ersätta - 0xB4B2 - och kör skriptet:

Förutom de redan nämnda strukturerna innehåller koden även följande:

Som i föregående fall, efter BLX-instruktionen finns det en offset:

Vi tar offseten till adressen från LR, lägger till den i LR och går dit. 0x72044 + 0xC = 0x72050. Skriptet för denna design är ganska enkelt:

def put_unconditional_branch(source, destination):
offset = (destination - source - 4) >> 1
if offset > 2097151 or offset < -2097152:
raise RuntimeError("Invalid offset")
if offset > 1023 or offset < -1024:
instruction1 = 0xf000 | ((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"

Resultat av skriptkörning:

När allt är lappat i funktionen kan du peka IDA till dess verkliga början. Det kommer att lägga ihop all funktionskod, och den kan dekompileras med hjälp av HexRays.

Avkodning av strängar

Vi har lärt oss att hantera obfuskering av maskinkod i biblioteket libsgmainso-6.4.36.so från UC Browser och fick funktionskoden 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;
}

Låt oss titta närmare på följande rader:

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

I funktion sub_73E24 klassnamnet dekrypteras tydligt. Som parametrar för denna funktion skickas en pekare till data liknande krypterad data, en viss buffert och ett nummer. Uppenbarligen, efter att ha anropat funktionen, kommer det att finnas en dekrypterad rad i bufferten, eftersom den skickas till funktionen FindClass, som tar klassnamnet som den andra parametern. Därför är siffran storleken på bufferten eller längden på linjen. Låt oss försöka dechiffrera klassnamnet, det borde berätta för oss om vi går i rätt riktning. Låt oss ta en närmare titt på vad som händer i 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;
}

Funktion sub_7AF78 skapar en instans av en behållare för byte-arrayer av den angivna storleken (vi kommer inte att uppehålla oss i dessa behållare i detalj). Här skapas två sådana behållare: en innehåller raden "DcO/lcK+h?m3c*q@" (det är lätt att gissa att detta är en nyckel), den andra innehåller krypterad data. Därefter placeras båda objekten i en viss struktur, som skickas till funktionen sub_6115C. Låt oss också markera ett fält med värdet 3 i denna struktur. Låt oss se vad som händer med den här strukturen härnäst.

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-parametern är ett strukturfält som tidigare tilldelats värdet 3. Titta på fall 3: till funktionen sub_6364C parametrar skickas från strukturen som lades till där i föregående funktion, dvs nyckeln och krypterad data. Om man tittar noga på sub_6364C, kan du känna igen RC4-algoritmen i den.

Vi har en algoritm och en nyckel. Låt oss försöka tyda klassnamnet. Här är vad som hände: com/taobao/wireless/security/adapter/JNICLibrary. Bra! Vi är på rätt väg.

Kommandoträd

Nu måste vi hitta en utmaning Registrera infödda, som pekar oss på funktionen doCommandNative. Låt oss titta på funktionerna som kallas från JNI_OnLoad, och vi hittar det i 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;
}

Och faktiskt, en infödd metod med namnet är registrerad här doCommandNative. Nu vet vi hans adress. Låt oss se vad han gör.

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;
}

Med namnet kan du gissa att här är ingångspunkten för alla funktioner som utvecklarna bestämde sig för att överföra till det inhemska biblioteket. Vi är intresserade av funktionsnummer 10601.

Du kan se från koden att kommandonumret ger tre siffror: kommando/10000, kommando % 10000 / 100 и kommando % 10, dvs i vårt fall, 1, 6 och 1. Dessa tre siffror, samt en pekare till JNIEnv och argumenten som skickas till funktionen läggs till i en struktur och skickas vidare. Med hjälp av de tre erhållna siffrorna (låt oss beteckna dem N1, N2 och N3), byggs ett kommandoträd.

Något som det här:

Trädet fylls i dynamiskt JNI_OnLoad.
Tre siffror kodar sökvägen i trädet. Varje blad i trädet innehåller den pockade adressen för motsvarande funktion. Nyckeln finns i föräldranoden. Att hitta platsen i koden där funktionen vi behöver läggs till i trädet är inte svårt om du förstår alla strukturer som används (vi beskriver dem inte för att inte svälla upp en redan ganska stor artikel).

Mer förvirring

Vi fick adressen till funktionen som ska dekryptera trafik: 0x5F1AC. Men det är för tidigt att glädjas: utvecklarna av UC Browser har förberett ytterligare en överraskning åt oss.

Efter att ha tagit emot parametrarna från arrayen som bildades i Java-koden får vi
till funktionen på adress 0x4D070. Och här väntar oss en annan typ av kodförvirring.

Vi lägger två index i R7 och R4:

Vi flyttar det första indexet till R11:

För att få en adress från en tabell, använd ett index:

Efter att ha gått till den första adressen används det andra indexet, vilket är i R4. Det finns 230 element i tabellen.

Vad ska man göra åt det? Du kan tala om för IDA att detta är en växel: Redigera -> Övrigt -> Ange växlingsspråk.

Den resulterande koden är fruktansvärd. Men när du tar dig igenom dess djungel kan du märka ett samtal till en funktion som vi redan känner till sub_6115C:

Det fanns en switch där det i fall 3 fanns en dekryptering med RC4-algoritmen. Och i det här fallet fylls strukturen som skickas till funktionen från parametrarna som skickas till doCommandNative. Låt oss komma ihåg vad vi hade där magicInt med värdet 16. Vi tittar på motsvarande fall - och efter flera övergångar hittar vi koden med vilken algoritmen kan identifieras.

Detta är AES!

Algoritmen finns, allt som återstår är att erhålla dess parametrar: läge, nyckel och eventuellt initialiseringsvektorn (dess närvaro beror på AES-algoritmens driftsläge). Strukturen med dem måste bildas någonstans före funktionsanropet sub_6115C, men den här delen av koden är särskilt väl obfuskerad, så idén uppstår att lappa koden så att alla parametrar för dekrypteringsfunktionen dumpas i en fil.

Lappa

För att inte skriva all patchkod i assemblerspråk manuellt kan du starta Android Studio, skriva en funktion där som tar emot samma inmatningsparametrar som vår dekrypteringsfunktion och skriver till en fil, kopiera och klistra sedan in koden som kompilatorn ska generera.

Våra vänner från UC Browser-teamet tog också hand om bekvämligheten med att lägga till kod. Låt oss komma ihåg att i början av varje funktion har vi skräpkod som enkelt kan ersättas med vilken annan som helst. Mycket bekvämt 🙂 I början av målfunktionen finns det dock inte tillräckligt med utrymme för koden som sparar alla parametrar till en fil. Jag var tvungen att dela upp den i delar och använda sopblock från närliggande funktioner. Det blev fyra delar totalt.

Första delen:

I ARM-arkitekturen skickas de första fyra funktionsparametrarna genom registren R0-R3, resten, om några, passeras genom stacken. LR-registret bär returadressen. Allt detta måste sparas så att funktionen kan fungera efter att vi har dumpat dess parametrar. Vi måste också spara alla register som vi kommer att använda i processen, så vi gör PUSH.W {R0-R10,LR}. I R7 får vi adressen till listan med parametrar som skickas till funktionen via stacken.

Använder funktionen öppen låt oss öppna filen /data/local/tmp/aes i "ab"-läge
dvs för tillägg. I R0 laddar vi adressen till filnamnet, i R1 - adressen till raden som indikerar läget. Och här slutar sopkoden, så vi går vidare till nästa funktion. För att det ska fortsätta att fungera lägger vi i början övergången till den verkliga koden för funktionen, förbi skräpet, och istället för skräpet lägger vi till en fortsättning på lappen.

Kallelse öppen.

Funktionens tre första parametrar aes har typ int. Eftersom vi sparade registren i stacken i början kan vi helt enkelt skicka funktionen fwrite deras adresser på högen.

Därefter har vi tre strukturer som innehåller datastorleken och en pekare till data för nyckeln, initialiseringsvektorn och krypterad data.

I slutet, stäng filen, återställ registren och överför kontrollen till den verkliga funktionen aes.

Vi samlar in en APK med ett lappat bibliotek, signerar det, laddar upp det till enheten/emulatorn och startar det. Vi ser att vår soptipp skapas, och det skrivs mycket data där. Webbläsaren använder kryptering inte bara för trafik, och all kryptering går via den aktuella funktionen. Men av någon anledning finns inte den nödvändiga informationen där, och den begärda begäran är inte synlig i trafiken. För att inte vänta tills UC Browser ägnar sig åt att göra den nödvändiga begäran, låt oss ta det krypterade svaret från servern som mottogs tidigare och lappa applikationen igen: lägg till dekrypteringen till onCreate av huvudaktiviteten.

    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

Vi monterar, signerar, installerar, lanserar. Vi får ett NullPointerException eftersom metoden returnerade null.

Vid vidare analys av koden upptäcktes en funktion som dechiffrerar intressanta rader: "META-INF/" och ".RSA". Det verkar som att programmet verifierar sitt certifikat. Eller till och med genererar nycklar från den. Jag vill egentligen inte ta itu med vad som händer med certifikatet, så vi skickar bara det rätta certifikatet. Låt oss patcha den krypterade raden så att istället för "META-INF/" får vi "BLABLINF/", skapa en mapp med det namnet i APK:n och lägg till ekorrwebbläsarcertifikatet där.

Vi monterar, signerar, installerar, lanserar. Bingo! Vi har nyckeln!

MITM

Vi fick en nyckel och en initialiseringsvektor lika med nyckeln. Låt oss försöka dekryptera serversvaret i CBC-läge.

Vi ser arkivets URL, något som liknar MD5, "extract_unzipsize" och ett nummer. Vi kontrollerar: MD5 för arkivet är densamma, storleken på det uppackade biblioteket är densamma. Vi försöker patcha det här biblioteket och ge det till webbläsaren. För att visa att vårt patchade bibliotek har laddats kommer vi att lansera en avsikt att skapa ett SMS med texten "PWNED!" Vi kommer att ersätta två svar från servern: puds.ucweb.com/upgrade/index.xhtml och ladda ner arkivet. I den första ersätter vi MD5 (storleken ändras inte efter uppackning), i den andra ger vi arkivet med det patchade biblioteket.

Webbläsaren försöker ladda ner arkivet flera gånger, varefter det ger ett felmeddelande. Tydligen något
Han gillar inte. Som ett resultat av att analysera detta grumliga format visade det sig att servern också överför storleken på arkivet:

Den är kodad i LEB128. Efter patchen ändrades storleken på arkivet med biblioteket lite, så webbläsaren ansåg att arkivet laddades ner snett och efter flera försök gav det ett fel.

Vi anpassar storleken på arkivet... Och – seger! 🙂 Resultatet finns i videon.

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

Konsekvenser och utvecklares reaktion

På samma sätt kan hackare använda den osäkra funktionen i UC Browser för att distribuera och köra skadliga bibliotek. Dessa bibliotek kommer att fungera i webbläsarens sammanhang, så de kommer att få alla dess systembehörigheter. Som ett resultat, möjligheten att visa nätfiskefönster, samt tillgång till arbetsfilerna för den orange kinesiska ekorren, inklusive inloggningar, lösenord och cookies lagrade i databasen.

Vi kontaktade utvecklarna av UC Browser och informerade dem om problemet vi hittade, försökte påpeka sårbarheten och dess fara, men de diskuterade ingenting med oss. Under tiden fortsatte webbläsaren att visa sin farliga funktion i klarsynt. Men när vi väl avslöjade detaljerna om sårbarheten var det inte längre möjligt att ignorera den som tidigare. 27 mars var
en ny version av UC Browser 12.10.9.1193 släpptes, som fick åtkomst till servern via HTTPS: puds.ucweb.com/upgrade/index.xhtml.

Dessutom, efter "fixen" och fram till tidpunkten för att skriva den här artikeln, resulterade ett försök att öppna en PDF i en webbläsare i ett felmeddelande med texten "Hoppsan, något gick fel!" En begäran till servern gjordes inte när man försökte öppna en PDF, men en begäran gjordes när webbläsaren startades, vilket antyder den fortsatta möjligheten att ladda ner körbar kod i strid med Google Plays regler.

Källa: will.com