S3 Ep97: Blev din iPhone pwned? Hur skulle du veta? [Ljud + text]

Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.

DOUG.  Bitcoin-bankomater attackerade, Janet Jackson kraschar datorer och noll dagar i massor.

Allt det och mer i podcasten Naked Security.

[MUSIKAL MOODEM]

Välkommen till podden, alla.

Jag är Doug Aamoth.

Med mig är som alltid Paul Ducklin.

Paul, hur gör du?

---

ANKA.  Jag mår mycket bra, Douglas.

Välkommen tillbaka från din semester!

---

DOUG.  Skönt att vara tillbaka i säkerheten på mitt eget kontor, borta från små barn.

[SKRATT]

Men det är en annan historia för en annan gång.

Som ni vet vill vi börja showen med lite teknikhistoria.

Den här veckan, den 24 augusti 1995, släpptes låten "Start Me Up" av Rolling Stones, under licens, som temalåten som lanserade Microsoft Windows 95.

Som låten förutspådde, "Du får en vuxen man att gråta", och några Microsoft-hatare har gråtit sedan dess.

Jag gillade Windows 95...

…men som du säger, du behövde starta den flera gånger, och ibland startade den av sig själv.

---

ANKA.  Starta upp mig?!

Vem visste var *det* skulle leda?

Jag tror att vi hade en aning, men jag tror inte att vi hade tänkt oss att det skulle bli Windows 11, eller hur?

---

DOUG.  Det gjorde vi inte.

Och jag gillar Windows 11 – jag har få klagomål om det.

---

ANKA.  Vet du vad?

Jag gick faktiskt och hackade min fönsterhanterare på Linux, som bara gör rektangulära fönster.

Jag lade till ett litet hack som sätter in väldigt lätt rundade hörn, bara för att jag gillar hur de ser ut på Windows 11.

Och jag borde inte säga det offentligt – att jag använde en visuell funktion i Windows 11 som drivkraft...

… annars kommer jag att heta smuts, Douglas!

---

DOUG.  Åh, herregud!

Okej, låt oss inte prata om det mer då.

Men låt oss snälla hålla oss till temat teknikhistoria och musik.

Och jag kan ställa den här enkla frågan...

Vad gör Janet Jackson och angrepp mot beteende ha gemensamt?

---

ANKA.  Tja, jag tror inte att vi säger att Janet Jackson plötsligt har blivit utpekad som en ond haxxor från början av 2000-talet, eller ens 1990-talet, eller ens slutet av 80-talet.

---

DOUG.  Inte medvetet, åtminstone.

---

ANKA.  Nej... inte med flit.

Det här är en historia som kommer från inte mindre en källa än ueberblogger på Microsoft, Raymond Chen.

Han skriver de kortaste, vassaste bloggarna – förklarar saker, ibland lite motkulturellt, ibland till och med tar en liten grävning på sin egen arbetsgivare och säger: "Vad tänkte vi då?"

Och han är så känd att även hans slipsar – han bär alltid slips, vackra färgade slipsar – även hans slipsar har en Twitter flöde, Doug.

[SKRATT]

Men Raymond Chen skrev en historia som går tillbaka till 2005, tror jag, där en Windows-maskinvarutillverkare (han säger inte vilken) kontaktade Microsoft och sa: "Vi har det här problemet att Windows kraschar hela tiden, och vi" har begränsat det till när datorn spelar låten, genom sitt eget ljudsystem Rhythm Nation".

En mycket känd Janet Jackson låt – Jag gillar det faktiskt – från 1989, tro det eller ej.

[SKRATT]

"När den låten spelas kraschar datorn. Och intressant nog, det kraschar också datorer som tillhör våra konkurrenter, och det kommer att krascha närliggande datorer."

De tänkte uppenbarligen snabbt: "Det har väl med vibration att göra?"

Hårddiskvibrationer eller något liknande.

Och deras påstående var att det bara råkade matcha den så kallade resonansfrekvensen på hårddisken, till den grad att den skulle krascha och få ner operativsystemet med den.

Så de satte in ett ljudfilter som klippte ut de frekvenser som de trodde var mest sannolikt att få hårddisken att vibrera till problem.

---

DOUG.  Och min favoritdel av detta, bortsett från hela historien...

[SKRATT]

…är att det finns en CVE *utgiven 2022* om detta!

---

ANKA.  Ja, ett bevis på att åtminstone vissa personer inom public service har humor.

---

DOUG.  Älskar det!

---

ANKA.  CVE-2022-23839: Denial of service parentes (enhetsfel och systemkrasch).

"En viss OEM-diskenhet på 5400 rpm, som levererades med bärbara datorer ungefär 2005, gör det möjligt för fysiskt närliggande angripare att orsaka ett överbelastningsskydd via en resonansfrekvensattack med ljudsignalen från Rhythm Nation musikvideo."

Jag tvivlar på att det var något specifikt för Rhythm Nation... det råkade bara vibrera din hårddisk och få den att fungera fel.

Och faktiskt, som en av våra kommentatorer påpekade, finns det en berömd video från 2008 som du kan hitta på YouTube (vi har lagt länken i kommentarerna om Naked Security-artikeln) med titeln "Shouting at Servers".

Det var en forskare på Sun – om han lutade sig in och ropade in i en diskenhetsuppsättning kunde du se på skärmen att det fanns en enorm ökning i en återställningsbar diskfel.

Ett enormt, enormt antal skivfel när han ropade där inne, och uppenbarligen satte vibrationerna skivorna från sig.

---

DOUG.  Ja!

Utmärkt konstig historia för att starta showen.

Och en annan sorts konstig historia är: En Bitcoin ATM skum attack som inte innehöll någon egentlig skadlig programvara.

Hur lyckades de med den här?

---

ANKA.  Ja, jag var fascinerad av den här historien på flera konton.

Som du säger, det ena är att kundkontona "utlöstes" eller "skummades" *utan att implantera skadlig programvara*.

Det var bara konfigurationsändringar, utlösta via en sårbarhet.

Men det verkar också som att antingen försökte angriparna bara detta, eller så var det mer av ett proof-of-concept, eller så hoppades de att det skulle förbli obemärkt i evigheter och att de skulle skumma små mängder under en lång tidsperiod utan någon som är medveten.

---

DOUG.  Ja.

---

ANKA.  Det märktes, tydligen ganska snabbt, och skadorna var tydligen begränsade till - ja, jag säger "bara" - $16,000 XNUMX.

Vilket är tre storleksordningar, eller 1000 gånger, mindre än de typiska mängder som vi vanligtvis behöver för att ens börja prata om dessa berättelser.

---

DOUG.  Ganska bra!

---

ANKA.  100 miljoner dollar, 600 miljoner dollar, 340 miljoner dollar...

Men attacken var inte mot själva uttagsautomaterna. Det var mot Coin ATM Server-produkten som du måste köra någonstans om du är kund hos det här företaget.

Det kallas för Allmänna bytes.

Jag vet inte om han är en släkting till den berömda Windows-personligheten General Failure...

[SKRATT]

Men det är ett tjeckiskt företag som heter General Bytes, och de tillverkar dessa bankomater för kryptovaluta.

Så tanken är att du behöver den här servern som är back-end för en eller flera uttagsautomater som du har.

Och antingen kör du det på din egen server, i ditt eget serverrum, under din egen noggranna kontroll, eller så kan du köra det i molnet.

Och om du vill köra det i molnet har de gjort ett specialavtal med värdleverantören Digital Ocean.

Och om du vill kan du betala dem en transaktionsavgift på 0.5 %, tydligen, och de kommer inte bara att lägga din server i molnet, de kommer att köra den åt dig.

Allt mycket bra.

Problemet är att det fanns vad som låter som en autentiseringsförbikopplingssårbarhet i Coin ATM Server-gränssnittet.

Så om du skulle lägga in superkomplicerade lösenord, 2FA, 3FA, 12FA, verkade det inte spela någon roll. [SKRATT]

Det fanns en bypass som skulle tillåta en obehörig användare att skapa ett administratörskonto.

Så vitt jag kan förstå (de har inte varit helt öppna, förståeligt nog, om exakt hur attacken fungerade), ser det ut som om angriparna kunde lura systemet att gå tillbaka till sitt "initial setup"-läge.

Och, uppenbarligen, en av sakerna när du konfigurerar en server, säger den, "Du måste skapa ett administrativt konto."

De skulle kunna komma så långt, så att de kunde skapa ett nytt administrativt konto och sedan, naturligtvis, sedan kunde de komma tillbaka som en nytillverkad sysadmin... ingen skadlig kod krävs.

De behövde inte bryta sig in, släppa några filer, göra en privilegiehöjning i systemet.

Och i synnerhet verkar det som att en av de saker de gjorde är...

…i händelse av att en kund oavsiktligt försökt skicka mynt till fel, eller en obefintlig, kanske till och med kanske en blockerad plånbok, i denna programvara, kan bankomatoperatörerna ange en speciell insamlingsplånbok för vad som annars skulle vara ogiltiga transaktioner.

Det är nästan som en sorts depositionsplånbok.

Och så vad skurkarna gjorde är: de ändrade den "ogiltiga betalningsdestinationsidentifieraren" till en av sina egna.

Så antagligen var deras idé att varje gång det skedde en felaktig eller ogiltig transaktion från en kund, vilket kan vara ganska sällsynt, kunde kunden inte ens inse att pengarna inte hade gått igenom om de betalade för något anonymt...

Men poängen är att detta är en av de attacker som påminner oss om att hot mot cybersäkerhet nu för tiden... det handlar inte längre om helt enkelt: "Nåja, hitta skadlig programvara; ta bort skadlig programvara; applicera plåstren."

Alla dessa saker är viktiga, men i det här fallet förhindrar applicering av patchen att du blir hackad i framtiden, men om du inte också går och helt omvaliderar alla dina inställningar...

…om du blev hackad tidigare kommer du att förbli hackad efteråt, utan skadlig programvara att hitta någonstans.

Det är bara konfigurationsändringar i din databas.

---

DOUG.  Vi har en MDR-tjänst; många andra företag har MDR-tjänster.

Om du har människor som proaktivt letar efter sånt här, är detta något som vi kunde ha fångat med en MDR-tjänst?

---

ANKA.  Nåväl, uppenbarligen är en av de saker du skulle hoppas är att en MDR-tjänst – om du känner att du inte är på djupet, eller om du inte har tid, och du tar in ett företag inte bara för att hjälpa dig, men i huvudsak för att ta hand om din cybersäkerhet och få den på en jämn köl...

..Jag vet att Sophos MDR team skulle rekommendera detta: "Hej, varför har du din Coin ATM Server öppen för hela Internet? Varför gör du det inte åtminstone tillgängligt via något mellanliggande nätverk där du har något slags nollförtroendesystem som gör det svårare för skurkarna att komma in i systemet i första hand?”

Det skulle ha ett mer detaljerat tillvägagångssätt för att släppa in människor, eftersom det ser ut som om den verkliga svaga punkten här var att dessa angripare, skurkarna, bara kunde göra en IP-skanning av Digital Oceans servrar.

De vandrade i princip bara igenom, letade efter servrar som körde just den här tjänsten, och gick sedan förmodligen tillbaka senare och försökte se vilken av dem de kunde bryta sig in i.

Det är inte bra att betala ett MDR-team för att komma in och göra säkerhet åt dig om du inte är villig att försöka få säkerhetsinställningarna rätt i första hand.

Och, naturligtvis, den andra saken som du kan förvänta dig att ett bra MDR-team gör, med sina mänskliga ögon på situationen, med hjälp av automatiska verktyg, är att upptäcka saker som *nästan ser rätt ut men som inte är det*.

Så ja, det finns massor av saker du kan göra, förutsatt att: du vet var du ska vara; du vet var du vill vara; och du har ett sätt att skilja det goda beteendet från det dåliga beteendet.

För, som du kan föreställa dig, i en attack som denna – förutom det faktum att de ursprungliga anslutningarna kanske kom från ett IP-nummer som du inte skulle ha förväntat dig – finns det inget absolut olämpligt.

Skurvarna försökte inte implantera något, eller ändra någon programvara som kan ha utlöst ett larm.

De utlöste en sårbarhet, så det kommer att finnas några biverkningar i loggarna...

…frågan är, är du medveten om vad du kan leta efter?

Letar du regelbundet?

Och om du hittar något avvikande, har du ett bra sätt att reagera snabbt och effektivt?

---

DOUG.  Bra.

Och på tal om att hitta saker, vi har två berättelser om nolldagar.

Låt oss börja med Chrome noll-dag först.

---

ANKA.  Ja, den här historien bröts i mitten av förra veckan, precis efter att vi spelade in förra veckans podcast, och det var 11 säkerhetsfixar som kom ut vid den tiden.

En av dem var särskilt anmärkningsvärd, och det var CVE-2022-2856, och den beskrevs som "Otillräcklig validering av otillförlitlig input i Intents."

En avsikt. Om du någonsin har gjort Android-programmering... är det tanken på att ha en åtgärd på en webbsida som säger: "Ja, jag vill inte bara att det här ska visas. När sånt här händer vill jag att det ska hanteras av den här andra lokala appen.”

Det är samma typ av idé som att ha en magisk webbadress som säger: "Ja, det jag vill göra är att bearbeta det här lokalt."

Men Chrome och Android har det här sättet att göra det som kallas Intents, och du kan föreställa dig allt som tillåter opålitlig data på en webbsida att trigga en lokal app att göra något med den opålitliga data...

…kan faktiskt sluta väldigt illa.

Till exempel, "Gör det här som du verkligen inte ska göra."

Som "Hej, starta om installationen, skapa en ny administrativ användare"... precis som vi pratade om i Coin ATM Server.

Så problemet här var att Google medgav att detta var en nolldag, eftersom det var känt att det hade utnyttjats i verkligheten.

Men de gav inga detaljer om exakt vilka appar som utlöses; vilken typ av data skulle kunna utlösa; vad som kan hända om dessa appar triggades.

Så det var inte klart vilka indikatorer för kompromiss [IoCs] du kan leta efter.

Det som *var* tydligt är att den här uppdateringen var viktigare än den genomsnittliga Chrome-uppdateringen, på grund av nolldagarshålet.

Och förresten, det gällde även Microsoft Edge.

Microsoft skickade ut en säkerhetsvarning och sa: "Ja, vi har tittat, och så vitt vi kan se gäller detta även för Edge. Vi har typ ärvt buggen från Chromium-kodbasen. Övervaka den här ytan."

Och den 19 augusti 2022 släppte Microsoft en Edge-uppdatering.

Så oavsett om du har Chromium, Chrome, Edge eller någon annan Chromium-relaterad webbläsare, måste du gå och se till att du har den senaste versionen.

Och du föreställer dig att något daterat den 18 augusti 2022 eller senare förmodligen har denna fix i sig.

Om du söker efter versionskommentarer för vilken Chromium-baserad webbläsare du än använder, vill du söka efter: CVE 2022-2856.

---

DOUG.  Okej, då har vi en fjärrkodexekveringshål i Apples WebKit HTML-renderingsprogram, vilket kan leda till ett kärnexekveringshål...

---

ANKA.  Ja, det var en ännu mer spännande historia!

Som vi alltid säger kom Apples uppdateringar precis när de kom.

Men den här dök plötsligt upp, och den fixade bara dessa två hål, och de är båda i det vilda.

En, som du säger, var en bugg i WebKit, CVE-2022-32893, och den andra, som är -32894, är, om du vill, ett motsvarande hål i själva kärnan... båda fixade samtidigt, båda i det vilda.

Det luktar som att de hittades samtidigt eftersom de utnyttjades parallellt.

WebKit-buggen för att komma in, och kärnbuggen för att komma upp och ta över hela systemet.

När vi hör sådana korrigeringar från Apple, där allt de fixar är web-bug-plus-kernel-bug på samma gång: "I det vilda! Patcha nu!”...

..din omedelbara tanke är, eh-oh, detta kan tillåta jailbreaking, där i princip alla Apples säkerhetsbegränsningar tas bort, eller spionprogram.

Apple har inte sagt så mycket mer än: ”Det finns dessa två buggar; de hittades samtidigt, rapporterade av en anonym forskare; de är båda lappade; och de gäller alla iPhones, iPads och Macs som stöds."

Och det intressanta är att den senaste versionen av macOS, Monterey... som fick en hel patch på operativsystemnivå direkt.

De tidigare två versionerna av Mac som stöddes (det är Big Sur och Catalina, macOS 10 och 11)... de fick inte patchar på operativsystemnivå, som om de inte var sårbara för kärnexploateringen.

Men de *fick* en helt ny version av Safari, som följde med Monterey-uppdateringen.

Detta tyder på att de definitivt riskerar att ta över WebKit.

Och, som vi har sagt tidigare, Doug, det kritiska med kritiska buggar i Apples WebKit är tvåfaldigt:

(1) På iPhones och iPads, alla webbläsare och all webbrenderingsprogramvara, om den ska tillåtas i App Store, *måste använda WebKit*.

Även om det är Firefox, även om det är Chrome, även om det är Brave, vilken webbläsare det än är... de måste riva ut alla motorer som de kan använda och sätta in WebKit-motorn under.

Så bara att undvika Safari på iPhones kommer du inte runt det här problemet. Det är (1).

Siffran (2) är att många appar, både på Mac och iDevices, använder HTML som ett mycket bekvämt, effektivt och vackert sätt att göra saker som Hjälpskärmar och Om Windows.

Varför skulle du inte det?

Varför bygga din egen grafik när du kan skapa en HTML-sida som anpassar sig för att passa vilken enhet du än har?

Så många appar *som inte är webbläsare* kan använda HTML som en del av sitt skärmspråk om du vill, särskilt i Om skärmar och Hjälp Windows.

Det betyder att de förmodligen använder en Apple-funktion som heter WebView, som gör HTML-renderingen åt dem.

Och WebView är baserat på WebKit, och WebKit har denna bugg!

Så det här är inte bara ett problem för webbläsaren.

Det skulle i teorin kunna utnyttjas mot vilken app som helst som bara råkar använda HTML, även om det bara är skärmen Om.

Så det är de två kritiska problemen med just detta kritiska problem, nämligen: (1) buggen i WebKit, och, naturligtvis, (2) på Monterey och på iPhones och iPads, det faktum att det också fanns en kärnsårbarhet , som förmodligen skulle kunna utnyttjas i en kedja.

Det innebar inte bara att skurkarna kunde ta sig in, de kunde klättra uppför stegen och ta över.

Och det är verkligen väldigt dåligt.

---

DOUG.  OK, det leder bra till vår läsarfråga i slutet av varje show.

På Apples dubbla nolldagsberättelse frågar läsaren Susan ett enkelt men utmärkt fråga: "Hur skulle en användare veta om utnyttjandet båda hade utförts på deras telefon?"

Hur skulle du veta?

---

ANKA.  Doug... det knepiga i det här fallet är att du förmodligen inte skulle göra det.

Jag menar, det *kan* finnas någon uppenbar bieffekt, som att din telefon plötsligt börjar krascha när du kör en app som varit helt tillförlitlig tidigare, så att du blir misstänksam och du får någon expert att titta på den åt dig, kanske för att du anser att du löper stor risk att någon vill knäcka din telefon.

Men för den genomsnittliga användaren är problemet här att Apple just sa: "Tja, det finns den här buggen i WebKit; det finns den här buggen i kärnan."

Det finns inga indikatorer på kompromiss. ingen proof-of-concept-kod; ingen beskrivning av exakt vilka biverkningar som kan lämnas kvar, om några.

Så det är nästan som om det enda sättet att ta reda på exakt vilka synliga biverkningar dessa buggar kan lämna kvar permanent. som du kan gå och leta efter...

… skulle i huvudsak vara att återupptäcka dessa buggar själv, och ta reda på hur de fungerar och skriva en rapport.

Och så vitt jag vet finns det bara inga indikatorer på kompromiss (eller några pålitliga sådana) där ute som du kan gå och söka efter på din telefon.

Det enda sättet jag kan tänka på som skulle låta dig gå tillbaka till i huvudsak ett "känd bra" tillstånd skulle vara att undersöka hur man använder Apples DFU-system (som jag tror står för Device Firmware Update).

I grund och botten finns det en speciell tangentsekvens du trycker på, och du måste koppla din enhet med en USB-kabel till en pålitlig dator, och i princip installerar den om hela firmware... den senaste firmwaren – Apple låter dig inte nedgradera, eftersom de vet att folk använder det för jailbreaking-trick). [SKratt]

Så, den laddar ner i princip den senaste firmware – det är inte som en uppdatering, det är en ominstallation.

Det torkar i princip din enhet och installerar allt igen, vilket får dig tillbaka till ett känt-bra skick.

Men det är ungefär som att slänga din telefon och köpa en ny – du måste ställa in den från början, så att all din data raderas.

Och, viktigare, om du har några 2FA-kodgenereringssekvenser inställda där, kommer *dessa sekvenser att raderas*.

Så se till, innan du gör en enhetsfirmwareuppdatering där allt kommer att raderas, att du har sätt att återställa konton eller att ställa in 2FA fresh.

För efter att du har gjort den DFU kommer alla autentiseringssekvenser som du kan ha programmerat in i din telefon att försvinna, och du kommer inte att kunna återställa dem.

---

DOUG.  OK. [LÅT NED] JAG...

---

ANKA.  Det var inget bra svar, Doug...

---

DOUG.  Nej, det har ingenting med detta att göra – bara en sidoanteckning.

Jag uppgraderade min Pixel-telefon till Android 13, och den murade telefonen, och jag tappade mina 2FA-grejer, vilket var en riktig stor grej!

---

ANKA.  *Brickade* den [GJORDE DEN OBOTABLER FÖR EVIGT] eller bara torkade den?

Fungerar telefonen fortfarande?

---

DOUG.  Nej, den slås inte på.

Den frös, och jag stängde av den, och jag kunde inte slå på den igen!

---

ANKA.  Jasså?

---

DOUG.  Så de skickar en ny till mig.

Normalt när du skaffar en ny telefon kan du använda den gamla telefonen för att konfigurera den nya telefonen, men den gamla telefonen slås inte på...

…så den här historien träffade bara lite nära hemmet.

Gjorde mig lite vemodig, eftersom jag nu använder den ursprungliga Pixel XL, som är den enda telefonen jag hade som backup.

Och den är stor, otymplig och långsam, och batteriet är inte bra... det är mitt liv.

---

ANKA.  Nåväl, Doug, du kan nappa ner till telefonbutiken och köpa dig en Apple [DOUG BÖRJAR LAGA FÖR ATT HAN ÄR EN ANDROID FANBUOY] iPhone SE 2022!

---

DOUG.  [FÖRING] Ingen chans!

Nej! Nej! Nej!

Min två dagars frakt.

---

ANKA.  Smal, lätt, billig och vacker.

Mycket snyggare än vilken Pixel-telefon som helst – jag har en av varje.

Pixel-telefoner är fantastiska, men...

[HOSTA MED VETENHET, VISKAR] …iPhonen är bättre, Doug!

---

DOUG.  OK, en annan historia för en annan gång!

Susan, tack för att du skickade in den frågan.

Det var en kommentar till den artikeln, vilket är jättebra. så gå och titta på det där.

Om du har en intressant berättelse, kommentar eller fråga som du vill skicka in, läser vi det gärna i podden.

Du kan maila tips@sophos.com; du kan kommentera vilken som helst av våra artiklar; eller så kan du träffa oss på sociala: @NakedSecurity.

Det är vår show för idag – tack så mycket för att du lyssnade.

För Paul Ducklin, jag är Doug Aamoth, påminner dig, tills nästa gång, att...

---

BÅDE.  Håll dig säker!

[MUSIKALT MODEM]