22/11/01
Vulnérabilités
en série dans les systèmes d'administration sécurisée
SSH
Avec SSH
(Secure SHell), l'administrateur se sent a priori en
sécurité pour travailler à distance
sur les systèmes qu'il a en charge. Et pour cause:
ce protocole TCP/IP (port 22, lire notre questions/réponses
sur les protocoles réseaux) lui permet d'établir
une connexion à distance équivalente à
Telnet, mais avec une composante forte d'authentification
et de chiffrement des données échangées.
En théorie, le tunnel établi de part en
part d'Internet est imperméable à tout
attaquant. D'autre part, le transfert des mots de passe
ne s'effectue pas en clair. Mais aussi, ce n'est qu'en
théorie que SSH suffit pour maintenir un véritable
niveau de confiance. Un avertissement qu'avait déjà
formulé Anthony C. Zboralski dans son interview
publiée début novembre.
Ces deux dernières semaines, toute une série
d'alertes au sujet de SSH ont été diffusées
par les organisations de veille en matière de
sécurité informatique les plus en vue.
Le bilan n'est donc pas aussi positif qu'on pourrait
le croire à l'égard de ce protocole, ou
plutôt de sa version 1.0 et de certaines de ses
implémentations dans des produits finis (SSH
Communications Security, F-Secure, OpenSSH, Cisco 11000,
Sun Solaris, RedHat Linux...). L'équipe du Cert
(Computer emergency response team) américain
au sein de l'université Carnegie Mellon indique
une augmentation conséquente du nombre de rapports
qui lui parviennent au sujet de "scans" sur
le port TCP/IP 22. Les "scans" de ports, qui
correspondent à des tentatives de récupération
de données en vue d'une exploitation ultérieure,
sont un moyen très usité des hackers pour
détecter la façon de pénétrer
des systèmes.
Au
moins trois vulnérabilités répertoriées
La note
d'incident (où figure la liste des actions
à la disposition du responsable sécurité)
du Cert
fait état de l'exploitation d'un dépassement
de la mémoire tampon dans le sous-système
de détection d'attaque CRC-32.
Pour
parvenir à ses fins, le hacker recommence jusqu'à
ce qu'il parvienne à entrer, ce qui résulte
en une série de messages apparaissant dans les
fichiers logs. Plusieurs phénomènes ont
été observés ensuite sur les systèmes
ciblés: modification des utilitaires systèmes
standards en vue de cacher les faits et gestes de l'intrus,
remplacement du programme SSH lui-même par une
version modifiée contenant un cheval de Troie,
et présence d'outils destinés à
lancer des "scans" sur d'autres systèmes.
Dans son
propre bulletin d'information, le CIAC
(Computer incident advisory capability), dépendant
du ministère américain de l'énergie,
rappelle que cette vulnérabilité a été
découverte initialement en février 2001
par un
expert de la société Bindview. Mais
celui-ci n'avait alors pas été pris au
sérieux, des doutes subsistant quant à
la possibilité réelle d'exploiter la faille.
Et le CIAC de mentionner un second type d'attaque, qu'il
qualifie de complexe, touchant cette fois-ci la version
1.5 du protocole SSH. Découverte par la société
Core SDI,
celle-ci permettrait de récupérer la clef
de chiffrement pour accéder aux sessions en cours.
Enfin, selon
le prestataire spécialisé SecuriTeam,
l'association de OpenSSH sous OpenBSD 2.9 avec le système
de mot de passe S/Key pourrait donner au hacker, après
certaines sollicitations, un accès à des
informations susceptibles de l'assister dans la pénétration
du système visé.
Au final, l'administration vraiment sécurisée
ne serait-elle qu'un mythe ? Pas obligatoirement. En
revanche, l'idée qu'un système sécurisé
puisse protéger de toutes les tentatives de détournement
ou d'intrusion reste dangereuse. Concernant les problèmes
liés à SSH 1.0 et 1.5, le CIAC suggère
de passer à la version 2.0 du protocole disponible
en version finale, et indique tout comme le Cert où
trouver des correctifs. Mais cette démarche ne
dispense pas d'une approche plus "globale"
de la sécurité.
|