Uppdatering: Mullvad har släppt information gällande denna sårbarhet. Och bekräftar att dom ej är sårbara pga brandväggsregler som förhindrar datatrafik utanför tunneln.
Uppdatering 2: Tipstack till Hjelmvik som tipsar om Dragos åtgärd till Linux att helt skippa option 121.
TunnelVision är en ny (gammal?) attack mot VPN-tunnlar som har fått CVE-2024-3661. Attacken gör det möjligt att lura klienter att skicka nätverkstrafik utanför VPN-tunneln, detta genomförs genom att skicka ett DHCP-paket som innehåller option 121. Just denna option 121 gör det möjligt att skicka in nya routing-tabeller, och då kommer klienten mer eller mindre automatiskt att skicka trafiken utanför VPN-tunneln (förenklat).
Option 121 supports installing multiple routes with CIDR ranges. By installing multiple /1 routes an attacker can leak all traffic of a targeted user, or an attacker might choose to leak only certain IP addresses for stealth reasons. We’re calling this effect decloaking.
Detta gäller oavsett vilket operativsystem eller VPN-protokoll som används (WireGuard, OpenVPN etc). Dock så stödjer Android ej DHCP option 121. Ett sätt att åtgärda detta problem är att använda network namespaces.
Observera att angriparen måste sitta på samma nätverk eller ha tillgång till DHCP-servern för att utföra denna attack. En snarlik attack publicerades förra året, med namnet TunnelCrack.
Sårbarheten uppdagades av Dani Cronce och Lizzie Moratti från företaget Leviathan Security Group. Givetvis har sårbarheten också en hemsida: tunnelvisionbug.com.
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.
Med anledning av senaste tidens händelser och en ökad hotbild på cyberarenan så tänkte jag passa på att skriva ner några bra tips och råd på hur Er organisation kan höja cybersäkerheten.
Cyberresiliens och överbelastningsattacker
Er hemsida kan utsättas för överbelastningsattacker eller DDoS som det också brukar kallas. Antagonisten kommer att försöka identifiera kritiska punkter och skicka anrop om och om igen till dessa. Därför är det viktigt att se över hela den exponering som återfinnes mot Internet. Glöm inte API:er, subdomäner, DNS, SMTP osv.
Se till att ha en nödsajt samt alternativa vägar för att kommunicera inom Er organisation. Om internetförbindelsen går ner till Er organisation eller om tjänster såsom Slack går ner på grund av ökad belastning, hur kan ni då kommunicera? Om ni använder tjänster såsom Cloudfront, Akamai eller Cloudflare, se då till att den bakomliggande infrastrukturen inte går att nås via utanför dessa tjänster.
Internetexponering
Att veta hur organisationen ser ut från internet är otroligt viktigt. För det är just på dessa exponerade punkter som antagonisten kommer att fokusera först på. Kontrollera därför Er domän eller IP-adresser mot följande tjänster:
Eller använd OAWSP amass som gör det automatiskt. Använd DNS Anycast och försök att fronta via CDN och WAF. Även om jag inte är ett stort fan av Web Application Firewalls så kan det vinna Er några timmar.
Autentisering
Denna punkt har också att göra med ovan punkt. Dvs identifiera alla exponerade delar mot internet där en användare kan autentisera sig. Här är det otroligt viktigt att använda flera lager av skydd, jag rekommenderar att använda VPN som omslutning för allt. Och se till att också använda tvåfaktorsautentisering med hårdvaru-tokens såsom Yubikeys och certifikat.
Så kortfattat: Exponera inget mot internet som går att köra över VPN. Se till att den som ansluter via VPN inte kommer åt mer än nödvändigt, tänk zero-trust arkitektur.
Patchning och uppdatering
Om möjligt, se till att systemen uppdaterar sig själva automatiskt med nya säkerhetspatchar. Men var också medveten om att det finns möjlighet för bakdörrar att sig sig in den vägen. Dvs gör ett noga övervägande om för respektive nackdelar med automatiskt säkerhetspatchning. För majoriteten så är detta rätt väg att gå men inte något för alla.
Patcha inte bara mjukvaror, glöm inte heller switchar, skrivare, firmware och annat som också måste uppdatera. Och håll koll på om produkter eller system börjar närma sig End-of-Life och vad ni har för möjligheter då.
Har ni system som är äldre och som inte går att uppdatera men som ni ändå är beroende av, se till att isolera dessa extra noga. Exempelvis ett eget segment i nätverket där allt är filtrerat in och ut samt en speciell jump-host måste användas för att komma åt detta gamla system.
Härda systemen och se till att enbart mjukvaror som används exponeras eller är påslagna.
Övervaka, öva och testa
Testa säkerheten kontinuerligt med automatiska testverktyg såsom Holm Security, Detectify eller Nessus. Anlita konsulter som gör återkommande manuella penetrationstester samt genomför kodgranskning löpande om ni utvecklar mjukvara.
Öva på att återställa backup och se till att backuperna lagras offline eller på annat sätt icke åtkomliga från den ordinarie IT-infrastrukturen.
En komprometterad klient kan snabbt leda till att hela Er Windows AD-miljö blir övertagen. Se därför till att ni snabbt kan detektera om en klient börjar att bete sig suspekt. Har ni inte förmågan själva så se till att anlita ett företag som är experter på SIEM/SOC. Och vad gör ni när ni upptäcker något suspekt eller blivit utsatta för intrång, då är det bra att redan ha upparbetade kontaktvägar eller plan hur delar ska isoleras för att begränsa skada.
Glöm inte att allt ni ansluter kan producera loggfiler och hjälpa till att upptäcka intrång, syslog har funnits med länge och går att slå på och använda på nästan allt som kopplas upp.
Sammanfattning
Sist men inte minst, det ni inte känner till kan ni inte heller skydda. Se därför till att inventera och ha en god koll på vilken utrustning ni har, såväl mobiltelefoner, servrar, laptops och annat.
Administrativa konton bör användas ytterst begränsas och om möjligt med dubbelhandsfattning, tidsbegränsat eller liknande. Inventera dessa konton kontinuerligt.
Se också över beroendet gällande leverantörer, underleverantörer och tredjepartsberoenden. Upprätta en SBOM eller liknande. Jobba långsiktigt och systematiskt med cybersäkerheten och genomför omvärldsbevakning löpande, jag själv använder Twitter som en källa.
Cyberangripare attackerar nu personal som nu jobbar hemma i allt större utstäckning. Med ett nytt modus operandi så ringer angriparen upp den anställde och förmår denne att logga in på en alternativ fiktiv webbsida för VPN-anslutningar.
Denna webbsida innehåller även funktion att lura till sig engångstokens för tvåfaktorsautentisering. Det var även på detta sätt som angripare lyckades göra intrång hos Twitter förra månaden.
Här är ett riktigt exempel på hur webbsidan helpdesk-att.com såg ut för några dagar sedan:
Denna typ av attack kallas för Vishing (voice phising) och har några år på nacken men att nu kombinera detta med attacker mot VPN som stjäl 2FA-tokens är det nya tillvägagångssättet.
Även kan denna attack kombineras med en annan attack som medger att spoofa numret till företagets växel så samtalet ser ut att komma från medarbetarens egna organisation.
Motåtgärder
Först och främst är utbildning en viktig faktor, även återkommande utbildningspass för medarbetare. När det gäller MFA/2FA så har angriparna ännu inte någon metod för att genomföra MITM på hårdvarunycklar såsom Yubikeys.
Och sist men inte minst så är det viktigt med spårbarhet och loggning och övervaka samtliga inloggningar och knyta dessa inloggningar vidare mot klientcertifikat och datorkonfiguration.
Kan även tipsa om svenska startupen Castle.io har en hel del intressanta metoder att hitta kapade konton.
De senaste dagarna så har det publicerats två intressanta sårbarheter som jag tänkte skriva några rader om, den första är en ”VPN bugg” som påverkar många olika typer av VPN-anslutningar och den andra handlar om en miss i operativsystemet OpenBSD som medger att flertalet autentiseringsmekanismer går att kringgå.
OpenBSD
Denna sårbarhet har CVE 2019-19521 och upptäcktes av säkerhetsföretaget Qualys. Även så finns det ett antal relaterade sårbarheter enligt följande:
CVE-2019-19520: Local privilege escalation via xlock
CVE-2019-19522: Local privilege escalation via S/Key and YubiKey
CVE-2019-19519: Local privilege escalation via su
Men den allvarligaste medger att du över nätverket (remote) kan kringgå autentiseringen i flertalet program såsom smtpd, ldapd och radiusd.
Det är nämligen så att programmet login_passwd anropas vid autentisering. Och om informationen som skickas vidare till login_passwd innehåller -schallenge som argument så returneras lyckad inloggning, se följande exempel:
Denna sårbarhet går under CVE 2019-14899 och medger att en angripare kan injicera data i en VPN-tunnel eller lista ut vilken IP som blivit tilldelad inne i en tunnel. Denna sårbarhet påverkar flertalet Linux OS, FreeeBSD, OpenBSD, Android och macOS.
Kortfattat kan man säga många operativsystem som etablerar VPN-tunnlar inte bryr sig om vilket gränssnitt som data kommer in på. Så om du har ett tunnel-gränssnitt och data helt plötsligt kommer in på ett annat gränssnitt så funkar det lika bra.
Och Colm MacCárthaigh som jobbar på Amazon meddelar att Amazon Linux inte påverkas men att attacken kan bli ännu mer allvarlig om DNS kan påverkas inne i VPN-tunneln:
Hijacking traffic via DNS is usually much more powerful than payload injection; for example an attacker can observe all connections but choose to target only connections that do not use TLS. This is more flexible and helps evade detection.
Mer omfattande information hittar du i följande PDF samt följande två intressanta patchar till OpenBSD:
En av de mer intressanta släppen under sommarens Blackhat-konferens i Las Vegas var den som handlade om att attackera SSL VPN:s.
Och varför är detta intressant? Jo det finns ett antal olika faktorer till att just detta är intressant och jag ska försöka beskriva dem nedan:
Underrättelsetjänster
NSA och andra underrättelsetjänster ser VPN:s som mål för att de används för att utbyta information. Med hjälp av passiv (och aktiv) avtappning så kan informationen ge fördelar, försprång och gynna den egna industrin:
Equation Group’s BENIGNCERTAIN tool – a remote exploit to extract Cisco VPN private keys.
Attackytan
Attackytan för specifikt SSL VPN:s är intressant då det mest troligt är en webbservern inblandad och denna kan innehålla sårbarheter. Webbservern måste hantera TLS, HTTP och underliggande protokoll. Vilket kan jämföras med exempelvis IKE och IPSEC.
En angripare som kan ta sig in i en VPN-enhet kan troligtvis också ta sig vidare in i nätverket eller modifiera kommunikationen (förutom att läsa av den).
Hårdvaran
När du köper ett SSL VPN så köper du troligtvis en låda av en leverantör som du inte vet så mycket om. Hur är det underliggande operativsystemet uppsäkrat? Vet du om den använder den ASLR + DEP? Och om den nu blir hackad, hur genomför du en forensisk undersökning av enheten?
Sårbarheterna
Följande sårbarheter har identifierats av Meh Chang (@mehqq_) och Orange Tsai (@orange_8361) i Fortigate SSL VPN:
CVE-2018-13379: Pre-auth arbitrary file reading
CVE-2018-13380: Pre-auth XSS
CVE-2018-13381: Pre-auth heap overflow
CVE-2018-13382: The magic backdoor
CVE-2018-13383: Post-auth heap overflow
Även har sårbarheter identifierats i Pulse Secure VPN, se mer här.
Även så har Palo Alto i all tysthet även patchat sin GlobalProtect, se mer här. Vad som också är skrämmande just nu är att två av ovan sårbarheter utnyttjas aktivt på internet av angripare vilket CERT-SE gick ut med en varning om.
Åtgärder
Sist men inte minst så tänkte jag ge några rekommendationer vad ni som organisation bör göra om ni har ett SSL VPN som är exponerat mot Internet.
Spara ner trafik framför och bakom SSL VPN:et. Så ni kan i efterhand undersöka vad som har hänt.
Uppdatera och se till att senaste säkerhetspatchar är installerade och att produkten inte är End-of-Life
Se till att loggar skickas från SSL VPN:et. Om möjligt alla typer av loggar såsom access-loggar på webbservern.
Begränsa tillgången till system som kan nås via VPN:et. Dvs ge inte full åtkomst till allt bara för att en användare ansluter via VPN.
Genomför en oberoende säkerhetsgranskning av uppsättningen
Er anslutningspunkt kanske inte bör vara vpn.företagsnamn.se
Följ upp anslutningar till och från Erat VPN. Har någon överfört 100 GB via VPN:et utan en koppling till en inloggad användare? Långa TCP-sessioner, beacons osv.
Policy över hantering av nya och användare som slutar samt regelbunden uppföljning
Försvåra password-spraying attacker genom att använda hårda/mjuka certifikat etc. Dator + användarcertifikat
Har ni eller har haft en sårbar version. Se till att byta samtliga lösenord
Sök av kontinuerligt med en sårbarhetsskanner
Har jag missat något ovan? Fyll gärna på i kommentarsfältet nedan.
Totalförsvarets forskningsinstitut (FOI) har sedan 10 år tillbaka förvaltat och utvecklat en övningsmiljö för cyberattacker (cyber range) vid namn CRATE. Miljön används för att bygga upp olika scenarion med hjälp av cirka 800 virtuella servrar och ett simulerat internet.
Huvudkunder för denna miljö är Myndigheten för samhällsskydd och beredskap (MSB) samt Försvarsmakten som båda har bidragit till uppbyggnaden av Crate. Övning i miljön kan också ske utanför anläggningen genom en extern anslutning till spelnätet via VPN. Dessutom går det att koppla in skrivare, telefoner, styrsystem och olika övervakningsstationer (ICS/SCADA etc) samt det mesta som VirtualBox kan hantera.
Fotografi från Crate City. Foto: FOI.
Crate är en viktig komponent för att öka Sveriges förmåga att hantera cyberangrepp. Vi ser anläggningen som en arena för samverkan mellan såväl det privata och offentliga som på ett nationellt och internationellt plan. Crate är unikt och hjälper verkligen företag och myndigheter att öka sin cybersäkerhet.
Konstaterar Åke Holmgren som är MSB:s chef för cybersäkerhet och skydd av samhällsviktig verksamhet
Dock verkar det inte helt lätt att komma igång med CRATE eftersom jag saknar en ”sign up” knapp, manuell kontakt som verkar gälla. Därför tror jag att många privata aktörer istället väljer lösningar från leverantörer såsom Hackthebox.eu eller bygger eget med Amazon EC2, vilket jag själv gör när jag vill sätta upp labbar eller övningar. Har du tips på andra leverantörer av cyber-rangers, lämna gärna en kommentar nedan.
Och förutom vid träning och övning används CRATE även för forskningsprojekt samt för test och försök.
Film från CRATE med en bro avsedd för leksakståg:
CRATE står för Cyber Range And Training Environment.
Assured AB har tillsammans med tyska Cure53 publicerat en säkerhetsgranskning av VPN-tjänsten Mullvad. Granskningen gäller främst VPN-klienten som släppts i en ny utgåva som baseras på Electron-ramverket. Cure53 är även kända sedan tidigare för att publicera flertalet av sina granskningar publikt.
Jag tycker detta är ypperligt bra att publicera granskningsrapporten transparent på detta vis och något som jag efterfrågat gällande VPN-tjänster tidigare.
Rapporten innehåller en del smaskigheter där en identifierad brist har severity High och en Critical. Rapporten framhåller ändå att det är relativt få sårbarheter som identifierats och en av de troliga orsakerna är att mullvad-daemon är skriven i programspråket Rust.
Testerna tog 18 dagar att genomföra och tre av granskarna kom från Assured och fem från Cure53.
Här kan du läsa granskningsrapporten i sin helhet:
Att använda VPN har blivit otroligt populärt på senare år men det finns anledningar att se upp och tänka efter en extra gång om du verkligen behöver använda ett VPN.
Så därför tänkte jag vara djävulens advokat och gå igenom några anledningar att inte använda ett VPN. Denna artikel gäller främst VPN-tjänster för hemmabruk/personligt bruk (som används för anonymisering).
Öppnar upp för nya sårbarheter
Klienter eller plugins som du installerar för att använda en VPN-tjänst kan innehålla sårbarheter och därmed kan sänka säkerheten på din dator. Det gäller givetvis all mjukvara du installerar såsom antivirus-program. Du bör även se upp om din VPN-leverantör bara stöder protokollet PPTP som sedan länge är osäkert.
Om du vanligtvis sitter skyddad bakom en brandvägg kan VPN-klienten eller -pluginet dessutom utan din vetskap öppna upp för inkommande anslutningar från internet eller andra VPN-användare.
Lämnar ut loggar
Det har förekommit att VPN-leverantörer loggar vem som anslutit när och kan då lämna ut uppgifterna till myndigheter som efterfrågar dessa. HideMyAss är exempelvis en leverantör som sparar loggar och lämnar ut dessa.
Har du dessutom betalt med kreditkort eller liknande så finns det stora möjligheter att koppla VPN-användaren till dig.
Leverantören Hotspot Shield loggar din data och kan även sälja den vidare till tredje part. De injicerar även JavaScript-kod i din okrypterade surftrafik.
Har du en stat som ingår i din hotbild som du försöker gömma dig för? Inget VPN i världen kommer troligtvis att skydda dig. Många VPN-leverantörer har en ingång och en utgång på samma server/IP etc och en myndighet eller signalspaningstjänst kan då koppla ihop utgången med ingångstrafiken.
Tänk även på att om du använder en VPN-anslutning mynnar ut i ett annat land så kommer detta lands signalspaningstjänst att se din trafik och eventuellt alla länder på vägen dit och mot din destination.
Din trafik kan även sticka ut om du försöker smälta in i normalbilden.
Överföringskapacitet
Din bandbredd och fördröjning kommer att påverkas negativt när du använder VPN. Testa att köra Bredbandskollen från Internetstsiftelsen före och efter du är uppkopplad via VPN så får du en uppfattning om ungefär hur stor skillnad det är. Det kan även vara bra att testa vid några olika tidpunkter på dygnet.
Det även vara så att din VPN-leverantör blockerar viss typ av trafik såsom peer-to-peer-protokoll eller e-post (SMTP).
Avslutande ord
Det finns absolut tillfällen då du kan överväga att använda ett VPN. Sådana kan vara när du sitter på ett internetcafé eller annat ställe där det tillhandahålls ett öppet WiFi eller att du litar mer på en VPN-leverantör än din internetleverantör.
Glöm inte heller att det finns tjänster såsom Tor som kan vara bättre att använda i vissa fall. Och framförallt så tänk på vad och hur du surfar när du använder tjänster såsom Tor eller ett VPN.
Mo Bitar som driver vpnreport.org har tittat närmare på 11 stycken olika VPN-tjänster och hur de lever upp till ett antal olika ställda krav som han själv formulerat.
De krav som Mo har identifierat som viktiga är följande:
Förhindra DNS-läckor
Andra typer av IP-adressläckor
Läckor via WebRTC
Hastighet
Baserat på OpenVPN eller IKEv2/IPsec
Ingen loggning eller spårning
Tre eller flera samtidiga enheter
Ärliga priser
Ärlig marknadsföring
Krav som är trevliga att ha är följande:
Servrar utanför England
Gratis provperiod
Anonym betalning
Fildelning via P2P och torrents
IPv6
Och sist men inte minst sådant som han anser inte alls bör finnas hos en VPN-tjänst:
Baserad på en föråldrade och osäkra tekniken PPTP
Bandbreddsbegränsning
Jag kan tycka att dessa krav kan vara tämligen enkla och tittar inte exempelvis på säkerheten i klienten (se rapporten nedan).
Bäst enligt testet blev TunnelBear och på andraplats kom min egen favorit OVPN (som jag även skrivit om tidigare).
TunnelBear uppfyller samtliga viktiga krav utom när det gäller läckage av IP-adress via WebRTC. Det gäller även OVPN, som rekommenderar att man stänger av WebRTC i sin webbläsare eller använder uBlock Origin.
Och kommer vi sedan till de krav som är trevliga att ha så slår OVPN Tunnelbear. Tunnelbear uppfyller nämligen ej följande krav:
Anonym betalning
IPv6
P2P och fildelning via torrents
Och när vi ändå nämner TunnelBear så är det även värt att tillägga att TunnelBear är ett av få VPN-leverantörer som genomfört en oberoende extern säkerhetsgranskning. I detta fall genomförde tyska Cure53 granskningen och rapporten kan du ladda hem här:
När får vi se OVPN eller Mullvad genomföra en oberoende extern granskning samt publicera resultaten?
Full disclosure: Vissa länkar ovan är så kallade affiliate-länkar. Dvs jag tjänar några kronor om du klickar och sedan väljer att betala för att använda tjänsten.
Hotbilden
