Aanvaller gemeente Buren kreeg toegang via vpn-wachtwoord van 14 karakters
De aanvaller die systemen van de gemeente Buren met ransomware infecteerde wist al in januari van dit jaar via een vpn-wachtwoord van veertien karakters toegang te krijgen. Dit wachtwoord was door wachtwoordmanager KeePass gegenereerd en bestond uit hoofdletters, kleine letters, cijfers en speciale karakters, zo blijkt uit het onderzoeksrapport naar de ransomware-aanval van securitybedrijf Hunt & Hackett dat vandaag openbaar is gemaakt.
Eerder meldde de gemeente Buren zelf dat de aanvaller gebruikmaakte van de inloggegevens van een niet nader genoemde leverancier. Er werd verder geen gebruikgemaakt van multifactorauthenticatie, waardoor de aanvaller alleen met het wachtwoord kon inloggen. Bij de aanval werd zeker 126 gigabyte aan data buitgemaakt en op internet gepubliceerd, waaronder identiteitsbewijzen.
Op de getroffen systemen stonden kopieën van ruim 1300 identiteitsbewijzen. Om misbruik te voorkomen geeft de gemeente getroffen inwoners de mogelijkheid om hun identiteitsbewijs kosteloos te vervangen. Op dit moment zijn er al ruim duizend inwoners aangeschreven met het aanbod hun identiteitsbewijs te laten vervangen.
Vpn-wachtwoord
Uit het onderzoek blijkt dat de aanvaller al in januari toegang tot de systemen van de gemeente kreeg. Hiervoor werd er vanaf een Russische ip-adres op een legitiem vpn-account ingelogd. "Het wachtwoord van dit account was willekeurig gegenereerd door KeePass, en bestond uit 14 karakters afwisselend hoofdletters, kleine letters, cijfers en speciale karakters. Dit is van voldoende complexiteit en lengte om een succesvolle uitkomst van een brute force aanval minder waarschijnlijk te maken", aldus de onderzoekers.
Die weten niet hoe de aanvaller het wachtwoord in handen heeft gekregen. "Het is een mogelijkheid dat dit wachtwoord is gelekt, of op een andere manier door een aanvaller is buitgemaakt op een systeem buiten de omgeving van de gemeente." De eerste keer dat de aanvaller weet in te loggen is op 18 januari. Vervolgens voert hij een bruteforce-aanval uit om toegang tot andere accounts te krijgen.
"Mogelijk is het wachtwoord [Geredigeerd] van het [GN1] account door middel van een (offline) brute force aanval buitgemaakt. Dit wachtwoord lijkt sterk, maar is dat in feite niet. Dat het is buitgemaakt, staat vast", zo laten de onderzoekers verder weten. Het "GN1-account" was van een domeinbeheerder. Daarmee kon de aanvaller zich lateraal door het net netwerk bewegen en de ransomware uitrollen.
Beveiligingsniveau
De onderzoekers stellen dat met een hoger beveiligingsniveau de aanval aanzienlijk moeilijker was geweest om succesvol uit te voeren. "Echter, de ervaring leert ook dat gemotiveerde aanvallers bijna altijd wel een point-of-entry vinden waarmee de initial access kan worden verkregen. Wat er daarna gebeurt hangt in hoge mate af van de mate waarin een organisatie in staat is om de aanval vroegtijdig te detecteren", zo laten ze verder weten.
Conclusie
Uit het rapport blijkt dat de gemeente Buren verschillende maatregelen had kunnen nemen om zich beter te beschermen. Zo was het wachtwoord van het beheerdersaccount niet voldoende complex om een bruteforce-aanval te voorkomen. Ten tweede was het wachtwoordbeleid niet dusdanig ingericht dat dergelijke wachtwoorden met enige regelmatig werden gewijzigd. Als derde en laatste waren accounts met verhoogde rechten, en de vpn-accounts, niet beveiligd met een tweede factor.
Het inloggen door de aanvaller met het vpn-account genereerde wel voor meldingen binnen de antivirussoftware, maar hier werd geen opvolging aan gegeven. Eeen van de belangrijkste systemen die de aanvaller benaderde was de bestandsserver. "Omdat er geen proces is ingericht om adequaat om te gaan met meldingen uit detectiemechanismen zoals antivirus, is het mogelijk geweest voor de aanvaller om ongemerkt door het netwerk te bewegen en grote hoeveelheden informatie van de organisatie te kunnen exfiltreren", zo concluderen de onderzoekers.
Afsluitend doen de onderzoekers verschillende aanbevelingen, onder andere wat betreft de complexiteit en omgang met wachtwoorden, het gebruik van multifactorauthenticatie, systeembeheer, het uitschakelen van legacy protocollen zoals SMBv1 en het laten uitvoeren van een security assessment.
Het "vanaf een Russisch IP-adres" is non info maar klinkt wellicht lekker. Ik zie altijd een evenredige verdeling van pogingen vanuit China, Rusland en de VS waarbij de VS aanvoerder is.
Het klinkt alsof er een belangrijk stuk informatie mist.
Het "vanaf een Russisch IP-adres" is non info maar klinkt wellicht lekker. Ik zie altijd een evenredige verdeling van pogingen vanuit China, Rusland en de VS waarbij de VS aanvoerder is.
Ik beschouw mijzelf als een leek op dit gebied, maar een wachtwoord bestaande uit 14 tekens, en ook nog eens willekeurig gegenereerd, is natuurlijk op dit moment onkraakbaar met de huidige techniek, daar zullen de echte expert het wel over eens zijn. Het lijkt mij dan ook duidelijk, dat hier een menselijke fout aan vooraf is gegaan, die men wellicht om juridische redenen (schadeloosstelling benadeelden) tot alle prijs tracht te verhullen.
Het klinkt alsof er een belangrijk stuk informatie mist.
Dat heeft het ook. Het onderzoek heeft die informatie niet gevonden , maar is zich er wel van bewust.
Relevante quote over dit 14 char random VPN password :
Dit is van voldoende complexiteit en lengte om een succesvolle uitkomst van een brute force aanval minder waarschijnlijk te maken", aldus de onderzoekers.
Die weten niet hoe de aanvaller het wachtwoord in handen heeft gekregen. "Het is een mogelijkheid dat dit wachtwoord is gelekt, of op een andere manier door een aanvaller is buitgemaakt op een systeem buiten de omgeving van de gemeente."
Gemiddeld zal een aanvaller dus 1 x 10^25 brute force pogingen moeten doen om het wachtwoord te achterhalen. De kans dat zo'n random gegenereerd wachtwoord toevallig voorkomt in een lijst met veelgebruikte wachtwoorden, is daarmee ook "één gedeeld door astronomisch" klein. Net zoals de kans dat KeePass met de gegeven instellingen toevallig "gemeente buren" als wachtwoord genereert.
Als het de aanvaller lukt om 1.000.000 online pogingen per seconde te doen, is hij gemiddeld 10^19 seconden bezig. Als ik met 365 dagen per jaar reken duurt die aanval, ervan uitgaande dat er geen onderbrekingen zijn en ik geen reken/denkfouten maak, gemiddeld 317.097.919.837 jaar.
Daarbij ga ik ervan uit dat er geen timing-attack mogelijk is (d.w.z. dat de VPN-server iets sneller of juist iets langzamer een foutmelding terugstuurt naarmate meer karakters in het geprobeerde wachtwoord kloppen). Oftewel, op basis van de beschikbare informatie denk ik dat we gerust kunnen uitsluiten dat het VPN-wachtwoord middels een online brute-force aanval op de VPN-server door de aanvaller is achterhaald.
De kans dat het wachtwoord middels phishing of via een gecompromitteerd systeem van een legitieme inlogger is achterhaald, is gigantisch groter.
Helaas komt het voor dat medewerkers van een externe beheerpartij allemaal hetzelfde VPN-account gebruiken. Als zo'n medewerker vertrekt en de KeePass database (of de Excel sheet) meeneemt, of het wachtwoord onthoudt, loop je onnodige risico's. Een sluitende administratie wie waar kan inloggen is stomvervelend maar noodzakelijk, alsmede het ASAP blokkeren van elk persoonlijk account zodra toegang niet meer nodig/gewenst is plus het wijzigen van alle wachtwoorden van noodzakelijkerwijs shared accounts.
AVG?
En ja Jan en alleman (bedrijfjes) werken met gegevens van de VNG, dat leveren de VNG zelf aan, en Weg is het toezicht op betrouwbare verwerking van Paspoort gegevens. (Bsn .o.a.)
Zou ook een goed idee zijn om dat nummer eens beter af te schermen, d.m.v.
Gehele, of gedeeltelijke versleuteling.
Bij het uitvaardigen ervan geeft men aan dat je dit veilig te dient te bewaren, in de praktijk,
Komt daar Niets van terecht, op straat kan je je Bsnnetje ff tonen aan een willekeurige BOA,
Of andere ambtenaar.
Uitermate knullig hoe dit allemaal gaat.
Kan zijn dat iemand het ergens verkeerd copy/pasta'd heeft, en/of iemand al toegang tot een machine had waar het VPN wachtwoord was ge-keylogged (of van het geheugen gepakt was, virussen herkennen dit soort copy/paste dingen tegenwoordig ook).
Dit heeft niks met KeePass zelf te maken, maar meer met het lekken van wachtwoord.
Maakt volgens mij niet echt een drol uit wat voor manager ze gebruiken, als je beleid en omgang met de wachtwoorden al brak is, is het peanuts.
KeePass heeft trouwens niet direct een maximum grootte van wachtwoorden.
VPN software zal de factor zijn waar de limitatie zit, ligt er ook beetje aan welke software je gebruikt.
Heb zelf meestal 32 characters of groter als dat kan.
Mogelijk hebben aanvallers daar het VPN wachtwoord vandaan...
Of van de privé-pc van 1 van de beheerders...
Maar aan de andere kant neemt het risico behoorlijk toe als meerdere mensen op admin niveau hun wachwoorden ergens bewaren. Er is wel iets te zeggen voor gecentraliseerde aanpak i.c.m. IP logging. Als een medewerker vertrekt moeten accounts worden geblokkeerd of wachtwoorden worden vervangen. Altijd.
Verder wel met je eens dat het belachelijk is dat zoveel bedrijven een kopie van je ID willen maken. Bekijken en identiteit verifieren is geen probleem, maar kopieren? Niks er van, nergens voor nodig.
Dat hoeft niet als ze de wachtwoord hash onderscheppen en dan verder offline gaan bruteforcen, zoals veel technieken werken omdat bij de meeste normale wachtwoord challenges je na 5 / 10 pogingen wel geblokkeerd wordt (al dan niet voor enkele minuten).
Helaas is 2fa ook niet zaligmakend want ook daar valt omheen te klussen. Het probleem is het gedrag van de gebruikers en de soms stompzinnige wijze waarop het beheer is ingericht. Leverancier op je omgeving laten inloggen met alleen username/pass? Onder welke steen heeft beheer gelegen als ze dat nog toestaan?
Dat een wachtwoord vaak moet worden gewijzigd is ook maar security by obscurity want mensen hebben nu eenmaal een slecht geheugen en gaan het wachtwoord ergens opschrijven of herbruiken het vorige wachtwoord maar zetten er een cijfer 2 achter i.p.v. van de cijfer 1 die er eerder stond. Dat heet het paard achter de wagen spannen in vaktermen.
Beter is het om alle wachtwoorden op een bepaald moment te laten vervallen, zodat gebruikers een nieuw wachtwoord moeten opstellen, maar de kwaliteit van de nieuw in te voeren wachtwoorden door tooling te laten beoordelen of deze aan de policy voldoen, niet op de verboden lijst staan (welcome01 t/m 10 duizend) of ergens op darknet voorkomen. Verder is het dan toch van belang om alle online accounts te voorzien van een of meerdere vormen van MFA. Sowieso zouden leveranciers nooit rechtsreeks toegang mogen hebben tot je omgeving maar op z'n minst via een stepping stone constructie waarbij mfa wordt afgedwongen en waarbij de leverancier alleen binnen een tijdelijke VDI eventueel beheerwerk mag doen op de specifieke omgeving waar dat beheer werk moet plaatsvinden. En uiteraard monitor je al het gedrag op eventuele afwijkingen.
Ik verbaas me soms nog weleens over de naievitet bij beheerders dat ze blind op leveranciers vertrouwen. Dat je dit niet van bestuurders hoeft te verwachten dat ze zich hiervan bewust zijn is tot daar aan toe maar van beheerders mag je anno 2022 toch we verwachten dat ze hun zaakjes inmiddels wel op orde hebben en op z'n minst security whitepapers van diverse vendoren lezen en de beveiliging in de pas laten lopen met de huidige eisen.
Dit kan net zo goed het probleem geweest zijn.
Tip: dus altijd 15 karakters gebruiken ;)
Helaas is eap-peap mschapv2 snel te implementeren (kost dus weinig) en is het met elk type apparaat compatible, daarnaast ook gebruiksvriendelijk voor de eindgebruiker die met hetzelfde account kan aanmelden op de wifi. Zo is de cirkel rond en wordt deze onveilige techniek instand gehouden.
Beter kan gebruik worden gemaakt van eap-tls waarbij certificaten worden geïnstalleerd op eindapparatuur, stuk veiliger ;).
Dit kan net zo goed het probleem geweest zijn.
behalve dan dat dit een heeeeeeel stuk minder waarschijnlijk is alleen al door gebruikers statistieken en ook nog eens door het aantal malwares dat zonder klikken of actie van die gebruiker ene keylogger kan runnen in een kernel die verder met alle modules etc netjes pgp gesigneerd is en met secureboot via UEFI gestart ist. maar dat wist je toch allemaal wel nietwaar?
Dit is al sinds tientallen jaren een oud discussiepunt.
Het is de kunst om een sterk wachtwoord te maken tegen (Brute Force / Social engineering / AI...) hackers die tooch nog goed door mensen gebruikt en beheerd kunnen worden volgens vingerende policies.
De minimale wachtwoordlengte schuift steeds meer naar achteren en men heeft het op dit moment al over minimaal 14 tekens. WIe doet dat ????
Vanaf 2030 of eerder zullen Quantum computers deze klassieke waarden echter overtreffen en men heeft nu al voorstellen over Kwantumbestendige encryptie-algoritmen welke RSA etc. overstijgen.
Bij een gewoon mens in de alledaagse praktijk is het vragen naar een wachtwoord (zelfs zeer dom opgebouwd zoals Pietje 123) als vloeken in de kerk. Soms denkt men zelfs dat een wachtwoord van een vorige provider van 5 jaar geleden bij een nieuwe provider ook nog geldt !? Potverdori....
En dan nog regelmatig de wachtwoorden veranderen en versterken etc. etc voor tientallen omgevingen en zie het gaat mis.
Andere gebreken:
- men onthoudt een tiental wachtwoorden in het hoofd,
- men schrijft ze op de achterkant van een envelop en raaktd die kwijt,
- men gebruikt overal dezelfde
- men schrijft ze (onversleuteld) op in een boekje
- men gebruikt een wachtwoordmanager maar vergeet die naderhand.....
en ga zo maar door....
In bedrijven is het doorgans beter maar ook daar is het nodige voor verbetering vatbaar.
Dus we hebben nog een lange weg te gaan.
By the way; bij KeePass kun je achtwoorden van duizenden willekeurige karakter genereren. Dus het ligt niet aan KeePass maar aan de mens erachter.
Bijvoorbeeld: wachtwoord
»CO·{Àdg<htXöm·Ûhm-»$Æ`÷5b¹=~0wEÌ&é9byê0·«Ü+Á5õ"5¸£%£|¢DØ3qµºi1h&@(]8=@äH{³Cþè«Cf .................Î6þBsÐ,ÿbº³SH¿ÁiÏ|hz,8iÎÚîn0@¥bÚ!v=ß[Ä«ëß÷M;#ÆÍ®Ó
En zoals vaker: DE MENS IS DE ZWAKSTE SCHAKEL in de beveiliging.....Een computer maakt niet uit of 0 of 1. Alleen vereist een langer wachtwoord meer ruimte, meer processing en meer tijd is benodigd. En er zijn systeem en app-limieten.
Blijf veilig,
Cowb0ysec
Dit is al sinds tientallen jaren een oud discussiepunt.
Het is de kunst om een sterk wachtwoord te maken tegen (Brute Force / Social engineering / AI...) hackers die tooch nog goed door mensen gebruikt en beheerd kunnen worden volgens vingerende policies.
De minimale wachtwoordlengte schuift steeds meer naar achteren en men heeft het op dit moment al over minimaal 14 tekens. WIe doet dat ????
Vanaf 2030 of eerder zullen Quantum computers deze klassieke waarden echter overtreffen en men heeft nu al voorstellen over Kwantumbestendige encryptie-algoritmen welke RSA etc. overstijgen.
Bij een gewoon mens in de alledaagse praktijk is het vragen naar een wachtwoord (zelfs zeer dom opgebouwd zoals Pietje 123) als vloeken in de kerk. Soms denkt men zelfs dat een wachtwoord van een vorige provider van 5 jaar geleden bij een nieuwe provider ook nog geldt !? Potverdori....
En dan nog regelmatig de wachtwoorden veranderen en versterken etc. etc voor tientallen omgevingen en zie het gaat mis.
Andere gebreken:
- men onthoudt een tiental wachtwoorden in het hoofd,
- men schrijft ze op de achterkant van een envelop en raaktd die kwijt,
- men gebruikt overal dezelfde
- men schrijft ze (onversleuteld) op in een boekje
- men gebruikt een wachtwoordmanager maar vergeet die naderhand.....
en ga zo maar door....
In bedrijven is het doorgans beter maar ook daar is het nodige voor verbetering vatbaar.
Dus we hebben nog een lange weg te gaan.
By the way; bij KeePass kun je achtwoorden van duizenden willekeurige karakter genereren. Dus het ligt niet aan KeePass maar aan de mens erachter.
Bijvoorbeeld: wachtwoord
»CO·{Àdg<htXöm·Ûhm-»$Æ`÷5b¹=~0wEÌ&é9byê0·«Ü+Á5õ"5¸£%£|¢DØ3qµºi1h&@(]8=@äH{³Cþè«Cf .................Î6þBsÐ,ÿbº³SH¿ÁiÏ|hz,8iÎÚîn0@¥bÚ!v=ß[Ä«ëß÷M;#ÆÍ®Ó
En zoals vaker: DE MENS IS DE ZWAKSTE SCHAKEL in de beveiliging.....Een computer maakt niet uit of 0 of 1. Alleen vereist een langer wachtwoord meer ruimte, meer processing en meer tijd is benodigd. En er zijn systeem en app-limieten.
Blijf veilig,
Cowb0ysec
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
