image

Nieuwe Log4j-kwetsbaarheid veel ernstiger dan eerst gedacht

vrijdag 17 december 2021, 12:53 door Redactie, 28 reacties

Een nieuwe kwetsbaarheid in Apache Log4j die deze week werd gevonden is veel ernstiger dan eerst werd gedacht. In eerste instantie leek het erop dat het beveiligingslek, aangeduid als CVE-2021-45046, alleen een denial of service (dos)-aanval mogelijk maakt. Nu blijkt dat remote code execution tot de mogelijkheden behoort, waardoor een aanvaller in bepaalde gevallen kwetsbare servers kan overnemen.

Vorige week werd er werreldwijd gewaarschuwd voor een kritiek beveiligingslek in Log4j, dat inmiddels bekendstaat als Log4Shell en CVE-2021-44228. De impact van dit beveiligingslek werd op een schaal van 1 tot en met 10 met een 10.0 beoordeeld en werd verholpen met Log4j versie 2.15.0. Een aantal dagen later bleek dat deze versie het beveiligingslek CVE-2021-45046 bevatte. In bepaalde gevallen maakt dit het lek mogelijk voor aanvallers om een dos-aanval uit te voeren. De impact van deze kwetsbaarheid, verholpen in Log4j 2.16.0, is veel kleiner en werd beoordeeld met een 3.7.

De impactscore is vandaag echter aangepast naar een 9.0, omdat in bepaalde niet-standaard configuraties remote code execution mogelijk is. Het grote beveiligingslek in Log4j van vorige week werd veroorzaakt doordat een aanvaller de logsoftware door middel van een message lookup kwaadaardige code kon laten downloaden en uitvoeren.

Om dit te voorkomen werden in Log4j 2.15.0 remote verbindingen in message lookups, bijvoorbeeld een verbinding naar een server van de aanvaller, geblokkeerd. Verder werden message lookups standaard uitgeschakeld. Onderzoekers hebben nu ontdekt dat op andere plekken in de code van Log4j message lookups nog steeds mogelijk zijn, meldt securitybedrijf Lunasec. Daardoor kan een aanvaller kwetsbare servers nog steeds kwaadaardige code laten uitvoeren. Organisaties wordt dan ook aangeraden om te updaten naar versie 2.16.0.

Image

Reacties (28)
17-12-2021, 13:39 door Anoniem
Nieuwe Log4j-kwetsbaarheid...

Kunnen inmiddels beginnen met Log4Shell Alfa, Log4Shell Beta....
17-12-2021, 14:04 door Coritchando
Zoals altijd, als er in bepaalde software een serieus lek wordt ontdekt dan ligt deze software de eerste weken onder een vergrootglas. Vaak is de eerste fix ook niet toereikend, vaak zien we dan een pleister die later vervangen wordt door een structurele oplossing.

Volgende week weer wat te doen voor veel beheerders, maar belangrijk is dat dit enkel in "bepaalde niet-standaard configuraties" voorkomt. Een stuk minder aanvalsvectoren dus.
17-12-2021, 14:25 door Anoniem
Log4j: the gift that keeps on giving :-)
17-12-2021, 14:26 door Anoniem
Door Anoniem:
Kunnen inmiddels beginnen met Log4Shell Alfa, Log4Shell Beta....
Waarom niet gelijk door naar Log4Shell Delta en Log4Shell Omikron?

Ik zei het al, nu komt een brak stuk code onder de aandacht van de hackers en blijkt het ene na het andere probleem.
Als log4j uitgemolken is zullen de andere modules van Tomcat wel onder de aandacht komen. En dat zijn er nogal wat.
17-12-2021, 14:46 door Anoniem
Waarschijnlijk al honderduizenden backdoors geplaatst. Gaat een hete kerst worden. Maandagochtend 27 december vele confrontaties met randsomeware.
17-12-2021, 15:14 door Anoniem
Maar goed dat het open source is. Nu wordt het door heel veel beveiligingsmensen bekeken en gefixt. Dat gaat een stuk sneller dan bij closed source.
Nu blijkt dat remote code execution tot de mogelijkheden behoort, waardoor een aanvaller in bepaalde gevallen kwetsbare servers kan overnemen.
Dat lijkt mij niet want die code draait onder Linux niet als root maar als een gebruiker met verder weinig rechten. Onder windows weet ik niet. Ik weet wel dat veel IIS plugins gewoon met admin rechten draait.
17-12-2021, 15:22 door [Account Verwijderd]
Door Anoniem:
Door Anoniem:
Kunnen inmiddels beginnen met Log4Shell Alfa, Log4Shell Beta....
Waarom niet gelijk door naar Log4Shell Delta en Log4Shell Omikron?

Ik zei het al, nu komt een brak stuk code onder de aandacht van de hackers en blijkt het ene na het andere probleem.
Als log4j uitgemolken is zullen de andere modules van Tomcat wel onder de aandacht komen. En dat zijn er nogal wat.

Hoe kom je erbij dat log4j 'brakke' software zou zijn? En dat rare verhaal over andere 'modules' van Tomcat? Weet je eigenlijk wel wat log4j is (hint: het is geen 'module'). Het is echt geen gevalletje consumentensoftware in lichte consumententoepassingen, waarover we zo vaak (bijna 100% van de voorvallen) lezen op security.nl,

Door Anoniem: Waarschijnlijk al honderduizenden backdoors geplaatst. Gaat een hete kerst worden. Maandagochtend 27 december vele confrontaties met randsomeware.

Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware').

Wat er in al deze scriptkiddiepaniek staat te gebeuren is dat de scriptkiddies van de echte beheerders gescheiden gaan worden.
17-12-2021, 16:15 door Anoniem
Door Anoniem: Maar goed dat het open source is. Nu wordt het door heel veel beveiligingsmensen bekeken en gefixt. Dat gaat een stuk sneller dan bij closed source.
Ook wel goed om even te constateren dat open source niet tegen houdt dat afgrijselijke blunders zoals het expanderen van macro's in extern aangeleverde data (zeg maar het kaliber SQL statements samenstellen uit form data) gewoon in een module kunnen worden ingebouwd (zat er in versie 1 niet in, is in versie 2 ingebouwd) zonder dat er mensen op de rem trappen en dat soort kolder naar de bittenbak verwijzen!
17-12-2021, 16:52 door Anoniem
Door Toje Fos:

Hoe kom je erbij dat log4j 'brakke' software zou zijn? En dat rare verhaal over andere 'modules' van Tomcat? Weet je eigenlijk wel wat log4j is (hint: het is geen 'module'). Het is echt geen gevalletje consumentensoftware in lichte consumententoepassingen, waarover we zo vaak (bijna 100% van de voorvallen) lezen op security.nl,

Nee, het is inderdaad geen gevalletje consumentensoftware. Het is een hobbyprojectje van zes ontwikkelaars dat door tientallen bedrijven in hun software is opgenomen omdat het handig en gratis is. Die zitten nu op de blaren. Net als die 6 hobbyisten die nu vele onbetaalde overuren moeten maken. Dat is het mooie van FOSS. Het is gratis. Maar helaas; There ain't no such thing as a free lunch.
17-12-2021, 16:59 door Anoniem
Door Toje Fos:
Wat er in al deze scriptkiddiepaniek staat te gebeuren is dat de scriptkiddies van de echte beheerders gescheiden gaan worden.

Waren die al niet gescheiden? Ik mag hopen van wel.
Er komt echt wel wat aan https://www.bleepingcomputer.com/news/security/new-ransomware-now-being-deployed-in-log4shell-attacks/
17-12-2021, 17:23 door Anoniem
T valt wel mee, speciale omstandigheden, 2 niet standaard configuraties en alleen op een Mac OS. Dus geen paniek mensen. Sowieso upgraden uiteraard, maar deze is niet direct dodelijk voor iedere organisatie.
17-12-2021, 17:35 door Anoniem
Door Toje Fos: Hoe kom je erbij dat log4j 'brakke' software zou zijn?
Andere anoniem hier.

Ik heb zojuist de source repository gekloond om een idee te krijgen hoeveel Java-code dit eigenlijk is:

$ git clone https://github.com/apache/logging-log4j2.git
$ cd logging-log4j2
$ find -name '*.java' -print0 | xargs -0 wc -l | grep total
150459 total
146501 total
$ $ find -name '*.java' | wc -l
2301

Dat zijn 296.960 regels broncode in 2.301 .java-bestanden. Ik heb steekproefsgewijs wat sources bekeken. Die zien er op het oog kort en netjes uit, al valt me op dat er buiten het licentieblok voorin elke source geen letter commentaar in staat.

Maar een kleine 300.000 regels code voor een logcomponent? Wat doet dat in vredesnaam allemaal? Logging is toch in de basis een behoorlijk simpele actie. Mijn eerste indruk is dat log4j vreselijke bloatware is, en dat het ontiegelijk veel een applicatie binnen sleept dat die applicatie vermoedelijk helemaal niet nodig heeft.

Een mogelijke reden die bij mij opkomt voor log4j om zo enorm te zijn is dat het in zo'n beetje elke denkbare omgeving in te passen is, omdat het alles ondersteunt wat je maar tegen kan komen qua logging-infrastructuur. Dan zou je hopen dat ze het het zo hebben opgezet dat alleen de onderdelen geïnstalleerd worden die ook werkelijk gebruikt worden. De kwetsbaarheden die nu aan het licht zijn gekomen doen vermoeden dat het niet zo in elkaar zit. Als dit beeld klopt zie ik dat als een ontwerpfout, die veiligheidsrisico's met zich meebrengt. Dat los je niet op met netjes programmeren maar met een wezenlijk andere opzet.

Trouwens, hoe moet een gebruiker van deze component de kwaliteit ervan beoordelen? Even in 2.300 sources met 300.000 regels code zonder verklarend commentaar overzien dat het goed zit? Ga er maar aanstaan. Het voordeel dat open source in dit opzicht kan hebben wordt zo niet waargemaakt. Ik denk dat het problematisch is als de logcomponent alleen al groter is dan de gebruikende applicatie, en ik denk dat dat vaak genoeg zal voorkomen.

Dit is geen probleem dat specifiek is voor open source, er is in het algemeen een sterke neiging om elk wiel dat al elders is uitgevonden niet zelf nog eens uit te gaan vinden, én om gaan voor componenten die geweldig veel kunnen. Maar als je kijkt hoeveel meer je dan binnenhaalt dan je nodig hebt wordt het heel twijfelachtig om zoiets in te zetten. Je haalt namelijk ook de problemen binnen die erin zitten.
17-12-2021, 17:46 door karma4
Door Anoniem:
Door Anoniem: Maar goed dat het open source is. Nu wordt het door heel veel beveiligingsmensen bekeken en gefixt. Dat gaat een stuk sneller dan bij closed source.
Ook wel goed om even te constateren dat open source niet tegen houdt dat afgrijselijke blunders zoals het expanderen van macro's in extern aangeleverde data (zeg maar het kaliber SQL statements samenstellen uit form data) gewoon in een module kunnen worden ingebouwd (zat er in versie 1 niet in, is in versie 2 ingebouwd) zonder dat er mensen op de rem trappen en dat soort kolder naar de bittenbak verwijzen!

Je beschrijft het probleem van een ontwerp fout. Gescheiden segmenten met niet door direct gekoppelde programmatuur doorgeven van informatie. Het is kostbaarder stelt meer technische eisen maar is wel veiliger.
De aloude keus van snel resultaat vs kwaliteit.
17-12-2021, 18:18 door karma4
Door Toje Fos: Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware'). .. .
Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.
Randsomware lijkt me een prima woord. Random wat bij elkaar graaien, de gevolgen met een ransom. Prima aanduiding
17-12-2021, 18:38 door Anoniem
Door karma4:
Door Toje Fos: Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware'). .. .
Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.
Randsomware lijkt me een prima woord. Random wat bij elkaar graaien, de gevolgen met een ransom. Prima aanduiding

Hier gaat de hele ransomeware industrie op duiken. Beetje naief te denken dat dit alleen iets voor scriptkiddies is.
https://www.zdnet.com/article/log4j-flaw-this-new-threat-is-going-to-affect-cybersecurity-for-a-long-time/
17-12-2021, 20:08 door Anoniem
Door Anoniem:
Door Anoniem: Maar goed dat het open source is. Nu wordt het door heel veel beveiligingsmensen bekeken en gefixt. Dat gaat een stuk sneller dan bij closed source.
Ook wel goed om even te constateren dat open source niet tegen houdt dat afgrijselijke blunders zoals het expanderen van macro's in extern aangeleverde data (zeg maar het kaliber SQL statements samenstellen uit form data) gewoon in een module kunnen worden ingebouwd (zat er in versie 1 niet in, is in versie 2 ingebouwd) zonder dat er mensen op de rem trappen en dat soort kolder naar de bittenbak verwijzen!
Dat is het doel van open source helemaal niet maar genoeg eyeballs fixen elk probleem snel omdat de source beschikbaar is. Dat is nu ook het geval en misschien gaat men inzien dat er meer eyeballs nodig zijn bij dit soort software. Zo ging het met openssl ook.
17-12-2021, 21:31 door Anoniem
Door Anoniem: T valt wel mee, speciale omstandigheden, 2 niet standaard configuraties en alleen op een Mac OS. Dus geen paniek mensen. Sowieso upgraden uiteraard, maar deze is niet direct dodelijk voor iedere organisatie.

Tuurlijk. Slaap rustig verder.
https://www.bleepingcomputer.com/news/security/log4j-vulnerability-now-used-by-state-backed-hackers-access-brokers/
17-12-2021, 23:35 door Anoniem
Door karma4:
Door Toje Fos: Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware'). .. .
Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.

Wat opmerkelijk is, is dat Microsoft in een waaier van applicaties, en in hun Azure cloud, Log4j heeft gebruikt, maar dat de techreus blijkbaar nooit de moeite heeft genomen om de Log4j code eerder aan een grondige audit te onderwerpen. Men zou mogen veronderstellen dat zo'n gigant over voldoende middelen en mensen beschikt om zo'n klus zelf te klaren.

https://www.security.nl/posting/734616/Microsoft+waarschuwt+voor+Log4j-kwetsbaarheid+in+eigen+software
17-12-2021, 23:46 door Anoniem
Door Anoniem:
Door Toje Fos:

Hoe kom je erbij dat log4j 'brakke' software zou zijn? En dat rare verhaal over andere 'modules' van Tomcat? Weet je eigenlijk wel wat log4j is (hint: het is geen 'module'). Het is echt geen gevalletje consumentensoftware in lichte consumententoepassingen, waarover we zo vaak (bijna 100% van de voorvallen) lezen op security.nl,

Nee, het is inderdaad geen gevalletje consumentensoftware. Het is een hobbyprojectje van zes ontwikkelaars dat door tientallen bedrijven in hun software is opgenomen omdat het handig en gratis is. Die zitten nu op de blaren. Net als die 6 hobbyisten die nu vele onbetaalde overuren moeten maken. Dat is het mooie van FOSS. Het is gratis. Maar helaas; There ain't no such thing as a free lunch.
Daar heb je er weer een die het niet heeft begrepen. Het gaat niet om een gratis lunch of bier maar om vrijheid. Het recht om code te bestuderen (wat nu heel belangrijk is) het te mogen aanpassen (waar velen op hebben gewacht) en te copieren etc.
Daarnaast is het snel gefixt door een paar hobbyisten zoals jij het noemt. Kunnen Citrix, Microsoft (exchange en printspooler), etc nog een puntje aan zuigen. Microsoft zal deze software niet hebben opgenomen in haar producten omdat het gratis of handig was.
17-12-2021, 23:51 door Anoniem
Door Anoniem:
Door Anoniem: T valt wel mee, speciale omstandigheden, 2 niet standaard configuraties en alleen op een Mac OS. Dus geen paniek mensen. Sowieso upgraden uiteraard, maar deze is niet direct dodelijk voor iedere organisatie.

Tuurlijk. Slaap rustig verder.
https://www.bleepingcomputer.com/news/security/log4j-vulnerability-now-used-by-state-backed-hackers-access-brokers/
Ja ik slaap rustig verder. Mijn systemen worden niet versleuteld. Wat klanten zelf installeren als gebruiker moeten ze zelf weten. IK weet wel dat het Windows ecosysteem er het meest last van heeft omdat die per default closed source producten kopen waar dit in zit verwerkt zonder dat ze er weet van hebben.
18-12-2021, 01:15 door Anoniem
Door Coritchando: Zoals altijd, als er in bepaalde software een serieus lek wordt ontdekt dan ligt deze software de eerste weken onder een vergrootglas.
Klopt. Daar heb ik al voor gewaarschuwd en het is ook logisch.
Een fout van dergelijke magnitude trekt onguur cyber-volk aan.
18-12-2021, 10:16 door Anoniem
Trouwens, hoe moet een gebruiker van deze component de kwaliteit ervan beoordelen? Even in 2.300 sources met 300.000 regels code zonder verklarend commentaar overzien dat het goed zit? Ga er maar aanstaan. Het voordeel dat open source in dit opzicht kan hebben wordt zo niet waargemaakt. Ik denk dat het problematisch is als de logcomponent alleen al groter is dan de gebruikende applicatie, en ik denk dat dat vaak genoeg zal voorkomen.

Ja dat is een probleem wat vaak over het hoofd gezien wordt bij het verhaaltje "iedereen kan de source bekijken".
Maar in dit geval is het eigenlijk veel ernstiger! Het is niet zo zeer een bug in de implementatie, iets wat je zou kunnen
hebben als iemand een foutje gemaakt heeft bij het programmeren, en wat je dan maar toevallig moet zien.
Nee dit is een DOMME ONTWERPFOUT VAN DE 1E ORDE.
Dit zou je in de documentatie al moeten zien. Source is hier helemaal niet voor nodig. Als er ergens in de documentatie
staat dat je op willekeurige plekken van die handige ${....} macro's mag opnemen en dat die dan vanalles kunnen doen
waaronder connecten naar externe datasources en de geretourneerde waarden op die plek invoegen, dan zouden
alle alarmbellen moeten afgaan en dit product meteen naar de "onbruikbaar, in de bittenbak" categorie moeten worden
verwezen.

Zeker ook omdat die feature in de 1e versie niet aanwezig was, en toen dit erin gedesigned werd iedereen al wist
dat het heel dom is om dit soort dingen te doen (zie bijvoorbeeld SQL injection door queries die zijn opgebouwd
op zo'n soort manier).

Nee, ik snap echt niet hoe zo iets in productie gekomen kan zijn. Ik houd me altijd ver van Java omdat ik nog nooit
de combinatie "Java - acceptabel werkend" ben tegengekomen (wel "Java - onbruikbaar traag", "Java - resource hog"
en "Java - alleen maar ellende met versies"). Maar dit soort dingen laat me weer 5 jaar alles waar Java in zit
mijden als de pest.
18-12-2021, 10:27 door Anoniem
Door Anoniem:
Door Coritchando: Zoals altijd, als er in bepaalde software een serieus lek wordt ontdekt dan ligt deze software de eerste weken onder een vergrootglas.
Klopt. Daar heb ik al voor gewaarschuwd en het is ook logisch.
Een fout van dergelijke magnitude trekt onguur cyber-volk aan.
Het trekt ook de aandacht van een hoop cyber-volk dat op verbetering gericht is. Hun inbreng om de problemen op te sporen en te verhelpen heeft een blijvende positieve impact op de code, terwijl de activiteiten van de ongure types, ook al kunnen die aanzienlijke schade veroorzaken, van voorbijgaande aard zijn.

Ik heb overigens grote twijfels of een logcomponent van maar liefst 300.000 regels Java-sourcecode wel goed in elkaar zit, in de zin dat dat wel heel erg veel code is voor een in essentie simpele functie. Dat roept de vraag op hoeveel van de geïnstalleerde code in een specifieke operationele omgeving daadwerkelijk geraakt wordt. De volgende vraag is of de code die voor die omgeving overbodig is weggelaten kan worden uit de installatie. Ook code waarvan de bedoeling niet is dat die uitgevoerd wordt in een bepaalde omgeving kan exploiteerbare lekken opleveren. Uit security-oogpunt kan die beter niet geïnstalleerd zijn, want code die niet in je runtime beschikbaar is kan niet voor exploitatie misbruikt worden. Als het nu niet mogelijk is om de gewenste functionaliteit selectief te installeren (ik ben nog niet tegengekomen dat dat wel kan) dan zou het wel eens een enorme klus kunnen zijn om uit elkaar te trekken wat nu met elkaar verweven is.

Het doen van JNDI-lookups (de oorspronkelijke log4shell-kwetsbaarheid), omdat een string gelogd wordt die syntax voor die lookup bevat, lijkt mij een duidelijk voorbeeld van iets dat je niet eens geïnstalleerd wilt hebben als je het niet bewust gebruikt. Niet alleen zou die mogelijkheid niet default actief moeten zijn, het levert extra veiligheid op als die mogelijkheid default om te beginnen niet aanwezig is. Dergelijke mogelijkheden zet je dus bij voorkeur op als plug-ins die een gebruiker expliciet moet installeren en die in een default-installatie domweg ontbreken. Het had denk ik nooit zo'n groot probleem kunnen worden als het nu is als dat de opzet was geweest.
18-12-2021, 10:40 door [Account Verwijderd] - Bijgewerkt: 18-12-2021, 11:10
Door karma4:
Door Toje Fos: Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware'). .. .
Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.
Randsomware lijkt me een prima woord. Random wat bij elkaar graaien, de gevolgen met een ransom. Prima aanduiding

Je gebruikt in de automatisering altijd 'wat van een ander dat je niet begrijpt'. Van microcode tot assemblercode tot API's van het besturingssysteem tot bibliotheken bij je programmeertaal tot de compiler/interpreter van je programmeertaal, enzovoort. Jij wilt het nog eens verergeren door closed source te gebruiken zodat je er zelfs in geval van nood niet bij kan. Nou, succes daarmee.
18-12-2021, 12:43 door Anoniem
Door Toje Fos:
Door karma4:
Door Toje Fos: Het woord dat je zoekt is natuurlijk ransomware (geen 'randsomeware'). .. .
Open source is een script kiddie wereld, daar heb je gelijk in. Je gebruikt wat van een ander zonder de gevolgen te doorgronden dan wel de bron te begrijpen.
Randsomware lijkt me een prima woord. Random wat bij elkaar graaien, de gevolgen met een ransom. Prima aanduiding

Je gebruikt in de automatisering altijd 'wat van een ander dat je niet begrijpt'. Van microcode tot assemblercode tot API's van het besturingssysteem tot bibliotheken bij je programmeertaal tot de compiler/interpreter van je programmeertaal, enzovoort. Jij wilt het nog eens verergeren door closed source te gebruiken zodat je er zelfs in geval van nood niet bij kan. Nou, succes daarmee.
Inderdaad dat hebben we bij de gesloten supplychain software tik gezien waardoor ook Microsoft werd gehackt.
18-12-2021, 12:48 door Anoniem
is dit weer zo'n NSA backdoortje die er stiekem ingeslopen is?
20-12-2021, 07:45 door Anoniem
Maar open Source was toch altijd zo veilig omdat "iedereen" er naar kan kijken en het kan controleren op fouten?
Dat is tenminste wat ik altijd lees hier als er weer eens iets met Windows software aan de hand is.

Chris
20-12-2021, 17:06 door Anoniem
Door Anoniem: Maar open Source was toch altijd zo veilig omdat "iedereen" er naar kan kijken en het kan controleren op fouten?
Dat is tenminste wat ik altijd lees hier als er weer eens iets met Windows software aan de hand is.

Chris
Ja, want daarom is het nu ontdekt en wordt het verholpen, door een grote hoeveelheid mensen die zich nu inzet daarvoor.
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.