Github kämpar för att hänga med en skadlig kodkampanj som är en ny twist på stavfel. Pjäsen är enkel: Klona populära arkiv, lägg till skadlig programvara och annonsera om gafflarna som originalet. Vissa utvecklare misstar gafflarna för de riktiga projekten och kör oavsiktligt skadlig programvara. Det självklara namnvalet är forksquatting, men det forskare vid apiiro gick med det säkrare namnet "Repo Confusion".

Kampanjen är automatiserad, och GitHub är medveten om det, med den stora majoriteten av dessa skadliga arkiv som tas bort direkt. Av vilken anledning som helst, fångar GitHub-algoritmen inte alla nya repor. Den nuvarande kampanjen verkar publicera miljontals gafflar, med hjälp av kod från över 100,000 XNUMX legitima projekt. Det börjar verka som att den hukande familjen av attacker är här för att stanna.

RustDesk och udda certifikat

RustDesks fjärråtkomstprogramvara är intressant, eftersom den är öppen källkod, tillåter självvärd och skriven i Rust. Jag har länge utforskat RustDesk som ett att göra-objekt, men lite oroande dramatik har precis spelat klart. En användare påpekade det redan i november ett testrotcertifikat installerades som en del av RustDesk-installationen. Det rotcertifikatet är självsignerat med SHA1. Det finns också oro för att RustDesk-binärerna är signerade med ett annat certifikat.

Det har kommit nya händelser sedan dess. Först fanns det en Hacker News-tråd om frågan tidigare denna månad. Nästa dag, CVE-2024-25140 registrerades hos NIST, rankade en galen CVE 9.8 CVSS. Låt oss skära igenom lite FUD och prata om vad som verkligen händer.

För det första borde rotcertifikat signeras med en säkrare hashfunktion än SHA1. Men inte av den anledningen du tror, ​​och i det här fallet spelar det ingen roll. Rotcertifikat är självsignerade per definition, och det enda skälet till att de är signerade överhuvudtaget är att dessa certifikat måste signeras för att vara giltiga. Underordnade certifikat skyddas inte av rotens signatur. Den viktiga funktionen som beror på den rotsignaturen är möjligheten att utfärda en begäran om återkallelse. Det skulle vara riktigt dåligt för ett av de allmänt betrodda rotcertifikaten, och inte ett problem alls för ett opålitligt certifikat som det här.

Därefter har RustDesk ett giltigt, signerat certifikat för de körbara filerna. Det självsignerade rotcertifikatet är enbart för att signera en kärndrivrutin, vilket kräver ett Extended Validation (EV)-certifikat. Det är lite oroande att detta krav så lätt kan kringgås genom att installera ett rotcertifikat under applikationsinstallationen, men det är på Microsoft, inte RustDesk.

Det sista problemet här är att detta certifikat installeras som en systemomfattande certifikatutfärdare (CA). Det är det mest oroande inslaget i den här sagan, men certifikat har ett fält som anger deras nyckelanvändning (KU) och utökad nyckelanvändning (EKU). RustDesk CA är enbart för kodsignering. Detta tillåter inte RustDesk eller någon som har denna nyckel att bryta TLS eller förfalska webbplatser. Det tillåter kodsignering, vilket kan vara ett giltigt problem, men är inte den hår-på-brand-situation den först uppträder.

RustDesk har hämtat den här nyckeln från sin installation, vilket råkar inaktivera den virtuella skärmdrivrutinen. Det var den funktionalitet som krävde en signerad kärndrivrutin. De senaste nyheterna är att RustDesk-utvecklarna får lite hjälp och söker ett EV-kodsigneringscertifikat och förväntar sig att ha den processen avslutad om ungefär en månad. Och den där CVE som fick 9.8 i svårighetsgrad? Verkar helt falskt.

Ultimate Member SQL Injection

Ultimate Member WordPress-plugin har uppdaterats till release 2.8.3, åtgärda ett SQL-injektionsfel som var tillgänglig som en oautentiserad användare. Baserat på uppdateringsdiff, nyckelfrågan är förmodligen en missad prepare() på linje 704. Åh, och det är tydligen undersökt och potentiellt utnyttjat i det vilda, så gå patch.

Det här är förmodligen ett bra tillfälle att prata om varför det finns så många SQL-injektionsattacker i WordPress. För det första är SQL-injektion när data från användaren tolkas som en del av SQL-kommandot att köra. Det görs genom att inkludera en oväntad karaktär. Ett semikolon indikerar till exempel slutet på en sats och kan användas för att starta nästa. Så där ett naivt program förväntar sig ett nummer, en inmatning av 15; DROP TABLE Students kommer att uppfylla en SQL-sats och injicera en andra sats som ska köras i databasen.

I stort sett finns det två tillvägagångssätt för att förhindra SQL-injektion: indatasanering och förberedda uttalanden. Och båda är bra också! Rensa först användarinmatning. Se till att heltal faktiskt är ett heltal och bara ett heltal. Ta bort citattecken, semikolon och andra potentiellt farliga tecken.

Den andra metoden är att använda förberedda uttalanden. Detta skiljer SQL-kommandot från data på ett grundläggande sätt. Det är något liknande $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); för att skicka SQL-kommandon. Sedan följs det av $database->bind_param("si", $name, $age); för att ställa in de värden som ska användas. Och slutligen a $database->execute(); kör faktiskt frågan. Det är ingen injektion möjlig på grund av den strikta åtskillnaden mellan koden och värdena.

Nu kommer vi till WordPress, som har sitt eget wpdb klass för databasanrop. Det inkluderar en användbar funktion, wpdb::prepare() som ser nästan ut som ett förberett uttalande som visas ovan.

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

Förutom att det inte alls är det. De prepare() fungerar strikt gör en sanering passerar, och en sprintf() värdesubstitution. De prepare() funktion producerar faktiskt inte en förberedd databassats. WordPress erbjuder inte ett sätt att faktiskt använda förberedda uttalanden. Ett av de grundläggande paradigmen för att hålla utvecklare borta från problem med SQL-injektioner saknas.

M&Ms tittar på

Jag har något av en hobby. Jag tycker att det är roligt att upptäcka maskiner som inte beter sig, och försöka ta reda på vilket operativsystem som körs under det glänsande GUI. Den konstigaste inbäddade enheten jag har hittat är en sidskanner som körde en fullfet kopia av Windows. Prisskannrarna i din lokala storlådbutik kanske bara kör Windows CE. Infotainmentcenterna för flygplansryggstöd kör en riktigt gammal Linux. Och tydligen kör M&M-automaterna vid University of Waterloo Windows med programmet Invenda.Vending.FacialRecognition.App.exe.

Vi vet det eftersom [SquidKid47] fångade ett okänt programvaruundantag på varuautomatens skärm och delade det på reddit. A skoltidningen tog upp historien (pdf) och fastställde att varuautomaten använder en kamera och ansiktsdetektering som en kombination av smart rörelsesensor och demografisk detektor för riktad reklam. Ja, dessa varuautomater visar riktade annonser. Det gjorde de åtminstone. Dessa varuautomater har träffade deras Waterloo vid University of Waterloo, där skolan nu formellt begär att de ska tas bort.

Bitar och bytes

Ring dörrklocka till Pwn: Det visar sig att vissa smarta dörrklockor är inte så smarta. Det är inte förvånande att det finns en process för att återställa en smart dörrklocka, för att associera den med ett annat konto. Det är ganska förvånande att denna process är lika enkel som att hålla den stora dörrklockans knapp nedtryckt i 8 sekunder. Åtminstone kommer den legitima ägaren att få ett e-postmeddelande om ändringen.

Osäkerhet på skrivare är inget nytt, men 3D-skrivarsäkerhet är fortfarande lite av en nischidé. Det kanske håller på att förändras nu motsvarande en "greetings.txt"-fil har tagits bort på ett gäng Anycubic-skrivare. Uppenbarligen använder Anycubic en MQTT-server som verkligen inte har tillräckliga åtkomstkontroller.

Det är den tiden igen, när en sårbarhetskorrigering har släppts för GitLab, och det är dags att uppdatera. Det som sticker ut den här gången är ett Cross Site Scripting-fel (XSS) när du besöker en användares profilsida. Jag lämnar det som en övning för läsaren, att producera exempelkod som kopierar "samy is my hero" till profilsidan för varje besökare.

Och slutligen, i ironiavdelningen, Avast har fått böter för att använda ett plugin för webbläsares sekretess som en plattform för att samla in och sälja användardata. Detta hände från 2014 till 2020, med hjälp av Jumpshot-plattformen för den faktiska försäljningen av data. Uppgifterna var nominellt anonymiserade, men mängden och detaljinformationen tillgänglig är lite häpnadsväckande. Det är värt att påpeka att Jumpshot inte finns längre, och Avast ägs nu av ett annat företag. Förhoppningsvis utan att skörda användarinformation.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://hackaday.com/2024/03/01/this-week-in-security-forksquatting-rustdesk-and-mms/