Database storing legt gevoelige informatie bloot?

[Dannydekr]

Ik heb weinig verstand van hacken, hoewel ik wel weet dat het niet echt handig is als er fouten gegenereerd worden met usernames en passwords van databases?

Om jullie even te waarschuwen, dit was zojuist voor zo'n 40seconden zichtbaar:

Modbreak:

even config verwdijderd

[ Voor 84% gewijzigd door rob_erwt op 23-03-2012 10:18 ]

[S1W]

Jep... ik zag deze ook... lijkt me niet handig...
Snel accounts and PW's wijzigen jongens!

[ Voor 34% gewijzigd door S1W op 23-03-2012 10:15 ]

[significant]

doe ff sociaal en gooi die wachtwoorden even minimaal uit je post

Nu de nettere reactie: ik zou die wachtwoorden even uit je post verwijderen.

[ Voor 40% gewijzigd door significant op 23-03-2012 10:15 ]

[jvanhambelgium]

Yep, zag het net ook voorbij vliegen...

[Xan]

Same here.

Maar het lijkt me handig als je even de ww's uit je post haalt.

Dacht het ligt aan mij, maar gelukkig (nouja.. gelukkig) ben ik niet de enige die het ervaart.

edit: heerlijke redundantie.

[ Voor 10% gewijzigd door Xan op 23-03-2012 10:16 ]

[Mottebelke]

Ja, dat zag ik dus inderdaad ook. Was al bezig om wat screenshots te maken.
Als dit de echte login gegevens zijn, dan zou ik ze maar snel veranderen...

[Turbots]

Jep, ik heb het ook!

Edit: volgens mij zijn deze DBs waarschijnlijk toch niet van buitenaf toegankelijk, maar toch... Ergens een haakje vergeten sluiten of zo?

[ Voor 78% gewijzigd door Turbots op 23-03-2012 10:17 ]

[biglia]

Lol, when things go wrong...

[Wokkels]

Zucht, ik wilde dit in een DM zetten naar de crew, zodat niet iedereen op het forum deze info zou hebben. Maar blijkbaar heeft niet iedereen gezond verstand...

[S1W]

Wel sterke passwords, maar je moet ze natuurlijk niet zo online gooien

[Phoib]

Ik neem aan dat de wachtwoorden nu wel gewijzigd zijn... protip, niet de < voor de php tag deleten

[Keypunchie]

Het zal wel meevallen met het directe risico. Neem aan dat die users alleen vanaf lokale omgeving (app-servers) erbij mogen en niet vanaf het internet.

Dus je moet eerst nog door de perimeter en binnen het netwerk komen, als het goed is.

Goed om te zien dat er sterke wachtwoorden worden gebruikt!

[Dannydekr]

Denk dat iemand nu bij de redactie met rode oortjes en een zwetend voorhoofd als een gek de wachtwoorden aanpast. Het kost immers enkele seconden om met deze gegevens het gehele userbestand van Tweakers weg te roven?

[rob_erwt]

We zijn er mee bezig! Bedankt voor het melden. Wel even de config verwijderd...

[Turbots]

Wokkels schreef op vrijdag 23 maart 2012 @ 10:17:
Zucht, ik wilde dit in een DM zetten naar de crew, zodat niet iedereen op het forum deze info zou hebben. Maar blijkbaar heeft niet iedereen gezond verstand...

Hoe sneller er iets aan gedaan wordt, hoe minder kans eventuele hackers of kwaadwillige gebruikers hebben om daadwerkelijk iets buit te maken... De wachtwoorden hier in het lang en het breed uitsmeren zal de admins wel aanmoedigen om snel actie te ondernemen. Iedereen kon deze wachtwoorden trouwens zien, dus ze hier posten "verergerd" de situatie niet naar mijn mening...

[Orion84]

Dannydekr schreef op vrijdag 23 maart 2012 @ 10:18:
Denk dat iemand nu bij de redactie met rode oortjes en een zwetend voorhoofd als een gek de wachtwoorden aanpast. Het kost immers enkele seconden om met deze gegevens het gehele userbestand van Tweakers weg te roven?

Ik mag hopen dat de redactie toch echt geen rechten heeft om wachtwoorden in de PHP code aan te passen

Gelukkig zijn de devvers er mee bezig

Dit soort zaken kan je beter melden in Lieve Devvers waar ook al een paar topics geopend waren zo te zien.

[ Voor 11% gewijzigd door Orion84 op 23-03-2012 10:21 ]

[MoiZie]

Kreeg inderdaad dezelfde storing! Ook een e-mail gestuurd naar redactie at tweakers.

[Wokkels]

Turbots schreef op vrijdag 23 maart 2012 @ 10:19:
[...]

Hoe sneller er iets aan gedaan wordt, hoe minder kans eventuele hackers of kwaadwillige gebruikers hebben om daadwerkelijk iets buit te maken... De wachtwoorden hier in het lang en het breed uitsmeren zal de admins wel aanmoedigen om snel actie te ondernemen. Iedereen kon deze wachtwoorden trouwens zien, dus ze hier posten "verergerd" de situatie niet naar mijn mening...

En daarom zijn ze meteen weggemodbreakt?

[S1W]

Keypunchie schreef op vrijdag 23 maart 2012 @ 10:17:
Het zal wel meevallen met het directe risico. Neem aan dat die users alleen vanaf lokale omgeving (app-servers) erbij mogen en niet vanaf het internet.

Dus je moet eerst nog door de perimeter en binnen het netwerk komen, als het goed is.

Goed om te zien dat er sterke wachtwoorden worden gebruikt!

Ja, maar indirect is het risico natuurlijk wel aanwezig, leuke inkijk in de config van Tweakers...

[Rob]

Bijzonder dat het ontbreken van een < die info kan tonen. Meestal wordt die data in een config bestand buiten de www-mappen bewaard

[SinergyX]

Wokkels schreef op vrijdag 23 maart 2012 @ 10:17:
Zucht, ik wilde dit in een DM zetten naar de crew, zodat niet iedereen op het forum deze info zou hebben. Maar blijkbaar heeft niet iedereen gezond verstand...

* SinergyX leest frontpage over diverse 'lekken' die het nieuws komen.

Waarom zou T.net dan opeens 'sneaky achter de schermen' moeten werken? Als er door een bugje alsnog gevoelige gegevens op straat zijn gekomen (hoeft maar 1 bezoeker en een dump van te maken), waarom zou dat opeens heel geheimzinnig moeten gaan?

[Orion84]

Bij al die lekken die in het nieuws komen is de "lekke" partij meestal ook al via minder publieke weg op de hoogte gebracht, voordat de hacker/onderzoeker de publiciteit zoekt. Zo gek is dat dus helemaal niet

[Keypunchie]

@SinergyX

Het gaat niet om geheimzinnig. Het gaat om "responsible disclosure". Als je hebt gezien dat de buurman vergeten is zijn auto op slot te doen en er een dure GPS-unit achter de voorruit ligt, dan bel je toch even aan om hem dat te zeggen, dan ga je dat toch niet per megafoon vanuit jouw deuropening roepen?

Hetzelfde hier.

[Wokkels]

Keypunchie schreef op vrijdag 23 maart 2012 @ 10:26:
@SinergyX

Het gaat niet om geheimzinnig. Het gaat om "responsible disclosure". Als je hebt gezien dat de buurman vergeten is zijn auto op slot te doen en er een dure GPS-unit achter de voorruit ligt, dan bel je toch even aan om hem dat te zeggen, dan ga je dat toch niet per megafoon vanuit jouw deuropening roepen?

Hetzelfde hier.

Inderdaad. Het heeft weinig zin om het op die manier openbaar te maken, brengt alleen maar meer 'risico' met zich mee.
Buiten dat zijn het ook je eigen gegevens die mogelijkerwijs at risk zijn, dus is het ook eigenbelang

[Wilbert de Vries]

We komen later vandaag met wat meer gegevens, maar kortstondig is een configfile zichtbaar geweest. Met deze gegevens hadden kwaadwillenden geen toegang kunnen krijgen: de wachtwoorden zijn niet van buitenaf bruikbaar in verband met beveiligingsmaatregelen.

[wildhagen]

Hoe zit het met gebruikers waarvan de wachtwoorden nu op straat gekomen zijn? Worden die geforceerd om een nieuw wachtwoord te genereren?

[Hooglander1]

Waar haal jij vandaan dat er wachtwoorden van gebruikers op straat gekomen zijn? Wilbert zegt net dat dat niet kon gebeuren.

[moorscode]

Enige wat mis is is dat de PHP-open tag niet met een < begint. Typo lijkt me.

[kenneth]

wildhagen schreef op vrijdag 23 maart 2012 @ 10:33:
Hoe zit het met gebruikers waarvan de wachtwoorden nu op straat gekomen zijn? Worden die geforceerd om een nieuw wachtwoord te genereren?

Het waren wachtwoorden van systeemaccounts.

[MuddyMagical]

moorscode schreef op vrijdag 23 maart 2012 @ 10:34:
Enige wat mis is is dat de PHP-open tag niet met een < begint. Typo lijkt me.

Ja inderdaad. Meer is het niet geweest lijkt me. Wel weer iemand die voor het komende decenium koffie mag halen en bier dragen op de MOAM

[wildhagen]

Hooglander1 schreef op vrijdag 23 maart 2012 @ 10:34:
Waar haal jij vandaan dat er wachtwoorden van gebruikers op straat gekomen zijn? Wilbert zegt net dat dat niet kon gebeuren.

Ja, binnen een paar seconden van mijn post. Hoe moet ik dat dan zien? Die reactie zie ik dan ook pas als de mijne geplaatst is he...

Maargoed, dat is dus ook weer opgehelderd

[Mr. Awesome]

Dannydekr schreef op vrijdag 23 maart 2012 @ 10:18:
Denk dat iemand nu bij de redactie met rode oortjes en een zwetend voorhoofd als een gek de wachtwoorden aanpast. Het kost immers enkele seconden om met deze gegevens het gehele userbestand van Tweakers weg te roven?

Jij bent zeker ook nog zo iemand die denkt dat de monitor de PC is? Redactie != Devvers

[Keypunchie]

oe zit het met gebruikers waarvan de wachtwoorden nu op straat gekomen zijn?

De gebruikers waren zgn. "databasegebruikers", oftewel de accounts waarmee regels uit een database worden ingeladen (zie het als systeemaccounts).

Die accounts zijn doorgaans gebonden aan servers waarvandaan mag worden verbonden. Precies om bij uitlekken tegen te gaan dat de hele wereld plotseling root-rechten op de database heeft.

"Defense in-depth" heet dat. Je moet er van uitgaan dat een enkele beveiliging wel eens omzeilt kan worden en daarom een volgende laag hebben om in zo'n geval de aanvaller alsnog te beperken in de schade die hij kan aanrichten.

[MuddyMagical]

Dannydekr schreef op vrijdag 23 maart 2012 @ 10:18:
Denk dat iemand nu bij de redactie met rode oortjes en een zwetend voorhoofd als een gek de wachtwoorden aanpast. Het kost immers enkele seconden om met deze gegevens het gehele userbestand van Tweakers weg te roven?

In je DB server aangeven dat access alleen van bepaalde IP adressen mag komen (je webservers) en klaar. Dan kan je hier weinig mee.

[KirovAir]

Wel interessant om eens mee te kunnen kijken in de tweakers DB config.php.

Keypunchie schreef op vrijdag 23 maart 2012 @ 10:38:
[...]


De gebruikers waren zgn. "databasegebruikers", oftewel de accounts waarmee regels uit een database worden ingeladen (zie het als systeemaccounts).

Die accounts zijn doorgaans gebonden aan servers waarvandaan mag worden verbonden. Precies om bij uitlekken tegen te gaan dat de hele wereld plotseling root-rechten op de database heeft.

"Defense in-depth" heet dat. Je moet er van uitgaan dat een enkele beveiliging wel eens omzeilt kan worden en daarom een volgende laag hebben om in zo'n geval de aanvaller alsnog te beperken in de schade die hij kan aanrichten.

Hier maken wij ook gebruik van op het werk. Geen 'groot' beveiligingsrisico geweest dus.

[Dannydekr]

hyptonize schreef op vrijdag 23 maart 2012 @ 10:37:
[...]

Jij bent zeker ook nog zo iemand die denkt dat de monitor de PC is? Redactie != Devvers

Heb zo snel mogelijk een post aangemaakt zonder mezelf druk te maken over de juiste banming van de verantwoordelijken

[rob_erwt]

Ik verplaats dit topic naar Lieve Devvers zodat dit het centrale topic kan worden voor communicatie hierover. Redactie zal heir idd weinig aan kunnen oplossen.

[rob_erwt]

wildhagen schreef op vrijdag 23 maart 2012 @ 10:33:
Hoe zit het met gebruikers waarvan de wachtwoorden nu op straat gekomen zijn? Worden die geforceerd om een nieuw wachtwoord te genereren?

Hoewel de wachtwoorden bekend waren, waren ze door andere beveilingsmaatregelen nog steeds niet te gebruiken: onze databases zijn niet direct vanaf internet te bereiken.

Wachtwoorden van gebruikers zijn dus sowieso niet op straat komen te liggen. En ook zijn de gegevens die zichtbaar waren al weer aangepast en niet meer geldig.

Later vandaag zullen we, zoals jullie van ons gewend zijn, met meer informatie komen in een .plan.

[curry684]

Rob schreef op vrijdag 23 maart 2012 @ 10:23:
Bijzonder dat het ontbreken van een < die info kan tonen. Meestal wordt die data in een config bestand buiten de www-mappen bewaard

Dat maakt 'm niet minder zichtbaar op het moment dat ie geinclude wordt.

[wimpie007]

Als ze niet vanaf buiten te gebruiker waren is er toch niks aan de hand?

[ Voor 174% gewijzigd door wimpie007 op 23-03-2012 11:08 ]

[Kees]

wimpie007 schreef op vrijdag 23 maart 2012 @ 11:07:
Als ze niet vanaf buiten te gebruiker waren is er toch niks aan de hand?

Nee, maar dan is het alsnog niet heel erg netjes

[MoiZie]

wimpie007 schreef op vrijdag 23 maart 2012 @ 11:07:
Als ze niet vanaf buiten te gebruiker waren is er toch niks aan de hand?

Dus wil je niets veranderen? Dan weet iedereen je wachtwoorden en heb je alleen nog maar de buitenste laag te kraken om helemaal binnen te komen...

[ Voor 38% gewijzigd door MoiZie op 23-03-2012 11:14 ]

[Verwijderd]

MoiZie schreef op vrijdag 23 maart 2012 @ 11:12:
Dus wil je niets veranderen? Dan weet iedereen je wachtwoorden en heb je alleen nog maar de buitenste laag te kraken om helemaal binnen te komen...

Ze zijn uiteraard weldegelijk aangepast ....

[Kees]

MoiZie schreef op vrijdag 23 maart 2012 @ 11:12:
[...]

Dus wil je niets veranderen? Dan weet iedereen je wachtwoorden en heb je alleen nog maar de buitenste laag te kraken om helemaal binnen te komen...

Uiteraard zijn ze wel aangepast, zowel het wachtwoord als de accountnaam.

[rob_erwt]

En zoals beloofd de .plan update: plan: Server- & netwerkstatusmeldingen XII

[Rob]

rob_erwt schreef op vrijdag 23 maart 2012 @ 11:18:
En zoals beloofd de .plan update: plan: Server- & netwerkstatusmeldingen XII

tikfoutje: twiter

[rob_erwt]

Rob schreef op vrijdag 23 maart 2012 @ 11:23:
[...]


tikfoutje: twiter

Euhm ja, nu niet meer in ieder geval.

[MoiZie]

Verwijderd schreef op vrijdag 23 maart 2012 @ 11:13:
[...]

Ze zijn uiteraard weldegelijk aangepast ....

Kees schreef op vrijdag 23 maart 2012 @ 11:15:
[...]

Uiteraard zijn ze wel aangepast, zowel het wachtwoord als de accountnaam.

Een reactie op wimpie007 .

[regmaster]

Beetje vreemde reactie om wachtwoorden, die gewoon voor een ieder te vinden zijn op Pastebin, te laten verwijderen als er inderdaad niets mee valt aan te vangen. Als dit van een andere website zou zijn geweest dan was het breed uitgemeten op Frontpage. Maar goed, een algemene mea culpa op Frontpage is wel welkom want het is en blijft een domme fout (zeker als je iets dergelijks van andere sites publiceert op de T-Net Frontpage).

[matthiastuut]

@remaster

Lijkt mij niet meer dan logisch om deze wachtwoorden af te schermen op je eigen website.
Daarnaast zijn de berichten welke op Frontpage terecht komen structureel gemaakte fouten die niet komen door het vergeten van < welke binnen 2 minuten aangepast was. Daarnaast was de beveiliging van T-net zodanig goed dat er niks met de gegevens gedaan zou kunnen worden in deze korte tijdsperiode.

De inloggegevens etc blijft gewoon informatie die niet zo handig is om overal te hebben en dan vooral niet op je eigen site.

Ik vind de fout menselijk en gewoon goed opgelost van de devvers

[Olaf van der Spek]

Kees schreef op vrijdag 23 maart 2012 @ 11:15:
Uiteraard zijn ze wel aangepast, zowel het wachtwoord als de accountnaam.

Waarom staan die wachtwoorden uberhaupt in de doc root?

Daarnaast zijn de berichten welke op Frontpage terecht komen structureel gemaakte fouten die niet komen door het vergeten van < welke binnen 2 minuten aangepast was.

Dit is echt niet de eerste keer dan PHP source zichtbaar is hoor.

[ Voor 34% gewijzigd door Olaf van der Spek op 24-03-2012 18:35 ]

[AW_Bos]

Olaf van der Spek schreef op zaterdag 24 maart 2012 @ 18:33:
[...]

Waarom staan die wachtwoorden uberhaupt in de doc root?


[...]

Dit is echt niet de eerste keer dan PHP source zichtbaar is hoor.

Ik heb wel ooit eens wat Zend Encoded source gezien, waar React/HenkBoard mee gecompileerd is. Maar op t.net nog nooit eerder PHP-code?

Op Fok werd de index.php wel eens een keer blootgelegd, maar dat was niet zo boeiend, gezien al het belangrijkste buiten de webroot stond.

[afraca]

Ik was eigenlijk nog wel benieuwd naar het code fragmentje, niet zozeer vanwege de accounts, maar meer vanwege het afleiden van de architectuur en de gebruikte syntax. De code heeft nu toch al op straat gelegen, kunnen jullie niet even die accountgegevens eruit halen en een snippet hier neer zetten?

[ Voor 3% gewijzigd door afraca op 24-03-2012 22:48 . Reden: spatiegebruik.nl ]

[_David_]

afraca schreef op zaterdag 24 maart 2012 @ 22:47:
Ik was eigenlijk nog wel benieuwd naar het code fragmentje, niet zozeer vanwege de accounts, maar meer vanwege het afleiden van de architectuur en de gebruikte syntax. De code heeft nu toch al op straat gelegen, kunnen jullie niet even die accountgegevens eruit halen en een snippet hier neer zetten?

zoek op pastebin.com naar tweakers

[CyBeR]

Euh, ik heb 't zelf niet gezien maar ik stel me het volgende ongeveer voor:

PHP:

?php

$db_server="192.168.1.1"
$db_user="uberroot"
$db_pass="keesmaghetfixen"
?>

M.a.w., geen 'architectuur' uit af te leiden en waar die file staat maakt allemaal geen donder uit: als je 'm include en die start tag ('<?php') was niet goed, dan wordt 'ie plaintext naar de browser gestuurd en aangezien de variables erin vervolgens niet gezet worden is er (bijvoorbeeld) geen db connectie en komt er dus verder ook weinig tevoorschijn.


Even de pastebin erbij gepakt en inderdaad, precies wat ik zei. Alleen dan in een $config array. En eronder de source van de webpagina die gegenereerd wordt nadat er geen configuratie was.

[ Voor 15% gewijzigd door CyBeR op 25-03-2012 00:30 ]

[afraca]

De pastebin paste was wel iets interessanter dan jouw snippet CyBeR, postfix voor mail bijvoorbeeld deed mij een lichte "hmm" ontsnappen, en de gezette timeout een "hm, ok"

Maar inderdaad niet heel spannend, kan crisp niet even wat dependency graphs genereren en posten

[ Voor 24% gewijzigd door afraca op 24-03-2012 23:24 ]

[CyBeR]

Postfix is gewoon de default MTA van Ubuntu, wat ze bij t.net tegenwoordig gebruiken. En die timeout is in milliseconden.

Nog altijd niets spannends dus

[crisp]

Olaf van der Spek schreef op zaterdag 24 maart 2012 @ 18:33:
[...]

Waarom staan die wachtwoorden uberhaupt in de doc root?

Dat staan ze niet, maar dat maakt voor een require() weinig uit

Maar de configReader is al zodanig aangepast dat hij nu checked of een config file geen output genereert.

[ Voor 17% gewijzigd door crisp op 25-03-2012 00:24 ]

[afraca]

CyBeR schreef op zaterdag 24 maart 2012 @ 23:27:
Postfix is gewoon de default MTA van Ubuntu, wat ze bij t.net tegenwoordig gebruiken. En die timeout is in milliseconden.

Nog altijd niets spannends dus

offtopic:
True, de hmms waren dat misschien zelfs nog overdreven.

[ Voor 12% gewijzigd door afraca op 25-03-2012 16:41 ]