[Eaton Zveare] kocht een jacuzzi-bubbelbad en gaf geld uit aan de SmartTub-add-on, die de whirlpool met internet verbindt, zodat je de temperatuur, verlichting, enz. Van een afstand kunt regelen. Hij wist niet dat hij op het punt stond te ontdekken een nachtmerrie van beveiligingsproblemen. Want zoals we allemaal weten, staat de S in IoT voor beveiliging. In dit geval kwam de registratie-e-mail van smarttub.io, dus het was normaal om die URL in een webbrowser op te halen om te zien wat er was. De pagina gaf een login-prompt weer, dus [Eaton] toetste de inloggegevens in die hij zojuist had gegenereerd. “Ongeautoriseerd” Dat is niet verwonderlijk, maar wat heel vreemd was, was de flits van een dashboard dat verscheen vlak voor de autorisatieklacht. Zouden dat echte gegevens kunnen zijn die onbedoeld zijn verzonden? Een schermrecorder beantwoordde die vraag en onthulde dat er inderdaad een tabel was geladen met geldig ogende gegevens.

Als je in het JavaScript van de pagina graaft, krijg je de inlogstroom. De pagina gebruikt de Auth0-service om aanmeldingen af ​​te handelen en die service stuurt een toegangstoken terug. De pagina stuurt dat toegangstoken rechtstreeks terug naar de Auth0-service om gebruikersrechten te krijgen. Als de ingelogde gebruiker geen beheerder is, vindt de omleiding plaats. We weten echter al dat sommige echte gegevens worden geladen. Het lijkt erop dat de beperkingen voor gegevens allemaal aan de clientzijde zijn geïmplementeerd en dat de backend alleen een geldig toegangstoken voor gegevensverzoeken vereist. Wat zou er gebeuren als het antwoord van Auth0 zou worden gewijzigd? Er zijn een paar benaderingen om dit te bereiken, maar hij koos ervoor om te gebruiken: vioolspeler. Herschrijf het antwoord zodat de front-end denkt dat je een beheerder bent en dat je meedoet.

Deze aanpak lijkt beheerderstoegang te krijgen tot alle SmartTub-beheerfuncties, hoewel [Eaton] niet heeft geprobeerd daadwerkelijk wijzigingen aan te brengen om te zien of hij ook schrijftoegang had. Dit was genoeg om de fout aan te tonen, en het aanbrengen van veranderingen zou flirten zijn met die gevaarlijke lijn die onderzoek scheidt van computercriminaliteit. Het echte probleem begon toen hij probeerde de kwetsbaarheid te onthullen. SmartTub had geen beveiligingscontact, maar een e-mail naar hun ondersteunings-e-mailadres lokte wel een antwoord uit waarin om details werd gevraagd. En nadat details waren verstrekt, volledige radiostilte. Geërgerd wendde hij zich uiteindelijk tot Auth0 en vroeg hen om in te grijpen. Hun oplossing was om de stekker uit een van de twee URL-eindpunten te trekken. Eindelijk, na zes maanden proberen om Jacuzzi en SmartTub op de hoogte te stellen van hun ernstige beveiligingsproblemen, waren beide beheerdersportalen beveiligd.

Weg joggen van de beveiliging

Er zijn twee lagen van mislukking in dit verhaal over de Strava-oefenapp. Strava laat zijn gebruikers hun hardlopen, fietsen en wandelen volgen. Vanwege privacyoverwegingen is er een optie om de locatie van de gebruiker te verbergen, maar het blijkt dat een slim gebruik van de heatmap- en segmentfuncties die bescherming kan verslaan. Uploadruns van een nep-gebruiker, en de app vergelijkt je run handig met andere gebruikers in het gebied, verborgen of niet. Die lijst met gebruikers zou een toegewijde onderzoeker in staat stellen in kaart te brengen waar individuen hun tijd hebben doorgebracht. De nadruk van dit onderzoek lag op het volgen van militaire leden, wat een aantal voorspelbaar interessante resultaten aan het licht bracht.

En dat is de tweede beveiligingsfout. Het Israëlische leger staat hun soldaten, zelfs leden van de speciale strijdkrachten, toe een app te gebruiken die naar huis belt met gps-locaties. Zelfs als er geen gemakkelijk te exploiteren beveiligingszwakte in de app was, is het nog steeds een verschrikkelijk beveiligingsprobleem. Het onderzoek werd bekendgemaakt aan Strava, die de nep-gebruiker verwijderde die in het onderzoek werd gebruikt. Het is onduidelijk of de app-makers het probleem daadwerkelijk hebben aangepakt. Het Israëlische leger stelt dat ze procedures aan het uitrollen zijn om dit soort datalekken in de toekomst te voorkomen.

OpenSSL AVX512-bug

Er zit een bug in OpenSSL 3.0.4 en het kan een bijzonder vervelende zijn, maar het komt alleen voor op CPU's met de AVX512-extensies. Het probleem wordt geactiveerd in ossl_rsaz_mod_exp_avx512_x2(), die een oproep doet naar bn_reduce_once_in_place(). De oproep omvat de waarde factor_size, wat het aantal te verwerken woorden zou moeten zijn, maar de oude code stuurde in plaats daarvan de bitgrootte. Dit werkte meestal, maar in bepaalde gevallen resulteerde dit in een heapbufferoverloop. Het griezelige hiervan is dat het kan worden geactiveerd door een TLS-handshake en andere mogelijk door een aanvaller bestuurde input. Het enige wat ontbreekt om dit een 10.0 CVSS CVE te noemen, is een daadwerkelijke demonstratie van uitbuiting. Zoals het is, is het gemakkelijk om een ​​crash aan te tonen. Een 3.0.5 release zal binnenkort worden gemaakt, met de fix, maar het is niet duidelijk wanneer dat zal gebeuren. De meeste distributies lijken de verzending van de 3.0.4-release uit te stellen, in afwachting van de oplossing voor dit potentieel ernstige probleem.

FreeBSD BadBeacon

Ik ben zo vrij geweest om de voor de hand liggende naam voor deze kwetsbaarheid te kiezen, BadBeacon. Ontdekt door [m00nbsd], het is een simpele hoop overflow, maar deze geeft de aanvaller controle over het exacte aantal bytes dat moet worden geschreven en de inhoud van die bytes. Het is een probleem bij de verwerking van WiFi Beacon-frames door FreeBSD. Een frame is in wezen een wifi-pakket en een baken is het pakket dat de details van een wifi-netwerk aankondigt. Er zijn veel mogelijke velden in een baken, en veel daarvan vereisen speciale codepaden om ze te verwerken.

Een zo'n veld is de Mesh ID-waarde. Het bevat een lengte en waarde, en de FreeBSD-kernel neemt die als invoer voor a memcpy() aanroepen in een buffer met een vaste grootte. De manier waarop gegevens zijn ingedeeld in de bevattende structuur, overschrijft deze buffer ook een andere gegevensstructuur, die eindigt in een gegevensaanwijzer en lengtewaarde. Die datapointer wordt dan gebruikt als de doellocatie van een ander memcpy() telefoongesprek. Het is een "schrijf-wat-waar"-primitief, oftewel een gemakkelijke techniek om bijna willekeurige gegevens overal te schrijven.

De richting die ze vervolgens kozen, was om een ​​​​kernel-achterdeur op te zetten in het ongebruikte geheugensegment en die code vervolgens in een deel van de frameverwerkingscode te haken. Het werkt als een eenrichtingskernelachterdeur. Hun Proof-of-Concept-code drukt eenvoudig een bericht af naar het kernellogboek, maar zou vrij gemakkelijk kunnen worden bewapend. FreeBSD heeft de fout in april gepatcht. Het is onduidelijk wanneer en of pfSense een update met de fix heeft uitgebracht, hoewel het waarschijnlijk is gebeurd en gewoon niet heeft geadverteerd met de CVE-fix, CVE-2022-23088.

De Linux Syslogk Rootkit

Er is een bijzonder onopvallende kernel-rootkit, Syslogk, op de loer in het wild. De versie van de rootkit die onderzoekers van Avast onderzochten, leek gericht te zijn op Centos 6 en soortgelijke kernels. Het doet er alles aan om te verdwijnen, zijn bestanden te verbergen en zichzelf zelfs te wissen van de lijst met geladen kernelmodules. Er is een verborgen functie, het schrijven van een 1 naar /proc/syslogk, dat de stealth-functies uitschakelt. Dus als je een oudere server hebt die mogelijk is gehackt, probeer dan die locatie te porren om te zien of er iets gebeurt.

iOS-infectie via de DCP

Als u de beveiliging van de hoofdprocessor niet kunt kraken, misschien kun je door een co-processor achterdeur gaan? Dat is precies wat een nep-Vodaphone-app op de iPhone doet. De Display Co-Processor (DCP) is een nieuw onderdeel van de M1 SoC en deze kwaadaardige app gebruikt het in een van zijn gebundelde exploits. De beschrijving is gedetailleerd en diepgaand, zoals meestal het geval is met Google Project Zero-berichten. In plaats van in de details te graven, laat ik je gewoon achter met de gedachten van [Hector Martin], als waarschijnlijk de belangrijkste expert op het gebied van de M1-chip buiten een handvol Apple-ingenieurs:

Ha, een op DCP gebaseerde exploit die springt van gebruikersruimte naar DCP en terug naar de kernel. Schattig.

Weet je nog wat ik zei over M1-coprocessors die het systeem niet kunnen pwn? Dat veronderstelt dat uw stuurprogramma "sudo pwn the system" niet implementeert zoals dat van Apple doet 😅.https://t.co/3uNVBVrD4F

- Hector Martin (@ marcan42) 24 June 2022