Hogeschool Vives: wijzigen 17.000 wachtwoorden kost meer tijd dan gedacht
De Belgische hogeschool Vives die meer dan een week geleden door een cyberaanval werd getroffen hoopt morgen de deuren weer te kunnen openen, maar dat is nog niet zeker. Het wijzigen van 17.000 wachtwoorden van leerlingen kost meer tijd dan gedacht. Ook het herstarten van de systemen neemt meer tijd in beslag dan verwacht.
"Lessen vandaag de dag zijn niet meer met enkel een bord en krijtjes", zegt algemeen directeur Joris Hindryckx tegenover Het Laatste Nieuws. "Docenten gebruiken onder meer powerpoint en andere softwaretoepassingen, en aangezien ons wifinetwerk nog altijd plat ligt, kunnen die niet gebruikt worden." Volgens een verklaring van de hogeschool probeerden aanvallers met het wachtwoord van een leerling toegang te krijgen tot het netwerk.
"Dat lukte telkens niet. Maar afgelopen vrijdag, op 8 april, werd er rond 1 uur 's nachts opgemerkt dat die hackersgroep software probeerde te installeren, waarmee ze de wachtwoorden van ons datamanagement zou kunnen overnemen", zo liet directeur Hindryckx eerder weten. Na deze ontdekking werd besloten alle systemen uit te schakelen. Aangezien het vorige week vakantie in België was, was de impact hiervan beperkt.
De hogeschool moest vanwege de impact van de aanval vandaag de deuren noodgedwongen gesloten houden. Alle 17.000 leerlingen moeten hun wachtwoorden wijzigen. "Door de vakantie hebben we nog niet iedereen kunnen bereiken. Niet iedereen kan dat helemaal zelfstandig, dus onze servicedesk krijgt momenteel heel veel vragen binnen om gebruikers daarbij te helpen. Daarnaast zijn we nog druk bezig om extra beveiliging in te bouwen, zodat we met een gerust hart opnieuw online kunnen gaan", zegt Hindryckx.
Of dat morgen zal zijn is nog onduidelijk. "We doen er momenteel alles aan om tegen dan klaar te zijn, maar het is nog afwachten of we morgen dinsdag alles rond krijgen. Het is een heel arbeidsintensief werk." Tegenover Focus & WTV laat de directeur weten dat de situatie per dag wordt bekeken. "Maar dinsdag kunnen de lessen nog niet gestart worden. Wij hopen dat we woensdag opnieuw kunnen van start gaan."
Je reset de wachtwoorden van alle gebruikers en verwittigd ze *achteraf* ervan.
Je gaat niet wachten op dat mensen zelf reageren en je legt zeker niet de verantwoordelijkheid bij de gebruiker om dat te doen. Enige klachten over de procedure redirect je naar HR of de mentor en je zorgt dat je operationale staf 100% kan focussen op herstel werkzaamheden.
En waarom zet men niet gewoon een tweede tijdelijk netwerk op met beperkte bandbreedte.
QoS erop beperkt aantal gebruikers en enige dataopslag tijdelijk even via lokale schijven die je in een brandkluis legt.
Niemand op het het idee gekomen om even snel langs een winkel te gaan nieuwe apparatuur in te kopen abbonementje af te sluiten en gewoon weer op te starten?
Toen wij door een extreme storm (kleine 20 jaar terug) onze richtschotel connectie kwijt waren tussen twee locatie hebben we de telefoon gepakt provider gebeld en binnen twee dagen stonden er twee mobiele zendmasten voor Point-to-point wifi tot vervangende schotel alligned was. Dat was in de tijd dat glasvezel niet vanzelf sprekend was in heel Nederland en vergunningen een jaren ramp was. Geintje koste -+ 10000 euro maar stilstaan voor 1 dag was wel ietsje duurder als ook de claims van onze klanten.
Soms vraag ik me echt af wat voor opleiding dit soort mensen genoten hebben. Iedergeval geen IT Management of Datacom.
Als je nog steeds accounts software laat instaleren na dat incident en je gaat het feit dat het nieuwe wachtwoorden zijn gebruiken om jezelf opnieuw veilig te noemen, dan is er toch iets goed mis daar.
Wachtwoorden zijn voor de beveiliging van de accounts. De enigste mensen die je persoonlijk moet contacteren voordat je terug online gaat zijn mensen die voor een reden extra permissies nodig hebben en waar dus nooit door iemand anders op ingelogd mag worden. In theorie zou er ook door niemand anders op normale accounts ingelogd mogen worden, maar als dat toch gebeurd zou niet het hele systeem onveilig mogen zijn.
tl;dr: ze zouden beter hun systemen verbeteren in plaats van gebruikers lastig te vallen
Je reset de wachtwoorden van alle gebruikers en verwittigd ze *achteraf* ervan.
Je gaat niet wachten op dat mensen zelf reageren en je legt zeker niet de verantwoordelijkheid bij de gebruiker om dat te doen. Enige klachten over de procedure redirect je naar HR of de mentor en je zorgt dat je operationale staf 100% kan focussen op herstel werkzaamheden.
.
Het resetten van wachtwoorden zal niet zo'n probleem zijn, echter het uitgeven van de nieuwe (tijdelijke) wachtwoorden zal het meeste tijd kosten. Want hoe ga je de wachtwoorden uitdelen of communiceren met 17.000 mensen en op een veilige manier?
1. Naast de userid moeten zowel het oude als het nieuwe wachtwoord worden ingevuld. Het probleem daarmee is dat een wachtwoordreset voor iedereen impliceert dat ze aannemen dat de oude wachtwoorden gecompromitteerd kunnen zijn. Dat betekent dat de aanvaller de oude wachtwoorden kan hebben. Die kan dan via dit wachtwoordresetscherm de account van elke leerling overnemen. Oeps, dat wil je niet.
Daarom worden in dit soort gevallen alle wachtwoorden in een klap gereset en kan het wachtwoordresetscherm niet meer het oude wachtwoord controleren, want dat is gereset. Dat leidt tot de andere mogelijkheid:
2. De userid en het nieuwe wachtwoord moeten worden ingevuld. Nu kan niet alleen de aanvaller maar iedereen elke account waarvan ze de userid weten overnemen via het resetscherm. Oeps, dat wil je ook niet.
Daarom zie je dat men niet met die extra kolom werkt maar typisch een "wachtwoord vergeten"-dialoog heeft die, indien erkop geklikt wordt, leidt tot een e-mail naar de gebruiker (de leerling), met een wachtwoord-reset-link erin, die naar een scherm leidt waarop het nieuwe wachtwoord ingevuld kan worden. Omdat de link een uitgebreide random waarde bevat kan die alleen worden opgeroepen door degenen die de e-mail kunnen lezen. Dat is nog niet volledig waterdicht, maar zo'n opzet zet de sluizen niet open op de manier waarop jouw benadering, als ik die goed heb begrepen, dat doet.
Het zit er dik in dat het systeem een opzet als deze heeft, en dan is de constatering kennelijk dat onder die 17.000 leerlingen er te veel zijn die zoiets niet zonder hulp van de helpdesk kunnen.
Je reset de wachtwoorden van alle gebruikers en verwittigd ze *achteraf* ervan.
Je gaat niet wachten op dat mensen zelf reageren en je legt zeker niet de verantwoordelijkheid bij de gebruiker om dat te doen. Enige klachten over de procedure redirect je naar HR of de mentor en je zorgt dat je operationale staf 100% kan focussen op herstel werkzaamheden.
.
Het resetten van wachtwoorden zal niet zo'n probleem zijn, echter het uitgeven van de nieuwe (tijdelijke) wachtwoorden zal het meeste tijd kosten. Want hoe ga je de wachtwoorden uitdelen of communiceren met 17.000 mensen en op een veilige manier?
Men zou als eind gebruiker simpelweg wachtwoord vergeten doorlopen.
Het restant wat dit niet kan doorlopen om welke reden dan ook zal dit moeten melden bij hun mentor die kan dan begeleiding geven en de paar procent die je overhoudt die zet je door naar eerstelijns servicedesk.
Althans ik mag aannemen dat een hogeschool werkt met MFA en er dus een altijd bekende wachtwoord herstel alternatief is. Zo niet mogen ze mij betreft de eindverantwoordelijken voor het huidige beleid na dit fiasco de laan uit sturen.
17k gebruikers is peanuts in de huidige tijd.
Dat forensics lang duren alle begrip voor. Het doorlopen van een wachtwoord wipe protocol mag niet langer dan paar dagen duren op zo kleine schaal. Dit geintje loopt nu al sinds 8 april en ze melden het nog steeds als een storing. https://status.vives.be/
Ze geven notabene IT beveiliging opleidingen in hun aanbod ze hebben letterlijk een leger studenten die ingezet kan worden als praktijk opdracht voor supervised opzetten van noodvoorzieningen. En zo niet kun je ook simpelweg bedrijven hiervoor inhuren gespecialiseerd in noodondersteuning.
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.
