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 , , 47 reacties

Een hacker heeft toegang gekregen tot een database van netwerk- en beveiligingsbedrijf Barracuda Networks, en heeft een dump van de database op het internet geplaatst. Onder andere wachtwoord-hashes en loginnamen zijn zichtbaar.

De hacker gebruikte sql-injectie om de gegevens uit de database te halen en plaatste deze op het internet. Onder meer gegevens van werknemers en zakelijke partners zijn zichtbaar. Het gaat onder meer om ip-adressen, gebruikersnamen en hashes van wachtwoorden.

Een wachtwoordhash is een versleutelde versie van een wachtwoord, waaruit het oorspronkelijke wachtwoord niet direct kan worden achterhaald. Door zogeheten rainbow tables aan te leggen kunnen hashes echter aan de bijbehorende wachtwoorden worden gekoppeld, zodat deze toch zijn te achterhalen.

Volgens ComputerWorld had een door Barracuda zelf ontwikkelde firewall de server tegen dit soort aanvallen moeten beschermen, maar was die op het moment van de aanval offline voor onderhoud. Er zouden volgens Barracuda geen financiële gegevens in de database zijn opgeslagen. Sql-injectie is een vaak voorkomende aanval op het internet en laat hackers door een programmeerfout eigen opdrachten toevoegen aan sql-queries.

Moderatie-faq Wijzig weergave

Reacties (47)

Niet echt een nuttige actie geloof ik, behalve laten zien dat ook beveiligingsbedrijven zwakheden hebben. Dat is wel een belangrijk en nuttig doeleinde an sich, maar maakt op dit moment niet veel indruk omdat de firewall down was.
Wel gek dat die firewall gewoon offline was. Het lijkt me dat je als beveiligingsbedrijf met dergelijke gevoelige data toch minstens een redundant systeem hebt waarbij je aan de firewall kunt sleutelen zonder meteen de boel kwetsbaar te stellen. Daarnaast zou de server toch ook tijdens het maintenance even losgekoppeld kunnen worden? Even de server offline lijkt me voordeliger dan zoals nu gevoelige data op straat dankzei je eigen bedrijf.

Barracuda had voor zover ik weet geen beef met bepaalde groepen, buiten de gewoonlijke, dus daar kan het niet aan liggen.

Zo zie je maar weer dat iedereen te hacken valt en dat niks echt veilig is. Ook beveiligingsbedrijven niet.

[Reactie gewijzigd door DamonTheron op 12 april 2011 11:07]

Allereerst kun je je afvragen hoe gevoelig de data is. In feite niet veel meer dan de klantgegevens van je fietsenwinkel. Daarnaast is dit een feature geen bug. Veel bedrijven hebben liever dat als er een probleem met de firewall is, de servers achter de firewall beschikbaar blijven. Vandaar dat veel firewalls een passthrough functie hebben. Gaat het fout is de site nog beschikbaar. Die functie hoef je natuurlijk niet te gebruiken maar afhankelijk van hoe het risico wordt ingeschat en de potentiele gederfte inkomsten kan het voor een bedrijf een goede optie zijn.

Barracuda heeft gewoon pech gehad, en dan vooral dat de software zelf lekken bevatte die net op dat moment werden misbruikt,maar wereldnieuws is dit ook weer niet.
Je bagatelliseert het voorval nogal. Ik vind dit daarentegen een uiterst grove blunder, een echte Epic Fail om maar eens een populaire term te gebruiken. De redenen waarom:

- Dit is een beveiligingsbedrijf. Veilig stellen van data en/of spullen tegen kwaadwillenden is hun Core Business.
- Uit het artikel valt af te leiden dat ze enkel en alleen vertrouwden op een firewall. Dat heet in vaktermen een Single Point Of Failure. Iedere programmeur/netwerkdesigner/admin waar betrouwbaarheid en beveiliging een primair punt is weet dat je die ten alle tijde moet elimineren, op z'n minst vermijden.
- Waat veiligheid een issue is (en dat is het per definitie voor een beveiligingsbedrijf) dienen er altijd checks te zijn dat exploits zoals een SQL-injectie niet mogelijk kunnen zijn. Of die controle was er niet, of hij is slecht uitgevoerd.
- Het lijkt om een MySQL database te gaan waar de wachtwoorden op een standaard manier versleuteld zijn. Dit is m.b.v. rainbow tables en/of een serverfarm redelijk makkelijk te kraken met genoeg tijd. En de Bad Guys hebben nu alle tijd van de wereld. M.a.w. een slechte beveiliging.
- De gestolen gegevens zijn enorm gevoelig. De kans is heel groot dat dezelfde gebruikersnamen op andere sites ook worden gebruikt met hetzelfde wachtwoord. Ook al is het niet handig als gebruiker om overal dezelfde usernames/wachtwoorden te gebruiken, iedereen weet dat het gebeurt en je hebt die data toevertrouwd aan het bedrijf.

Dit zou voor mij persoonlijk als bedrijf reden zijn om onmiddellijk het contract met hun te ontbinden. Als ze al niet hun eigen data kunnen beveiligen, dan lijkt het me niet dat ze dat wel goed gaan doen met mijn data!
sql injectie? wel ergs slecht dat een beveiligings bedrijf hiervoor vatbaar is.

het zou mij niks verbazen als het komt door het gebruikt van 3rd party tool waar deze kwetsbaarheid in zat.
In het artikel staat dat hun eigen firewall die hiertegen zou moeten beschermen op het moment van de injectie offline was voor onderhoud. Ligt dus niet zozeer aan een 3rd party tool en meer aan het feit dat ze schijnbaar opzettelijk de server vrijgaven om onderhoud te plegen.

Het lijkt me dat je als beveiligingsbedrijf toch een redundant system hebt waarbij je aan een firewall kunt sleutelen zonder dat je de hele zooi uit moet zetten en aan dit soort gevaar moet blootstellen.
Je hebt geen firewall nodig om je code zodanig in orde te hebben dat er geen sql-injectie mogelijk is... Wel tijd om je code te controleren uiteraard. Een firewall die daar tegen beschermt hoort juist overbodig te zijn. Het is dus alsnog een fout in hun software die er niet in had moeten zitten, ongeacht of een firewall daarvoor aan- of uitstond.

Er zijn uiteraard zat dingen waar je een firewall tegen in zet, maar sql-injection hoort daar niet onder te vallen. 't Is natuurlijk mooi meegenomen als je een firewall hebt die je daar toch wel tegen beschermd, maar je code moet gewoon bestand zijn tegen sql-injection.
Vertel dit maar niet aan bedrijven als F5. Die brengen al jaren heel succesvol een app firewall op de markt. Ook barricuda heeft dat soort producten Dat dit iets anders is dan een gewone firewall is een feit, maar het is wel degelijk normaal om grotere sites met dat soort producten te beschermen. Het lijkt erop dat de auteur het verschil niet kent. Echter net zoals een os niet perfect is en je een firewall gebruikt om het os te beschermen gebruik je dus een applicatie firewall om applicaties te beschermen.
Zomaar een vraagje, maar hoe kan een firewall tegen sql injection beschermen?
Dit komt toch gewoon door slecht programmeerwerk en zou voor een firewall toch hetzelfde zijn als een 'geldig' request voor data dat via een website zou komen.
In theorie zou het, volgens mij, wel mogelijk moeten kunnen zijn. (mits men geen SSL verbinding gebruikt overigens) Maar efficiënt zou het nooit kunnen zijn!
Er bestaat veel producten die dit kunnen, F5 Big-Ip ASM bijvoorbeeld.

Dit kan op verschillende manieren te werk gaan. Bijvoorbeeld bepaalde SQL code die op injectie wijst gewoon te weigeren. Andere manier is de site om een soort van learning modus te laten draaien en daardoor zien welk type request legit zijn. Je kunt dat ook doen terwijl de site al in productie is door trusted locations toe te voegen. Het systeem is slim genoeg om zo zichzelf bij te leren wat al dan niet legit traffic is.
dat kan niet mogelijk zijn, een PHP script o.i.d. blijft de output genereren die van hem wordt verwacht.

In andere woorden, je zou altijd een dump te zien krijgen van de database, een firewall zal dit nooit als een database kunnen identificeren.

tevens is een firewall ook niet bedoeld voor dit soort dingen.
Wellicht dat de firewall de toegang tot de kwetsbare website regelde.

Het zal niet de eerste keer zijn dat door werkzaamheden per ongeluk een website bereikbaar wordt die alleen intern toegankelijk had mogen zijn.

Het analyseren van requests om te zien of er injectie-code in zit kan niet foutloos werken. Zo'n injectie kan je namelijk relatief makkelijk verstoppen onder iets wat best legitieme invoer zou kunnen zijn:
parents' or true--this is not what I thought

[Reactie gewijzigd door Infinitive op 12 april 2011 11:40]

Daarom moet je dus nooit alleen vertrouwen op een apperaat om je te beschermen tegen SQL injecties en dat soort ongein, maar ook fatsoenlijke code eisen van de developers.

(en testen, testen en nog eens testen)
Je kan eisen en testen wat je wilt, maar fouten zullen blijven voorkomen. Dus gebruikt men mits men het geld heeft, een gelaagde methode. En fatsoenlijke code EN een firewall die dit kan voorkomem.
Kwestie van alles valideren en mysql_real_escape_string() eroverheen?

PHP5 heeft zelfs filters erin zitten, waardoor je kan sanitizen en/of validaten, dan heb je echt geen excuus meer als developer om er dit soort blunders in te laten zitten.

Er wordt gewoon te weinig aandacht aan besteed, zelfs bij een securitybedrijf zoals Barracuda.

Voor mij gewoon een teleurstelling in Barracuda, maar 'k ben iig blij dat ze al hun passwords hebben versleuteld (zoals uiteraard ook hoort).
Dan doe je het nog steeds verkeerd met mysql_real_escape_string.

Je moet even nogmaals lezen wat PolarBear schrijft.

En als je dat gelezen hebt, dan even dit lezen : http://php.net/manual/en/mysqli.prepare.php

Gewoon de hele mysql_query functie vergeten en nooit meer gebruiken en je eigen code herschrijven.
Gewoon de hele mysql_query functie vergeten en nooit meer gebruiken en je eigen code herschrijven.
Doe je dat in je eigen apps ook? Linkje?
Echt SQL injecties waarom kan het uberhaupt nog? 8 tot 9 jaar geleden deed ik alles voor schoolopdrachten al met stored procs en/of geparameteriseerde SQL. Dat mag toch echt nu zo wel een beetje als basis kennis worden verwacht.
Niet dus.

In mijn klas zijn we bezig met PHP en SQL, en als ik code van klasgenoten zie, dan zie je geen enkele validatie.
Spreek je ze er op aan, dan schreeuwen ze dat het ze niet boeid, en dat er toch niks kan gebeuren.
Voer ik een SQL injectie uit (waar ze bij zijn) en delete ik de hele database (via hun zelf gemaakte app) dan is de wereld te klein.
Vooral niet stoppen met SQL-injecteren. Ze kunnen niet vroeg genoeg leren dat er vodden van komen als ze hun werk niet doen.
Een wachtwoordhash is een versleutelde versie van een wachtwoord, waaruit het oorspronkelijke wachtwoord niet direct kan worden achterhaald. Door zogeheten rainbow tables aan te leggen kunnen hashes echter aan de bijbehorende wachtwoorden worden gekoppeld, zodat deze toch zijn te achterhalen.
Als er een salt doorheen gegooid wordt is de kans nog maar klein dat er wat uit zal komen.
Eh.. daar helpen de rainbow tables nou juist mee?

Daarnaast is er zo te zien geen per-entry salt gebruikt. Een aantal (systeem!) accounts hebben allemaal dezelfde hash. Dat wordt het al een stuk eenvoudiger.
De db is MySql, dus ga er maar aanstaan. Daar zullen wel rainbow tables voor te vinden zijn, als er niet zelfs overzichten zijn met standaard wachtwoorden (zoals voor Oracle ook)

[Reactie gewijzigd door The Van op 12 april 2011 13:10]

Uh, nee?

Als je een salt toevoegt aan het wachtwoord van de user zijn rainbow tables juist nutteloos. Het wachtwoord 'test' krijgt met de salt een andere MD5 hash (oid) dan de 'test' zonder salt. Alle rainbow tabels zijn gemaakt voor passwords zonder salt.

Een rainbow table is gewoon een database met miljoenen veelvoorkomende woorden/paswords + hun hashes (in MD5/SHA1/etc). Daarmee is er relatief snel (binnen 30 seconden) te kijken wat voor wachtwoord bij welke hash hoort.

Wordt er een salt toegevoegd bij het aanmaken van user? => rainbow useless.
Sterk wachtwoord? => rainbow useless.

En het type database doet er ook geenzins toe (wat betreft salts dan). Wat er wel toe doet is de gebruikte hashingmethode.

[Reactie gewijzigd door Clock op 12 april 2011 15:11]

Volgens ComputerWorld had een door Barracuda zelf ontwikkelde firewall de server tegen dit soort aanvallen moeten beschermen, maar was die op het moment van de aanval offline voor onderhoud.
Dat klinkt erg ongeloofwaardig en is volgens mij meer een poging om imago-schade te voorkomen. Pijnlijke situatie, net zoals de hacks bij Kaspersky. Bij dergelijke partijen is het extra genant als ze slachtoffer worden van iets waartegen ze ons zouden moeten beschermen met hun vaak kostbare oplossingen.
Mjah, ik werk voor een MKB bedrijf (stuk of 20 servers en 100mbit avg) en wij hebben onze firewall in active-failover.
Was te duur denk ik voor Barracuda :)
even je naam settelen in de datacom wereld maar erg onvoorzichtig om je firewall down te gooien voor maintanence en de datacommunicatie door te laten gaan.

maar tja iedereen leert ook van die hackes gelukkig gebeurt het nu bij een die hard comm bedrijf dan weet iedereen nog dat we een lange weg te gaan hebben. en dat het minder veilig is dan we ook maar denken dat het is aan de internet kabel. O-)
Dit is niet echt goed te noemen. Het feit dat je firewall offline is, ondanks dat ze zelf redundantie , load balancing aparaten verkopen. Hoe kan zoiets überhaut offline gaan. En dan als het offline gaat, waarom is dan niet al het verkeer geblokkeerd.

Zo gaan ze geen brokken maken met hun nieuwe NG Firewall solutions. Barracuda heeft een goede spamfilter, maar de rest kan soms wel eens tegenvallen. Waaronder hun NG Firewall, mooi aparaat, zolang je in de GUI kan blijven, eens het spannend en wat exotischer word, kan je maar hopen dat je het in orde krijgt...
Programmeer fouten in een website zijn snel gemaakt. Ik vind het meer een taak van de webserver en een IDS om het gros van dit soort aanvallen tegen te houden.

Er zijn twee gratis Linux producten die een website perfect "out-of-the-box" kunnen beschermen tegen SQL injecties, CRSF, XSS en dergelijke aanvallen zonder de nodige security plugins in een cms/php framework:

- De Hiawatha webserver - http://www.hiawatha-webserver.org/
- Het Suricata IDS - http://www.openinfosecfou...dex.php/download-suricata
Ik begrijp nooit zo goed wat die hackers hier nou mee willen berijken zoek een baan en ga werken ipv, bedrijfen lastig vallen
Nou misschien laten zien dat er een lek is en zorgen dat het bedrijf het ook fixt. Als ze er geen melding van krijgen doen ze ook niks aan. Je hebt ook minder liefe hackers die dingen vernielen of jatten.
Je kunt het ook omdraaien: practice what you preach voor Barracuda. Ik ga toch ook niet klagen in het oerwoud over hoe gemeen de natuur is...
Ik denk dat hacken ook is op basis van prestige, iets proberen wat nog niet iemand is gelukt.

Het is een uitdaging, net zoals sporten proberen mensen beter te worden.
Ik denk dat het los staat van een baan, waarschijnlijk hebben de meeste hackers ook wel een baan gok ik.

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