Depuis quelques jours circule un courriel semblant provenir de l'équipe technique Facebook. Mais sa pièce jointe n'est autre qu'une variante du downloader Bredolab, déjà connu pour installer d'autres logiciels malveillants (Waledac, Daurso, Koobface, etc).

Voici un exemple de message (que vous avez aussi certainement reçu) :

Le message fait croire à l'utilisateur que son mot de passe Facebook a été changé et que le nouveau est dans la pièce jointe (ici Facebook_Password_6dd19.zip). Celle-ci contient un simple fichier .exe qui se révèle bien entendu malveillant.

En analysant rapidement le malware, on se rend compte qu'il s'injecte dans des processus Windows, via la méthode classique OpenProcess/VirtualAllocEx/WriteProcessMemory/CreateRemoteThread :

Sur la figure ci-dessus, il demande un handle sur le processus 0x478 (explorer.exe sur notre système de test). Après avoir réalisé les appels à WriteProcessMemory pour recopier le code malveillant dans ce processus, le thread distant est ensuite créé :

Bredolab n'est qu'un downloader ; cet échantillon se connecte au domaine mmsfoundsystem[dot]ru par HTTP afin de télécharger et exécuter d'autres logiciels malveillants :

Afin d'assurer son lancement au prochain redémarrage, il se contente de se recopier dans le dossier Démarrage de l'utilisateur :

Comme indiqué dans un précédent billet, l'outil MSRT de Microsoft est documenté comme supportant Bredolab ; notre échantillon est effectivement détecté comme TrojanDownloader:Win32/Bredolab.X :

An email which seems to come from the Facebook team has been circulating for a few days. Its attachment is yet another variant of the Bredolab downloader, already known for installing other malware (Waledac, Daurso, Koobface, etc).

Here is an example (you are likely to have received it as well):

The attachment is a simple ZIP file (Facebook_Password_6dd19.zip in our example) and contains a malicious binary.

A quick analysis of the executable reveals that it injects itself into Windows processes, via the traditional OpenProcess/VirtualAllocEx/WriteProcessMemory/CreateRemoteThread method:

On the picture above, the binary asks for a handle on process 0x478 (explorer.exe on our test system). After calling WriteProcessMemory to copy its malicious code into this process, the remote thread is created:

Bredolab is only a downloader; this sample connects to the mmsfoundsystem[dot]ru domain via HTTP to download other malware:

To ensure it will run at startup, it simply drops itself in the user's Startup folder:

As said in a previous bulletin, the MSRT is documented as supporting Bredolab; indeed, our sample is detected as TrojanDownloader:Win32/Bredolab.X:

Il y a deux semaines, Microsoft a corrigé (Réf Lexsi 12420) une faille dévoilée à la Black Hat par Moxie MarlinSpike fin juillet concernant les certificats X.509 qui n'a pas obtenu une grande attention.

La faille en elle-même est triviale : la plupart des bibliothèques gérant les certificats X.509, telles que les bibliothèques NSS utilisées par Firefox ou encore la bibliothèque CryptoAPI présente dans Windows, ne tiennent pas compte de la possibilité d'insérer un caractère nul (\0) dans le champ CN (Common Name) d'un certificat X.509. Du coup, lors du traitement d'un certificat contenant ce caractère, l'affichage s'arrête à ce caractère nul. Par exemple, le champ CN « lexsi.com\0domainemalveillant.com » est vu comme « lexsi.com » par les programmes vulnérables.

Des certificats valides utilisant cette vulnérabilité ont même été publiés, l'un pour www.paypal.com et l'autre pour * (!).

Pourtant, Microsoft a donné un indice d'exploitabilité de 3 (= exploits fonctionnels peu probables).

Afin de comprendre pourquoi cet indice est si faible alors que « l'exploitabilité » a été démontrée à la BlackHat, voyons quels sont les pré-requis pour tirer partie de cette vulnérabilité.

Prenons le cas d'un attaquant qui souhaite déchiffrer le trafic échangé avec le site https://www.bienveillant.fr qui est authentifié et chiffré à l'aide du protocole SSL.

Coté client, le navigateur Internet vérifie 3 éléments pour authentifier un site utilisant SSL :

1. La date d'expiration du certificat
2. Le certificat est signé par une autorité de certification présente dans la liste des autorités de confiance embarquée dans chaque navigateur
3. Le nom de domaine est identique au champ CN du certificat

L'attaquant doit donc disposer d'un certificat valide pour le domaine www.bienveillant.fr. Il ne peut pas être auto-signé (condition 2) et il doit donc se le procurer auprès d'une autorité de certification. Seulement, cela n'est pas possible puisque lors de l'achat d'un tel certificat, l'autorité de certification va vérifier que le domaine appartient à l'attaquant.

C'est ici qu'intervient la vulnérabilité, puisqu'il est possible d'acheter un certificat www.bienveillant.fr\0malveillant.fr (en supposant que l'attaquant contrôle le domaine malveillant.fr).

Une fois en possession de ce certificat valide, l'attaquant met en place une page (redir.malveillant.fr) qui fait office de passerelle vers le site www.bienveillant.fr légitime, ceci dans le but que la victime ne se doute de rien pendant que ses paquets sont allègrement déchiffrés.

Reste cependant notre 3e condition, qui affiche un avertissement lorsque le contenu du champ CN (considéré ici comme étant www.bienveillant.fr) est différent de l'URL saisie par l'utilisateur.

L'attaquant doit donc se débrouiller (DNS Cache ou ARP Poisoning par exemple) pour que l'utilisateur soit dirigé vers l'adresse IP de redir.malveillant.fr lorsqu'il tape www.bienveillant.fr dans sa barre d'adresse.

C'est cette étape qui explique qu'une exploitation massive de cette vulnérabilité n'ait pas eu lieu en dépit des 2 mois et demi que Microsoft a pris pour la corriger. On comprend mieux également l'indice d'exploitabilité de 3.

Il faut non seulement créer un certificat spécifique à chaque cible, mais en plus se trouver en situation de "man-in-the-middle".

Par ailleurs, Microsoft indique s'être assuré que les autorités de certification présentes dans son navigateur n'acceptent plus le caractère nul dans les certificats qu'elles délivrent.

Mais qu'en est-il du certificat valide pour la wildcard « * » ?

En fait, Internet Explorer ne considère pas ce domaine comme valide, et on obtient tout de même un avertissement (ce qui est censé éveiller la méfiance de la victime).

Par contre, le navigateur de la fondation Mozilla n'émet aucune objection à ce joker et les versions inférieures à la 3.0.13 sont vulnérables à cette attaque sans que l'attaquant ait besoin de créer un certificat spécifique à sa victime.

La faille a été corrigée deux jours après la conférence dans le navigateur Firefox (version 3.0.13, la 3.5 n'étant pas vulnérable), début septembre par Opera (sortie de la version 10), et mi-octobre par Microsoft dans son bulletin MS09-056. Concernant Safari, la version Windows s'appuie sur la bibliothèque CryptoAPI de Microsoft et n'est donc pas vulnérable si le correctif MS09-056 est appliqué. De nombreux outils gérant des certificats ont également été corrigés (thunderbird, mutt, openldap, proftpd, wget, curl, fetchmail, neon, kdelibs, qt ...), et certains navigateurs mobiles (BlackBerry).

Cependant, et comme l'explique Moxie MarlinSpike, Firefox intègre un système de mise à jour automatique dans lequel toute la protection repose sur le site à partir duquel les mises à jour sont téléchargées. Et ce site est authentifié ... via SSL. Si les conditions d'exploitation sont réunies, on peut non seulement déchiffrer le trafic SSL, mais également installer ce que l'on veut sur la machine de la victime ! Au passage, on peut noter également la faille qu'il exploite dans le protocole OCSP afin d'empêcher la révocation de son certificat.

Nous finirons par Safari version Mac. Dans sa version actuelle (4.0.3) son comportement est différent des autres navigateurs (même non corrigés). En effet, ici le caractère nul est tout simplement ignoré. Notre certificat "www.bienveillant.fr\0malveillant.fr" est vu sur Safari comme étant pour le domaine www.bienveillant.frmalveillant.fr. Cependant, l'exemple donné lors de la présentation d'un certificat ayant pour champ CN "sitekey.ba\0nkofamerica.com" montre bien que l'exploitation est toujours possible, bien qu'avec plus de contraintes.

Cette faille permet bel et bien de déchiffrer du trafic SSL (forcément, puisque le certificat présenté à la victime nous appartient), et cela à son insu puisque tous les indicateurs habituels (cadenas, barre d'adresse verte ...) restent identiques. Le titre du billet n'est donc pas à prendre au pied de la lettre, la trouvaille (faite en parallèle par Dan Kaminsky) est belle.

Par contre, la nécessité de pouvoir réaliser une attaque de type "man-in-the-middle" est un frein relativement important à son exploitation massive. Le certificat pour paypal qui a été publié ne suffit donc pas à réaliser des phising à grande échelle. Reste que des attaques ciblées au sein de réseaux d'entreprises sont possibles ...

Les détails de la faille sont disponibles dans les slides.

Two weeks ago, Microsoft fixed (Ref Lexsi 12420) a flaw disclosed at the Black Hat by Moxie MarlinSpike in late July regarding X.509 certificates which did not get a big attention.

The flaw itself is simple: most libraries handling X.509 certificates, such as NSS libraries used by Firefox or CryptoAPI in Windows, do not take into account the possibility to insert a null character (\0) in the CN (Common Name) field of an X.509 certificate. Thus, the display stops at this null character when handling a certificate.

As an example, the CN field « lexsi.com\0maliciousdomain.com » is seen as « lexsi.com » by vulnerable software.

Valid certificates using this vulnerability have been published, one for www.paypal.com and the other for * (!).

However, Microsoft has given an exploitability index of 3 (= functional exploits are unlikely).

In order to understand why this index is so low although the exploitability has been proved at Black Hat, let's see what are the requirements to take advantage of this vulnerability.

Let's imagine the case of an attacker who wants to decipher the data exchanged with the website https://www.benevolent.fr which is authenticated and ciphered by SSL protocol.

In the client side, the web browser checks 3 elements to authenticate a website using SSL:

1. The certificate has not expired
2. The certificate is signed by a certification authority present in the trusted authorities list embedded in the browser
3. The domain name is identical to the CN field of the certificate

So, the attacker must own a valid certificate for the www.benevolent.fr domain. It can not be self-signed (condition 2) and therefore it must be obtained from a certification authority. But this is not possible because when buying such a certificate, the certification authority will check that the domain belongs to the attacker.

This is where the vulnerability enters the game, because it is possible to buy a certificate for www.benevolent.fr\0malicious.fr (supposing the attacker owns the domain malicious.fr).

Once in possession of this valid certificate, the attacker can set a page (redir.malicious.fr) which acts as a gateway to the legacy www.benevolent.fr website, with the purpose of silently decipher the victim's packets without raising his suspicion.

This leaves us with our third condition, which prompts a warning when the CN content (considered here as being www.benevolent.fr) is different from the URL set by the user.

The attacker has to manage a way (DNS Cache or ARP Poisoning for example) to get the user forwarded to the IP address of redir.malicious.fr when it types www.benevolent.fr in the address bar.

This step is the one which explains that a massive exploitation did not happen despite the 2 months and a half that Microsoft took to fix it. This also explains the exploitability index of 3.

It is required to forge a specific certificate for each target, and also to be in a man-in-the-middle scenario.

Furthermore, Microsoft states that it ensured the certification authorities listed in its browser do not accept anymore a null character in the certificates they deliver.

But what about the valid wildcard « * » certificate ?

In fact, Internet Explorer do not consider this domain as valid, and a warning is displayed (hoping to increase victim's alertness).

However, the Mozilla foundation browser do not reacts to this wildcard and versions prior to 3.0.13 are vulnerable to this attack without the need for an attacker to forge a specific certificate for each victim.

The flaw has been fixed two days after the conference in the Firefox browser (version 3.0.13, the 3.5 is not affected), in early September by Opera (release of the version 10) and in mid-October by Microsoft in the MS09-056 bulletin. Regarding Safari, the Windows version relies on the Microsoft's CryptoAPI library and therefore is not vulnerable if the MS09-056 fix is applied. Several tools handling certificates have been fixed (thunderbird, mutt, openldap, proftpd, wget, curl, fetchmail, neon, kdelibs, qt ...), and some mobile browsers (BlackBerry).

However, as it is explained by Moxie MarlinSpike, Firefox embeds an automatic update mechanism in which all the protection relies on the website from where the updates are retrieved. And this site is authenticated ... via SSL. If the exploitation requirements are met, an attacker is able not only to decipher SSL data, but also to install whatever he wants to on the victim's computer! The exploitation of a vulnerability in the OCSP protocol in order to prevent the revocation of the certificate is also worth noting.

Let's finish with the Mac version of Safari. In its actual version (4.0.3), its behaviour is different from other browsers (even those which are not patched). Indeed, the null character is ignored. Our certificate "www.benevolent.fr\0malicious.fr" is seen by Safari as being for the domain www.benevolent.frmalicious.fr. However, the example of a certificate with the CN field "sitekey.ba\0nkofamerica.com" given during the presentation shows that exploitation is still feasible, just adding more constraints.

This flaw allows to decrypt SSL traffic (obviously, as we own the certificate offered to the victim), and without him being aware of it as all of the usual signs (lock, green address bar...) are the same. The title of this blog entry is not to take too seriously, as the finding (done concurrently by Dan Kaminsky) is great.

Yet the need to perform a man-in-the-middle attack is a major hindrance for a massive exploitation. Thus, the certificate issued for paypal is not enough to perform a large scale phising. Still, targeted attacks in a corporate network are possible ...

Details of the vulnerability are available in the slides.

Le petit landernau de la lutte contre la cybercriminalité est consterné, cette semaine, par le « coming out » d’un jeune chercheur en sécurité, Peter Kleissner ; ce dernier a déclaré être lié au gang à l’origine du cheval de Troie Torpig, et être à l’origine du site web avtracker.info. Ce site est utilisé par les développeurs de malware pour identifier les adresses IP appartenant aux éditeurs anti-virus et chercheurs en sécurité pour mieux s’en protéger, et pour les attaquer. L’auteur de ce site a fait tomber les masques sur son site personnel, où il se paye même le luxe de diffuser son identité complète, celle de son partenaire ainsi qu’une photo.

Le site avtracker.info annonce clairement la couleur, puisque sa page d’accueil incite les visiteurs au déni de service contre les éditeurs anti-virus (« You can also DDoS them in order to lame 'em down »). Kleissner accuse même la société Kaspersky d’avoir tenté de pirater son site, et – non sans un certain culot – est allé jusqu’à demander à l’éditeur anti-virus la somme de 2000 Euros en guise de réparations pour les dommages subis (lire à ce titre le message sur le blog de Kaspersky).

Tout ceci ne serait qu’un fait divers de plus, rapidement lu et rapidement oublié, n’était le fait que Peter Kleissner menait une double vie : il avait en effet réussi avec le temps à s’insérer dans plusieurs cercles informels très fermés de la communauté de lutte contre la cybercriminalité - notamment en participant à la prestigieuse conférence Blackhat, où son intervention en août dernier avait fait sensation ; cercles au sein desquels il a pu accéder à des informations sensibles sur la manière dont les chercheurs coordonnent leurs actions, les enquêtes qu’ils mènent au quotidien, les réseaux qu’ils surveillent, etc. Une mine d’or pour un criminel, qui serait ainsi informé en temps réel des orientations prises par la communauté et des astuces non-publiques qu'utilisent les chercheurs dans leur travail. Si les liens de Kleissner avec le groupe derrière Torpig nous paraissent relever du fantasme de l'adolescent de 18 ans qu'il est - les développeurs de ce malware étant particulièrement discrets, ils n'iraient pas s'en vanter en public - en revanche son pouvoir de nuisance est bien réel, ne serait-ce qu'à cause du site avtracker.info.

C’est ce type d’affaires qui nous rappelle qu’à l’avant-garde de la sécurité, ce n’est ni l’organisation ni la technique qui priment, et encore moins le produit : c’est d’abord le renseignement et la veille, orientés sur les réseaux criminels et les modes opératoires déployés. Renseignement qui passe parfois par des techniques agressives d’infiltration (les services américains sont coutumiers de ces pratiques), mais qui n’est pas l’apanage des forces de l’ordre, les criminels usant de tactiques identiques. Et depuis cette semaine, plus de doutes : « ils » sont parmi nous.

Il apparaît que l'attaque mentionnée dans notre précédent billet n'était pas si ciblée que ça ! Des centaines d'entreprises dans le monde sont en effet attaquées. Beaucoup de banques sont ciblées, mais pas uniquement, des sociétés sans aucun rapport avec le secteur bancaire étant également impactées. Il apparaît que dans certaines de ces attaques, l'URL ne redirige pas immédiatement vers l'exécutable malicieux, mais vers un faux site de messagerie "Outlook Web Access".

Il apparaît également que les e-mails spammés sont envoyés depuis un botnet, de multiples adresses IP de particuliers abonnés à l'ADSL apparaissant comme origine de la campagne. Les sites web frauduleux eux-mêmes sont également hébergés sur un botnet. Cette nouvelle vague d'attaque démontre une créativité certaine des pirates dans l'ingénierie sociale de masse, et l'exploitation de moyens techniques conséquents. Ainsi, l'identification des cibles semble reposer sur des recherches automatiques de sites dans un moteur de recherche : certains domaines, détenus par des particuliers, ont également été ciblés.

Ci-dessous un inventaire (très partiel) de quelques sites frauduleux que nous avons détectés :

• updates.ameropa.de.secure.1-cert.net
• updates.bendigobank.com.au.secure.1-central.net
• updates.bendigobank.com.au.secure.1-db.net
• updates.bendigobank.com.au.secure.1ssl-certs.net
• updates.bendigobank.com.au.secure.admindatacenter.com
• updates.bendigobank.com.au.secure.central-updates.net
• updates.bendigobank.com.au.secure.ssl-updates.com
• updates.berliner-volksbank.de.secure.1ssl-certs.com
• updates.berliner-volksbank.de.secure.ssl-datacontrol.net
• updates.blurfl.com.secure.ssl-updates.net
• updates.borg.mindspring.com.secure.1-db.net
• updates.carohosting.com.secure.1ssl-certs.com
• updates.cdsave.com.secure.upd-services.net
• updates.fuckyou.com.secure.1-central.com
• updates.gmail.com.secure.ssl-updates.net
• updates.halifax.es.secure.first-systems.com
• updates.hardrockgroup.net.secure.central-updates.com
• updates.heartbeatentertainment.com.au.secure.1ssl-network.com
• updates.hm-treasury.gov.uk.secure.oneupdate.net
• updates.hm-treasury.gov.uk.secure.updata-1.com
• updates.hmrc.gsi.gov.uk.secure.admin-data.net
• updates.hmrc.gsi.gov.uk.secure.cert1.net
• updates.hmrc.gsi.gov.uk.secure.upd-center.net
• updates.ing.com.au.secure.1cert.net
• updates.ing.com.au.secure.admin-systems.com
• updates.ing.com.au.secure.ssl-datacontrol.com
• updates.ing.com.au.secure.sys-1.net
• updates.ing.com.au.secure.up1-mail.net
• updates.ing.com.au.secure.upd-central.com
• updates.ing.com.hk.secure.1-cert.com
• updates.ing.com.hk.secure.1ssl-certs.net
• updates.ingcanada.com.secure.upd01.com
• updates.khb.hu.secure.ssl-updates.net
• updates.kqlz.org.secure.cert-services.net
• updates.lloydstsb-offshore.com.secure.admin-db.net
• updates.lloydstsb-offshore.com.secure.nixserver-systems.net
• updates.lloydstsb-offshore.com.secure.updata-1.net
• updates.nab.com.au.secure.1ssl-network.net
• updates.nabholz.com.secure.ssl-updates.com
• updates.nanoprobes.com.secure.1-cert.com
• updates.nanoprobes.com.secure.updata-1.net
• updates.national.com.au.secure.upd-center.com
• updates.nationwide.co.uk.secure.1-admin.net
• updates.redcross-philly.org.secure.upd-services.net
• updates.spamcop.net.secure.admindatacenter.net
• updates.toplanguagejobs.co.uk.secure.up1-mail.net
• updates.weblab.de.secure.admin-db.net
• updates.weblab.de.secure.admindatacenter.com
• updates.weblab.de.secure.ssl-datacontrol.net
• updates.weblab.de.secure.sys-1.net
• updates.yahoo.com.secure.central-updates.com
• updates.ybonline.co.uk.secure.admin-systems.com
• updates.khb.hu.secure.ssl-updates.net
• www.updates.khb.hu.secure.ssl-updates.net
• updates.redcross-philly.org.secure.upd-services.net
• updates.nanoprobes.com.secure.updata-1.net
• updates.hm-treasury.gov.uk.secure.updata-1.com
• updates.hmrc.gsi.gov.uk.secure.admin-data.net
• updates.bendigobank.com.au.secure.1-db.net
• updates.bendigobank.com.au.secure.central-updates.net
• updates.nanoprobes.com.secure.1-cert.com
• updates.carohosting.com.secure.1ssl-certs.com
• updates.halifax.es.secure.first-systems.com
• updates.heartbeatentertainment.com.au.secure.1ssl-network.com
• updates.ing.com.au.secure.upd-central.com
• updates.cdsave.com.secure.upd-services.net
• updates.bendigobank.com.au.secure.1ssl-certs.net
• updates.blurfl.com.secure.ssl-updates.net
• updates.yahoo.com.secure.central-updates.com
• updates.borg.mindspring.com.secure.1-db.net
• updates.nab.com.au.secure.1ssl-network.net
• updates.ybonline.co.uk.secure.admin-systems.com
• updates.ing.com.au.secure.ssl-datacontrol.com
• updates.bendigobank.com.au.secure.1-central.net
• updates.ing.com.au.secure.sys-1.net
• updates.hm-treasury.gov.uk.secure.oneupdate.net
• updates.nationwide.co.uk.secure.1-admin.net

Plusieurs banques européennes sont sujettes, en ce moment même, à des attaques ciblées contre leurs directions des systèmes d’information : les personnels informatiques de ces banques reçoivent des spams ciblés, l’adresse e-mail source ayant été changée pour qu’apparaisse une adresse interne à la banque, du type "administrator@<domaine>". Ces messages incitent leur destinataire à télécharger une mise à jour de sécurité, depuis un site web externe contrefaisant l’identité de la banque ; le « patch » téléchargé n’est autre que le fameux cheval de Troie Zeus (a.k.a Ntos / Zbot / WsnPoem / PRG …), bien connu pour ses fonctions de vol d’information sensible. Les sites web contrefaits sont hébergés en Turquie, en Russie, et en Chine.

La suite du scénario n’est pas connue, mais il nous semble probable que le cheval de Troie soit utilisé pour dérober des identifiants d’accès à des applications privatives internes, ou bien même pour permettre une intrusion par rebond au pirate, qui dispose alors d’une fenêtre ouverte sur le SI de la société.

Ce n’est pas la première fois qu'un malware de ce type est utilisé dans une attaque contre des sociétés : des entreprises ont fait état dernièrement de l’usage d'un malware dans le cadre d’escroqueries, les pirates usurpant auprès de leurs victimes l’identité d’employés de banques identifiés sur Internet (à ce titre, les réseaux sociaux sont une source potentiellement très intéressante pour un fraudeur) ; le malware ne servant que d’amorce pour cette escroquerie.

Cette semaine, l’arrestation d’une figure emblématique du crime organisé en Israël ouvre une fenêtre sur des pratiques désormais courantes dans le domaine du jeu d’argent en ligne.

Dror Alperon, fils du parrain mafieux Ya’akov Alperon, a été arrêté par la police israélienne mardi dernier, alors qu’il revenait d’un séjour à l’étranger. Il est accusé avec son frère Elad d’avoir entretenu sur Internet un site de casino frauduleux. Les joueurs y perdaient de fortes sommes d’argent dans des jeux truqués ; ceux qui ne pouvaient s’acquitter de leurs dettes de jeu se voyaient menacés de mort.

Cette affaire fait écho à la saga judiciaire de la famille mafieuse Gambino, dont plusieurs de ses membres ont été reconnus coupables en 2003 d’avoir opéré un site web illégal de paris sportifs. Ce site était également utilisé par les criminels pour blanchir des fonds issus d’autres activités : les escrocs y jouaient de l’argent à perte, l’argent étant récupéré par d’autres escrocs, et sortait ainsi blanchi en tant que gains issus de jeux d’argent. En février 2008, 26 membres de la famille Gambino furent arrêtés et accusés d’opérer une société de jeux d’argent en ligne illégale, à travers quatre sites web hébergés au Costa Rica, au Panama et au Belize (www.BETMSG.com ; www.BETALLSPORTS.com ; www.BETWSI.com ; et www.BETOFFSHORE.net). Cette opération aurait ainsi rapporté aux Gambino la somme de 10 millions de dollars en seulement deux ans.

Ces évènements témoignent du fait que bon nombre de sociétés de jeux d’argent en ligne ne sont pas « seulement » illégales, mais sont en réalité directement contrôlées par des groupes criminels organisés.