Smartphones kommer vanligtvis med förinstallerade appar, vissa användbara och andra aldrig användbara. Vad användarna dock inte förväntar sig är att för en förinstallerad app kommer ett verkligt ansvar för deras integritet och säkerhet.
Check Point-undersökningar upptäckte nyligen en sårbarhet i en av de förinstallerade apparna hos en av världens största leverantörer av mobila enheter, Xiaomi, med nästan 8 % marknadsandel, trea på mobiltelefonmarknaden. Ironiskt nog är det den förinstallerade säkerhetsappen, ‘Guard Provider’ (com.miui.guardprovider), som kommer att skydda telefonen genom att upptäcka skadlig programvara, vilket faktiskt gör användaren sårbar.
Kort sagt, på grund av nätverkstrafikens osäkra karaktär till och från Guard Provider, kan ett hot ansluta till samma Wi-Fi-nätverk som offret och utföra en man-in attack.-the-Middle (MiTM). Sedan, som en del av en SDK-uppdatering från tredje part, kan han inaktivera skydd mot skadlig programvara och lägga in valfri manipuleringskod han väljer för att stjäla data, plantera ransomware eller spåra eller installera någon annan typ av skadlig programvara.
Xiaomi ‘Guard Provider’ är en applikation som kommer förinstallerad i alla vanliga Xiaomi-telefoner som använder vissa tredjeparts Software Development Kit (SDK) som en del av säkerhetstjänsten den tillhandahåller, inklusive olika typer av enhetsskydd, radering och förbättring.
Appen innehåller tre olika märken av inbyggt antivirus som användare kan välja för att hålla sina telefoner skyddade: Avast, AVL och Tencent. När användaren väljer en app väljer användaren en av dessa leverantörer som standard Anti-Virus-motor för att skanna enheten.
Innan du förklarar det potentiella attackscenariot är det viktigt att påpeka att det faktiskt finns några potentiella nackdelar med att använda flera SDK:er i samma applikation. Eftersom de alla delar applikationskontext och behörigheter är följande huvudsakliga nackdelar:
Problem i en SDK kommer att påverka skyddet för alla andra SDK:er.
En SDK:s privata lagringsdata kan inte isoleras och kan därför nås av en annan SDK.
När det gäller Xiaomi Protection Provider visar vi nedan hur Remote Code Execution (RCE)-attacker kan inträffa när två SDK:er integreras med problematiskt beteende.
Kort sagt, eftersom skyddsleverantörens nätverkstrafik från vilken Xiaomi-enhet som helst är osäkrad, gör detta att den kan avlyssnas genom en Man-in-the-Middle (MiTM)-attack. och inkluderar den falska koden som en del av en tredjeparts SDK-uppdatering . Överväg ett möjligt attackscenario.
Steg 1: Avast Update Update
Som standard, med Avast inställt som appens säkerhetsskanner, uppdaterar appen med jämna mellanrum sin virusdatabas genom att ladda ner avast-android-vps-v4-release.apk APK-filen till Guard Providers privata katalog: /data/data/com.miui. guardprovider / app_dex / vps_update_
Denna APK-fil laddas sedan och körs av Avast SDK innan enheten skannas och innehåller tidsstämpeln för när filen laddades ner. Till exempel: vps_update_20190205-124933.apk.
Check Point avslöjade på ett ansvarsfullt sätt denna sårbarhet för Xiaomi, som släppte patchen kort efter.
Tyvärr, eftersom uppdateringsmekanismen använder en osäker HTTP-anslutning för att ladda ner den här filen, kan hotaktören, genom MiTM-attacken, upptäcka Avasts uppdateringstid och förutsäga APK-filnamnet på nästa skiva. Angriparen fångar helt enkelt upp svarsdelen av anslutningen http://au.ff.avast.sec.miui.com/android/avast-android-vps-v4-release.apk.
Tänk på detta, eftersom det förutsagda filnamnet för Avast-uppdateringen sedan kommer att användas i det andra steget av attacken.
Som initial avlyssning kan en MITM-angripare således förhindra framtida Avast-uppdateringar genom att svara med ett “404-fel” på http://au.ff.avast.sec.miui requests .com/android/vps_v4_info.vpx.
Steg 2: Åsidosätt Avast Update APK genom sårbarhet via AVL Update Path
När en angripare aktivt börjar blockera anslutningar till Avast-servrar byter användare standardantivirus till ett annat antivirusprogram – i det här fallet AVL Anti-Virus. Kom ihåg att AVL Antivirus SDK också är en inbyggd del av Protection Provider-appen.
När AVL blir standard antivirus, uppdaterar det omedelbart programmet med dess virusdatabas. Den gör detta genom att kontrollera om det finns nya virussignaturer genom att begära en konfigurationsfil (t.ex. http://update.avlyun.sec.miui.com/avl_antiy/miuistd/siglib/20180704 .cj.conf). Den här .conf-filen är i vanligt textformat och visar URL, storlek och MD5-hash för ZIP-arkivet med de nya signaturerna.
Efter bearbetning av konfigurationsfilen laddar AVL sedan ned arkivet med signaturerna som anges i fältet read_update_url och packar upp det i mappen Protection Providers.
Återigen kan en MITM-angripare ändra innehållet i .conf-filen eftersom den laddas ner via en osäker anslutning, genom att använda is_new =0 för att visa existensen av en ny uppdatering och tillhandahålla en URL-länk till en manuellt genererad ZIP-fil.
Det visar sig att AVL SDK är sårbart för ett annat säkerhetsproblem som hjälper angripare att utföra det andra steget av attacken: en pipeline under dekompression. Som ett resultat kan en angripare använda ett manuellt arkiv för att skriva över alla filer i programmets sandlåda, inklusive andra SDK-relaterade filer.
Därför kommer en manuellt genererad APK, tillagd som “../../app_dex/vps_update_20190205-124933.apk” till ZIP-signaturens arkiv att skriva över den tidigare nedladdade uppdateringen från Avast, eftersom båda antivirus-SDK-komponenterna använder samma sandlåda i sina respektive SDK:er.
Om du kommer ihåg, upptäcktes APK-filnamnet för den senaste Avast-uppdateringen i det första steget av MiTM-attacken.
Allt som angriparen behöver göra nu är att släppa Avast-kommunikation och blockera AVL:s kommunikation tills användaren åter väljer Avast som aktivt antivirus. När detta händer laddas och körs den manuellt genererade skadliga APK-filen av Avast SDK.
Attacken lyckades eftersom signaturfilen för den tidigare Avast-uppdateringen inte verifierades före nedladdningen och skyddsleverantören kontrollerade den vid den första nedladdningen. Därför förutsätter den att det inte finns någon anledning att verifiera igen. På så sätt kan den skapade skadliga filen laddas ner och köras eftersom han i princip smög sig förbi vaktens rygg.
Det är helt förståeligt att användare litar på smartphonetillverkarnas förinstallerade appar, särskilt när dessa appar skyddar telefonen på egen hand. Denna sårbarhet upptäcktes dock i Xiaomis “Protection Provider”, vilket väcker den oroande frågan om vem som skyddar väktaren. Och även om vårdnadshavare inte nödvändigtvis är skyddande, är det uppenbart att när det gäller hur appar utvecklas, även de som byggs av smartphone-leverantörer, kan man inte vara för försiktig.
Attackscenariot ovan illustrerar också farorna med att använda flera SDK:er i en applikation. Även om mindre buggar i varje enskild SDK ofta kan vara ett fristående problem, när flera SDK:er distribueras i samma applikation, är det troligt att mer allvarliga sårbarheter inte är långt borta.
Check Point SandBlast Mobile, om den är installerad på enheten, upptäcker och förhindrar den initiala man-in-the-midten-attacken, vilket eliminerar hotet från denna sårbarhet hos Xiaomi Protection Provider.
. .
…
