Mode d’attaque

rapide pour identifier
le port d’écoute de SQL Server : ils
peuvent interroger un service non
nommé que j’appelle le SQL Advertisement
Service, qui écoute sur le port
UDP 1434. Ce service a un buffer non
vérifié que le ver SQL Slammer a exploité
(SP3 corrige cette faille). Quand
un pirate interroge ce service, SQL
Server 2000 renvoie les noms de toutes
les instances SQL Server disponibles et
le port sur lequel elles écoutent. Les pirates
peuvent aussi trouver des SQL
Server disponibles en utilisant des outils
de balayage de ports qui essaient de
trouver des serveurs utilisant le port
TCP 1433, le port d’écoute par défaut
de SQL Server, ou le port 2433.
Une fois que les assaillants ont reconnu
un SQL Server disponible en interrogeant
l’Advertisement Service ou
en scrutant les ports 1433 et 2433, ils
n’ont aucun mal à  savoir quel mode
d’authentification vous utilisez. Il leur
suffit d’ouvrir Query Analyzer, d’entrer
l’adresse IP du SQL Server, de taper sa
comme nom d’utilisateur, de laisser le
mot de passe vierge et de cliquer sur
OK. Si le message d’erreur qui s’en suit
est Login failed for user ‘sa’, le SQL
Server utilise l’authentification mixte.
Si le message d’erreur est Login failed
for user ‘sa’. Reason : Not associated
with a trusted SQL Server connection,
le SQL Server utilise l’authentification
Windows. Les pirates essaient en principe
d’accéder aux serveurs qui renvoient
le premier message d’erreur.
L’action suivante du pirate consiste
à  découvrir le mot de passe du compte
sa. Beaucoup d’outils – dont SQLdict à 
http://ntsecurity.nu/toolbox/sqldict et
sqlbf à  http://www.sqlsecurity.com/
scripts.asp – sont disponibles pour révéler
le mot de passe du compte sa en
réponse à  une attaque par dictionnaire
ou une attaque en force. D’ailleurs, les
auditeurs de sécurité utilisent ce genre
d’outils pour mettre à  l’épreuve la résistance
des mots de passe login de
SQL Server. Bien entendu, les pirates
peuvent aussi se procurer ces outils.
Les attaques par mot de passe sont
fructueuses parce que SQL Server n’a
pas de fonctions de filtrage (et de refus)
de compte. Mais les API sur lesquelles
s’appuient les applications de
cracking pour créer des logins et les
envoyer sur votre réseau, subissent généralement
une chute de performances
suffisante pour décourager un
pirate impatient. Cependant, Network
Intelligence India possède un utilitaire
appelé Forcesql (disponible à  http://
www.nii.co.in/research/tools.html) qui
crée le login et l’envoie sur le réseau
lui-même, évitant ainsi la baisse de performance.
Un assaillant ou un auditeur
utilisant cet outil peut spécifier un jeu
de caractères et une longueur de mot
de passe adaptés à  une attaque en
force. Forcesql peut produire quelques
200 à  300 suppositions de mots de
passe par seconde. Pendant le test initial
en laboratoire de Forcesql, j’ai effectué
plus d’un million de tentatives
de mot de passe en 90 minutes.
Comme il est facile de se procurer de
tels outils, les DBA et les développeurs
doivent créer des mots de passe sa suffisamment
longs et compliqués pour
dissuader les assaillants.