Belkin Wemo Smart Plug V2 – bufferoverløbet, der ikke vil blive rettet

Belkin Wemo Smart Plug V2 – bufferoverløbet, der ikke vil blive rettet

Tidsstempel: 16. maj 2023 kl. 1
Kildeknude: 2657924
by

Forskere hos IoT-sikkerhedsvirksomheden Sternum gravet i et populært netstik til hjemmeautomatik fra det kendte enhedsmærke Belkin.

Modellen de så på, den Wemo Mini Smart Plug (F7C063) er tilsyneladende ved at være mod slutningen af ​​sin holdbarhed, men vi fandt masser af dem til salg online sammen med detaljerede råd og instruktioner på Belkins websted om, hvordan man sætter dem op.

Gamle (i den kortsigtede moderne forstand), selvom de kunne være, bemærkede forskerne at:

Vores første interesse for enheden kom fra at have flere af disse liggende rundt i vores laboratorium og brugt i vores hjem, så vi ville bare se, hvor sikre (eller ej) de var at bruge. [... Det ser ud til at være en ret populær forbrugerenhed[; b]baseret på disse tal er det sikkert at anslå, at det samlede salg på Amazon alene burde være i hundredtusindvis.

Kort sagt, der er masser af mennesker derude, som allerede har købt og tilsluttet disse ting, og som bruger dem lige nu til at styre stikkontakter i deres hjem.

Et "smartstik", kort sagt, er en stikkontakt, som du sætter i en eksisterende stikkontakt, og som indskyder en Wi-Fi-styret kontakt mellem stikkontakten på forsiden af ​​stikkontakten og en stikkontakt, der ser identisk ud. forsiden af ​​smartstikket. Tænk på det som en strømadapter, der i stedet for at konvertere f.eks. en rund Euro-stikdåse til en trekantet britisk, konverterer f.eks. et manuelt skiftet amerikansk stik til et elektronisk skiftet amerikansk stik, der kan fjernstyres via en app eller en web-type grænseflade.

S'et i IoT...

Problemet med mange såkaldte Internet of Things (IoT) enheder, som den gamle joke siger, er, at det er bogstavet "S" i "IoT", der står for sikkerhed...

…hvilket selvfølgelig betyder, at der ofte ikke er så meget cybersikkerhed, som du kunne forvente, eller endda nogen overhovedet.

Som du kan forestille dig, kan en usikker hjemmeautomatiseringsenhed, især en, der kan tillade nogen uden for dit hus, eller endda på den anden side af verden, at tænde og slukke for elektriske apparater efter behag, føre til masser af problemer.

Vi har skrevet om IoT-usikkerhed i en lang række forskellige produkter før, fra internetkedler (ja, virkelig), der kunne lække dit Wi-Fi-adgangskode i hjemmet til sikkerhedskameraer, som skurke kan bruge til at holde deres øje på dig i stedet for omvendt, til netværkstilsluttede diskdrev med risiko for at få splattet af ransomware direkte på internettet.

I dette tilfælde fandt forskerne et eksternt kodeudførelseshul i Wemo Mini Smart Plug tilbage i januar 2023, rapporterede det i februar 2023 og modtog et CVE-nummer for det i marts 2023 (CVE-2023-27217).

Desværre, selvom der næsten helt sikkert er mange af disse enheder i aktiv brug i den virkelige verden, har Belkin tilsyneladende sagt, at den anser enheden for at være "ved slutningen af ​​sin levetid", og at sikkerhedshullet derfor ikke vil blive rettet.

(Vi er ikke sikre på, hvor acceptabel denne form for "end of life"-afskedigelse ville være, hvis enheden viste sig at have en fejl i dets 120V AC eller 230V AC elektriske kredsløb, såsom muligheden for overophedning og udsendelse af skadelige kemikalier eller indstilling i brand, men det ser ud til, at fejl i den digitale lavspændingselektronik eller firmware i enheden kan ignoreres, selvom de kan føre til, at en cyberangriber blinker med hovedafbryderen i enheden til og fra gentagne gange efter ønske.)

Når venlige navne er din fjende

Problemet, som forskerne opdagede, var et godt gammelt problem stak bufferoverløb i den del af enhedssoftwaren, der giver dig mulighed for at ændre den såkaldte FriendlyName af enheden – den tekststreng, der vises, når du opretter forbindelse til den med en app på din telefon.

Som standard starter disse enheder med et venligt navn i stil med Wemo mini XYZHvor XYZ angiver tre hexadecimale cifre, som vi gætter på er valgt pseudotilfældigt.

Det betyder, at selv om du ejer to eller tre af disse enheder, vil de næsten helt sikkert starte med forskellige navne, så du nemt kan konfigurere dem.

Men du vil sikkert gerne omdøbe dem senere, så de er nemmere at skelne fra hinanden i fremtiden ved at tildele venlige navne som f.eks. TV power, Laptop charger , Raspberry Pi server.

Belkin-programmørerne (eller mere præcist, programmørerne af koden, der endte i disse Belkin-mærkede enheder, som også kunne have leveret smart plug-software til andre mærkenavne) reserverede tilsyneladende 68 bytes midlertidigt lager for at holde styr på nyt navn under omdøbningsprocessen.

Men de glemte at tjekke, at det navn, du angav, ville passe ind i det 68-byte slot.

I stedet antog de, at du ville bruge deres officielle telefonapp til at udføre enhedens omdøbningsprocessen, og dermed kunne de begrænse mængden af ​​data, der sendes til enheden i første omgang, for at afværge ethvert bufferoverløb, der ellers kunne opstå.

Ironisk nok var de meget omhyggelige med ikke blot at holde dig til den 68-byte grænse, der kræves for selve enheden til at opføre sig korrekt, men endda for at begrænse dig til at skrive på kun 30 tegn.

Vi ved alle, hvorfor det er en frygtelig idé at lade klientsiden foretage fejlkontrollen i stedet for at tjekke i stedet (eller endnu bedre) på serversiden:

  • Klientkoden og serverkoden kan glide ud af overensstemmelse. Fremtidige klientapps vil måske beslutte, at navne på 72 tegn ville være en god mulighed og begynde at sende flere data til serveren, end den sikkert kan håndtere. Fremtidige server-side kodere vil måske bemærke, at ingen nogensinde syntes at bruge de fulde 68 bytes reserverede, og ensidigt beslutte, at 24 skulle være mere end nok.
  • En angriber kunne vælge ikke at genere appen. Ved at generere og overføre deres egne anmodninger til enheden ville de trivielt omgå enhver sikkerhedskontrol, der er afhængig af appen alene.

Forskerne var hurtigt i stand til at prøve stadig længere navne til det punkt, at de kunne nedbryde Wemo-enheden efter forgodtbefindende ved at skrive over enden af ​​hukommelsesbufferen, der var reserveret til det nye navn, og korrumpere data gemt i de bytes, der fulgte umiddelbart efter.

Korrumperer stakken

Desværre, i et stack-baseret operativsystem, ender det meste software med dens stack-baserede midlertidige hukommelsesbuffere, så de fleste af disse buffere er tæt fulgt af en anden vital hukommelsesblok, der fortæller programmet, hvor det skal hen, når det er færdigt med hvad det gør lige nu.

Teknisk set er disse "hvor skal man gå videre" data bidder er kendt som returadresser, og de gemmes automatisk, når et program kalder det, der er kendt som en funktion eller subrutine, som er et stykke kode (for eksempel "udskriv denne besked" eller "pop en advarselsdialog op"), som du ønsker at kunne bruge i flere dele af dit program.

Returadressen bliver på magisk vis registreret på stakken, hver gang subrutinen bruges, så computeren automatisk kan "afvikle" sin vej for at komme tilbage til hvor subrutinen blev kaldt fra, hvilket kan være anderledes hver gang den aktiveres.

(Hvis en subrutine havde en fast returadresse, kunne du kun ringe til den fra ét sted i dit program, hvilket ville gøre det meningsløst at pakke den kode ind i en separat subrutine i første omgang.)

Som du kan forestille dig, hvis du tramper på den magiske returadresse, før subrutinen er færdig med at køre, så vil den tillidsfuldt, men ubevidst "afvikle" sig til det forkerte sted, når den slutter.

Med lidt (eller måske meget) held kan en angriber måske på forhånd forudsige, hvordan man trampe på returadressen kreativt, og derved misdirigere programmet på en bevidst og ondsindet måde.

I stedet for blot at gå ned, kan det forkerte program narre til at køre kode efter angriberens valg, hvilket forårsager, hvad der er kendt som en fjern kodeudførelse udnytte eller RCE.

To almindelige forsvar hjælper med at beskytte mod udnyttelser af denne art:

  • Randomisering af adresserumslayout, også kendt som ASLR. Operativsystemet indlæser bevidst programmer på lidt forskellige hukommelsesplaceringer, hver gang de kører. Dette gør det sværere for angribere at gætte, hvordan man fejldirigerer buggy-programmer på en måde, der i sidste ende får og bevarer kontrol i stedet for blot at crashe koden.
  • Stable kanariefugle, opkaldt efter de fugle, som minearbejdere plejede at tage med sig under jorden, fordi de ville besvime i nærværelse af metan og dermed give et grusomt, men effektivt tidligt varsel om risikoen for en eksplosion. Programmet indsætter bevidst en kendt, men tilfældig blok af data lige foran returadressen, hver gang en subrutine kaldes, så et bufferoverløb uundgåeligt og påviselig vil overskrive "kanariefuglen" først, før den overskrider langt nok til at trampe på den altafgørende returadresse.

For at få deres udnyttelse til at fungere hurtigt og pålideligt, var forskerne nødt til at tvinge Wemo-stikket til at slå ASLR fra, hvilket fjernangribere ikke ville være i stand til at gøre, men med mange forsøg i det virkelige liv, kan angribere alligevel være heldige, gæt rigtigt på de hukommelsesadresser, som programmet bruger, og få kontrol alligevel.

Men forskerne behøvede ikke at bekymre sig om stakkanarie-problemet, fordi buggy-appen var blevet kompileret fra sin kildekode med funktionen "indsæt kanariefugle-tjek sikkerhedsinstruktioner" slået fra.

(Kanarie-beskyttede programmer er typisk lidt større og langsommere end ubeskyttede på grund af den ekstra kode, der er nødvendig i hver underrutine for at udføre sikkerhedstjekket.)

Hvad skal jeg gøre?

  • Hvis du er Wemo Smart Plug V2-ejer, sørg for, at du ikke har konfigureret din hjemmerouter til at tillade, at enheden kan tilgås "udefra" over internettet. Dette reducerer det, der i jargonen er kendt som din angrebs overfladeareal.
  • Hvis du har en router, der understøtter Universal Plug and Play, også kendt som UPnP, skal du sørge for, at den er slået fra. UPnP gør det notorisk nemt for interne enheder at blive åbnet utilsigtet for udenforstående.
  • Hvis du er programmør, undgå at deaktivere softwaresikkerhedsfunktioner (såsom stakbeskyttelse eller stakkanariekontrol) bare for at spare nogle få bytes. Hvis du virkelig løber tør for hukommelse, skal du prøve at reducere dit fodaftryk ved at forbedre din kode eller fjerne funktioner i stedet for at mindske sikkerheden, så du kan proppe mere ind.

Tidsstempel:

Mere fra Naked Security