Le fourre-tout à Geo

Aller au contenu | Aller au menu | Aller à la recherche

dimanche, novembre 8 2009

HowTo: audits et logs

Les logs, c'est une liste de messages datés vous indiquant ce qui se passe sur votre système (pour ceux qui ne le savaient pas).

On va me dire: "les logs c'est pas de la sécu, ça protège rien". Et je vais répondre: "est-ce que vous savez si quelqu'un a essayé de se logguer sur votre machine aujourd'hui? Est-ce que cette personne a essayé de se connecter devant la machine, ou depuis le réseau?"

Gérer ses logs, c'est savoir ce qui se passe sur sa machine et être alerté en cas de problèmes. Et puis ça alimente ma paranoïa, donc je suis content :)

J'écris ce billet maintenant car dans les billets suivants, j'ajouterai des éléments aux logs. Si on sait comment ça marche dès le début, la pilule passera mieux.

Allez, on va voir de quoi ça parle: tout d'abord, on va se rajouter les droits pour regarder les logs, parce que depuis l'article précédent, on n'a plus les droits d'admin :). Lancer la console "Local users and groups" (lusrmgr.msc), allez dans Groupes, puis Event log readers, clic droit et Add to group. Rajoutez votre utilisateur. Maintenant, vous pouvez lancer la console de gestion des logs.

L'event viewer

"Démarrer->exécuter" puis eventvwr.msc. Vous pouvez voir plusieurs types de logs.

  • Custom views: les autres logs passés au travers de filtres pour indiquer les infos qui vous intéressent
  • Windows logs: les logs qui nous intéresseront ici. Tous les messages que Windows vous dépose gentiment, en espérant que vous les lirez...
  • Applications and services logs: le reste des applications qui utilisent les logs de Windows.
  • Subscriptions: pour récupérer des logs d'une autre machine.

Parmi les logs de la section Windows, on trouve:

  • Applications: reçoit les événements concernant les applications, comme les crashes (Windows Error Reporting)
  • Security: on ne peut le voir qu'avec les droits d'admin (va falloir Run as Administrator la console de logs, parce que c'est celui qu'on va regarder).
  • Setup: reçoit les événements de mise à jour, installation de .msi, etc.
  • System récupère les événements relatifs aux services, au kernel, etc.
  • Forwarded events est lié à l'envoi de logs sur d'autres machines

events categories

Prenez le temps de fouiner un peu, regarder quelles informations votre machine vous renvoie. Comme vous pouvez le voir, il se passe beaucoup de choses!

Rajoutons des événements

Supposons que je veuille vérifier si quelqu'un a tenté de se connecter à ma machine en mon absence. Je vais vérifier si quelqu'un a tapé un mauvais mot de passe, et je vais vérifier quel utilisateur a réussi à se logguer au cours de la journée.

Lancez secpol.msc. Allez dans Local Policies puis Audit Policy. Choisissez par exemple Audit account logon events et indiquez Failure et Success dans les propriétés.

secpol.msc

Essayez maintenant de vous connecter à un autre compte, en ratant délibérément le mot de passe. Vous verrez apparaître dans les logs Security des lignes contenant le mot clef "Audit failure" pour la tâche "Credential validation". Cliquez sur l'une d'elles: vous verrez que le log indique la date, l'heure, la machine concernée et le compte qui a essayé de se logguer.

login failed

Marrant, non? Et on va peut rajouter des logs pour pas mal de choses. Suppsons que j'aie des documents compromettants (par exemple, la photo d'un prez de BDE complètement bourré). J'aimerais savoir si quelqu'un a essayé de la copier. Je vais donc ajouter un audit sur les accès à ce fichier, et donc afficher une ligne dans les logs si quelqu'un essaie d'ouvrir le fichier.

Il suffit d'aller dans le dossier contenant ce fichier, clic droit puis Propriétés -> Advanced -> Auditing et utiliser ses droits d'admin pour voir les propriétés d'audit.

auditing

Maintenant, on va ajouter des propriétés d'audit pour ce fichier. Je choisis de les mettre sur le groupe Users. Je veux auditer les accès en lecture, et les suppressions de fichier (au cas où quelqu'un voudrait faire disparaître les preuves de ses frasques). Vous pouvez voir de nombreuses options, le système d'audit est très flexible (peut-être trop pour être utilisé par une personne normale).

auditing entries

Maintenant, on va essayer d'ouvrir le fichier, et aller voir le contenu du log. L'event viewer nous indique que "an attempt was made to access an object", par Geal (moi), sur le fichier en question.

log file access

Et voilà! Maintenant, vous allez pouvoir en ajouter beaucoup plus! Il est possible d'auditer des clefs registre, l'usage de privilèges admin, le lancement de programmes, etc. Je proposerai quelques-uns de ces ajouts dans les prochains tutoriels.

Notez bien que la génération des logs peut prendre pas mal de ressources et d'espace disque, donc évitez par exemple de mettre un audit sur toutes les lectures de fichiers sur c:\ et ses sous dossiers (j'ose même pas imaginer ce que ça donne pendant une compilation de vlc).

lundi, novembre 2 2009

HOWTO: la sécurité au quotidien

Je vois partout les mêmes recommandations: utilisez un antivirus, activez votre firewall, changez vos mots de passe régulièrement, ne cliquez pas sur n'importe quel lien, etc. J'en ai MARRE! On vous sort ces solutions à deux sous, qui ne font qu'adresser une partie du problème, qui est:

comment éviter à un boulet de perdre ses données, de se faire voler son n° de carte bleue ou son compte Facebook ou de servir de noeud dans un botnet? Et comment rendre ça user friendly (aka "éviter d'écrire le mot de passe sur un PostIt").

Je me lance dans une entreprise ambitieuse, qui consiste à trouver une série de solutions qui vont bien ensemble pour protéger une machine perso. Je ne parlerai pas de machines sur un réseau d'entreprise, mais j'aborderai éventuellement les problèmes du réseau @home et du WiFi, et de mobilité. Ah, et il s'agira uniquement de Windows: les utilisateurs Linux sont encore pas mal protégés, et les utilisateurs Mac n'écoutent pas quand on leur dit qu'ils ne sont pas à l'abri. Mes tests seront faits sous Windows 7 et Vista (XP si je combats la flemme de m'installer une autre machine) avec toutes les mises à jour effectuées (bien évidemment, si vous ne mettez pas à jour votre OS pour cause de paranoïa et/ou de piratage, je ne peux rien faire pour vous).

J'écrirai une série de billets, sous la forme de tutoriels et/ou tests, sur les sujets suivants:

  • Utilisateurs et groupes d'utilisateurs
  • Logs
  • Mots de passe
  • Droits (UAC, LUA, Integrity Levels, SRP)
  • Firewall
  • Navigateurs
  • virus, chevaux de troie, etc.
  • Applications dangereuses et leurs alternatives
  • Protection des applications
  • Applications web
  • Sauvegarde de données
  • Mises à jour

J'essaierai (dans la mesure du possible) de rendre ces solutions faciles à mettre en place, (ça va être dur) pas trop restrictives à l'utilisation et bien intégrées dans L'OS (aka "pas de hook foireux qui traînent").

Utilisateurs et groupes

Pour ce premier tutoriel sur la protection de votre machine, on va parler des notions d'utilisateurs et de groupes d'utilisateurs dans Windows. Oui, ça existe, on n'est pas obligé de prendre le compte "Administrateur" pour pouvoir utiliser sa machine.

Pourquoi est-ce que tout le monde tourne sous le compte admin de sa machine? Parce que c'est plus simple pour le constructeur de vous donner le compte admin et vous laisser pourrir votre machine, que de vous donner plusieurs compte et ainsi s'exposer aux nombreux appels de clients en colère parce qu'ils n'arrivent pas à installer une application. Et c'est aussi plus simple, vu que pas mal d'applications supposent encore qu'elles peuvent écrire dans C:\Program Files.

Que va-t-on faire aujourd'hui? Pas compliqué: on va créer deux comptes utilisateurs: un "normal", que vous pourrez utiliser tous les jours, et un compte "Administrateur" qui vous permettra d'effectuer certaines tâches nécessitant plus de droits comme l'installation d'applications.

Tout d'abord, lancez la console de gestion des "Local users and groups" en allant dans Démarrer->exécuter et en tapant lusrmgr.msc.

Local Users and Groups

Cliquez sur le dossier Users (ou Utilisateurs si vous aimez votre version française). Vous devriez maintenant voir une liste de comptes, dont Administrator (qui est pour l'instant désactivé), Guest, le (les) vôtre(s), ainsi que AlphaUser$ et HomeGroup$ si vous avez créé un Homegroup (c'est pas particulièrement important pour le moment).

Users

Ce que l'on va faire maintenant:

  • Désactiver le compte Guest (si c'est pas déjà fait)
  • Activer le compte Administrateur
  • Ajouter un mot de passe au compte Administrateur
  • Retirer votre compte du groupe Administrateurs

Très simple: clic droit sur les comptes, puis propriétés. Pour Administrateur, clic droit, puis changer le mot de passe, et indiquez un mot de passe de votre choix (non, on ne choisit pas "123456" ou "admin", c'est MAL), puis à nouveau clic droit, propriétés et activez le compte. Pour Guest, faites l'inverse (désactivez-le). Pour votre compte, clic droit, propriétés, puis allez dans l'onglet "Membre de". Cet onglet liste les groupes dont le compte fait partie. Cliquez sur Administrateurs puis cliquez sur Retirer.

Member of

Voilà, c'est fait! Bon, euh, qu'est-ce qu'on a fait en fait? Avant, vous pouviez, avec votre compte normal, installer des applications, supprimer des fichiers de C:\Windows,tripoter votre base de registres, etc. XP ne vous indiquait même pas que vous alliez bousiller votre système. Vista et 7 vous montraient la fameuse fenêtre UAC vous demandant si vous vouliez vraiment faire une connerie. Maintenant, cette fameuse fenêtre va vous demander de vous identifier avec le compte Administrateur pour aller trifouiller dans votre système.

Oui, je sais, ça paraît relou. Mais vous verrez que 90% du temps, on n'a pas besoin des droits d'Administrateur (surtout depuis Windows 7). Avec cette modification, si une application ressent tout à coup le besoin d'aller vous installer des cochonneries, vous serez averti!

Quid de l'UAC? C'est pas une protection! Lorsque vous utilisez avec votre compte de base, vous avez deux casquettes: celle de l'utilisateur normal, et celle de l'administrateur. Lorsque vous voulez effectuer une action nécessitant plus de droits, Windows vous demande de changer de casquette. Certains programmes changeront même votre casquette sans vous demander... Avec la manip' que vous venez de faire, Windows vous demande systématiquement l'autorisation de l'administrateur :)

Ah, et un effet de bord sympa: c'est pas n'importe qui qui peut installer une application derrière mon dos quand je le laisse utiliser mon ordi cinq minutes (valable aussi et surtout si vous avez des gosses).

Bon, manifestement, c'est pas fini, on peut encore faire pas mal de conneries sur ma machine, avec suffisamment de motivation. On en rajutera dans le prochain article :)

mercredi, octobre 28 2009

test d'EMET, un nouvel outil pour protéger vos programmes

L'annonce est parue hier sur le blog de Microsoft Security Research & Defense: la release d'EMET(Enhanced Mitigation Evaluation Toolkit), un outil gratuit permettant d'appliquer des protections comme DEP sur vos programmes.

Jusqu'ici, l'ajout de ces protections était soumis au bon vouloir du développeur. Soit on activait les options dans Visual Studio, soit on utilisait ma bidouille avec peflags. EMET permet d'activer les protections chez vous, sur les processus que vous voulez de façon très simple: EMET_conf --add <executable>. Quel que soit le dossier contenant votre programme, EMET se chargera de le lancer avec les protections choisies.

EMET gère ainsi une liste de processus et leur apporte les protections suivantes:

  • SEHOP (Structured Exception Handler Overwrite Protection): validation de la chaines des gestionnaires d'exception
  • DEP (Data Execution Prevention): marque certaines parties de la mémoire, par exemple la stack, comme non exécutables
  • NULL page allocation: protection contre les "NULL dereferences" en résevant la première page mémoire
  • Heap spray allocation: "heap spray" est une attaque qui consiste à balancer du shellcode un peu partout dans la mémoire, et à sauter plus ou moins au hasard dans les zones mémoires affectées en espérant pouvoir exécuter le shellcode. EMET réserve les adresses mémoire généralement utilisées dans les exploits pour les empêcher d'y écrire.

Bon, maintenant, les critiques (j'ai bien appris la présentation classique thèse/antithèse/synthèse à l'école, maintenant, j'applique!):

  • J'aurais bien aimé voir ASLR(Address Source Layout Randomization) là-dedans, parce que ça va bien avec DEP et SEHOP.
  • On ne peut pas choisir quelle protection on applique à quel binaire: les options sont dans des clefs registres dans HKLM/Software/Microsoft/EMET, et quand on en désactive une, on la désactive pour tous les programmes. Par contre, il y a une clef registre assez fun nommée "heap_pages", qui permet d'indiquer à EMET quelles adresses réserver pour la partie heap spray allocation.
  • Ce serait sympa d'avoir une interface "oh, look, shiny!", même si ça sert à rien :)

Comparé à peflags, EMET apporte la protection contre les null pointer dereferences et les heap sprays, et permet de protéger un exécutable en se basant sur son nom. Par contre, peflags permet d'appliquer les protections beaucoup plus finement (par exemple, SEHOP pour un programme et pas pour l'autre), et peut ajouter le flag ASLR (qui doit être appliqué sur toutes les DLLs chargées par un programme pour fonctionner correctement).

En résumé, un outil sympa, mais qui devrait être travaillé encore un peu. Ca reste un programme utile pour les développeurs qui veulent tester le comportement de leur application lorsque les protections sont activées. Dommage, c'est déjà fait avec VLC media player!

lundi, septembre 21 2009

Enable DEP and ASLR with MinGW

Every now and then, we see reports about vulnerabilities in numerous applications: buffer overflows and heap overflows are unfortunately very common. Until we find a way to teach all the developers how to think about security while coding (and then, there will still be a lot of programs to fix), we can try some tricks to prevent exploitation of vulnerabilities.These tricks have been Visual Studio only for a long time (and even with VS, not everybody uses them), but now, we have tools to protect as well programs built with GCC.

DEP and ASLR?

DEP provides support for NX bit since Windows XP SP2 and Windows 2003 SP1. This feature flags some part of the memory, like the heap and the stack, as not executable. Then, the shellcodes stored in buffers will have a hard time trying to run.

ASLR randomizes the address of function entry points. This way, exploits with hardcoded functions address like ret2libc attacks won't work.

These two mechanisms are not silver bullets: they can be bypassed. But it makes the process of writing an exploit much harder.

Using it

If you build your program with Visual Studio, it's easy and documented. If you're using MinGW to build for Windows, it's not really documented, but it's easy too.

To mark an executable as DEP and/or ASLR compatible, you have to change the DllCharacteristics field in the Portable Executable header. You can write your own PE modification software, or use one of these two solutions:

Peflags

Peflags is a program you can find in the rebase package from Cygwin. Peflags builds fine with MinGW in MSYS, but you have to tweak a bit the source if you want to run it from Linux, or directly take my modified source.

It is really easy to use:

peflags --dynamicbase=true --nxcompat=true myexecutable

You can add this command to your Makefile. It has to run on the executable and all the dlls it loads, to be effective. If you want to verify that your program has enabled the flags, do:

objdump -p myexecutable

And look for the DllCharacteristics flag. If its value is 140, congratulations! Your executable is now compatible. You can also verify with Process Explorer, from SysInternals. Here is the line for VLC media player:

DEP and ASLR

LD

In March 2009, the support for this DllCharacteristics flag was added to ld, but the new binutils package containing the updated ld hasn't been released (yet). The command line is more or less the same.

Remarks

  • You have to add the flags to every executable used by your program. If you load a vulnerable dll without DEP, it won't protect you.
  • I'll say it again: it's no silver bullet. You still have to fix your bugs. It's a lot harder to exploit, but some may be able to do it.
  • VLC media player now has peflags in its building toolchain! I'm waiting for the release of the next binutils, and then I'll use the new ld.

- page 1 de 2