OpenSSL is een veelgebruikte open-source softwarebibliotheek voor het implementeren van veilige communicatie via computernetwerken. Hoe veel gebruikt? De kans is groot dat als je ooit een HTTPS-webpagina hebt bezocht, je dit via een OpenSSL-codering hebt gedaan. De bibliotheek biedt cryptografische functies en protocollen voor gegevenscodering, decodering, authenticatie en verificatie van digitale handtekeningen. OpenSSL is bijna overal te vinden waar er behoefte is aan het beveiligen van webservers, e-mailservers, virtuele particuliere netwerken (VPN's) en andere vormen van netwerkcommunicatie.
Als we naar de bovenstaande paragraaf kijken, zou het duidelijk moeten zijn hoe belangrijk OpenSSL is voor de goede werking van het internet. Het is een cruciaal onderdeel van de beveiligingsinfrastructuur voor veel computersystemen en applicaties. Het helpt gevoelige gegevens te beschermen tegen ongeoorloofde toegang en helpt de integriteit en authenticiteit van netwerkcommunicatie te garanderen. Daarom nemen de beheerders van de bibliotheek kwetsbaarheden zeer serieus en proberen ze deze zo snel mogelijk te patchen. Het is bijna ondenkbaar dat aanvallers toegang zouden krijgen tot de beveiligde communicatielijnen van de World Wide Web-infrastructuur.
In dit artikel onderzoeken we de kwetsbaarheden die aanleiding gaven tot de OpenSSL-patch 3.0.7 in oktober 2022, en bekijken we wat we kunnen leren van de manier waarop de OpenSSL-beheerders het probleem hebben opgelost.
De kwetsbaarheden
Op 25 oktober 2022 publiceerde het OpenSSL Project een adviserend waarschuwing dat er binnenkort een nieuwe patch komt om sommige problemen op te lossen kritisch kwetsbaarheden. De 'kritieke' tag impliceert dat de kwetsbaarheden waarschijnlijk kunnen worden misbruikt en dat het stelen van privésleutels en/of RCE op getroffen servers waarschijnlijk is.
Een week later, op 1 november 2022, bracht het OpenSSL Project zowel de nieuwe patch, 3.0.7, als de specifieke kwetsbaarheden ze wilden het repareren. In de tussenliggende tijd is de beoordeling van de kwetsbaarheden verlaagd van kritiek naar ‘zeer ernstig’.
Wat zijn deze kwetsbaarheden?
CVE-2022-3602 – X.509 e-mailadres 4-byte bufferoverloop – Bij X.509-certificaatverificatie, met name bij het controleren van naambeperkingen, kan een bufferoverschrijding van vier bytes optreden. Vier door de aanvaller bestuurde bytes op de stapel kunnen worden overlopen door een aanvaller die een kwaadaardig e-mailadres gebruikt. Een crash (resulterend in een Denial of Service) of mogelijk uitvoering van externe code kan worden veroorzaakt door deze bufferoverloop. Aanvankelijk werd het als kritiek gecategoriseerd, maar uit aanvullende tests bleek dat veel platforms stack-overflow-beveiligingen gebruiken om het risico op uitvoering van code op afstand te verminderen.
CVE-2022-3786 – X.509-e-mailadres Bufferoverloop met variabele lengte – Bij X.509-certificaatverificatie, met name bij het controleren van naambeperkingen, kan een bufferoverloop optreden. Een aanvaller kan een kwaadaardig e-mailadres in een certificaat aanmaken om de stapel te vullen met een willekeurig aantal bytes dat het teken '.' bevat, wat het decimale getal 46 is. Er kan een crash optreden als gevolg van deze bufferoverloop (waardoor een dienstweigering).
Om maar te herhalen hoe ernstig deze kwetsbaarheid isies zijn, CISA, de Amerikaanse Cybersecurity en Infrastructure Security Agency, een vrijgegeven adviserend dezelfde dag als OpenSSL, encouragebruikers en beheerders de mogelijkheid bieden om de OpenSSL-documentatie en upgrade, indien van toepassing, naar de nieuwe patch 3.0.7.
Zoals eerder besproken zou RCE (executie van externe code) op besturingssystemen of mailservers met OpenSSL erg slecht zijn, dus is het logisch om alleen de kwetsbaarheden zodra een goede patch is gevonden en aangeboden.
Wat gebeurt er nu
Zodra het eerste advies werd gepubliceerd, begonnen mensen te klauteren. 'Geen paniek' was een veel voorkomende uitdrukking destijds waaruit blijkt hoe serieus mensen het nieuws namen dat OpenSSL van cruciaal belang heeft kwetsbaarheden.
Zodra het advies werd gepubliceerd, probeerden alle relevante belanghebbenden erachter te komen welke versie van OpenSSL werd gebruikt in hun server, besturingssysteem, applicatie, pakket, enz. Naast alleen intern OpenSSL-gebruik moesten mensen ook uitzoeken of een van hun derde partijleveranciers of serviceproviders gebruikten een kwetsbare OpenSSL-versie. Als u niet zeker wist welke versie u gebruikte, of als u niet zeker wist welke versie uw leveranciers en serviceproviders gebruikten, werd het destijds veiliger geacht een applicatie offline te halen in plaats van potentiële RCE te riskeren.
Omdat het adviesbureau vooraf de tijdlijn voor de patch gaf, kregen mensen de tijd om hun eigen infrastructuur en die van hun leveranciers en serviceproviders uit te zoeken. Het idee was om alles wat nodig was op het gebied van de infrastructuur zo te plannen dat zodra de patch uitkwam, de upgrade, indien nodig, kon plaatsvinden.
Hoe zou jij het aanpakken?
Laten we nu zeggen dat u een ingenieur bent in een bedrijf dat, voor zover u weet, OpenSSL op zijn servers gebruikt. Zodra het advies verdwijnt, moet u uitzoeken welke versie van de bibliotheek waar in gebruik is (inclusief eventuele verouderde code als deze nog steeds wordt uitgevoerd) en vervolgens hetzelfde bedenken voor al uw leveranciers of serviceproviders.
Dit is waar een SBOM zou echt van pas kunnen komen. Een SBOM staat voor een Software Bill Of Materials en is een lijst met alle componenten en softwareafhankelijkheden waaruit een bepaald softwareproduct bestaat. Een SBOM bevat doorgaans informatie zoals de namen en versies van alle softwarecomponenten (zie waar ik hiermee naartoe ga), hun bronnen en licenties, en alle bekende kwetsbaarheden of beveiligingsproblemen die aan elk onderdeel zijn gekoppeld.
Als u, als verantwoordelijke ingenieur die u bent, ervoor heeft gezorgd dat u over een bijgewerkte SBOM beschikt voor elk van uw producten, dan zou het vinden van waar u OpenSSL gebruikte en welke versie in gebruik was eenvoudigweg een kwestie zijn geweest van het uitvoeren van een zoekopdracht in het SBOM-bestand . Als u er ook voor had gezorgd dat u om bijgewerkte SBOM's vroeg bij een leverancier of dienstverlener waarmee uw bedrijf samenwerkte, had u daar ook dezelfde zoekopdracht kunnen uitvoeren.
Omdat u werd verteld dat de kwetsbaarheden alleen de versies tussen 3.0.0 en 3.0.6 troffen, hoeft u alleen maar te controleren welke versies u gebruikte om te weten welke applicaties moesten worden verwijderd of bijgewerkt met de nieuwe patch – 3.0.7. XNUMX.
Om te laten zien hoe uitgebreid de lijst met bekende besturingssystemen en bedrijfsapplicaties die OpenSSL gebruiken, kun je dit eens bekijken lijst gepubliceerd als een openbare dienst, zodat mensen weten hoe bezorgd ze zich moeten maken.
Hoe kan een op bewijzen gebaseerde beveiligingshub helpen?
Als onderdeel van het evoluerende cyberbeveiligingslandschap, dat zulke verstrekkende gevolgen heeft kwetsbaarheden, waar we momenteel getuige van zijn de evolutie van applicatiebeveiliging naar software supply chain-beveiliging. Er is een nieuwe generatie hulpmiddelen en technologieën ontwikkeld om deze problemen op te lossen. Door een op bewijs gebaseerd platform voor continue codebeveiliging aan te bieden dat kan instaan voor de betrouwbaarheid van de levenscyclus van softwareontwikkeling en softwarecomponenten, helpen geautomatiseerde tools en oplossingen organisaties bij het bereiken van een nieuw beveiligingsniveau. Door voortdurend afhankelijkheden en kwetsbaarheden in kaart te brengen, wordt het eenvoudiger om patches te herstellen of toe te passen zodra deze beschikbaar komen.
Schriftgeleerde is een Software Supply Chain Security-hub. Het verzamelt bewijs en presenteert dit voor elke build die door uw CI/CD-pijplijn gaat. Het doel van de oplossing van Scribe was om het gemakkelijker te maken om te voldoen aan de EU- en Amerikaanse regelgeving en best practices voor het vergroten van de softwaretransparantie en het bevorderen van vertrouwen tussen softwareontwikkelaars en gebruikers. Het platform maakt het mogelijk om uitgebreide SBOM’s en andere beveiligingsinzichten te creëren en te delen. Bovendien kan het platform bevestigen dat de build die u bekijkt, voldoet aan zowel het SSDF-framework van NIST als de SLSA niveau 3-vereisten. U hoeft niet langer te zoeken waar u welke versie van welke bibliotheek gebruikt, omdat u voor elk van uw builds een bewijsarchief met een SBOM heeft. Nu is het uitzoeken ervan net zo eenvoudig als het zoeken naar een bepaalde zin in een tekstdocument.
Een laatste woord: wees voorbereid op de volgende grote openbaarmaking van kwetsbaarheden
Het OpenSSL Project-verhaal van patch 3.0.7 biedt ons twee, even belangrijke, gezichtspunten over hoe om te gaan met potentieel kritieke kwetsbaarheden.
Van de getroffen kant – het bedrijf of project dat mogelijk door deze kwetsbaarheden is getroffen – hebben we transparantie geboden. Ze maken niet onmiddellijk informatie openbaar die schade kan veroorzaken, maar ze maken wel alles bekend zodra ze zich bewust zijn van een probleem. Niet alleen dat ze naast zoveel mogelijk informatie over het probleem ook een tijdlijn voor herstel bieden. Zodra er een patch of herstel bestond, waren ze niet verlegen om te onthullen wat er precies mis was en hoe dit mogelijk zou kunnen worden uitgebuit. Deze vorm van transparantie bevordert het vertrouwen. Gebruikers en klanten willen weten en voelen dat het bedrijf meer, of op zijn minst evenveel, om hen geeft als om de bedrijfsresultaten of de raad van bestuur.
In 2014 werd het OpenSSL-project het slachtoffer van een kritieke bug genaamd 'hartbloeding' – een kritieke fout in de TLS/DTLS-implementatie van OpenSSL die het voor een aanvaller mogelijk maakte om geheimen zoals coderingssleutelmateriaal, wachtwoorden en andere gevoelige informatie van getroffen servers te verkrijgen. Heartbleed liet zien wat een kritieke kwetsbaarheid in OpenSSL kan doen, aangezien deze een grote verscheidenheid aan programma's en Linux-distributies trof. Het proberen om elk kwetsbaar systeem te identificeren en te repareren bezorgde beveiligingsteams maandenlang hoofdpijn. Het implementeren van een tool, zoals een SBOM, waarmee u uw software sneller en eenvoudiger kunt updaten en patchen, zou een zegen zijn voor het cybersecurityteam van elk bedrijf.
Aan de kant van het herstel – precies weten waar u mee moet werken – welke versie van de pakketten u waar gebruikt, is essentieel om een dergelijke potentiële noodsituatie het hoofd te kunnen bieden. Als we Log4J als voorbeeld nemen: sommige bedrijven proberen er meer dan een jaar na de ontdekking nog steeds achter te komen of ze wel of niet door dit beveiligingslek zijn getroffen.
Het feit dat u zich niet alleen zorgen hoeft te maken over uw software en servers, maar ook over de externe leveranciers die u gebruikt, of de serviceproviders waarmee u samenwerkt, zelfs als u API-verbindingen gebruikt, betekent dat wij allemaal van ons, moeten echt een web van vertrouwen tussen ons opbouwen. Een dergelijk vertrouwen moet zoveel mogelijk afhankelijk zijn van hard bewijsmateriaal. Maak en volg uw eigen SBOM's en die van elk bedrijf waarmee u zaken doet, deel deze SBOM's en toon te goeder trouw bij het aankondigen en oplossen van eventuele exploiteerbare kwetsbaarheden waarvan u zich bewust wordt.
We zouden allemaal moeten samenwerken om een wereld te bereiken waarin het delen van dergelijk bewijsmateriaal net zo gewoon is als het delen van de nieuwste PR van het bedrijf op sociale media. Zonder dit vertrouwen bereiden we alleen maar het toneel voor voor de volgende grote kritieke kwetsbaarheid die de onderling verbonden infrastructuur zal afbreken waar we allemaal zo hard aan werken om deze te onderhouden.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
