TL;DR

• Smart Bluetooth mandlig kyskhedslås, designet til brugeren til at give Fjernbetjening til en betroet 3. part ved hjælp af mobilapp/API
• flere API-fejl betød, at enhver kunne fjernlåse alle enheder og forhindre brugere i at frigive sig selv
• fjernelse kræver derefter en vinkelsliber eller lignende, der bruges i nærheden af sarte og følsomme områder
• præcise brugerplaceringsdata lækket også af API, inklusive personlige oplysninger og private chats
• leverandør oprindeligt lydhør, så gik glip af tre de satte sig over en 6 måned periode
• nægtede derefter endelig at interagere yderligere, selvom størstedelen af problemer blev løst i migrering til v2 API, men alligevel API v1 ubønhørligt tilbage til rådighed
• dette indlæg offentliggøres i koordinering med Internet of Dongs
• 27/01/2021 de angiver, at mobil-og API-problemerne nu er løst.

Smart voksen legetøj og os

Vi har ikke skrevet om smart voksen legetøj i lang tid, men Chiui Cellmate kyskhed bur var simpelthen for interessant at passere forbi. Vi blev tippet om den voksne kyskhed enhed, designet til at låse op bærerens vedhæng.

Der er andre mandlige kyskhedsenheder tilgængelige, men dette er en Bluetooth (BLE) aktiveret lås og klemmemekanisme med en ledsagende mobilapp. Tanken er, at bæreren kan give kontrol over låsen til en anden.

Vi er ikke i gang med kink shaming. Folk skal være i stand til at bruge disse enheder sikkert og sikkert uden risiko for, at følsomme personoplysninger lækkes.

sikkerheden i teledildonics-feltet er interessant i sig selv. Det er værd at bemærke, at salget af smart voksenlegetøj er steget markant under den nylige nedlukning.

hvad er risikoen for brugerne?

vi opdagede, at fjernangribere kunne forhindre Bluetooth-låsen i at blive åbnet og Permanent låse brugeren i enheden. Der er ingen fysisk oplåsning. Røret er låst på en ring, der bæres rundt om kønsorganets bund, hvilket gør tingene utilgængelige. En vinkelsliber eller andet egnet tungt værktøj ville være påkrævet for at skære bæreren fri.

placering, adgangskode til almindelig tekst og andre personlige data blev også lækket uden behov for godkendelse af API ‘ en.

Vi havde særlige problemer under oplysningsprocessen, da vi normalt ville bede sælgeren om at tage et utæt API ned, mens afhjælpning blev implementeret. Imidlertid, enhver, der i øjeblikket bruger enheden, da API ‘ en blev taget offline, ville også være permanent låst inde!

som du vil se i oplysningstidslinjen nederst i dette indlæg, blev nogle problemer afhjulpet, men andre var ikke, og sælgeren stoppede simpelthen med at svare os, journalister og detailhandlere. I betragtning af den trivielle karakter af at finde nogle af disse problemer, og at virksomheden arbejder på en anden enhed, der udgør endnu større potentiel fysisk skade (en “intern” kyskhedsenhed), har vi følt os tvunget til at offentliggøre disse resultater på dette tidspunkt.

problemerne

Vi har redigeret vigtige detaljer her.

mobilapp

Vi fandt en alvorlig sårbarhed over for privatlivets fred meget hurtigt med mobilappen: alle API-slutpunkter blev ikke godkendt ved kun at bruge en lang ish “memberCode” til at fremsætte anmodninger. Selve membercoden er noget deterministisk og er baseret på den dato, en bruger tilmeldte sig tjenesten, men vi fandt en endnu nemmere måde at bruge en kortere “venekode”på.

en anmodning med denne sekscifrede “ven”-kode returnerede en enorm mængde information om den bruger, herunder meget følsomme oplysninger såsom deres navn, telefonnummer, fødselsdag, de nøjagtige koordinater, hvor appen blev åbnet, deres længere “memberCode” – værdi og brugerens adgangskode til almindelig tekst (ikke at vi har brug for det).

det ville ikke tage en angriber mere end et par dage at eksfiltrere hele brugerdatabasen og bruge den til afpresning eller phishing.

numre og lækkede placeringsdata

Vi var i stand til at prøve et par id ‘ er tilfældigt og vise brugerplaceringer på tidspunktet for appregistreringer. Husk, at dette kun er en lille delmængde af brugere fra de tilgængelige data. Vi smed straks alle personlige oplysninger væk.

memberCode data = DoS for brugeren

nu har vi den længere memberCode, vi kan hente alle de enheder, der er knyttet til den pågældende person:

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,

og når vi har det, kan vi finde ud af, hvilke tilladelser den person har over den lås (så kan de låse den op selv eller skal spørge en anden):

GET /wear?memberCode=20200409xxxxxxx&deviceCode=20191204xxxxxx HTTP/1.1Host: qiuitoy.com

og hvis de kan, kan vi vende det, så de nu er låst ud af enheden:

POST /binding HTTP/1.1Host: qiuitoy.comConnection: closememberName=Pwned&memberCode=20200409xxxxxx&deviceCode=20191204xxxxxx

og vi kan gøre det for alle, meget hurtigt, låse alle ind eller ud. Der er heller ingen nødoverstyringsfunktion, så hvis du er låst inde, er der ingen vej ud. Dette kan eller måske ikke betragtes som en funktion!

BLE-problemer

BLE-implementeringen i sig selv kræver en API-anmodning om at generere en oplåsningskommando baseret på et token, der tidligere er skrevet til låsen. Det er muligt, at vi kunne analysere anmodningerne og svarene for at generere den rigtige nøgle eller reverse engineer selve låseudstyret…

ovenstående er taget fra den dekompilerede Android-app og ved at tilslutte den med Frida kan vi se meddelelserne (36f6) og skriver (36f5) forbundet med at kontrollere batteriniveauet først og derefter låse op (den tredje skrive):

 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 vent, at sekskant fra Android app, og BLE karakteristika ser frygtelig bekendt. Det er nøjagtig den samme implementering som Nokelock vi kiggede på, undtagen det annoncerede enhedsnavn er “OKGSS101”.

per lock AES-krypteringsnøglen returneres i API-opkaldet, der viser de enheder, vi lavede tidligere. Masse oplåsning løbet BLE nogen?

låst inde? Her er en løsning

Hvis du befinder dig låst inde, undrer du dig sandsynligvis over, hvordan du kan komme ud uden tunge værktøjer eller et besøg på skadestuen…

designet af låsestiften bruger en motor til at trække den tilbage og er desværre ikke jernholdig, så ingen let brug af magneter, og det er heller ikke “bumping” det åbent (som du har det på). Jeg havde en lille succes med en shim lavet af en cut-up dåse, men ideen om skarpt spids metal nær noget vigtigt er ikke ideel.

det “bedre” alternativ er at prise åbne printkortområdet, hvor frontknappen og lyset er:

det er limet ind, men kom ud uden stor indsats eller skade. 3 volt (to AA-batterier), der påføres de hvide og gule ledninger, er nok til at drive oplåsningsmotoren direkte (hvid = negativ, gul = Positiv), en teknik kendt som “spiking”.

din lokale beredskabsafdeling vil sandsynligvis have de rigtige værktøjer til at skære selvom metallet sikkert og ville være din bedre første anløbshavn!

konklusion

for en realistisk trussel synes risikoen for lækage af personlige data mere sandsynligt at blive udnyttet og give belønning til en angriber.

en række lande har undertrykkende love, der kan udsætte brugere af disse typer enheder for uberettiget interesse fra retshåndhævelse og bigots.

desuden vil brugerne sandsynligvis gerne holde deres private liv private. De bør forvente privatliv som standard og sikkerhed ved design. Hvis man ønsker at dele meget private oplysninger, skal det være ved eksplicit hensigt fra brugeren.

mange voksne legetøjsleverandører har vist næsten fuldstændig tilsidesættelse af privatlivets fred og sikkerhed i de senere år. Heldigvis har projekter som Internet of Dongs hjulpet med at guide mange mod forbedret sikkerhed. Det var tydeligt, at Niall ikke havde fået beskeden.

Disclosure timeline

Disclosure var ikke så problemfri, som vi oprindeligt havde håbet:

20.April 2020: vi sendte en besked til dem, der spurgte, hvem de skulle rapportere problemet til. De svarede meget hurtigt. Sejt!

intet problem, så vi prøvede igen uden PGP:

så vi sendte dem detaljerne. Stilhed regerede.

26. maj 2020: vi skubbede lidt hårdere, svarede de og sagde, at de ville ordne den 6.juni.

11/06/2020: en opdateret version blev implementeret til appen & Play Stores. Dette løste for det meste problemer med anmodninger, der nu bliver tvunget til at godkende. Ældre API-slutpunkter blev dog efterladt, og nye API ‘ er returnerede stadig nøjagtige brugerplaceringer.

17. juni 2020: vi sendte en besked, der beskriver de resterende problemer uden svar.25. juni 2020: vi nåede ud igen via en journalist, sagde Chiui, at de ikke ønskede at rette (eller ikke kunne), da de “kun” havde $50.000.

30. juni 2020: vi sendte en opfølgende e-mail (og kvidre DM) med potentielle rettelser til de resterende problemer (og fik den oversat til Kinesisk i tilfælde af) uden svar.

10. juli 2020: vi kontaktede to britiske forhandlere af enheden for at gøre dem opmærksomme på problemerne. Den ene trak den tilbage fra salget og kontaktede de EU-baserede grossister. Kiui svarede tilbage til detailhandlerne, at de resterende problemer ville blive løst “i August”.11. September 2020: RenderMan fra @ InternetOfDongs kom også i kontakt med os: han havde hjulpet en anden forsker gennem afsløringsprocessen med Chiui. @MikeTsenatek havde fundet et problem med nulstilling af adgangskode uafhængigt og kæmpede også for at blive hørt af sælgeren. Ved en tilfældighed bemærkede han en kvidre af mig for nogen tid siden, regnede med, at vi måske kiggede på denne enhed og nåede ud.

Vi havde et godt opkald sammen, hvor vi udvekslede bemærkelsesværdigt lignende oplevelser af interaktioner med Chiui! Hans opskrivning er tilgængelig her.

dette forstærkede vores beslutning om at offentliggøre: det var klart, at andre sandsynligvis ville finde disse spørgsmål uafhængige af os, så sagen om offentlig interesse blev fremsat i vores sind.RenderMan fortjener bestemt kudos for hans fortsatte bestræbelser på at mægle samtaler mellem forskere og leverandører i voksenlegetøjsarenaen. Nogle leverandører har foretaget betydelige forbedringer af deres produktsikkerhed og privatliv som et resultat af hans hårde arbejde.

4. oktober 2020: vi blev kontaktet af en tredje forsker med lignende bekymringer.

6. oktober 2020: vi offentliggjorde i samarbejde med de andre parter.

opdatering 27/01/2021

Chiuis Europæiske distributør bad os om at give en opdatering til denne blog i lyset af udviklingen. De kontaktede os den 28. December og forklarede, at problemet var med mobilappen. Dette var ikke vores forståelse, da sikkerhedsproblemerne ovenfor er i API ‘ en.

alligevel bad vi om bevis for dette og blev sendt en pen testrapport fra mobilappen af en 3 .part.

rapporten var tydeligt af mobilappen og havde fremsat en række anbefalinger.

Vi gik tilbage til distributøren og bad om en kopi af en pen testrapport af API.

dette ankom den 19.januar. En række andre problemer var blevet bemærket, et resultat af en fuldt autoriseret pen test, som vi ikke havde tilladelse til at gøre under vores oprindelige forskning.

de angiver, at mobil-og API-problemerne nu er løst.