Haal het certificaat uit de flits van een Shark RV2320EDUS-robotstofzuiger en u kunt root-opdrachten uitvoeren op de Shark-stofzuigers van andere mensen in dezelfde AWS-regio: bekijk de camera, bestuur de robot, lees de kaart van het huis en neem het wifi-wachtwoord in leesbare tekst.
Een onderzoeker die onder het handvat publiceert tokay0 zette de methode maandag online, nadat hij deze alleen had getest met stofzuigers die hij zelf had gekocht. De fout was toen nog niet verholpen.
Hij zegt dat SharkNinja, het bedrijf achter de apparatenmerken Shark en Ninja, zijn rapport sinds maart heeft ontvangen.
Het beleid dat aan dat certificaat is gekoppeld, is nooit van toepassing geweest op het apparaat waarop het certificaat is geplaatst. Presenteer het aan de cloudmakelaar van Shark en de makelaar accepteert alles wat u publiceert, geadresseerd aan elk apparaat dat het bedient.
Geen geheugencorruptie, geen escalatie van privileges, geen wachtwoord om te raden. De opdracht die wordt uitgevoerd is een gewoon veld in de schaduw van het apparaat; het statusdocument per apparaat dat AWS in de cloud bewaart.
Met behulp van het certificaat van een RV2320EDUS abonneerde de onderzoeker zich op $aws/things/# en keek naar het verkeer dat de makelaar kruiste, terwijl hij serienummers verzamelde. Publiceren werkt op dezelfde manier. De schaduw bevat een Exec_Command-veld dat de managementdaemon appd leest en overhandigt aan een functie met de naam execute_command, die alles onder de 1000 bytes via popen uitvoert.
Stuur een schaduwupdate met dat veld naar het onderwerp van een apparaat. Als dat apparaat de handler implementeert, voert het de opdracht uit.
Hij bewees het cross-model-pad door een omgekeerde granaat op een AV1102ARUS te laten landen die hij puur als doelwit had gekocht, en vervolgens die granaat te gebruiken om live beelden van de ingebouwde camera van het model te trekken terwijl de robot rondreed.
Het certificaat komt eraf met een schroevendraaier. Het moederbord geeft UART-pinnen vrij, de U-Boot-console vraagt om geen wachtwoord, en init=/bin/sh in de opstartargumenten brengt je naar een root-shell, waar de sleutel per apparaat en het certificaat in /mnt/res/vapp/certs/ staan als gewone bestanden.
Certificaten worden vastgemaakt aan hun AWS-regio, wat hier het dichtst bij een limiet komt: een sleutel die in één regio wordt opgehaald, bereikt alleen de apparaten van die regio. Voor het bereiken van een andere regio is een ander certificaat nodig, dat daar is ingericht en hetzelfde kapotte beleid draagt.
Amazon heeft een auditcontrole voor deze exacte beleidsvorm. Device Defender, de IoT-vlootcontroleservice van AWS, markeert apparaatbeleid dat publiceren of abonneren op $aws/things/* toestaat in plaats van het onderwerp vast te zetten op het verbindende apparaat met ${iot:Connection.Thing.ThingName}.
Het verschijnt als IOT_POLICY_OVERLY_PERMISSIVE_CHECK, en AWS beoordeelt het als kritiek en waarschuwt in de documentatie dat een gecompromitteerd certificaat met een dergelijk beleid een aanvaller in staat stelt schaduwen, taken of taakuitvoeringen voor al uw apparaten te lezen of te wijzigen.
Niet elk certificaat is een skeletsleutel. Een vacuüm waarvan het certificaat het gebroken beleid bevat, is de sleutel van een aanvaller. Elk vacuüm dat Exec_Command uitvoert, is een doelwit, ongeacht of het eigen certificaat wel of niet correct is gescoped. De AV1102ARUS is een doel en geen sleutel: het certificaat had de juiste scope en kon zich niet met een wildcard abonneren. De firmware was enkele jaren nieuwer.
Hij beschouwt dat als een provisieoplossing die nooit de certificaten van de oudere vloot heeft bereikt. Dat is de reden waarom de cross-model-shell werkte, en waarom zijn bewering dat elke op het internet aangesloten Shark-stofzuiger kwetsbaar is, in tweeën moet worden gesplitst.
De kop op zijn post zegt miljoenen. Het cijfer dat hij heeft geverifieerd, is kleiner. Tokay0 keek 24 uur lang naar één AWS-regio en telde 1.517.605 unieke Shark-serienummers, waarvan 673.816, of 44%, een Exec_Response uitzond, die hij beschouwt als een bevestiging dat het apparaat de opdrachtafhandeling uitvoert. Dit zijn apparaten waarvan is waargenomen dat ze reageren, geen apparaten die zijn getest of gecompromitteerd, en hij zegt dat het werkelijke aantal waarschijnlijk hoger ligt.
Vier maanden en het telt
Volgens tokay0’s verslag van de correspondentie nam hij op 1 maart contact op met SharkNinja en stuurde details op 11 maart. Het bedrijf bevestigde de ontvangst de volgende dag, vertelde hem op 27 april dat het rapport werd beoordeeld en zei op 3 juli dat het tegen vrijdag 10 juli een bevestigde voltooiingsdatum zou sturen. Er kwam geen e-mail binnen.
Hij publiceerde op 13 juli. Hij zegt dat de leverancier de ernst bagatelliseerde en zich afvroeg of “een CVE gepast is.”
Wat specifiek IoT-rapporten betreft, verplicht SharkNinja’s gepubliceerde beleid inzake openbaarmaking van kwetsbaarheden het bedrijf om “regelmatige updates te verstrekken totdat de gerapporteerde kwetsbaarheid is opgelost.” Hetzelfde beleid vraagt onderzoekers om stil te blijven totdat het bedrijf een oplossing bevestigt of openbaarmaking schriftelijk toestaat.
SharkNinja had donderdag niets over de fout gepubliceerd. The Hacker News heeft contact opgenomen met het bedrijf voor commentaar op de patchstatus en de tijdlijn voor de openbaarmaking, en zal dit verhaal bijwerken bij eventuele reacties.
Er is ook geen CVE. Hij vroeg MITRE’s CNA in laatste instantie, de opdrachtgever die kwetsbaarheden afhandelt die niet door de CNA van de leverancier worden gedekt, op 11 juni om een identiteitsbewijs en had nog niets gehoord tegen de tijd dat hij publiceerde. Geen identificatie, geen CVSS, geen advies: niets waarop een programma voor kwetsbaarheidsbeheer kan inspelen.
De oplossing is aan de serverzijde
Het is niet de eigenaar die de oplossing installeert. Het bevindt zich in het AWS-account van SharkNinja, niet in de firmware van de robot. Volgens de herstelrichtlijnen van AWS wordt een niet-conform beleid vervangen door een scoped-versie te pushen met CreatePolicyVersion en de setAsDefault-vlag, waardoor die versie operationeel wordt voor elk certificaat dat het beleid gebruikt.
Geen firmware-uitrol vereist. Het opnieuw uitgeven van de certificaten, zoals Tokay0 in maart aanbeveelde, is het langere werk daarachter.
Totdat SharkNinja het een of het ander doet, is de enige oplossing die een eigenaar ter beschikking heeft, het loskoppelen van de stofzuiger van wifi. Dat maakt een einde aan app-controle, planning en kaarten, en verandert het product weer in een vacuüm.
tokay0 hield zijn scripts achter terwijl de fout live was. Hij oordeelde dat zijn andere bevindingen te klein waren om op te schrijven.
Hij heeft ook nooit de rest van SharkNinja’s verbonden assortiment onderzocht, de slimme grills en de draadloze vleessondes, die volgens hem waarschijnlijk ook kwetsbaar zijn. Deze producten zijn afkomstig van hetzelfde bedrijf waarvan het beleid regelmatige updates belooft totdat een fout is opgelost. Vier maanden later is deze dat niet meer.
