Kryptobugg i Java

ECDSA Kryptobugg i Java

En ny kryptobugg har identifierats i programspråket Java. Det gäller hur Java hanterar ECDSA-signaturer och buggen gör det möjligt att förfalska dessa signaturer. Sårbarheten gäller Java versioner mellan 15 och 18. Anledningen till att buggen uppstod var för att man bestämde sig för att skriva om koden från C++ till native Java.

Omfattningen av buggen är otroligt omfattande och gäller exempelvis OIDC, WebAuthn tokens, JWT och SAML. Intressant är också att Project Wycheproof som är utvecklat av Google har just tester för denna typ av sårbarhet.

ECDSA står för Elliptic Curve Digital Signature Algorithm och en längre förklaring av buggen finns på Neil Maddens blogg. Oklart gällande CVSS-scoring eftersom Oracle ger den 7.5 men Neil hävdar att den bör ligga på högsta och allvarligaste värdet som är 10.

Stack-overflow i Go:s hantering av PEM-certifikat

Sårbarhet i progamspråket Go:s hantering av PEM-certifikat

En stack-overflow brist har identifierats i programspråkets Go hantering av PEM-certifikat. Bristen har fått CVE-2022-24675 och uppdagades av Juho Nurminen från Mattermost.

Rekommenderat är att uppgradera till 1.18.1 och 1.17.9 som innehåller åtgärder för denna brist samt två andra. Oklart hur attack-vektorn ser ut för utnyttjande av denna sårbarhet, men troligtvis leder denna till ”RCE över nätverk” i flertalet applikationer.

Följande test har införts för att testa efter buggen:

Följande tre brister har åtgärdats:

- encoding/pem: fix stack overflow in Decode

A large (more than 5 MB) PEM input can cause a stack overflow in Decode, leading the program to crash.

Thanks to Juho Nurminen of Mattermost who reported the error.

This is CVE-2022-24675 and https://go.dev/issue/51853.

- crypto/elliptic: tolerate all oversized scalars in generic P-256

A crafted scalar input longer than 32 bytes can cause P256().ScalarMult or P256().ScalarBaseMult to panic. Indirect uses through crypto/ecdsa and crypto/tls are unaffected. amd64, arm64, ppc64le, and s390x are unaffected.

This was discovered thanks to a Project Wycheproof test vector.

This is CVE-2022-28327 and https://go.dev/issue/52075.

- crypto/x509: non-compliant certificates can cause a panic in Verify on macOS in Go 1.18

Verifying certificate chains containing certificates which are not compliant with RFC 5280 causes Certificate.Verify to panic on macOS.

These chains can be delivered through TLS and can cause a crypto/tls or net/http client to crash.

Thanks to Tailscale for doing weird things and finding this.

This is CVE-2022-27536 and https://go.dev/issue/51759.

RCE i Windows RPC

En ny allvarlig sårbarhet (Remote Code Execution) har uppdagats i Windows RPC-gränssnitt. Denna sårbarhet har fått CVE-2022-26809 samt CVSS score på 9.8 vilket är mycket högt.

Som en förmildrande åtgärd så rekommenderar Microsoft att blockera TCP port 445, men tittar man på Shodan så finns det över en miljon exponerade portar. Och här i Sverige finns det över 5000 exponerade MS RPC-portar. Dock går RPC även att köra över port 135, 139 och oklart varför Microsoft inte har med det i sin rekommendation.

Förutom att blockera dessa portar för inkommande trafik så bör du även installera tisdagens patchar som släpptes av Microsoft. Viktigt också att poängtera att exploit complexity är satt till ”low”.

Kvantdatorsäker algoritm i nya OpenSSH

OpenSSH

Den nya versionen 9.0 av OpenSSH som släpptes i fredags innehåller en spännande ny algoritm. Som standard framöver kommer en ny algoritm användas för att utbyta nycklar nämligen: NTRU Prime + X25519 ECDH. Dessa två i kombination ger ett skydd som försvårar nya okända attacker mot NTRU Prime samt försvårar även för forcering med hjälp av kvantdatorer.

Även om det just nu är osannolikt att kvantdatorer knäcker något i realtid just nu så finns alltid problemet med ”spela in nu, knäck senare” kvar. Därav denna tidiga åtgärd från OpenSSH-teamet.

Gällande standardiseringen från NIST PQC så är NTRU Prime en av finalisterna och blir det inte NTRU Prime som blir standard enligt NIST, så kommer OpenSSH troligtvis även att stödja den andra PQ-algoritmen. De andra två finalisterna är CRYSTALS-KYBER och Classic McEliece.

Från OpenSSH changelog:

* ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key
   exchange method by default ("[email protected]").
   The NTRU algorithm is believed to resist attacks enabled by future
   quantum computers and is paired with the X25519 ECDH key exchange
   (the previous default) as a backstop against any weaknesses in
   NTRU Prime that may be discovered in the future. The combination
   ensures that the hybrid exchange offers at least as good security
   as the status quo.

   We are making this change now (i.e. ahead of cryptographically-
   relevant quantum computers) to prevent "capture now, decrypt
   later" attacks where an adversary who can record and store SSH
   session ciphertext would be able to decrypt it once a sufficiently
   advanced quantum computer is available.

Det kommer troligtvis att dröja ett tag innan OpenSSH 9.0 dyker upp i mer populära Linux-distar.

Docker SBOM

Docker har precis släppt en ny funktion som gör det möjligt att skapa en Software Bill Of Materials (SBOM) på en docker-image. Förutom att det är ett krav på amerikanska myndigheter att upprätta en SBOM så är det säkerhetsmässigt mycket bra att veta exakt vilka beroenden som återfinnes i ett IT-system eller mjukvara. Vid sårbarheter såsom den i log4j går det snabbare och enklare att identifiera var sårbara bibliotek återfinnes.

syft

Dockers sbom-funktion bygger på open-source projektet Syft. Och följande paket stödjer docker sbom/syft att identifiera i containers:

  • Alpine (apk)
  • Dart (pubs)
  • Debian (dpkg)
  • Go (go.mod, Go binaries)
  • Java (jar, ear, war, par, sar)
  • JavaScript (npm, yarn)
  • Jenkins Plugins (jpi, hpi)
  • PHP (composer)
  • Python (wheel, egg, poetry, requirements.txt)
  • Red Hat (rpm)
  • Ruby (gem)
  • Rust (cargo.lock)

Och för att skapa själva rapporten så finns ett antal olika SBOM-format såsom spdx, cyclonedx, json och text. Jag testade att snabbt jämföra debian med alpine utan några extra paket och då såg det ut så här:

  • Alpine – 14 paket (apk)
  • Debian – 96 paket (deb)
  • Alma Linux – 153 paket (rpm)
  • Rocky Linux – 151 paket (rpm)

Och tittar vi på hur en text-rapport från alpine:latest ser ut som är skapad med hjälp av kommandot docker sbom alpine:latest

Syft v0.43.0
 ✔ Loaded image
 ✔ Parsed imag
 ✔ Cataloged packages      [14 packages]

NAME                    VERSION      TYPE
alpine-baselayout       3.2.0-r18    apk
alpine-keys             2.4-r1       apk
apk-tools               2.12.7-r3    apk
busybox                 1.34.1-r5    apk
ca-certificates-bundle  20211220-r0  apk
libc-utils              0.7.2-r3     apk
libcrypto1.1            1.1.1n-r0    apk
libretls                3.3.4-r3     apk
libssl1.1               1.1.1n-r0    apk
musl                    1.2.2-r7     apk
musl-utils              1.2.2-r7     apk
scanelf                 1.3.3-r0     apk
ssl_client              1.34.1-r5    apk
zlib                    1.2.12-r0    apk

Hjälptext för docker sbom:

Observera att docker sbom bara finns i Docker Desktop från version 4.7.0 än så länge. Men givetvis går syft att ladda hem och köra separat.

Underrättelseutmaning 22

Uppdatering: Nu finns det en discord länk för den som vill ställa frågor: https://discord.gg/gZF5yY5Pkr

De tre myndigheterna MUST, FRA och Säpo anordnar en CTF samt event på Armémuseumet. Du kan redan nu anmäla dig till CTF:en och eventet på undutmaning.se.

CTF står för Capture The Flag och är en typ av tävling där deltagaren ska försöka lösa utmaningar inom olika områden och hitta ”flaggor” för att bevisa att man klarat av utmaningen.

Det fysiska eventet går av stapeln på torsdag den 28:e april klockan 16-21 och CTF:en startar 2022-04-09 kl 08:00. Det finns även en tillhörande Discord-server för att ställa frågor.

Totalt finns det 24 st utmaningar och de områden som gäller för utmaningarna är bl.a. inom IT-forensikkrypto och programmering. Arrangörerna lovar att vissa av utmaningarna är riktigt svåra att lösa.

Eva Björkman som jobbar på Säpo berättar om denna CTF:

Genom denna gemensamma CTF lyfter vi inte bara upp den enorma kompetens som våra medarbetare har, utan vi ger också potentiella medarbetare en liten inblick i våra verksamheter.

Spring4Shell – Två nya sårbarheter i Spring

Två nya RCE:er har publicerats i java-ramverket Spring. Den ena sårbarheten går under namnet Spring4Shell och återfinnes i Spring Cloud Function SPEL:

  • CVE-2022-22963 – Spring Expression Resource Access Vulnerability

Exempel på anrop där sårbarheten utnyttjas:

curl -i -s -k -X $’POST’ -H $’Host: 192.168.1.2:8080′ -H $’spring.cloud.function.routing-expression:T(java.lang.Runtime).getRuntime().exec(\”touch /tmp/test”)’ –data-binary $’exploit_poc’ $’http://192.168.1.2:8080/functionRouter’

Att uppgradera till Spring Cloud Function 3.1.7 eller 3.2.3 löser problemet med den ena sårbarheten. Sårbarheten har fått en CVSS score på hela 9.0 av 10, vilket är mycket allvarligt.

Den andra RCE:n återfinnes i Spring Core. Och en PoC återfinnes på Github här bl.a. (obs kör på egen risk):

Enligt universitetet i peking så utnyttjas minst en av dessa sårbarheter aktivt:

All versions of JDK9 and above may be affected. Currently, this vulnerability has been exploited in the wild.

Och några mer uppdateringar:

The new Spring RCE (coined Spring4Shell) is as bad as it seems! It is a ClassLoader manipulation (no unsafe deserialization or jndi as I heard). It allows attackers to plant a webshell when running Spring MVC apps on top of JRE 9. Just a POST needed. No patch available yet.

Troligtvis uppstår problemet på grund av följande (källa)

Uppdatering: Kan vara så att jag blandat ihop dessa två, att Spring4Shell är den i Spring Core.

Gällande den ena sårbarheten utan CVE så är den relativt gammal och går under CVE-2010-1622.

Troligt intrång hos Okta

Molnleverantören Okta som tillhandahåller identitets- och åtkomsthantering har troligtvis blivit hackade av hackergruppen LAPSUS$. Intrånget genomfördes troligtvis ett hackat konto som anslöt via PaloAlto GlobalProtect som tillhandahåller VPN mot Okta. Tittar man också på skärmdumpar så framgår det att intrånget genomfördes i Januari 2022 och Lapsus själva hävdar att intrånget genomfördes för att man ville komma åt en kund till Okta.

Det framkommer även på skärmdumparna att Lapsus har eller har haft tillgång till flertalet tjänster hos Okta såsom: AWS, Okta Superuser, Zoom app, Okta Sales, Atlassian Cloud Jira & Confluence, Cornerstone (Okta learning portal), Gmail, Crayon och Splunk.

Att just detta intrång är extra intressant är för att många organisationer helt litar på Okta när det gäller identitets- och åtkomsthantering. Om just Er organisation använder Okta så bör ni genast genomföra en utredning huruvida ni har blivit påverkade av detta intrång. Vad har ni för möjlighet att genomföra threat hunting och incidentutredning?

Följande kommentar skrev Lapsus i deras Telegram-kanal:

Lapsus är en känd ransomware-grupp, som förutom Okta också på senare tid hävdat att dom hackat Microsoft Azure DevOps.

Microsoft patch-tisdag

Idag var det dags för Microsofts månatliga släpp gällande säkerhetspatchar. Det var ingen liten lista med patchar som släpptes idag med hela 71 st brister som åtgärdas. Sammanfattningsvis ser det ut enligt följande:

  • Microsoft Windows: 41 sårbarheter
  • Microsoft Office: 5 sårbarheter
  • Microsoft Exchange: 3 st sårbarheter

Och utöver ovan sårbarheter så har även följande brister åtgärdats:

  • CVE-2022-24502: Internet Explorer Security Feature Bypass Vulnerability
  • CVE-2022-24508: SMB Server Remote Code Execution Vulnerability
  • CVE-2022-24512: .NET and Visual Studio Remote Code Execution Vulnerability
  • CVE-2022-21990: Remote Desktop Client Remote Code Execution Vulnerability
  • CVE-2022-23277: Microsoft Exchange Server Remote Code Execution Vulnerability
  • CVE-2022-24459: Windows Fax and Scan Service Elevation of Privilege Vulnerability

Microsoft uppger att inget aktivt utnyttjande har detekterats av dessa brister ännu. Men det är troligtvis bara en tidsfråga innan bindiffandet börjar och exploits finns färdiga.

Mer information finnes du hos Microsoft här:

DirtyPipe – Ny allvarlig sårbarhet i Linux-kerneln

Dirtypipe - Ny allvarlig sårbarhet i Linux-kerneln

Uppdatering: Ny PoC-exploit vid namn dirtypipez från blasty som skriver över godtycklig suid-binär och sedan återställer den för att erhålla root.

Uppdatering 2: Denna sårbarhet gäller även containers. Se detta blogginlägg från Aquasec

Max Kellermann har identifierat en ny säkerhetsbrist i Linux-kerneln som medger att du kan skriva över godtycklig fil. Sårbarheten har fått CVE-2022-0847 och finns i alla Linux-kernels från version 5.8. Fixades i versionerna 5.16.11, 5.15.25 och 5.10.102. Även Android är drabbad av denna sårbarhet eftersom Android-baserade system använder sig av Linux-kerneln.

Även värt att notera så skriver Max följande:

To make this vulnerability more interesting, it not only works without write permissions, it also works with immutable files, on read-only btrfs snapshots and on read-only mounts (including CD-ROM mounts). That is because the page cache is always writable (by the kernel), and writing to a pipe never checks any permissions.

Vissa förutsättningar måste dock uppfyllas, men dessa är rätt enkla:

  • Angriparen måste ha läsrättigheter
  • Offset får inte vara på en page boundary
  • Skrivningen kan inte ske över en page boundary
  • Storleken på filen kan inte ändras

Demo på hur CVE-2022-0847 kan utnyttjas för att erhålla root på en Kali Linux-installation (privilege escalation). Detta är på en fullt patchad Kali:

Oklart dock huruvida detta fungerar med säkerhetshöjande lösningar såsom Apparmor, SELinux etc. Rekommenderar även att läsa Max intressanta write-up om hur han hittade buggen. Även finnes fungerande exploit här:

Observera att många operativsystem såsom Debian har under dagen idag måndag, åtgärdat buggen.