Skip to main content

    OpenSSL v3.x sårbarhet

    HVA:

    Biblioteket Open SSL v3.x [1] som blir brukt for å håndtere kryptering og til å sikre kommunikasjon må oppdateres til minimum v3.0.7 for å lukke en Kritisk sårbarhet.

    REFERANSER:

    OpenSSL teamet publiserte 25. oktober et forvarsel [2] om at versjon 3.0.7 vil bli publisert tidlig morgen (Eastern Time) tirsdag 1. november 2022.

    I dag 1. november har de lagt ut informasjon om CVE-2022-3786 [9] og CVE-2022-3602 [10], begge sårbarhetene er vurdert som High / Viktig - altså er de nedgradert fra Critical / Kritisk som ble varslet på forhånd!

    NÅR:

    Versjonene som kan misbrukes er alle 3.x versjoner fra v3.0.0 (sept 2021) til og med v3.0.6 (oktober 2022). [3]

    Ny versjon 3.0.7 ble gjort tilgjengelig 1. november 2022 [4], se informasjon om oppdatering som er publisert  [8].  

    HVOR:

    Slike bibliotek blir tatt inn i mange verktøy, både open source og proprietære. Slik inkludering bør og skal være deklarert som del av lisens og / eller produktdokumentasjon men biblioteket vil typisk ikke være del av software inventory og vil ofte ikke bli oppdatert før løsningen biblioteket er brukt i publiserer ny versjon. 

    På grunn av dette blir en nødt til å gjøre en manuell kartlegging av hvor biblioteket kan være brukt i miljøet. Husk at det kan være en del av alt fra lokalt installert programvare / Private Cloud løsning til Public Cloud og SaaS tjenester.

    Selv om en har kartlagt hvor slike bibliotek har vært brukt tidligere må en være forberedt på at andre applikasjoner / tjenester / komponenter kan være berørt denne gang.

    Merk at 

    • NCSC-NL har sammen med en gruppe frivillige  en oversikt de oppdaterer kontinuerlig, den peker blant annet på at mange Linux distribusjoner er berørt og må oppdateres. [5]
    • mange produkt vil ikke være berørt fordi de enda ikke har oppdatert til v3.x.
    • en oppdatering til v1.1.1 kom samtidig med v3.0.7, men denne skal ikke inneholde en sikkerhetsoppdatering

    HVA KAN SKJE:

    Oppdatert: Nå som vi har fått publiseringen fra OpenSSL teamet [6] ser vi at kritikalitet er endret fra Critical til High, dette da det antas å være vanskelig å utnytte sårbarheten.

    De to identifiserte sårbarhetene går ut på at OpenSSL kan bli påvirket (buffer overflow) av et sertifikat som er konfigurert med ekstra tegn i ett av feltene.

    Merk også at det potensielt farlige innholdet i sertifikatet kun blir behandlet dersom 

    1. sertifikatet er signert av en offisiell sertifikatutsteder
      eller
    2. dersom sjekk av sertifikatkjeden ikke blir utført av klient / server 

    SANNSYNLIGHET 

    Oppdatert:  Vi visste fra før at mange tjenester og programvarepakker ikke er berørt da de fortsatt ikke har tatt i bruk v3.x av OpenSSL.  Muligheten for å presentere et modifisert sertifikat til klienter er mindre sannsynlig da f.eks. Windows klienter og servere ikke bruker OpenSSL biblioteket. Og servere er kun sårbare dersom de ber om klientsertifikat.

    Det fremstår derfor som lite sannsynlig at denne sårbarheten krever annen behandling enn nevnt under, at en følger med på oppdateringer fra leverandører og installerer disse som del av vanlig oppdateringsrutine.

    HVA BØR DU GJØRE:

    NB: Merk at de som abonnerer på kritisk varsling fra oss ikke vil få nye varsling på e-post når vi oppdaterer vurderingene - sjekk innom siden regelmessig utover kvelden og utover i uken.

    Netsecurity's anbefaling er å jobbe med å identifisere omfang / potensiale. Se også råd fra Nasjonal Sikkerhetsmyndighet (NSM) [7] som vil bli oppdatert.


    Prepare – Identifiser komponenter / programvare / tjenester som er berørt
    • Besøk leverandørenes nettsider for å se om de har vurdert og evt. håndtert OpenSSL 3.x sårbarhet

      • Eksempel: VMware sin vurdering som pågår [11]
    • Be evt leverandør om å bekrefte status på håndtering

    Identify – Sjekke om svakheten allerede har blitt utnyttet.
    • Ett eksempel er å se etter bakdører som kan ha blitt installert av en angriper for å beholde fotfestet selv om sårbarheten skulle bli håndtert
     Containment - blokkering
    • Kreve autentisering og muligens også VPN før en får tilgang til berørte applikasjoner
    • Aktivere regler som gjenkjenner og stanser forsøk på å utnytte svakhet
    Eradication – oppdage / fjerne komponenter
    • Flere leverandører av sikkerhetsprodukter vil kunne gjenkjenne og forsøke å fjerne komponenter som blir installert av angriper
    • Vurder å bygge opp fra mal og sikkerhetskopi for å være sikker på at alle endringer angriper kan ha gjort er fjernet, pass på å fjerne sårbarhet før publisering
    Recovery - gjenopprett til normal tilstand

    Her antatt å gå fra tilstand SÅRBAR til BESKYTTET. Det vil være behov for flere aktiviteter dersom en avdekker at kompromittering har skjedd

    • Snarest mulig: Oppdater berørte komponenter der dere har ansvar for dette selv
    • Følg opp leverandører
    Lessons learned – bruk denne hendelsen til å dokumentere og forbedre
    • Scenario i beredskapsplan;
      Sårbarhet i programvare / komponenter som er del av Supply Chain.
    • Katalog / inventory over programvare og komponenter.
      Husk å dokumentere systemansvarlige
    • Rutine for å oppdatere komponenter. En hovedregel er å være oppdatert rimelig raskt, teste på en relevant gruppe før oppdatering publiseres til alle og ha plan for å rulle tilbake ved feil
      • Noen har aldri oppdatert til sårbar versjon (3.x i september 2021) og kan denne gang være fornøyd med at de ikke er på "bleeding edge" når det gjelder oppdateringer. 

    KONTAKT MED NETSECURITY:

    Ta gjerne kontakt med din kontaktperson i Netsecurity for mer informasjon og assistanse, se https://www.netsecurity.no/under-angrep. Vi kan bistå med å verifisere om du er sårbar eller allerede har blitt utsatt for angrep. Vi kan også gi råd / teknisk assistanse for å sikre din infrastruktur.

    KILDER:

    [1] OpenSSL hovedside; https://www.openssl.org/ 

    [2] Forvarsel om kritisk oppdatering; https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html 

    [3] OpenSSL versjoner publisert på GitHub; https://github.com/openssl/openssl/tags 

    [4] OpenSSL v3.0.7 nedlasting (når tilgjengelig) - merk at det ofte vil være leverandør av programvare / tjeneste som leverer ny versjon med oppdaterte komponenter; https://github.com/openssl/openssl/tags 

    [5] Oversikt over software / tjenester som bruker OpenSSL, oppdateres av NCSC-NL m/frivillige;https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md (Tips fra
    Kevin Beaumont aka @GossiTheDog)

    [6] Liste over sårbarheter i OpenSSL v3.0; https://www.openssl.org/news/vulnerabilities-3.0.html 

    [7] Nasjonal sikkerhetsmyndighet – NCSC, forvarsel;https://nsm.no/fagomrader/digital-sikkerhet/nasjonalt-cybersikkerhetssenter/varsler-fra-ncsc/forvarsel-kritisk-sarbarhet-i-openssl-3-x 

    [8] Varsling om at 3.0.7 er publisert; https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html 

    [9] CVE-2022-3786; https://www.openssl.org/news/vulnerabilities.html#CVE-2022-3786

    [10] CVE-2022-3602; https://www.openssl.org/news/vulnerabilities.html#CVE-2022-3602 

    [11] VMware vurdering (under utarbeidelse); https://blogs.vmware.com/security/2022/11/vmware-response-to-cve-2022-3602-and-cve-2022-3786-vulnerabilities-in-openssl-3-0-x.html 

    Endringslogg:

    1-Nov-2022 13.00: Første versjon publisert.

    1-Nov-2022 13.05: Rettet informasjon om kilde til ressurs [5].

    1-Nov-2022 16.50: Lenke til publisert oppdatering

    1-Nov-2022 17.00: Informasjon om CVE nummer

    1-Nov-2022 17.20: Informasjon om endring kritikalitet og leverandørlenker

    1-Nov-2022 17.55: Oppdatert Hva Kan Skje og Sannsynlighet med vår vurdering

    Oslo

    Drammensveien 288

    0283 Oslo

     

    Bergen

    Sandviksbodene 1

    5035 Bergen

    Stavanger

    Kanalsletta 4

    4033 Stavanger

    Grimstad

    Bark Silas vei 5

    4876 Grimstad

    Kristiansand

    Dronningens gt 12

    4610 Kristiansand

    Stockholm

    Kammakargatan 22

    111 40 Stockholm