image

Groot aantal applicaties getroffen door kritieke kwetsbaarheid in Log4j

zondag 12 december 2021, 20:32 door Redactie, 10 reacties

De kritieke kwetsbaarheid in logsoftware Log4j raakt een groot aantal applicaties, waaronder die van VMware, ElasticSearch, Red Hat, Atlassian, Amazon, Apache, Oracle en tal van andere programma's en leveranciers. Microsoft is bezig met een onderzoek en het Nationaal Cyber Security Centrum (NCSC) heeft inmiddels op GitHub een overzicht van kwetsbare Log4j-applicaties en te nemen stappen gepubliceerd. De lijst zal de komende dagen nog verder worden aangevuld, aangezien tal van applicaties van Apache Log4j gebruikmaken.

De impact van de kwetsbaarheid, aangeduid als CVE-2021-44228, is op een schaal van 1 tot en met 10 met een 10 beoordeeld. Log4j laat ontwikkelaars allerlei informatie binnen hun applicatie loggen. In bepaalde gevallen kan er data afkomstig van gebruikersinvoer worden gelogd. Een aanvaller kan via een speciaal geprepareerd request, dat door Log4j wordt gelogd, vervolgens via verschillende diensten, zoals het Lightweight Directory Access Protocol (LDAP), Secure LDAP (LDAPS), Remote Method Invocation (RMI) en Domain Name Service (DNS), kwaadaardige code op de server uitvoeren waarop Log4j draait.

"De kwetsbaarheid is wat complex: hoewel sommige producten kwetsbaar zijn, wil dit niet zeggen dat de kwetsbaarheid succesvol is te misbruiken aangezien dit afhankelijk is van verschillende pre- en postcondities, zoals de gebruikte Java virtual machine, de huidige configuratie, etc.", aldus het Zwitserse Government Computer Emergency Response Team (GovCERT.ch). De overheidsinstantie waarschuwt dat het Log4j-lek tegen de vitale infrastructuur kan worden ingezet, maar zijn hier nog geen meldingen over binnengekomen. Bij de huidige aanvallen is voor zover bekend alleen malware geïnstalleerd voor cryptomining en het uitvoeren van ddos-aanvallen.

Image

Reacties (10)
12-12-2021, 23:08 door Anoniem
Gelukkig is mijn rhel7 server niet kwetsbaar volgens redhat en ben ik blij dat ik nginx gebruik.
13-12-2021, 01:54 door Anoniem
Een 10. Dat is best wel hoog en dat voor server software. Maar gelukkig zijn er ook nog alternatieven voor dit fantastische product, zoals bv de webserver Hiawatha, maar kijk ook naar OpenBSD, waar ze nog steeds op versie 1 zitten van Apache ipv versie 2. Zeer waarschijnlijk zagen ze dit al lang aankomen. Het probleem is natuurlijk alle andere jongens die nog steeds niet willen leren van grove fouten zoals OpenSSL en Apache.
13-12-2021, 09:41 door _R0N_
2 reakties en beide slaan de plank mis.

Log in op je server en doe
sudo lsof|grep log4j

En kijk welke versie er actief is als deze er is.

Elasticsearch gebruikt het bijvoorbeeld ook en logstash stuurt de exploit code gewoon door naar ES.
Er is een hele waslijst aan software wat gebruik maakt van log4j en nee dat heeft niets te maken met Apache webserver behalve dat het door dezelfde stichting onderhouden wordt.
13-12-2021, 09:52 door Anoniem
Door Anoniem: Gelukkig is mijn rhel7 server niet kwetsbaar volgens redhat en ben ik blij dat ik nginx gebruik.
Alleen gaat het niet over de Apache-webserver, het gaat om een logcomponent voor Java-applicaties. Als die de backend van een webapplicatie vormen dan draaien die niet binnen het apache2-proces zelf maar in een apart proces, bijvoorbeeld op basis van Tomcat. En daar hoeft dan weer niet apache2 voor te zitten, dat kan ook nginx of iets anders zijn.

Als je dit al niet doorhebt, ondanks dat in het nieuws duidelijk wordt gemeld wat Log4j is en de informatie ook zonder dat makkelijk te vinden is, dan lukt het je kennelijk niet om te beoordelen of een kwetsbaarheid wel of niet op jou betrekking heeft. De conclusie dat je niet kwetsbaar bent trek je niet op basis van inzicht in wat hier gaande is. Als je inderdaad niet kwetsbaar bent dan heb je per ongeluk de goede conclusie getrokken.

Vraag jezelf eens ernstig af of je wel in huis hebt wat je nodig hebt om op een verantwoorde manier een webserver te draaien.
13-12-2021, 10:45 door Anoniem
Een handige URL van onze Nederlandse NCSC: https://github.com/NCSC-NL/log4shell/tree/main/software.

Het gaat dus verder dan alleen Apache, zoals hierboven ook al aangegeven.
13-12-2021, 12:56 door Anoniem
Door Anoniem: Een handige URL van onze Nederlandse NCSC: https://github.com/NCSC-NL/log4shell/tree/main/software.

Het gaat dus verder dan alleen Apache, zoals hierboven ook al aangegeven.

De lijst is nog niet volledig en moet aangevuld worden. Het NCSC roept bedrijven en instellingen op om aanvullende informatie te delen, bijvoorbeeld over de versie van Log4j die zij gebruiken.

https://nos.nl/artikel/2409263-internetwaakhond-deelt-lijst-met-software-die-kwetsbaar-is-voor-hackers
13-12-2021, 20:09 door karma4 - Bijgewerkt: 13-12-2021, 20:32
Door Anoniem: Een handige URL van onze Nederlandse NCSC: https://github.com/NCSC-NL/log4shell/tree/main/software.

Het gaat dus verder dan alleen Apache, zoals hierboven ook al aangegeven.
Dank je prima te gebruiken Wat al iemand gedaan heeft hoef je niet meer zelf te doen. Tijd gebruiken wat nog niet gedaan is. Ook wel typisch in de keten van de aanval maar lieft 5 punten om het te stoppen.
14-12-2021, 00:02 door Anoniem
[Er is een hele waslijst aan software wat gebruik maakt van log4j en nee dat heeft niets te maken met Apache webserver behalve dat het door dezelfde stichting onderhouden wordt.
Maar Apache maakt toch ook geweldige helicopters?
14-12-2021, 00:05 door Anoniem
Door Anoniem:
Door Anoniem: Gelukkig is mijn rhel7 server niet kwetsbaar volgens redhat en ben ik blij dat ik nginx gebruik.
Alleen gaat het niet over de Apache-webserver, het gaat om een logcomponent voor Java-applicaties. Als die de backend van een webapplicatie vormen dan draaien die niet binnen het apache2-proces zelf maar in een apart proces, bijvoorbeeld op basis van Tomcat. En daar hoeft dan weer niet apache2 voor te zitten, dat kan ook nginx of iets anders zijn.

Als je dit al niet doorhebt, ondanks dat in het nieuws duidelijk wordt gemeld wat Log4j is en de informatie ook zonder dat makkelijk te vinden is, dan lukt het je kennelijk niet om te beoordelen of een kwetsbaarheid wel of niet op jou betrekking heeft. De conclusie dat je niet kwetsbaar bent trek je niet op basis van inzicht in wat hier gaande is. Als je inderdaad niet kwetsbaar bent dan heb je per ongeluk de goede conclusie getrokken.

Vraag jezelf eens ernstig af of je wel in huis hebt wat je nodig hebt om op een verantwoorde manier een webserver te draaien.
Nee het gaat niet over de Apache webserver maar wel over Apache log4j logging. De default rhel server zelf is inderdaad niet kwetsbaar. Biedt alleen een service aan een (java log) applicatie die als een user proces draait. Dat proces heeft geen root of admin rechten. Hoezo kan dit leiden tot execute arbitrary code met niveau critical?
14-12-2021, 11:19 door [Account Verwijderd]
Door Anoniem:
Door Anoniem: Gelukkig is mijn rhel7 server niet kwetsbaar volgens redhat en ben ik blij dat ik nginx gebruik.
Alleen gaat het niet over de Apache-webserver, het gaat om een logcomponent voor Java-applicaties. Als die de backend van een webapplicatie vormen dan draaien die niet binnen het apache2-proces zelf maar in een apart proces, bijvoorbeeld op basis van Tomcat. En daar hoeft dan weer niet apache2 voor te zitten, dat kan ook nginx of iets anders zijn. ...

Inderdaad en dat gejammer over de webserver Hijawatta of zoiets die ook gebruikt kan worden slaat al helemaal nergens op. De getroffen omgeving is Java EE en de webserver is maar een klein onderdeeltje daarvan, wat er in dit geval ook nog helemaal los van staat ook. Je moet natuurlijk een webserver hebben die als applicatieserver dienst kan doen (waardoor 'Hiawatha' sowieso al afvalt dus houd op met dat ding hier te spammen) maar het probleem zit in een logging bibliotheek.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.