Det har uppdagats en hel del intressanta brister på senare tid så jag tänkte försöka skriva en kortare sammanställning på vad som kan vara bra att hålla koll på:
CVE-2023-23415 – Vilket är en sårbarhet i Windows som gör att en lyssnare på en RAW-socket kan troligtvis utföra RCE via ett ICMP-paket. Exempelvis på mjukvara som nyttjar RAW-sockets i Windows är Wireshark. Mer info här.
CVE-2023-24033 – Sårbarheter i Samsungs Exynos basbandsmodem. Möjliggör att en angripare kan få fotfäste i flertalet Google Pixel-telefoner såsom Pixel 6 och 7 samt flertalet Samsungmodeller. Voice-over-LTE (VoLTE) eller WiFi-samtal kan slås av för att mitigera sårbarheterna temporärt. Project Zero hos Google har skrivit här.
CVE-2023-21036 (acropalypse) – När crop-funktionen används i Android så tas inte den croppade delen bort. Det går att återskapa delar eller delen av bilden som har beskurits bort. Men observera att flertalet tjänster såsom Signal gör en konvertering av filen innan, således försvinner metadata. Intressant root-cause.
CVE-2023-23397 – Elevation-of-privilege i Outlook, utnyttjas aktivt just nu. Attacken upptäckes av CERT-UA, läs mer här. ”This attack vector, which leads to NTLM harvesting,”
Förutom att Offensive Security numera går under namnet OffSec så har företaget även släppt en ny version av Kali Linux som heter Kali Purple.
Som det nya namnet lite avslöjar så handlar det om en Linux-distribution som är anpassad för Purple-Teaming eller Blue-Teaming, dvs mer defensiv cybersäkerhet än offensiv som Kali Linux är mest känt för.
Och givetvis så är Kali Purple proppad med över 100 st olika verktyg, och för att nämna några:
Med följer även Kali Autopilot som låter dig bygga olika attackscenarion samt en community Wiki som låter dig läsa på om olika defensiva verktyg och hur du använder dessa.
LOLBAS som står för Living Off The Land Binaries, Scripts and Libraries är ett projekt som funnits i många år nu. Projektet LOLBAS går ut på att lista ”dual use” binärer, script och bibliotek som gör att en angripare som vill försvåra upptäckt eller inte har verktyg installerade på en hackad enhet kan använda sig av sådant som redan är befintligt installerade (tidigare hette projektet LOLBIN). För Unix-system så finns även projektet GTFOBins.
För några veckor sedan så släpptes projektet LOLAPPS som är snarlikt men istället listar mjukvaror eller ”appar” som också går att använda för illasinnade funktioner såsom att ladda ner- eller exekvera kod.
Initiativtagare bakom LOLAPPS är John Jackson aka ”Mr Hacking”.
Redan nu finns det ett antal mjukvaror listade såsom:
En ny sårbarhet har uppdagats i OpenSSH. Denna sårbarhet återfinnes innan autentisering (pre-auth) och beror på att allokerat minne frigörs dubbelt. Sårbarheten har CVE-2023-25136 och den version som av OpenSSH som åtgärdar sårbarheten släpptes 2:a Februari 2023, version 9.2.
Det är i dagsläget möjligt att genomföra en DoS (krasha opensshd) men oklart om det skulle vara möjligt att göra något mer såsom RCE (Remote Code Execution). Dock så använder opensshd Privilege Separation på många plattformar samt sandboxning (pledge, chroot osv). Proof-of-concept kod är släppt för att utför DoS av opensshd version < 9.2.
Eftersom OpenSSH är så otroligt populärt så kommer troligtvis en hel del resurser läggas på att försöka utnyttja denna sårbarhet.
Att verktyget ChatGPT som verkar inom området artificiell intelligens (AI) blivit poppis råder ingen tvekan om. Men precis som många andra intressanta och nya innovationer så finns det som oftast ett ”dual use”, dvs där innovationen eller verktyget kan användas av såväl sådana som vill gott och sådana som har onda avsikter.
Just inom området cybersäkerhet och ChatGPT så har jag testat några olika områden där ChatGPT kan användas för offensiva och defensiva syften.
ChatGPT för offensiv cybersäkerhet
Precis som Github CoPilot som jag själv använder så kan du säga till ChatGPT att utveckla skadlig kod såsom kod som utför ransomware och krypterar filer.
Om jag berättar för ChatGPT att den ska skriva några olika programstycken som var för sig inte gör illasinnade sakar och sedan berättar att den ska utveckla koden vidare så klagar den inte:
Men om vi rakt ut skriver att ChatGPT ska skapa ransomware i python så vägrar den:
Det är även möjligt att ställa frågor om vilka verktyg som är bra att använda för olika offensiva syften såsom portscanning av internet så får jag förslag på fyra verktyg: nmap, masscan, zmap och fscan. Så den har någorlunda rätt.
Antagonister kan även använda ChatGPT för att skriva phishing-meddelanden i olika språk och föda in information om målet till ChatGPT för att göra phishingen ännu mer effektiv. Det är även möjligt att till viss del skala upp nyttjandet av ChatGPT, eller använda OpenAI:s API som tillhandahåller GPT3.
Ett annat område är att AI:t utger sig för att vara någon annan och således försöka fiska till sig information genom exempelvis chattar. En vidareutveckling på sådant som vi har sett tidigare där kapade Facebook-konton nyttjas till att ”be en vän om hjälp med BankID” eller berätta om en knipa där pengar behövs.
Dock är AI:t inte felfritt, men min upplevelse är att ungefär i hälften av fallen så blir det korrekt eller att du måste korrigera och fixa koden.
Bild från ett chattforum för kriminella där någon lyckats att skapa en mjukvara för att exfiltrera (sno) filer med en viss filändelse:
ChatGPT kan analysera loggfiler och se mönster i text eller andra former av kod såsom assembler och således hjälpa till att förstå analyser av skadlig kod. Det finns redan nu flertalet plugins till reverse-engineering verktygen IDA Pro och Ghidra för att göra just detta.
ChatGPT har även förmågan att skapa YARA-regler på sådant som man kan uppge, ett exempel:
Det finns även möjlighet att fråga saker om olika grupperingar, men dock finns det begränsningar eftersom informationen som ChatGPT är tränad på är från år 2021 och tidigare:
Och precis som botten skriver ovan så är listan inte komplett. Men ger en bra fingervisning iallafall och jag tycker att vi är på god väg när det gäller utvecklingen inom AI och dess möjligheter inom cybersäkerhet.
Uppdatering: Ett annat område jag glömde att skriva om är att ChatGPT kan göra enklare kodgranskningar och identifiera sårbarheter:
CERT-SE gick ut med en varning gällande en kritisk sårbarhet i FortiOS från Fortinet. Sårbarheten medger kodexekvering över nätverk.
Sårbarheten återfinnes i FortiOS sslvpnd-process och är en heap-baserad sårbarhet. Genom att stänga av VPN i FortiOS så kan man förhindra att sårbarheten kan utnyttjas.
Fortigate har även gått ut och meddelat att denna sårbarhet används aktivt på internet. Användare av FortiGates produkter med VPN påslaget bör titta i loggfilerna efter följande meddelande:
Logdesc="Application crashed" and msg="[...] application:sslvpnd,[...], Signal 11 received, Backtrace: [...]“
Även så skrivs följande filer till filsystemet på FortiOS / Fortigate om enheten har blivit hackad:
Sårbarheten har CVE-2022-42475 och har kopplingar till ransomware-grupperingar som nyttjar denna sårbarhet för att installera ransomware. Se även information här på Franska.
Inom cybersäkerhet så har det på senare tid blivit populärt att prata om hur man kan analysera och begränsa attackytan, engelska: Attack surface reduction (ASR). Och jag har som vanligt funderat en hel del på området: Det är av stor vikt att organisationer har en insikt och förmåga att förstå sin attackyta.
Tittar man först och främst från internet där majoriteten av alla cyberattacker sker från så ser attackytan ut enligt följande:
Tjänster, servrar och enheter som är exponerade mot internet
Annan utrustning som kopplas upp såsom switchar, kopiator/scanner, laptops och mobiltelefoner
Indirekt attackyta, dvs sådant som kan bifogas med E-post och hamna hos en anställd. Eller när en anställd surfar ut eller på annat sätt ansluter utåt
Supply Chain. Mjukvaruppdateringar, hårdvara som köps in, firmware osv
Via en annan leverantör eller kund. Tänk exempelvis delad hosting
WiFi, bluetooth och andra uppkopplingar såsom VPN
Via molntjänster eller molnleverantörer
Finns säkert fler sätt än ovan som attacker kan ske men viktiga här är att begränsa och isolera samtliga områden där attacker kan genomföras. Ni som organisation måste förstå i detalj vad det innebär att exponera tjänster såsom Apache, Nginx eller Microsoft IIS.
Är det så att ni exponerar en webbserver, vad har den för TCP/IP-stack, TLS-implementation osv? Och kollar vi längre upp i lagret, vad har ni för API:er exponerade? Har ni köpt en on-premise appliance eller någon annan form av magisk låda, så har denna troligtvis en hel del funktioner så ni inte känner till som exponeras utåt.
För det är inte en fråga om ni kommer att bli hackade, utan en fråga om när. Och då måste ni ha verktyg att upptäcka denna attack. Övervaka därför samtliga kanaler på både insida och utsida och titta efter avvikande mönster. Om webbservern pratar TLS 100% av fallen så ska inte helt plötsligt förekomma klartext (annat än just sådant som kan förekomma i protokollet).
Jag gillar OpenBSD-teamets filosofi där allt ska vara avstängt från start och behöver du någon funktion eller tjänst så måste du aktivt aktivera denna ”secure by default”.
På klienter som används mot internet bör därför så lite funktioner, applikationer och dylikt användas. Tittar man på en standard Windows-installation så stödjer denna runt 600-700 olika filformat där många kan användas för att utnyttja eventuella sårbarheter.
Sammanfattning
Tänk så här: Desto mindre rader kod ni exponerar direkt eller indirekt mot internet eller andra attackvägar in mot Er organisation, desto säkrare blir ni. Bryt ner attackytan även mot individuella tjänster och portar som exponeras.
Isolera servrar, tjänster och annat som går att nå direkt från internet. Övervaka dessa tjänster och titta efter avvikande beteenden. Förändringar i attackytan över tid är också viktig att uppmärksamma.
Om någon lyckas få åtkomst till Er mail från internet, eller VPN eller annat som används remote. Vad får det för konsekvenser? Testa och granska, med exempelvis penetrationstester eller red-teaming.
Den amerikanska säkerhetsmyndigheten NSA har gått ut och varnat för programspråk som ej är minnes-säkra såsom C och rekommenderar en övergång till språk såsom C#, Go, Java, Ruby, Rust och Swift. Men bara för att man väljer ett programspråk som är minnes-säkert så betyder det inte per automatik att säkerhetsbrister inte kan uppstå, vilket också NSA framhäver. Även så kan språk såsom listade ovan anropa bibliotek som ej är minnes-säkra.
Även kan dessa programspråk leda till sämre prestanda på grund av funktioner såsom garbage collection (GC).
NSA rekommenderar att använda flertalet verktyg som utför SAST och DAST, dvs statisk och dynamisk applikationssäkerhetstestning. För att fånga upp bl.a. säkerhetsbrister och minnesproblem. En annan sak som framgår är även betydelsen av att använda anti-exploitfunktioner såsom Control Flow Guard (CFG), Address Space Layout Randomization (ASLR) och Data Execution Prevention (DEP).
Att just NSA går ut med dessa rekommendationer kommer inte direkt som någon nyhet eftersom säkerhetskritiska projekt såsom Tor har valt att bygga en ny implementation (Arti) helt i Rust. Programspråket C var ett givet val 2001 när utvecklingen av Tor påbörjades.
Genom att använda programspråk som C#, Go, Java, Ruby eller Rust så kan nästan hela buggklasser elimineras. Matt Miller på Microsoft berättade vid BlueHat-konferensen 2019 att mellan åren 2006 till 2018 berodde 70% av deras sårbarheter på minnessäkerhetsproblem. Google hittade också en liknande procentandel av minnessäkerhetssårbarheter under flera år i Chrome.
Bild från Microsofts presentation (länkad ovan)
Det ska vara kostsamt för angripare att identifiera och utnyttja säkerhetsbrister. För utvecklare ska det vara enkelt att göra rätt och verktyg ska finnas för att varna eller göra det omöjligt att göra säkerhetsfel.
Två nya sårbarheter har uppdagats i web-cache mjukvaran Varnish. Varnish används främst som reverse-proxy framför stora sajter som vill minska belastningen på bakomliggande mjukvara. Varnish började som ett projekt runt 2006 på den norska tidningen VG, Verdens Gang. Numera används Varnish av många stora företag och sajter såsom Tesla:
Båda sårbarheterna uppdagades av Martin van Kervel Smedshammer vid universitetet i Oslo. Den första sårbarheten, Request Smuggling drabbar versionerna 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.2.0.
Och den andra sårbarheten, Request Forgery återfinnes i följande versioner:
Varnish Cache version 5.x, 6.x, 7.0.x, 7.1.0, 7.1.1, 7.2.0.
Varnish Cache 6.0 LTS upp till och inklusive version 6.0.10.
Varnish Cache Plus från Varnish Software 6.0.x upp till och inkluderad 6.0.10r2.
Det är möjligt att begränsa skadan av dessa sårbarheter genom att införa en Varnish Configuration Language (VCL)-regel.
För mer information om dessa sårbarheter se Varnish hemsida. Request smuggling-sårbarheter kan användas för att bl.a. ta sig förbi begränsningar i regler eller läsa andra användares information. Request Forgery-sårbarheten har och göra med att hanteringen av HTTP/2 psuedo-headers kan skickas vidare på ett felaktigt sätt till bakomligande HTTP/1-server.
OpenSSL-teamet har gått ut med förhandsinformation gällande en ny sårbarhet som uppdagats i kryptobiblioteket OpenSSL. Information och en ny version av OpenSSL-biblioteket kommer att släppas den 1:a November någon gång mellan klockan 13 och 17:00 UTC.
Den nya versionen har nummer 3.0.7 och åtgärden klassas som KRITISK. Och enligt OpenSSL-projektets policy så innebär KRITISK att det är en sårbarhet som enkelt kan utnyttjas via internet och kan ge möjlighet att läsa minne eller godtycklig exekvering av kod.
Det är oklart i dagsläget huruvida andra forkar av OpenSSL påverkas såsom LibreSSL och BoringSSL. Viktigt är också att OpenSSL 1.1.x inte är drabbad av denna sårbarhet.
Vi får hoppas att detta inte blir en ny Heartbleed. Men OpenSSL är en viktig del av otroligt många produkter, system osv så oavsett vad som händer på tisdag den 1:a november så kommer det att komma många uppdateringar till diverse system och produkter.
Bugbounties är en av flera metoder att öka säkerheten i opensource-mjukvaror och Google betalar ut pengar till den som hittar buggar i OpenSSL sedan 2013.
Uppdatering: Även om OpenSSL 1.x är den vanligare versionen där ute så finns OpenSSL 3.x på rätt många ställen, bl.a. så skeppar Red Hat Enterprise Linux 9.x och Ubuntu 22.04 med OpenSSL 3.x som är sårbar.
