Kommande allvarlig sårbarhet

Uppdatering: Sårbarheten (sårbarheterna) är nu officiell och den återfinnes i CUPS. CUPS används för att hanter utskrifter. Läs mer på Simones blogg här men kontentan är att för den allvarligaste så behövs det enbart UDP-paket mot 631 där cups-browsed återfinnes. PoC återfinnes även här.

En säkerhetsforskare vid namn Simone Margaritelli (evilsocket) har på X (föredetta Twitter) skrivit att han identifierat en sårbarhet som fått CVSS score på hela 9.9 och påverkar majoriteten av all Linux-baserade operativsystem samt FreeBSD. Huruvida andra BSD OS såsom OpenBSD är sårbart, är oklart just nu.

Det har spekulerats en hel del var sårbarheten ligger bl.a. för att en ny version av OpenSSH släpptes precis som bl.a åtgärdar en del pre-auth prylar samt tar bort stöd för DSA i större utsträckning.

Datum som gäller framöver för denna sårbarhet:

  • September 30: Information på Openwall security mailing list.
  • Oktober 6: Full public disclosure

Observera att det fortfarande är oklart gällande omfattningen av denna sårbarhet.

Uppdatering: Evilsocket har nu stängt sin X-profil, här återfinns skärmdump av inlägget:

Veeam Remote-Code-Execution

Veeam

Flertalet allvarliga säkerhetsbrister har uppdagats i mjukvaran Veeam Backup & Replication. Minst två av dessa sex säkerhetsbrister som uppdagats leter till RCE (Remote Code Execution). Sårbarheter i backup-mjukvara är synnerligen allvarligt då dessa som oftast kör med höga behörigheter och kan innehålla en guldgruva för ransomware-grupperingar.

  • Sårbarheterna gäller också följande produkter, inklusive Backup & Replication:
  • Veeam ONE
  • Veeam Service Provider Console
  • Veeam Agent for Linux
  • Veeam Backup for Nutanix AHV
  • Veeam Backup for Oracle Linux Virtualization Manager and Red Hat Virtualization

Bristerna har identifierats av Florian Hauser från CODE WHITE GmbH och den högsta CVSS-scoren är på 9.8, vilket är kritisk nivå. Kan rekommendera följande läsning från Watchtowr.

Rekommenderat är att uppgradera till Veeam Backup & Replication version 12.2 (build 12.2.0.334).

Källa: Veeam security bulletin

Storbritannien satsar på honeypots

storbritannien NCSC satsar på honeypots

Trodde du att honeypots var ute? Då har du fel. Iallafall om man får tro brittiska cybersäkerhetscentret
NCSC (National Cyber Security Centre). NCSC satsar nu på att driftsätta ett stort antal olika honeyspots såsom följande:

  • Honeypots med hög och låg interaktion – Både på interna och och externa-nätverk inom organisationer i Storbritannien. Även kommer dessa driftsättas i molnmiljöer
  • Honeytokens – Unika siffror och tokens som ej ska röras eller förekomma i nätverk
  • Breadcrumbs – Ledtrådar som lurar en antagonist att logga in på system exempelvis

Att detta är en stor satsning kan man utläsa utifrån de siffror nedan på antalet instanser och tokens som minimum kommer att användas:

  • 5 000 instanser på det brittiska internet av låg- och höginteraktionslösningar över IPv4 och IPv6
  • 20 000 instanser inom interna nätverk av låginteraktionslösningar
  • 200 000 tillgångar inom molnmiljöer av låginteraktionslösningar
  • 2 000 000 distribuerade tokens

Målsättningen med dessa installationer och tokens är att svara på tre huvudfrågor:

  • Hur effektiva är implementationerna när det gäller att upptäcka dolda säkerhetsintrång inom organisationers system?
  • Hur effektiva är implementationerna när det gäller att kontinuerligt upptäcka nya säkerhetsintrång av hotaktörer?
  • Påverkar vetskapen om att sådana teknologier finns på nationell nivå det observerbara beteendet hos hotaktörer?

Synnerligen intressant satsning. Vi får hoppas att länder såsom Sverige tar efter och genomför liknande satsningar, kanske något för svenska NCSC?

Läs även mitt blogginlägg från 2015 då jag skrev om kanariefåglar inom cybersäkerhet.

Källa

0-klick RCE i Windows IPv6-stack åtgärdad

0-klick RCE i Windows IPv6-stack åtgärdad

Uppdatering: Enligt en källa på X (fd Twitter) så återfinnes sårbarheten i funktionen Ipv6pProcessOptions.

I veckan så var det dags för den månatliga patch-tisdagen, då Microsoft släpper viktiga buggfixar för Windows. Denna gång hanterades hela 90 CVE:er, varav en särskilt intressant sårbarhet stack ut: en 0-klick Remote Code Execution-sårbarhet i Windows TCP/IP-stack.

Detta innebär att skadlig kod kan fjärrexekveras på en Windows-server eller klient utan någon som helst användarinteraktion. Sårbarheten har identifierats som CVE-2024-38063 och återfinns specifikt i IPv6-delarna av TCP/IP-stacken. Den har tilldelats en allvarlighetsgrad på hela 9.8 och klassificeras som:

  • CWE-191: Integer Underflow (Wrap or Wraparound)

Denna kritiska sårbarhet upptäcktes av det kinesiska säkerhetsföretaget Kunlun Lab, och Microsoft har i sin säkerhetsrådgivning angivit att risken för utnyttjande är hög: Exploitation More Likely.

Rekommenderad åtgärd är att stänga av IPv6 temporärt alternativt installera denna månads säkerhetspatch.

Crowdstrike BSOD

Crowdstrike BSOD

I fredags så skickade det amerikanska cybersäkerhetsföretaget Crowdstrike ut en felaktig uppdatering till produkten Falcon Sensor som gjorde att cirka 8.5 miljoner Windows-datorer runt om i världen krashade och visade ”blue screen of death”, BSOD. Falcon Sensor är en Endpoint detection and response (EDR) mjukvara som bl.a. kan upptäcka cyberhot.

Men varför inträffade denna krash och hur kunde den få så stort genomslag? Det beror på ett antal olika faktorer. Crowdstrike har valt att implementera stora delar av sin mjukvara i Windows-kärnan, vilket får till följd att eventuella programmeringsfel får större konsekvenser. Dock så vinner man prestanda och kan göra saker som ej är möjligt från user-mode. Crowdstrike har gått ut med ett blogginlägg med mer information och skriver att det rör sig om en logisk brist gällande hanteringen av named pipes. Man skriver också på sin blogg att det de filer som innehåller den felaktiga uppdateringen “C-00000291-” ej är kernelkod, även om dom har filändelsen .sys. Dock är det oklart i dagsläget exakt hur uppdateringen leder till BSOD, på X så visar krashdumpen att minne från adressen 0x9c läses. Vilket gör att krashen inträffar.

Som oftast när det gäller uppdateringen till cybersäkerhetsprodukter så vill majoriteten genomföra detta ofta och automatiskt. Men om då leverantören klantar sig så kan detta få stora konsekvenser, såsom när McAfee år 2010 skickade ut en felaktig uppdatering som flaggade en Windows-fil som skadlig.

För att förhindra detta i framtiden så se till att Er miljö inte är homogen när det gäller exempelvis mjukvaror och operativsystem. Även om detta är en extra kostnad så är detta inte första och sista gången som en stor incident såsom denna kommer att inträffa.

Leverantören kan förbättra sitt QA-arbete och bl.a använda sig av Canary Deployment, läs mer om det här: semaphoreci.com/blog/what-is-canary-deployment

Ett annat sätt att förhindra sådant i framtiden är att inte ligga i yttersta framkant när det gäller uppdateringar. Se följande när det gäller att ligga på N-1 exempelvis:

Video från twitter hur du kan fixa BSOD. Obs, svårare om du använder bitlocker:

Pre-auth sårbarhet i openssh

En allvarlig sårbarhet har uppdagats i den populära mjukvaran OpenSSH. Sårbarheten medger att någon på internet kan utnyttja sårbarheten utan att vara autentiserad (pre auth). Sårbarheten har fått CVE-2024-6387 tilldelad, och går under namnet regreSSHion. Totalt finns det 14 miljoner exponerade OpenSSH-servrar på internet varav 700000 st är potentiellt sårbara.

Dock är sårbarheten inte helt enkel att utnyttja och går ej att utnyttja på samtliga plattformar. Versionen av OpenSSH som det gäller är mellan 8.5p1 och 9.7p1, dvs portabla versioner och som använder glibc (än så länge). Även är versioner innan 4.4p1 sårbara, för sårbarheten nedan. Sårbarheten identifierades av Qualys och deras information återfinnes här. Men kortfattat kan man säga att det är en variant på en tidigare sårbarhet:

CVE-2006-5051 – Signal handler race condition in OpenSSH
before 4.4 allows remote attackers to cause a denial of service (crash),
and possibly execute arbitrary code

Det är dock viktigt att betona att det är viktigt att uppgradera omgående. Speciellt för system som kör 32-bitar, såsom äldre routrar, switchar etc. Uppgradera till OpenSSH 9.8 (eller 9.8p1) som släpptes idag 1:a Juli. Denna release innehåller även en fix för en sårbarhet gällande funktionen ObscureKeystrokeTiming, som försvårar för en passiv angripare som kan läsa av tangentbordstryckningar.

Detta påvisar åter igen hur känsligt det är att exponera administrativa resurser mot internet såsom ssh. Försök istället att exponera wireguard eller liknande protokoll med mindre exponerad kodbas för ej autentiserade användare. Och isolera den process eller system som exponerar protokollet/tjänsten mot internet.

Blogginlägget uppdateras löpande

Intrång hos TeamViewer

TeamViewer hackade

Uppdatering: Nu har TeamViewer bekräftat att det rör sig om ryska APT29.

TeamViewer gick nyligen ut med information om att deras system blivit hackade. De anger i sitt meddelande att det enbart handlar om den interna IT-miljön och ej produktionssystem. Dock så finns det andra källor som pekar på att ryska APT29 står bakom intrånget och aktivt kan ta sig in i miljöer där TeamViewer är installerat. APT29 går också under namnet Cozy Bear, NOBELIUM eller Midnight Blizzard.

TeamViewer är en mjukvara för fjärrstyrning, fjärråtkomst och fjärrsupport. Den används för att ansluta till och styra datorer och andra enheter över internet, vilket möjliggör teknisk support, samarbete och filöverföring mellan användare oavsett var de befinner sig. TeamViewer används av både privatpersoner och företag för att underlätta fjärrarbete och teknisk support.

Följande meddelande gick ut från NCC Group och har delats på Mastodon:

Det är i ett tidigt skede och mycket som är oklart i dagsläget. Men jag rekommenderar att om du använder TeamViewer:

  • Stäng ner TeamViewer-servicen/mjukvaran omgående
  • Revidera eventuella loggfiler, se här
  • Undersök om TeamViewer finns installerat inom er organisation
  • Kontrollera nätverkstrafik på TCP/UDP-port 5938. Obs, mjukvaran kan använda andra portar
  • Undersök nätverkstrafik och DNS-uppslag till *.teamviewer.com
  • Vid eventuella indikationer på intrång, anlita specialister på IT-forensiska utredningar

Jag försöker att löpande uppdatera detta blogginlägg med ny information allt eftersom händelsen utvecklas.

TunnelVision – Ny sårbarhet som medger avidentifiering av VPN-trafik

TunnelVison Ny sårbarhet som medger avidentifiering av VPN-trafik

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.

Video som förevisar TunnelVision:

ArcaneDoor – Zero-days utnyttjas i Cisco-enheter

ArcaneDoor - Zero-days utnyttjas i Cisco-enheter

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:

show memory region | include lina

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:

Samt Cisco Talos utförliga inlägg här.

Ny Palo Alto Networks GlobalProtect-sårbarhet

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.

Lista med sårbara enheter:

Palo Alto Networks PAN-OS