Sikkerhed forskere netop opdaget en kode-signering bypass sårbarhed, der gør det muligt for ondsindet kode til maskerade som en officiel Anvend systemfil. Med andre ord, nogle af de implementeringer af Apples officielle kode-signering API kan udnyttes af hackere.
Apple har gjort et API til rådighed for udviklere, der ønsker at opbygge en sikkerhedsfunktion, som verificerede Apple filer som legitim. Spørgsmålet stammer fra den måde, nogle udviklere har implementeret API, således at indføre en sårbarhed i sikkerhedsprodukt.
Fejlen gør det muligt for usignerede skadelig kode til at ligne den er underskrevet af Apple. Som et resultat af denne ”misforståelse”, malware kan narre sårbare sikkerhedsprodukter og tjenester til at tro, det er bare en anden legitim Apple fil.
Hvem er berørt af denne sårbarhed? Et væld af sikkerhedsprodukter, flere open source-projekter og sikkerhedsfunktioner, der anvendes af Google, Facebook og Yelp.
Mere om sårbarhed
Som forklarede af forsker Josh Pitt på Okta, fejlen findes i forskellen mellem, hvordan Mach-O loader belastninger underskrevet kode versus hvordan bruges forkert Code Signing API'er tjek underskrevet kode og udnyttes via en misdannet Universal / Fat Binary (et binært format, der indeholder flere Mach-O-filer med hver rettet mod en specifik egne CPU-arkitektur).
Det skal bemærkes, at der er flere betingelser for sårbarheden til at arbejde:
– Den første Mach-O i Fat / Universal fil skal underskrives af Apple, kan være i386, x86_64, eller endda PPC.
– Den ondsindede binære, eller ikke-Apple leverede kode, skal være adhoc underskrevet og i386 udarbejdet for en x86_64 bit target MacOS.
– Den CPU_TYPE i Fat header af Apple binær skal indstilles til en ugyldig type eller en CPU type, der ikke er hjemmehørende i værten chipset.
Den oprindelige proof-of-concept demonstrerede hvor let det er for fejlen til at blive udnyttet med succes - det udnytter ikke engang kræver admin adgang og kræver heller ikke JIT'ing kode eller hukommelseskorruption at omgå kode-signering kontrol. Alt, hvad der kræves, er en “korrekt formateret Fat / Universal fil, og [derefter] kode-signering kontrol [returneres som værende] gyldig“, forskeren påpegede.
Patching Er udviklerens ansvar
Desuden, koden-signering API'er har flag, der skal sikre, at alle disse filer kryptografisk underskrives. Sandheden er anderledes, som "disse API'er kommer til kort som standard, og tredjepartsudviklere bliver nødt til at skabe sig og kontrollere hver arkitektur i Fat / Universal fil og kontrollere, at de identiteter matcher og er kryptografisk lyd.”Med hensyn til hvem der er ansvarlig for patching af problemet, Okta forsker siger, at det er bygherrens ansvar.
Kendte påvirket leverandører og open source-projekter er alarmeret og patches er tilgængelige. Her er en liste over berørte leverandører og de gældende patches:
Carbon Black (CVE-2018-10.407); Facebook (CVE-2018-6336); F-Secure (CVE-2018-10.403); Google (CVE-2018-10.405); Formål Udvikling (CVE-2018-10.470); Objective-See (CVE-2018-10.404); VirusTotal (CVE-2018-10.408); og Yelp (CVE-2018-10.406)
Der kan være endnu mere tredjepart sikkerhed, retsvidenskab og incident response værktøjer, der bruger de officielle kode-signering API'er, betyder, at der er mere berørte parter. Forskeren opfordrer udviklere til at kontrollere deres kode ved hjælp af hans proof-of-concept.
Milena Dimitrova
En inspireret forfatter og indholdschef, der har været hos SensorsTechForum siden projektets start. En professionel med 10+ års erfaring med at skabe engagerende indhold. Fokuseret på brugernes privatliv og malware udvikling, hun tror stærkt på en verden, hvor cybersikkerhed spiller en central rolle. Hvis almindelig sund fornuft giver ingen mening, hun vil være der til at tage noter. Disse noter senere kan blive til artikler! Følg Milena @Milenyim
Følg mig: