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