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.
Under mina många år i branschen är det få personer som har gett ett sådan gott intryck som Mårten Mickos. Mårten är från Finland, pratar flytande svenska och bor numera i San Francisco där han är VD för HackerOne.
Jag tog ett snack med Mårten och vad HackerOne pysslar med och hans jobb som VD där:
Vilka är de största fördelarna med att ha ett bugbounty-program för en organisation?
Det finns inget annat sätt att hitta de svåraste sårbarheterna. Testverktyg, code scanners och till och med intern personal följer order och hittar bara det de satts att söka. Men buggjägare är obundna och har närapå oändlig kreativitet. De hittar de kritiska buggarna – de som kriminella annars skulle exploatera. Till och med de organisationer som kan anställa hur mycket datasäkerhets- och test-personal som helst – Google, Amazon, USAs försvarsdepartement – kör sådana program. Förr var det ganska mycket jobb att drive ett bugbounty-program men i dag är det lätt tack vare företag som HackerOne. Man kan starta smått och utvidga an efter.
På vilket sätt kan företag såsom HackerOne hjälpa organisationer med dess cybersäkerhet?
HackerOne hjälper dem som utvecklar och driftsätter mjukvara. Nästan alla företag har i dag sin egen webbapplikation och kanske mobilapp. Mjukvaran uppdateras hela tiden, och till sin struktur är alla applikationer i dag byggda på kod som levererats av någon annan. Så hur man än gör så har systemen hål och sårbarheter, som man själv eller tredje part förorsakat. På något sätt måste man utsätta dessa applikationer för kontinuerligt testande så att hålen kan lappas. Annars lämnar man dörren öppen för dataintrång av kriminella eller främmande makt, vilket vore ansvarslöst. HackerOne kan sköta detta testande från början till slut för kunder stora som små. Till vår hjälp har vi världens bästa säkerhetsexperter som anmält sig som frivilliga på vår plattform. Dessa så kallade etiska hackare tävlar med varandra om vem som är bäst och får betalt enligt vad de hittar. En sann global meritokrati som producerar världens bästa datasäkerhet.
Vad är det som utmärker en person som är bra på att hitta brister och sårbarheter? (buggjägare)
Nyfikenhet. Det är så enkelt. Visst krävs det kreativitet, logiskt tänkande, datakunskap och goda sittmuskler också. Men det är nyfikenheten som driver dem. Samma som man ser med barn som skruvar i sär sina leksaker (och annat!) för att förstå hur de funkar.
Är ett bugbounty-program något för alla organisationer?
Bara för dem som vill undvika dataintrång.
Bäst passar bugbounty för organisationer som utvecklar och driftsätter mjukvara för sina kunder. Vanligen är det fråga om webbapplikationer, mobilappar och gränssnitt (API). Men vi har också kunder av många andra typer, t.ex. IoT-leverantörer. Riktigt små organisationer saknar ofta kapacitet att ta hand om datasäkerhet, så våra kunder har ofta tiotals utvecklare eller mer. Det är fråga om högteknologiföretag (som PayPal, Zoom och Slack), banker (som Goldman Sachs, CapitalOne), industriföretag (t.ex. General Motors, Caterpillar, Toyota), konsumentföretag (t.ex. Starbucks, Hyatt Hotels m.m.) och den offentliga sektorn (t.ex. försvarsdepartementen i USA, Storbritannien och Singapore).
Vilka är de vanligaste misstagen företag gör när de implementerar ett bugbounty-program?
Vi tar hand om det mesta för våra kunder så i dagens läge är det inte så många misstag som kan ske. Viktigast är kanske att kunden har en intern beslutsamhet att åtgärda sårbarheterna. Det är möjligt att vi hittar ganska många. Då måste kodarna vara beredda på att ta itu med buggarna. Först kanske de lite knotar, men fort inser de värdet av riktigt avancerade buggrapporter. För en utvecklare blir det en möjlighet att skärpa sina egna kunskaper samtidigt som applikationen blir säkrare.
Vad ser du för framtid inom området? Har ni några nya intressanta funktioner eller tjänster på gång?
Det här är ett område som blir bara större. Nu ser vi att USAs statsförvaltning börjar kräva sårbarhetsprogram av alla som levererar något till myndigheterna. Banker och försäkringsbolag kommer till oss allt oftare. Själva bygger vi ut tjänsterna. Vi kan nu gå in på insidan och revidera källkod också. På så sätt hittas sårbarheterna tidigare och smidigare. Vi bygger också ut vår förmåga att hitta svagheter i AI-applikationer. Det är en helt egen värld med ”prompt injection”, ”training data poisoning” och andra faror. Det finns många leverantörer i denna bransch. HackerOne är klart störst och vi har det bredaste utbudet.
Vad är det du gillar mest med ditt jobb som VD På HackerOne?
Det är nog att se de oerhört duktiga experterna som vi har i vårt nätverk. Några av de absolut bästa är bara 17 år gamla. Många har känt sig åsidosatta i samhället. Ingen har verkat behöva dem. Men när de får jaga buggar på HackerOnes kundprogram märker de att deras arbete behövs (och belönas). De sträcker på ryggen och blir stolta. De växer upp och mognar till ansvarskännande globala medborgare. Utan dem skulle vår digitala värld vara på väg i en ganska så otrevlig riktning. Men här har vi lösningen. Och det finns massvis med sådana etiska hackare. Vi har två miljoner i vårt nätverk. På sätt och vis är de som digitala scouter. De över upp sig i nyttiga aktiviteter och gör en god gärning varje dag. De är redo.
Tack Mårten! Och för den som vill jaga efter säkerhetsbuggar och eventuellt tjäna lite pengar kan registrera sig gratis på HackerOne.com.
Jag tog ett snack under sommaren Olle E Johansson som är en av initiativtagarna bakom projektet DNSTapir. Olle berättar mer om projektet:
Fokus vad gäller DNS har varit mycket på hur man kan skydda sina frågor från insyn och hur vi kan lita på svaren. Vi såg att det finns mycket information i loggarna från DNS resolvers, dom som förmedlar svar, som är värd att analysera. Det görs idag, men i många fall av utländska aktörer som förser oss med gratis resolvertjänster. Vi vill se till att loggarna anonymiseras och att vi kan analysera data och se vad som händer, inte minst ur cybersäkerhetssynpunkt.
Med stöd av Sunet/Vetenskapsrådet bildade vi projektet Robust DNS som nu fått projektmedel av Post- och Telestyrelsen. Organisation: Vi är nu i en uppstartsfas av ett utvecklingsprojekt och ett Open Source-projekt. All utveckling kommer att ske öppet i vårt projekt ”DNStapir” på Github. Dagens gäng är initiativtagarna – däribland Lars Johan Liman på Netnod, Johan Stenstam på Internetstiftelsen, Jakob Schlyter på Kirei och Mikael Kullberg på Cat Herd. Leif Johansson på Sunet satte oss i samma rum och har fått igång projektet.
Vi har också resurser från Sunet i projektet och kommer att utvidga vårt nätverk och bygga en långsiktig organisation. Jag har en sammahållande funktion i det hela. Partners bakom projektet är idag PTS, Sunet/Vetenskapsrådet, Netnod och Internetstiftelsen. Vi kommer att söka samarbete med fler organisationer, både i näringslivet och i offentlig sektor. Framtidsplaner: Vi jobbar nu med steg 1: Utveckling av arkitektur och programvara.
Samtidigt planerar vi för kommande steg som innebär att bygga för drift och ge oss en stabil grund för vidare utveckling. Idéerna sprudlar och vi har många roliga diskussioner i arbetsgruppen. Målet är att vi ska bygga en plattform som olika operatörer – såväl privata som i offentlig sektor – har förtroende för. För att lyckas krävs ett samarbete, inte minst med Sveriges internetoperatörer. Vad gäller DNS generellt så är jag nog inte rätt person att svara, men har ju expertisen i projektet. Det pågår ju mycket arbete i IETF för att öka privacy i DNS och stärka infrastrukturen. Ett problem jag ser är ju att DNSSec inte har acceptans i alla kretsar och i viss mån motarbetas.
Personligen är jag ju intresserad av att förankra klient- och server-certifikat i DNS, vilket förutsätter DNSsec. Jag är med i arbetsgruppen DANCE som jobbar med klient-cert. Den lösningen handlar mer om TLS och applikationer än själva DNS, men förutsätter DNSsec.
Kontaktuppgifter: Om man har frågor får man gärna kontakta mig direkt. Som sagt, vi bygger upp en organisation inklusive web sajt och kommer att synas mer under hösten. Projektet DNStapir finns redan på GitHub och där kommer det löpande komma mer kod och ges möjlighet att medverka.
