Imperva analyse les attaques automatisées

Imperva dévoile les résultats de son rapport Hacker Intelligence d’avril sur les attaques automatisées. Imperva analyse en détails comment et pourquoi les attaques d’applications web sont automatisées. Selon le précédent rapport (Janvier – Mars 2012), plus de 98% d’attaques RFI et plus de 88% des injections SQL sont automatisées, via les logiciels Havij et sqlmap.
Comparé aux méthodes manuelles, ces outils automatiques permettent aux pirates d’attaquer plus d’applications et d’exploiter de manière plus efficace les vulnérabilités. Ces logiciels sont disponibles en ligne, ils simplifient l’identification des vulnérabilités et apprennent aux pirates à les exploiter et en tirer profit.
« Ces outils logiciels sont facilement utilisables, même un hacker débutant peut, dans un laps de temps réduit, attaquer des applications afin d’en extraire des données précieuses puis se tourner vers de nouvelles cibles », déclare Sylvain Gil, Expert en sécurité chez Imperva. « Les outils automatisés peuvent également servir à contourner la sécurité informatique d’une entreprise. »
Principaux enseignements du rapport :

• Méthodes d’identification automatique: Les caractéristiques de trafic telles que le taux d’attaques, les variations du taux et du volume d’attaques peuvent êtres utilisées pour identifier des attaques automatiques.
• Tendances des attaques automatisées: Les outils automatiques peuvent laisser une empreinte ou patterns extractibles à partir du code source pour identifier avec fiabilité la nature de l’attaque automatisée.
• Remédier aux attaques automatisées: Imperva délivre une analyse des multiples vecteurs d’attaques, mettant en évidence les caractéristiques sur lesquelles les professionnels de la sécurité peuvent s’appuyer pour prévenir un trafic malicieux et établir des listes noires d’adresses IP suspects.

REF.: Pour télécharger ce rapport complet en anglais : http://www.imperva.com/download.asp?id=360

Ce qu'il faut comprendre des attaques d'applications Web: injection HTML

C'est un problème de sécurité de base dans lequel les données (informations comme une adresse e-mail ou une adresse ou prénom) et un code (qui créent la page Web, comme la création d'éléments

Comment une firme en sécurité peut s'enrichire facilement ?

 

Comment un gang de pirates a-t-il pu voler plus d’un milliard de mots de passe ?

Un petit groupe de cybercriminels a employé un botnet pour infiltrer des dizaines des milliers de sites web et récupérer une quantité gigantesque de données sensibles. Mais la firme qui a fait cette découverte en profite pour faire un formidable coup de com’ et vendre un service derrière. Bizarre.

La page d'accueil alarmiste de Hold Security, entreprise qui a révélé le piratage… Et qui propose une solution payante pour tenter d’y remédier.

Que vous soyez un expert en informatique ou un technophobe, à partir du moment où vous avez des données quelque part sur le web, vous pouvez être affecté par cette brèche. On ne vous a pas nécessairement volé directement. Vos données ont peut être été subtilisées à des services ou des fournisseurs auxquels vous avez confié des informations personnelles, à votre employeur, même à vos amis ou votre famille  ». Voilà le discours flippant de Hold Security pour décrire la gigantesque collection de données personnelles volées que cette entreprise de sécurité a mis au jour.

Les chiffres présentés donnent en effet le tournis : d’après Hold Security, un gang d’une douzaine de hackers russes baptisé CyberVor aurait donc récupéré pas moins de 4,5 milliards de combinaisons de mots de passe et de noms d’utilisateurs. En omettant les doublons, CyberVor aurait accès à plus d’un milliard de comptes sur des milliers de sites différents, qui seraient rattachés à 500 millions d’adresses e-mail. Le hack du siècle, en somme.  

Pour voler autant d’informations sensibles, CyberVor aurait usé de multiples sources et techniques, mais aurait surtout profité des services d’un botnet (un réseau de PC infectés par un logiciel malveillant) « qui a profité des ordinateurs des victimes pour identifier des vulnérabilités SQL sur les sites qu’ils visitaient. » Les membres de CyberVor auraient de cette manière identifié plus de 400 000 sites web vulnérables, qu’ils ont ensuite attaqué pour voler leur bases de données d’utilisateurs. 

Des détails qui clochent

Sauf qu’il y a quelques petits détails qui clochent dans cette histoire. A commencer par le fait que Hold Security profite de cette annonce hallucinante pour tenter de s’enrichir immédiatement, en misant sur la peur du hacker qu’il a généré. En gros, la firme propose aux entreprises et aux particuliers de se préinscrire à un service –payant même s’il y a un essai gratuit- qui leur permettra notamment de savoir si oui ou non ils sont concernés par cette fuite de données. Et ce n’est pas donné : comptez 120 dollars par mois si vous êtes une entreprise.

D’autre part, Hold Security se refuse à donner le moindre nom de site dont la base a été piratée. Ce peut être compréhensible : son patron Alex Holden l’explique dans le New York Times, il ne souhaite pas révéler le nom des victimes pour des raisons de confidentialité. Il y aurait pourtant des entreprises du Fortune 500 selon lui dans le lot.

Mais comme le fait remarquer Forbes, il semble pour le moins étonnant (mais pas totalement impossible) que de si grandes entreprises se soient fait berner par une injection SQL, une technique très connue des hackers… et des experts en sécurité qui protègent les sites importants de telles attaques.

Des infos de piètre qualité ?

Il y a aussi de nombreuses informations qui manquent, dans la description de Hold Security. Quels botnets ont été utilisés ? Comment le malware a-t-il été inoculé dans la machine des victimes ? Et surtout pourquoi, comme l’indique le New York Times, le gang se contente-t-il d’utiliser pour l’instant leur fabuleuse base de données pour… envoyer du spam sur les réseaux sociaux, alors qu’ils pourraient à priori faire bien plus de mal ?

En réalité, il se peut que les milliards de mots de passe collectés par CyberVor étaient déjà disponibles sur le web underground depuis bien longtemps. Hold Security l’avoue sur son site : « Au départ, le gang a acquis des bases de données d’identifiants sur le marché noir ». Une pratique fort courante chez les cybercriminels, mais qui ne repose pas sur le moindre hack : il suffit de payer. Il est fort possible que ces « collectionneurs » aient au fil du temps accumulé un nombre de données incroyable, mais pas forcément « fraîches » et donc de piètre qualité. Il se peut aussi que la technique de l’audit d’un site par un botnet ait été fructueuse… Sur des sites de moindre envergure, voire des sites perso, mal sécurisés, qui n’ont pas fourni à Cybervor de quoi faire autre chose que du spam sur Twitter.

Quoiqu’il en soit, l’annonce de Hold Security vous donne une excellente excuse pour changer dès aujourd’hui vos mots de passe, ça ne fait jamais de mal !

Source : Hold Security

Pourquoi les attaques par injection SQL sont couronnées de succès ?

Le rapport Ponemon offre un aperçu intéressant :
SQL est martelé par les méchants . Pourquoi est-ce , et c'est là tout ce qui peut être fait pour remédier à la situation ? Une récente étude du Ponemon sur les injections SQL et les solutions possibles sont discutés.
SQL a été autour depuis les années 1970 , donc on assumerait tous les bugs de la vulnérabilité du language ont été éliminés.Pourtant, il existe encore de nombreux rapports d'attaquants pouvant tirer parti des faiblesses dans SQL à enfreindre systématiquement les entreprises de grande envergure .

On m'a dit que c'est la nature de la bête . Chaque fois que les gens sont autorisés à accéder aux informations stockées sur les serveurs backend,le problème est juste une requête plus loin .Méchants utilisent une injection SQL pour libérer les données du serveur hébergeant la base de données sous attaque .

En quoi consiste exactement une attaque par injection SQL ?
Selon l'Institut Ponemon , injection SQL est utilisée pour :

" Applications pilotées par les données d'attaque : dans les instructions SQL malveillants sont insérés dans un champ de saisie pour l'exécution (par exemple pour vider le contenu de base de données à l'attaquant ) injections SQL exploitent les failles de sécurité dans le logiciel d'une application injection SQL est plus communément connu comme un . . vecteur d'attaque par des sites grand public , mais peut être utilisée pour attaquer des bases de données SQL dans une variété de façons . "

Pourquoi les attaques par injection SQL sont encore répandue ?
Le fait que les attaques par injection SQL ont été découverts il y a plus de 15 ans par Jeff Forristal et sont encore exécuté par beaucoup de gens frustrés .
D'autres applications vulnérables sont finalement fixés , mais pas SQL . Le projet Open Web Application Security ( OWASP ) propose cette explication :

«Les attaques par injection SQL sont malheureusement très commun , et cela est dû à deux facteurs : . La prévalence des vulnérabilités d'injection SQL et l'attractivité de la cible ( bases de données contenant les données intéressantes / critiques pour l'application ) "
La prévalence de la vulnérabilité et l'apparente incapacité de faire quoi que ce soit à ce sujet le Dr Larry Ponemon perplexe , président et fondateur de l'Institut Ponemon , un organisme de recherche indépendant . Dr Ponemon a décidé de faire ce qu'il fait le mieux : la recherche du problème .

Avec le parrainage de DB Networks, l'Institut Ponemon a recueilli les réponses de près de 600 membres du personnel de TI et les professionnels de la sécurité pour tenter de comprendre comment les organisations réagissent aux menaces d'injection SQL et la prise de conscience des participants sur la façon de gérer le risque - les choses simplement , pourquoi les attaques par injection SQL se produisent encore .

De l'enquête les réponses des répondants , l'Institut Ponemon dérivé résultats intéressants qu'il a publié dans l'étude SQL Injection de la menace .

Méthodologie de l'enquête
Avant d'arriver à ce découvert Ponemon , je vais partager la façon dont il a mis en place l'enquête , en particulier la sélection des participants :

" Un cadre d'échantillonnage de 16520 a connu TI et praticiens de la sécurité situées aux États-Unis ont été sélectionnés comme participants à cette enquête. Rendement total s'élève à 701 . Dépistage et les vérifications de fiabilité requis la suppression de 106 enquêtes . L'échantillon final était composé de 595 enquêtes . "

Le nombre d'organisations attaquées

Une conférence téléphonique a eu lieu avec le Dr Ponemon et Michael Sabo , vice- président du marketing pour DB Networks, pour discuter des résultats . L' ampleur du problème a fait surface lors de l'examen des réponses des répondants aux questions suivantes :

Au cours des 12 derniers mois , votre entreprise at- expérience une ou plusieurs attaques réussies par injection SQL ?

Si oui , combien de temps at-il fallu pour détecter l'attaque ?

Si oui , combien de temps at-il fallu pour contenir l'attaque ?

Soixante- cinq pour cent des organisations représentées dans cette étude a connu une attaque par injection SQL qui a évité avec succès leurs défenses périmétriques dans les 12 derniers mois . Vingt et un pour cent ( le plus grand groupe en termes de pourcentage ) a déclaré qu'il a pris six mois pour détecter l'attaque , et vingt- un pour cent ( le plus grand groupe en termes de pourcentage ) dit qu'il a fallu un mois pour contenir l'attaque .

Pourquoi le taux de réussite ?

La prochaine série de questions a essayé de déchiffrer pourquoi tant d'attaques ont réussi , et pourquoi il a fallu tant de temps pour détecter et contenir les attaques :

Comment êtes-vous familier avec le terme comme arme d'attaque par injection SQL ?

Combien de fois ne scanne votre entreprise pour les bases de données actives ?

Est-ce que votre test de l'entreprise et de valider des logiciels tiers afin de s'assurer qu'elle n'est pas vulnérable à des attaques par injection SQL ?

Quarante- huit pour cent des répondants n'étaient pas familiers avec le terme comme arme attaques par injection SQL . Comme pour la numérisation de bases de données actives , vingt -cinq pour cent le faire à intervalles irréguliers , et vingt-deux pour cent ne recherche pas du tout . Cinquante -deux pour cent des répondants ne va pas tester ou valider un logiciel tiers pour leur sensibilité à attaques par injection SQL .

Essayer d'identifier les faiblesses

Ensuite, les participants ont été invités à évaluer les déclarations suivantes .

La question se référant au BYOD semblait hors de propos. Pour expliquer , Sabo mentionné attaques par injection SQL via un PC a commencé avec le navigateur Web , dont il ne reste que quelques versions et relativement facile à obtenir . Considérant que, BYOD , le plus souvent chaque application se connecte à un serveur SQL , ce qui rend presque impossible de protéger les appareils et les données , et d'expliquer pourquoi 56 pour cent des répondants sont préoccupés par BYOD .

les conclusions

Comme la plupart des enquêtes , l'étude SQL Injection de la menace fournit les informations , mais pas de conclusions . Ponemon et Sabo ont été invités à spéculer sur les conclusions du rapport d'enquête . Tous deux centrés sur la façon dont le maillon faible de SQL est la requête , et que la garantie de toutes les requêtes font ce qu'ils sont censés et rien de plus est une tâche difficile .

Sabo a également mentionné que , jusqu'à récemment , il fallait un haut niveau d'expertise pour construire une requête illicite . Maintenant, l'Internet est inondé avec des outils qui permettent aux individus inexpérimentés à obscurcir les requêtes malveillantes , ce qui rend facile d'être un mauvais gars(Pirate/Hacker) , et encore plus difficile pour les mesures de sécurité SQL pour détecter les requêtes malveillantes.

" Le processus commence par l'apprentissage automatique et la modélisation du comportement de génération de SQL correcte de l'application. L'IDS de base utilise alors une suite de procédures de tester et d'évaluer chaque instruction SQL sur le modèle de comportement appris. Logique floue est appliquée pour déterminer la menace globale de chaque instruction SQL . "

Scepticisme sur les solutions est justifiée sur la base du passé de SQL . Mais , Joe McCray , un consultant indépendant en sécurité et  vétéran Pen testeur, dans cette vidéo YouTube, a expliqué que la réponse de DB réseau à injection SQL bloqué toutes les attaques qu'il a essayé :

" La façon dont le produit fonctionne est unique . Le suivi en temps réel et la détection basée sur les anomalies - était quelque chose que je n'avais pas vu dans cet espace de l'application. Elle a été en mesure de montrer à tous les attentats que je tentais , même quelques trucs très sophistiqués que j'utilise " .

REF.: