KPN blundert met standaard ADSL-wachtwoord
Door een standaard wachtwoord was het lange tijd mogelijk om toegang tot de beheeromgeving van 140.000 KPN-klanten te krijgen. De telecomprovider gebruikte voor zakelijke ADSL-klanten het standaard wachtwoord 'welkom01'. Klanten werden niet verplicht het wachtwoord te wijzigen. In combinatie met de vaste, eenvoudig te achterhalen gebruikersnaam van 'postcode+huisnummer' was het daardoor kinderspel om toegang te krijgen.
Webwereld tipte KPN, waarna de omgeving voor klanten offline werd gehaald. Volgens KPN hebben een kleine 120.000 van de in totaal 180.000 Z-ADSL klanten het standaardwachtwoord niet gewijzigd. Daarnaast blijkt dat circa 20.000 klanten de gebruikersnaam óók als wachtwoord gebruiken.
"Klanten lopen hierdoor het risico dat onbevoegden tamelijk eenvoudig op hun self care pagina zouden kunnen inloggen", zo laat KPN op de eigen website weten. Dat misbruik zou echter nooit hebben plaatsgevonden.
Wachtwoord
Om klanten te beschermen zijn de mogelijk kwetsbare wachtwoorden van 140.000 klanten automatisch gereset. "Dit betekent dat deze klanten zelf een nieuw wachtwoord moeten instellen", laat KPN weten. Vanmiddag komt beheeromgeving weer online. "Klanten kunnen vanaf dat moment weer inloggen. Voor circa 40.000 klanten met hun bekende, zelfgekozen wachtwoord; voor de andere 140.000 klanten met een nieuw aan te maken wachtwoord."
Ofwel een dikke 75%.
Met zulke klanten heb je geen aanvallers nodig.
Dan vergis je je dus best erg, waarom denk je dat default wachtwoorden problemen dan nog in 2012 elke dag voorbij komen?
Zelfs bij een groot concern als KPN, blijkbaar weet men het dus niet.
mogelijk , maar als je nu op vakantie bent als de KPN met je account afkomt , beetje dom, om met een bekende prinses te spreken. Maar daar maakt de KPN zich wel meer schuldig aan .....
Daarnaast blijkt dat circa 20.000 klanten de gebruikersnaam óók als wachtwoord gebruiken.
lol, en hoe kunnen zij dat weten als de wachtwoorden nou op z'n minst versleuteld staan in de database ?
Hebben ze nou echt zoveel moeite gedaan om de hashes van de gebruikers te vergelijken met een username ? Of staat er gewoon niks versleuteld in de database :P ?
- Zakelijke klant gaan naar retailer en kiest/koopt KPN-adsl zakelijk.
- Een afspraak voor een monteur via een brief van KPN
- Monteur zal alles regelen, ondernemer heeft het al druk zat en snapt het niet (groot deel is zzp/klein bedrijf)
- Monteur rommelt wat met draadjes - als je mazzel hebt krijg je wat uitleg over instellingen, meestal niet
- veel plezier ermee, t werkt, niets meer aan doen
Overigens gaat niemand mij wijs maken dat ze dit bij KPN nog niet wisten. Hoogstwaarschijnlijk is het een weloverwogen besluit geweest om het zo makkelijk mogelijk te maken in verband met kosten en tijd die ze in een klant willen stoppen. En waarom zouden ze het achteraf wijzigen als je daardoor slecht in het nieuws komt.
Ik begin serieus te twijfelen aan de deskundigheid van de ICT afdeling.
Zelfs een vrouw? Ik weet dat het ongelofelijk klinkt, maar wist je dat er zelfs seksisten bestaan die weten dat standaardwachtwoorden gewijzigd moeten worden?
Dat die klanten iets hebben verzuimd doet niets af aan het feit dat KPN hier ook een forse steek heeft laten vallen. Het is niet het een óf het ander, het moet het een én het ander zijn voor een goede veiligheid. Een leverancier kan niet achterover kan gaan leunen omdat de klanten zelf ook iets zouden moeten doen. KPN hoort als leverancier deskundig te zijn. Een professionele leverancier snapt dat en neemt voorzorgen. Dus nee, niets van dat "ho ho": het is onaanvaardbaar dat KPN dit niet beter had geregeld.
Daarnaast blijkt dat circa 20.000 klanten de gebruikersnaam óók als wachtwoord gebruiken.
lol, en hoe kunnen zij dat weten als de wachtwoorden nou op z'n minst versleuteld staan in de database ?
Hebben ze nou echt zoveel moeite gedaan om de hashes van de gebruikers te vergelijken met een username ? Of staat er gewoon niks versleuteld in de database :P ?
Ik heb, gewoon om even te controleren dat ik geen onzin uitkraam, een Python-script geschreven dat de users die hun usernaam als wachtwoord gebruiken afdrukt:
import crypt
with open('/etc/shadow') as shadow:
for line in shadow:
data = line.split(':')
if len(data[1]) <= 1:
continue
if crypt.crypt(data[0], data[1]) == data[1]:
print data[0]
Dat zijn 8 regels code. Dit is voor een systeem dat hashes in /etc/shadow heeft staan. Het moet met root-rechten uitgevoerd worden.
Het uitzoeken dat ik de crypt-functie nodig had ('man shadow' en 'man 3 crypt'), dat die beschikbaar is in de standaard-library van Python (zoeken naar de crypt-functie in de documentatie-index van python), en hoe de glibc2-extensies die die functie op mijn systeem gebruikt (uit 'man 3 crypt') precies uitpakken, alsmede het testen of het inderdaad werkt (met en zonder tijdelijke user die de usernaam als wachtwoord heeft ingesteld), dat alles heeft gemaakt dat ik er een klein half uurtje voor nodig had om dit te produceren in plaats van de paar minuten die het intypen van de programmacode alleen heeft gekost. Dit is geen brute-force-aanval, dit is gewoon per user één wachtwoordcontrole uitvoeren, waarbij je de usernaam zelf als wachtwoord gebruikt.
De crypt-functie roep je aan met het wachtwoord en de salt. De genoemde glibc2-extensies maken gebruik van modernere algoritmes dan de oorspronkelijke op DES gebaseerde versie van crypt mogelijk. In de shadow-file staan de usernaam en de wachtwoordhash in de eerste twee (door ':' gescheiden) velden van een regel. Het hash-veld is weer onderverdeeld in algoritme-id, salt en de eigenlijke hash. Dat kan je rechtstreeks als salt aan crypt-functie doorgeven, die alleen algoritme en salt oppakt en de hash negeert. Wat die teruggeeft is een hash in hetzelfde formaat, dus inclusief algoritmeaanduiding en salt. Daardoor kan je crypt met wachtwoord en hashveld aanroepen en geeft die bij een juist wachtwoord exact het doorgegeven hashveld terug. Voor het wachtwoord vul ik de usernaam in, en die druk ik af als dat het goede wachtwoord blijkt te zijn.
Voor systemen die wachtwoorden op een andere manier controleren en/of opslaan is ongetwijfeld een net zo eenvoudig script te schrijven.
Aan het beschrijven van wat ik gedaan heb heb ik nu al meer tijd besteed dan aan het schrijven en testen van het script. Zo simpel is dit.
Zelfs een vrouw? Ik weet dat het ongelofelijk klinkt, maar wist je dat er zelfs seksisten bestaan die weten dat standaardwachtwoorden gewijzigd moeten worden?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Chief Information Security Officer
Utrecht heeft jou nodig! Als Chief Information Security Officer speel jij een cruciale rol in de bescherming van de digitale informatie van de gemeente Utrecht. Als geen ander weet jij welke dreigingen er zijn en kun je deze vertalen naar risico's die de gemeente en haar inwoners lopen. Solliciteer nu!
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.
