TL;DR

• Smart Bluetooth mannlig kyskhetslås, designet for at brukeren skal gi fjernkontroll til en pålitelig 3. part ved hjelp av mobilapp/API
• Flere API-feil betydde at alle kunne fjernlåse alle enheter og forhindre brukere i å frigjøre seg

Fjerning krever deretter en vinkelsliper eller lignende, brukt i nærheten av delikate og sensitive områder

• Presise brukerplasseringsdata også lekket av API, inkludert personlig informasjon og private chatter
• Leverandør i utgangspunktet responsiv, så savnet tre utbedringsfrister de SETTE seg over en 6 måned til slutt nektet å samhandle videre, selv om flertallet av problemene ble løst i migrering til V2 API, MEN API v1 inexcusably venstre tilgjengelig
• dette innlegget er publisert i samordning med Internet Of Dongs
• 27/01/2021 de sier at mobil og API problemer har nå blitt løst.

Smarte voksne leker og oss

Vi har ikke skrevet om smarte voksne leker på lenge, Men Qiui Cellmate chastity cage var rett og slett for interessant å passere forbi. Vi ble tipset om den voksne kyskhetsenheten, designet for å låse opp brukerens vedlegg.

det finnes andre mannlige kyskhetsenheter tilgjengelig, men Dette er En Bluetooth-aktivert lås-og klemmemekanisme med en mobilapp. Tanken er at brukeren kan gi kontroll over låsen til noen andre.

Vi er ikke i bransjen for kink shaming. Folk bør kunne bruke disse enhetene trygt og sikkert uten risiko for at sensitive personopplysninger blir lekket.

sikkerheten til teledildonics-feltet er interessant i seg selv. Det er verdt å merke seg at salget av smarte voksne leker har steget betydelig under den siste lockdown.

hva er risikoen for brukerne?

vi oppdaget at eksterne angripere kunne forhindre At Bluetooth-låsen ble åpnet, permanent låsing av brukeren i enheten. Det er ingen fysisk opplåsing. Røret er låst på en ring slitt rundt bunnen av kjønnsorganene, noe som gjør ting utilgjengelige. En vinkelsliper eller annet egnet tungt verktøy vil være nødvendig for å kutte brukeren fri.

Plassering, klartekst passord og andre personlige data ble også lekket, uten behov for godkjenning, AV API.

Vi hadde spesielle problemer under avsløringsprosessen, da vi vanligvis ville be leverandøren om å ta ned en lekkende API mens utbedring ble implementert. Men alle som for tiden bruker enheten når API ble tatt offline, vil også være permanent låst inn!

som du vil se i opplysningstidslinjen nederst i dette innlegget, ble noen problemer løst, men andre var ikke, og leverandøren sluttet ganske enkelt å svare på oss, journalister og forhandlere. Gitt den trivielle karakteren av å finne noen av disse problemene, og at selskapet jobber med en annen enhet som utgjør enda større potensiell fysisk skade (en «intern» kyskhetsenhet), har vi følt oss tvunget til å publisere disse funnene på dette punktet.

problemene

Vi har redigert viktige detaljer her.

Mobile app

vi fant en alvorlig sårbarhet personvern svært raskt med mobile app: ALLE API endepunkter ble ikke godkjent ved hjelp av bare en lang-ish «memberCode» for å gjøre forespørsler. MemberCode selv er noe deterministisk og er basert på datoen en bruker registrerte seg for tjenesten, men vi fant en enda enklere måte å bruke en kortere «venn kode».En forespørsel med denne sekssifrede «venn» – koden returnerte en stor mengde informasjon om den brukeren, inkludert svært sensitiv informasjon som navn, telefonnummer, bursdag, de nøyaktige koordinatene der appen ble åpnet, deres lengre «memberCode»-verdi og brukerens klartekstpassord (ikke at vi trenger det).det ville ikke ta en angriper mer enn et par dager å exfiltrere hele brukerdatabasen og bruke den til utpressing eller phishing.

Tall og lekkede posisjonsdata

Vi var i stand til å prøve Noen Id-Er tilfeldig, som viser bruker steder på tidspunktet for app registreringer. Husk at dette bare er en liten delmengde av brukere fra tilgjengelige data. Vi kastet bort personlig informasjon umiddelbart.

memberCode data = DoS for brukeren

nå har vi lengre memberCode vi kan hente alle enhetene som er knyttet til 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,

og når vi har det, kan vi finne ut hvilke tillatelser personen har over den låsen (så kan de låse opp det selv eller må spørre noen andre):

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

Og hvis de kan, kan vi vende det slik at de nå er låst ut av enheten:

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

og vi kan gjøre det for alle, veldig Raskt, låse alle inn eller ut. Det er heller ingen nødoverstyringsfunksjon, så hvis du er låst inn, er det ingen vei ut. Dette kan eller ikke kan betraktes som en funksjon!

ble issues

SELVE ble-implementeringen krever EN API-forespørsel for å generere en opplåsingskommando basert på et token som tidligere er skrevet til låsen. Det er mulig vi kunne analysere forespørsler og svar for å generere den riktige nøkkelen, eller omvendt konstruere låsen maskinvare selv…

ovennevnte er hentet Fra dekompilert Android app og ved å koble Den Med Frida vi kan se varsler (36f6) og skriver (36f5) forbundet med å sjekke batterinivået først og deretter låse opp (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, det hex fra Android-appen, og ble-egenskapene ser veldig kjent ut. Det er akkurat den samme implementeringen som Nokelock vi så på, bortsett fra at det annonserte enhetsnavnet ER «OKGSS101».

per lock aes-krypteringsnøkkelen returneres I API-anropet som viser enhetene vi laget tidligere. Mass unlocking over ble noen?

Låst inn? Her er en løsning

hvis du befinner deg låst inn, lurer du sikkert på hvordan du kan komme deg ut uten tunge verktøy eller et besøk til beredskapsrommet…

utformingen av låsepinnen bruker en motor for å trekke den ut og er dessverre ikke jernholdig, så ingen enkel bruk av magneter, og det er heller ikke «bumping» det åpent (som du vil ha på deg det). Jeg hadde litt suksess med en shim laget av en cut-up boks, men ideen om skarpt spisset metall nær noe viktig er ikke ideelt.

det er limt inn, men kom ut uten mye innsats eller skade. 3 volt (TO AA-batterier) på de hvite og gule ledningene er nok til å drive opplåsingsmotoren direkte (hvit = negativ, gul = positiv), en teknikk kjent som «spiking».

din lokale beredskapsavdeling vil trolig ha de riktige verktøyene for å kutte om metallet trygt skjønt, og ville være din bedre første anløpshavn!

Konklusjon

for en realistisk trussel synes risikoen for datalekkasje mer sannsynlig å bli utnyttet og gi belønning til en angriper.En rekke land har undertrykkende lover som kan utsette brukere av denne typen enheter for uberettiget interesse fra rettshåndhevelse og bigots.

videre vil brukerne sannsynligvis ønske å holde privatlivet privat. De bør forvente personvern som standard og sikkerhet ved design. Hvis man ønsker å dele veldig privat informasjon, bør det være av eksplisitt hensikt for brukeren.

Mange voksne leketøysleverandører har vist nesten fullstendig mangel på respekt for personvern og sikkerhet de siste årene. Heldigvis, prosjekter som Internett Av Dongs har hjulpet veilede mange mot bedre sikkerhet. Qiui hadde tydeligvis ikke fått meldingen.

disclosure tidslinje

Disclosure var ikke så sømløs som vi kanskje først hadde håpet:

April 20th 2020: vi sendte meldinger til dem og spurte hvem de skulle rapportere problemet til. De svarte veldig raskt. Kult!

ikke noe problem, så vi prøvde igjen uten PGP:

så vi sendte dem detaljene. Stillhet regjerte.26. Mai 2020: vi presset litt hardere, svarte de og sa at de ville fikse det innen 6. juni.

11/06/2020: en oppdatert versjon ble distribuert til Appen & Play Stores. Dette løste for det meste problemer med forespørsler som nå blir tvunget til å godkjenne. Eldre API-endepunkter ble imidlertid forlatt, og nye Apier returnerte fortsatt eksakte brukersteder.

17. juni 2020: vi sendte en melding med detaljer om de gjenværende problemene, uten svar.juni 25th 2020: Vi reiste ut igjen, via en journalist, Sa Qiui At De ikke ville fikse (eller ikke kunne) da de» bare » hadde $ 50.000.30. juni 2020: vi sendte en oppfølgings-e-post (og twitter DM) med potensielle løsninger på de gjenværende problemene (og hadde det oversatt Til Kinesisk bare i tilfelle), uten svar.

10. juli 2020: vi kontaktet to britiske forhandlere av enheten for å gjøre dem oppmerksomme på problemene. En trakk den fra salg, og tok kontakt med eu-baserte grossister. Qiui reagerte tilbake til forhandlerne at de resterende problemene ville bli løst «i August».11. September 2020: RenderMan fra @ InternetOfDongs tok også kontakt med Oss: han hadde hjulpet en annen forsker gjennom avsløringsprosessen Med Qiui. @MikeTsenatek hadde funnet et problem med tilbakestilling av passord uavhengig og sliter også med å bli hørt av leverandøren. Ved en tilfeldighet la han merke til en tweet av meg for en tid siden, skjønte at vi kanskje ser på denne enheten og nådde ut.

Vi hadde en flott samtale sammen hvor vi utvekslet bemerkelsesverdig lignende erfaringer med samspill med Qiui! Hans oppskrivning er tilgjengelig her.

dette forsterket vår beslutning om å publisere: klart andre var sannsynlig å finne disse problemene uavhengig av oss, så offentlig interesse saken ble gjort i våre sinn.

RenderMan fortjener definitivt kudos for hans fortsatte innsats for å megle samtaler mellom forskere og leverandører i voksen leketøy arena. Noen leverandører har gjort betydelige forbedringer i deres produktsikkerhet og personvern som følge av hans harde arbeid.4. oktober 2020: vi ble kontaktet av en tredje forsker med lignende bekymringer.

6. oktober 2020: vi publiserte i samarbeid med de andre partene.

Oppdatering 27/01/2021

Qiui Europeiske distributør ba Oss om å gi en oppdatering til denne bloggen i lys av utviklingen. De kontaktet oss på 28 desember, forklarer at problemet var med den mobile app. Dette var ikke vår forståelse, gitt sikkerhetsproblemer ovenfor er I API.uansett, vi ba om bevis på dette og ble sendt en penn testrapport fra mobilappen av en 3. part .

rapporten var tydelig av mobilappen og hadde gjort en rekke anbefalinger.

vi gikk tilbake til distributøren og ba om en kopi av en pen testrapport AV API.

dette kom på 19 januar. En rekke andre problemer hadde blitt notert, et resultat av en fullt autorisert penntest, som vi ikke hadde tillatelse til å gjøre under vår opprinnelige forskning.

de sier at mobil-og API-problemene nå er løst.