Vragen en antwoorden Log4j-informatiesessie 15 december 2021

Kwetsbare systemen & software

• Zit Log4j alleen in Java-applicaties?
  Ja, Log4j staat voor Log for Java.
   
• Klopt het dat wanneer het softwarepakket geschreven is in een andere taal dan Java (bijvoorbeeld C of .Net), de kwetsbaarheid uit te sluiten is?
  Ja, het betreft alleen Java-based applicaties. 
   
• Kan deze kwetsbaarheid ook verstopt zitten dus ingebakken in software?
  Ja, een Java-applicatie maakt gebruik van Log4j als library. Deze kan mee worden gecompileerd in de JAR-file van de Java-applicatie.
   
• Als mijn organisatie geen Log4j in applicaties heeft, kan het dan toch nog geraakt worden door de Log4j van derden met wie we zaken doen?
  Dit is afhankelijk van de relatie die je hebt met de derde partij. Indien er koppelingen of afhankelijkheden zijn van deze derde partij, zou dit mogelijk kunnen zijn.
   
• Kan Log4j ook in IoT-apparaten of routers zitten?
  Ja, elk systeem dat gebruik maakt van de kwetsbare Log4j-versies en input van een gebruiker logt kan misbruikt worden. Dit kan een webserver zijn, maar dit kunnen ook andere applicaties zijn.
   
• 'Niet Internet Facing'-applicaties zouden ook ernstig risico lopen. Kunnen jullie hier meer over toelichten? Is het risico van dergelijke applicaties net zo ernstig?
  Zolang een kwaadwillende kan acteren met het systeem kunnen exploits uitgevoerd worden. De kans dat dit gebeurt, is kleiner omdat een kwaadwillende input moet kunnen leveren op de applicatie waarin Log4j gebruikt wordt. De impact bij misbruik is daarmee hetzelfde, maar de kans van misbruik is kleiner.
   
• Voor zover ik begrepen heb wordt de Log4j-module voornamelijk gebruikt in webservers en wordt via die ingang ook een aanval opgezet. Kan ik er vanuit gaan dat zolang er geen webserver draait er ook geen risico is?
  Nee, elk systeem dat gebruik maakt van de kwetsbare Log4j-versies en input van een gebruiker logt, kan misbruikt worden. Dit kan een webserver zijn, maar dit kunnen ook andere applicaties zijn (mits er ook daadwerkelijk gebruikersinput gelogd wordt).
   
• Kan ik als bedrijf/organisatie geraakt worden als ik een cloudapplicatie (die bij een leverancier draait) gebruik die kwetsbaar is voor Log4j?
  Wanneer je belangrijke informatie verwerkt in een kwetsbare cloudapplicatie loopt je informatie mogelijk ook risico.
   
• Zijn systemen van grote platformen ook geraakt zoals Apple, Google, etc. Ik zie deze niet terug in de GitHublijst.
  Wij hebben geen signalen hierover ontvangen tot dusver (20 dec) Op de GitHublijst staan ook enkele platformen, maar de lijst is niet compleet en niet alle platformen doen er uitspraken over.
   
• Er wordt over software gesproken, kan het ook in hardware zitten?
  Log4j is een Java library (software) voor het regelen van logging binnen Java-applicaties. Hardware dat niet gebruik maakt van software (en daarmee Log4j) is niet kwetsbaar.
   
• In hoeverre kunnen 'losse' systemen (bijvoorbeeld van thuiswerkers) geraakt worden en wat betekent dit dan voor onze netwerksecurity?
  Dit is geheel afhankelijk van hoe deze systemen zijn ingeregeld. Indien er een applicatie met een kwetsbare Log4j-versie op de systemen van een gebruiker (clientside) draait, is deze mogelijk uit te buiten.
   
• Is er een lijst van apparaten (applicances) met embedded java die de Log4j-kwetsbaarheid hebben? Op 'eigen' systemen kan ik zien wat er draait, op deze blackboxes niet en dat baart me zorgen.
  Het NCSC is bezig om een zo breed en actueel mogelijk beeld te verkrijgen van mogelijke gerelateerde kwetsbare software. Deze lijst is te vinden op GitHub. 
   
• Zijn er ook JAVA-apps op mobiele apparaten (waarvan we moeten uitgaan dat deze kwetsbaar zijn) en wordt er hier voor gewerkt aan een lijst. Is er anders hierover meer informatie te vinden?
  Het NCSC is bezig om een zo breed en actueel mogelijk beeld te verkrijgen van mogelijke gerelateerde kwetsbare software. Deze lijst is te vinden op GitHub.
   
• Kan de kwetsbaarheid ook in frameworks zoals Laravel zitten? Of zit dit meer in de serversoftware?
  Laravel is een PHP-based framework en maakt daarmee geen gebruik van Java. Log4j (Log for Java) is een logger van Java-based applicaties. Laravel is daarmee niet kwetsbaar voor deze kwetsbaarheid. De backend of andere software op de webserver kunnen echter wel kwetsbaar zijn indien deze gebruik maken van Log4j.
   
• Zijn alleen webapplicaties kwetsbaar (die draaien via een webserver)?
  Nee, elk systeem dat gebruik maakt van de kwetsbare Log4j-versies en input van een gebruiker logt, kan misbruikt worden. Dit kan een webserver zijn, maar dit kunnen ook andere applicaties zijn.
   
• Is er gevaar voor desktops en desktop applicaties die gebruik maken van Log4j?
  Er is een mogelijk risico. Gebruikers die input kunnen leveren die gelogd wordt door deze applicaties, kunnen deze applicaties en de systemen waarop dit draait misbruiken.
   
• Kan de Log4j-kwetsbaarheid ook plaatsvinden in de OT-omgeving?
  Ja, indien OT-omgevingen gebruik maken van Log4j, dan kunnen deze ook kwetsbaar zijn.

Detectie

• Hoe kunnen we erachter komen of er misbruik van het lek gemaakt is?
  Je kunt gebruik maken van de detectieregels die op GitHub gepubliceerd zijn om mogelijke pogingen tot misbruik te ontdekken. Ook kun je nog gebruik maken van verschillende tooling om systemen te checken op kwetsbare Log4j-versies. Het gebruik van Intrusion Detection Systemen (IDS) kan mogelijk ook helpen bij het detecteren van misbruik.
   
• Welke proactieve tools adviseren jullie?
  Op de GitHub zijn diverse tools opgenomen die kunnen ondersteunen. Individueel advies is hier niet mogelijk aangezien dit afhankelijk is van je omgeving en de doelstelling.
   
• Naast de detectietools die een systeem scannen vanaf het netwerk, is het ook mogelijk om op een systeem te zoeken naar bestanden die duiden op de aanwezigheid van Log4j? Ik heb gehoord dat het bepaalde .jar files zijn.
  Je kunt gebruik maken van verschillende tooling om systemen te checken op kwetsbare Log4j-versies. Het gebruik van Intrusion Detection Systemen (IDS) kan mogelijk ook helpen bij het detecteren van misbruik.
   
• Zijn er ook andere open source tooltjes die wijdverspreid gebruikt worden en in de nabije toekomst vergelijkbare problemen kunnen gaan geven?
  Op dit moment richten we ons op het mitigeren van de kwetsbaarheden in Log4j. Of en in welke mate er in de toekomst kwetsbaarheden in vergelijkbare software zit, is onbekend en niet te voorspellen.

• Is het zo dat als deze string op de machine binnenkomt, deze gelogd wordt en via binnenkomst op de logfile geactiveerd wordt?
  Zodra deze JDNI-string gelogd wordt met Log4j, wordt de JNDI-string geëvalueerd en uitgevoerd. Het wel of niet voorkomen van deze string in de logfile geeft geen duidelijk antwoord of je bent aangevallen of niet. In principe wordt de string geëvalueerd en het resultaat wordt weggeschreven naar het logbestand. Lees meer over dit gedrag. 

Misbruik

• Kunnen jullie wat meer zeggen over hoe deze kwetsbaarheid misbruikt kan worden en wat de mogelijke gevolgen kunnen zijn?
  De kwetsbaarheid maakt het mogelijk voor een ongeauthenticeerde kwaadwillende op afstand om willekeurige code uit te voeren met de rechten van de applicatie die gebruik maakt van Log4j. Het beveiligingsadvies van het NCSC bevat een tabel die in detail aangeeft hoe de inschatting tot stand is gekomen voor de schade die bij een succesvolle aanval kan ontstaan.
   
• Welke bedreigingen zijn er als iemand misbruik maakt van Log4j?
  In de kwetsbare software kan code worden uitgevoerd en kan een achterdeur worden ingebouwd waardoor aanvallers zich toegang kunnen verschaffen en programma's installeren of commando's kunnen uitvoeren. Dit kan worden misbruikt met verschillende motieven. Ransomware is op dit moment een realistisch scenario, deze aanvallers hebben financiële motieven. 
   
• In hoeverre kan dit gevolgen hebben voor kritieke sectoren? (zorg, nuts, veiligheid etc)
  De kwetsbaarheid van Log4j zit in veel systemen, ook in de systemen van de als vitaal aangewezen sectoren en/of organisaties. Het NCSC heeft hen direct geïnformeerd en deze sectoren treffen maatregelen om de kwetsbaarheid te mitigeren.
   
• Waar kun je misbruik melden?
  Misbruik kan worden gemeld bij cert@ncsc.nl. Meer informatie over in welke gevallen een verplichte melding plaats moet vinden, is te vinden op de factsheet Meldplicht bij het NCSC.
  Voor digitale dienstverleners geldt deze meldplicht.
  Het is ook mogelijk om vrijwillig te melden.
   
• Zien jullie al concreet misbruik plaatsvinden van deze kwetsbaarheid in NL? Scannen jullie hierop? Kan (moet) dit gemeld worden? 
  Er is misbruik van deze kwetsbaarheid geconstateerd, zowel binnen Nederland, als in het buitenland. Hierbij wordt bijvoorbeeld een achterdeur geïnstalleerd of malware uitgerold. Systemen kunnen zo misbruikt worden voor cryptomining of onderdeel worden van een botnet.
  Het NCSC, DTC en CSIRT-DSP hebben geen mandaat om vulnerabilty scans uit te voeren. DIVD, een vrijwilligersorganisatie van securityspecialisten, voert wel scans breed uit en waarschuwt ook organisaties. Wij onderhouden contacten met DIVD en zij dragen ook bij aan de GitHub.

Datalekken & privacy

• Gezien de kans op datalekken als gevolg van deze kwetsbaarheid, is de Autoriteit Persoonsgegevens (AP) betrokken?
  De meldplicht datalekken houdt in dat organisaties (zowel bedrijven als overheden) direct een melding moeten doen zodra zij een datalek hebben. Zij moeten dit melden bij de Autoriteit Persoonsgegevens (AP) en bij de individuen wie het betreft. Een datalek melden bij de AP kan via het Meldloket datalekken.

Incident respons

• Hoe kan ik het beste mijn data veilig stellen zodat ik altijd een kopie heb om snel weer operationeel te zijn na een ransomware hack?
  Het maken van een back-up is één van de maatregelen die je in algemene zin kunt nemen om weerbaarder te zijn en is dus verstandig voor het beveiligen van je (belangrijke) systemen. Voor meer informatie over back-ups kan je terecht bij de adviezen van het DTC en NCSC. Het hebben en periodiek testen van een back-up is een goede strategie voor het snel weer operationeel zijn na een hack en een ransomware-aanval. Lees wat je moet doen na een ransomware-aanval. Hoe kun je voorbereidingen treffen tegen een ransomware-aanval? Lees het Factsheet Ransomware van NCSC. Zie voor adviezen ter voorbereiding op ransomware de factsheet Ransomware van het NCSC.

Mitigatie

• Wat is het risico van updaten? Kan het niet zo zijn dat het update zorgt voor juist andere problematiek?
  Aan het uitvoeren van een update zijn altijd risico's verbonden. Het is mogelijk dat sommige applicaties anders reageren of niet kunnen samenwerken met een nieuwe versie van software. Voor details van de inhoud van een upgrade of patch, lees je de release notes of raadpleeg je ICT- of softwareleverancier.
   
• Kan ik Windows 10/11 gebruikers beschermen door ze de admin rechten te ontnemen? 
  Deze kwetsbaarheid is niet te mitigeren door gebruikers admin rechten te ontnemen. Wel is het beperken van rechten van gebruikers één van de maatregelen die je in algemene zin kunt nemen om weerbaarder te zijn en het is zinvol voor het beveiligen van je (belangrijke) systemen. Het is gebruikelijk om geen admin rechten te geven aan gewone gebruikers.

• Is het waar dat je om directe aanvallen te voorkomen, internetfacing applicaties als hoogst mitigerende maatregel dicht moet zetten en toegang tot diensten via de VPN moet laten lopen?
  We zien dat er scans worden uitgevoerd op het internet op zoek naar kwetsbare systemen. Mocht je om welke reden niet kunnen upgraden of maatregelen kunnen nemen ter voorkoming van misbruik, dan kan uitzetten de ultieme maatregel zijn. Wees je echter bewust dat ook niet aan het internet verbonden systemen kwetsbaar kunnen zijn en besteed ook daar aandacht aan.
   
• Worden er nog endpoint-security aangeraden (voor degene die dat nog niet hebben)?
  Endpoint security is één van de maatregelen die je kunt nemen om weerbaarder te zijn en is dus verstandig voor het beveiligen van al je apparatuur.
   
• In aanvulling op Zero-Trust, is 2FA beschermend in deze in combinatie met een kwetsbare Log4j VPN? Zou de Zero Trust methodologie hierin een uitkomst bieden?
  ​​​​Tweefactorauthenticatie (2FA) is één van de maatregelen die je in algemene zin kan nemen om weerbaarder te zijn en is dus verstandig voor het beveiligen van je (belangrijke) systemen. Zero Trust als concept kan ook helpen, echter het inrichten hiervan kost tijd en is niet direct toe te passen. Voor deze kwetsbaarheid is het vooral noodzakelijk om kwetsbare system op te sporen, de maatregelen te nemen zoals gedeeld door NCSC en door leveranciers en in de tussentijd te monitoren op verdachte situaties in je netwerk en systemen.

Andere doelgroepen

• Moet ik mij als consument ook zorgen maken? Ik maak gebruik van bijv. Netflix.
  Ook applicaties die door consumenten gebruikt worden kunnen kwetsbaar zijn. Ook voor consumenten geldt daarom het advies om zo spoedig mogelijk te updaten. Het maken van een back-up van data is verstandig. Lees meer over het updaten van slimme apparaten.
   
• Deze kwetsbaarheid kan impact hebben op de dienstverlening richting de burger op een grotere schaal (bijv. landelijke BRP) waardoor meer landelijke communicatie nodig is. Wordt er voor overheden (gemeenten) vanuit het NCSC ook voorzien in een 'jip en janneke' uitleg over deze kwetsbaarheid, al dan niet via de media? Of ligt dit bij de VGN/IBD of overheidsinstellingen zelf?
  Het NCSC heeft een centrale rol in de informatievoorziening rondom Log4j. Naast deze centrale informatie informeren meerdere partijen specifiek hun doelgroep. Speciaal voor gemeenten heeft de Informatie Beveiligings Dienst (IBD) handelingsperspectief uitgebracht.

Centraal informatiepunt NCSC GitHub

• Hoe kan ik informatie aan het NCSC aanleveren over aanvullende kwetsbare software?
  Er is een lijst met applicaties die kwetsbaar zijn als gevolg van de kwetsbaarheid in Log4j. Deze lijst is nog niet volledig. Aanvullingen op deze lijst zijn welkom via bijdragen in de NCSC GitHub.

• Klopt het dat de Nederlands lijst op GitHub de meest complete in de wereld is?
  De lijst op GitHub is zeer uitgebreid, maar niet compleet. Er wordt nationaal, maar ook internationaal, aan bijgedragen.
   
• Is die softwarelijst op GitHub niet handig voor hackers en daarmee ook een risico?
  Kwaadwillende kunnen deze informatie sowieso online vinden. Het risico is nu groter als men niet patched en mitigerende maatregelen treft.
   
• Kunnen kwaadwillenden ook updaten naar de GitHub? Wordt er gevalideerd?
  De GitHub is voor iedereen toegankelijk. Het NCSC valideert wat er wordt geüpload.

Blijf op de hoogte van de meest recente ontwikkelingen

Graag zetten we nog even op een rij waar je actuele informatie over de Log4j kwetsbaarheid kunt vinden:

• Informatie over te nemen maatregelen: NCSC Log4j
• Informatie over beveiligingsupdates, betrokken applicaties en IoC’s: NCSC Github
• Kennisdeling in cybersecurity forum en notificaties van updates ontvangen: DTC Community