Windows RCE i LDAP

I tisdags var det återigen dags för Microsofts månatliga Patch-tisdag, och denna gång adresserades ett antal mycket allvarliga säkerhetsbrister. Totalt patchades 16 sårbarheter som möjliggör Remote Code Execution (RCE), varav flera klassas som kritiska.

Den brist med högst CVSSv3 base score var en sårbarhet i Windows LDAP-hantering som hamnar på hela 9.8. Som förmildrande åtgärd rekommenderar Microsoft att blockera inkommande RPC-anrop, samt förhindra helt utgående trafik från domänkontrollanter. Vid utnyttjande av bristen så erhåller en eventuell angripare samma rättigheter som LDAP-tjänsten. Samt så klart installera själva patchen som åtgärdar bristen (och övriga brister inom LDAP som listas nedan).

Extended Protection for Authentication (EPA), SMB signing och LDAP signing + channel binding är rekommenderat att använda generellt i Windows-miljöer för att höja säkerheten.

Även så har ett aktivt utnyttjande av en zero-day i Windows Common Log File System (CLFS) identifierats och patchats, CVE-2024-49138. Den har en något lägre CVSS på 7.8, främst för att det är en lokal brist men medger rättighetshöjningar.

Nedan följer en tabell med samtliga tre brister som åtgärdas i LDAP:

SeverityCVSS ScoreCVEDescription
Critical9.8CVE-2024-49112Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
Critical8.1CVE-2024-49124Windows Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability
Critical8.1CVE-2024-49127Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability

NISTs uppdaterade riktlinjer för lösenord

NIST Password Lösenords policy

Det amerikanska organisationen National Institute of Standards and Technology (NIST) uppmanar till att överge gamla metoder för lösenord till förmån för mer nya och effektiva skydd. Här har jag sammanfattat sex viktiga insikter från NIST:s nya rekommendationer som kan hjälpa Er organisation att skapa moderna och säkra lösenordspolicyer:

1. Prioritera längden på lösenordet framför komplexitet

Tidigare har många organisationer krävt komplexa lösenord med stora och små bokstäver, siffror och specialtecken. Men ny forskning visar att människor ofta skapar förutsägbara mönster som gör lösenorden lättare att gissa.

NIST föreslår istället att fokusera på lösenordets längd. Uppmuntra därför användare att skapa långa lösenfraser, som kombinerar orelaterade ord, exempelvis “lamas-kasett-trumpet7”. Dessa är både enklare att komma ihåg och svårare att knäcka än komplexa men förutsägbara lösenord.

2. Möjliggör långa lösenord

NIST rekommenderar att stödja lösenord upp till 64 tecken för att ge maximal flexibilitet och säkerhet. Även om lösenfraser inte är osårbara, erbjuder de bättre skydd än kortare alternativ. Se till att dina system tillåter tillräckligt långa lösenord:

SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.

3. Inför multifaktorautentisering (MFA)

Enligt undersökningar från Microsoft saknade 99 % av alla komprometterade konton MFA. NIST understryker att MFA inte längre är valfritt – det är ett måste. Kombinera lösenord med ytterligare autentiseringsfaktorer för att öka säkerheten ytterligare.

4. Undvik frekventa lösenordsbyten

Många användare ogillar att ofta behöva byta lösenord ofta, och NIST rekommenderar att slopa denna praxis om det inte finns bevis för att ett lösenord har komprometterats. Ofta leder sådana krav till svagare lösenord, då användarna gör minimala ändringar. En mer balanserad strategi är att förlänga tiden mellan byten och istället använda verktyg som upptäcker komprometterade lösenord såsom HaveIBeenPwned.

5. Blockera komprometterade lösenord

Att använda lösenord som redan finns i databaser över tidigare läckor är en stor säkerhetsrisk. NIST rekommenderar att man kontrollerar nya lösenord mot dessa databaser för att förhindra att komprometterade lösenord används igen. Detta kan eliminera en vanlig attackmetod innan den utnyttjas. Och för att implementera detta kan exempelvis k-anonymitet användas eller nedladdade databaser från HaveIBeenPwned.

6. Sluta med lösenordstips och säkerhetsfrågor

Traditionella metoder som lösenordstips och säkerhetsfrågor är föråldrade och bör ej användas. Med dagens tillgång till information via sociala medier är svaren ofta enkla att hitta. NIST föreslår istället att använda säkrare alternativ som återställningslänkar via e-post eller MFA vid lösenordsåterställningar.

Att anpassa sig till NIST:s riktlinjer är ett viktigt steg mot starkare lösenordssäkerhet i din organisation. Genom att fokusera på lösenordslängd, använda MFA och förebygga vanliga misstag kan du skapa en säkerhetspolicy som är både användarvänlig och robust.

Här kan du läsa hela det nya dokumentet med rekommendationer:

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: