Denna vecka i säkerhet: kilar, LassPass och trasiga tandborstar?

By | February 10, 2024

Linux har ett wedge-problem. Vilket naturligtvis leder till en rimlig fråga: Vad är en kil och varför behöver vi en? Svaret: få Linux att fungera med säker uppstart och en oönskad egenhet hos GPLv3.

Secure Boot är verifieringsschemat på moderna maskiner som säkerställer att endast ett pålitligt operativsystem kan starta. När säker uppstart först introducerades, föreslog många Linux-fans att det var lite mer än ett försök att hålla Linux-distributioner borta från konsumentmaskiner. Den rädslan verkar ha varit obefogad, eftersom Microsoft flitigt höll Linux Shim signerat, så att vi alla kan köra Linux-distributioner på våra säkra startmaskiner.

Passa sedan in den. Det är i huvudsak en starthanterare i första steget, som kan starta upp ett signerat GRUB2 eller annat mål. Du kanske undrar, varför kan vi inte bara be Microsoft att signera GRUB2 direkt? Och det är där GPLv3 kommer in i bilden. Den licensen har en “anti-tivoisering”-sektion, som specificerar “Installationsinformation” som en del av vad som måste tillhandahållas som en del av GPLv3-efterlevnad. Och Microsofts juridiska team förstår att det kravet bör gälla även för denna signeringsprocess. Och det skulle totalt motverka syftet med säker uppstart att släppa nycklarna så att ingen GPLv3-kod signeras. Istället får vi kilen.

Nu när vi förstår kilen, låt oss se hur den går sönder. Den allvarligaste sårbarheten är ett buffertspill i HTTP-filöverföringskoden. Bufferten tilldelas baserat på storleken på HTTP-huvudet, men en skadlig HTTP-server kan ställa in det värdet felaktigt, och fixkoden skulle gärna skriva det faktiska HTTP-innehållet förbi slutet av bufferten, vilket leder till exekvering av godtycklig kod. . Du kanske undrar, varför har mellanlägget HTTP-kod? Det enkla svaret är att stödja UEFI HTTP-start, en ersättning för PXE-start.

Den goda nyheten är att denna sårbarhet endast kan utlösas när du använder HTTP-bootstrapping och endast genom att ansluta till en skadlig server eller genom en man-in-the-middle-attack. Med detta i åtanke är det konstigt att denna sårbarhet har betyget 9,8. Specifikt verkar det felaktigt att denna bugg klassificeras som låg komplexitet eller en allmän nätverksattackvektor. I Red Hats egen artikel om sårbarheten hävdar de att exploatering är mycket komplext och endast är möjligt från ett angränsande nätverk. En handfull mindre sårbarheter hittades och alla fixades med shim 15.8.

LassPass förbjuden från App Store

Allt vi saknar här är ett annat LastPast-appnamn, och vi skulle ha App Store-motsvarigheten till tre olika Spidermen som står i en cirkel och pekar på varandra. Utvecklarna bakom LastPass-appen hittade en LassPass-app med misstänkt liknande utseende i Apple App Store. Vi har sett stavfel i flera programvaruförråd med öppen källkod, men det är också ett problem i appbutiker.

Tre miljoner tandborstar

En historia överraskade säkerhetsvärlden denna vecka: tre miljoner smarta tandborstar hade äventyrats och användes för att starta en DDoS-attack (distributed denial of service) på en schweizisk webbplats. Berättelsen har sitt ursprung på en schweizisk nyhetswebbplats och refererade till en intervju med Fortinets Stefan Züger.

Innan vi avslöjar resten av historien, låt oss tänka på detta. Berättelsen skulle vara viktig, men detta verkar vara den enda originalkällan på Internet. Märket på tandborsten nämns inte, inte heller företaget som drabbades av DDoS-attacken. Ingen specifik botnät eller skadlig programvara inkluderades heller. Smarta tandborstar finns, men de kommer inte att exponeras i massor för Internet. Faktum är att det skulle vara ovanligt för en av dessa att ha anslutning utöver enkel Bluetooth. Hur kunde skadlig programvara nå en av dessa enheter för att äventyra den?

Vi kan bygga ett scenario där detta kan hända. En smart tandborste bör ha en Wi-Fi-anslutning som en del av installationsprocessen. Det här låter konstigt, men jag har sett fånigare IoT-beteenden. Så det enda sättet att förklara att så många enheter äventyras samtidigt är en skadlig firmwareuppdatering. Oavsett om det är genom en supply chain attack eller något dumt som ett domännamn som löper ut och hävdas av en hotaktör. Detta ganska komplicerade scenario skulle kunna förklara ett tandborstrobotnätverk på tre miljoner människor.

Men om du inte har märkt det ännu så hände inte detta. Det är ett hypotetiskt scenario baserat ungefär på tidigare Fortinet-forskning om vad som kan göras med skadlig programvara för tandborstar (PDF). Bleeping Computer har fått ett officiellt svar från Fortinet:

För att förtydliga så presenterades ämnet att använda tandborstar för DDoS-attacker under en intervju som en illustration av en viss typ av attack och är inte baserat på forskning från Fortinet eller FortiGuard Labs.Det verkar som att på grund av översättningar har berättelsen om Detta ämne har sprids till den punkt där hypotetiska och verkliga scenarier blir förvirrade.

Det är inte slutet på historien. Aargauer Zeitung sajten var ganska tydlig när han sa att Fortinets Stefan sa att denna attack var verklig i den ursprungliga artikeln. Som svar på Fortinets tillkännagivande, ändrade de den artikeln, men postade också ett svar, där det stod att det inte fanns någon översättningsfråga; alla pratar ju tyska. De rapporterar att Fortinet klassade tandborstattacken som verklig, gav detaljer om hur länge den varade och hur kostsam den var för offret. Den mest överraskande detaljen här är att Fortinet gjorde en förpubliceringsgranskning av artikeln och godkände den.

Så vad är takeaway här? Dels tar nyhetssajter ibland fel. Om en berättelse verkar konstig, titta till primära källor. Om det inte finns några primära källor så kanske något inte är som rapporterat. Det är inte helt klart var kommunikationsfelet inträffade i det här fallet, men vad som verkar mer troligt är att en Fortinet-anställd läste en intern fallstudie om en hypotetisk attack och trodde att den beskrev en verklig händelse. Av all täckning av detta tror jag att jag gillar berättelsen på Malwarebytes-bloggen mest.

Bitar och bytes

Det finns ett intressant knep som säkerhetsforskare har spelat på sig själva. Det finns för många honungskrukor där ute. Eller kanske är problemet att honungskrukor är för bra för att fungera som riktig hårdvara. Hur som helst blir processen att spåra antalet sårbara enheter tillgängliga på Internet ganska utmanande. Exemplet som ges är närvaron av över 200 000 Confluence-resultat på Shodan, men bara 5 000 faktiska favicon-resultat. Det tyder på att det finns 40 Confluence honeypots för varje riktig server. Sinnet är chockat.

Tydligen har vissa Alpha Innotec och Novelan värmepumpar en odokumenterad funktion: SSH-åtkomst med ett känt root-lösenord. Det är ett sätt att förhindra Home Assistant-användare från att spamma dina API-servrar. Även om det förmodligen inte var avsiktligt. Det händer bara att ett enkelt 3DES-krypterat lösenord kan knäckas på några sekunder på en modern maskin. Är eschi om du frågade dig själv.

Och slutligen fanns det en sårbarhet i Mastodon som publicerades förra veckan. Detta är en bugg i hanteringen av federerade konton, så en angripare kan imitera ett konto på en annan server. Uppdateringen är tillgänglig nu, men fullständig information kommer inte att vara offentlig förrän den 15:e för att ge serveroperatörerna tid att uppdatera. Hackaday.social är nu uppdaterad, om du undrar.

Leave a Reply

Your email address will not be published. Required fields are marked *