Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 10 reacties

Nasdaq is in verlegenheid gebracht nu een Zwitsers beveiligingsbedrijf bekend heeft gemaakt dat de aandelenbeurs een xss-lek twee weken lang ongemoeid heeft gelaten. Eerder al bleken criminelen in staat via een sql-lek creditcardgegevens van gebruikers te ontfutselen.

NasdaqVolgens beveiligingsbedrijf High-Tec Bridge konden kwaadwillenden via de ontdekte xss-lekken volledige toegang krijgen tot Nasdaq.com. Hierdoor zou het onder meer mogelijk zijn geweest om html-code aan de website toe te voegen waarmee kwaadwillenden creditcardgegevens en andere privégegevens had kunnen afvangen. Ook hadden aanvallers het lek kunnen misbruiken om kwaadaardige software via de website van Nasdaq te verspreiden, aldus het beveiligingsbedrijf.

Het is niet duidelijk of het om een persistent of non-persistent xss-kwetsbaarheden gaat. Bij een persistente xss-aanval wordt html-code permanent geïnjecteerd, waardoor alle bezoekers de kwaadaardige code te zien krijgen. De meeste xss-kwetsbaarheden zijn echter non-persistent: de kwaadaardige code wordt daarbij via de url geïnjecteerd, en om de kwaadaardige code te krijgen, moet dus die specifieke url worden bezocht. Slachtoffers kunnen verleid worden om die url te bezoeken via bijvoorbeeld sociale media.

High-Tec Bridge zegt Nasdaq twee weken terug al op de hoogte te hebben gebracht van het bestaan van de xss-lekken. De fouten werden maandag pas hersteld, nadat diverse media hadden bericht dat de website van Nasdaq vatbaar was voor cross site scripting-aanvallen. Volgens Nasdaq zijn de gedichte lekken niet misbruikt door aanvallers, schrijft Computerworld.

Eerder al bleek dat aanvallers er in waren geslaagd om via sql-lekken in de website van onder meer Nasdaq creditcardgegevens te ontfutselen. Hierbij zouden in totaal de gegevens van 160 miljoen creditcards zijn gestolen. In verband met deze aanval zijn vorig jaar twee Russen in Nederland opgepakt, die samen met drie andere verdachten achter de grootste datadiefstal ooit zouden zitten.

De hackers zouden destijds binnengekomen zijn via sql-injecties: bij Nasdaq zat die bijvoorbeeld op de pagina waarop gebruikers hun verloren wachtwoord konden opvragen. Daardoor kregen de hackers toegang tot computersystemen van de bedrijven en instellingen. Ze gebruikten een backdoor om malware op die systemen te zetten. Die spyware maakte dumps van alle creditcardgegevens en stuurde die door.

Moderatie-faq Wijzig weergave

Reacties (10)

Binnen 3 weken gedicht, dus.

Als er een lek is, dan kan het ook nog vaak best tijd kosten om te a) een analyse te maken waar het lek precies door komt b) een fix te ontwerpen c) een fix te ontwikkelen d) de fix te testen.

Op basis van de beschikbare informatie is het voor mij in deze lastig om in te schatten hoe kritiek het lek is en of het bijvoorbeeld mogelijk was om op misbruik te monitoren terwijl een fix ontwikkeld wordt.

Overigens wil ik niet zeggen dat Nasdaq hier geen steken heeft laten vallen, simpelweg dat het als buitenstaander wel heel makkelijk is om dit soort dingen te roepen, terwijl je vaak geen beeld hebt van de complexiteit van een omgeving.

Door een "foute" fix te maken kun je soms meer schade aanrichten dan een hacker. Iemand die een lek heeft gevonden, heeft er vaak belang bij om de impact ervan een beetje dik aan te zetten.

[Reactie gewijzigd door Keypunchie op 17 september 2013 09:19]

En vergeet ook de operationele impact niet. Je kunt niet "zomaar" een systeem plat leggen omdat er een update moet worden ingedraaid. Er zijn teveel gebruikers van zo'n systeem afhankelijk en dan is het een afweging van belangen en risico's. Maar zoals je zegt: vanaf de zijlijn is het altijd makkelijk commentaar geven, terwijl iedereen die in een dergelijke omgeving werkt (feitelijk iedere IT-er) weet dat de wereld niet zo simplistisch in elkaar zit.
lekker slordig dat ze 2 weken hebben gewacht met het dichten van een lek. het is gelukkig wel gebeurd, maar wel een beetje laat. dat had eerder gekunt. het had misschien wel net zo kunnen lopen als bij dat SQL lek.
Wat ik veel erger vind is dat het pas gedaan wordt op het moment dat "diverse media hadden bericht dat de website van Nasdaq vatbaar was voor cross site scripting-aanvallen."

Wat mij betreft mag hier regelgeving voor komen oid met betrekkking op onverantwoord handelen. Bedrijven die immers dergelijke gegevens (oa creditcards) verwerken dienen aan strenge eisen te voldoen (PCI), gaan ze hier onverantwoordelijk mee om door beveiligingslekken pas te dichten nadat deze publiekelijk bekend worden, mogen ze wat mij betreft (gedeeltelijk) verantwoordelijk worden gehouden voor de onkosten die jaarlijks door fraude gemaakt worden.

disclaimer: mocht Nasdaq na de melding meteen zijn begonnen met het dichten van dit specifieke lek, mag je er vanuit gaan dat dit makkelijk aantoonbaar moet zijn dmv geschreven communicatie danwel logboeken of een issuetracker of zoiets.
Bij laakbaar handelen omtrend de beveiling van persoonsgegevens kunnen bedrijven vziw in Nederland in elk geval een fikse geldboete opgelegd krijgen. Topmensen kunnen geloof ik in extreme gevallen ook hoofdelijk aansprakelijk gesteld worden en, dacht ik, ook crimineel aangeklaagd worden.
Wordt het niet eens tijd dat ze al die programmeurs eruit schoppen?
SQL-injectie lekken in een systeem als dat van Nasdaq? Ik zou me als programmeur kapot schamen!
als het 2 weken duurt lijkt het dat een vaste release cycle gevolgd is.... oftewel, men gaat niet direkt in live-code frutselen en halsoverkop aanpassen, maar ontwikkeld een fix , test deze en released deze na het testen...


Vraag is natuurlijk vooral of hier een hof-fix wl heel hard noodzakelijk was en er grond was te vrezen dat die exploit actief uitgenut zou worden.
Dat is niet geheel duidelijk, het bedrijf dat met de melding komt is zelf natuurlijk ook een belanghebbende om bepaalde 'angsten' te creeren.

Nasdaq zelf geeft aan dat er kennelijk geen direkte grond zou zijn geweest, maar kennelijk was precies oop de datum dat de bug gemeld werd er ook enkele technische problemen met hun systeem en dat kan misschien ook ertoe geleid hebben dat ze geen kortstondige oplossingen konden dorvoeren...


Wat het precies is, is heel erg lastig te bepalen vanaf een afstandje en met onvolledige informatie...
Er is altijd wel een kans dat 'de soep niet zo heet gegeten wordt als die opgediend wordt'... en an sich hoeft het ook geen slecht teken zijn dat juist in bepaalde zeer kritische systemen bugs niet 'eventjes' tussendoor opgelost kunnen en mogen worden, en dat soms ook iets langer duurt (maar wel goed getest worden)
Heeft het beveiligingsbedrijf 2 weken eerder al een melding gemaakt van de lek?
Of hebben ze het pas na 2 weken door gehad?

Als ze het ook daadwerkelijk al 2 weken wisten is dit wel heel slecht |:(
In het artikel staat "High-Tec Bridge zegt Nasdaq twee weken terug al op de hoogte te hebben gebracht van het bestaan van de xss-lekken. De fouten werden maandag pas hersteld".
Ze hebben het lek maandag dus pas hersteld en wisten er toen al twee weken van.
In het artikel staat "High-Tec Bridge zegt Nasdaq twee weken terug al op de hoogte te hebben gebracht van het bestaan van de xss-lekken. De fouten werden maandag pas hersteld".
Ze hebben het lek maandag dus pas hersteld en wisten er toen al twee weken van.
Sorry verkeerd gelezen. :X

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True