Vals alarm

10, 13–14 en . Kleine aanpassingen nog op 18 en 19 november.

Draad

In de loop van vrijdag 31 oktober 2025 merkte ik de volgende Twitterdraad van @TRDVnl op, een vervolg op iets van mij uit 2022:

3:05 a.m. · 31 okt. 2025
“🧵 1/4
🚨 🚨 Tijdens een web-audit stuitte ik op een oud CGI-script dat invoer direct als systeem-commando uitvoerde.
Waarschijnlijk nog geschreven in 1986, door iemand die dacht dat nice ook beveiliging was. 💾”

3:05 a.m. · 31 okt. 2025
“🧵2/4
De INJECTIE kwam van BUITEN EUROPA (AMERIKA), niet van mij. Ik deed alleen legale curl-checks om te zien wat er openstond.
Tijdens die audit vond ik vier bestanden die bij misbruik als DDoS-vector konden dienen. ⚠️”

3:05 a.m. · 31 okt. 2025
“3/4
Maar Ruud zag “curl” en riep meteen: “DOS-AANVAL!” 😅
(Dat is alsof je iemand van inbraak beschuldigt omdat hij op de deurbel drukt.)
Hij bedoelde vast DDoS, maar kreeg DOS-flashbacks uit 1983.”

3:05 a.m. · 31 okt. 2025
“4/4
Kort: ik auditteer en waarschuw; ik viel niet aan.
De echte dreiging kwam van buiten Europa niet van mijn toetsenbord.
Patch die museum-code, Ruud. 🙃💾”

Hele nachten zijn deze lieden bezig de veiligheid van mijn website te controleren. Wat een eer! Want ook Kirill Korneev (Кирилл Корнеев, beklemtoond Кири́лл Корне́ев), was die nacht om 11 over 3 actief, hij bevestigde de uitkomsten van @TRDVnl:

3:11 a.m. · 31 okt. 2025
“Ik heb de bevindingen van @TRDVnl gecheckt en het is werkelijk beschamend.
@rudharcom heeft altijd een heel grote muil, maar zulke lekken bezorgen hem een enorm gezichtsverlies (inclusief de wenkbrauwen)”

Enkele reacties vooraf

  1. Bij 1/4: 1986? Zou @TRDVnl doelen op mijn umlautenconversie? Ik heb daarbij inder­daad nog altijd een associatie met een indoor atletiekbaan, in een gratis sporthal die Heinz Nixdorf, oprichter van, had geschonken aan de bevolking van Paderborn, om te delen in zijn vergaarde rijkdom. Hij was overigens enkele maanden voordat ik daar vertoefde, op 17 maart 1986, overleden.

    Tijdens een rondje hardlopen daar overdacht ik de basisaanpak, of enkele verfijningen, dat weet ik niet meer, voor het algoritme van die automatische umlautconversie. Hard­ware (printers) en software waren toen namelijk nog zo moeizaam en primitief dat men veelal nämlich schreef als naemlich.

    Algoritme, script (sh met sed) en sneller programma (in C) dateren van toen, maar CGI bestond in die tijd toen nog niet, dus die maakte ik er veel later pas bij. En daarin zat, zo bleek ook bij herinspectie in 2025, geen datalek dat te benutten zou zijn voor code-injectie.

  2. Ook bij 1/4: nice beveiligt inderdaad tegen overbelasting door een intensieve reken­taak, zoals het vinden van priemgetallen. Het CGI-proces krijgt een lage prioriteit (met een hoger getal), en is daardoor bij het toekennen van time slices pas later aan beurt, als er eerst en dringender tijd nodig is voor bijvoorbeeld het bedienen van andere site­bezoekers.

    Had de verder naamloze @TRDVnl dat nice misschien hier gezien? (O pardon, een frame restant; kan ook zonder, hoor!) Dat programmaatje, naar het overbekende algo­ritme van Eratosthenes (Ἐρατοσθένης ὁ Κυρηναῖος), schreef ik (of schreven we? het was een opleiding) op een terminal bij de Rabobank in Utrecht, in een of ander Basic-dialect. Die terminal was met een telefoonlijn verbonden met een minicomputer (zo heette dat toen, iets tussen een microcomputer en een mainframe in) van DEC (Digital Equipment Corporation), die zich in Zeist bevond. TOPS20, staat me bij, heette die computer zo, of het OS? Maakt ook niet uit.

    De uitvoer verscheen op een printer. Op een kettingformulier. Ik heb dat printje vast nog ergens, maar ik ga niet zoeken. Van de eerste 20.000 priemgetallen, of de priem­getallen tot 20.000. Anders werd het te traag. Staat nu in een flits op het scherm.

    Algoritme van ongeveer 2250 jaar geleden, code uit 1980, maar CGI van pas veel later. En zonder lek. Nogmaals gecheckt in 2025.

  3. Bij 2/4: Met curl haal je volgens mij webpagina’s op. Zien wat er openstaat, bijvoor­beeld poorten, doe je met een port scanner. Heel iets anders.

  4. In tweet 3/4 refereerde @TRDVnl aan mijn tweet:

    12:33 a.m. · 31 okt. 2025
    “Ik heb je ondertussen geblockt in mijn firewall trouwens. Je DOS-poging is mislukt. Odido zal er blij mee zijn.”

    Inderdaad was ik die avond om half een ook nog wakker, en bemerkte ik via mijn lijst van veelbezochte pagina’s een ongebruikelijke activiteit: vanaf 23:51:38A, nog op 30 oktober, werden door een IPv4-nummer van Odido dat eindigde op 247 herhaaldelijk foto’s zoals te zien in deze pagina van mijn site opgehaald. 5 tot 9 foto’s per seconde, steeds in een rijtje weer dezelfde. Vanaf 23:55:43 ook oude schoolfoto’s zoals hier te zien.

    Ook zijn tussen 23:49:38 en 00:22:52 vanaf dit IP-adres zeer vele pogingen gedaan, soms 26 keer per seconde, om bestanden als icons/text.gif, icons/folder.gif, icons/image2.gif, icons/back.gif en icons/blank.gif te downloaden. Tip voor de aan­valler, of het nou @TRDVnl of iemand anders was: zulke bestanden heeft webserver nginx niet, dat is meer een Apache-dingetje, of iets van FreeBSD. Ik heb ze vroeger wel eens gezien inderdaad. Dienen denk ik voor het verfraaien van directorylistings. nginx doet dat anders, via de installeerbare extensie fancyindex.

    Nogmaals het citaat van tweet 3/4:
    “Maar Ruud zag “curl” en riep meteen: “DOS-AANVAL!” 😅
    (Dat is alsof je iemand van inbraak beschuldigt omdat hij op de deurbel drukt.)
    Hij bedoelde vast DDoS, maar kreeg DOS-flashbacks uit 1983.    ”

    Ik zag geen “curl”, ik zag “python-httpx/0.28.1”. “curl” kwam maar 9 keer voor, tot aan tijdstip 31/Oct/2025:00:25:05 +0100. En als ik DOS zeg bedoel ik ook DoS, Denial of Service, niet DDos, Distributed …, want alles kwam van een en hetzelfde IP-nummer.

    En de denial, het ontkennen of beter vertaald het verhinderen, dat was er niet, want mijn servertje kan dit, ondanks maar 1 processorkern en ‘slechts’ 1 GB RAM, heel best hebben. Vandaar dat ik tweette dat hij mislukt was, de stresstest dus, want dat was het.

Gaat u allen rustig slapen

Die middag of ochtend van 31 oktober las ik wel de hele thread en keek ik kort de log­bestanden van nginx al in, stelde ze ook veilig. “[...] een oud CGI-script dat invoer direct als systeem-commando uitvoerde.”? Dat zou ik natuurlijk nooit doen, en dat had ik dus ook niet gedaan.

Ik ging ervan uit dat de melding bluf was, onderdeel van het denigrerende getrol en getreiter waar dit duo al geruime tijd mee bezig was (en is!). Dus ik negeerde het en ging lekker door met wat ik aan het doen was: een stuk schrijven in het Interlingua, over muzieknotatie, over het verschil tussen een tie en een slur, een overbinding en een legatoboog, en fraseringsbogen, die heb je ook nog. Veel leuker, veel interessanter.

Valt het onderstaande eigenlijk onder het juridische begrip afdreiging?

3:37 a.m. · 31 okt. 2025
“Ruud heeft drie opties:
1️⃣ De lekkages laten voortduren.
2️⃣ Zelf uitzoeken waar het is misgegaan.
3️⃣ Stoppen met laster en smaad richting Kiril en mij.
  
@kirikorneev en ik weten welke vijf bestanden het precies betreft. Jij kiest, Ruud. 💾”

Ik denk het niet. Maar het lijkt er wel op. Ik ben geen jurist.

Wel een extra motivering ze te negeren en gewoon mijn eigen leven te leiden, zonder deze ettertjes.

Geschrokken!

Laat in de middag van 1 november, om 16:50A, had ik mijn stukje af. Toen ging ik toch nog maar eens naar die CGI’s kijken. En ik schrok! Want ik zag wel degelijk een plek waar ik gebruikersinvoer op de server liet uitvoeren! Precies zoals @TRDVnl beweerd had.

Dat was het moment waarop ik besloot mijn VPS meteen uit te schakelen, met het voor­nemen alle code van alle CGI’s grondig te gaan nalopen. En vanwege die beweerde Ameri­kaanse injectie, waar ik overigens nog steeds weinig van geloofde, zouden webserver en mailserver pas weer opkomen na herinstallatie op een schone, nieuwe VPS. Voor de alle zekerheid. Better safe than sorry!

In de loop van 5 nov 2025 was de website weer op. Eerste access in de logfile: 10:20A.

Op 6 november 2025 heb ik met mijn erg handige, al ruim 30 jaar oude, maar pas recent gepubliceerde programma 4waylist een vergelijking getrokken tussen de oude en de nieuwe VPS, in de hoop zo de effecten van de beweerde Amerikaans injectie (hoe onwaar­schijnlijk ook) te vinden. Helaas bleken er te veel, ongetwijfeld legitieme en verklaarbare, verschillen tussen de beide servers, om er conclusies uit te kunnen trekken.

Leks

Op 10:23 a.m. · 1 nov. 2025 startte ik een interessante twitterdraad over de relatieve moeilijkheidsgraad van onderhoud versus nieuwbouw bij softwareontwikkeling. Dit was in reactie op een zoveelste neerbuigende opmerking van Kirill Korneev over mij:

11:08 p.m. · 30 okt. 2025
“Klinkt gewoon als een software onderhoudsmonteurtje, een verijdelde code monkey.”
(Kirill bedoelde daar uiteraard ‘veredelde’ in plaats van “verijdelde”. Klein foutje in zijn verder uitstekende Nederlands.)

In die draad schreef Kirill Korneev, zich richtend tot compaan @TRDVnl:
2:13 p.m. · 1 nov. 2025
“Staan de leks al op dark web of hacker fora? Weet jij het?
  
Gratis aangeboden uiteraard, want niemand gaat voor deze jaren 90 troep betalen.”

@TRDVnl antwoordde:

2:16 p.m. · 1 nov. 2025
“Voor zover ik weet nog niet. Maar de situatie is in beweging, dus dat kan snel veranderen.
  
VPS zijn wel in trek bij Bot Farms, zijn injecties uitermate geschikt voor!”

Kirill:
2:19 p.m. · 1 nov. 2025
“Gaan ze zijn VPS tot een spambot ombouwen? Dan staat er eindelijk moderne software op die server.”

Enkele dagen later, @TRDVnl:
2:00 p.m. · 7 nov. 2025
“En vergeet de kans op Amerikaanse script-injecties niet. Die overschrijden Ruuds firewall met gemak. 😎”

Eh, ik weet niet, maar een code-injectie via een invoerveld of URL-parameter loopt gewoon via de normale webpoort 80 of 443. Dat heeft met de firewall niks te maken, aangezien die poorten bij een webserver uiteraard open moeten staan. Anders doet-ie ’t gewoon niet.

Weer een aanwijzing (achteraf) dat de melding nep was.

Welke lekken?

XSS

XSS = Cross-Site Scripting. Dit is een gevaar dat optreedt als tekst afkomstig van een gebruiker, bijvoorbeeld op het scherm of in een URL-parameter, wordt gebruikt als ele­ment in HTML voor schermweergave. Een kwaadwillige kan dan afbeeldingen op het scherm laten verschijnen, of een hyperlink naar een andere, mogelijk kwaadaardige website. Het verkeer daar lijkt dan van de website met het XSS-lek te komen, terwijl de ontwerper of beheerder daarvan van niets weet en geen kwade bedoelingen had.

Dat mag uiteraard nooit gebeuren. Ik werd op 15 september 2022 per e-mail op mijn fout gewezen. Meteen een dag later, 16 september heb ik de gaten dichtgespijkerd. Het betrof zoals gedetecteerd mijn lokale zoekfunctie, Siworin, maar na inspectie bleken ook de zoekinterface voor Interlingua-woordenboeken, en de umlautconversiedemonstratie kwetsbaar te zijn.

Zie ook de Common Weakness Enumeration van MITRE, en de Cross Site Scripting Preven­tion Cheat Sheet van OWASP.

Toegegeven, mijn fixes waren er natuurlijk laat. Te laat. Maar het kan niet zo zijn dat dit de lekken zijn die Twitteraar @TRDVnl eind oktober 2025 beweerde te hebben gevonden, aangezien ik deze problemen als gezegd al op 16 september 2022 heb opgelost.

Nafilter

Nu kom ik op een kwalijk lek dat wel degelijk echt in mijn site zat! Ik ontdekte dat zelf bij mijn inspectie, in 2025, van alle broncode van alle CGI’s op mijn site. Het zat in de Interlingua-woordenboekeninterface. Niet in het gewone zoekwoordveld, want de invoer daarvan voerde ik al sinds 17 maart 2020 toe via een tijdelijk bestand en de grepoptie -f. Daardoor krijgt de shell de inhoud van het zoekargument nooit te zien, en is er dus ook geen risico van code-injectie via de shell.

Dit betekent wel dat er tussen 22 september 2015 en 17 maart 2020 wel een lek moet zijn geweest. Ook kwalijk. Ik had eerder zorgvuldiger moeten zijn met deze dingen.

Nog erger is dat er als gezegd tot zeer recent nog een code-injectielek aanwezig was: in het postfiltro, het nafilter, dat dient om wat massale resultaten te kunnen matigen door aan een bepaald woord (algemeen: een reguliere expressie) de exclusieve voorkeur te geven, of door wat voldoet aan dat patroon er juist uit te gooien.

Achterliggend werd dit gedaan:
| grep -E [-v] "ingevoerd patroon"
Als nu werd ingevoerd ";cat /etc/passwd;", dan was de actie na substitutie:
| grep -E [-v] "";cat /etc/passwd;""
De nu afgesloten grep in de pipe liet alles door, het commando na de puntkomma liet de inhoud van het Unix-gebruikersbestand op het scherm verschijnen. Kon echt, ik heb het zelf zien gebeuren. Uiterst kwalijk. Mag echt nooit kunnen.

Wel toch twee redenen waarom het minder erg is dan het lijkt:

Dit alles neemt niet weg dat dit een kwalijk lek was, en een blunder van mij dat ik het heb laten ontstaan en voortduren. Ik heb de bug dus verholpen, op 2 november 2025, door meer tekens te vervangen door een spatie: <, >, &, " en '.

popen

Dit was het schrikmoment. Maar achteraf was het risico hier klein of vrijwel afwezig. Het betrof namelijk zoeken met reguliere expressies in mijn lokale zoekmachine Siworin. Daar sta ik maar één regexp tegelijk toe, niet meerdere woorden zoals bij zoeken zonder regexp. Zodra dus in het beoogde injectiecommando een spatie voorkomt, zet ik het keuzevakje “Regular expression” uit. Zonder spaties kom je bij het injecteren niet ver.

Het risico ontstond doordat via popen() een grep werd (en wordt) uitgevoerd, met het zoekargument direct in de commandoregel. Ik beweerde op 28 oktober jl dat popen() geen shell start om het aangeboden commando uit te voeren, maar dat is onjuist. Er is wel een shell, dus een risico.

Klein weliswaar, maar voor de alle zekerheid heb ik het kleine gaatje toch dichtgelast: de reguliere expressie is niet meer een oproepargument voor grep, maar bereikt dat in een tempfile via de optie -f. Aanpassing 3 november 2025, source file siworin-srchind.c .

Niet gevonden!

Er zaten dus inderdaad veiligheidslekken in mijn site, in mijn CGI’s, maar Twitteraar @TRDVnl heeft die niet gevonden, althans die kans is erg klein. Dat kan ik zien in de logfiles van nginx.

@KiriKorneev twitterde die nacht, als eerder vermeld:
3:11 a.m. · 31 okt. 2025
“Ik heb de bevindingen van @TRDVnl gecheckt en het is werkelijk beschamend.
@rudharcom heeft altijd een heel grote muil, maar zulke lekken bezorgen hem een enorm gezichtsverlies (inclusief de wenkbrauwen)”

Nee, Kirill had niks gecheckt, want er was niks. Het was allemaal bluf en nep, alleen bedoeld om mij te vernederen en intimideren, iets wat al vele weken aan de gang was en is op Twitter. Door alle ophef heb ik dan wel bij mijn eigen code-inspectie de echte lekken gevonden en gefixt, en dat is mooi meegenomen.

Wat dan wel?

Wat heeft @TRDVnl dan wel gedaan? Het eerdere IP-nummer had ik geblokkeerd in de firewall. Vanaf een IPv4-adres bij KPN dat eindigt op 99, waarvan ik sterk vermoed dat het eveneens aan de persoon achter het Twitteraccount @TRDVnl toebehoort, of althans door hem te gebruiken is, is op 31 oktober, eenmaal om 00:57:10 +0100 en daarna van 02:22:04 tot 02:22:26, in totaal 37 keer, waaronder 14 keer in de ene seconde 02:22:12 en 9 keer in 02:22:13, geprobeerd mijn CGI-programma dstqview (bedoeld voor het ophalen van random geselecteerde citaten uit artikelen van mijn site, in een bepaalde taal of random in allerlei talen), maar vaker mijn CGI-programma rndmview (bedoeld voor idem, maar dan met links naar hele artikelen), te verleiden tot anomaal gedrag, waarbij interne informatie zou worden prijsgegeven, door het aanbieden van verzonnen para­meters in de URL.

Voorbeeld:
GET /cgi-bin/rndmview.cgi?link=http%3A%2F%2Flocalhost%2Fcgi-bin%2Faccount_mgr.cgi
Met gedecodeerde procentcoderingen staat dat uiteraard voor:
GET /cgi-bin/rndmview.cgi?link=http://localhost/cgi-bin/account_mgr.cgi
In plaats van “link” kwamen ook voor: url, redirect, fetch, include, page, url, href, src, goto, next en target.

Tips voor @TRDVnl of wie het ook was, en voor andere would-be hackers die dit ook zouden willen proberen:

  1. Zo’n account manager, of wat het ook zou moeten wezen, heb ik helemaal niet in mijn webserver of op mijn VPS, niet onder deze naam en ook niet onder een andere.
  2. De accounts, of beter users zoals ik ze zou willen noemen, zijn gerealiseerd op de standaard UNIX-manier, met /etc/passwd en /etc/shadow.
  3. Er is bij mij niks van buitenaf bereikbaar met adressen als localhost of 127.0.0.1. Ik kan me ook niet voorstellen dat dat bij andere websites wel zo is. Maar ik weet niet alles. En bij de directory cgi-bin kom je op die manier natuurlijk al helemaal niet.
  4. Het proberen van allerlei parameternamen heeft geen enkele zin, want al mijn CGI-programma’s en -scripts reageren uitsluitend op de parameternamen die ik bedacht heb. Al het andere wordt stilzwijgend genegeerd. Heeft dus gewoon helemaal geen uitwerking. Niente, nada, zilch, nihil, niks.
  5. Het proberen van heel lange parameternamen of parameters (was hier weliswaar niet gedaan) heeft ook geen zin, want ik test en kopieer uiteraard alleen zoveel bytes als de buffers aankunnen. Er vindt geen buffer overflow plaats.

    Dat is bij de programmeertaal C weliswaar mogelijk, maar juist daarom let ik er natuur­lijk scherp op. Moderne compilers waarschuwen er waar mogelijk ook tegen, hoewel het zur Kompilierzeit, anders dan zur Laufzeit, principieel niet mogelijk is om alle ge­vaarlijke situaties te onder­kennen. Maar veel gebruikelijke wel.

Voor de test deden betreffende IP-adressen (soms ook een IPv6 eindigend op 71e7, ook van KPN) diverse tamelijk zinloze GET- en POST-opdrachten op enkele van mijn CGI-programma’s.

Geavanceerd audittool?

@TRDVnl deed naar eigen zeggen een “web-audit” op mijn site. Ik heb even gedacht, gezien de user agent string “SafeAuditEnumerator/1.0”, dat hij een of ander geavanceerd pentest-, hacking- of auditgereedschap zou gebruiken. Maar bij zoeken op die string vond ik niets. Zulke tools zijn toch meestal open source? Dan zou er toch ergens een beschrij­ving of source code van te vinden moeten zijn?

“SafeAuditEnumerator/1.0” zag ik ook gebruikt worden vanaf een IPv6-adres van KPN dat eindigt op 7b59.

Andere user agent strings die ik betreffende IP-adressen zag gebruiken waren curl/8.4.0 en python-httpx/0.28.1, ik denk van rechtstreeks ophalen met programma curl resp. door een python-script dat commando curl, of via python-opdrachten libcurl gebruikt. Ik zie daarom SafeAuditEnumerator/1.0 als een fantasienaam bedacht door @TRDVnl, niet als een echt tool.

Die indruk wordt versterkt door wat ik in de logfiles zag van hernieuwde ‘audit’-acties op 8 november 2025. De IP-adressen waren toen weliswaar anders, wel gelijkend, de meeste ook van KPN. Een eindigde op 204, een andere op 7b59, en er was er ook een die op 100 eindigde, maar die niet van KPN is.

Het gedrag was steeds sterk gelijkend. Men richtte zich op mijn kleurentester cores.cgi – dat geen veiligheidslek bevat en ook nooit bevat heeft. (Merk op dat “cores” niet het meervoud van Engels core, kern, is, maar van Portugees cor, kleur.) Maar, opvallend, de user agent string varieerde daarbij soms binnen eenzelfde seconde tussen “SafeAuditEnumerator/1.0”, “Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36”, en “Mozilla/5.0 (compatible; Bingbot/2.0; +http://www.bing.com/bingbot.htm)”, hoogstwaarschijnlijk zonder dat het verkeer ooit echt van Microsofts Bing kwam.

Ik denk: alles kwam van een python-programmaatje dat de user agent string random vanuit een tabelletje varieerde. Gewoon dikke nep dus in feite.

Dat websiteverkeer op 8 november vond plaats tussen 19:17:27 en 19:48:36 +0100. Rond diezelfde tijd was @TRDVnl op Twitter weer gezellig en behoorlijk onzinnig over mijn website en webserver aan het keuvelen met @KiriKorneev:

7:21 p.m. · 8 nov. 2025
“Net een nieuwe scan gedaan: 2–3 dagen offline geweest en nog steeds niks opgelost.
Eerlijk @KirikKorneev, wat vind jij hiervan? ”

Die discussie begon in de ochtend van 8 november al, om 8:10A, en ging oorspronkelijk over iets heel anders. Ik link naar enkele tweets zonder alles te citeren: __, __, __, __, __, __, __, __, __, __, __, __, __, __, __, __: “Nee, je site heeft een lek. Je hoeft mij niet te geloven, het is alleen handig!”). Dat laatste was om “7:06 p.m. · 8 nov. 2025”, ruim voor de eerste log entry van 19:17:27. Heeft deze discussie @TRDVnl op het idee gebracht weer een nieuwe “audit” te gaan doen? Die in werkelijkheid wederom geen audit was, maar een stresstest.

(Die tweets over 502 waren een tegenplagerijtje van mijn kant. Ik suggereerde dat de fout bij @TRDVnl zat, maar dat kon helemaal niet. Het was een fout van mij: ik had ergens een font-size: 80% ingesteld, maar omdat die string naar een fprintf ging moest ik die als 80%% schrijven, anders werd de hele header niet gestuurd, met “Bad Gateway” tot gevolg. Cryptische foutmelding, maar bedenk dat CGI betekent: Common Gateway Interface. De C-compiler had wel gewaarschuwd, maar dat had ik toen niet gezien. Later wel.
Het pleit voor @TRDVnl en @KiriKorneev dat ze er niet intrapten.)

Wat kan @TRDVnl gevonden hebben?

Ik denk: het zijn allemaal leugens, het is bluf, intimiderende onzin, bedoeld om mij te treiteren. Daar trap ik niet meer in. Mijn lokale zoekmachine Siworin werd enkele keren snel achter elkaar, zonder URL-parameters, benaderd. Daarmee het lek vinden (dat overi­gens niet of nauwelijks exploiteerbaar was) is erg onwaarschijnlijk.

Het kwalijke échte lek in mijn site, in het nafilter van mijn woordenboekinterface voor Interlingua (en één Esperanto-Engels woordenboek), zat in het CGI-programma cgi-grep.cgi . Maar die CGI is op 30 en 31 oktober en op 8 november door geen van de auditende IP-adressen ooit benaderd!!!. @TRDVnl kan dat lek dus ook nooit gevonden hebben, en er heeft daarvia al helemaal geen Amerikaanse injectie plaatsgevonden, die hij gezien zou kunnen hebben, nota bene zonder inzage in de logfiles van nginx op mijn VPS!

Ethisch hacken?

Was dit ethisch hacken? Ik heb op 11 november 2025 eens aan grok.com gevraagd wat dat inhoudt. Niet dat die nou alles goed weet, ik heb daar ook negatieve ervaringen mee, maar op het gebied van programmeren en andere IT-onderwerpen is hij over het al­gemeen wel goed op de hoogte. Er kwam een gedetailleerd antwoord, waar ik twee be­langrijke punten uitlicht: er moet vooraf toestemming van de eigenaar of beheerder zijn, en na afloop komt er een uitgebreid verslag met concrete details. Beide ontbraken in dit geval. Niet ethisch dus.

Het was ook geen hacken, geen pentest (penetration test), want er is niet binnen­ge­drongen. De pogingen daartoe die er wel waren, waren nogal knullig.

Voor de rest waren het slechts stresstests, waar mijn bescheiden VPSje warm noch koud van werd, durf ik te vermoeden zonder met een thermometer in de serverruimte naar binnen te kunnen of willen.

Als @TRDVnl en @KiriKorneev echt van mening zijn dat er nog security holes in mijn site of VPS zitten, dan moeten ze die maar eens op een nette manier aan mij melden, bijvoor­beeld zoals die bounty hunter in 2022 deed over XSS. Tot die tijd geloof ik er allemaal geen barst van.

Copyright © 2025 van R. Harmsen, alle rechten voorbehouden, all rights reserved.