Nieuws

Full Scope Tests voor deelnemers

Vandaag introduceren we Full Scope Tests voor deelnemers van de Internet Cleanup Foundation. Deelnemers kunnen hiermee volledige security scans uitvoeren met bekende security tools.

Resultaten van deze tests kunnen ernstige kwetsbaarheden aan het licht brengen. Ook zijn deze tests intensiever dan de normale tests die we uitvoeren op basisbeveiliging.nl. Dit heeft gevolgen voor wanneer zo’n test gestart kan worden en hoe de rapportage is in te zien. In deze post wordt dat allemaal uitgelegd.

6000 metingen, versleuteld…

De eerste Full Scope Test kan worden gedaan met de tool ‘Nuclei’. Op dit moment is dit een van de populairste security-scanners. We gebruiken deze tool al sinds maart 2023 voor Login Plaza, maar het het kan nog veel meer. Het heeft ongeveer 6000 checks aan boord. Waaronder meer dan 1500 checks op algemeen bekende kwetsbaarheden (CVE’s).

Het verwerken van kritieke kwetsbaarheden vraagt om een nieuwe aanpak. We zijn gewend dat alle informatie rondom metingen publiek is, dus er waren geen maatregelen nodig om informatie te beschermen tegen uitlekken. Bij full scope tests ligt dat anders.

Resultaten van full scope tests worden versleuteld opgeslagen. De enige die de data kan lezen is diegeen met de sleutel. Het is voor ons, noch anderen onmogelijk om resultaten in te zien zonder de sleutel. Zelfs als de database morgen op straat ligt is er dus niets aan de hand. Dat haalt een boel last van ieders schouders. Deze versleuteling gebeurt met NaCl Box.

  1. Wanneer de database uitlekt kan niemand de rapporten bekijken.
  2. Niemand van de Internet Cleanup Foundation kan de rapporten bekijken.
  3. Je kan zien dat de rapportage van ons komt door de publieke sleutel (ieder rapport heeft een eigen publieke sleutel, de prive-sleutel gooien we weg).

Hoe kan je deze rapporten dan toch inzien? Je moet hiervoor het rapport ontsleutelen met een eigen prive-sleutel. Dat kan op je eigen computer maar ook in de browser.

Praktijkvoorbeeld van A tot Z

Stap 1: vrijwaring

Omdat Full Scope Tests intensiever zijn dan de normale tests op basisbeveiliging is het noodzakelijk om de Internet Cleanup Foundation een vrijwaring te geven voor deze tests. De vrijwaring is hier te vinden en wordt opgestuurd naar info@internetcleanup.foundation. Na ondertekening wordt het mogelijk om Full Scope Tests uit te voeren.

Stap 2: instellen publieke sleutel

Om de resultaten veilig op te slaan is het noodakelijk om een publieke sleutel te maken. Dat doe je op deze pagina. Het is op die pagina ook mogelijk om een prive-sleutel te maken. Je kan dat ook op je eigen computer doen op of op een andere website. We geven daar een voorbeeld van op die pagina.

Stap 3: Full Scope Test inplannen

Vanaf nu is het mogelijk om een Full Scope Test in te plannen. Dit gebeurd vanuit het portfolio.

Overzicht van het portfolio met daarop de knop “Plan Full Scope Test”, met de kever.

Na de klikken op de knop wordt het volgende venster getoond. Hierop is in te stellen welke Full Scope Test moet worden uitgevoerd en wordt er gecontroleerd of de juiste voorzorgsmaatregelen zijn genomen. Na het beantwoorden van de alle vragen wordt de “Let’s go!” knop actief.

Stap 4: Wachten tijdens de test

De test is nu aangevraagd en wordt zo snel mogelijk opgepakt. Dit kan, afhankelijk van de drukte, eventjes duren. Meestal zal dit toch binnen een half uur zijn.

Om dit barre half uur door te komen hebben we wat tips om te kijken op YouTube. In willekeurige volgorde een paar leuke filmpjes:

Maar je kan natuurlijk ook iets nuttigs doen met je tijd…


Stap 5: Testresultaten inzien

Het rapport is in te zien op de Sensitive Reports pagina. Hier zie je de meting die we net hebben gestart. Door op de knop “Show Details” te klikken zie je de versleutelde gegevens en de optie om deze te downloaden of te ontsleutelen.

Het downloaden levert dezelfde informatie die je ziet in het “versleutelde gegevens” veld. Je kan dit ook kopieren en plakken en ergens anders ontsleutelen. Let wel op dat je onze publieke sleutel nodig hebt, die staat naast “Ours” en wisselt per rapport.

Stap 6: Testresultaten ontsleutelen (online)

Door het invullen van je prive-sleutel wordt het rapport volledig in de browser ontsleuteld. Het invullen van je prive-sleutel betekent dat je je browser vertrouwt, de plugins in je browser en onze webapplicatie. Als je geen vertrouwen hebt hierin dan kan je naar stap 7 of 8. We raden in ieder geval aan regelmatig de set met sleutels te vervangen.

Door op “ontsleutelen in browser” te klikken wordt het rapport zichtbaar. Het rapport van Nuclei Full Scope Tests heeft een overzicht in een tabel en als kaartenbak.

Kaartenbakweergave:

Bevindingen in kaartenbakweergave

Tabelweergave, doorzoekbaar:

Bevindingen in tabelweergave

Je in bovenstaande screenshots dat er allerlei risico’s zijn gevonden. In dit voorbeeld zijn ze allemaal inschat op het risiconiveau “info”. Iedere tool heeft een eigen gradatie in risico’s. Deze wijken af van elkaar, en wijken af van basisbeveiliging.nl omdat de scope anders (intensiever) is. Wij raden sterk aan om alle bevinden door te nemen, omdat soms vele lage risico’s soms samen een groot risico vormen.

Stap 7: Testresultaten ontsleutelen (elders)

Als je de gegevens in de browser wil ontsleutelen, dan is het mogelijk deze te kopieren of te downloaden en elders te ontsleutelen.

Iedere implementatie van NaCl (zoals Libsodium) kan worden gebruikt om het bestand te ontsleutelen. Hieronder zie je twee voorbeelden. De eerste is de interface van TweetNaCl. Daaronder zie je een python script wat je kan gebruiken om e.e.a. te ontsleutelen.

Ontsleuteling van het rapport in de test-interface van TweetNaCl

Stap 8: Testresultaten ontsleutelen (lokaal)

Met het volgende python3 script en het installeren van PyNacl kan je het rapport ontsleutelen. Er zijn ook gebruikersinterfaces die hetzelfde doen. Je kan er naar zoeken. De toverwoorden zijn: NaCl, LibSodium en xsalsa20.

# Decrypts a file
# python3 decrypt.py --their_public_key="3pFkpZ8X1NKWCwZB3uEPhhZvmejrySVPWozBgLrUjzw=" --my_private_key="..." file

import argparse

import nacl.encoding
from nacl.public import Box, PrivateKey, PublicKey

parser = argparse.ArgumentParser(
    prog='decrypt.py', description='Decrypt NaCl files, show output in console', epilog='Internet Cleanup Foundation'
)
parser.add_argument('--their_public_key')
parser.add_argument('--my_private_key')
parser.add_argument('filename')
args = parser.parse_args()


def decrypt(their_public_key, my_private_key, file):
    their_public_key = PublicKey(bytes(their_public_key, 'utf-8'), encoder=nacl.encoding.Base64Encoder)
    my_private_key = PrivateKey(bytes(my_private_key, 'utf-8'), encoder=nacl.encoding.Base64Encoder)

    with open(file, 'rb') as f:
        file_data = f.read()

    try:
        the_box = Box(my_private_key, their_public_key)
        encrypted_data = the_box.decrypt(file_data)
    except nacl.exceptions.CryptoError as e:
        print(f"Could not decrypt file. Are the keys correct? Error received: {e}.")
        raise nacl.exceptions.CryptoError from e

    print("Decrypted file. Content is displayed below:")
    print("--------- Begin decrypted content")
    print(encrypted_data.decode('utf-8'))
    print("--------- End decrypted content")


if __name__ == '__main__':
    decrypt(args.their_public_key, args.my_private_key, args.filename)

Alleen voor deelnemers

Deelnemers van de Internet Cleanup Foundation hebben toegang tot Basisbeveiliging+. Zo weten we dat alleen de juiste omgevingen worden getest onder de juiste voorwaarden. Wil je deelnemer worden? Kijk dan voor meer informatie op de deelnemerschap pagina.

Vooraankondiging nieuwe meting: locatie van dienstverlening binnen/buiten NL en EU

Onlangs hebben we een meting toegevoegd waarmee te zien is of een website op zichzelf staat, of dat bezoekers gevolgd worden door bedrijven die ook in de advertentiebusiness zitten.

We zijn deze meting aan het finetunen en afronden met een artikel hierover. Ondertussen zijn we bezig met een vervolg hierop. Dit vervolg wordt in de komende weken/maanden uitgerold en heeft alles te maken met locaties van online diensten.

Het ultieme doel is dat de online-overheid uitsluitend in de EU of Nederland opereert, behalve waar het logisch of redelijk is dat dit niet gebeurd (denk aan een KNMI meetproject in Azië). Dit is in lijn met de GDPR-wet en de bijbehorende trend om alles binnen Nederland of de EU te krijgen.

We gaan controleren op twee verschillende punten: de locatie van servers en de locatie van de inhoud van de voorpagina van websites. Hieruit halen we ip-adressen.

Deze adressen zoeken we op in een database waarin staat welk adres in welk land actief is. Deze database wordt op een complexe manier samengesteld: het is een mix van administratieve gegevens en kennis van hoe het internet op dit moment in elkaar zit. Voor de geïnteresseerden: de technische term is “ip geolocation”.

Een tipje van de sluier:

Op basis van ip-adressen en de locaties hiervan zien we dat er een klein percentage van servers buiten de EU staat. 3% van alle door ons gemeten ip adressen leidt naar de Verenigde Staten en een verwaarloosbaar percentage elders. Van de servers met een locatie anders dan US/EU zijn er een aantal legitiem en een paar ook niet. We zullen hier nog een mailtje over sturen naar de eigenaren van die servers. We hebben nog geen cijfers over  de inhoud van websites.

Eigenaar van 8% overheidsdomeinen onduidelijk (Mei 2023)

Bij 8% van de overheidsdomeinen is het niet te achterhalen of de overheid eigenaar is. Dat is te verdelen in twee categorien: er zijn 95 domeinen zonder informatie en 68 domeinen met een onjuiste eigenaar.

Juiste houderinformatie geeft vertrouwen: iemand kan hierdoor checken of de site eigendom is van de overheid. De overheid heeft nog een andere reden om eigenaar te zijn: zelf bepalen wat er met een domein gebeurt nadat een project of contract afloopt.

Dit is het overzicht van eigendom van domeinen op dit moment:

OverheidDomeinenGeen eigenaarOnjuiste eigenaarJuiste eigenaar
Gemeenten431328391
Provincies132011
Overheid154661601425
TOTAAL199095 (4.77%)68 (3.41%)1827 (91.81%)
Overzichtstabel juistheid houders van domeinen.

Houder van een domein

Iedere domeinnaam is uniek en heeft een eigenaar. De adminstratie van alle .nl domeinen zoals rijksoverheid.nl wordt bijgehouden door “Stichting Internet Domeinregistratie Nederland”: SIDN.

Om te zien wie eigenaar is van een domein kan je op de site van het SIDN de administratie doorzoeken. In het onderstaande voorbeeld zie je het zoekresultaat voor de site “rijksoverheid.nl”.

Screenshot met de houdergegevens van rijksoverheid.nl. Je kan dit zelf proberen op de site https://www.sidn.nl/nl-domeinnaam/domeinnaam-zoeken/

In het screenshot zit een highlight op de informatie uit het “houder” veld: “Rijksoverheid”, dit is de naam van de eigenaar van het domein.

De nieuwe meting op basisbeveiliging.nl controleert of de eigenaar van het domein juist is. Hieruit kunnen drie conclusies komen:

  • Geen eigenaar: het is niet te zien van wie het domein is omdat het “Houder” veld leeg is. Dit wordt beoordeeld met Oranje.
  • Onjuiste eigenaar: een tussenpartij, een persoon, een onduidelijke organisatie of een geanonimiseerde organisatie (en nog wat andere gevallen) is allemaal onjuist. Dit wordt beoordeeld met Oranje. Wij verwachten dat “Gemeente Texel” eigenaar is van “texel.nl”.
  • Juiste eigenaar: Is de registratie in te zien en behoort die tot een van de goedgekeurde organisaties? Dan wordt dat beoordeeld als Groen.

Bepaling van de meting

Het is lastig om te bepalen wie de juiste eigenaar is. Dat gebeurd dan ook voor een deel met de hand. Dit is een detail-overzicht van hoe we de juiste eigenaar vaststellen.

In deze gevallen zien wij de juiste eigenaar:

  • De houder is ongeveer hetzelfde als het domein. Bijvoorbeeld “rijksoverheid” op “rijksoverheid.nl”.
  • De houder is een overheidsorganisatie, ziekenhuis of andere aanverwante entiteit.
  • De houder is een bedrijf/organisatie en deze staat genoemd op de voorpagina van de site of onder contactgegevens. Bijvoorbeeld in het e-mail adres of bij de copyright informatie.
  • Sites met een rijksoverheidslogo mogen alleen op een naam van een overheid staan.
  • De houder bestaat uit een onbekend deel, maar ook een bekend deel zoals: “TweeToffePeren B.V. i.o. Rijkswaterstaat” op een site van Rijkswaterstaat.
  • Bij onduidelijkheden wordt altijd kort gezocht naar wie de eigenaar is. Bijvoorbeeld kan bij ICT-samenwerkingsverbanden de gebruikte naam niet direct worden herleid omdat er een “abstracte” naam wordt gebruikt waar geen van de deelnemers wordt genoemd.

In deze gevallen zien we een onjuiste eigenaar:

  • Bedrijfsnaam van een ontwikkelbedrijf, consultancybedrijf, juristenbureau of andere ontwikkelaar. “TweeToffePeren B.V.” terwijl de site zegt: Rijkswaterstaat.
  • Namen van personen.
  • Afgeschermde gegevens. Houder hoeft niet afgeschermd te zijn omdat het altijd gaat over namen van organisaties.
  • Namen van organisaties die geen of ‘generieke’ resultaten hebben in zoekmachines. Het is dus niet duidelijk van wie het is.
  • Onherleidbare informatie als “Crediteurenadministratie X-12391”.
  • Een leeg veld.
In dit voorbeeld staat dat de eigenaar onbekend is. Er staat “Privacy protected by Hostnet”. De juiste houder zou “Trimbos-Instituut” kunnen zijn, of een andere organisatie in dezelfde strekking.

Dank aan SIDN

Informatie over eigenaarschap is afkomstig uit de WHOIS database van Stichting Internet Domeinregistratie Nederland (SIDN) en wordt verwerkt en gepubliceerd met toestemming.

Je kan controleren van wie een domein is op de volgende pagina: https://www.sidn.nl/nl-domeinnaam/domeinnaam-zoeken/

Bij iedere meting wordt verwezen naar het WHOIS register van het SIDN als second opinion.

Updates (mei 2023)

Nieuwe subdomein scanner OWASP amass is toevoegd. Hiermee kan op tientallen manieren naar subdomeinen worden gezocht. Komen we daarmee eindelijk op de 100.000 overheidsdomeinen?

Domeininformatie van het SIDN wordt nu ingelezen. Dit om verlopen / uit handen gegeven domeinen te kunnen herkennen en makkelijk te kunnen verwijderen. Dank aan de SIDN voor het bieden van de who-is api.

Een domein dat van eigenaar is veranderd. Hier zie je dat het domein opnieuw is geregistreerd sinds dat we het monitoren. We kunnen dit domein en alle subdomeinen in 1x verwijderen. Dat maakt het onderhoud van de site behapbaar.

De website ondersteunt nu geolocatie: dus je kan makkelijk vinden welke organisaties in jouw buurt zitten zonder de kaart te hoeven doorzoeken. Geolocatie wordt gebruikt op de voorpagina en op de kaarten-pagina. Mogelijk binnenkort ook nog op andere pagina’s.

Geolocatie op de voorpagina. In Arnhem zie je een gemeenschappelijke regeling, de gemeenten arnhem, rheden, westervoort en lingewaard, daarna meer regelingen en ook bijvoorbeeld het Rijnstate ziekenhuis.
Op de gemeentekaart zie je alleen de gemeenten om je heen.

De voortgang-pagina is opgeruimd en heeft nu permanente links. Je kan nu direct zien wat de toename is van security.txt voor bijvoorbeeld gemeenten en provinices.

Op de voortgang pagina is te zien dat het aantal security.txt toepassingen is gestegen van 28 naar 41. Er zijn ook kleine getallen linksonder op de kaart geplaatst waarmee je snel kan zien wat de absolute aantallen zijn.

Aanpassingen in metingen

De bannergrab scanner is bijgewerkt, waardoor bevindingen worden opgeslagen als https/443 als http/443 wordt gevonden. Wij gebruiken “https” als protocol waar nmap vaak “http” ziet omdat de webserver een “http” status pagina geeft waarop staat dat je de site via “https” moet bezoeken.

Idem zijn de protocollen ‘gnutella’, ‘ssl’ en ‘ms-wbt-server’ teruggebracht naar https. De 160.000 endpoints hiervoor zijn verwijderd en de metingen komen terug op https endpoints.

Aanpassingen in django admin

De endpoint pagina is versneld, zoeken op endpoints is versneld.

Er is een bug gefixt waardoor niets meer kon worden opgeslagen van nieuwe scans. Je kan in de onderstaande grafiek zien wanneer die bug was opgelost:

Nieuwe uitzonderingen

We blijven er wel op meten, maar strepen eventuele bevindingen weg op de volgende plaatsen:

Poort 8443 mag open staan voor vpn doeleinden. Dit zien wij onder subdomeinen als ‘thuiswerken’, ‘telewerken’, ‘vpn’, ‘werkplek’ enzovoorts.

Het subdomein ‘sip’ hoeft geen http security headers meer te hebben.

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.