image

Securitybedrijf hekelt hype rondom laatste Log4j-kwetsbaarheid

woensdag 5 januari 2022, 11:14 door Redactie, 8 reacties

De laatste kwetsbaarheid in Log4j is meer hype dan inhoud, zo stelt securitybedrijf LunaSec. De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde.

Op 28 december publiceerde onderzoeker Yaniv Nizry van securitybedrijf Checkmarx een tweet waarin hij liet weten dat de meest recente versie van Log4j een kwetsbaarheid bevatte waardoor remote code execution mogelijk was en de Apache Foundation met een update zou komen. Het beveiligingslek, aangeduid als CVE-2021-44832, laat een aanvaller alleen op afstand code uitvoeren wanneer die toegang tot het Log4j-configuratiebestand heeft.

Een "onwaarschijnlijk scenario", stelt Chris Thompson van LunaSec. Al bij de bekendmaking van de details reageerden onderzoekers kritisch op het beveiligingslek. In een blogposting waarin Checkmarx de details beschreef stelde het securitybedrijf eerst dat het om een kritieke kwetsbaarheid ging, waarbij het beveiligingslek met een eerder kritiek Log4j-lek werd vergeleken.

Volgens Thompson is CVE-2021-44832 zo onbeduidend dat LunaSec heeft besloten om de eigen Log4j-scantool er niet naar te laten zoeken. "We hopen dat de focus blijft op het verhelpen van de meer kritieke kwetsbaarheden in eerdere versies." Checkmarx heeft inmiddels de blogposting aangepast, maar volgens Thompson wordt door het waarschuwen voor een nieuwe remote code execution kwetsbaarheid zonder verdere context te geven misbruik gemaakt van de angst en verwarring die mensen rond het Log4j-lek hebben.

Thompson stelt dat het oproepen van ontwikkelaars om te updaten alleen voor het updaten naar de laatste versie niet de oplossing is en kan leiden tot een scenario waarbij er steeds ten onrechte alarm wordt geslagen, wat het vertrouwen niet ten goede komt en uiteindelijk tot kwetsbare services en systemen kan leiden.

Image

Reacties (8)
05-01-2022, 11:49 door Anoniem
"De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
05-01-2022, 20:07 door Anoniem
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.
06-01-2022, 00:46 door Anoniem
Door Anoniem:
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.

Hoe bedoel je “horen niet”? Waar slaat dit op?
06-01-2022, 08:01 door Anoniem
Door Anoniem:
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.

Helaas zitten er altijd kwetsbaarheden in software. Iets dat gemaakt wordt door mensen, kan stukgemaakt worden door mensen. Fouten maakt iedereen.

Zie ook hoe men nog best regelmatig exploits weet te vinden in software dat al ruim een decennia in omloop is. Zoals in onderdelen van Linux en Windows.
06-01-2022, 08:57 door Anoniem
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Ondanks dat iemand moord en brand gilt behoor je dit nog steeds zelf af te wegen in hoeverre zo'n dreiging binnen jouw organisatie tot risico's kan leiden. Er komen veel high risks voorbij die in sommige gevallen alleen een high risk kunnen vormen als iemand daadwerkelijk een server heeft over kunnen nemen. In dat scenario heb je dan nog veel meer problemen dan alleen die ene high risk melding.
Log4j is eigenlijk wel een zegen want het drukt veel bedrijven met de neus op de feiten dat ze niet in control zijn en dus veel meer moeten doen. Ik vrees alleen dat er nog veel teveel bedrijven zijn die alleen maar kijken of ze kwetsbaar zijn voor Log4j en, als een scanner zegt van niet dat het dan weer business as usual is. Er zijn er zelfs bij die ver. 1.x nog gebruiken en daarmee stellen dat ze dus niet kwetsbaar zijn voor Log4j en dus veilig zijn. Tja, als je dergelijk eol spul draait dan moet je maar hopen dat er niemand anders uit een of ander wakkietakkie land over je schouder in je systemen aan het mee kijken is.
06-01-2022, 09:01 door Anoniem
Door Anoniem:
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.

Daarin heb je gelijk, maar in praktijk bestaat bugvrije software niet. De praktijk is risico van een kwetsbaarheid een optelsom van impact en waarschijnlijkheid.
De impact als een kwaadwillend iemand deze log4j kwetsbaarheid misbruikt is groot, maar de waarschijnlijkheid is laag omdat je eerste door andere lagen heen moet (toegang tot de server, schrijfrechten op het bestand). Dus opgeteld risico is gemiddeld. En de mate van publicatie moet daarop aangeast zijn.
06-01-2022, 09:22 door Anoniem
Door Anoniem:Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.

Denk dat dit iets te kort door de bocht is. Waar mensen werken worden fouten gemaakt en dus ook in de programmeerkant van IT. En iets wat x jaar geleden een goed idee was kan nu ineens onbedoelde bijwerkingen hebben. 100% Security (Veiligheid) bestaat immers niet, ook niet in software.
06-01-2022, 10:00 door Anoniem
Door Anoniem:
Door Anoniem: "De onderzoeker die het beveiligingslek ontdekte heeft inmiddels excuses gemaakt voor de manier waarop hij de kwetsbaarheid aankondigde."

Dat zouden meer onderzoekers moeten doen. En ook voor dat ze een of andere theoretische kwetsbaarheid melden
eerst eens nadenken hoe reeel dat allemaal is en of ze dit doen voor betere veiligheid of om hun eigen naam rond
te toeteren.
Hoe men het ook draait of keert: kwetsbaarheden horen niet in software te zitten. Punt uit.

Ik heb als onderzoeker ontdekt dat als je schrijftoegang hebt op /etc/shadow je de wachtwoorden van de gebruikers
kunt veranderen of leegmaken. Ik zal het de wereld over tweeten zodat iedereen weet dat ie kwetsbaar is.
Allemaal updaten mensen!
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.