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.
Cisco Talos varnar för att en statlig grupp med kopplingar till Kina just nu utnyttjar två zero-days som återfinnes i Cisco ASA-produkter. De två sårbarheterna som utnyttjas sedan tidigt 2024 är enligt följande:
CVE-2024-20353
CVE-2024-20359
Dock har dessa CVE:er tyvärr inget att göra med initiala attackvektorn som fortfarande är okänd för Cisco.
Cisco har släppt ett kommando som man kan köra på sin Cisco ASA-enhet för att se om man har fått ett implantat inladdat:
show memory region | include lina
Och kontrollera följande:
Den övre delen av bilden ovan visar på flertalet adressrymder där Perm är r-xp och pathname /asa/bin/lina, detta indikerar på att det eventuellt finns en bakdörr i enheten.
Angriparna har också genomfört flertalet anti-forensiska åtgärder i bakdörren, vilket är intressant. En av dessa är bl.a. att se till att en krash-dump som genereras ej innehåller bakdörren.
Bakdörrarna går under namnen Line Runner och Line Dancer och hela kampanjen går under namnet ArcaneDoor av Cisco.
Rekommenderar även att läsa följande artikel som jag skrev på LinkedIn:
Uppdatering 2: Att stänga av telemetri är ej längre rekommenderat åtgärd för att förhindra utnyttjande av sårbarheten:
Uppdatering: Sårbarheten har CVE-2024-3400
En ny sårbarhet utnyttjas aktivt mot Palo Alto Networks tjänst GlobalProtect som är en del av dess operativsystem PAN-OS. CVSS är absolut högsta (10) och är därmed mycket kritisk och bör åtgärdas snarast. Sårbarheten medger att en angripare över nätverket kan exekvera kommandon som root mot enheten.
Cloud NGFW, Panorama appliances och Prisma Access berörs ej av denna sårbarhet. Inte heller andra typer av enheter som använder sig av PAN-OS.
Sårbarheten gäller för PAN-OS 10.2, PAN-OS 11.0 och PAN-OS 11.1 där GlobalProtect och telemetri är aktiverat. För att temporärt göra så att sårbarheten ej kan utnyttjas av en angripare så rekommenderar Palo Alto Networks att telemetri temporärt stängs av enligt följande instruktion. Patchar är på väg och förväntas bli färdiga den 14:e april.
Uppdatering: Sårbarheten har fått namnet BatBadBut och gäller fler programspråk än Rust.
Om du använder program som är skrivna i Rust under Windows och dessa i sin tur kör batch-filer med filändelsen .bat eller .cmd så kan du ligga risigt till.
Det är nämligen så att det kan vara möjligt att få med otillåtna argument vidare till dessa script har det visat sig. Även om dokumentationen till Rust skriver ”it should be safe to pass untrusted input as an argument”.
CVSS för detta är 10, vilket är kritiskt och CVE-numret är: CVE-2024-24576
En fix för detta finns med i Rust version 1.77.2 som släpps idag den 10:e april. Och bristen gäller således alla Rust-versioner innan denna. Sårbarheten rapporterades till Rust-projektet av RyotaK.
En bakdörr har identifierats i projektet xz/liblzma. Vad vi vet än så länge så påverkar bakdörren sshd på Linux-baserade operativsystem. Några intressanta saker i historien som jag uppmärksammat är att antagonisten har jobbat metodiskt under flera år för att föra in bakdörren, samt så är bakdörren bra skriven. Den injiceras när koden byggs som jag kan utläsa det och finnes i xz-versionerna 5.6.0 och 5.6.1
En annan intressant del är hur den upptäcktes, det var via prestandaproblem som den kunde identifieras. Bakdörren har fått CVE-2024-3094 med en CVSS på 10.
Det kan även finnas fler bakdörrar i koden eftersom det github-alias som införde bakdörren även genomfört 750 andra ändringar i xz/liblzma-projektet.
Bakdörren upptäcktes av Andres Freund och även amerikanska CISA har gått ut med en advisory.
Just de versioner av xz med bakdörrar verkar finnas i Fedora Linux 40 (vissa) samt Fedora Rawhide. Debian Unstable och Kali Linux är också drabbade. Samt så har Red Hat Enterprise Linux ej denna version. Meddelande från Kali:
The impact of this vulnerability affected Kali between March 26th to March 29th
För att se om du använder en version som är sårbar kan följande oneliner användas. Obs, undvik att köra själva xz-binären:
for xz_p in $(type -a xz | awk '{print $NF}' | uniq); do strings "$xz_p" | grep "xz (XZ Utils)" || echo "No match found for $xz_p"; done
Minst två falska servrar som tillhandahåller paket och uppdateringar till programspråket har identifierats. Och det var via top.gg-forumets hackade Github-sida som detta uppdagades via en så kallad supply-chain attack.
Skärmdump som visar på commiten där pypihosted.org ändras till den skadliga sidan pythonhosted.org:
Efter att colorama-modulen importerats enligt ovan skärmdump så körs skadlig kod som sedan försöker identifiera lösenord, nycklar, sessioner och annat intressant. Även så installeras en registernyckel i Windows som gör att den skadliga koden startas igen vid omstart.
Det är i dagsläget oklart hur många som drabbats av denna bakdörr, men top.gg-forumet har 170k användare. Även har andra repos på Github hackats såsom en TikTok-viewbot, men gör man en sökning på github i dagsläget så finns det inga referenser kvar till pypihosted.org förutom denna Solana-Sniper.
Följande IOC:er (Indicators of Compromise) kan användas:
Tycoon är en attack som riktar sig mot GMail och Office 365-inloggningar som använder sig av MFA, multifaktorsautentisering.
Tycoon fungerar som en phishing-as-a-service (PhaaS)-plattform och underlättar för cyberkriminella att lägga sig som en mellanhand vid inloggningar och därmed kringgå det skydd som MFA ger. Denna typ av attack går också under samlingsnamnet adversary-in-the-middle (AitM).
Just denna PhaaS är den som är mest aktiv och uppdaterades nyligen att bli ännu mer effektiv. Det har identifierats minst 1100 olika domäner där denna attack återfinnes.
Bild från Sekoia
Attacken som stjäl sessions-cookies efter användaren autentiserat sig med användarnamn, lösenord och en ytterligare faktor ser ut enligt följande steg:
Angriparna sprider skadliga länkar via e-postmeddelanden med inbäddade webbadresser eller QR-koder, vilket lurar offren att surfa till en phishing-sida
En säkerhetsutmaning (Cloudflare Turnstile) filtrerar bort bottar och tillåter endast mänskliga interaktioner att fortsätta till den bedrägliga phishing-sidan
Bakgrundsprogram extraherar offrets e-post från webbadressen för att anpassa phishing-attacken
Användarna omdirigeras till en annan del av phishing-sidan, vilket flyttar dem närmare den falska inloggningssidan
Denna fas presenterar en falsk Microsoft-inloggningssida för att stjäla inloggningsuppgifter, med hjälp av WebSockets
Kittet imiterar en 2FA-utmaning och fångar upp 2FA-token eller svar för att kringgå säkerhetsåtgärder
Slutligen riktas offren till en legitimit utseende sida, vilket döljer phishing-attackens framgång
Denna typ av attacker är en katt och råtta-lek där tjänsteleverantörerna blir bättre och bättre på att upptäcka och försvåra AitM-attacker.
Andra snarliknande phishing-kit heter: Dadsec OTT, Caffeine, NakedPages och Greatness. Jag har tidigare bloggat om metoder för att ta sig förbi MFA/2FA här.
Idag har det varit stora driftstörningar på flertalet ställen runt om i världen. Dels har Facebook haft problem under några timmar med inloggningar på dess plattformar såsom Instagram, WhatsApp, Messenger och Facebook.com. Dels har även det genomförts överbelastningsattacker (DDoS) mot flertalet svenska sajter såsom regeringen.se, Konkurrensverket, IMY. Och bakom DDoS-attackerna så står en eller flera pro-ryska hackergrupper enligt chatt-kanaler på kommunikationstjänsten Telegram.
Från telegram så kan vi även se att mål för DDoS har även varit www.riksgalden.se och isp.se. Projektet går under namnet DDoSia Project, samt så används Go Stresser som en av mjukvarorna för att skicka paket. Skrämdump från telegram:
Skärmdump från Riksdagens hemsida så som den ser ut just nu:
Troligtvis ej relaterat men flertalet undervattenskablar har också troligtvis kapats i röda havet:
Det amerikanska säkerhetsföretaget Rapid7 har identifierat två nya allvarliga sårbarheter i JetBrains TeamCity CI/CD-server.
Sårbarheterna är enligt följande två CVEer:
CVE-2024-27198 – Denna sårbarhet gör att det är möjligt att ta sig förbi autentiseringen genom CWE-288 ”Authentication Bypass Using an Alternate Path or Channel”
CVE-2024-27199 – Gör också att det är möjligt att ta sig förbi autentisering i webbkomponenten genom CWE-22 ”Improper Limitation of a Pathname to a Restricted Directory/Path Traversal”
Dessa två sårbarheter har CVSS score på 9.8 (Critical) respektive 7.3 (High). Jetbrains som är företaget bakom TeamCity har släppt ett blogginlägg om sårbarheterna samt rekommenderar att organisationer uppdaterar till version 2023.11.4 snarast.
A remote unauthenticated attacker can leverage this to take complete control of a vulnerable TeamCity server.
Att containers har blivit en del av många organisationers vardag råder det ingen tvivel om. Med hjälp av populära verktyg såsom Docker, Podman eller Kubernetes (K8s) så realiserar dessa en containerbaserad infrastruktur och applikationsdistribution.
Det är av stor vikt att hålla dessa säkra och nedan följer en guide hur du kan minska risken för eventuella cyberattacker.
Minska attackytan
Först och främst gäller det att minska attackytan. Detta för att minska risken, och att uppnå en 100%-ig säkerhet är så klart helt omöjligt. Men hur gör man för att minska attackytan? Jo det består i flertalet saker:
Använd användare med låga behörigheter inne i containern. Kör rootless utanför om möjligt
Använd en container till ett syfte. Dvs inte både webbserver och databas, exponera eller installera ej sshd inne i en container
Exponera minimalt med kataloger, sockets eller annat mellan containers och mot värden (operativsystemet som kör containers) och vice versa
Stäng av sådant som inte behövs, såsom nätverk. Kan stängas av med: –network none
Utgå från minimala containers såsom -slim och distroless
Skydda API:et eller socketen för att kommunicera med din containermjukvara såsom Podman, Docker osv. Dvs podman.socket och /var/run/docker.sock samt TCP-portarna 2376/2375
Håll dockerd, podman etc uppdaterat och även containers
Undvik argument såsom : –privileged och –cap-add då dessa öppnar upp för ”container escape” sårbarheter
Attacker via mjukvarukedjan (supply chain)
Ladda inte hem och använd godtyckliga containers, utan utgå ifrån sådana som är signerade och verifierade. Använd verktyg såsom cosign och docker trust för att verifiera. Det har hänt flertalet gånger att containers innehåller bl.a. crypto-miners.
Exempel på hur docker trust inspect kan användas för att validera alpine:latest
Och för cosign där jag verifierar distroless python3-debian11:
Även om containers är signerade så är det givetvis ingen garant för att den innehåller bakdörrar.
Loggning och spårbarhet
Det är av stor vikt att logga även sådant som händer i containers. Det vanligaste sättet är att skriva loggarna till stdout och sedan fånga upp detta. Viktigt är att centralt samla in loggarna och analysera dessa ytterligare efter avvikande mönster, kända attacker osv.
Även så finns det verktyg såsom Sysdig Falco eller auditd som kan kontrollera beteendet på dockerd eller inviduella containers. Exempel på hur audit.rules kan se ut för docker:
-w /usr/bin/docker -p wa
-w /var/lib/docker -p wa
-w /etc/docker -p wa
-w /lib/systemd/system/docker.service -p wa
-w /lib/systemd/system/docker.socket -p wa
-w /etc/default/docker -p wa
-w /etc/docker/daemon.json -p wa
-w /usr/bin/docker-containerd -p wa
-w /usr/bin/docker-runc -p wa
Glöm inte heller att logga och analysera nätverkstrafik som går in/ut ur respektive container, använd Suricata, Zeek eller Arkime. Försök att skilja på applikationsloggar, operativsystemsloggar, prestandaloggar etc. Även om alla är viktiga så har alla sina unika mönster för att identifiera intrång. Andra saker som kan skilja är hur länge du vill lagra dessa.
Sårbarhetsskanning
Det finns många bra verktyg för att genomföra sårbarhetsskanning av containers. Dels det inbyggda kommandot docker scout (tidigare docker scan som använde Snyk) och dels tredjepartsverktyg såsom trivy och grype.
Jag tänkte göra en snabb jämförelse mellan dessa tre enligt nedan.
Trivy
Jag använder en test-image vid namn hello-python. Sedan kör jag kommandot:
trivy image hello-python
Då identifierar den tre sårbarheter i python-paket och 47 st i alpine 3.11.5:
Grype
För att skanna av en container med grype kör jag kommandot:
grype hello-python
Och då hittar den enligt nedan. Totalt blir det 118 kända sårbarheter som identifieras, vilket är flest antal av de tre verktyg jag testar. Men dock räknar jag antalet CVE:er och GHSA:s individuellt så blir det 81 st.
Docker Scout
Kör jag med senaste versionen av docker scout, som tyvärr måste laddas hem separat då nyaste versionen ej ingår i Docker Desktop så hittar den 67 sårbarheter i 12 paket.
Även Docker Scout identifierar tre sårbarheter i python-paket (pypi). Kommandot jag använder är:
./docker-scout cves hello-python
Övrigt
Kan även rekommendera att titta på lösningar såsom Kata och Gvisor som tillför ett extra lager med säkerhet i Er container-miljö.
Vissa IT-forensiska utmaningar kan också uppstå i en container-baserad miljö. Se därför till att öva på olika scenarion där en container eller dess host-operativsystem drabbats av intrång, eller möjlighet att söka efter IOC:er (Indicators of Compromise).
Fick tips om att UFW ej fungerar tillsammans med Docker. Även en rekommendation om att skapa upp SBOM:s för alla dina containers, som jag bloggat tidigare om.
Se även över om ni kan upprätta ett eget container-index och således få en bättre överblick över vilka containers om används inom organisationen.
