Comment faut-il juger les cybercriminels ? Un hacker condamné à 20 ans de prison pour vol de données

[Katleen Erna]

Mise à jour du 29.03.2010 par Katleen

Comment faut-il juger les cybercriminels ? Un hacker condamné à 20 ans de prison pour vol de données

Après une délibération longue, c'est un verdict lourd qui a été rendu avec plusieurs mois de retards sur la date annoncée en début de procès.

Rappelez-vous, fin 2009, nous vous avions parlé d'Albert Gonzalez, ce pirate qui avait dérobé plus de 130 millions de numéros de cartes de crédit.

Lors de son procès, il avait finalement décidé de plaider coupable.

Le pirate de 28 ans était inquiet de la sentence qui l'attendait, mais s'attendait-il à une peine aussi lourde ?

Jeudi, il a été condamné par un tribunal de Boston (Massachussets) à vingt ans de prison.

C'est la peine la plus lourde jamais prononcée pour du piratage de données

L'homme de 28 ans ne s'est pas arrêté en si bon chemin, et il devra comparaitre en fin de semaine pour les chefs d'accusation de complot, fraude informatique et vol d'identité pour d'autres actes de piratage.

Sa peine pourrait ainsi se rallonger de 5 ans.

La justice américaine a voulu faire de ce cas un exemple, comme l'a expliqué la juge Patti Saris : «Même si vous éprouvez des remords (...), je dois lancer un message, vu l'énorme coût de votre délit».

Albert Gonzales avait de plus dissimulé un million de dollars dans le jardin de ses parents. Somme qu'il a restituée aux autorités pour rembourser une partie de ses victimes.

Gonzales souhaitait mettre 15 millions de dollars de côté, s'acheter un yacht, et prendre sa retraite. Il va la prendre, c'est sûr, mais à l'ombre.

Mise à jour du 14/09/09

Vol de 130 millions de cartes bleues : Albert Gonzalez reconnait les faits

Après avoir annoncé qu'il allait plaider coupable, Albert Gonzalez vient de reconnaitre les faits qui lui sont reprochés, ce Vendredi, devant une Cour du District de Boston.

Il a également apporté des précisions sur son mode opératoire (confirmant ainsi les news précédentes cf. ci-dessous).

Accusé du plus grand vol de numéros de CB de l'histoire de l'informatique, le forfait remonte à 2003. Depuis cette date, Albert Gonzalez a admis avoir revendu ces listings puis placé cet argent sur des comptes bancaires en Lettonie.

Le Hacker encours aujourd'hui une peine de 25 ans de prison et une amende de 1,65 millions de dollars. Tout ses biens peuvent être saisis pour payer cette dette.

Son avocat a déclaré à la presse que l'accusé se sentait "vraiment mal".

Le verdict est prévu pour le 8 Décembre 2009.

MAJ par Gordon Fowler.



Mise à jour du 31/08/09

Vol de 130 millions de cartes bleues : Albert Gonzalez plaide coupable

Le responsable du plus important vol de numéros de cartes bleues de l'Histoire de l'informatique a annoncé qu'il plaiderait coupable.

Albert Gonzales, hacker reconnu, avait été engagé par les services secrets américains avant d'être démasqué comme "agent double.

Suite à ce "au plaidoyer de marchandage" (plea bargain) avec le procureur, le présumé cerveau de l'escroquerie réalisée par injection SQL (cf. plus bas, news précédente) encourt désormais une peine de prison diminuée allant de 15 à 25 ans.

Il devra par ailleurs payer 2,8 millions de dollars en liquide, vendre un appartement à Miami, sa voiture et un montant non précisé de bijoux pour s'acquitter de l'amende liée à son forfait.

MAJ par Gordon Fowler



Hacking : des attaques par injection SQL permettent à trois américains de voler plus de 130 millions de numéros de cartes bleues. Comment contrer ces attaques ?

Un habitant de Miami âgé de 28 ans, Albert Gonzalez, ainsi que ses deux comparses d'origine russe ont été accusés aujourd'hui par les Services Secrets du New Jersey de ce que les journaux U.S. désignent déjà comme le plus grand vol de données de l'histoire américaine.

Les trois hommes ont en effet réalisé une attaque à grand échelle. Ils ont en tout mis la main sur plus de 130 millions de numéros de cartes bancaires, ainsi que sur les informations personnelles d'identification des propriétaires qui y étaient associées.

L'américain et les deux russes opéraient depuis octobre 2006 avec une technique bien rôdée : une attaque par injection SQL qui leur permettait de voler les informations désirées en contournant le pare-feu du réseau visé. Ils envoyaient ensuite les données volées sur des serveurs aux Pays-Bas et en Ukraine et effaçaient leurs traces.

Une injection SQL est un type d'attaque ciblant les applications fonctionnant avec une base de données relationnelle. Le pirate injecte une requête SQL imprévue dans le système et exploite les failles générées par cette action.

En effet, pour les sites fonctionnant de cette manière, les paramètres sont annoncés à la base de donnée sous la forme de requêtes SQL. Vous comprendrez alors aisément que si l'administration du site ne contrôle ni ne verouille les paramètres ainsi envoyés, un pirate pourra aisément compromettre la base de données, y accédant par l'envoi de ses propres requêtes falacieuses.

Par exemple, certains caractères permettent d'éxécuter plusieurs requêtes à la suite, tandis que d'autres (par exemple, l'apostrophe) forcent à ignorer la suite de la requête. De cette manière, un hacker peut lancer presque n'importe quelle requête de son cru.

Les autorités locales se félicitent d'avoir appréhendé les trois pirates -malgré les protections sophistiquées qu'ils avaient utilisées pour dissimuler leurs identités- ce qui couronne leurs efforts pour poursuivre de manière individuelle les personnes sévissant de cette manière dans le "grand banditisme électronique". La justice américaine à ici fait preuve d'une grande diplomatie pour travailler conjointement avec ses homologues étrangers dans ce cas d'envergure internationale.

L'entreprise ayant subit le plus gros préjudice dans cette affaire est Heartland Payment Systems à qui les pirates ont volé plus de 100 millions de numéros de cartes de crédit. Ont aussi été mises à mal 7-Eleven Inc. (chaîne de magasins nationale basée au Texas, 4.2 millions de numéros volés) et Hannaford Brothers (chaîne de supermarchés ayant son siège dans le Maine). Les noms des deux autres compagnies victimes de cette fraude n'ont pas encore été rendus publiques.

S'ils sont reconnus coupables, les trois compères risquent jusqu'à 25 ans de réclusion criminelle ainsi qu'une amende de plus de 500.000 dollars chacun.

Mais ce n'est pas tout pour Gonzalez, récidiviste arrêté une première fois en 2003 pour fraude à la carte bancaire, qui sera également jugé en septembre 2009 ainsi qu'à l'automne 2010 pour d'autres braquages électroniques (vol de données des compagnies TJX Companies, Dave & Busters, BJ's Wholesale Club, OfficeMax, Boston Market, Barnes & Noble, Sports Authority, Forever 21 et DSW).

Source : Communiqué du Ministère de la Justice des Etats-Unis

Comment éviter une attaque par injection SQL ? Utiliser des comptes utilisateurs SQL à accès limité (en lecture-seule) et des requêtes SQL préparées (requêtes à trous envoyées au serveur SQL, serveur à qui l'on envoie par la suite les paramètres qui boucheront les trous) est-il suffisant ?

Avec tous les moyens de protection actuels, est-il normal que de telles attaques soient encore réalisables ?

[Halleck]

Je serai curieux de savoir comment ils ont été retrouvés. 130 milliosn, c'est n'importe quoi, quelques centaines suffisent non ?

Avec tous les moyens de protection actuels, est-il normal que de telles attaques soient encore réalisables ?

Oui il y a toujours des failles, la priorité d'un site n'est pas toujours la sécurité. C'est "normal" je trouve que des sites soient piratables, par contre ça l'est moins quand ils contiennent des données sensibles

Et sur toutes ces cartes, combien ils en avaient exploité ?

[Floréal]

Sur chacun des comptes reliés à ces cartes de crédits tu prend une petite somme même imperceptible, de l'ordre du centime, calcules combien tu empoches. C'est là l'intérêt que je vois à pirater 130 000 000 numéros de Carte bancaires.
Sinon ils ont beau avoir le super firewall de la mort qui tue la vie, si les codeurs n'ont pas pris les bonnes dispositions pour sécuriser correctement le site, ça ne sert à rien.

[Valère]

L'intérêt principal de ce type de vol de numéros de cartes bancaires, ce n'est pas de les utiliser soit même, mais bien de les revendre.

[Lyche]

Sur un forum d'informatique on devrait plus se soucier de "comment est-il possible de laisser de telles failles de sécurité quand on a à charge des données aussi sensible que des Numéros de carte de crédit"
Sérieusement. Je travail dans une banque et la plus petite application est protégé, au minimum contre les SQL Injection.
Ça m'insupporte plus que tout de voir que des entreprises de cette taille et de cette importance négligent totalement la sécurité et acceptent des développeurs qui ne soient pas capable de maitriser cette sécurité.. c'est le B A BA de l'intranet/internet que de protéger son site contre ce type d'attaque.. Si encore c'était récent

[Inazo]

Bonjour à tous,

En effet voir des sites contenant des données très très sensibles vulnérable à des failles d'injection SQL... C'est une honte... Ce qui m'attriste le plus c'est que se genre d'attaque et plus que courante et que je n'ai pas l'impression que cela affole les gens, la sécurité étant la dernière choses qui préoccupe 98 % de mes clients...

Par contre :

tandis que d'autres (par exemple, l'apostrophe) forcent à ignorer la suite de la requête.

L'apostrophe ne sert pas à ignorer la suite de la requête, cela va dépendre du SGBDR et bien souvent on utilise des "--" ou des "/*", chacun ayant ça spécification.

L'apostrophe sert plus à casser, et encore pas toujours, la zone de valeur pour un champ dans une clause de la requête, par moment un simple espace suffit pour avoir le même résultat. Et ainsi permettre de rajouter des conditions dans une requêtes tel que OR 1=1 pour lister toutes les valeurs ce qui peut produire des mini DoS, mais qui en multithread pourrait être douloureux ^^.

Cordialement,

[Bart-Rennes]

Mais pourquoi les boutiques stockent les numéros de cartes ! là j'ai du mal à comprendre, on effectue la transaction de paiement, c'est validé, terminé on supprime le numéro de carte bancaire. Pourquoi la stocker !

[Inazo]

Pourquoi le stocker ?

C'est une excellente question, pour ma part la seul raison et que l'on cherche les ennuies ou que l'on est très sûr de son système de sécurité, vraiment très très sûr... Exemple Nierle.com qui il y a quelques années avait connu un sort identique.

De plus si un site stock vos numéro de CB il doit de manière ostensible vous le signaler.

Enfin certain site tel qu'Amazone stock vos numéro de CB mais j'ose croire, pas forcément avec raison, qu'Amazone a une sécurité digne de ce nom pour éviter se genre de déconvenue.

Cordialement,

[LittleBean]

Sur une forum d'informatique on devrait plus se soucier de "comment est-il possible de laisser de telles failles de sécurité quand on a à charge des données aussi sensible que des Numéros de carte de crédit"
Sérieusement. Je travail dans une banque et la plus petite application est protégé, au minimum contre les SQL Injection.

Peut être que si les grands organisme ne prestarisaient pas tant leurs applications, ils y aurait moins de soucis .... ou du moins plus de compétance dans ce domaine

acceptent des développeurs qui ne soient pas capable de maitriser cette sécurité.

Ce n'est pas toujours la faut des dev mais bien souvent de leurs chefs ..... tu chiffre une fonctionnalité à 5J on te dis de la faire en 2J, les trois critéres qui y perdent sont maintenabilité, sécurité et performance ...

L'intérêt principal de ce type de vol de numéros de cartes bancaires, ce n'est pas de les utiliser soit même, mais bien de les revendre.

+1

Mais pourquoi les boutiques stockent les numéros de cartes ! là j'ai du mal à comprendre, on effectue la transaction de paiement, c'est validé, terminé on supprime le numéro de carte bancaire. Pourquoi la stocker !

Il est courant aux states de payer à crédit, pour cela les grands magasins ont besoin de garder les références bancaires de leurs clients(je suppose).

[Inazo]

En France on peut ajouter des modules de paiement a crédit je pense que se genre de solution a été développé aussi aux USA. Voir nous vient directement de chez eux.

Cordialement,

[Valère]

Envoyé par Bart-Rennes

Mais pourquoi les boutiques stockent les numéros de cartes ! là j'ai du mal à comprendre, on effectue la transaction de paiement, c'est validé, terminé on supprime le numéro de carte bancaire. Pourquoi la stocker !

La boite Heartland Payment Systems sur laquelle ont été piqués le plus grand nombre de carte de crédit est visiblement un organisme de services bancaires...

La honte!

[Lyche]

Envoyé par LittleBean

Ce n'est pas toujours la faut des dev mais bien souvent de leurs chefs ..... tu chiffre une fonctionnalité à 5J on te dis de la faire en 2J, les trois critéres qui y perdent sont maintenabilité, sécurité et performance ...

Je travaille dans le secteur bancaire, et je ne suis pas employé par la banque, je suis un "sous traitant" et une chose est sure, je ne rendrais jamais un travail dont le système de sécurité est bâclé. Si mon client me dit "on a 2 jours pour faire ça" je lui répondrais toujours, "oui, 2 jours pour les fonctionnalités + 1 pour le système de cryptage et de sécurisation de l'appli".
C'est non négociable et quand tu expliques pourquoi tu rajoutes 1 jour de délai, il te dit merci.
Bien entendu, la compétence ne se qualifie pas uniquement dans la capacité à coder une programme, c'est aussi arriver à montrer pourquoi il est important de faire telle ou telle chose. Et surtout, montrer que sans lui le travail ne se fera pas et qu'il ne faut rien négliger quand on développe une application.

[publicStaticVoidMain]

http://tv.lepost.fr/2009/08/18/16606...s-aux-usa.html

[LittleBean]

Je travail dans le secteur bancaire, et je ne suis pas employé par la banque, je suis un "sous traitant" et une chose est sure, je ...

Bien entendu, la compétence ...

Je ne comprends pas vraiment ta réaction, je n'ai jamais mis en doute ta compétence

Mais simplement qu'il arrive que :

Si mon client me dit "on a 2 jours pour faire ça" je lui répondrais toujours, "oui, 2 jours pour les fonctionnalités + 1 pour le système de cryptage et de sécurisation de l'appli".
C'est non négociable et quand tu expliques pourquoi tu rajoutes 1 jour de délai, il te dit merci.

- ou il te répond mais c'est vrais j'y avais pas pensé !!!
- alors j'ai bien les 3 jours ?
- bah non j'en ai que 2 de budget

Mon point de vue est simplement qu'il est réducteur de mettre en cause uniquement les développeurs, toute personne participant au cycle de vie du logiciel peut être source de faille.

[Lyche]

Envoyé par LittleBean

Je ne comprends pas vraiment ta réaction, je n'ai jamais mis en doute ta compétence

Je ne m'offusquais pas de ce que tu disais Je dis juste qu'il ne faut pas se laisser faire dans le métier ou l'on est expert. Qu'importe le budget, j'ai déjà refusé des projets parce que c'était voué à l'échec, que les budgets ne permettaient pas de faire tout ce qu'il fallait en temps impartis. Si d'autres n'ont pas l'honnêteté de dire à leur client que "c'est impossible" ou "si la sécurité du programme est remise en cause je dis non" c'est leur problème. Mais moi ce genre de comportement ça m'ulcère.
Je suis peut-être trop honnête ou crédule (je suis le genre de personne à dire à un commerçant qu'il me rend trop d'argent ou qu'il a oublié quelque chose sur la note ) Et je suis persuadé que l'honnêteté dans notre métier est primordiale. Autant pour la réputation du développeur (et pas uniquement la notre).
Met toi à la place de celui qui a développé le système qui s'est fait piraté par Injection SQL , déjà, celui qui va passer derrière pour récupérer ses conneries vas s'arracher les cheveux, ensuite, je me doute que son patron va pas lui faire de la bonne pub.. voir carrément le virer et je ne l'en blâmerais pas, parce qu'il n'a pas fait son métier. (Et ne me dites pas "c'est une question de budget") protéger une appli des attaques SQL c'est quand même pas ce qui prend le plus de temps dans une appli hein...

Tu ne vas pas apprendre à ton banquier à garder ton fric, c'est pareil pour nous. Notre métier c'est de faire des applications, et tout ce que comporte cette mission. ( Je reste très Candide de ce côté là, mais jusqu'ici, ça m'a toujours porté chance )

[Floréal]

Amen. Que dire de plus si ce n'est "+1"?

[Lyche]

Envoyé par Floréal

Amen. Que dire de plus si ce n'est "+1"?

ironique?

[Floréal]

Pas le moins du monde, je suis tout à fait d'accord avec toi, ce qui me vaut d'ailleurs quelques accrocs avec la gente commerciale.
Lorsqu'on commanditaire a des ambitions, j'estime qu'il est nécessaire que les moyens qu'il te donne soient à leur hauteur (des ambitions). Le hic c'est qu'un commercial, pour vendre cherchera, toujours à faire en sorte que les couts soient plus faible que ses concurrents, plutôt que justifier des couts plus élevés parce que la qualité (comprendre la réponse aux attentes du client) sera au rendez-vous.

[76317]

Mais bon pourquoi 130 millions alors que quelques cartes suffisent... mais bravo à eux ! pour l'exploit mais faut pas les utiliser hein les gars ?!! mais pas de bol pour les propriétaires des cartes !

[publicStaticVoidMain]

Envoyé par 76317

Mais bon pourquoi 130 millions alors que quelques cartes suffisent... mais bravo à eux ! pour l'exploit mais faut pas les utiliser hein les gars ?!! mais pas de bol pour les propriétaires des cartes !

T'as qu'a prendre 50 cents sur chacun et calcule le montant que ca fait