Opnieuw Comodo-reseller gehackt

Een Comodo-reseller is getroffen door een hackaanval via sql-injection. Het is de vierde keer dit jaar dat een Comodo-reseller is gehackt. Bij één aanval werden frauduleuze ssl-certificaten uitgegeven; dit keer gebeurde dat niet.

Een hacker is erin geslaagd om persoonsgegevens buit te maken die waren opgeslagen in de database van ComodoBR, een Braziliaanse reseller van Comodo. Hij of zij kreeg de gegevens in handen dankzij sql injection, waarbij een verzoek aan een mysql-database wordt gemanipuleerd om eigen requests uit te voeren. Een gedeeltelijke dump van de database is op Pastebin geplaatst.

In de dump zijn onder andere e-mailadressen, gebruikersnamen en hashes van wachtwoorden te zien. Ook bevat de dump informatie over ondertekende ssl-certificaten. Voor zover bekend is de hacker er niet in geslaagd om ssl-certificaten te genereren met de bemachtigde informatie, zoals eerder bij een andere Comodo-reseller wel gebeurde.

Het is de vierde keer dit jaar dat Comodo, een beveiligingsbedrijf dat ssl-certificaten en beveiligingssoftware aanbiedt, een van zijn resellers gehackt ziet worden. De ceo van Comodo maakt zich geen zorgen, zo meldt The Register; in een e-mail schreef Melih Abdulhayoglu dat er 'niets te rapporteren' viel en dat het om een 'vrij gebruikelijke' sql-aanval gaat.

Reacties (37)

[Verwijderd]

Nu ken ik weinig van MySQL, maar is het dan zo makkelijk om een SQL injection te doen? De laatste tijd hoor je niet anders meer in de media...

[Little Penguin]

Als je de code goed schrijft dat is het vrijwel onmogelijk om SQL-injecties uit te voeren. Wat er echter vaak gebeurt dat is dat er simpelweg strings bij elkaar opgeteld worden.

Iets van: query = "SELECT * FROM USERS WHERE USERNAME = " + $_POST['username'] + " AND PASSWORD_HASH = " + $passwordhash.

Via de username kun je dan SQL binnenloodsen...

[Verwijderd]

SELECT * FROM USERS WHERE USERNAME = "$_POST['user]" AND PASSWORD = "$_POST['pass']";

$user = " ' ' OR 1=1";
$password = " ' ' OR 1=1";

[alopex]

@anvar :

Er bestaat zelfs een Wikipedia pagina over SQL-injectie :
http://nl.wikipedia.org/wiki/SQL-injectie

Op die pagina wordt ook uitgelegd dat je bij (php) scripts, die informatie opvragen uit een MySQL-database het best kunt beveiligen door alle input van de gebruikers door volgende functie te halen :
mysql_real_escape_string($input)

Verder vind ik het ook slordig dat webdevelopers van nota bene een beveiligingswebsite deze functie niet gebruiken in hun scripts.

[Verwijderd]

En toch zou het gebruik van deze functie niets uitgemaakt hebben..

Boven in de pastebin informatie is te zien dat de volgende SQLi gebruikt is:
compra_codesigning.php?prod=8 UNION ALL SELECT 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 -- -

Hier komt geen enkele quote in voor. Deze functie alleen is dus niet genoeg om injectie tegen te gaan.

zie ook:
http://www.pfz.nl/archief/1309411-mysql-real-escape-string-niet-genoeg-tegen-injectie/

[Ellos]

Dat toch zeker dat soort bedrijven hun beveiliging niet op orde hebben, ook al zijn het resellers, is toch wel triest.

zij moeten ssl certificaten uitgeven en goedkeuren en kunnen zelf nog niet eens een sql-injectie veilige site maken, wonderbaarlijk.

[kevinr1]

Inderdaad, hoeveelste keer bij hun is dat al gebeurd!?
4de keer nu, komt wel erg in strijd met hun slogan:
'Creating Trust Online'.

Ik vind het maar triest ...

[wildhagen]

Het is dus niet bij Comodo gebeurd, maar bij een reseller van hen. Dat is dus gewoon een losstaand bedrijf dat verder niets met Comodo te maken heeft, behalve dat ze Comodo-produkten verkopen.

[c-mattic]

Daar heb je wel gelijk, maar toch schaadt het de reputatie van het merk Comodo.

De hedendaagse consument denkt niet zo ver en wil dit ook niet doen. Onze hersenen moeten al genoeg informatie verwerken. We maken waarschijnlijk op één dag evenveel keuzes dan een holbewoner tijdens zijn hele leven moest doen.
Daarbij zien wij onbewust de reseller deels als een vermenselijking van het merk dat we overwegen, hier Comodo.
Als jij onrespectvol wordt bediend door een garage die merk X verkoopt, zal je onbewust een negatief gevoel linken aan merk X. Zelfs al is de garage maar een reseller...

Als ze bij Comodo een beetje gezond verstand hebben, zouden ze dit beter aanpakken.
Wie zou nu bij Comodo veiligheidsproducten en diensten willen aankopen als hun eigen reseller zich zelf niet kunnen beveiligen?

[Verwijderd]

Het is wel degelijk de schuld van Comodo. Comodo zou audits moeten uitvoeren of laten uitvoeren bij de websites van hun resellers. Totdat alles in orde is kunnen er geen certificaten worden besteld - punt.

Zo werkt het ook met de ideal betalingen, je kan ideal installeren op je site, je krijgt toegang tot een dummy omgeving en wanneer alles in orde is krijg je pas toegang tot het echte systeem.

Ze laten dit zelf gebeuren, ze zouden kunnen investeren in de beveiliging van hun resellers, althans de detectie van problemen om te voorkomen dat hun naam beschadigd. Wij hebben hier in het bedrijf alle Comodo certificaten al gedumpt en vervangen door certificaten van een ander merk. Deze hacks ondermijnen het doel namelijk van een certificaat, het kunnen vertrouwen in de echtheid van een server. Comodo claimde de vorige keer dat er slechts een x aantal certificaten waren gemaakt. Dat valt dus niet te bewijzen, ze kunnen claimen wat ze willen. Dat zullen ze ook doen immers bij wijze van spreke kunnen certificaten van miljoenen servers uitgegeven zijn, dat gaan ze ons dan nooit vertellen, dan kunnen ze de tent sluiten.

P.S.: Wel héél amateuristisch van opzet, een site die gevoelig is voor SQL injectie, zeker omdat het een bedrijf is dat handelt in 'veiligheid'.

@ Kurai Hoshi: Prima, bedankt voor de aanvulling, voorbeeld is hetzelfde.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:41]

[Kurai Hoshi]

iDeal controleert niet of je webshop lek is of niet, die controleert enkel of de betalingen goed over en weer gaan.

[Verwijderd]

Wie weet hanteert Comodo deze wijze ook juist, maar hebben de betreffende resellers wijzigingen "NA" de tests uitgevoerd en/of zijn ze compleet overgestapt op andere front- en/of backends waarna achteraf toch lekken aanwezig bleken te zijn?!.

iDeal test overigens alleen de transacties zoals Kurai Hoshi al aangeeft, niet of een website lek is of niet.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:41]

[BeosBeing]

Als jij onrespectvol wordt bediend door een garage die merk X verkoopt, zal je onbewust een negatief gevoel linken aan merk X. Zelfs al is de garage maar een reseller...

De eeuwige autovergelijking, maar goed:
Als de auto steengoed is, dan weet de klant best dat onderschijd te maken.
(Nikon was ook begin jaren 90 ook steengoed, maar de importeur hier behandelde de proffesionele gebruikers als onbelangerijke lastposten waardoor die massaal overstapten op Canon. Pentax camera's zijn sinds de K10 uit 1996 ook steengoed maar in de Benelux bakt de importeur er niets van, gevolg ze liggen bijna nergens in de winkel)

In bepaalde gebieden, zoals de randstad ga je dan naar een andere garage van dat merk, die zit dichtbij genoeg. Als er in jou regio geen andere garage van jouw merk zit, dan wordt dat moeilijker. En als die garage deel uitmaakt van een bedrijf dat meerdere garages heeft in jouw regio, voor verschillende merken, en bij allemaal wordt je arrogant behandeld omdat men weet dat je toch nergens anders heen kunt gaan, dan ga je vanzelf dat merk/die merken vermijden.

Maar als diezelfde arrogante garage dan ook nog reparaties slecht uitvoert, dan heeft dat ook zijn weerslag op het merk zelf.

Als ze bij Comodo een beetje gezond verstand hebben, zouden ze dit beter aanpakken.
Wie zou nu bij Comodo veiligheidsproducten en diensten willen aankopen als hun eigen reseller zich zelf niet kunnen beveiligen?

Ik zou mischien best producten van Comodo willen gebruiken, maar ze zeker niet bij die reseller halen. Het is ook welke relatie er is tussen maker en verkoper.Als die verkoper een door de maker geselecteerde verkoper is, dan zou je verwachten dat de maker ondersteuning geeft aan die verkoper voor de beveiliging, maar bv bij iedere computerboer om de hoek kun je de Internet-security-pakketten kopen van Norton, McAffee e.d. en zij kopen die bij een groothandel die het koopt bij een importeur die het betrekt van de makers in de USA. De makers hebben daar geen enkele relatie met die verkoper.

Het zou trouwens erger zijn als inderdaad de makers zelf gehackt zouden zijn (is dacht ik bij McAffee een keer gebeurt).

[Verwijderd]

Het is dus niet bij Comodo gebeurd, maar bij een reseller van hen. Dat is dus gewoon een losstaand bedrijf dat verder niets met Comodo te maken heeft, behalve dat ze Comodo-produkten verkopen.

Comodo verkoopt ssl certificaten. Je business is cerificaten die vallen of staan bij security.
Als je deze niet op orde hebt kun je de toko wel sluiten. Ik zou nooit een cerificaat bij Comodo kopen.


nieuws: Comodo geeft frauduleuze ssl-certificaten uit na hack

Als de beveiliging niet te garanderen is bij de reseller zouden ze reseller kunnen verplichten om door te linken naar de officiële Comodo site.

[ASS-Ware]

Comodo verkoopt ssl certificaten. Je business is cerificaten die vallen of staan bij security.
Als je deze niet op orde hebt kun je de toko wel sluiten. Ik zou nooit een cerificaat bij Comodo kopen.

Waarom niet ?
Stel dat een inbreker zelf certificaten aan kan maken en daar onwelriekende zaken mee uit kan voeren, dan zou dat nog geen invloed hebben op certificaten die jij bij Comodo koopt.
Ik zie geen reden om daar geen certificaten aan te schaffen.

[Verwijderd]

Iedereen kan zelf certificaten aanmaken! Dat is het hele idee ervan.

Ik heb zelf certificaten op mijn NAS; voor alles wat https gebruikt wordt een certificaat gebruikt.

Https heeft twee (hoofd) doelen;
-> Versleutelen; afluisteraars blokken
-> Identiteit garanderen (van de site)

Als jij alleen wil versleutelen, en afluisteraars zo wil blokkeren, heb je geen (geldig) certificaat nodig. Je kan er zelf eentje maken, en je bent klaar.

Als jij je als site ook wil kunnen "identificeren" (handig, dit is echt een must voor alles waar geld mee gemoeid is), dan moet een gerespecteerd bedrijf jou controleren. Comodo is een van die bedrijven.

Comodo heeft (simpel gezegd) een lange lijst van certificaten waarvan zij de juistheid hebben gecontroleerd. Als jij dan https://mijn.ing.nl bezoekt, wordt het certificaat dat ing verstuurd even gevalideerd bij Comodo.
Als dit klopt, ga je rustig door en merk je er niets van.
Als het niet klopt, krijg je een melding, zie pic;
http://saucelabs.com/blog...ads/2010/01/Picture-8.png

Als mensen zomaar naar hartelust zelf dingen aan Comodo's lijstje kunnen toevoegen, dan heeft Comodo geen toegevoegde waarde. Iedere crimineel kan zichzelf toevoegen, dus als https://mijn.ing.nl het certificaat van een crimineel verstuurd heeft jouw browser dat niet meer door.

Comodo loopt dus het risico dat ze uit het groepje van "betrouwbare lijstjes" worden gegooid. Dat zou het einde van het bedrijf betekenen.
(note; ze zullen echt niet direct gekickt worden, maar ze moeten dit niet te vaak flikken)

[ASS-Ware]

Als jij je als site ook wil kunnen "identificeren" (handig, dit is echt een must voor alles waar geld mee gemoeid is), dan moet een gerespecteerd bedrijf jou controleren. Comodo is een van die bedrijven.

Klopt, en dat doen ze bij de aanvraag van het certificaat.

Als jij dan https://mijn.ing.nl bezoekt, wordt het certificaat dat ing verstuurd even gevalideerd bij Comodo.

Dat is niet waar.

Als het niet klopt, krijg je een melding, zie pic;
http://saucelabs.com/blog...ads/2010/01/Picture-8.png

Nee, dat is een melding dat je een certificaat krijgt waarvan de DNS naam niet overeenkomt met de DNS naam van de website die je bezoekt, of het certificaat is niet van een trusted partij, maar dat hoeft ie niet bij Comodo te checken.
De browser weet zelf welke partijen wel trusted zijn.

[Verwijderd]

Het is niet de schuld van Comodo, en ik vind dan ook niet dat ze echt aansprakelijk zijn voor de slecht beveiligde website van een reseller.

Als er bij een slotenwinkel wat wordt gestolen omdat de deur open staat, wil toch ook niet meteen zeggen dat de fabrikant van het slot in de deur van de slotenwinkel schuldig is.

Wel zou Comodo hogere eisen kunnen stellen aan websites van resellers, omdat hun naam er nu toch indirect mee in verband wordt gebracht.

[Thomaster94]

SQL-injection? Tegenwoordig leer je volgens mij bij elke basiscursus server-side programming (bijv. php / asp) of databases hoe je dit kunt voorkomen. Verbazend dat er zoveel webdesign-bedrijven lijken te zijn die dit aan hun laars lappen...

[Firelock]

Ik krijg het nu in me eerste jaar applicatieontwikkelaar opleiding.

Wel faal dit. En dan nog zeggen dat het dood normaal is.

[dusti]

een beperking op het aantal tekens die in een veld van een form kan ingegeven worden helpt ook al, gezien je daardoor onvoldoende tekens hebt om dergelijke querries uit te voeren, los van het gebruik van mysql_real_escape_string($input) en dergelijke functies

bv: <input type="text" name="UsEr" maxlength="25" value="">

verder ontopic, ik begrijp niet dat er nog steeds sql-injections voorkomen.
Blijkbaar staat de database-connectie bij veel bedrijven gewoon open zonder dat ze het zelf door hebben of zonder dat ze erbij stil gestaan hebben. Je laat je voordeur toch ook niet open als er iemand in je huis moet zijn? dan geef je een sleutel, als je die persoon vertrouwt

En zoals anderen aangeven, erg veel vertrouwen zou ik ook niet meer hebben in comodo als die maar zo laks omspringen met hun beveiliging. Dat het 1x gebeurd is kan wel goed en wel, maar nu de 4de keer en telkens bij de resellers geeft toch vragen bij de kwaliteit van de resellers. Ik had op z'n minst alle resellers aan een audit onderworpen na de eerste injection.

[Reactie gewijzigd door dusti op 23 juli 2024 06:41]

[Clock]

Het cliënt-side controleren en afdwingen van de maximale lengte heeft 0,0 effect. Dat kan met elke browser+webdev plugin omzeild worden. Daarnaast beperk je je gebruikers onnodig (waarom geen username langer dan 25 tekens toestaan?).

De oplossing ligt in het server-side sanitizen van _alle_ data die door de user beinvloedbaar is voor je het gebruikt in een query. Daarbij horen dus ook dingen als het ip adres van de cliënt uit de $_SERVER[] array in PHP (is spoofbaar).

[EricJH]

On a not unimportant side note. Check dit lijstje eens uit van digitaal ondertekende malware: http://www.ccssforum.org/malware-certificates.php .

De grote namen Verisgn, Thawate en Geotrust duiken hier op. Alledrie in handen van Symantec dezer dagen en de virii worden allemaal door Symantec gedetecteerd.....

Zijn er nog CA's die wel te vertrouwen zijn?

[arjankoole]

Iedere halve zool kan zo'n certificaat aanvragen.

Bovendien is het ook regelmatig zo dat een virus gesigned wordt met een certificaat wat gestolen is bij een software maker. Dat certificaat moet dan revoked worden, maar dat vergeten een hoop mensen geloof ik.

CA's zijn prima te vertrouwen, of Certificaten te vertrouwen zijn? Dat moet je voor jezelf uitmaken.

[cyberstalker]

Waar ik met mijn hoofd niet bij kan is dat er anno 2011 nog steeds beveiligingsbedrijven zijn die kwetsbaar zijn voor sql-injection.

Juist voor een systeem dat veilig moet zijn kies je toch voor stored procedures waarbij je rechtstreekse toegang tot de datatabellen niet toestaat? Of tenminste voor prepared statements.

[PiepPiep]

Abdulhayoglu dat er 'niets te rapporteren' viel en dat het om een 'vrij gebruikelijke' sql-aanval gaat.

Zeker voor een beveiligingsbedrijf vind ik het dan erg kwalijk dat een vrij gebruikelijke aanval gewoon bij hun werkt. Je zou haast verwachten dat zo'n bedrijf iets van beveiliging zou moeten weten.

[Verwijderd]

Haha LOL, ik dacht exact hetzelfde. En de mailadressen en usernames liggen toch mooi op straat...

[Kurgan]

Spreekt meneer Abdulhayoglu zichzelf niet een beetje tegen? Als het om een "vrij gebruikelijke" sql-aanval gaat dan zou dat toch allang afgeschermd en dichtgetimmerd moeten zijn? Dus ofwel het ging hier niet om een "vrij gebruikelijke" aanval, ofwel men heeft de beveiliging niet op orde - en ik gok op het laatste.

[RHochstenbach]

Zulke bedrijven moeten eigenlijk veiligheidseisen stellen aan hun resellers (en dus ook actief controleren). Anders kan je als reseller gewoon een publieke self-service website maken waarbij iedereen zichzelf kan bedienen....

[totaalgeenhard]

Ik vraag me af wat Comodo gaat doen zodra er in Turkije demonstraties zijn.

Zou mij niets verbazen als ze dan zelf certificaten aan Turkse overheid verstrekken om login voor socialnetworks te kunnen afvangen.

Hiermee niet implicerend dat Amerikaanse bedrijven hun overheid NIET helpen.

[Plofkotje]

En het verband van deze mening met dit nieuwsartikel?