Pentest miste zwak wachtwoord bij ransomwareaanval op gemeente Hof van Twente

De gemeente Hof van Twente maakte gebruik van zwakke wachtwoorden en ingehuurde pentesters hebben deze problemen niet geconstateerd. Daardoor kon de gemeente worden getroffen door ransomware. Er zijn volgens onderzoekers meerdere problemen gevonden.

De ransomwarecriminelen kwamen bij de gemeente binnen via een server waar het Remote Desktop Protocol open stond. In oktober 2019 werd die poort door de gemeente open gezet. Later werd het wachtwoord van een ftp-account voor die server veranderd naar Welkom2020. Criminelen konden dat gemakkelijk kraken met een bruteforce-aanval. Ook was er een account genaamd 'testadmin' met volledige adminrechten dat de aanvallers gebruikten om door het netwerk te bewegen, zegt de gemeente woensdag tijdens een persconferentie. Inmiddels is het rapport over de hack ook openbaar gemaakt.

De gemeente liet een extern rapport opstellen naar aanleiding van een ransomwareaanval die in december plaatsvond. Daardoor waren systemen niet meer bereikbaar. Uit het rapport blijkt dat er verschillende kwetsbaarheden bij de gemeente waren te vinden, zoals het slechte wachtwoord. Ook was het netwerk niet gesegmenteerd en werd er niet actief gemonitord op verdachte activiteiten.

Naast de gemeente zelf krijgt ook Sogeti kritiek. Dat bedrijf voerde in mei vorig jaar een pentest uit in opdracht van de gemeente, maar daarbij werden geen grote kwetsbaarheden ontdekt. Bij de pentest werd bijvoorbeeld niet gekeken naar de specifieke server die nu werd aangevallen. De onderzoekers zeggen niet te kunnen achterhalen hoe de pentest destijds is uitgevoerd, omdat het daarbij om een zelfontworpen methode ging. Daardoor is de test moeilijk te controleren.

De gemeente steekt de hand deels in eigen boezem. Hof van Twente noemt de hack 'een stevige les' en zegt dat er 'een kloof was tussen de veiligheid van het systeem zoals deze beleefd werd door de gemeente en de daadwerkelijke technische situatie'. "Er was sprake van een relatie gebaseerd op onderling vertrouwen en daarbinnen rolsonduidelijkheid tussen de gemeente en de externe partij die het beheer en de beveiliging regelde", schrijft de gemeente. Ongeautoriseerde toegang 'had voorkomen kunnen worden', stelt de gemeente.

Reacties (181)

[iDennis3D]

Het is echt te makkelijk om dit op de pentest af te schuiven.

Het is een gebrek aan (wachtwoord)beleid,
Vulnerability management en Awareness bij de beheerder.

Als een RDP poort vanaf het Internet open staat, dan zouden alle alarmbellen moeten gaan rinkelen. Hier zijn hele eenvoudige oplossingen voor die slechts een paar tientjes per maand kosten.(bv Hacker-Target).

Hoeveel zou de gemeente hebben geïnvesteerd in ICT Security trainingen en Awareness trainingen voor beheerders?!

[Djerro123]

Waar het meestal prat gaat hierin is niet de pentest maar de algehele rolverdeling tussen klant en outsource partij. Deze gemeente heeft waarschijnlijk geen enkel technisch persoon in dienst, enkel wat service managers en contract managers. Dat betekent dat ze volledig afhankelijk zijn van de outsourcings partij.

Het probleem met outsourcen is dat je veelal een opsomming van taken outsourced en geen verantwoordelijkheden. Je kan moeilijk zeggen "ik betaal je X per maand en dan ben jij verantwoordelijk voor mijn Security". dat is namelijk te vaag en te veranderlijk om zo af te spreken.

Je kan enkel afspreken wat je van die partij verwacht; ik verwacht patch en update management en uitvoering, ik verwacht marktstandaarden, lifecycle activiteiten etc. Aan die activiteiten worden een prijskaartje gehangen.

De IT partij genaamd Switch IT Solutions is hier absoluut verantwoordelijk als zij de beheer partij zijn van deze server. Een server met een testadmin account? Come on, ik zou een hartig woordje spreken met het desbetreffende team die dat door de vingers heeft laten slippen. Dit komt standaard naar voren bij simpel vulnerability management, dat hebben ze duidelijk niet voor elkaar hier.

[Tomas_]

Dit klopt niet. er zijn wel degelijke interne beheerders. Het is ook een van de interne beheerders die het wachtwoord heeft gezet en de firewall heeft aangepast.

Daarnaast was het niet het ftp account, maar een "testadmin" account met het wachtwoord.

bron: https://www.tubantia.nl/h...zelf-te-wijten~a1901c825/

[Reactie gewijzigd door Tomas_ op 24 juli 2024 13:42]

[Oyxl]

quote mezelf

Dit soort verzoeken (open zetten RDP) gaan standaard langs de CISO's van beide partijen. Waarschijnlijk is hier gewoon een waiver voor getekend, omdat het persé moest van de gemeente.

Of er is geen waiver getekend en men doet maar gewoon wat met intern personeel, dat kan natuurlijk ook:P

[Djerro123]

Maar dat is dus exact mijn punt: hoe kan je TAB in eigen beheer houden maar OS verantwoordelijkheid beleggen bij een andere partij? Dat is zo nauw met elkaar verbonden, dan krijg je dus dit soort gaten.

Ik heb zelf de oplossing ook niet hoor, anders zou ik daar veel geld mee verdienen;) maar dit zijn wel degelijk problemen. En geloof me als ik zeg dat er 60x in de winnende aanbestedingsdocumenten heeft gestaan dat ze staan voor "partnership", "ontzorgen" en "samen". Die hele markt is een rare wassen neus en het is eigenlijk bizar dat we nog steeds, na al die jaren, nog steeds geen standaard outsourcing frameworks hebben.

[Tomas_]

Eens dat gaat ook niet werken. Ik ken meerdere bedrijven die nog steeds geen 2 factor hebben op hun Citrix login bijvoorbeeld. Maar ook geen updates op infrastructuur devices.

Inderdaad standaard frameworks is de oplossing, zeker omdat ze allemaal standaard dezelfde fouten maken.

Eigenlijk overal waar ik kom als infra consultant zijn ze gewoon niet in control van de omgeving.

[Reactie gewijzigd door Tomas_ op 24 juli 2024 13:42]

[mjtdevries]

Heel goed punt wat je hier aankaart.
Ik denk zelfs dat de meeste problemen met IT bij de overheid te verklaren zijn doordat ze veel te veel outsourced hebben.
Dan heb je zelf de kennis niet meer om te beoordelen of een externe partij wel goed werk levert. En je mist die kennis ook bij al die nieuwe projecten die door externe partijen gedaan worden. Ze kunnen je van alls op de mouw spelden wat betreft kosten, complexiteit, doorlooptijd etc etc.

[Oyxl]

Dit soort verzoeken (open zetten RDP) gaan standaard langs de CISO's van beide partijen. Waarschijnlijk is hier gewoon een waiver voor getekend, omdat het persé moest van de gemeente.

[batjes]

Het is wel waarom de overheid steeds meer IT in eigen handen neemt. Er wordt al heel wat minder uitbesteed naar de Caps en Ordina's. Veel nieuwe projecten lopen via overheids eigen IT afdelingen.

[mjtdevries]

Ik heb zowiezo nooit begrepen waarom de overheid zoveel outsourced.
Dat is per definitie veel duurder dan het zelf doen, omdat die derde partij er winst uit wil (moet) halen.

Outsourcing is interessant als je bedrijf te klein is om dedicated experts in te huren.
Maar al die overheids organisaties zijn gigantisch groot. (Een beetje gemeente heeft veel meer mensen in dienst dan een grote multinational in Nederland heeft)

Al die overheidsorganisaties zijn zo groot dat er ook geen schaalvoordeel te behalen is voor de toko waarnaar je het outsourced.

De overheid zou ook prima zelf beveiligingsexpert kunnen aannemen die pentest diensten aan andere overheidstakken aan kunnen bieden voor een fractie van het geld dat commerciele partijen hiervoor vragen.

Probleem blijft natuurlijk wel dat grapjes over ambtenaren niet zomaar ontstaan zijn

[d3burt]

Ik denk dat je de grootte van gemeentelijke organisaties overschat (en onderschat hoe groot de puinhoop is bij veel bedrijven van vergelijkbare omvang).

Het grote probleem met het zowel inhuren van eigen beheerders als het uitbesteden van beheerswerk is dat de meeste gemeenten (en bedrijven van vergelijkbare omgang) niet de expertise hebben om de kwaliteit van de sollicitant of inschijver te kunnen bepalen.

Vraag maar eens aan een willekeurige beslissingsmaker bij uitbesteding of de ingehuurde partij een ISO-27001 certificaat heeft. "Natuurlijk, we willen het wel veilig houden". Vraag dan maar eens of de klant infrastructuur in scope is bij dat certificaat. Je krijgt bijna gegarandeerd een schaapachtige blik terug.

Er zijn in Nederland volgens het CBS 42.645 bedrijven met tussen de 50 en 250 werknemers. Er zijn domweg niet zoveel gekwalificeerde beheerders, dus er vallen gegarandeerd ergens gaten.

O, en ik heb zeer gekwalificeerde mensen zeer domme dingen zien doen...

[mjtdevries]

Gemeentelijke organisaties zijn al snel duizenden mensen, ipv tussen de 50 en 250 zoals bij de meeste bedrijven.
Gemeente Almere zit op zo'n 1800 werknemers en dat is klein in verhouding.

Verder zijn we het volgens mij eens. Dat ze de kennis missen doordat ze zoveel outsourced hebben, heb ik eerder in deze thread zelf al aangekaart.

[Marcel Br]

En voor deze onterechte en weerlegde aannames wordt +3 gegeven

[wimjongil]

Werknemer van Sogeti gespot

[iDennis3D]

Haha, nee hoor, gelukkig niet.

Wel iemand die opdrachten voor pentesten geeft, en die weet wat je van een pentest mag en kan verwachten:-)

[dj.verhulst]

ik heb ooit bij diverse gemeentes als extern gewerkt het is echt heel droevig wat ik daar gezien, wethouders krijgen de portefeuille ICT terwijl ze een bloemenwinkel hebben gehad,, jij mag dan alles vraagstukken oplossen maar zit niet bij de vergaderingen , besluiten word je meestal niet of heel laat bij betrokken , ik zag ook derden misbruik maken van dit soort situaties.

iemand beslist dat ze wel wat MBO'ers dingen kunnen laten doen ,, maar betalen ze matig de goede vertrekken ,, men snap niet dat goede ict'ers geld kosten dan nemen ze wat ze kunnen krijgen en vaak politiek correcte argumenten gebruikt ,, heb maanden ergens 1 of 2 dagen in de week ergens gezeten om iemand die op die manier aangenomen was te ondersteunen , en ze lieten ook dingen bewust liggen tot ik er was, en meer uren maken om alles gedaan te krijgen was ook zo'n drama ,, heb ook wel eens gratis gezeten omdat er papieren er door moesten voor iemand die bijzondere problemen had en dit niet kon wachten dat ik er weer was ,, word door de mensen daar super gewaardeerd en hogerop denkt hay thx , puur omdat je wil dat mensen de zorg krijgen die ze nodig hebben , omdat ergens documenten blijven hangen . je kan vaak alleen het meest nijpende doen.

[Oyxl]

Misschien moet je er even een coherent verhaal van maken, waaruit blijkt dat je geen MBO'er bent....

[dj.verhulst]

heb last van een vorm van dyslectie,,, bedankt voor het herinneren .... was ik ff vergeten

[Oyxl]

Ahh, het dyslexie excuus. Het vreemde is, dyslexie doet helemaal niets met je punten en comma's. Dyslexie heeft weliswaar te maken met woord en zinsbouw, maar je weet verdomde goed waar je die punten en komma's plaatst en zelfs dat lukt amper.

Het doet ook vrij weinig met wát je wil zeggen, slechts met hoe het er uit komt. Dit incoherente verhaal is gewoon niet te volgen en dat betekent dat het verhaal dat zich in je hersenen heeft gevormd ook niet coherent was. Dat is wel een gradatie verder dan simpelweg dyslexie.

[Reactie gewijzigd door Oyxl op 24 juli 2024 13:42]

[robenroute]

[dj.verhulst]

ah je ben een expert ......

[winux]

Een pentest bevat altijd een scope waarin de onderzoekers zich mogen bewegen. Zonder deze informatie over de scope is het lastig te bepalen of dit toe te rekenen is aan de pentesters of pentest organisatie.

[Orangelights23]

Pentester hier. Dit is inderdaad wat ik wou melden. Het komt zelden voor dat je dmv bruteforcing ergens binnen probeert te komen, simpelweg omdat dat de scope niet is. Heel veel pentests zijn tegenwoordig white box, waardoor je al ‘binnen’ in de applicatie bent. Het hele gedeelte omtrent autenticatie en authenticeren wordt overgeslagen en daardoor worden dit soort bevindingen niet geconstateerd. Bij de black box pentests proberen we het uiteraard wel dmv wordlists, alleen vinden organisaties het vaak te duur om duizenden euro’s te betalen voor slechts een poging om binnen te komen.

[Moartn]

Uiteraard is de scope relevant, maar dat zou betekenen dat al deze zaken buiten scope vallen:
- Openstaande RDP
- Zwak wachtwoordbeleid
- Ontbreken van MFA
- Volledig open intern netwerk (als je eenmaal binnen bent kun je overal bij)

Dat lijkt me toch sterk.

[winux]

Mee eens. Echter blijft de afgesproken scope wel relevant. Deze komt tot stand in overleg met beide partijen, opdrachtgever en opdrachtnemer. En vaak komt deze tot stand op basis van de kennis welke bij de opdrachtgever bekent is.

Ter illustratie: (en nogmaals zonder de opdracht en de scope is het heel lastig conclusies trekken)
- Wanneer het asset management niet op orde is of niet bekent is bij de opdrachtgever, zal de scope daarop gebaseerd zijn.
- Juridisch zaken afvangen blijft nog steeds een verdien model van opdrachtnemers (pentesters en andere leveranciers). Daar wordt vaak ook op gestuurd in de scope.
- Er worden ook vaak bepaalde assets buiten de scope gelaten. Dit kan meerdere redenen hebben, in ergste geval omdat men op voorhand al weet dat asset niet veilig is, maar men geen oplossing heeft. En men redeneert, wat niet bekent is hoeft ook niet opgelost te worden.

Vaak denkt men, ik laat een pentest uit voeren, want dat schrijft de jaarlijkse audit voor. Dus voldoen we aan audit en krijgen we een groen vinkje. Echter moet men wel beseffen dat de verantwoordelijkheid altijd bij de eigen organisatie ligt. En dat men moet weten waar men mee bezig is.

Alle middelen, pentest, audit, baselines, vulnerability scans enz zijn tools om inzicht te krijgen hoe de beveiliging erbij staat, maar het is nooit een oplossing om achter over te gaan leunen.

Buiten dit alles, blijft het lastig te zijn om hieruit te concluderen wie hier blaam treft.

[dezejongeman]

Sterker nog als een pentester buiten de scope te werk gaat, kan hij zelfs op eem juridisch vlak terecht komen dat het niet mag en de wet overtreed.

Daarnaast is er bij zoiets ook een aantal uren of budget welke grenzen aan de opdracht geven. Kortom de scope kennen is noodzaak om een oordeel te kunnen vellen.

[Anoniem: 455617]

Qua falen van beveiliging kijk ik nagenoeg nergens van op. Veel organisaties hebben gewoon boter op hun hoofd. Er is simpelweg nog steeds onvoldoende aandacht voor in de breedte van de meeste organisaties. En dat is niet alleen bij het management maar ook bij het personeel op de werkvloer.

Veel mensen denken nog steeds dat als er regels en procedures bestaan dat het dan wel snor zit. Ze realiseren zich niet dat regels en procedures niks betekenen als je de naleving daarvan niet zekert. En dat is lastiger dan veel mensen denken. Om dat voor elkaar te krijgen zijn er meerdere aspecten van belang, zoals o.a.

• Zorgen dat iedereen in de organisatie doordrenkt word van het belang van goede naleving; iemand die het nut van regels en procedures niet inziet zal veel eerder geneigd zijn om daar laks mee om te gaan
• Zorgen dat de additionele impact van de naleving op de medewerkers zo klein mogelijk is; maak het niet ingewikkelder dan nodig en zorg dat de mensen de benodigde tools (en skills) hebben
• Frequente audits, en dan niet alleen papieren audits die checken of zaken formeel correct beschreven zijn, maar ook echte audits op de werkvloer die controleren of de regels correct worden toegepast
• Sancties; het moet duidelijk zijn dat niet naleven van regels en procedures leidt tot sancties. Het moet echter ook duidelijk zijn dat dit alleen een laatste redmiddel is.

Vooral het eerste item kost veel tijd om te realiseren. Het is ook een continue proces, het gaat nl. over motiveren van mensen en dat is net zoals kennis een een eigenschap die weglekt als je er niet continue aan werkt. En dat gaat veel verder dan b.v. elk half jaar iedereen een linkje sturen om een online "training" te volgen en ze te laten beloven dat ze netjes volgens de regels werken. Dit moet persoonlijk, interactief en repetitief gebeuren, anders komt de boodschap niet bij iedereen aan.

Al deze aspecten moet je op orde hebben om de kans op problemen te minimaliseren. Deze benadering werkt niet alleen voor beveiliging maar voor alles waar regels en procedures van toepassing zijn zoals kwaliteitsbewaking, legal compliance, normering/certificering etc. etc.

[Niemand_Anders]

Je op een groot aantal punten gelijk, maar er is geen excuus voor zwakke wachtwoorden. Als je kan inloggen op RDP verwacht ik dat er een domain controller zal draaien. Via active directory is het kinderspel om sterke wachtwoorden af te dwingen. Als het om een collectie 'losse' computers gaat, zelfs dan kan een systeembeheerder redelijk wat group policies instellen.

Rotatie van wachtwoorden vind ik altijd een lastige. Aan de ene kant ik willen dan een medewerker elke 2 tot 3 maanden een nieuw (sterk) wachtwoord moet kiezen, waarbij de laatste 10 wachtwoorden niet meer zijn toegestaan. Maar aan de andere kant vergroot dat juist weer de kans dat medewerkers hun wachtwoord gaan opslaan. Bij ons op kantoor hebben we daarom gekozen dat je wachtwoord maximaal een jaar geldig is, maar daarbij is het minimum aantal karakters van 8 naar 10 gegaan..

Een goed geconfigureerd bedrijfsnetwerk dwingt procedures grotendeels af zoals wachtwoord management, rechten beheer, RDP access, etc. Uiteraard is er ook een sociaal onderdeel, maar de gevolgen daarvan kun je beperken door goed beheer. Wij gaan er vanuit gegaan dat van iedereen zijn wachtwoord bekend is. Vervolgens via nmap alle SMB machines in kaart gebracht en vervolgens gekeken welke shares en directories elke gebruiker kan benaderen..

Maar in dit geval betrof het een pentest en niet een audit. Bij een pentest verwacht ik dat men op z'n minst een brute-force attack uitvoert op het systeem. Een goede ingang is altijd de mailserver. Vrijwel elk bedrijf of organisatie heeft emailadressen op de website staan. Vervolgens connect je met de mailserver en kijk je eerst welke smtp software er wordt gebruikt waardoor je weet of je slechts het username gedeelte van het emailadres moet gebruiken of het volledige emailadres van de persoon als username.

Als je eenmaal een mailbox hebt gekraakt, kun je andere personen binnen de organisatie vinden. Bij grotere bedrijven betreft het vaak een exchange server welke gekoppeld is aan de active directory (eventueel via federatie) en vaak zijn exchange mailaccounts zijn ook bruikbaar als Windows login..

Tegenwoordig moet iedereen zijn mail altijd en overal kunnen lezen. Vele gebruiken daarom een imap account. Alleen bij imap blijven standaard alle berichten op de mailserver staan, waardoor dit een waardevol archief is voor hackers. pop3-clients doen standaard na het ophalen van de mail, de mail op de server verwijderen.

[iKiddo]

Bij ons op kantoor hebben we daarom gekozen dat je wachtwoord maximaal een jaar geldig is, maar daarbij is het minimum aantal karakters van 8 naar 10 gegaan..

Welkom2020 voldoet aan allebei die criteria.

Maar in dit geval betrof het een pentest en niet een audit. Bij een pentest verwacht ik dat men op z'n minst een brute-force attack uitvoert op het systeem.

Opdrachtgever bepaalt de scope van een pentest. Dus je kan wel verwachten dat een brute-force attack wordt gedaan, maar zo werkt het niet. Wachtwoorden bruteforcen wordt maar zelden gepentest, want we hebben wachtwoordbeleid, toch?

Een goede ingang is altijd de mailserver.

Dit is precies het probleem met pentesten als verdedigingslinie: als ze een pentest op de mailserver hadden laten uitvoeren, dan waren ze nog steeds niet tegen het probleem aangelopen waarmee ze zijn binnengekomen. Want dat was een ftp-account dat openstond op hun rdp server (of zoiets vaag).

[Reactie gewijzigd door iKiddo op 24 juli 2024 13:42]

[kodak]

Hoezo lijkt het je sterk? Een pentest is niet hetzelfde als alles testen. Dat kost tijd maar ook geld en andere middelen en lang niet iedere organisatie heeft dan genoeg om alles te willen laten onderzoeken. Dit soort testen hangt dus heel erg af van wat een opdrachtgever belangrijk genoeg lijkt en wat een bedrijf ze uitlegt wat ze wel en niet doen bij een bedrag en tijd.

[Delay]

Volgens het artikel viel de hele server waar RDP op open stond buiten de scope.

[Ge Someone]

- Openstaande RDP
- Zwak wachtwoordbeleid

Tja, het wachtwoord "Welkom2020" voldoet wel aan: hoofdletter, kleine letter, cijfer en lengte. Ik denk dat het probleem toch vooral de brute force mogelijkheid was.
Dat RDP was open gezet in een firewall is niet opgemerkt omdat het desbetreffende IP-adres niet getest is.

Je kunt je op zo'n manier wel afvragen wat het nut van een penetratie-test is.

[JaymzHetfield]

Uit het rapport van De Winter: "Voor de aanval op het netwerk van Hof van Twente blijkt er een zogenaamde penetratietest uitgevoerd.Daarbij kijken beveiligingsonderzoekers naar zwakheden in de systemen. In het onderzoek wordt de server onderzocht, waarop later door de aanvaller zal worden ingebroken. ..."

[asing]

Het moet wel in de opdracht staan he? Een pentester voert uit wat je wilt. Als je een webserver draait en je vraagt of ze de website willen pentesten, dan kijken ze of ze via de webserver kunnen inbreken. Een zwak wachtwoord zit niet in de scope, er wordt niet naar gezocht en het wordt ook niet gevonden.

In dit geval is er een probleem met het uitvoeren van het beleid van HvT. Dat moet regels stellen aan de wachtwoorden en dat ook zo instellen. Dat ze gehackt zijn is hun eigen verantwoordelijkheid en moeten ze niet in de schoenen van de pentesters schuiven.

Dat laatste geldt niet als zwakke wachtwoorden ook tot de pentest horen. Dat is echter nogal heftig omdat je dan een rainbow table attack moet uitvoeren tegen de SAM database op de machine.

[K-aroq]

Maar een beetje test auditor adviseert ook. Een pentester die niet op zwakker wachtwoorden test is zijn geld niet waard. De tester waar ik mee heb gewerkt laten alles los op een systeem wat ze kunnen bedenken. Vooraf keuzes maken is de grootste fout die je kunt maken. Hackers gaan ook niet proberen via de meest voor de hand liggende manier binnen te komen.

[Chrisz]

Ik werk al geruime tijd als pentester en heb ook veel samengewerkt met IT auditors en ik kan je vertellen dat dit echt twee aparte takken van sport zijn. Een auditor vraagt in veel gevallen ook een dump uit de Active Directory op en zal dan een check doen of er zwakke wachtwoorden tussen zitten en of dus de policies nagestreeft worden.

Voor een pentester is dit veel te beleidsmatig, een pentester is praktischer en zal waar hij bij kan/mag (volgens de scope) bijvoorbeeld proberen om met bekende usernames en wachtwoorden proberen binnen te komen. Je kunt een pentest zien als een hacksimulatie op specifieke machines binnen een bepaalde tijd, wachtwoorden uit een AD opvragen hoort daar dus niet bij.

Om iedere machine te brute-forcen is een zeer tijdrovende klus, wat vaak de tijd die je hebt gekregen niet toe laat. Zeker als je bedenkt dat een auditor dit stuk dient op te pakken en jij als pentester veel meer kansen hebt op andere vlakken, spendeer je hier simpelweg, in vele gevallen, niet veel tijd aan.

[Reactie gewijzigd door Chrisz op 24 juli 2024 13:42]

[Zebby]

Je vergeet 1 heel groot en belangrijk ding - budget. Tuurlijk kan een pentester helemaal los gaan, maar security kost geld en levert niks op, dus dat moet meestal zo goedkoop mogelijk.

Onze klanten laten de systemen die wij voor ze hosten ook pentesten. Meestal kost zo'n test ~4-5k, echt de bodem van de markt, en veel meer dan een Nessus scan + ssllabs + headerscan doen die niet. Echt je usual suspects. Dat doen onze eigen vulnerability testen en scans ook wel, en ssllabs doen we zelf ook.
Ook test men normaliter volgens een normenkader, anders is scope zo lastig te bepalen.

We hebben maar 1 klant die een interne security organisatie heeft die 1 pentester 40u dedicated geeft om problemen te vinden, en dat is dan ook de enige die wat vindt. Die had n.a.v. een melding vorig jaar op een plek iets gevonden waar hij met 3-4 voorwaarden alsnog middels een cookie waarde aanpassen (hoera Burpsuite..) een bepaalde actie kon herhalen. Ik vind het knap.

[bazzi]

En aan zo'n penstest heb je wat. Welke partij was het die de pentest deed?

[asing]

Ik geef je even wat achtergrond informatie. Ik heb zowel cursus als examen Ethical Hacker gedaan. Dat wil zeggen : ik ben een soort witte hoed hacker.

In de opleiding leer je dat je je aan de opdracht van de klant dient te houden. Die zegt wat ze getest willen hebben en hoe ze dat gedaan willen hebben. Wat de klant niet vraagt of verbied moet je niet gaan testen. Zie het als dat je je auto naar de kwik fit brengt voor APK. Aan het einde van de dag haal je hem op en zit er ineens een nieuwe uitlaat, 4 nieuwe banden en rondom nieuwe remmen op. Dat was nog prima en de opdracht was "APK".

Dus als zwakke wachtwoorden of het beleid buiten scope van de opdracht liggen, dan is dat zo.

Je maakt overigens een fout door een auditor en een pentester door elkaar te halen. Het is de taak van de auditor om procedures en instellingen tegen het licht te houden op zoek naar slecht beleid of slechte procedures.

In dit geval had een audit misschien wel geholpen, de pentest helaas niet.

[blorf]

Naar mijn idee is een zwak wachtwoord pas een issue als de interface die om wachtwoorden vraagt niks doet bij brute-force en een groot aantal mislukte pogingen van dezelfde bron niet opmerkt.
Oftewel, bij een systeem dat 20 seconden wacht als er 3x een fout wachtwoord is ingevoerd is geautomatiseerd "raden" geen optie.

[Reactie gewijzigd door blorf op 24 juli 2024 13:42]

[Nystran]

Ja leuk, remote toegang die blokkeert bij teveel verkeerde inlogpogingen. Even een DOS aanval (hacker raadt 30x per minuut een verkeerd wachtwoord) en je komt zelf niet meer binnen. Succes!

Uiteraard is dit op te lossen met 2-factor authenticatie of fysiek reizen en lokaal benaderen, maar zonder meer roepen dat RDP in 5 minuten goed geconfigureerd had kunnen worden is soms wat kort door de bocht.

[blorf]

Een DOS-aanval op een niet-webserver valt als het goed is nogal op...

Geen idee wie dat van RDP zei, maar het klopt. RDP is gewoon goed te configureren. Alleen al als je aangeeft welke hosts met welke gebruikersaccounts er mee mogen doen ben je al een eind op weg. Daarnaast, alternatieve poorten, versleuteld signaal, block voor niet-lokale toegang. Is allemaal niet heel ingewikkeld.

[HahahaLoL]

Een monteur kan best aangeven dat je kapotte autoradio makkelijk te vervangen is als hij bezig is met de APK. Hij is dat niet verplicht, maar het is wel netjes om dat even te melden als hij het toch ziet. Een bedrijf dat onderzoek doet zal ook nooit zomaar wachtwoorden gaan veranderen zonder de systeembeheerder erbij te halen, dus je vergelijking is wat krom. Het is nu nog een beetje onduidelijk wat er tijdens de pentest gevraagd werd en of ze de wachtwoorden konden zien, maar als je simpele wachtwoorden ziet dan is het ook wel netjes om dat even te vermelden ook al was het niet de opdracht. Je kan dan alleen het bedrijf niks verwijten als het niet in de opdracht zat.

Het is sowieso verstandig om niet meer of minder te doen dan wat de opdrachtgever vraagt. Anders werk je jezelf uit de naad, terwijl je er geen extra beloning voor krijgt. Dat is onnodig de werkdruk verhogen, waar je zelf later ook weer last van gaat krijgen. Liever op voorhand de opdrachtgever proberen te overtuigen dat zwakke wachtwoorden ook binnen de scope moeten zitten.

[asing]

En daar ga je. Geen idee wat de rest was. Misschien iets heel anders, of negeer de brakke rdp oplossing. Kan ook.

Een simpel wachtwoord zie je niet, dat wordt versleuteld opgeslagen en de string is altijd even lang. Ook zijn ze nooit reverse decryptable dus je moet een rainbow table hack uitvoeren.

Maar al met al, de pentestester was nooit verantwoordelijk voor deze hack.

[henri8096]

In de opleiding leer je dat je je aan de opdracht van de klant dient te houden. Die zegt wat ze getest willen hebben en hoe ze dat gedaan willen hebben. Wat de klant niet vraagt of verbied moet je niet gaan testen.

Leer je dan ook in die opleiding dat de gemiddelde klant geen idee heeft waar die om vraagt, of eigenlijk waar die voor betaald.
Je kunt je makkelijk verschuilen achter de opdracht, echter is het daarbij wel je plicht om de opdrachtgever daarbij goed te informeren. (tegelijk ligt er bij de opdrachtgever ook de plicht zichzelf goed te laten informeren)
Dat is een wisselwerking, echter moet je je wel beseffen dat je opdrachtgever "niet weet wat hij niet weet".

[michielRB]

In de opleiding leer je dat je je aan de opdracht van de klant dient te houden. Die zegt wat ze getest willen hebben en hoe ze dat gedaan willen hebben. Wat de klant niet vraagt of verbied moet je niet gaan testen. Zie het als dat je je auto naar de kwik fit brengt voor APK. Aan het einde van de dag haal je hem op en zit er ineens een nieuwe uitlaat, 4 nieuwe banden en rondom nieuwe remmen op. Dat was nog prima en de opdracht was "APK".

(Zoals heel vaak) gaat ook hier de 'auto analogie' niet op. Een APK is niet een keuring die door de klant wordt gevraagd, maar een specifieke set van eisen die door de overheid is opgelegd. De klant en de garage hebben hier geen zeggenschap in. Verder is de APK een verplichting.
Als je je als een mak schaap door de opleiding doctrine van de grote detacheerders laat inpakken, dan geloof ik niet dat je het beste voor hebt met zowel de klant als met je eigen gevoel voor je vak.
IMO heb je als partij die een 'pentest' aanbiedt de verplichting om de klant uit te leggen wat een pentest is en wat wel en niet binnen het traject valt.

Verder snap ik werkelijk niet dat er dergelijke blunders qua accountbeheer gemaakt worden. En dat er niet voor iets anders gekozen is dan RDP direct van buiten open te gooien. Waarom niet bijvoorbeeld iets als Guacamole met RADIUS? Waarom niet een service als Fail2ban die na x fouten op zijn minst alarm slaat (maar bij voorkeur het account en/of IP tijdelijk blokkeert).

Ik ben dan al wel een tijdje uit het directe systeembeheer, maar je hoeft geen Einstein te zijn om dit soort elementaire dingen te bedenken. Het is al helemaal geen rocketscience om ze te implementeren.

[asing]

Je snapt het niet. De klant bepaalt wat getest wordt en hoe. Net als jij naar de garage gaat en zegt dat je alleen een keuring wil. Als er dan ineens van alles is gedaan wat je niet gevraagd hebt is er een probleem. Zelfde met pentesten. Dit is de opdracht, stick tot it.

Wat de klant verder fout doet is aan de klant

[Oyxl]

Dat is geen scope. Dat is een super vage beschrijving van elke pentest ever.

[Byron010]

Met vervolgens dit in het artikel
"Bij de pentest werd bijvoorbeeld niet gekeken naar de specifieke server die nu werd aangevallen."

[Christoxz]

Dus die server zat niet in de scope.

[xSNAKEX]

Volgens het artikel niet, maar het rapport De Winter dus wel. Staat 2 berichten hierboven...

[pietje63]

Of wel in de scope, maar er is desondanks niet naar gekeken

[kodak]

Het opvallende is dus dat de relevante conclusie of het wel of niet binnen scope was niet is gegeven maar er wel kritiek lijkt te zijn over de scope. Kritiek zonder duidelijkheid hoe terecht die is klinkt mij te vaag. Zo leren de opdrachtgevers en pentesters niet dat ze beiden verantwoordelijkheid hebben voor goede scoping en uitleg als het mis gaat.

[JaymzHetfield]

Het lijkt mij dat de onderliggende onderzoeksrapporten eerder kloppen dan dit nieuwsartikel.

[JaymzHetfield]

Misschien kan de auteur van dit artikel (op Tweakers) het door jou geciteerde dan even aanpassen o.b.v. de onderzoeksrapporten

[Reactie gewijzigd door JaymzHetfield op 24 juli 2024 13:42]

[Fordox]

Als je mij vraagt, als iemand die basiskennis heeft van netwerken, neem ik aan dat een bedrijf die een pentest aanbied ook daadwerkelijk een goeie pentest uitvoert.

Je koopt een pentest met de aanname dat dat bedrijf een rapport gaat opstellen aan verbeteringen die je moet doen aan je beveiliging. Als het rapport zegt 'alles is OK', ga ik er als leek vanuit dat mijn systeem redelijk veilig is.

Als je achteraf te horen krijgt dat je systeem ruk is en het is zo lek als een mandje, waarvoor heb je dan in godsnaam die pentest gekocht? En hoe weet iemand die niet heel kundig is in beveiliging wat mist in de scope? Daarbij hoort het bedrijf toch te helpen die de pentest uitvoert? Zij zijn toch de experts, als voor hun de scope onduidelijk is dan stellen zij die toch beter op?

[JouwertMJW]

Bij een pentest spreek je een scope af, dit ligt dus aan het bedrijf. Een pentester kan en mag niet meer testen dan binnen de scope is. Ze zullen ook niet zeggen dat alles OK is, ze zeggen wij hebben geen kwetsbaarheden gevonden binnen deze scope met deze afspraken. Dit ligt dus niet aan het bedrijf maar aan de opdrachtgever. De server in dit artikel viel buiten scope en is dus niet getest wat ook zo hoort als je dit afspreekt.

[Fordox]

Ja ik begrijp dat de scope wordt bepaald door beide partijen. Maar 1 partij is een expert en de ander heeft als doel een veilig systeem in handen te hebben.

De expert zou van een 'vage scope' als "zwakheden in het systeem moeten worden gevonden", zouden zij adviezen horen te geven over wat er allemaal getest kan worden en dat de scope mogelijk te klein is om een goeie pentest uit te voeren.
De expert zou hun netwerk kunnen bekijken en als advies kunnen geven om die server ook maar te laten testen.

Of denk ik te simpel en moet ik er vanuit gaan dat een gemeente prima zelf 50% van de scope kan bepalen?

[Reactie gewijzigd door Fordox op 24 juli 2024 13:42]

[JouwertMJW]

De expert zou wel advies kunnen geven, ja absoluut en dit gebeurt vaak ook. Maar even iemands netwerk doorzoeken kan heel tijdrovend zijn en vooral heel lastig. Vaak is er geen of gebrekkige documentatie aanwezig.

Daarom leg je de scope vaak neer bij de IT van de opdrachtgever want deze mensen hebben de meeste kennis van het landschap. Zij vragen ook een test aan en geven dit door aan directie. Een legacy systeem kan bijvoorbeeld heel gevoelig zijn en wordt daarom buiten scope gesteld door IT, niet omdat het veilig is maar omdat de test methodes een grote kans hebben tot het neerhalen van het systeem. Hiervoor worden andere oplossingen bedacht of aparte testen voor aangevraagd die rekening houden hiermee.

[kodak]

Ik zou van een opdrachtnemer verwachten dat die mee denkt over de scope en formulering, maar als dat geen aparte opdracht is mag ook verwacht worden dat de opdrachtgever daar professionals voor in dienst heeft om zichzelf te beschermen. Want een ander inhuren wil niet zeggen dat die vooral rekening met de opdrachtgever zal houden of die voldoende kent om tot een acceptabele prijs/kwaliteit te komen. Ik verbaas me er wel over hoe weinig aandacht er lijkt voor de eigen verantwoordelijkheid.

[PageFault]

Als je de scope dermate uitkleed of voor ons triviale, belangrijke zaken achterwege laat, dan is de derde partij niks te verwijten. Zo'n pentest stelt meestal niet extreem veel voor in acties die worden uitgevraagd en dus worden uitgevoerd. Je krijgt ook wat je betaalt in zo'n geval. Vaak testen ze maar 4 of 8 uurtjes, meer wil men er niet aan uitgeven.

[ArchNemeziz]

Inderdaad, het is vaak een dag werk met een rapport wat er gevonden is. Binnen een dag kan je niet alles testen, mogelijk heb je maar een klein deel getest van de omgeving en is dat ook de opdracht geweest. Verder weet je natuurlijk ook niet wat er allemaal in de tussentijd is gewijzigd, in het artikel staat dat een rdp-poort is opengezet, maar niet of deze al die tijd open stond van buitenaf of dat deze later pas is opengezet (op de firewall). Verder kunnen er natuurlijk al diverse zaken zijn doorgenomen, maar niet in het rapport opgenomen die ze wel zijn tegengekomen. Denk tevens dat het voor veel gemeentes erg lastig is om aan security monitoring te doen en met externen moeten ze mogelijk weer cloud-oplossingen afnemen wat ook niet wenselijk is.

[JaymzHetfield]

In het NFIR rapport staat eveneens: "Door een extern bedrijf is in de periode van juni 2020 een penetratietest uitgevoerd, deze penetratietest vond plaats in de periode dat de FTP-server bereikbaar was vanaf het internet. In de scope is ook het IP-adres opgenomen vanaf waar de FTP-server bereikbaar was via het internet. De bovengenoemde problemen (namelijk een server bereikbaar via RDP vanaf internet) zijn echter niet aan het licht gebracht. Deze informatie is mogelijk niet gezien of niet goed gerapporteerd. "

[Oyxl]

Top, ik reageer puur op het feit dat jij reageert op een verzoek om een scope, zonder een scope. Wat je nu post is al iets meer van een scope, maar dekt nog steeds niet de lading. Misschien hebben de opgelegde beperkingen er toe geleid dat wachtwoorden überhaupt niet getoetst zijn. Het feit dat men een lijst had met de server daarop, zegt nog altijd niets over de scope van de test.

[mening]Daarbij huren veel organisaties pentesters zodat ze een vinkje krijgen en zal het ze verder niet veel interesseren of er daadwerkelijk iets uit komt.

[kodak]

Dat een IP-adres is opgenomen wil niet zeggen dat de ftp service in scope was en ook niet dat het bij het onderzoek onderzocht kon worden. Er zijn dus meer mogelijkheden dan de informatie is niet gezien of niet goed gerapporteerd.

De verwoordingen in beide conclusies komen op mij over alsof de schrijvers een voorkeur hebben om de schuld te leggen in plaats van de mogelijkheden echt open te houden dat een opdracht iets tussen meerdere partijen is en niet zomaar resultaat aan een partij zou liggen.

[ArchNemeziz]

En al zou de ftp service in scope zijn, mogelijk is dan niet aangegeven om op de rdp-protocol te testen (als ze bijvoorbeeld zelf al aangeven dat het dicht staat, bijv. via GPO al uitgezet, terwijl de GPO niet goed doorkomt of override wordt).

[mjtdevries]

Er lijken knap wat tegenstrijdigheden te zijn in de informatie die naar buiten word gebracht:
Jij geeft aan dat het volgende in het NFIR rapport staat:

In de scope is ook het IP-adres opgenomen vanaf waar de FTP-server bereikbaar was via het internet. De bovengenoemde problemen (namelijk een server bereikbaar via RDP vanaf internet) zijn echter niet aan het licht gebracht. Deze informatie is mogelijk niet gezien of niet goed gerapporteerd. "

Op security.nl staat echter:

Sinds 29 oktober 2019 was een FTP-server van de gemeente voor iedereen op het internet via RDP (remote desktop protocol) benaderbaar.

Door middel van een bruteforce-aanval wisten de aanvallers het wachtwoord van een "testadmin"-account te raden, namelijk "Welkom2020". Dit wachtwoord was op 15 oktober voor het account ingesteld.

Dat is dus allebei gedaan nadat de pentest is gedaan. Uiteraard komt het dan niet naar boven in een pentest.

[Oon]

Het zou toch eigenlijk wel super zijn als iedere organisatie een infrastructuur had die makkelijk te dupliceren was, bijvoorbeeld een k8s of docker omgeving waar je dan tijdelijk één of meerdere nodes aan toevoegt, de data synct, en ze dan loskoppelt van de rest.

Je zou dan een pentester de volledige vrijheid kunnen geven om z'n werk te doen, zelfs als dit destructief is. Veel pentests gebeuren nu redelijk oppervlakkig omdat ze dat proberen te vermijden, maar dat zou dan niet nodig zijn.

Maar goed, dat is natuurlijk lastig als je met persoonsgegevens werkt die niet zomaar even naar een andere (externe) server gekopiëerd mogen worden en je infrastructuur inmiddels 10-20 jaar oud is zoals bij veel gemeenten het geval is.

[Aikon]

Zou inderdaad wel strak zijn, zo een testomgeving.

Maar als je een omgeving dupliceert, hoef je niet perse de daadwerkelijke inhoud van bijv. een database te kopiëren. Dat heeft geen invloed op het resultaat. Althans, dat kan ik me niet voorstellen

En van een omgeving van 20 jaar kan ik je zo al vertellen dat deze onveilig is

[Oon]

Dat is inderdaad ook waar, je hebt niet alle productiegegevens nodig om een pentest uit te voeren. Wel heb je (zoals nu blijkt) alle gebruikersaccounts met rechten voor niet-publieke opties nodig, maar daar hoeven dan weer geen (echte) persoonsgegevens aan te hangen.
Ik denk alleen dat er altijd wel edge cases zijn waar je dan weer gegevens voor blijkt te missen tenzij je gewoon alles kopiëert. Dan lijkt (achteraf) anonimiseren mij een beter idee om het volledige plaatje te hebben.

Er zijn genoeg systemen van 20 jaar oud die heel veilig zijn, maar die zijn wel offline of rusten op andere infrastructuur voor het delen van informatie (als heel plat voorbeeld; Kladblok kan heel veilig .txt bestanden verwerken die in een goedbeveiligde Sharepoint-omgeving staan). Ik kan me inderdaad niet voorstellen dat er veel tools met directe online communicatie zijn van 5-10 jaar oud of ouder die door een moderne pentest komen

[Aikon]

Maar kladblok is geen systeem.

Tuurlijk ga je dingen missen, maar dat weet je vantevoren. Want ga je bijv. je vmware omgeving virtueel dupliceren of op identieke hardware? Met dezelfde biosversie? Op dezelfde switch? Met dezelfde vlans en firewall daar weer voor?

Overigens kan je normaliter gewoon je data, ook persoonlijke, kopiëren binnen je netwerk wat je wilt. Daar zijn niet echt strakke regels voor, behalve dat je ze goed moet beveiligen etc.

[TheVivaldi]

De vraag is natuurlijk wat voor soort test er moet plaatsvinden. Als het alleen een controle is of de software an sich waterdicht is, dan heb je geen identieke hardware nodig.

[Oon]

Tja, het ligt er natuurlijk heel erg aan wat voor omgeving je hebt. Als je een eigen serverruimte hebt met genoeg budget voor hotswap hardware dan kun je bij wijze van spreken een extra server in het rack duwen en die 1:1 synchroniseren, maar dan ga je er dus ook vanuit dat je hele infrastructuur op één server draait/past. Ik kan me voorstellen dat bij grotere gemeenten er netjes losse servers zijn met eigen doeleinden/services en failover, zodat (zo goed als) nooit het hele netwerk in één keer plat ligt, maar dat maakt het idee van een tijdelijke afgesloten omgeving dan ook weer wat ingewikkelder.

Maar ik weet dat er veel organisaties zijn waar dat niet het geval is, zo weet ik van een aantal hele grote organisaties dat hun kernsysteem gewoon op een oude PC ergens op kantoor draait. Het ligt er maar net aan wie de systeembeheerder is en wanneer die voor het laatst een opfriscursus heeft gedaan.

Wat dat betreft zou het overigens wel mooi zijn als er vanuit de overheid iets meer controle en verplichting zou komen voor gemeenten en andere belangrijke organisaties (zoals bijv. de GGD) om zo nu en dan ook daadwerkelijk een volledige audit en pentest te laten doen van zowel de systemen als de organisatie in z'n geheel. Dan zou een hele ingewikkelde oplossing om een destructieve pentest te doen op de systemen al bijna niet meer nodig zijn, want als iedereen netjes de processen volgt en veilige wachtwoorden gebruikt gaat er al een hele hoop minder fout.

[coolkil]

Meeste organisaties zoals dit heb je het als snel over enkele honderden virtuele/fysieke machines. Waaronder databases die verbonden zijn aan elkaar daarboven op komen dan nog applicatie servers welke ook nog onderling communiceren. Daarnaast nog een twin datacenter concept waarbij op verschillende locaties data staat. er daartussen verschillende data lijnen zijn. In sommige gevallen komt er dan ook nog eens een public cloud connectie bij kijken.

Dat wordt te groot om in een 1 op 1 kopie over te nemen om te pentesten. Wat je wel vaak ziet, helemaal bij grote Enterprise is dat als onderdeel van de acceptatie criteria een pentest voor bepaalde projecten gedaan moet zijn. Maar die zijn dan wel gescoped op dat project.

Het de schuld geven van je pentesters is simpelweg afwimpelen van verantwoordelijkheid. Iedere it'er met een klein beetje verstand kan bedenken dat het onverstandig is om een simpel wachtwoord op een FTP server te plaatsen. Helemaal als deze naar buiten open staat

[Reactie gewijzigd door coolkil op 24 juli 2024 13:42]

[bazzi]

En de vraag moet misschien ook zijn, had die naar buiten moeten open staan... Dat had bij een beetje pen test wel naar boven moeten komen en de standaard vraag die wij dan krijgen, is het nodig en wel veilig genoeg... Maarja als je dat dan mitigeert met een antwoord en er geen brute force is gedaan door de pentesten, mogelijk out of scope, tja....

[NBK]

Op zich zou je tijdens het kopieren van de omgeving ook meteen al kunnen checken of er dingen opvallen mbt de veiligheid. Het ontbreken van VLAN's of gescheiden netwerken zou op dat moment al heel goed zichtbaar moeten zijn.

Soms is het ook wel gewoon vervelend voor de admin.. Ik heb thuis het nodige gescheiden in mijn netwerk om te testen wat mogelijk is maar soms zit je echt tijden te kloten om te achterhalen waarom iets $@&%^# niet werkt. Blijkt een apparaat per ongeluk in een verkeerd VLAN te hangen of er komt iets niet door de firewall. Binnenkomende VPN verbinding waardoor je IP in een ander subnet zit dan de PC waar je gebruikelijk op zit.

[Reactie gewijzigd door NBK op 24 juli 2024 13:42]

[Blackbird-ce]

Zelfs dan hou je altijd de vraag wat de scope is van de testen. Een gemiddeld applicatielandschap is dermate groot dat niet alles getest wordt (te duur, te langdurig, etc).

[jpsch]

Je kunt toch nooit alles dupliceren?

[RoL0]

Zo gaf de NOS aan (https://nos.nl/artikel/23...te-simpel-wachtwoord.html) dat bij deze pentest één IP-adres niet meegenomen werd, en precies deze machine nu 'gehackt' werd. Je hoeft natuurlijk ook maar één deur open te laten staan (en je 'binnendeuren' niet op slot te doen) om flink beroofd te kunnen worden.

EDIT: @TheVivaldi, ik probeer hier ook zeker niets goed te praten, het ging op meerdere punten compleet mis (veel te simpel wachtwoord, één adminaccount dat overal bij kon, inclusief backups, uitschakelen van firewallregels zodat servers 'lekker makkelijk benaderbaar' werden etc.), maar ik doelde vooral op de 'scope' van pentesten die winux aanhaalde. De pentest zelf was misschien dan wel ok, al kun je betwijfelen of een test goed is als je scope al niet klopt..

[Reactie gewijzigd door RoL0 op 24 juli 2024 13:42]

[TheVivaldi]

Dat is waar, maar we hebben het hier wel over mogelijke toegang tot persoonsgegevens en alles - dan zou ik toch zeker wel alles meenemen in tests. Een museum is ook beter beveiligd dan een woonhuis, en feitelijk is een gemeente net als een museum, in de zin van dat ze beide hele waardevolle dingen opslaan.

[SillieWous]

Dat is dan een verwijt aan de gemeente, niet aan de pentester. De pentester heeft zich lijkt het aan de scope gehouden. Je lijkt te insinueren dat de pentester buiten zijn opdracht moet treden omdat het om persoonsgegevens zou kunnen gaan. Dat is op dat moment simpelweg computervredebreuk, en daarmee absoluut verboden.

[TheVivaldi]

Nee, ik bedoelde juist dat de gemeente álles had moeten laten testen.

[SED]

Maar een controle van actieve accounts is onvermijdelijk onderdeel van een pentest!
Een account als "testadmin", valt dan gegarandeerd door de mand.

[mjtdevries]

Bij een pentest van een extern systeem ga je niet het zwakke wachtwoord van het testadmin account vinden dat alleen intern actief was.

De server met RDP open en welkom2020 was nog niet actief toen de pentest uitgevoerd was. Dus uiteraard kon dat niet gevonden worden.

[SED]

Als je een pentest doet en je komt een testadmin tegen die actief is dan horen alle alarmbellen af te gaan. Ongeacht het ww.
Dat is zon beetje het begin van een audit van een systeem en een pentest zoekt juist naar dat soort zwakheden. Als die niet op de takenlijst staan is het een extreem slordig gebeuren!

[mjtdevries]

Dus als jij een pentest doet op een extern systeem, dan ga je alle interne wachtwoorden testen?
Dat valt buiten de scope van een pentest op een extern systeem.

Een account waarmee je van buitenaf op dat systeem kan inloggen moet je natuurlijk wel checken, maar daar was geen sprake van bij dat testadmin account. Dus volstrekt logisch dat dat niet gevonden was.

En een pentest is geen audit.

[SED]

Om te zien welke accounts toegang hebben van buiten doorloop je eerst de user directory.
Een account met volledige admin toegang kan in principe zowel intern als extern gebruikt worden. daarnaast is een RDP account wat dat betreft nog kwetsbaarder.
Alleen al de accountnaam.. tjonge... als je dat mist!
Blijft dus extreem slordig om daar niet naar te kijken.
Ik zeg nergens dat een pentest een audit is.. ik haal beiden aan.

[mjtdevries]

LOL, nog nooit een pentest meegemaakt waarbij voor de test van een extern systeem, de hele interne user directory word nagelopen.

Jij hebt een geidealiseerd beeld van pentests dat niet overeen komt met de werkelijkheid.

Een account met volledige admin toegang kan in principe zowel intern als extern gebruikt worden

Nee. Dat is een aanname die nergens op gebaseerd is.

[SED]

Je zult een volledige admin bewust moeten uitsluiten, afhankelijk van onderliggende os.

[Fiander]

mits dat een AD account is, en geen alleen op deze server aanwezig lokaal account.
Deze server viel blijkbaar om een of andere reden buiten scope.

tja, eenmaal binnen in een netwerk, is binnen.

[Vedette.]

De titel is wel vrij kort door de bocht. Uit het rapport van NFIR:

Het “testadmin” account had een dermate verhoogd rechtenprofiel (Domain Administrator-rechten)

Hieruit kunnen we opmaken dat het om een domein account gaat, en niet een lokaal account op een server. Indien een pentest is uitgevoerd op specifieke servers is het niet verwonderlijk dat dit zwakke wachtwoord niet is gevonden. Als het gaat om een "algemene" pentest van het interne netwerk met het Active Directory in scope is het uiteraard een ander verhaal.

Daarnaast staat in het rapport van NFIR het volgende:

Deze informatie is mogelijk niet gezien of niet goed gerapporteerd. Er is geen informatie verstrekt aan NFIR over wat er met de resultaten van de penetratietesten is gedaan.

Uit de eerste zin maak ik op dat Gemeente Hof van Twente niet in staat is geweest om de resultaten van de penetratietest over te dragen aan NFIR. Je zou verwachten dat, mits Sogeti ook maar enige vorm van verslaglegging heeft opgeleverd, de gemeente in staat zou moeten zijn deze verslaglegging met NFIR te delen. Niet alleen dat bleek onmogelijk, ook kan de gemeente niet vertellen wat er met de uitkomsten van de test is gedaan.

Het lijkt me met de huidige informatie vrij vroeg om kritiek te uiten op Sogeti. Was getekend, een concullega.

[aikebah]

[...]

Uit de eerste zin maak ik op dat Gemeente Hof van Twente niet in staat is geweest om de resultaten van de penetratietest over te dragen aan NFIR.

Dan lees je wel meer in die zin dan ik. Wat ik er in lees:
1) "er stond niets over in het rapport, dus het is niet opgemerkt danwel niet correct gerapporteerd"
2) "wat Hof van Twente met de bevindingen uit het rapport heeft gedaan is niet vastgelegd"

[paulhekje]

Ik kan me niet voorstellen dat een algemene pentest niet begint met een simpele port scan van de internet IP-adressen. En daarbij had rdp 3389 direct gevonden moeten worden.

[prutser001]

Snap er geen bal van, standaard test die ik doe heeft dit gewoon standaard en voert standaard op de gevonden poorten die open staan de tests uit. Pak een standaard kali installatie met de tests en je bent er al.

[CyBeRSPiN]

Kan Sogeti nog aansprakelijk worden gesteld? Zal vast niet goedkoop geweest zijn zo'n pentest maar klinkt alsof er enkel gebakken lucht is verkocht. Een paar securitytooltjes draaien en een mooi rapportje opstellen kan iedereen.

[Aikon]

De test was uit mei, en het wachtwoord uit oktober. Als het ww daarvoor wel complex was en de server blijkbaar niet in de scope zat,wat valt de pentester dan te verwijten? Als die server wel in de scope zat, dan heeft de systeembeheerder op zijn beurt blijkbaar gemist dat deze overgeslagen is.

Waarschijnlijk gefaal rondom en te weinig systeembeheerders

[TheVivaldi]

Een testaccount met volledige adminrechten, zwak wachtwoord én aan het internet hangen is sowieso niet slim, of dat nou tijdens de scope bekend was of niet. Een góed systeembeheerder had dat nooit gedaan.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 13:42]

[Aikon]

De vraag is dus of het ww ten tijde vd pentest zwak was. Een testaccount kan adminrechten nodig hebben, niks geks aan. En een account 'hang' je niet aan het internet. Dat was het probleem ook helemaal niet tijdens de hack, dat was (o.a.) dat de firewall ook een zwak wachtwoord had.

[TheVivaldi]

Hoe dan ook had de systeembeheerder dat allemaal beter kunnen instellen.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 13:42]

[Metalfreak]

En er is waarschijnlijk ook geen DE systeembeheerder. Het is natuurlijk lekker makkelijk oordelen vanaf de zijlijn. Het kan zomaar voorkomen dat systeembeheerder A de server aan het internet heeft gehangen, systeembeheerder B daarvan niet op de hoogte was en zich niet bewust was dat het testaccount ook daar rechten op had, maar dat systeembeheerder A ook niet op de hoogte was van het bestaan van dat account. Je kunt nu eenmaal niet alles de hele tijd continu in de gaten houden. Of wellicht heeft iemand gewoon een vinkje over het hoofd gezien omdat alles "even snel" tussendoor moet. Je probeert processen zo in te richten dat je dergelijke situaties kunt voorkomen, maar door drukte, onderbezetting, ziekte of whatever, kan het zomaar gebeuren dat je niet altijd overal volledig zicht op hebt.

Het is natuurlijk makkelijk (ver)oordelen vanaf de zijlijn en natuurlijk heeft iedereen met commentaar zijn eigen straatje volledig en 100% schoongeveegd, nooit te maken met onderbezetting, nooit ergens een securityrisico en alleen maar perfect voltooide projecten zonder open eindjes... En vervolgens stappen ze op hun eenhoorn en rijden ze richting de regenboog.

[darthdrinker]

Heel pijnlijk en als oud Sogeti werknemer kan ik alleen zeggen dat ik het bedrijf zo niet ken of herken. Uiteraard moet er goed worden gekeken wat er is gebeurd en hoe dit beter kan worden uitgevoerd.

Maar laten we ook niet lastiger maken dn het is. Als jij als admin tegenwoordig dat soort wachtwoorden gebruikt ben je geen knip voor de neus waard. Dit had al je eer te na moeten zijn om dat toe te laten, of het gecontroleerd wordt of niet.

[Batiatus]

Als iemand die Sogeti als security test parner had, kan ik me wel redelijk vinden in het verhaal. Helaas kan Sogeti / de pentester hier vaak niet veel aan doen. Zeker binnen de overheid zijn kavels over wat ze mogen testen behoorlijk beperkt in hun scope. Dat kan komen doordat partij X de Infra doet, partij Y het platform (OS) doet en partij Z de applicaties. Vervolgens nog een aparte testpartij (Sogeti) die weinig kennis van de omgeving heeft omdat ze 1x in het jaar langskomen en dan een paar dagen testen om vervolgens een rapport op te leveren.
Een ander nadeel kan zijn dat andere partijen / diensten afhankelijk zijn van de applicatie die zij gaan pentesten waardoor er maar beperkte tijd is om de pentest uit te voeren.
Heb met verschillende pentesters van Sogeti van doen gehad, sommige erg kundig en anderen duidelijk nog te junior zonder begeleiding. Volgens mij is er ook veel verloop in mensen en expertise, maar dat terzijde.
TLDR: wat mij betreft kan er niet een schuldige aangewezen worden, daarvoor zijn teveel zaken onbekend hier. Lijkt me ook niet het doel, maar wel hoe dit de volgende keer wel gedetecteerd kan worden zodat het niet gebeurd.
Een testaccount met full-admin rechten is overigens wel schandalig (van de beheerders).

[darthdrinker]

Dat is een beetje het punt van mij in de zin dat er dingen zijn gevonden die gewoon echt niet kunnen. Als er een hele obscure software bug was gebruikt die alleen werkt met patch x van OS y enz. tja dan kan je nog zeggen dit is ons ontgaan. In dat geval is het ook logisch dat je een audit aanwijst, die hadden dit voor jou moeten controleren. Maar het zijn echt de absolute basis zaken die hier zijn fout gegaan. Een beetje mijn huis is leeg gehaald omdat ik gewoon de deuren niet op slot doe. Een rechter zal dit ook erkennen en aangeven dat je hier toch echt zelf schuld hebt, dit had je kunnen weten daar is geen audit voor nodig. Ik kan me voorstellen dat er door andere ervaringen wat frustraties zijn met het bedrijf Sogeti en dat kan terecht zijn, maar daar staat de kern van dit verhaal volgens mij echt los van.

[aikebah]

Een beetje mijn huis is leeg gehaald omdat ik gewoon de deuren niet op slot doe.

Tsja, om dan even in die vergelijking te blijven: En dat is niet eens opgemerkt door die veiligheidscontrole die ik had aangevraagd om te kijken of mijn raamkozijnen goed inbraakwerend waren.

[init6]

Als oud klant herken ik Sogeti wel hierin, een hoop gebakken lucht verkopen. Destijds moest en zou via Sogeti een Cloud Service Provider contract aangegaan worden, via hun contract met de cloud provider werden cloud resources ingekocht waardoor er een 5% besparing gerealiseerd werd. Hiervoor moesten wel alle resources naar hun account over gezet worden. Toen het eenmaal over was werkte de billing dashboard niet en kon er geen inzage gegeven worden in waar kosten naartoe gingen. Exit Sogeti.

Je kan dit soort praktijken ook vinden op geenstijl.nl waar er artikelen zijn over hoe er geprutst is bij UWV door Sogeti / Capgemini:
https://www.geenstijl.nl/...-connection-en-de-haagse/

Dit is wel iets wat redelijk basis is, en een wachtwoord manager kan je hier al bij helpen. Maar ik verwacht wel dat als je Sogeti inhuurt dat het ook naar dit soort dingen kijkt. Het zijn juist de domste dingen waardoor je gepakt kan worden. Een telefoontje naar een onoplettende medewerker, een post it op je beeldscherm plakken... etc.

[Reactie gewijzigd door init6 op 24 juli 2024 13:42]

[kodak]

Wat heeft je voorbeeld met beveiliging te maken? Dat je problemen hebt met een bedrijf op een bepaalde gebieden wil niet zeggen dat ander werk op andere gebieden ook zo is. En als je dan bedenkt dat dit soort bedrijven veel meer diensten leveren dan die voorbeelden zou ik eerder van je verwachten dat je de relevantie aantoont in plaats van alles kennelijk maar over een kam te scheren.

[Anoniem: 435630]

Precies dat inderdaad.

[japzr]

Dat lijkt me niet. Succesvol een pentest doorlopen is nooit een garantie dat een omgeving ook daadwerkelijk veilig is, maar alleen dat er binnen de scope en de afgesproken tijdsduur niets is aangetroffen.

Ik denk dat het moeilijk is om een oordeel te vellen over de pentest die is uitgevoerd zonder te weten wat precies de opdracht was.

[batjes]

Welke scope? Volgens mij was er geen scope als zulke basis zaken niet eens uitgevoerd zijn.

De onderzoekers zeggen niet te kunnen achterhalen hoe de pentest destijds is uitgevoerd, omdat het daarbij om een zelfontworpen methode ging. Daardoor is de test moeilijk te controleren.

Je logt toch gewoon welke handelingen je uitvoert? Krijg zo sterk de indruk dat er totaal geen pentest is uitgevoerd, dan is het controleren begrijpelijk moeilijk.

[Anoniem: 316512]

Je kan toch prima in een scope bepaalde servers of ip adressen weg laten? Dan is er nog steeds een afgesproken scope. Er wordt ook in het artikel al over een pentest gesproken. Dat is toch een wat minder uitgebreide opdracht dan een red teamer die aan de slag gaat.

[FreshMaker]

Inderdaad, die kwam ik een tijdje geleden tegen bij een kennis.
Die had voor zijn bedrijf informatie opgevraagd.

Met een standaardinvul lijstje wat je wilt laten testen, hoe en in welke tijd
Éen van de vragen was welk extern IP-adres moet er getest worden.
Er wordt dan alleen op dát adres gefocust, terwijl je makkelijk meerdere IPadressen kan hebben ( of de pech dat je nét een gewijzigde heb gekregen van je ISP

[japzr]

Zeker. Het is hoe dan ook een rare gang van zaken, ik mag hopen dat de opdracht specifieker was dan “pentest doen plx” en dat het rapport meer omvat dan “niks gevonden”.

Ik ben dan ook benieuwd naar de opdracht en offerte...

[SED]

De pen waarmee het contract werd getekend schreef. Pentest geslaagd.

[Anoniem: 435630]

Lijkt me wel, dat je de meest obscure zaken niet ziet, oké. Maar zwak wachtwoordbeleid en een topologie die om te janken is had gewoon bovenaan de lijst met aanbevelingen moeten staan. Ook dat er blijkbaar geen rapportage meer is blijkt niet in het voordeel van Sogeti. Er had op z'n minst nog een berg aanbevelingen en verbeterpunten moeten zijn, maar Sogeti had geen bijzonderheden gevonden. Er komen altijd punten uit een goede pentest..Lijkt meer op een gevalletje niets doen en cashen.

[Anoniem: 316512]

Ik mis even de zin waarin staat dat er geen bijzonderheden zijn gevonden. Wel lees ik dat er geen grote kwetsbaarheden zijn gevonden. Dat is een wezelijk verschil.

Sogeti lijkt wel de schijn tegen te hebben, maar vergeet niet dat pentests altijd volgens een scope gaan en het gewoon een financiele overweging geweest kan zijn om bepaalde systemen niet mee te nemen.

[TheVivaldi]

Maar wel een domme financiële overweging dan. Een museum gaat toch ook niet maar een deel van de beveiliging testen? Die testen ook alles, juist om te voorkomen dat er iets gejat wordt.

Neemt niet weg dat ook de admin in kwestie hier niet slim heeft gehandeld door een testaccount met volledige adminrechten aan te maken en te behouden…

[Tadango]

Dat is net als een APK test. Die geeft geen garantie dat je auto volgende week niet uit elkaar valt.....

[MPeek]

Dat klopt, maar je weet wel wat er bij een APK precies gecontroleerd wordt (of zou moeten worden) en aan de hand daarvan kun je dus concluderen of het de garage aan te rekenen valt.

[Anoniem: 435630]

Maar een goede garage geeft wel aanbevelingen, ook al komt de auto nog net door de apk. En de auto waar het hier om gaat is helemaal niet door de apk gekomen. Zwak wachtwoordbeleid en een zwakke topologie kunnen gewoon niet meer.

[peewee.]

Ook een slechte garage moet aanbevelingen geven, bijvoorbeeld als je bandenprofiel tegen de ondergrens aan zit, daar is ook plaats voor vrijgemaakt op het apk-formulier.

[TheVivaldi]

Maar een APK-test is geen scopetest - er wordt veel uitgebreider gecontroleerd dan slechts kijken of de wielen en deuren er niet afvallen…

Bovendien: áls je garage zou vaststellen dat je auto volgende week mogelijk uit elkaar zou vallen, dan zouden ze wel ziet dat er e.e.a. mis is en je aanbevelingen geven om die zaken z.s.m. te laten repareren.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 13:42]

[ultimasnake]

Als mijn auto door de APK komt en twee dagen later ik een gat in de bodem van m'n wagen trap tijdens het remmen kunnen ze inderdaad niet verantwoordelijk gesteld worden voor de schade die reeds aan mijn auto was. Echter was dit wel onderdeel van de keuring en hadden ze dit moeten zien, zij hebben dan dus een controle achterwege gelaten en mij met een onveilige auto de weg op gestuurd waar ze wel degelijk een 'zorgplicht' voor hadden.

Zo zie ik dat ook hier want een open poort scan en/of het inzien van interne documenten over Password policy zou zeker een bare-minimum moeten zijn.

Wij zijn door vele multi-nationals door de mangel gehaald en eigenlijk ongeacht wie hun pentest uitvoerde en/of welke software/routines ze gebruikte: Er zijn altijd basis zaken die terugkomen: server locatie, wachtwoord beleid, personeelsbeleid bij voornamelijk bij uit dienst gaan, lokale machine beleid, port scans op servers, backup, avg-beleid en van al die zaken moesten we of fysiek aantonen dat het goed was (denk aan iemand die een half dagje langs kwam om enkele zaken te confirmeren zoals het wachtwoord beleid)

Als je een Pen-test doet en dat soort zaken achterwege laat ben je echt heel slecht bezig als je het mij vraagt

[aikebah]

Dat is geen pentest, dat is een security-audit

[ultimasnake]

Een aantal zaken hiervan zijn ook zeker onderdeel van een security-audit maar was toch echt onderdeel van onze pen-test (gek genoeg?) want net als bij de gemeente kan de penetratie komen door slecht wachtwoord beleid, lekken vanuit medewerkers en kan een penetratie/datalek ook uitgevoerd worden op een slechte wijze van backup beheer ;-)

[arie.v]

Is het een rare gedachte dat de hackers na binnenkomst de server wél goed beveiligd hebben, maar dan nog wel zo dat ze zelf toegang hadden? Dat zou de ultieme dekmantel zijn - want er worden geen slapende honden wakker gemaakt.

[FreshMaker]

Dat is geen verkeerde aanname

Juist als een een waardevol doelwit hebt gevonden, wil je dat jij de enige bent met toegang.
Dan zorg je inderdaad dat alle kwetsbaarheden gesloten zijn, zonder dat je jouw toegang verwijderd

[themadone]

Het eerste tooltje zou dan toch de ad scanner moeten zijn die dit meteen meldt?

[Halfscherp]

Ik neem aan dat die contracten zo in elkaar zitten dat er nauwelijks tot geen rechten aan ontleend kunnen worden.

Desalniettemin is dit een behoorlijke knauw voor de reputatie van Sogeti die ze indirect behoorlijk wat geld gaat kosten.

[kodak]

Waarop wil je ze aansprakelijk stellen? De conclusie dat het logisch zou zijn dat ze het hadden moeten vinden of melden lijken niet gebaseerd op aannames en niet door duidelijk te zijn of de gemeente werkelijk duidelijknis geweest wat er wel of niet getest moest worden. Dan kan je wel van alles gaan vinden over een bedrijf maar voor aansprakelijkheid is er wel wat meer nodig dan speculeren en een mening hebben over een van de minimaal twee betrokkenen.

Het vreemde is dat er nauwelijks aandacht is voor de verantwoordelijkheid van de gemeente als het om een opdracht geven en controleren gaat. Je kan wel opdracht geven maar dat ontslaat je nog niet van de verantwoordelijkheid om te controleren of die juist geformuleerd is, juiste uitvoering krijgt en het maar aan een partij te laten. Uitbesteden is niet hetzelfde als geen verantwoordelijkheid hebben of hoeven nemen. Maar daar hebben ze het kennelijk liever niet over bij het schrijven van de conclusies.

[KRG]

ik akn uit dit artikel niet echt opmaken of ook het systeem en netwerkbeheer door een externe partij werd gedaan. Of had de gemeente zelf een afdeling die verantwoordelijk was/is voor beheer en is alleen de externe partij gevraagd voor de pentest ?

[Ford Prefect]

Volgens onze regionale krant hier in Twente was dat er zeker, een zekere Switch IT Solutions uit Enschede (ik ken het bedrijf persoonlijk niet). Aldus de krant:

De gemeente onderzoekt in hoeverre Switch IT Solutions uit Enschede, dat het gemeentelijke netwerk beheerde, aansprakelijk kan worden gesteld. Volgens onderzoekers heeft dat bedrijf onvoldoende veiligheid in het systeem ingebouwd.

https://www.tubantia.nl/h...-was-welkom2020~aa0b6635/

[Killah_Priest]

Uit het verhaal op de website van de betreffende leverancier maak ik op dat één van de eigen beheerders bij de gemeente het Welkom2020 wachtwoord had ingesteld en poort 3389 heeft opengezet (die firewall viel buiten de scope van hun beheer).

[Harm_H]

Precies. Ik erger me eraan dat pentesters helemaal diep gaan op technische details van een bepaalde software.

Dit terwijl het belangrijkste - welke machines en servers hebben we allemaal - door beheerders wordt gemist. De gemiste business analisten zijn in die zin toch wel de mensen die de IT bij elkaar houden.

Iedereen een beetje schuldig:

• Lokale onderbetaalde beheerder die de rdp en poort open zet
• Netwerk bedrijf
• Sogeti, kapitalistisch, dat niet verder kijkt dan de gegeven scope
• Gemeeente bestuurders die wel dure consultants inhuren, maar geen dure IT werknemers
• De bitcoin kopers die niet inzien dat ze dit aantrekkelijk maken

[Reactie gewijzigd door Harm_H op 24 juli 2024 13:42]

[Dadona]

"Sogeti, kapitalistisch, dat niet verder kijkt dan de gegeven scope" Buiten scope gaan is extreem riskant. Zelfs binnen de scope zijn pentesters al meer dan eens in de problemen gekomen (denk aan de hackers van Coalfire: https://www.wired.com/sto...hite-hat-hackers-in-jail/ Buiten scope, kun je andere partijen betrekken die geen toestemming geven / hebben gegeven. Daarnaast hoop je dat de pentester al zijn tijd in het object van onderzoek steekt. Niet dat diegene doodleuk een lading aan tijd in andere objecten gaat steken.

[Christoxz]

Staat in het artikel:

"Er was sprake van een relatie gebaseerd op onderling vertrouwen en daarbinnen rolsonduidelijkheid tussen de gemeente en de externe partij die het beheer en de beveiliging regelde"

Dus een externe partij voor het beheer en beveiliging en een andere externe partij(Sogeti) voor de pentest

[Kraay89]

Een vrij heftige en toch ook wel pijnlijke conclusie, maar wat een openheid. Dat mag ook wel eens gezegd worden.

[Brinkiewestland]

Absoluut. De normale reactie in dit soort situaties is meestal om het stil te houden en niet zo uitgebreid te onderzoeken en te publiceren.

[Anoniem: 30722]

Zwak? Welkom2020 voor een beheerder 🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️ Die man zou voortaan met pen en papier moeten werken! En dan rdp en ftp aan het internet knopen, sorry, waar zit je verstand? 🤯

[Kevinns]

Duidelijk de verkeerde persoon op de verkeerde plek. Maar iemand binnen de gemeente is er ook verantwoordelijk voor dat deze persoon op deze plek terecht is gekomen en gebleven... Dit duidt ook op een dramatisch HR beleid en management.

[trisje]

Volgens mij staat er in het bericht da het beheer werd gedaan door een externe partij.

edir: Al is het niet duidelijk of de gemeente zelf ook toegang had tot het beheer van de systemen, wat er wel op lijkt.

[Reactie gewijzigd door trisje op 24 juli 2024 13:42]

[Kevinns]

Maar dit is wel van het niveau dat een loodgieter jouw lekkende waterleiding komt fixen met duct-tape. En dat je aan het eind van de dag zegt: ‘bedankt hè, stuur maar een rekening!’.

Uiteindelijk ligt de verantwoordelijkheid bij (iemand bij) de gemeente. En die persoon had duidelijk niet de juiste kwalificaties.

[trisje]

opzich is FTP niet het probleem, FTP kan goed voor sommige diensten. wel in een DMZ zetten, Je moet natuurlijk niet een zwak paswoord gebruiken en het account ook toegang geven tot andere zaken.
Remotedesktop beveel ik niet aan, 3389 open op het internet, binnen een uur heb je niets anders dan aanvallen op die poort. Maar met goede paswoorden kan men niet inloggen. Dit wordt best nog wel veel gebruikt. Meestal via een Gateway Server, zolang je accounts beperkt zijn en wachtwoorden van de accounts goed, kan dit best. Dit wordt best nog veel gebruikt op universiteiten bijvoorbeeld.
Echte probleem was dat er zwakke paswoorden waren gebruik en dat die account ook iets te veel toegang hadden.

[Triblade_8472]

Pentest mist open RDP server had ik een betere titel gevonden.

Je mag als gemeente niet blij zijn met je pentesters, maar net als Microsoft licenties, je bent te allen tijde zelf verantwoordelijk.

Testers zijn daarnaast een moment opname, je moet gewoon goede security lui inhuren én (wat vaak vergeten word) adviezen opvolgen.

Hiernaast mistaat het niet een degelijke lijst bij te houden met welke access er allemaal is vanaf buiten, dit moet je minimaal zelf op je firewall kunnen inzien.

[RM-rf]

Als ik dat eventjes grof doorlees is die penetratietest niet doorslaggevend misgegaan, maar vooral dan de audits en analyse van potentiele lekken en risico's..... die hadden de bestaande veiligheidslekken moeten vinden, omdat men dan in kaart probeert te brengen hoe de organisatie intern verloopt.

Een penetratietest is natuurlijk hooguit een poging van buitenaf met toestemming om met enkele standaard tools een 'poging' te doen een systeem te kraken door mensen die vaak ervaring hebben waar men dan van buitenaf kan proberen, maar geeft geen enkele garantie dat men alles kan vinden.
Dat de getroffen servers met zwakke passwords ook nooit doelwit daar waren lijkt ook vermoedelijk te betekenen dat ze nooit specifiek del van de opdracht waren.

Imho is het rapport ook niet erg gefocussed op die penetratietest en steken ze terecht ook vooral de hand in eigen borst. Dit soort dingen kun je niet zomaar delegeren naar een extern bedrijf en laten afhangen van een eenmalige penetratietest.... Veel belangrijker vij veiligheidsissues is dat in een organisatie zelf een mindset aanwezig is op te reageren en agereren op misstanden en onveilige situaties.