Github heeft moeite om bij te blijven een malwarecampagne die een nieuwe draai geeft aan typosquatting. Het spel is eenvoudig: kloon populaire opslagplaatsen, voeg malware toe en adverteer de forks als het origineel. Sommige ontwikkelaars verwarren de forks met echte projecten en voeren onbedoeld de malware uit. De voor de hand liggende naamgevingskeuze is forksquatting, maar de onderzoekers van apiiro kozen voor de veiligere naam “Repo Confusion”.

De campagne is geautomatiseerd en GitHub is zich hiervan bewust, waarbij de overgrote meerderheid van deze kwaadaardige opslagplaatsen onmiddellijk wordt verwijderd. Om welke reden dan ook, vangt het GitHub-algoritme niet alle nieuwe repo's op. Het lijkt erop dat de huidige campagne miljoenen forks publiceert, waarbij gebruik wordt gemaakt van code van meer dan 100,000 legitieme projecten. Het begint erop te lijken dat de kraakfamilie van aanvallen een blijvende toekomst heeft.

RustDesk en Odd-certificaten

De RustDesk-software voor externe toegang is interessant, omdat deze open source is, zelfhosting mogelijk maakt en is geschreven in Rust. Ik heb RustDesk al een hele tijd als to-do-item verkend, maar er is net een beetje zorgwekkend drama afgelopen. Een gebruiker wees daar in november op er is een testrootcertificaat geïnstalleerd als onderdeel van de RustDesk-installatie. Dat rootcertificaat is zelfondertekend met SHA1. Er bestaat ook bezorgdheid dat de binaire bestanden van RustDesk zijn ondertekend met een ander certificaat.

Sindsdien zijn er nieuwe evenementen geweest. Ten eerste was er een Hacker News-thread over de kwestie eerder deze maand. De volgende dag, CVE-2024-25140 was geregistreerd bij NIST en behaalde een krankzinnige CVE 9.8 CVSS. Laten we wat FUD doornemen en praten over wat er werkelijk aan de hand is.

Ten eerste moeten rootcertificaten worden ondertekend met een veiligere hashfunctie dan SHA1. Maar niet om de reden die jij denkt, en in dit geval doet het er niet toe. Basiscertificaten zijn per definitie zelfondertekend, en de enige reden dat ze überhaupt ondertekend zijn, is omdat deze certificaten ondertekend moeten zijn om geldig te zijn. Onderliggende certificaten worden niet beschermd door de handtekening van de root. De belangrijke functie die afhankelijk is van die roothandtekening is de mogelijkheid om een ​​intrekkingsverzoek te doen. Dat zou heel slecht zijn voor een van de algemeen vertrouwde rootcertificaten, en helemaal geen probleem voor een niet-vertrouwd certificaat als dit.

Vervolgens beschikt RustDesk over een geldig, ondertekend certificaat voor de uitvoerbare bestanden. Het zelfondertekende rootcertificaat is uitsluitend bedoeld voor het ondertekenen van een kernelstuurprogramma, waarvoor een Extended Validation (EV)-certificaat vereist is. Het is een beetje verontrustend dat deze vereiste zo gemakkelijk kan worden omzeild door een rootcertificaat te installeren tijdens de installatie van de applicatie, maar dat is van Microsoft, niet van RustDesk.

De laatste zorg hier is dat dit certificaat wordt geïnstalleerd als een systeembrede certificeringsinstantie (CA). Dat is het meest zorgwekkende element van deze sage, maar certificaten hebben een veld dat hun sleutelgebruik (KU) en uitgebreid sleutelgebruik (EKU) specificeert. De RustDesk CA is uitsluitend bedoeld voor het ondertekenen van codes. Dit staat RustDesk of iemand anders die in het bezit is van deze sleutel niet toe om TLS te breken of websites te vervalsen. Het maakt het ondertekenen van code mogelijk, wat een terechte zorg zou kunnen zijn, maar het is niet de haarscherpe situatie die het op het eerste gezicht lijkt.

RustDesk heeft deze sleutel uit hun installatie gehaald, waardoor het stuurprogramma voor het virtuele beeldscherm wordt uitgeschakeld. Dat was de functionaliteit waarvoor een ondertekende kerneldriver nodig was. Het laatste nieuws is dat de ontwikkelaars van RustDesk enige hulp krijgen en een EV-code-signing-certificaat nastreven, en verwachten dat proces binnen ongeveer een maand te hebben afgerond. En die CVE, die een ernstscore van 9.8 scoort? Lijkt volkomen nep.

Ultieme lid SQL-injectie

De Ultimate Member WordPress-plug-in is bijgewerkt naar release 2.8.3, het oplossen van een SQL-injectiefout die toegankelijk was als niet-geverifieerde gebruiker. Gebaseerd op de update-diff, wordt het belangrijkste probleem waarschijnlijk gemist prepare() op regel 704. Oh, en het wordt blijkbaar onderzocht en mogelijk in het wild uitgebuit, dus ga patchen.

Dit is waarschijnlijk een goed moment om te praten over waarom er zoveel SQL-injectie-aanvallen zijn in WordPress. Ten eerste is er sprake van SQL-injectie wanneer door de gebruiker aangeleverde gegevens worden geïnterpreteerd als onderdeel van de uit te voeren SQL-opdracht. Dat doe je door een onverwacht personage op te nemen. Een puntkomma geeft bijvoorbeeld het einde van een verklaring aan en kan worden gebruikt om de volgende te beginnen. Dus waar een naïef programma een getal verwacht, een invoer van 15; DROP TABLE Students zal aan één SQL-instructie voldoen en een tweede instructie injecteren die in de database moet worden uitgevoerd.

In grote lijnen zijn er twee benaderingen om SQL-injectie te voorkomen: invoeropschoning en voorbereide instructies. En beide is ook goed! Saneer eerst de gebruikersinvoer. Zorg ervoor dat het gehele getal daadwerkelijk een geheel getal is en alleen een geheel getal. Verwijder aanhalingstekens, puntkomma's en andere potentieel gevaarlijke tekens.

De tweede benadering is het gebruik van voorbereide verklaringen. Dit scheidt de SQL-opdracht op een fundamentele manier van de gegevens. Het is zoiets als $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); om de SQL-opdrachten te verzenden. Dan wordt het gevolgd door $database->bind_param("si", $name, $age); om de te gebruiken waarden in te stellen. En tenslotte een $database->execute(); voert de query daadwerkelijk uit. Er is geen injectie mogelijk vanwege de strikte scheiding tussen de code en de waarden.

Nu komen we bij WordPress, dat zijn eigen heeft wpdb klasse voor databaseoproepen. Dat omvat een handige functie, wpdb::prepare() dat lijkt bijna op een voorbereide verklaring, zoals hierboven weergegeven.

$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );

Alleen is dat helemaal niet zo. De prepare() functie doet strikt een ontsmettingspas, en een sprintf() vervanging van waarde. De prepare() functie produceert feitelijk geen voorbereide database-instructie. WordPress biedt geen manier om voorbereide verklaringen daadwerkelijk te gebruiken. Een van de basisparadigma's om ontwikkelaars uit de problemen te houden met SQL-injecties ontbreekt.

De M&M's kijken mee

Ik heb iets van een hobby. Ik vind het leuk om machines die zich misdragen te spotten, en te proberen erachter te komen welk besturingssysteem er onder de glimmende GUI draait. Het vreemdste ingebedde apparaat dat ik heb gevonden, is een paginascanner waarop een volwaardige kopie van Windows draaide. De prijsscanners in uw plaatselijke grootwinkelwinkel draaien mogelijk gewoon op Windows CE. De infotainmentcentra achterin de vliegtuigstoelen draaien op een hele oude Linux-versie. En blijkbaar draaien de M&M-automaten op de Universiteit van Waterloo Windows met de toepassing Invenda.Vending.FacialRecognition.App.exe.

Dat weten we omdat [SquidKid47] een onbekende software-uitzondering op het scherm van de automaat heeft opgemerkt en deze op reddit heeft gedeeld. A De schoolkrant pikte het verhaal op (pdf) en stelde vast dat de automaat een camera en gezichtsdetectie gebruikt als een combinatie van slimme bewegingssensor en demografische detector voor gerichte reclame. Ja, deze automaten vertonen gerichte advertenties. Dat deden ze tenminste. Deze automaten hebben ontmoetten hun Waterloo aan de Universiteit van Waterloo, waarbij de school nu formeel om hun verwijdering vraagt.

Bits en bytes

Bel de deurbel naar Pwn: dat blijkt zo te zijn sommige slimme deurbellen zijn niet zo slim. Het is niet verrassend dat er een proces is om een ​​slimme deurbel te resetten en aan een ander account te koppelen. Het is nogal verrassend dat dit proces net zo eenvoudig is als het 8 seconden ingedrukt houden van de grote deurbelknop zelf. De legitieme eigenaar ontvangt op zijn minst een e-mail over de wijziging.

Printeronveiligheid is niets nieuws, maar 3D-printerbeveiliging is nog steeds een beetje een niche-idee. Dat kan veranderen, nu dat het equivalent van een “greetings.txt”-bestand is verwijderd op een aantal Anycubic-printers. Blijkbaar gebruikt Anycubic een MQTT-server die echt niet over voldoende toegangscontroles beschikt.

Het is weer zover, wanneer er is een oplossing voor een kwetsbaarheid vrijgegeven voor GitLab, en het is tijd om te gaan updaten. Het opvallende deze keer is een Cross Site Scripting (XSS)-fout bij het bezoeken van de profielpagina van een gebruiker. Ik laat het als een oefening voor de lezer om voorbeeldcode te produceren die “samy is mijn held” naar de profielpagina van elke bezoeker kopieert.

En tot slot, op het gebied van de ironie: Avast heeft een boete gekregen voor het gebruik van een browserprivacyplug-in als platform voor het verzamelen en verkopen van gebruikersgegevens. Dit gebeurde van 2014 tot en met 2020, waarbij gebruik werd gemaakt van het Jumpshot-platform voor de daadwerkelijke verkoop van data. De gegevens waren nominaal geanonimiseerd, maar de hoeveelheid en details van de beschikbare informatie zijn enigszins verbluffend. Het is de moeite waard erop te wijzen dat Jumpshot niet meer bestaat en dat Avast nu eigendom is van een ander bedrijf. Hopelijk zonder gebruikersinformatie te verzamelen.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://hackaday.com/2024/03/01/this-week-in-security-forksquatting-rustdesk-and-mms/