Gegevens 800.000 personen lekken uit na hack bij Proserve
Bij een hack van een server van internetbedrijf Proserve zouden databases met gegevens van in totaal 800.000 mensen op straat zijn komen te liggen. Het zou gaan om databases van onder andere Q-Music en een groot aantal webshops.
Een hacker met de alias Trixy ontdekte dat het kinderlijk eenvoudig was om als beheerder in te loggen bij een server van Proserve. Het bleek te gaan om een systeem voor het herstel van databases, dat eerder was binnengedrongen door hackers, die daarbij met een enkel commando alle databases wisten binnen te halen. Ook een andere server, die Proserve gebruikte om systemen in te richten en die niet via het internet verbonden had mogen zijn, bleek kwetsbaar. In maart kwam naar buiten dat inloggegevens van Proserve-hostingklanten waren gestolen via een ernstig lek in serverbeheertool Plesk, maar niet bekend is of die hacks verband houden met de nieuwe bevindingen.
Volgens Nu.nl, dat door Trixy van de hack op de hoogte werd gebracht, zijn onder andere gegevens van accounts van Q-Music, Stedin, het KrantCafé van Telegraaf Media Groep en verschillende webwinkels, zoals Pleinshoppen, Internetbikes en Brekelmans Modelbouw ontvreemd. Ook BabyDump zou tussen de bedrijven zitten waarvan de database gestolen is. Dat bedrijf had eerder dit jaar te maken met een datalek, waarbij onterecht gedacht werd dat de klantgegevens van een hack bij KPN-systemen afkomstig waren.
Proserve heeft de gekraakte systemen vervangen, de politie ingeschakeld en een beveiligingsbedrijf in de arm genomen om herhaling te voorkomen.
Reacties (51)
Telegraaf Media Groep? Houd dat ook in dat Hyves die hier ook onder valt is gehacked?
Volgens het nieuwsbericht betreft het alleen "het krantcafé", wat denk ik een afzonderlijk product is.
krantcafe is website voor vervoerders, depothouders en bezorgers die werken voor TMg
hyves draaide in elk geval vóór telegraaf ze overnam hun eigen servers. lijkt me sterk dat dat na telegraaf ineens niet meer zo zou zijn gezien de load die ze te verwerken krijgen en gespecialiseerde oplossingen die ze bedacht hadden.
Correct, Hyves heeft in Gyrocenter Amsterdam een complete datavloer 
Dat staat dus compleet los van dit verhaal.
Dat staat dus compleet los van dit verhaal.Ik voel een enorm gat in de markt aankomen, ICT beveiliging lijkt "hotter than ever"!
dat gat komt er niet die is er al 
@proxx, @hashtag
Dat is dan gezien een gemiddelde week frontpage op tweakers nog een behoorlijk leeg gat op dit moment. Ik zou als hacker wel weten wat mijn volgende carrière move zou zijn!
Dat is dan gezien een gemiddelde week frontpage op tweakers nog een behoorlijk leeg gat op dit moment. Ik zou als hacker wel weten wat mijn volgende carrière move zou zijn!
[Reactie gewijzigd door ScoeS op woensdag 18 juli 2012 16:50]
De gemiddelde beheerder denkt vaak 'dat overkomt mij niet'. Echt, geloof me.
Dus een hoop zaken zijn laksheid, maar kan soms ook met bedrijfsvoering te maken hebben. Oftewel, prioriteiten stellen.
Dus een hoop zaken zijn laksheid, maar kan soms ook met bedrijfsvoering te maken hebben. Oftewel, prioriteiten stellen.
Ik krijg bijv. gewoon niet het geld en de tijd om alles te doen zoals ik het zou willen. (hoewel het dan vast ook nog te hacken is dmv een zero day oid 
)
)Als webmaster/systeembeheerder kan je je niet beschermen tegen 0days in gebruikte software van derde partijen en virusscanners halen ze er ook niet uit, zelfs niet met fancy heuristiek, dat helpt zelfs niet tegen 3 jaar oude java lekken. Ook al worden 0days eigenlijk alleen gebruikt tegen kritieke infrastructuur zoals defensiebedrijven, energieleveranciers, overheden, etc.
Een hacker heeft maar 1 klein gaatje nodig om al in het systeem binnen te komen of om de databank leeg te trekken. Maar het makkelijkste wat vaak genegeerd wordt is het updaten van de software en genoeg webwinkels met het thuiswinkel waarborg/keurmerk en andere bedrijven/organisaties draaien verouderde software, kijk maar de openbare http headers, daar wordt vaak genoeg informatie in mee gestuurd om een boekdeel over te schrijven.
Frameworks als Metasploit zijn gewoon openbaar en door iedere halve zool te gebruiken om een website met openbare exploits open te krikken.
Ondanks de genoeg bedrijven die een flinke schuivert maken en gehackt in de media komen denken bedrijven als nog niet dat ze wat aan hun beveiliging moeten doen. 'Een applicatie werkt toch dan is er verder niks aan de hand'. Natuurlijk spelen ook de kosten mee, 100% veilig kan je een website, infrastructuur, etc niet maken, maar 80% van de hacks zijn simpel en dus ook zo te voorkomen en de preventieve kosten zijn bijna altijd lager dan kosten van een hack.
Het zijn besluiten van het management samen met gebrek aan kennis van de uitvoerders (beheerders + programmeurs) die er voor zorgen dat de beveiliging keer op keer faalt.
Een hacker heeft maar 1 klein gaatje nodig om al in het systeem binnen te komen of om de databank leeg te trekken. Maar het makkelijkste wat vaak genegeerd wordt is het updaten van de software en genoeg webwinkels met het thuiswinkel waarborg/keurmerk en andere bedrijven/organisaties draaien verouderde software, kijk maar de openbare http headers, daar wordt vaak genoeg informatie in mee gestuurd om een boekdeel over te schrijven.
Frameworks als Metasploit zijn gewoon openbaar en door iedere halve zool te gebruiken om een website met openbare exploits open te krikken.
Ondanks de genoeg bedrijven die een flinke schuivert maken en gehackt in de media komen denken bedrijven als nog niet dat ze wat aan hun beveiliging moeten doen. 'Een applicatie werkt toch dan is er verder niks aan de hand'. Natuurlijk spelen ook de kosten mee, 100% veilig kan je een website, infrastructuur, etc niet maken, maar 80% van de hacks zijn simpel en dus ook zo te voorkomen en de preventieve kosten zijn bijna altijd lager dan kosten van een hack.
Het zijn besluiten van het management samen met gebrek aan kennis van de uitvoerders (beheerders + programmeurs) die er voor zorgen dat de beveiliging keer op keer faalt.
Ben het erg met je post eens, maar de laatste paragraph was te kort door de bocht. Het zijn ook de besluiten van het management samen met de kennis van de uitvoerders (beheerders + programmeurs) die er voor zorgen dat de beveiliging keer op keer slaagt.Het zijn besluiten van het management samen met gebrek aan kennis van de uitvoerders (beheerders + programmeurs) die er voor zorgen dat de beveiliging keer op keer faalt.
Beveliging van digitale systemen is niets speciaals. Zoals alle beveiliging is het moeilijk, duur en je kan het nooit goed doen, je kan het alleen maar fout doen en daarmee in het nieuws komen. De meeste systeembeheerders zijn professionals en zullen hun best doen. Maar zoals je zelf (!) in je post aangeeft zijn er omstandigheden waar je je eenvoudigweg niet tegen verdedigen kan. Dan heb je 'pech' en komen alle 16 jarige systeembeheerders je op tweakers vertellen dat het allemaal aan het amateurgehalte van management en beheerders ligt.
Er bestaat geen 'afdoende' beveiliging. Er bestaat slecht een wankel evenwicht tussen de kosten en de baten. Dat geld voor brand, voor een normale inbraak en een digitale hack. Een bedrijf weegt de kosten en baten af en neemt een verzekering voor de rest. Net zoals we dat allemaal doen voor ons huis, auto, gezondheid etc. We gaan geen Fort Knox van ons huis maken, we doen wat redelijk is (lijkt?) en nemen maatregelen om de gevolgen van een probleem op te vangen.
Ik respecteer een systeembeheerder die me verteld dat er iets veranderd moet worden en dat dat geld kost. Neem alleen al de wettelijke zaken waar je dit jaar in Duitsland aan moet voldoen (20% meer kosten voor systeembeheer en snelheid die lager is!), de cookie wetgeving in Europa die me een halve ton kost. Maar beveiling is geen kostenpost, het is een 'state of mind'. Geld is daarvoor vrijwel nooit een issue. Als een beheerder naar me komt en een paar ton nodig heeft om beveiliging om te schroeven (komt minstens een maal per jaar voor, vaak net na de jaarlijkse Dell party) dan kan ie beter met zeer goede argumenten komen. Vorig jaar heb ik tijdens een dergelijke bijeenkomst via de telefoon (social hacking) een password van een belangrijke manager gekregen. in plaats van 225.000 Euro voor nieuwe servers hebben we voor een paar duizend euro alle gebruikers apart uitgelegt dat een IT beheerder ze niet belt om het pasword te horen. Na die meeting is een beheerder opgestapt omdat hij het 'not done' vond. Zijn opvolger snapt het wel, verdient nu ook meer.
Oke, misschien was die laatste opmerking een beetje kort door de bocht, maar geef toe dat dingen als escapen in webapplicaties geregeld vergeten wordt. Tuurlijk vind ik dat systeembeheerders (over het algemeen) goed werk leveren, maar beveiliging is iets dat vanzelf sprekend hoort te zijn en het aantal inbraken is veel hoger dan het aantal dat de media haalt.
Welnee; zero day lekken kan je 'gewoon' op de zwarte markt kopen; dus je zal er evengoed bijvoorbeeld medicijnfabrikanten treffen die ze aanschaffen om die vervolgens aan georganiseerde malwareschrijvers te geven met de opdracht er een botnet mee te bouwen om zoveel mogelijk viagra- en phizer-spam rond te sturen vanaf PC's van nietsvermoedende Windows-gebruikers.Ook al worden 0days eigenlijk alleen gebruikt tegen kritieke infrastructuur zoals defensiebedrijven, energieleveranciers, overheden, etc.
Dat is echt onzin
Ja, 0days zijn op de zwarte markt en via VUPEN te koop, maar alleen voor ¤50k +
Viagra spam wordt verstuurd om de gebruiker door te sturen naar nep apotheken, of heb je soms ervaringen die je wilt delen?
Ja, 0days zijn op de zwarte markt en via VUPEN te koop, maar alleen voor ¤50k +
Viagra spam wordt verstuurd om de gebruiker door te sturen naar nep apotheken, of heb je soms ervaringen die je wilt delen?
Bedrijven denken dat ICT beveiliging iets is wat je er "even bij doet".
Ze snappen niet dat dit een doorlopend proccess moet zijn. Zoals nu, huren ze een beveiligings bedrijf in, leuk enzo, die verdienen dan 1 jaar goed geld dan is alles weer dicht en worden deze experts weer de deur gewezen, de eerstvolgende beheerder die aangenomen wordt maakt dan WEER beginnersfouten en je bent terug bij af.
ICT beveiliging is iets dan in je bedrijfscultuur moet zijn verweven wil je dit langere tijd op order hebben en dat kost geld...
Ze snappen niet dat dit een doorlopend proccess moet zijn. Zoals nu, huren ze een beveiligings bedrijf in, leuk enzo, die verdienen dan 1 jaar goed geld dan is alles weer dicht en worden deze experts weer de deur gewezen, de eerstvolgende beheerder die aangenomen wordt maakt dan WEER beginnersfouten en je bent terug bij af.
ICT beveiliging is iets dan in je bedrijfscultuur moet zijn verweven wil je dit langere tijd op order hebben en dat kost geld...
Als dat gat niet behoorlijk leeg zou zijn dan zou het natuurlijk ook geen gat in de markt zijn@proxx, @hashtag
Dat is dan gezien een gemiddelde week frontpage op tweakers nog een behoorlijk leeg gat op dit moment. Ik zou als hacker wel weten wat mijn volgende carrière move zou zijn!
Wat Proxx zegt
Zie eerder nieuwsbericht over Proserver, dikke faal dit;
nieuws: Hackers maken wachtwoorden buit bij Proserve via Plesk-lek
Zie eerder nieuwsbericht over Proserver, dikke faal dit;
nieuws: Hackers maken wachtwoorden buit bij Proserve via Plesk-lek
Beetje flauw,
want als je die draad goed had gelezen, dan zag je dat het een algemeen lek in Plesk was. Toevallig was Proserve een van de eerste partijen die hier klanten over adviseerden, dus kwamen zij als een van de eerste in nederland in het nieuws.
Vele andere hosting providers hadden hetzelfde probleem (...welke beginnende server draait nu geen plesk?)
want als je die draad goed had gelezen, dan zag je dat het een algemeen lek in Plesk was. Toevallig was Proserve een van de eerste partijen die hier klanten over adviseerden, dus kwamen zij als een van de eerste in nederland in het nieuws.
Vele andere hosting providers hadden hetzelfde probleem (...welke beginnende server draait nu geen plesk?)
Dit is een langslepend proces waarbij de problemen nu naar boven komen omdat het steeds eenvoudiger wordt om de boel te hacken/omzeilen.
Ik geef al jaren aan dat IT security veel meer prio moet hebben dan men denkt, maar als ondertussen usernames en passwords in plain-text in een SQL-database worden opgeslagen, dan springen je de tranen in de ogen.
Zoals Proxx al aangeeft, het gat is er al lang. Het moet alleen even vakkundig worden dichtgetimmerd.
Ik geef al jaren aan dat IT security veel meer prio moet hebben dan men denkt, maar als ondertussen usernames en passwords in plain-text in een SQL-database worden opgeslagen, dan springen je de tranen in de ogen.
Zoals Proxx al aangeeft, het gat is er al lang. Het moet alleen even vakkundig worden dichtgetimmerd.
Dus even afgaande op wat hier staat: grove nalatigheid van proserve?
Mocht dat zo zijn dan is het misschien tijd om een voorbeeld te stellen en proserve te vervolgen.
Mocht dat zo zijn dan is het misschien tijd om een voorbeeld te stellen en proserve te vervolgen.
En dan? Een rechtspersoon (het bedrijf) moet dan misschien een fikse boete betalen. Boeten voor beveiligingslekken worden dan onderdeel van de fiscale schatting aan kosten. Gevolg is dat dan de klanten gaan betalen voor (potentieel) nalatigheid.Dus even afgaande op wat hier staat: grove nalatigheid van proserve?
Mocht dat zo zijn dan is het misschien tijd om een voorbeeld te stellen en proserve te vervolgen.
Als er sprake is van nalatigheid (beoordeeld vanuit redelijkheid en billikheid) is het beter om de verantwoordelijken vanaf de directie tot het niveau dat geen onderdeel is van de beslissingsvorming hoofdelijk (dus als natuurlijk persoon) strafbaar te stellen. Dit is vergelijkbaar met de Sarbanes-Oxley Act doordat het bestuurders motiveert de juiste keuzes te maken.
[Reactie gewijzigd door The Zep Man op donderdag 19 juli 2012 18:13]
Ik bedoel ook hoofdelijk, een boete heeft inderdaad niet altijd het gewenste effect, maar een boete doorrekenen aan klanten is ook weer niet zo makkelijk als je doet voorkomen (het kan immers niet tijdens de looptijd van een contract en het zorgt meteen dat je prijsstelling minder concurrerend wordt).
Het is soms ongekend hoe met zulke grote databases wordt omgesprongen qua beveiliging. En nog erger, ze hebben niet eens doorgehad dat er een kopie van is getrokken. Ik vraag me af hoe Trixy dat heeft kunnen zien (timestamp, database dump die er nog stond (niet gewist) of iets dergelijks)?
Log files misschien?
Je kan er bijna vanuit gaan... als iemand de beveiliging plat gooit van een redelijk waardevolle database, dan mag je er vrijwel blind vanuit gaan dat hier een dump van getrokken is
Als blijkt dat het hier gaat om nalatigheid dan moet er gestraft worden. Het wordt het tijd dat we in Nederland (Europa) betere juridische houvast krijgen voor het aanpakken van de verantwoordelijken voor lekkende rotzooi.
[Reactie gewijzigd door bakjefriet op woensdag 18 juli 2012 16:52]
Plesk vind ik persoonlijk ook een matige beheertool.
Leuk voor de klant, maar die gebruikt Plesk ook
niet dagelijks.
Ze komen soms veel te laat met security patches,
terwijl ze voor onderliggende UNIX al binnen zijn,
moeten zij hun eigen patches op de Plesk-branded
UNIX-programma's laten lopen.
Vanaf Plesk 10 is het al wat beter omdat dan tenminste
de Plesk updates automatisch binnenlopen. Plesk
8 bv. geeft niet eens een waarschuwing af dat er updates
zijn, zodat je dagelijks zelf zou moeten checken.
Denk dat voor oudere Plesken hier wat aan te doen is door beheerder door bv.
met unix-tool "expect" /usr/local/psa/admin/bin/autoinstaller
dagelijks te laten lopen.
Leuk voor de klant, maar die gebruikt Plesk ook
niet dagelijks.
Ze komen soms veel te laat met security patches,
terwijl ze voor onderliggende UNIX al binnen zijn,
moeten zij hun eigen patches op de Plesk-branded
UNIX-programma's laten lopen.
Vanaf Plesk 10 is het al wat beter omdat dan tenminste
de Plesk updates automatisch binnenlopen. Plesk
8 bv. geeft niet eens een waarschuwing af dat er updates
zijn, zodat je dagelijks zelf zou moeten checken.
Denk dat voor oudere Plesken hier wat aan te doen is door beheerder door bv.
met unix-tool "expect" /usr/local/psa/admin/bin/autoinstaller
dagelijks te laten lopen.
Buiten dat plesk een matige beheertool is worden alle wachtwoorden (voor versie 11 geloof ik) als plain tekst opgeslagen. Deze zijn gewoon beschikbaar via een bestaande exploit. Er is wel een patch voor oudere versies maar mijn vertrouwen in zo'n pakket was na het lezen over deze exploit direct weg. Zelfs het admin wachtwoord staat plain tekst in een file op het system.
Prachtig verhaal, maar dit lek heeft niets met Plesk te maken.
In het oorspronkelijke bericht staat het volgende:
"De zwakheid werd ontdekt door hacker Trixy van het Nederlands Genootschap van Hackende Huisvrouwen."
Is dat een grap? Of is Trixy echt een member van het "Nederlands Genootschap van Hackende Huisvrouwen"?
Viel me op dat Tweakers dat weg laat...
"De zwakheid werd ontdekt door hacker Trixy van het Nederlands Genootschap van Hackende Huisvrouwen."
Is dat een grap? Of is Trixy echt een member van het "Nederlands Genootschap van Hackende Huisvrouwen"?
Viel me op dat Tweakers dat weg laat...
De huisvrouwen waren al eerder aan het hacken: nieuws: GGZ-instellingen laten gegevens patiënten uitlekken. En of het werkelijk huisvrouwen zijn, dat weten zij alleen zelf, maar je kunt het wel raden denk ik.
[Reactie gewijzigd door wintermute. op woensdag 18 juli 2012 18:13]
Misschien hadden ze beter vooraf een beveiligingsbedrijf in de arm kunnen nemen om hun systemen op lekken en kwetsbaarheden te laten checken.Proserve heeft de gekraakte systemen vervangen, de politie ingeschakeld en een beveiligingsbedrijf in de arm genomen om herhaling te voorkomen.
Dat kost wel wat maar beperkt de schade aanzienlijk. Een 100% garantie zul je niet krijgen maar je hebt dan als bedrijf wel aangetoond dat je er moeite voor hebt gedaan om je databases en servers te beveiligen.
In hoeverre kan het College Bescherming Persoonsgegevens niet een meer pro-actieve rol spelen om dergelijke hacks in de toekomst tegen te werken? Bijvoorbeeld door richtlijnen voor te schrijven betreffende security en beheer?
Ik vraag me af hoe het informatielandschap eruit gaat zien als de gegevens van iedereen door hackers misbruikt/doorgegeven worden. Een bel-me-niet-register lijkt me niet echt afdoende om dergelijke lekkage tegen te gaan; en wie kan er voor de kosten gaan opdraaien die de getroffen personen moeten maken om e.e.a. weer 'op orde' te krijgen?
Ik vraag me af hoe het informatielandschap eruit gaat zien als de gegevens van iedereen door hackers misbruikt/doorgegeven worden. Een bel-me-niet-register lijkt me niet echt afdoende om dergelijke lekkage tegen te gaan; en wie kan er voor de kosten gaan opdraaien die de getroffen personen moeten maken om e.e.a. weer 'op orde' te krijgen?
[Reactie gewijzigd door bouvrie op woensdag 18 juli 2012 17:12]
Richtlijnen voor security en beheer zijn er genoeg. Dat is het probleem niet. Zo weet iedereen dat je wachtwoorden eigenlijk versleuteld moet opslaan en dat je creditcard data uberhaupt niet (geheel) opslaat.
Elk serieus bedrijf is wel met beveiliging bezig, maar zoals ook hier weer blijkt het een "vergeten" backup server te zijn, waar misschien minder restricties op zaten omdat "deze uberhaupt niet via het Internet bereikbaar zou mogen zijn".
Dit is dan een aaneenstapeling van fouten dat uiteindelijk leidt tot een dergelijk hack.
Vergelijkbaar is het lek van VCD Humannet. Daar bleek uiteindelijk dat een verouderd inlogsysteem nog online stond. De beveiliging was al eerder verbeterd door een nieuwe inlogpagina, maar de oude was alleen verplaatst en niet verwijderd.
Dat soort lekken ga je door middel van policies nooit voorkomen. Daarnaast, dit soort problemen kun je nooit geautomatiseerd ontdekken. Een CBP kan hier dus nooit proactief tegen optreden door middel van scans of wat dan ook
Datalekken zullen, om dit soort redenen, altijd blijven bestaan. Net als dat je "real life" inbraken nooit 100% zal voorkomen, ongeacht wat voor maatregelen je treft. Banken worden immers ook nog steeds overvallen ondanks de honderden jaren ervaring met de beveiliging van banken. En als een bank niet wordt overvallen wordt je wel geskimmed, waarmee ik bedoel dat dan de beveiliging wordt omzeild door een andere manier van aanvallen.
Elk serieus bedrijf is wel met beveiliging bezig, maar zoals ook hier weer blijkt het een "vergeten" backup server te zijn, waar misschien minder restricties op zaten omdat "deze uberhaupt niet via het Internet bereikbaar zou mogen zijn".
Dit is dan een aaneenstapeling van fouten dat uiteindelijk leidt tot een dergelijk hack.
Vergelijkbaar is het lek van VCD Humannet. Daar bleek uiteindelijk dat een verouderd inlogsysteem nog online stond. De beveiliging was al eerder verbeterd door een nieuwe inlogpagina, maar de oude was alleen verplaatst en niet verwijderd.
Dat soort lekken ga je door middel van policies nooit voorkomen. Daarnaast, dit soort problemen kun je nooit geautomatiseerd ontdekken. Een CBP kan hier dus nooit proactief tegen optreden door middel van scans of wat dan ook
Datalekken zullen, om dit soort redenen, altijd blijven bestaan. Net als dat je "real life" inbraken nooit 100% zal voorkomen, ongeacht wat voor maatregelen je treft. Banken worden immers ook nog steeds overvallen ondanks de honderden jaren ervaring met de beveiliging van banken. En als een bank niet wordt overvallen wordt je wel geskimmed, waarmee ik bedoel dat dan de beveiliging wordt omzeild door een andere manier van aanvallen.
Als je ervoor zorgt dat alle activiteit wordt gelogd, dan kun je uit de logfiles, met statistische methoden achterhalen dat er iets niet in de haak is.Daarnaast, dit soort problemen kun je nooit geautomatiseerd ontdekken.
Simpel voorbeeld, stel dat op een normale dag de volgende string in de logfile komt:
AHSSSDFHGASSSBASHSSJGFDHHHGDSFKJASJHAS
(even versimpeld, ieder karakter stelt een bepaalde operatie voor die is gelogd).
en op een bepaald moment bevat de logfile:
AHSDHGAAAAAAAAAAAAAAAADHGDHGAAAAAAAAAAAAA
Dan kun je dus (met statistische methoden) zien dat er iets vreemds aan de hand is en een alarmbel laten afgaan.
Intrustion Detection noemt men dat.
Vrij gebruikelijk in grote enterprise omgevingen.
Vrij gebruikelijk in grote enterprise omgevingen.
True, maar ik bespeur over het algemeen een soort "Foutje, bedankt"-mentaliteit rondom de hacks van tegenwoordig, die naar mijn mening (bijvoorbeeld door druk/boetes vanuit een erkend orgaan zoals het CBP) om zou moeten slaan naar een wat meer professionele.
[Reactie gewijzigd door bouvrie op woensdag 18 juli 2012 22:33]
Het is altijd "beter"om te bezuinigen op beveiliging en nadat er dan een hack heeft plaatsgevonden, komt het " als het kalf verdronken is dempt men de put verschijnsel" om de hoek kijken en gaan we er eindelijk maar eens iets aan doen..
[Reactie gewijzigd door Kees de Jong op woensdag 18 juli 2012 18:57]
Dat is wel eenvoudig gezegd. Wat als dit nu een doelgerichte aanval was via een (uiteraard onbekend) 0day lek was? Daar kan je jezelf helaas nooit tegen wapenen.
Houdt toch eens op met de gedachte: "M'n server is gehackt het moet een 0day zijn"
Een 0day is idd het ideale wapen, maar waarom op deze manier als het voor een hacker ook veel goedkoper kan door gewoon te kijken naar bekende veel voorkomende beveiligings en configuratiefouten om binnen te komen en er is maar een handje vol mensen dat 0days kan vinden én exploiten. En verder zijn er ook nog beschermingsmaatregelen als DEP/non executable stack en ASLR om geheugencorruptie te voorkomen.
Uit de quote: "Zij kwam erachter dat het ontbrak aan iedere toegangsbeveiliging om als beheerder in te loggen." van Nu.nl kan je stellen dat er misschien we sprake is geweest van een SQL injectie lek in het beheerpaneel zelf, dan zou je al binnen kunnen komen met:
username: '=', password: '=' of als de input van het wachtwoord wordt gehasht voor de invoer naar de query met username: -1' UNION SELECT * FROM users-- - en mysql_real_escape_string() is geen goede beveiliging hier tegen, zoek invoer in de vorm van een integer en mysql_real_escape_string() helpt niet meer aangezien je je ' dan niet meer nodig hebt.
Maar dat is maar wilt gokken en het kan ook aan andere dingen liggen, zoals voorspelbare inloggegevens, notes in de html broncode of niet goed gechmodded configuratiebestanden.
Een 0day is idd het ideale wapen, maar waarom op deze manier als het voor een hacker ook veel goedkoper kan door gewoon te kijken naar bekende veel voorkomende beveiligings en configuratiefouten om binnen te komen en er is maar een handje vol mensen dat 0days kan vinden én exploiten. En verder zijn er ook nog beschermingsmaatregelen als DEP/non executable stack en ASLR om geheugencorruptie te voorkomen.
Uit de quote: "Zij kwam erachter dat het ontbrak aan iedere toegangsbeveiliging om als beheerder in te loggen." van Nu.nl kan je stellen dat er misschien we sprake is geweest van een SQL injectie lek in het beheerpaneel zelf, dan zou je al binnen kunnen komen met:
username: '=', password: '=' of als de input van het wachtwoord wordt gehasht voor de invoer naar de query met username: -1' UNION SELECT * FROM users-- - en mysql_real_escape_string() is geen goede beveiliging hier tegen, zoek invoer in de vorm van een integer en mysql_real_escape_string() helpt niet meer aangezien je je ' dan niet meer nodig hebt.
Maar dat is maar wilt gokken en het kan ook aan andere dingen liggen, zoals voorspelbare inloggegevens, notes in de html broncode of niet goed gechmodded configuratiebestanden.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
