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.
Att upptäcka bakdörrar i IT-system är ingen lätt match och en mycket bra utvecklad bakdörr är mer eller mindre omöjlig att upptäcka. En bra utvecklad bakdörr har en mycket liten och snäv målgrupp och ligger vilande större delen av tiden. Men det finns givetvis olika metoder och sätt att upptäcka bakdörrar, för förr eller senare så kan misstag eller avvikande beteenden analyseras och påvisa en bakdörr.
Denna guide är främst skriven för att upptäcka bakdörrar som redan är in-planterade. Och hur bakdörrarna kommer in är utanför denna guide, men för att nämna några sätt:
Implanterade från start i servrar eller mjukvara/hårdvara
Via manuella eller automatiska uppdateringar av mjukvara, firmware osv
Man in the middle-attack eller MOTS mot nedladdad mjukvara
Via hackad server eller klient, bifogade filer i mail, sårbarhet i mjukvara
En vital funktion för att upptäcka bakdörrar på klienter och servrar är att samla in data, det kan röra sig om processer som startar och avslutas, drivrutiner som installeras/avinstalleras, telemetridata. Det är information där en enskild loggrad eller händelse kanske inte säger så mycket, men om den berikas och sätts i ett större sammanhang kan identifiera ett avvikande beteende.
Använder ni Windows-baserade system så är Sysmon ett givet verktyg att använda. För Linux-system så bör man använda verktyg såsom Sysdig Falco och auditd. Eller mer generiska verktyg såsom osquery.
Jag rekommenderar även att titta närmare på Velociraptor som jag bloggade tidigare om. Givetvis bör även binärer, konfigurationsfiler och dylikt hållas koll på med tripwire-liknande funktionalitet. Jobb som körs vid regelbundna intervall såsom cron, AT (Task Scheduler) osv. Eller vid uppstart av mjukvara, system (autoruns).
Nätverk
Jag har tidigare skrivit om RITA som kan underlätta analysen av nätverkstrafik för att hitta beacons som bakdörrar och implantat använder sig av för att kommunicera. Men en väl skriven bakdörr gör detta väldigt sällan och avviker minimalt från normal nätverkstrafik.
Att använda sig av TLSI (TLS Inspection) kan underlätta analysen av TLS/SSL-krypterad nätverkstrafik men det finns givetvis risker också, som bl.a. NSA varnat för. Rekommenderar att titta på PolarProxy som kan hjälpa till med TLSI.
Passivt bör ni också undersöka om system anropar och kopplar upp sig mot kända C&C-servrar, därav viktigt att underhålla aktuella Threat Intelligence-listor med IP-adresser, domännamn etc.
Mängden av data som flödar ut ur era system kan också ge en fingervisning om exfiltration genomförs. Men detta är inte alltid helt enkelt att upptäcka, vid forensiska undersökningar där jag medverkat har jag sett att antagonister delar upp upp information i flertalet 500MB RAR-arkiv som exfiltreras över en längre tid för att undgå upptäckt.
Glöm inte heller att DNS kan användas för kommunikation, som bl.a. SolarWinds Orion SUNBURST-bakdörren gjorde. Även kan Twitter och andra sociala medier eller andra välkända tjänster användas för kommunikation med bakdörren. Steganografi kan också nyttjas för att försvåra upptäckt.
På internet eller fjärrsystem
Att aktivt undersöka vilka fjärrsystem på Internet som anropas kan hjälpa till att förstå om bakdörren pratar med en Command and Control-infrastruktur (C&C). Flertalet olika datakällor såsom Shodan kan användas för att förstå vilket eller vilka målsystem som kommunikationen sker mot.
Ett verktyg såsom JARM kan hjälpa till med detta och skapa unika signaturer. Observera att just aktivt undersöka system på internet kan vara en legal gråzon och undersök noga vad ni har möjlighet att göra.
Avslutande ord
Jag rekommenderar att bygga upp ett antal olika scenarion där ni undersöker vilka möjligheter ni har att upptäcka just dessa metoder. För att ge några exempel:
Log4j JNDI-sårbarheten utnyttjas på ett system mot Internet. Om en bakdörr sedan installeras på detta system, hur kan ni försvåra installation av bakdörren och hur ni upptäcka denna bakdörr?
En mjukvara som automatiskt uppdateras börjar att ”ringa hem” via dess normala kanaler för uppdateringar. Men innehåller nu krypterad data om erat interna nätverk såsom AD-namnet
DNS används för exfiltration
Switchen ni köpte innehåller en Rasperry Pi med WiFi eller 4G-mobildata för exfiltration av intern nätverkstrafik
Vad väntar ni på? Avsätt tid och resurser redan nu för att utveckla förmågan att upptäcka bakdörrar i IT-system. Och givetvis så bör ni också genomföra åtgärder för att försvåra för att bakdörren hamnar i IT-systemet i första taget, och även dess möjligheter att kommunicera ut på internet (eller på andra sätt ringa hem).
Desto mer bakdörren är integrerad i en befintlig komponent i era IT-system desto svårare är det att upptäcka den.
Tack till Erik Hjelmvik för genomläsning och synpunkter!
Uppdatering: Oklart om du måste vara autentiserad på WiFi-nätverket. Men jag tolkar det som att du ej behöver det.
Flertalet WiFi-relaterade säkerhetsbrister har uppdagats i Linux-kerneln. Minst tre stycken av dessa sårbarheter kan leda till fjärrexekvering av godtycklig kod (Remote-code-Execution, RCE).
Säkerhetsforskare vid universitetet TU Darmstadt har uppdagat bristerna som alla återfinnes i kernelns mac80211-ramverk. Dessa sårbarheter har föranlett att bl.a. en ny version av Tails har släppts.
Det finns även ett Github-repo med Proof-of-concept här:
Cybersäkerhetsforskare vid Cisco Talos har identifierat ett nytt bakdörrsramverk vid namn Alchimist. Ramverket är skrivet i förenklad kinesiska och har även en malware-modul som fått namnet Insekt. Stöd för operativsystem såsom Windows, Mac och Linux återfinnes.
Insekt är skrivet i programspråket GoLang och exploits har identifierats för Linux Polkit (CVE-2021-4034). Talos skriver även att det finns vissa likheter med ett annat kinesiskt bakdörrsramverk vid namn Manjusaka.
Funktioner som implantatet har:
Kontrollera filstorlekar
Hämta OS-information
Kör godtyckliga kommandon via cmd[.]exe
Uppgradera det nuvarande Insekt-implantatet
Kör godtyckliga kommandon som en annan användare
Sov under tidsperioder som definieras av C2
Börja/sluta ta skärmdumpar
Även så kontrollerar implantet
För Linux så används den hårdkodade katalogen /tmp/Res/ samt ett statiskt TLS-certifikat för kommunikation:
WhatsApp har gått ut med en uppdatering gällande två nya sårbarheter som går att utnyttja för att ta över en mobiltelefon.
Sårbarheterna går att utnyttja om en användare av WhatsApp tar emot ett videosamtal eller videofil. Sårbarheterna gäller både iOS och Android-baserade enheter. CVSS är är 9.8 vilket är mycket allvarligt.
För att åtgärda sårbarheten behöver du uppdatera till version 2.22.16.12 eller nyare. Det är i dagsläget oklart huruvida dessa två sårbarheter utnyttjas aktivt.
Följande CVE har tilldelats: CVE-2022-36934 och CVE-2022-27492. För mer information se WhatsApps hemsida eller NIST NVD.
WhatsApp Security Advisories
2022 Updates
September Update
CVE-2022-36934
An integer overflow in WhatsApp for Android prior to v2.22.16.12, Business for Android prior to v2.22.16.12, iOS prior to v2.22.16.12, Business for iOS prior to v2.22.16.12 could result in remote code execution in an established video call.
CVE-2022-27492
An integer underflow in WhatsApp for Android prior to v2.22.16.2, WhatsApp for iOS v2.22.15.9 could have caused remote code execution when receiving a crafted video file.
Försök även själv lösa CTF:er som är offline eller testa HackTheBox-utmaningar. För offline kan jag rekommendera Metasploitable2 eller vulnhub.com.
Kolla på verktyg som återfinnes på Github och testa dessa. Se om du saknar något och utveckla eller vidareutveckla något verktyg. Att ha något på github som du kan visa upp är otroligt värdefullt.
Att bli bra inom cybersäkerhet innebär som oftast att man måste känna till många olika områden och sedan välja att fördjupa sig inom ett område.
Jag är inte så mycket för certifieringar men om du ska titta på någon och ta så är det OSCP som gäller, för den är mest hands-on och någorlunda realistisk. Förvisso så har du inte den typen av tidspress och i riktiga situationer får du använda automatiserade verktyg. Certifieringar kan vara bra vid upphandlingar eller om ditt CV inte är så välfyllt ännu. Har inte själv tagit eller gått någon av SANS kurser, men GPEN är också väletablerd. Håll dig långt borta från CEH, jag har tagit den men hela upplägget kändes otroligt oseriöst.
Att utföra omvärldsbevakning och lägga tid på forskning och utveckling är vitalt, jag använder främst Twitter nuförtiden och LinkedIn till viss del. Förut så följde jag mängder med bloggar via RSS-flöden, men det gör jag inte längre.
Se vilka konferenser som går av staplen framöver och viktigt att säga när det gäller att åka på konferenser så kanske 1-2 föredrag är intressanta. Men underskatta inte heller det sociala som händer mellan föredragen och kvällarna.
Lär dig hur ett Windows AD fungerar och sätt upp en labb-miljö med en server och en klient. Testa att utföra olika attacker och ser hur de är möjliga. Börja ej med en fullt patchad server och klient, utan installera en server och klient som är något äldre. Testa sedan samma saker och verktyg mot en nyare version.
Det är också viktigt att kunna läsa kod och skriva minst ett språk. Spendera lite tid i IDA Pro eller Ghidra och lär dig hur program är uppbyggda och hur skadlig kod fungerar.
Att veta vilka spår man lämnar vid ett penetrationstest eller red-teaming uppdrag är viktigt, därför bör du också känna till OPSEC och IT-forensik. Lär dig minnesforensik, hårddiskforensik och nätverksforensik. Som bonus är det även bra att känna till forensik på mobiltelefoner.
Lär dig att läsa in en stor PCAP-fil och identifiera indikatorer på intrång. Lär dig hur volatility fungerar och hur du kan utläsa information från en minnesdump.
Viktigt är också att inte förlita sig på ett enda verktyg, så lär dig därför att använda olika verktyg för att uppnå samma mål. Skriv ner fördelar och nackdelar med verktygen som används. Exempelvis: Vad är skillnaderna mellan masscan och nmap?
Sist men inte minst måste jag nämna Kali Linux. Det är bra med ett operativsystem som har många färdiga verktyg installerade, men vad finns det för nackdelar? Jag saknar alltid massor av verktyg så har byggt en egen Kali dist där jag lägger till sådant som jag saknar, men nackdelen då blir storleken.
En till lista jag hittade via twitter som är värd att ta med för att lära sig:
