Honderden passwords plaintext

[Asitis]

Nou, ik doe net toch een ontdekking waarvan ik niet precies weet wat ik er mee moet. Ik ben in het proces een heel nieuw systeem te ontwikkelingen voor een klant van ons, en in dat proces zitten heel wat geautomatiseerd import/export van XML bestanden.

Nou tref ik in dat proces net ook een XML bestand aan met daarin alle klantgegevens van hun klanten, inclusief adresgegevens en wachtwoorden, plaintext op een publiek te bereiken URL.
Nu weet ik dat het mijn klant zal verbazen, die houdt zich niet bezig met de techniek, daar zijn wij voor. Dit bestaande systeem hebben wij echter niet gemaakt en is zo opgezet door andere (externe) partijen die daar nu deels nog steeds voor verantwoordelijk zijn.

Ik weet dat de klant de betreffende partij die deze XML zo publiekelijk heeft geplaatst nog wel in beeld is.
Wat ik ga doen is contact opnemen met de vorige ontwikkelaar en de verantwoordelijke hiervoor, maar een wijziging in deze hele datastroom zal aardig wat extra ontwikkeltijd in beslag nemen, en ik weet dat de klant daar absoluut niet op zit te wachten.

Ik leg het aan jullie voor, omdat ik benieuwd ben wat jullie er van denken, adviseren of ooit zoiets hebben meegemaakt!

[Craven]

Ik zou het neerleggen bij de klant, via een schriftelijke methode, dat dit zo dus op de straat ligt. Het is aan de klant om te beslissen wat ze daarmee doen. Zij zijn opdrachtgever richting de andere leverancier die dit gebouwd heeft.

Overigens zou ik dit wel ff met je manager bespreken of accountmanager van deze klant. Als techneut iets als dit direct richting een klant communiceren word je niet altijd in dank afgenomen.

[Orion84]

Aannemende dat je voor een werkgever werkt en niet als ZZP'er aan de slag bent:
- meld het (eerst) aan je eigen leidinggevende en check met hem/haar hoe dit te melden aan de klant

Hoe zitten verder de relaties met die partij die de oude oplossing gemaakt heeft en beheert in elkaar loopt dat via jullie of via de klant? In dat laatste geval weet ik niet of het handig is om op eigen houtje naar die andere leverancier te gaan. Dat kan je dan wellicht beter via de klant laten lopen.

edit: wat Craven zegt dus

[ Voor 3% gewijzigd door Orion84 op 08-08-2016 15:21 ]

[F_J_K]

Craven schreef op maandag 08 augustus 2016 @ 15:20:
Ik zou het neerleggen bij de klant, via een schriftelijke methode, dat dit zo dus op de straat ligt. Het is aan de klant om te beslissen wat ze daarmee doen. Zij zijn opdrachtgever richting de andere leverancier die dit gebouwd heeft.

Overigens zou ik dit wel ff met je manager bespreken of accountmanager van deze klant. Als techneut iets als dit direct richting een klant communiceren word je niet altijd in dank afgenomen.

Inderdaad - het beste om het tenminste initieel netjes via de lijntjes te doen. (Behalve als een van de lijntjes 'negeer maar' roept...)

Maar: het is NIET aan de klant om te beslissen wat ze daarmee doen. De klant is als verantwoordelijke wettelijk verplicht om het lek te melden. https://autoriteitpersoon...den/meldplicht-datalekken

Is er een log dat kan aantonen dat het bestand nul keer is opgevraagd door onbevoegden? Anders bestaat de kans dat de klant het lek ook moet melden aan iedere persoon wiens gegevens in de XML-file staan. Maar dat kan de klant met de Autoriteit persoonsgegevens bespreken na de melding.

[Baserk]

Ik zou toch ook je eigen leidinggevende even aan de mouw trekken, overleggen wat dit -de plaintext pw's in XML- betekent voor jou/jullie aan werkzaamheden en meerwerk.
Dan contact opnemen met de klant en de onderbouwde uitleg geven en jouw klant zelf laten bepalen wie contact opneemt met de 3e partij.

Edit; En, zoals FJK terecht stelt, wijs de klant op z'n wettelijke verplichting en wat daaruit voortvloeit.

[ Voor 15% gewijzigd door Baserk op 08-08-2016 15:29 ]

[GerardVanAfoort]

Dat de klant niet op die ontwikkeltijd zit te wachten is begrijpelijk. Maar belangrijker de klant zal zeker niet willen dat dit op zijn bedrijf van toepassing wordt: https://autoriteitpersoon...den/meldplicht-datalekken

[F_J_K]

Overigens ook goed om het gat per direct provisorisch te dichten: laat de webserver het bestand blokkeren voor iedereen behalve het ene IP-adres dat toegang nodig heeft (en stel daar per direct bijv HTTPS verplicht!), of verwijder het bestand "fysiek". (Nou ja: adviseer de klant dat te doen).

[Asitis]

Ik werk bij een klein bedrijf dus ik heb wel zelf direct contact met de klant. Heb zowel de leverancier als de vorige ontwikkelaar proberen te bereiken, maar die zijn beide met vakantie.

Het bestand is dus vrij op te roepen en daar is geen verdere info over hoe vaak het al ingezien is. Ik kan uit de data erin wel afleiden dat het al zo'n anderhalf jaar online staat en dus gradueel is aangevuld met nieuwe gegevens.

Zojuist ook met m'n baas overlegt, die zegt inderdaad ook dat we het maar bekend maken bij de klant en dat de verantwoordelijkheid uiteindelijk bij hun ligt, om iets met de leverancier te doen.

Het zou natuurlijk nog verschil maken als alle wachtwoorden die daar in staan gegenereerd zijn door het systeem (dus zeer wss niet van toepassing op andere accounts), en als de gebruiker bij eerste keer inloggen verplicht wordt om het wachtwoord te wijzigen, maar dat weet ik niet zeker (ik geloof het niet).

[gitaarwerk]

GerardVanAfoort schreef op maandag 08 augustus 2016 @ 15:26:
Dat de klant niet op die ontwikkeltijd zit te wachten is begrijpelijk. Maar belangrijker de klant zal zeker niet willen dat dit op zijn bedrijf van toepassing wordt: https://autoriteitpersoon...den/meldplicht-datalekken

Volgens mij kan dit best van toepassing dus nu al zijn.
quote:

Melden datalek niet nodig
U mag de melding aan de betrokkenen eventueel achterwege laten als u passende technische beschermingsmaatregelen heeft getroffen, waardoor de gelekte persoonsgegevens onbegrijpelijk of ontoegankelijk zijn voor onbevoegden. Bijvoorbeeld goede encryptie.

In dit geval is dit niet van toepassing. Access logs kunnen bekeken inderdaad worden. De vraag is hoe lang ze bewaard worden. 1,5 jaar online, weet ik niet of je dit nog kan verifieren.


De klant kan dit vast verhalen op de originele ontwikkelaar.

Als jullie invloed hebben op dat proces, zou je, de klant in overleg kunnen besluiten deze offline te halen al, of inderdaad door F_J_K als suggestie gaf.

[ Voor 31% gewijzigd door gitaarwerk op 08-08-2016 15:41 ]

[HyperioN]

Asitis schreef op maandag 08 augustus 2016 @ 15:30:
Ik werk bij een klein bedrijf dus ik heb wel zelf direct contact met de klant. Heb zowel de leverancier als de vorige ontwikkelaar proberen te bereiken, maar die zijn beide met vakantie.

Het bestand is dus vrij op te roepen en daar is geen verdere info over hoe vaak het al ingezien is. Ik kan uit de data erin wel afleiden dat het al zo'n anderhalf jaar online staat en dus gradueel is aangevuld met nieuwe gegevens.

Vrijwel alle webservers, of het nu Apache, nginx, IIS of heel wat anders is, doen aan access-logging. Daarin zou het opzoeken van requests naar die specifieke file niet heel moeilijk moeten zijn.
Tenzij het bewust uitgezet is (of dusdanig slecht geconfigureerd dat het niet werkt).
Je hebt vaak wel te maken met log rotation, dus gegevens van anderhalf jaar geleden zijn waarschijnlijk niet gemakkelijk meer terug te halen.

Zojuist ook met m'n baas overlegt, die zegt inderdaad ook dat we het maar bekend maken bij de klant en dat de verantwoordelijkheid uiteindelijk bij hun ligt, om iets met de leverancier te doen.

Het zou natuurlijk nog verschil maken als alle wachtwoorden die daar in staan gegenereerd zijn door het systeem (dus zeer wss niet van toepassing op andere accounts), en als de gebruiker bij eerste keer inloggen verplicht wordt om het wachtwoord te wijzigen, maar dat weet ik niet zeker (ik geloof het niet).

Ja en nee. De adresgegevens zijn al erg genoeg, dat zijn ook persoonsgegevens die afgeschermd dienen te worden. Dat daar ook nog eens plaintext wachtwoorden bij staan, maakt het alleen nog een tikje erger.

[Asitis]

Ik zie dat (in ieder geval deels) onze klant zelf die gebruikers aanmaakt in een CRM systeem, en zelf wachtwoorden verzint die vervolgens gepushed worden naar de XML. Dat maakt het geloof ik al wat minder ernstig, maar ik kan nooit met zekerheid zeggen dat 100% van de wachtwoorden 'uniek' zijn.

[the-spawn]

Asitis schreef op maandag 08 augustus 2016 @ 15:36:
Ik zie dat (in ieder geval deels) onze klant zelf die gebruikers aanmaakt in een CRM systeem, en zelf wachtwoorden verzint die vervolgens gepushed worden naar de XML. Dat maakt het geloof ik al wat minder ernstig, maar ik kan nooit met zekerheid zeggen dat 100% van de wachtwoorden 'uniek' zijn.

Het gaat niet zo zeer om de wachtwoorden, het gaat juist om de namen en adresgegevens, dit zijn persoonsgegevens en deze zijn vertrouwelijk en vanuit de wet dienen deze deugdelijk beveiligd te zijn. Dat zijn ze niet als je ze zo van het internet kan plukken.
Daar dien je de verantwoordelijke over te informeren en zij dienen een melding te maken bij de Autoriteit (tenzij ze uit kunnen sluiten dat het bestand door andere geraadpleegd/gedownload is zoals HyperioN zegt) en natuurlijk actie te ondernemen om verdere verspreiding te voorkomen door dergelijke informatie goed beveiligd op te slaan.

Laat je klant zo snel als mogelijk maatregelen treffen, minimaal het bestand afschermen voor het gehele internet zodat het niet meer te downloaden is.

[ Voor 5% gewijzigd door the-spawn op 08-08-2016 15:45 . Reden: aanvulling op actie ]

[adminappelgebak]

Inderdaad, wat iedereen hier al zegt. Zorg dat per direct er een provisorische oplossing komt. Zo kan je de klant ook laten zien dat jullie met hun meedenken en dat hun beveiliging belangrijk is voor jullie. Een provisorische oplossing is niet veel werk lijkt mij (alle IP Adressen blokkeren van toegang daarheen op het server IP na die toegang nodig heeft). Daarna kan in overleg met de klant besproken worden hoe of wat daarna.

Belangrijkste is dat er nog geen lekken hebben plaatsgevonden, want zo ja dan heeft de klant echt een groot probleem! Dus controleer dat per direct.

[F_J_K]

Asitis schreef op maandag 08 augustus 2016 @ 15:36:
Ik zie dat (in ieder geval deels) onze klant zelf die gebruikers aanmaakt in een CRM systeem, en zelf wachtwoorden verzint die vervolgens gepushed worden naar de XML. Dat maakt het geloof ik al wat minder ernstig, maar ik kan nooit met zekerheid zeggen dat 100% van de wachtwoorden 'uniek' zijn.

Maak je daar nu niet druk om, voor nu niet relevant. Eerst zorgen dat de klant de voordeur dicht zet, dan pas kijken of slechts de reclame van de deurmat is gejat, of dat het hele huis is leeggeroofd
En zoals gezegd, na zorgen dat de voordeur dicht is, is er de verplichting het te melden. Doe het niet en de boete kan oplopen tot als ik het goed heb €8 ton of 10% van de jaaromzet.

En inderdaad dubbelchecken of er geen logs zijn en die dan veiligstellen. (Voor zover dat zin heeft; als de oude logs worden verwijderd dan is er simpelweg geen bewijs dat de file niet is 'gejat').

Edit: mocht de ontwikkelaar andere klanten hebben dan zou je die ook willen benaderen als de leverancier nu niet thuis geeft. Voordeeltje voor jouw bedrijf is dat je die andere klanten dan uurtje-factuurtje kan helpen de deur dicht te doen

[ Voor 10% gewijzigd door F_J_K op 08-08-2016 16:01 ]

[Asitis]

Ik heb ondertussen contact gehad met degene die het bestand op z'n server publiekelijk had staan en die is begrijpelijk wel geschrokken. Hij meende dat het bestand wel beveiligd zou moeten zijn en ik heb ondertussen de logs sinds januari 2015 ontvangen, daar kunnen we iig een mogelijk lek in ontdekken of juist uitsluiten.

Hij is nu ook nog aan het kijken of het bestand ooit wel versleuteld is geweest en sinds wanneer dat niet meer zou zijn.

Die verplichting om te melden, wij hebben dat natuurlijk richting onze klant, maar in hoeverre is onze klant ook verplicht alle gebruikers op de hoogte te stellen (zolang het nog niet duidelijk is of het gelekt is, of het misschien niet gelekt blijkt te zijn)? edit: nvm, kan ik natuurlijk zelf vinden op de site

[ Voor 12% gewijzigd door Asitis op 08-08-2016 16:15 ]

[F_J_K]

Asitis schreef op maandag 08 augustus 2016 @ 16:12:
maar in hoeverre is onze klant ook verplicht alle gebruikers op de hoogte te stellen (zolang het nog niet duidelijk is of het gelekt is, of het misschien niet gelekt blijkt te zijn)? edit: nvm, kan ik natuurlijk zelf vinden op de site

FWIW: dat hangt dus af van de precieze gegevens (bijv. of het een eenmalig door hen gegenereerd password is, dat niet is gebruikt anders dan om een password-reset te doen) en van de conclusies uit het logfile. Hopelijk toont het log aan dat niemand het bestand heeft gedownload behalve de klant zelf, evt. andere systemen die het bestand horen te gebruiken, en jij - die dan wel even wil verklaren richting klant dat je de data hebt weggeknikkerd etc. en niet hebt gebruikt anders dan om het lek te ontdekken danwel voor je reguliere werkzaamheden (als bewerker) voor hen.

[Asitis]

Yes Ik heb alle gegevens, ga nu direct alles offline halen en heb zojuist de klant op de hoogte gesteld van het lek en de vervolgstappen. Zoals ik het nu begrijp is het afhankelijk van de gegevens in het log of er nog iets mee moet gebeuren qua melden.

Bedankt voor alle info!

Edit: Gewoon voor de volledigheid, het lijkt erop dat de files wél beveiligd zouden moeten zijn via een htaccess Deny from All, maar dat iemand de punt voor de bestandsnaam is vergeten..

Bonusvraag; is zo'n Deny from All in de root van deze server een veilig genoeg voor dit soort zaken?

[ Voor 34% gewijzigd door Asitis op 08-08-2016 16:40 ]

[F_J_K]

Asitis schreef op maandag 08 augustus 2016 @ 16:27:
Yes Ik heb alle gegevens, ga nu direct alles offline halen en heb zojuist de klant op de hoogte gesteld van het lek en de vervolgstappen. Zoals ik het nu begrijp is het afhankelijk van de gegevens in het log of er nog iets mee moet gebeuren qua melden.

Ik neem aan dat je doelt op het melden aan de mailadressen in het bestand, niet aan de AP

En de . in .htaccess is wel relevant ja

In principe moet het voldoende zijn. (Anderen: schiet ajb als ik dat verkeerd zie). Maar dit foutje laat zien dat er dingen verkeerd kunnen gaan, de volgende keer wordt het per ongeluk weggecommentarieerd, wordt de volgorde omgedraaid, oid. Als een deny from all kan, dan kan het bestand ook gewoon niet in de DocumentRoot zetten misschien verstandiger..

[HyperioN]

Asitis schreef op maandag 08 augustus 2016 @ 16:27:
Bonusvraag; is zo'n Deny from All in de root van deze server een veilig genoeg voor dit soort zaken?

Op zich wel; maar je kunt je afvragen waarom zo'n file überhaupt in (een subdirectory van) de docroot staat van een publiekelijk benaderbare webserver.

Nu wordt de punt vergeten in de htaccess-filename.. de volgende keer wordt de file per ongeluk gekopieerd of wordt besloten om de website op nginx te gaan draaien in plaats van Apache; waardoor het htaccess-directive niet meer gelezen wordt. Zijn slechts voorbeelden; maar een foutje zit in een klein hoekje.

Zo'n file hoor je in een aparte directory te zetten buiten de docroot om; die dus niet geserveerd wordt door de webserver. Ook als de file uitgelezen/gebruikt wordt door een webapplicatie, kan dat prima.
Dan nog kan er door menselijke fouten een breach ontstaan; maar je maakt de kans al kleiner.

Hoe gaat dat "pushen" van de file door het CRM-systeem naar de server trouwens? Kan goed dat hier bijv. plain FTP gebruikt wordt. Ook dat is niet echt veilig te noemen ;-)

[Asitis]

Nu wordt de punt vergeten in de htaccess-filename.. de volgende keer wordt de file per ongeluk gekopieerd of wordt besloten om de website op nginx te gaan draaien in plaats van Apache; waardoor het htaccess-directive niet meer gelezen wordt. Zijn slechts voorbeelden; maar een foutje zit in een klein hoekje.

En eerlijk gebied te zeggen dat de beheerder van deze server niet persé echt ervaren is in dit vak (zijn eigen woorden), dus dat moeten we dan wel ff goed oplossen ja.

Hoe gaat dat "pushen" van de file door het CRM-systeem naar de server trouwens? Kan goed dat hier bijv. plain FTP gebruikt wordt. Ook dat is niet echt veilig te noemen ;-)

Daar moet ik nog achter komen, zoals ik al zei heb ik deze situatie zo niet geconfigureerd (dan had ik er anderhalf jaar geleden wel bij stilgestaan ), het gebeurd wel automatisch, maar ik heb totaal geen zicht op het gebruikte systeem noch de techniek daarachter. Al wel eens vaker naar gevraagd maar da's "allemaal moeilijk" ofzo, nog nooit een helder antwoord op gekregen..