Nieuws

De Helpdesk, aflevering 4 – “gesloten” poort en G1 certificaten

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Poort 8080 is gesloten (of toch open)

We kregen een korte mail met de melding: “Poort 8080 staat niet open”. Dus wij tikken in onze browser: http://[gemeentesite].nl:8080. In plaats van ‘geen gehoor’ wordt de gebruiker doorgestuurd naar de site van een gemeente. Daarna proberen we de site http://[gemeentesite].nl:9090, en daar gebeurd niets.

Conclusie: op poort 8080 gebeurd wel iets, dus deze poort staat open met iets overbodigs. We kunnen niet zien wat en of dit een uitzondering waard is. Dus de conclusie ‘overbodige poort’ blijft staan.

Screenshot bij het bezoeken van het hoofd-domein op dit adres op :8080. De melding op deze pagina zegt dat je mogelijk iets bijzonders moet hebben gedaan om geblokkeerd te worden. Daaronder valt dus ook gewoon bezoeken ­čÖé

Fix voor uitzondering G1 certificaten

De overheid geeft een certificaat uit dat by design niet wordt vertrouwd in browsers. Dit is het G1 certificaat. We hebben al wat jaren code in Basisbeveiliging die hiervoor een uitzondering toevoegt. Of… dat dachten we.

We ontvingen een mailtje met de vraag of we een G1 certificaat konden uitzonderen. We hadden zoiets van: dit doen we toch al?

Dit was het begin van een paar uur lang debuggen. Uit de logs konden we halen dat deze uitzondering is aangeroepen na de ‘niet vertrouwd’ conclusie van de TLS meting. We hebben de code erbij gepakt en het met de hand aanroepen van alle functies ging goed.

We hebben de code lokaal en op de server gedraaid als allerlei gebruikers: werkt altijd. We hebben extreem gedetailleerde logging toegevoegd aan deze code en we zagen dat alleen op de server, tijdens het meten via een worker, een specifieke SSL foutmelding optrad.

De conclusie is dat een van de componenten om parallel te kunnen meten (“gevent” voor de nerds) de SSL bibliotheek aanpast wat kan zorgen voor ander gedrag. Nadat we de worker hadden omgezet naar ‘prefork’ zagen we dat het probleem was opgelost.

We hebben deze taak dus overgezet naar een prefork worker. Dat kost wat meer geheugen maar dan hebben we wel zekerheid dat de meting goed gaat.

Inmiddels is de helft van de uitzondering-checks er doorheen en zijn er 83 G1 certificaten gevonden. We zien dit certificaat o.a. op sites als api.kvk.nl, isb.rdw.nl, en data.* subdomeinen van gemeenten.

Overzicht van uitzonderingsmetingen op het domein van de vraagsteller…

De Helpdesk, aflevering 3 – Diensten voor medewerkers en onjuiste header metingen

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Dienst voor medewerkers via het open internet

Een organisatie die graag mailtjes stuurt maakt gebruik van een standaardpakket. Medewerkers kunnen op die omgeving inloggen en de nieuwsbrieven opstellen.

Wij raden aan om dit soort diensten niet publiek te zetten: die vraag was voorgelegd aan de hoster. De hoster geeft aan bang te zijn om deze aanpassing door te voeren. Het zou meer problemen leveren dan het oplost. Dus ze gaan dat niet doen.

Oplossing: In dit geval zien we een Plesk PHP omgeving staan. Beiden zijn bekend en geroemd om hun vele kwetsbaarheden. Dat betekent voor een aanvaller: “Rustig wachten op de dag… van een nieuwe kwetsbaarheid… van een nieuwe kwetsbaarheid“. Dan kan IT weer fijn in het midden van de nacht / carnaval stekkers ergens uit halen, patchen, datalekmeldingen sturen enzovoorts. All in a good days work: maar je kan ook kiezen voor nachtrust, een goede reputatie en een stabiele dienstverlening.

Het is alsof je een deel van de interne organisatie buiten het gebouw naast de ingang zet. In plaats van binnen met verwarming, een beveiligingspoortje en een receptie. Iedereen kan er naartoe lopen en proberen binnen te komen: via gokken op het loginformulier of via een (nieuwe) kwetsbaarheid. Net zoals je bij een bedrijf een veiligheidspoortje hebt, wil je voor de toegang tot dit soort diensten altijd een controle uitvoeren.

Daar is in dit geval ook wel een poging tot gedaan. In plaats van de dienst op het standaard poort 443 aan te bieden, word deze “verborgen” op poort 8443. Dat soort security through obscurity werkt vertragend, maar uiteindelijk niet.

Er zijn diverse manieren om diensten te verbergen voor de buitenwereld. Het mooiste is achter een VPN, waarbij er publiek niets meer te vinden is. Een medewerker logt in op het deel VPN en kan dan naar mailing.intern.belangrijkeorganisatie.nl gaan om het werk te doen. Het is ook mogelijk om toegang op basis van certificaat of IP in te richten: dan kan een buitenstaander zien dat er nog wel *iets* is, maar niet meer wat. Dat is natuurlijk minder mooi en uiteindelijk ook meer werk. Er zijn vast nog wel andere oplossingen te bedenken. Wij gaan altijd voor de optie om zo min mogelijk diensten over het open internet aan te bieden.

Onjuiste header meting

We kregen de melding dat we onterecht bevinden dat bepaalde http security headers ontbreken. We gingen op onderzoek uit.

Oplossing: Hier hebben we inderdaad een fout gemaakt. We stuurde een “Host” header mee, maar hielden geen rekening met dat we konden worden doorgestuurd. Dat betekent dat we de verkeerde site (“Host”) opvroegen nadat we werden doorgestuurd naar een andere site.

We hebben dit aangepast.

Ook zagen we dat we http headers aan het meten waren op sites als http://example.nl:443. Dan sturen we dus met opzet een onversleuteld verzoek naar een versleutelde pagina. Een gemiddelde webserver geeft dan een behulpzame waarschuwing dat dit niet is wat je wil. Om ook daar op headers te controleren gaat wel erg ver, dus dat hebben we even uitgezet. We kijken daar wel naar andere dingen zoals versienummers bijvoorbeeld.

De Helpdesk, aflevering 2 – Schunnige subdomeinen en beloftes

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Schunnige subdomeinen bij de overheid?

Dat de overheid veel sites heeft weten we. Een van onze bezoekers wees ons op een mooie website: platformhoutrook.nl. Er werd gewezen op het bestaan van het subdomein “cleavage.platformhoutrook.nl” op onze site en daarna nog wat andere. Mogelijk is dat niet de bedoeling.

Oplossing: Eerst dachten we: misschien heeft iemand bij de overheid gewoon slechte smaak. Hout… houthakken… cleavage… lame. Maar er blijkt iets anders aan de hand te zijn. In de archieven van het domein blijkt dat er talloze subdomeinen zijn aangemaakt: bustywifey, giggles, friendsworld, sniper en honderden anderen. Op de site zelf staan google ads.

Het is duidelijk dat daar iemand met matige bedoelingen bezig is, en gewoon het domein heeft gekocht. Het platform achter deze site is namelijk in rook op opgegaan opgeheven in 2021 en kort daarna begonnen de problemen. We hebben het domein bij ons op verwijderd gezet en alle onderliggende domeinen geofferd aan onze hamsters. Er is ook een mailtje gestuurd aan de maker van de brondata.

Een paar van de vele subdomeinen op het domein dat nu van een ander is.

Er word aan gewerkt!

Soms krijgen we verklaringen binnen waar we graag iets mee willen, maar niets mee kunnen.

Zo kregen we de melding dat men RPKI aan het toevoegen is op een site. Het duurt nog ongeveer vier maanden voordat dit af is. “De doorlooptijd is hoog, maar het staat op de roadmap.”

Oplossing: Supergoed nieuws dat hieraan wordt gewerkt! Dit is namelijk 1 van de paar laatste oranje metingen bij deze organisatie. So close!

De comply or explain functie is bedoeld voor verklaringen waarbij de afwijking iets veilig of veiliger maakt. Het gaat om iets dat “by design” wordt toegepast. Dat is nu niet het geval, daarom kunnen we de bevinding niet wegstrepen.

Een andere reden is dat we geen toezeggingen of beloften willen verwerken in een uitleg. We hebben dit in een ver verleden wel gedaan en daar werd ook goed gebruik van gemaakt. Maar wat je dan ziet is dat het soms niet of verkeerd wordt opgeleverd: dan staat iets ten onrechte als correct op de site. Dit hebben we dus geschrapt.

De Helpdesk, aflevering 1 – Intrusion attacks en beheer op een vreemde poort

In de helpdesk kijken we naar vragen die binnenkomen via de mail en geven we een kort antwoord op vragen die vaker binnenkomen.

Intrusion attacks bij bezoeken site…

De eerste vraag gaat over een firewall. Deze ziet een intrusion attack als we de website bezoeken via http://. Het verkeer via https werd geweigerd. Dus basisbeveiliging ziet alleen een blokkade-website en dat is niet de site die de beheerder verwachtte.

Oplossing: Als je niet gemeten wil worden, dus bijvoorbeeld ip-restricties toepast, dan moet je dat op alle endpoints doen: ook op http://. Ons vermoeden: De firewall herkent ons gewone bezoek niet als een bekend IP, dus blokkeert dat als ‘intrusion’. Maar we zouden deze website helemaal niet mogen zien natuurlijk, want het is maar een gewoon websitebezoek.

Fortinet firewall blokkeert bezoek aan http:// website

Beheer op een vreemde poort

De tweede vraag ging over een vreemd poortnummer. We geven daar een oranje beoordeling aan. De hoster van de site gebruikte dit poortnummer om beheer uit te voeren via het plesk beheersysteem.

Oplossing: Voor iedere vorm van beheer (van overheidssites) raden we een VPN/afgescheiden netwerk aan. Hierdoor is zo’n beheerpanel niet meer bereikbaar via het publieke internet: dus veel minder mensen die het kunnen vinden en er een aanval kunnen uitvoeren. Er zijn natuurlijk regelmatig kwetsbaarheden in dit soort beheerpanelen: ze geliefd door aanvallers.

Op de schermprint zie je geen 2e factor, wat wel gebruikelijk is voor beheerpanelen. Het kan natuurlijk zijn dat je die vraag pas krijgt nadat je een inlogpoging hebt gedaan… of niet.

Plesk inlogpaneel op een vreemd poortnummer

Lubach bezoekt 1800 overheidssites, gelukkig is er nog veel meer!

In deze afgelopen uitzending van de Avondshow met Arjen Lubach wordt het enorme aantal overheidswebsites besproken. Onderzoeker Tex heeft gedaan wat menselijk mogelijk was: alle 1800 sites bezoeken en drie maanden geen daglicht gezien. Dat kon nog in tijden van corona. We weten hoe het voelt.

Het doel was om het antwoord te vinden op een simpele vraag. Maar het kan zijn dat je zelfs na het bezoeken van al deze sites geen antwoord hebt. We zien namelijk dat ieder van die sites gemiddeld zo’n 10 “subdomeinen” heeft met informatie en dienstverlening voor specifieke doelgroepen.

De 1800 sites die zijn bezocht door Tex staan in het websiteregister rijksoverheid. Wat daar niet in staat zijn de sites van gemeenten, provincies, waterschappen, regionale samenwerkingsverbanden (bijvoorbeeld het afvalverwerkingsbedrijf enzo) en alle semi-overheidsbedrijven.

Maar hoeveel sites zijn er dan? Dat weten we ook niet precies: dat weet niemand. In onze database staan zo’n 90.000 adressen, waarvan het ruime overgrote merendeel van de overheid is. Wekelijks komen er meer bij.

Waarom weten we dit?

Wij meten al deze sites op veiligheid. Dat doen we niet meer met menselijke onderzoekers, maar met een heel leger aan hamsters in luxe kooitjes. Zij bezoeken regelmatig de sites om te kijken of ze voldoen aan bijvoorbeeld de basis veiligheidsafspraken.

De resultaten daarvan worden dagelijks gepubliceerd op https://basisbeveiliging.nl.

Onderzoeker Tex die de 1800 sites laat zien tijdens de Avondshow met Arjen Lubach. Beeld van de VPRO via YouTube.

Nieuwe metingen (februari 2023) – Security.txt, RPKI

Security.txt

We kijken en publiceren nu ook metingen over security.txt. We beoordelen deze op drie manieren:

  • Aanwezig: dan is het goed
  • Ontbreekt op een subdomein: dan krijg je een info score (dit is nu groen). Eigenlijk hoort security.txt op alle domeinen en subdomeinen beschikbaar te zijn, maar dat is een klus. Dus we beoordelen alleen het ontbreken op het hoofddomein nu als onvoldoende (oranje).
  • Ontbreekt op domein: je krijgt dan een oranje score. Het niet hebben van een security.txt bestand betekent dat je kritieke informatie over kwetsbaarheden kan missen. Het samenstellen van een security.txt bestand kan o.a. door dit formuliertje in te vullen. Zet dan het bestand op je webserver. We meten dit elke paar dagen. Het oplossen hiervan is vooral procesmatig (wie krijgt de meldingen), het maken en plaatsen van een tekstbestandje is een kwetsie van een paar minuten en een kleine wijziging.

Deze nieuwe meting komt van internet.nl, en is ontwikkeld door dcypher en internet.nl.

RPKI Aanwezigheid

We kijken nu of RPKI aanwezig is voor webservers en e-mail diensten. We beoordelen dit op de volgende manieren:

  • Aanwezig: we keuren het goed. Andere RPKI metingen tonen we niet, het kan dus zijn dat de geldigheid is verlopen of dat de RPKI naar de nameserver niet juist is. Met deze ene meting proberen we het belangrijkste resultaat te vatten. Als iedereen dit goed doet, dan kunnen we de volgende aanzetten.
  • Afwezig: we keuren het als ‘middenmoot’ dus oranje. RPKI is kritiek voor een veilig internet, maar een organisatie kan naast melden/waarschuwen niet direct actie ondernemen omdat de organisatie niet geheel verantwoordelijk is voor het onderliggende internetverkeer. Een organisatie kan wel kiezen om naar een andere hoster te gaan bijvoorbeeld: maar het is makkelijker als groep klanten druk uit te oefenen om dit gewijzigd te krijgen.

Deze nieuwe meting komt van internet.nl, en is ontwikkeld door het Nationaal Cyber Security Centrum (NCSC) en internet.nl.

Zo zien de resultaten eruit

Een niet geslaagde test voor security.txt op het hoofddomein.
Een geslaagde RPKI meting