TL;DR
- Smart Bluetooth male chastity lock, utformad för att användaren ska ge fjärrkontroll till en betrodd 3: e part med hjälp av mobilapp/API
- flera API-brister innebar att någon kunde fjärrlåsa alla enheter och hindra användare från att släppa sig
- borttagning kräver då en vinkelslip eller liknande, som används i närheten av känsliga och känsliga områden sig över en 6 månad period
- sedan slutligen vägrade att interagera ytterligare, även om majoriteten av frågor löstes i migration till v2 API, men API v1 inexcusably kvar tillgängliga
- detta inlägg publiceras i samordning med Internet of Dongs
- 27/01/2021 de uppger att de mobila och API frågor har nu lösts.
smarta vuxna leksaker och oss
Vi har inte skrivit om smarta vuxna leksaker på länge, men Qiui Cellmate chastity cage var helt enkelt för intressant att passera. Vi fick tips om den vuxna kyskhetsanordningen, utformad för att låsa upp bärarens bihang.
det finns andra manliga kyskhetsenheter tillgängliga men det här är en Bluetooth (BLE) aktiverad lås-och klämmekanism med en följeslagare mobilapp. Tanken är att bäraren kan ge kontroll över låset till någon annan.
Vi är inte i branschen för kink shaming. Människor ska kunna använda dessa enheter säkert och säkert utan risk för att känsliga personuppgifter läcker ut.
säkerheten för teledildonics-fältet är intressant i sig. Det är värt att notera att försäljningen av smarta vuxna leksaker har ökat avsevärt under den senaste låsningen.
vad är risken för användarna?
vi upptäckte att fjärrangripare kunde förhindra att Bluetooth-låset öppnades, vilket permanent låste användaren i enheten. Det finns ingen fysisk upplåsning. Röret är låst på en ring som bärs runt könsorganens botten, vilket gör saker otillgängliga. En vinkelslipmaskin eller annat lämpligt tungt verktyg skulle krävas för att skära bäraren fri.
plats, klartext lösenord och andra personuppgifter läcktes också, utan behov av autentisering, av API.
Vi hade speciella problem under upplysningsprocessen, eftersom vi vanligtvis skulle be säljaren att ta ner ett läckande API medan sanering genomfördes. Men alla som för närvarande använder enheten när API togs offline skulle också vara permanent låsta in!
som du kommer att se i upplysningstidslinjen längst ner i det här inlägget, åtgärdades vissa problem men andra var inte, och säljaren slutade helt enkelt svara på oss, journalister och återförsäljare. Med tanke på den triviala karaktären att hitta några av dessa problem, och att företaget arbetar med en annan enhet som utgör ännu större potentiell fysisk skada (en ”intern” kyskhetsenhet), har vi känt oss tvungna att publicera dessa resultat vid denna tidpunkt.
frågorna
Vi har redigerat betydande detaljer här.
mobilapp
Vi hittade en allvarlig integritetssårbarhet mycket snabbt med mobilappen: alla API-slutpunkter var oautentiserade med endast en lång-ish ”memberCode” för att göra förfrågningar. MemberCode i sig är något deterministisk och baseras på det datum en användare registrerade sig för tjänsten, men vi hittade ett ännu enklare sätt att använda en kortare ”vänkod”.
en begäran med denna sexsiffriga ”vän” – kod returnerade en enorm mängd information om den användaren, inklusive mycket känslig information som deras namn, telefonnummer, Födelsedag, de exakta koordinaterna där appen öppnades, deras längre ”memberCode”-värde och användarens klartext-lösenord (inte för att vi behöver det).
det skulle inte ta en angripare mer än ett par dagar att exfiltrera hela användardatabasen och använda den för utpressning eller nätfiske.
siffror och läckta platsdata
Vi kunde prova några id slumpmässigt och visa användarplatser vid tidpunkten för appregistreringar. Tänk på att detta bara är en liten delmängd av användare från tillgängliga data. Vi kastade bort all personlig information omedelbart.
memberCode data = DoS för användaren
nu har vi längre memberCode vi kan hämta alla enheter som är associerade med den personen:
GET /list?memberCode=20200409xxxxxxxx HTTP/1.1Host: qiuitoy.comConnection: close "deviceId": 0, "deviceCode": "201909xxxxxxxxxx", "deviceName": "Cellmatexxxx", "deviceNick": "Cellmatexxxx", "deviceNumber": "QIUIxxxxxxxxx", "deviceType": 2, "deviceBlue": null, "deviceBlueAddr": "F9:34:02:XX:XX:XX", "isEncrypt": 1,
och när vi har det kan vi ta reda på vilka behörigheter den personen har över det låset (så kan de låsa upp det själva eller behöva fråga någon annan):
GET /wear?memberCode=20200409xxxxxxx&deviceCode=20191204xxxxxx HTTP/1.1Host: qiuitoy.com
och om de kan kan vi vända det så att de nu är låsta ur enheten:
POST /binding HTTP/1.1Host: qiuitoy.comConnection: closememberName=Pwned&memberCode=20200409xxxxxx&deviceCode=20191204xxxxxx
och vi kan göra det för alla, mycket snabbt, låsa alla in eller ut. Det finns ingen nödfunktion heller, så om du är låst finns det ingen väg ut. Detta kan eller inte kan betraktas som en funktion!
BLE-problem
BLE-implementeringen i sig kräver en API-begäran för att generera ett upplåsningskommando baserat på en token som tidigare skrivits till låset. Det är möjligt att vi kan analysera förfrågningar och svar för att generera rätt nyckel, eller bakåtkompilera själva låshårdvaran…
ovanstående tas från den dekompilerade Android-appen och genom att ansluta den till Frida kan vi se meddelandena (36f6) och skriver (36f5) associerad med att kontrollera batterinivån först och sedan låsa upp (den tredje skrivningen):
BluetoothGattCallback constructor called from com.apicloud.uzble.AndroidBle$2 UUID: 000036f5-0000-1000-8000-00805f9b34fb data: 0x56f3430769ddd6e1603xxx UUID: 000036f6-0000-1000-8000-00805f9b34fb data: 0xe01012b3074d111c98bxxx UUID: 000036f5-0000-1000-8000-00805f9b34fb data: 0x25f8a92325fd9cfc7ea79xxx UUID: 000036f6-0000-1000-8000-00805f9b34fb data: 0x2717dd996ab4a017a6ceexxx UUID: 000036f5-0000-1000-8000-00805f9b34fb data: 0x9ee90373a2d3f156b3557xxx UUID: 000036f6-0000-1000-8000-00805f9b34fb data: 0xbcdaea06fa1cb94f3f1c2596xxx UUID: 000036f5-0000-1000-8000-00805f9b34fb data: 0x9ee90373a2d3f156b3557d52xxxx UUID: 000036f6-0000-1000-8000-00805f9b34fb data: 0xc04dab04c54c818d808a78c79adef839
men vänta, att hex från Android app, och BLE egenskaper ser väldigt bekant. Det är exakt samma implementering som Nokelock vi tittade på, förutom att det annonserade enhetsnamnet är ”OKGSS101”.
AES-krypteringsnyckeln per lock returneras i API-anropet som listar de enheter Vi gjorde tidigare. Mass upplåsning över BLE någon?
låst i? Här är en lösning
om du befinner dig inlåst, undrar du förmodligen hur du kan komma ut utan tunga verktyg eller ett besök på akuten…
utformningen av låsstiftet använder en motor för att dra tillbaka den och är tyvärr inte järnhaltig, så ingen enkel användning av magneter, och inte heller ”stöter” den öppen (som du kommer att bära den). Jag hade lite framgång med en shim gjord av en uppskuren burk, men tanken på skarp spetsig metall nära allt viktigt är inte idealiskt.
det ”bättre” alternativet är att prise öppna kretskortets område där den främre knappen och lampan är:
det är limmat in men kom ut utan mycket ansträngning eller skada. 3 volt (två AA-batterier) applicerade på de vita och gula ledningarna räcker för att driva upplåsningsmotorn direkt (vit = negativ, gul = positiv), en teknik som kallas ”spiking”.
din lokala akutavdelning kommer förmodligen att ha rätt verktyg för att skära om metallen säkert men och skulle vara din bättre första anlöpshamn!
slutsats
för ett realistiskt hot verkar risken för läckage av personuppgifter mer sannolikt att utnyttjas och ge belöning till en angripare.
ett antal länder har förtryckande lagar som kan utsätta användare av dessa typer av enheter för obefogat intresse från brottsbekämpning och bigots.
vidare kommer användarna sannolikt att vilja hålla sina privata liv privata. De bör förvänta sig integritet som standard och säkerhet genom design. Om man vill dela mycket privat information, bör det ske genom användarens uttryckliga avsikt.
många vuxna leksaksleverantörer har visat nästan fullständig ignorering för integritet och säkerhet under de senaste åren. Lyckligtvis har projekt som dongs Internet hjälpt till att vägleda många mot förbättrad säkerhet. Det är uppenbart att Qiui inte hade fått meddelandet.
Disclosure timeline
Disclosure var inte så sömlös som vi ursprungligen hade hoppats:
April 20th 2020: vi meddelade dem att fråga vem som skulle rapportera problemet till. De svarade mycket snabbt. Coolt!
inga problem, så vi försökte igen utan PGP:
Så vi skickade dem detaljerna. Tystnad regerade.
26 maj 2020: vi pressade lite hårdare, svarade de och uppgav att de skulle fixa den 6 juni.
11/06/2020: en uppdaterad version distribuerades till appen & spela butiker. Detta löste mestadels problem med förfrågningar som nu tvingas autentisera. Äldre API-slutpunkter lämnades dock upp, och nya API: er returnerade fortfarande exakta användarplatser.
juni 17th 2020: vi skickade ett meddelande som beskriver de återstående problemen, utan svar.25 juni 2020: vi nådde ut igen, via en journalist, Qiui sa att de inte ville fixa (eller inte kunde) eftersom de ”bara” hade 50 000 dollar.
30 juni 2020: vi skickade ett uppföljningsmail (och twitter DM) med potentiella korrigeringar av de återstående problemen (och hade det översatt till Kinesiska för fall), utan svar.
10 juli 2020: vi kontaktade två brittiska återförsäljare av enheten för att göra dem medvetna om problemen. En drog tillbaka den från försäljningen och kontaktade de EU-baserade grossisterna. Qiui svarade tillbaka till återförsäljarna att de återstående problemen skulle åtgärdas ”i augusti”.
11 September 2020: RenderMan från @InternetOfDongs kom i kontakt med oss också: han hade hjälpt en annan forskare genom avslöjandeprocessen med Qiui. @MikeTsenatek hade hittat ett lösenordsåterställningsproblem oberoende och kämpade också för att bli hörd av säljaren. Av en slump märkte han en tweet av mig för en tid sedan, tänkte att vi kanske tittar på den här enheten och nådde ut.
Vi hade ett bra samtal tillsammans där vi utbytte anmärkningsvärt liknande erfarenheter av interaktioner med Qiui! Hans uppskrivning finns här.
detta förstärkte vårt beslut att publicera: det var uppenbart att andra sannolikt skulle hitta dessa frågor oberoende av oss, så allmänintresset gjordes i våra sinnen.
RenderMan förtjänar definitivt kudos för hans fortsatta ansträngningar att mäkla samtal mellan forskare och leverantörer i vuxenleksakarenan. Vissa leverantörer har gjort betydande förbättringar av deras produktsäkerhet och integritet som ett resultat av hans hårda arbete.
4 oktober 2020: vi kontaktades av en tredje forskare med liknande problem.
6 oktober 2020: vi publicerade i samordning med de andra parterna.
Uppdatering 27/01/2021
Qiui Europeiska distributör bad oss att ge en uppdatering till denna blogg mot bakgrund av utvecklingen. De kontaktade oss den 28 December, förklarar att problemet var med mobilappen. Detta var inte vår förståelse, med tanke på säkerhetsproblemen ovan finns i API.
hur som helst, vi bad om bevis på detta och skickades en penna testrapport från mobilappen av en 3: e part .
rapporten var tydligt av mobilappen och hade gjort ett antal rekommendationer.
Vi gick tillbaka till distributören och bad om en kopia av en penna testrapport av API.
detta kom den 19 januari. Ett antal andra problem hade noterats, ett resultat av ett fullt godkänt penntest, som vi inte hade tillstånd att göra under vår ursprungliga forskning.
de anger att mobil-och API-problemen nu har lösts.
