KPN haalt site Gemnet offline na beveiligingsprobleem - update

KPN heeft de website van zijn dochteronderneming Gemnet offline gehaald nadat bleek dat deze te hacken was. Gemnet ondersteunde het aanvragen van PKI-certificaten voor de overheid. KPN onderzoekt het lek.

Het lek werd ontdekt door een hacker die tegenover Webwereld zegt 'te vermoeden niet de eerste persoon te zijn die toegang heeft verkregen tot de systemen'. KPN laat weten het lek te onderzoeken en uit voorzorg de site offline te hebben gehaald. "Het ziet ernaar uit dat de mogelijke hack alleen de server betrof die de algemene informatie voor bezoekers zichtbaar maakt", verklaart KPN. Gemnet werd in 2006 ingelijfd door KPN. Daarvoor was het netwerkbedrijf in handen van de Vereniging van Nederlandse Gemeenten en de Bank Nederlandse Gemeenten.

De fout zou gelegen hebben bij de webbeheertool voor MySQL phpMyAdmin. Deze zou zonder wachtwoord toegang tot de database verleend hebben. Vervolgens was het mogelijk om documenten op de webserver in te zien en bestanden aan te maken, waaronder executables. Journalist Brenno de Winter claimt documenten op de server aangetroffen te hebben met informatie over de technische inrichting van het vertrouwelijke netwerk tussen KPN en overheden of bedrijven.

Onduidelijk is welke gevolgen een mogelijke hack door derden heeft voor de uitgifte van pki-overheidscertificaten. Eerder dit jaar luidde een lek bij de uitgifte van certificaten het eind van het bedrijf DigiNotar in. KPN zelf staakte de uitgave van certificaten begin november na mogelijk misbruik van een webserver van dochter Getronics.

Update, 31 december 2011 17:41: Anders dan in dit artikel werd vermeld, is Gemnet geen certificaatleverancier. Gemnet ondersteunde het aanvraagproces voor certificaten, maar leverde die zelf niet.

Reacties (35)

[Pixeltje]

De fout zou gelegen hebben bij de webbeheertool voor MySQL phpMyAdmin. Deze zou zonder wachtwoord toegang tot de database verleend hebben.

Euh wacht, wat?! Dan ligt de fout dus niet bij de tool maar bij de persoon die de tool heeft ingericht!

[Verwijderd]

De fout zou gelegen hebben bij de webbeheertool voor MySQL phpMyAdmin

Lijkt me toch dat je daar tenminste een ip-restrictie op zet ofzo?

[_Piwi_]

Of helemaal geen phpmyadmin installeren... mysql CLI is voldoende lijkt mij. Daarnaast is het opslaan van vertrouwelijke documenten op zo'n servers echt not done... Diegene dit dit heeft ingericht mag eens opnieuw de schoolbanken in zodat hij eens een les 'security' krijgt.

Ik noem dit sowieso niet hacken maar nalatigheid van KPN. Iedereen die maar iets van kennis heeft van internet had kunnen inloggen op phpmyadmin als ik het artikel moet geloven.

[NovapaX]

Of je installeert als developer gewoon een tool/applicatie op je workstation die vaak nog veel efficiënter werkt dan PMA.
Zie bijvoorbeeld Sequel Pro voor de Mac... geweldige db-beheer-app!

Als je dan netjes verbind op de mysql-socket via ssh (authenticatie via password...you know + certificate... you have. eventueel aangevuld met een firewall ip-restrictie op je ssh-poort) dan heb je mijns inziens een veel veiligere EN gebruiksvriendelijke oplossing.

Voor een devver hoeft dat geen probleem te zijn om in te stellen, ik kan het ook....

[Reactie gewijzigd door NovapaX op 2 augustus 2024 00:26]

[SlaadjeBla]

developers toegang geven tot je productiemachine? Ben jij betoeterd?

Dit heeft verder weinig met phpMyAdmin te maken, maar alles met slecht beheer. Er is op zich niets mis met phpMyAdmin, zolang het goed beheerd en onderhouden wordt. Dat lijkt hier niet gebeurd te zijn.

[NovapaX]

Lijkt me ook niet nodig inderdaad, maar soms zal de productiedatabase toch benaderd moeten worden. 'devver' was iets verkeerd gekozen.

En opzich is er niet zoveel mis met PMA als tool, maar wel vaak hoe gemakkelijk het benaderbaar is.... het is vaak gewoon de juiste URL invullen en PMA staat voor je om een wachtwoord te vragen... = 2x something you know (or geuss)

Daarom vind ik dat PMA überhaupt niet thuishoort op welke productieserver dan ook.
Wel installeren en dan afschermen met IP-filters en dergelijke vind ik een slechte, omgekeerde werkwijze. Zelfde als een firewall configureren door alles open te zetten en dan dicht te zetten wat je denkt dat dicht kan.....

[mrdemc]

Nee.
Een firewall instellen met alles open en alleen sluiten waarvan je denkt dat het dicht moet, is zeggen alle ip's toestaan op pma behalve de ip's/ip-ranges die ik nu blokkeer. Je vergelijking gaat dus een beetje mis hier.

[Sfynx]

developers toegang geven tot je productiemachine? Ben jij betoeterd?

Aparte deploy afdelingen heb je niet bij kleine bedrijfjes, dan schieten de developers het gewoon live als alle tests slagen.
Wel eens dat het gecontroleerd moet gebeuren vanuit een VCS met database migratie scripts o.i.d. en niet door handmatig shit in de database te prakken met iets als PMA.

[Reactie gewijzigd door Sfynx op 2 augustus 2024 00:26]

[Rynus_Rein]

Gemnet, leverancier van certificaten van (semi-) overheidsinstellingen is dan ook geen klein bedrijf.
Dat phpMyAdmin is geinstalleerd op een productieserver is fout 1 (deployment doe je met geprepareerde SQL scripts), dat het toegankelijk is van buitenaf is fout 2, geen wachtwoord nodig is fout 3.
Er zijn schijnbaar geen mogelijkheden geweest om in het proces voor uitgifte van certificaten te komen. Dat neemt niet weg dat het voor een bedrijf als Gemnet zeer genant is zo'n domme fout te maken.

[mpijnen]

mysql CLI is voldoende zeg je ?
Wellicht waarvoor jij het gebruikt, maar PHPMyAdmin biedt toch wel duidelijk meer functionaliteit als wat mysql CLI kan.

Wel blijft het feit dat ze hem beter hadden moeten dichtgooien, maar dat terzijde.

[_Piwi_]

Wat moeten hun dan wijzigen via phpmyadmin? Alles wat phpmyadmin kan kan ook via de CLI maar vereist uiteraard wel wat kennis. Zo te horen heb je dus nooit met de CLI gewerkt

[mpijnen]

Oké dan met voorbeeld:

Ga maar eens een set van 20 records handmatig updaten (opgezocht a.d.h.v. een query).
Dan ben je blij met een applicatie zoals PHPMyAdmin.

En ja ook ik werk vaak met mysql CLI

[DJMaze]

Dan kan je ook via SSH een tunnel open zetten en HeidiSQL, Aqua Data Studio, NaviCat of een andere favoriete gui applicatie gebruiken.
En dat werkt veel beter dan phpmyadmin.

En als je bedoeld dat de huis tuin en keuken website beheerder dat niet snapt, dan moet hij geen belangrijke website onderhouden.

[Reactie gewijzigd door DJMaze op 2 augustus 2024 00:26]

[mpijnen]

Klopt, je kunt inderdaad van allerlei andere GUI's daarvoor gebruiken, maar ieder zijn voorkeur daarvoor, en een van die GUI's is dus PHPMyAdmin.

Ook met de SSH tunnel zorg je voor een extra beveiliging, zelfde principe.

@Sv3n
20 update queries schrijven is dus duidelijk niet sneller dan in een lijstje de waardes even aanpassen en op update te klikken, dat was mijn statement

@Loserebzo
Klopt ik gaf aan dat PMA duidelijk wat meer functionaliteit biedt dan CLI, en dat is ook zo. Wat ik niet heb gezegd is dat dat nieuwe functionaliteiten van mysql zelf zijn, maar dat zijn natuurlijk de functionaliteiten om de commands heen.

Wat ik samenvattend wil zeggen is dat de beheerder blijkbaar graag met PHPMyAdmin werkt, dat daar in principe niets mis mee is omdat het nét wat meer functionaliteiten/eenvoudigheid biedt (zeg niet dat het mijn voorkeur heeft), maar dat de manier van beveiligen het probleem .

En nu weer O.T.

[Sv3n]

20 update queries schrijven is dus duidelijk niet sneller dan in een lijstje de waardes even aanpassen en op update te klikken, dat was mijn statement

Jij past dus met de hand zo maar wat waardes aan in je productieomgeving? Nou ligt dat in de business waar ik zit helemaal gevoelig(zorg), maar als ik data op een productieomgeving moet aanpassen test ik dat eerst op mijn testomgeving, dan wordt het uitgevoerd op de acceptatieomgeving waarna de klant het controleert en dan pas wordt zoiets op productie gedaan. Op een productieomgeving zou ik dus nooit handmatig gegevens aan gaan passen, altijd met een query die getest is, het liefst op een kopie van de productieomgeving.

[mrdemc]

Beetje een drogreden. Deze aanpassing moet je, ondanks dat je het eerst moet testen waar ik het ook mee eens ben, toch uiteindelijk uitvoeren in je productieomgeving. Bij het wijzigen van waardes in de tabellen kom je toch uit op queries draaien op de productiebak. Of dat nu via de CLI gaat of via de PHPmyadmin maakt dan niet uit. In beide gevallen ben je vatbaar voor lekken, en ik beide gevallen dien je dit te beveiligen op IP en met een password. Ook zou je voor elke actie een apart account moeten hebben in het geval van externe toegang.
Verder is phpmyadmin niet iets wat not-done is, want het is verrekte handig in veel gevallen, maar je moet het wel gewoon beveiligen!! Iemand hierboven zegt dan: Je kunt met de cli werken in een SSH-tunnel: Dat is ook enorm vatbaar voor fouten! Het liefst doe je zulke aanpassingen gewoon rechtstreeks op de server maar dat kan niet altijd. En met een SSH-toegang kun je zelfs nog meer dan alleen de database veranderen, iets wat in phpmyadmin wel restricted is tot alleen de database.

[thegve]

Wat een moeilijk gezeur hier. Je installeert gewoon een tweede servertje waar je phpmyadmin opzet. Deze beveilig je qua netwerk/firewall dat deze alleen vanuit je lan bereikbaar is, en een TCP verbinding mag maken op de TCP poort van de mysql server. De mysql timmer je vervolgens ook dicht, iedereen blij. Laat iedereen lekker de tools gebruiken die hij zelf fijn vind.
Overigens vind ik zowel MySQL als phpmyadmin kut, maar daar gaat het verder niet om.

[Sv3n]

Update table set veld = waarde where id in (select id from table .....) ?

Waarom zou je dat überhaupt handmatig willen doen?

[Loserenzo]

"Wellicht waarvoor jij het gebruikt, maar PHPMyAdmin biedt toch wel duidelijk meer functionaliteit als wat mysql CLI kan"

Als je bedoelt dat je je DB kunt 'tekenen' (a-la mysql-workbench) in phpmyadmin tegenwoordig, zo lijkt het. Dan ja.. Ik heb 3 seconden op de website van pma gekeken.
Maar pure mysql functionaliteit zoals in jouw voorbeeld, dan neen.

En als je er even over nadenkt kom je er zelf ook achter dat je je antwoord wat had kunnen nuanceren.
Alle mysql-functies die door het php-scriptje worden aangeroepen zitten in de CLI. Logisch ook, ze gebruiken onder water dezelfde shared objects. Waarschijnlijjk zijn er via de CLI nog meer functies aan te roepen die niet via de webinterface beschikbaar zijn.. Ik denk aan partitioning bijvoorbeeld, replicatie ofzo, dat soort dingen.
Maar ik weet het niet, want ik gebruik phpmyadmin nooit, omdat ik alles wat ik wil via de CLI kan doen.

[Verwijderd]

Met de CLI kan je alles én meer hoor; alleen is er meer kennis vereist.

[Verwijderd]

Gebruik dan MySQL Yog Community.
Veel batchwerk makkelijk te fixen, alles simpel te beheren (als je de juiste permissie hebt). Ik gebruik het ook omdat ik dan simpel de data van de slave even kan kopiëren naar mijn testdatabase. Als er dan wat breek kan ik de replicatie zo weer een schop geven en alles doet het weer .

PHPMyAdmin is een leuk tooltje als je zelf geen shell toegang hebt en de database alleen lokaal is te benaderen, maar voor de rest zou ik dat geen moment op mijn webserver laten staan. Al was het alleen maar omdat je dan ook heel de tijd versies moet blijven updaten en een keer bij mij was misgegaan (exploitje).

[Verwijderd]

Dat is niet zomaar een lelijke fout, maar eerder gebrek aan kennis om basisbeveiliging in te stellen op informatie die als gevoelig kan worden omschreven, bovendien hoort een wachtwoord op een inlogsysteem te zitten... Het toestaan om wachtwoorden null te laten is nalatigheid van de ontwerpers van een dergelijk systeem (PHPMyAdmin dus).

[mrdemc]

Nee, phpmyadmin vraagt namelijk om het wachtwoord van de sqlserver. Als jij deze als gebruiker instelt op niets, dan heeft phpmyadmin dat ook niet nodig. Standaard staat het root-wachtwoord van mysql ook op leeg trouwens.
Verder is het een mogelijkheid in pma om het wachtwoord te onthouden, dan moet je dat echter wel in het script doen via het configuratiebestand. Dat is een handigheidje van pma voor dev-omgevingen zodat je niet elke keer overal hoeft in te loggen, maar dat moet je dan niet gaan doen op een productieomgeving. Het is dan ook niet standaard aangegeven dat het een mogelijkheid is, dus als dat het geval is geweest is het een bewuste actie geweest van de dev'er die in dat geval een flinke tik tegen z'n achterhoofd zou moeten krijgen...

[Icekiller2k6]

Daarvoor haal je d esite offline..? .htaccess .htpasswd done?

en uiteraard password ingeven bij openen van phpmyadmin..

[thof]

Ze willen natuurlijk ook de gevolgen onderzoeken en controleren of er ook niet andere problemen zijn. Controleren wat er met de MySQL DB gebeurd is etc.

[Flight77]

Ik denk dat de site offline gehaald wordt, om te checken wat de gevolgen zijn...

Scenario: Als iemand link naar een 0-day hack in een website-pagina weet te plaatsen (via de database), kan er bijvoorbeeld een trojan geinstalleerd worden. Als je dit op de juiste plek doet, kun je vermoedelijk ook gericht de beheerder van de site targetten, met als doel wel het netwerk van de leverancier te bereiken.

[Robbbbbbbb]

Dit noem ik niet echt een hack, maar eerder nalatigheid van de instantie..

[Verwijderd]

Inderdaad, binnenlopen != hacken.

Beetje apart dat je een phpMyAdmin installeert zonder wachtwoord.
(volgens mij draait phpMyAdmin standaard na de installatie met wachtwoord dus dan heeft iemand bewust de config aangepast en de username/password vast gezet ?)

[mrdemc]

pma gebruikt het ww en gebruikersnaam van mysql zelf. Als je deze dus open laat dan heeft phpmyadmin dit ook niet nodig. pma heeft zelf geen gebruikersdatabase nodig, gebruikt dus puur die van mysql zelf.

[Davy de Vries]

nog niet eens een wachtwoord op PMA gaat wel heel ver voor zo'n bedrijf. dat hadden ze dan ook wel gehackt maar beter dan niks -,-

[cork87]

Je weet toch nooit wat derden op je systeem hebben gedaan? Daarom haal je dat offline en start je een onderzoek naar hoe dat heeft kunnen gebeuren en dat verhelp je uiteraard. Maar als een systeem gehackt wordt of in dit geval ingezien wordt door derden dan wil je toch ook wel weten wat ze hebben gedaan lijkt mij voordat je het weer online zet?

[fdh]

als ik het goed begrijp hebben ze dus op een webserver die in de dmz staat een webbeheertool voor MySQL gezet (en misschien ook de MySQL db zelf)?

Dit maakt de hele discussie over gui en cli wel heel off topic.

* Een beheer tool installeer je niet op een webserver in DMZ
* Een database installeer je niet op een server in DMZ

Normaal installeer je de db in je intern server netwerk, met in je DMZ de webservers.
Meestal heb je ook nog applicatie servers die dan ook in je server netwerk staan.
Dus de connectie verloopt van je web servers in dmz, naar je applicatie servers in je server netwerk (firewall dus tussen de web servers en je applicatie servers) en die hebben een connectie naar je database servers (met al dan niet nog een firewall tussen de applicatie en de db servers).

Een beheerstool staat dan op een afzonderlijke server (indien web based) in je server netwerk of op de pc van de administrators (client / server applicaties).

Een developer heeft ook geen of maar beperkte rechten op de productie db.
data updates verlopen via scripts die eerst getest werden op de test / dev omgeving, niet manueel.

[FrankHe]

Kom op zeg, zonder wachtwoord naar binnen kunnen lopen heeft niets te maken met hacken, in dat geval is het bijzonder slecht beveiligingswerk van de beheerders. Ook hebben de auditors in dat geval niet gedaan waarvoor ze duur worden betaald, namelijk deze problemen signaleren en de directie ermee om de oren slaan plus informatieplicht naar de raad van bestuur of in dit geval de verantwoordelijke ministers van binnenlandse zaken, financiën en sociale zaken. Voor dit soort dingen laat je periodiek een externe audit uitvoeren. We leven hier toch niet in een bananenrepubliek?

[Digihans]

Genant op z'n minst,
Had de overheid destijds niet een badinerend spotje op publieke omroep dat de burgers zelf beter voor hun eigen veiligheid op internet moesten zorgen.

drie keer kloppen, mwah....
Diginotoir is misbuikt en ge-defaced, PWC die alles tbv de overheid controleert en hun zegen geeft, en nu dit weer. Welke overheden hebben de afgelopen tijd hier hun certificaten betrokken? En welke toko heeft hier de controle gedaan? PWC?

Qua veiligheid en betrouwbaarheid lijkt me stemcomputers uit donkerafrika, of een narco-staat uit zuidamerika een goede suggestie.
En dan ont-stemmen!