20 fév. 2017

Vérifier les chiffrements disponibles sur un serveur HTTPS avec Nmap

Je me suis retrouvé l'autre jour avec une alerte de sonde de détection d'intrusion, laquelle me signalait qu'une potentielle exploitation de la faille Heartbleed avait eu lieu sur un serveur web. L'autre détail que j'avais au niveau de l'alerte : le protocole utilisé pour cette exploitation était SSL v3.

N'ayant pas la main sur la machine, je n'avais pour seule option que de vérifier côté client si le serveur utilise ce protocole. Sur l'instant, j'ai pensé à utiliser OpenSSL, qui dispose d'options pour se connecter à un serveur en utilisant certains protocoles. Cela donne pour mon cas, l'exemple et le résultat suivant :

$ openssl s_client -connect blog.anotherhomepage.org:443 -ssl3                                                                                                                                                             
CONNECTED(00000006)
140187574654788:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:1304:SSL alert number 40
140187574654788:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1485895043
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Alors bon, je sais pas trop vous, mais pour moi, ce n'est pas très évident que le serveur ne prend pas en charge SSL v3. Il y a quand même écrit "CONNECTED" au début, avant de me sortir "handshake failure". Néanmoins, la mission est remplie, et on peut vérifier plusieurs protocoles via les options suivantes d'OpenSSL :

* -ssl2 ;
* -ssl3 ;
* -tls1_2 ;
* -tls1_1 ;
* -tls1 ;
* -dtls1.

Peu satisfait de la solution, j'ai continué mon voyage dans les moteurs de recherche, avant de tomber sur une question similaire, disposant de la première solution, mais d'une autre visiblement plus lisible, utilisant le célèbre Nmap. Elle consiste à tirer parti d'une fonctionnalité assez intéressante du célèbre scanneur de ports, à savoir la disponibilité d'un langage de script permettant d'obtenir des détails supplémentaires lors d'un scan de port. Parmi les scripts disponibles, certains ont même pour but de mener des attaques par bruteforce. Là, il n'est pas question d'attaque, mais simplement d'énumération des ciphers disponibles. Comme plus haut, voici un exemple accompagné d'un résultat :

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-19 09:30 CET
Nmap scan report for blog.anotherhomepage.org (163.172.46.128)
Host is up (0.0012s latency).
rDNS record for 163.172.46.128: vhost2.anotherhomepage.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 10.06 seconds

On remarquera, dans mon exemple, l'absence de SSLv3.

Et pour l'alerte de mon IDS ? Et bien comme dans mon exemple, SSLv3 n'est pas apparu dans mes résultats, ce qui m'a permis de conclure au faux-positif.

Un dernier détail : au moment de l'écriture de ce billet, NSE n'est pas activé par défaut dans pkgsrc, et pour NetBSD, son activation empêche de compiler Nmap.

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

23 janv. 2017

Kodi : récupérer certaines informations sur des addons

J'ai récemment perdu le mot de passe d'un service web que j'utilise par le biais d'un addon de Kodi. Je sais, c'est pas très malin, j'ai malencontreusement écrasé ma base de mots de passe au mauvais moment. Shit happens, comme ils disent dans la langue de Shakespeare.

Comme c'est casse-pied de retaper un nouveau mot de passe via un clavier virtuel et une télécommande, je me suis demandé si le mot de passe était stocké en clair dans la configuration de l'addon. On sait jamais, sur un malentendu, ça pourrait marcher. J'ai donc commencé à fouiller dans l'arborescence de Kodi, et j'ai pu voir que celui-ci stocke ses informations dans ~/.kodi. On y trouve alors un répertoire addons, qui contient un répertoire par addon, ainsi qu'un répertoire packages, qui contient des archives des addons téléchargés. Il est intéressant de regarder le code source des addons, car c'est dans celui-ci que j'ai compris qu'il stockait bien le nom d'utilisateur et le mot de passe.

Au même niveau que le répertoire addons, se trouve un répertoire nommé userdata. Celui-ci contient un répertoire addon_data, dans lequel il y a un répertoire par addon. L'addon dont je souhaitais voir la configuration y a laissé un répertoire à son nom, contenant un fichier de paramètres ainsi qu'un répertoire temporaire. Un petit "cat" sur le fichier de paramètres dévoile donc le Graal :

<settings>
    <setting id="OSpass" value="motdepasseenclair" />
    <setting id="OSuser" value="utilisateur" />
</settings>

En résumé, les paramètres d'un addon Kodi se trouvent dans ~/.kodi/userdata/addon_data/nomdeladdon/, dans un fichier nommé settings.xml. Le code source se trouve quant à lui dans ~/.kodi/addons/nomdeladdon/.

Comme quoi, j'ai vraiment raison de ne vouloir utiliser qu'un unique trio e-mail/utilisateur/mot de passe sur certains sites ou certaines applications.

17 nov. 2014

Relai de spam, cela n'arrive qu'aux autres ?

Ça y est. Le jour que je redoutais est arrivé : après plus de 7 années sans problème majeur, Another Home Page a été victime de l'exploitation d'une faille de sécurité. Ou, en tous cas, c'est la première dont je me rend compte ce qui n'est guère rassurant. Est-ce parce que j'ai tardé à appliquer des mises à jour sur mon serveur ? Non, il s'agit en réalité d'une faille applicative présente sur l'un des sites que j'héberge. Pour être exact, il s'agit de l'exploitation d'une faille de Drupal. Le site n'a pas été mis à jour assez tôt, et mon infra s'est retrouvée relai de spam, bien malgré moi !

Comment m'en suis-je rendu compte ? Deux éléments m'y ont aidé : d'une part la réception d'un mail de la part d'une organisation anti-spam, Junk Email Filter. D'autre part, certaines adresses mail de destination étant invalides, j'ai reçu des réponses de type "mailer-daemon" incluant le contenu du mail en pièce jointe. D'autres éléments auraient mérité plus d'attention de ma part, comme par exemple le nombre de requêtes sur une page donnée, le nombre de mails envoyés par mon serveur de mail et surtout le nombre de mails bloqués pour cause de spam.

Par la suite, j'ai averti la personne responsable du site victime, qui s'est empressée de mettre à jour son site. Hélas, comme le mentionne Next INpact, cela ne suffit pas. Sans rentrer dans le détail, décision a été prise d'effacer tous les sites web tournant sous Drupal. Et maintenant, je n'ai plus qu'à me refaire une réputation auprès des services de filtrage anti-spam...

Je n'ai d'ailleurs pris conscience que tard de la quantité impressionnante de mails que le spammeur a envoyé via mon infrastructure. Au moment de l'écriture de ce billet, je termine tout juste de purger la file d'attente de mon serveur de mails...

Que retenir de cet évènement ?

- Plus que jamais, les mises à jour de sécurité au niveau OS ne sont pas suffisantes. Il est crucial de mettre aussi à jour les applications web ;

- il est important de surveiller correctement ses services, en effet, le volume de mails dans la file d'attente aurait dû me mettre la puce à l'oreille ;

- Enfin, ma gestion des sauvegardes mériterait quelques améliorations...

14 mar. 2011

Configuration d'OpenSSH

OpenSSH est un logiciel formidable, tout le monde le sait. Quelque chose que j'aime beaucoup avec ce logiciel, c'est la manière dont son fichier de configuration permet de simplifier certaines opérations. Je vous propose de voir ou de revoir certaines options qu'on peut ajouter à la suite d'un bloc de configuration qu'on stocke généralement dans ~/.ssh/config .

La base

On va configurer l'accès à la machine "testdrive" dont l'adresse IP est 192.168.13.37. Commençons avec les informations de base :

Host testdrive
        HostName 192.168.13.37
        User nils
        Protocol 2
        Port 22
        ServerAliveInterval 5

Lorsque que je taperai la commande "ssh testdrive", OpenSSH me connectera à la machine 192.168.13.37 en tant qu'utilisateur nils, en utilisant la version 2 du protocole SSH, sur le port 22 et vérifiera toutes les 5 secondes si la machine en question est toujours joignable, ce qui peut s'avérer pratique dans certains cas où on peut être déconnecté du réseau pour cause d'inactivité (réseau de téléphonie mobile, proxy...)

Connexion au travers d'un proxy HTTP

ProxyCommand /usr/bin/corkscrew monproxy.lan 3128 %h %p ~/.ssh/proxy_auth

Ici, j'utilise un utilitaire nommé Corkscrew qui me permet de me connecter via un proxy HTTP à mon serveur. Dans mon exemple, le proxy écooute sur le port 3128 et nécessite une authentification, j'ai donc ajouté un fichier proxy_auth contenant les identifiants. Les variables %h et %p désignent l'hôte vers qui se connecter et son port. A noter que la plupart des serveurs proxy qu'on peut trouver sont configurés pour ne pas autoriser les ports autres que les ports HTTP, HTTPS, et éventuellement FTP. Il faudra donc peut-être changer le port d'écoute de notre testdrive, et mettre notre serveur SSH sur le port 80 ou 443. A noter que selon l'organisation qui administre le proxy, cette manière de faire peut être vue comme une violation de la charte informatique du réseau, ou de tout autre règlement intérieur. Ne l'utilisez donc que si vous y êtes autorisés !

Créer un tunnel SOCKS

DynamicForward 1080

Cette option est très pratique si vous ne voulez pas vous casser la tête à créer un tunnel VPN. Une fois cette option ajoutée à la configuration de votre hôte, et la connexion à celui-ci effective, un tunnel SOCKS écoute sur la boucle locale de votre machine, sur le port 1080. Un cas concret d'utilisation est la connexion à vos sites préférés depuis un point d'accès sans fil public, comme une gare : une fois connecté au réseau, on se connecte en SSH à son serveur, puis on modifie les paramètres de proxy de notre navigateur web pour utiliser un proxy SOCKS dont l'adresse est 127.0.0.1 et le port est 1080. Tout le trafic web du navigateur passe ainsi dans la connexion SSH. Si vous faites souvent le va-et-viens dans votre configuration de proxy, Firefox possède une extension nommée FoxyProxy qui vous facilitera l'existence !

Créer un tunnel pour rediriger du trafic

LocalForward 5901 192.168.13.38:5900

Encapsuler un trafic réseau dans SSH est quelque chose de connu, et l'exemple ci-dessus est lui aussi archi-connu : le protocole VNC transite en clair sur le réseau, l'utilisation de SSH permet de chiffrer la transmission entre notre client et notre serveur. On transfère donc le port 5900 de la machine 192.168.13.38 (qui doit être joignable depuis notre machine testdrive) vers le port 5901 local. On lance ensuite notre client VNC en direction la machine localhost sur le port 5901.

Spécifier l'algorithme de chiffrement

Ciphers aes128-cbc

De nombreux algorithmes de chiffrement sont disponibles avec OpenSSH, vous pourrez trouver la liste dans les pages de manuel. Certains processeurs (tels que l'AMD Geode LX ou le VIA C7) savent déchiffrer certains algorithmes, ce qui les rend plus rapide pour ces types d'opérations. Forcer le chiffrement en AES 128 si vous vous connectez à une machine ayant un CPU AMD Geode peut ainsi s'avérer très efficace pour limiter l'utilisation du CPU et alléger la charge.

17 janv. 2011

Vérifications de permissions - suite

Introduction : les astuces de ce billet sont extraites du document Guide to the Secure Configuration of Red Hat Enterprise Linux 5 édité par la NSA. Vous pouvez télécharger le document au format PDF dans son intégralité sur leur site. Cette introduction me permet d'être en conformité avec leur notice de Copyright.

Après les droits des répertoires et le sticky bit, amusons-nous un peu avec SUID et SGID : un fichier possédant l'attribut SUID ou SGID permet d'être lancé avec les droits de l'utilisateur ou du groupe qui a été placé, généralement root. Ainsi, le programme at, permettant de lancer une tâche à un moment donné, est accessible aux utilisateurs classiques alors que son fonctionnement nécessite des droits plus élevés. Ceci peut s'avérer risqué car si un programme SUID root possède une faille, celle-ci peut être exploitée avec les droits de root, même si l'attaquant n'a pas les droits.

Comme pour le sticky bit, commençons par vérifier notre environnement :

root@orgrimmar:~# whoami
root
root@orgrimmar:~# cat /etc/redhat-release 
CentOS release 5.5 (Final)

Recherchons maintenant tous les fichiers possédant un SUID ou un SGID :

root@orgrimmar:~# find / \( -perm -4000 -o -perm -2000 \) -type f -print
/bin/ping6
/bin/umount
/bin/ping
/bin/mount
/bin/su
/lib64/dbus-1/dbus-daemon-launch-helper
/usr/bin/wall
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/sudoedit
/usr/bin/chsh
/usr/bin/write
/usr/bin/at
/usr/bin/chage
/usr/bin/crontab
/usr/bin/ssh-agent
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/gpasswd
/usr/bin/locate
/usr/bin/screen
/usr/libexec/openssh/ssh-keysign
/usr/libexec/libvirt_proxy
/usr/libexec/utempter/utempter
/usr/kerberos/bin/ksu
/usr/sbin/userhelper
/usr/sbin/postqueue
/usr/sbin/postdrop
/usr/sbin/usernetctl
/usr/sbin/ccreds_validate
/sbin/netreport
/sbin/mount.nfs4
/sbin/umount.nfs4
/sbin/umount.nfs
/sbin/mount.nfs
/sbin/unix_chkpwd
/sbin/pam_timestamp_check
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/task/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
find: /proc/9859/fd/4: Aucun fichier ou répertoire de ce type
root@orgrimmar:~# 

Sur le coup, voir autant de lignes peut paraître effrayant, mais si on y regarde de plus près, on peut comprendre que 99% des fichiers indiqués aient besoin du SUID. Le seul qui m'inquiète, c'est screen. Je vais donc regarder sur une autre machine, bien différente cette fois-ci :

nils@tomb:~$ uname -sr
NetBSD 5.0.2
nils@tomb:~$ ls -hl /usr/pkg/bin/scree*
lrwxr-xr-x  1 root  wheel   12B Jul 11 11:23 /usr/pkg/bin/screen@ -> screen-4.0.3
-r-s--x--x  1 root  wheel  279K Jul 11 11:23 /usr/pkg/bin/screen-4.0.3*

On voit que screen sur ma machine NetBSD a aussi un bit SUID. C'est bon, je peux aller me coucher l'esprit tranquille :) Mais avant, revenons à notre serveur CentOS, et comme pour l'affaire du sticky bit, simulons un programme dont le SUID a été ajouté inutilement :

root@orgrimmar:~# cat > testbin
#!/bin/bash
echo -n "Je suis un programme SUID de test"
exit 0
root@orgrimmar:~# chmod -v +x testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# ls -hl testbin 
-rwxr-xr-x 1 root root 63 déc 31 00:44 testbin*
root@orgrimmar:~# chmod -v +s testbin 
Le mode d'accès de `testbin' a été modifié à 6755 (rwsr-sr-x).
root@orgrimmar:~# ls -hl testbin 
-rwsr-sr-x 1 root root 63 déc 31 00:44 testbin*

Relançons notre recherche :

root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
/root/testbin

Supprimons maintenant le SUID et relançons la recherche :

root@orgrimmar:~# chmod -v -s testbin 
Le mode d'accès de `testbin' a été modifié à 0755 (rwxr-xr-x).
root@orgrimmar:~# find /root \( -perm -4000 -o -perm -2000 \) -type f -print
root@orgrimmar:~# 

Et voilà, nous sommes tranquille :)

Que faire si j'ai un doute sur un programme ? Plusieurs possibilités : s'il s'agit d'un programme qui est fourni par les paquets de votre distribution, on peut toujours aller vérifier sur d'autres machines, dont l'OS ou la distribution peut différer (comme je l'ai fait avec screen); un même programme nécessitant le SUID sur 2 OS différents peut légèrement rassurer. Si le logiciel est libre (exemple : GNU screen :D), on peut aussi aller chercher dans les fichiers de création du paquet binaire, pour les RPM il suffit de chercher le SRPM du logiciel et de l'installer sur une machine de test. Ensuite, on regarde le contenu du fichier .spec qui sert à la création de ce paquet : en effet, ces fichiers contiennent la liste et les droits des fichiers et répertoires du paquet que l'on veut compiler :) Si un .spec n'indique pas que le programme est SUID, alors il est temps de s'inquiéter !

Propulsé par Dotclear