SecurityInsider
Le blog des experts sécurité Wavestone

Introduction à la sécurité des mainframes - Partie 2



Après une présentation générale des mainframes et des aspects sécurité, ce 2ème article présente une première approche pour la réalisation de tests d'intrusion sur un mainframe.

Premiers pas – reconnaissance

Le premier réflexe de tout pentester lorsqu’il se connecte au réseau d’une entreprise est d’entamer un scan de port sur la machine cible. Un scan nmap est certes efficace et liste bien les ports ouverts sur le Mainframe, mais est loin de fournir l’ensemble des applications déployées sur ce dernier.

Un scan de port peut fournir un résultat qui ressemble à la figure suivante :


La base de données locale de l’outil Nmap est légèrement décalée par rapport à l’actualité, en effet c’est la version 1.13 du système d’exploitation Z/OS et non OS/390 qui est installée sur la cible.

Deux services intéressants sont présents sur cette machine : Telnet et FTP.

Le service Telnet affiché est généralement une interface VTAM acceptant des connexions depuis un terminal 3270. VTAM est un module d’interfaçage avec le protocole SNA développé par IBM et principalement utilisé pour la communication entre Mainframes et périphériques internes :


Autrement dit, VTAM est une sorte de point d’entrée qui permet de contacter des applications déployées sur un ou différents mainframes interconnectés (en mode sysplex). S’en suit donc qu’un seul service exposé sur le réseau (port 23), permet de contacter plusieurs applications : TSO, CICS, IMS, etc.

La commande IBMTEST entre autres, est caractéristique de VTAM et fournit ainsi un moyen sûr de l’identifier.



L’émulateur x3270[1] permet de simuler le comportement d’un terminal 3270 et de se connecter sur VTAM. Le protocole employé (TN3270) correspond à une version propriétaire du protocole Telnet. Le trafic transite donc en clair sur le réseau.

Une fois sur l’interface VTAM, il est possible de se connecter aux applications déployées sur le Mainframe en renseignant un identifiant unique à 8 caractères maximum (APPLID). Selon la configuration du Mainframe et de son usage au sein de l’entreprise, une liste des APPLID exposées peut être directement renseignée sur VTAM.

Pour les Mainframe les moins verbeux, Dominic White fournit un outil[2] sur github permettant d’énumérer les APPLID sur VTAM.

La connexion à ces applications peut bien évidemment nécessiter une authentification. Dans certains cas cependant, il est possible d’accéder à un nombre intéressant de menus et de fonctionnalités sans authentification aucune.

TSO

L’une des applications accessibles par défaut depuis VTAM est TSO. Celle-ci permet de mener à bien les tâches quotidiennes des développeurs et administrateurs : soumission de jobs, création d’utilisateurs, définition des règles d’accès, développement des applications, etc. (~ au SSH Telnet sur Unix).

Compte par défaut

Les identifiants du compte par défaut sont (IBMUSER : SYS1) et dans le cas idéal, ce compte n’a pas été désactivé et dispose toujours des plus hauts privilèges sur le système.

Bruteforce

La première fonctionnalité intéressante de TSO est que le message d’erreur permet d’identifier les comptes utilisateurs valides. Un outil[3] d’énumération a été développé par Phill Young en se basant sur une wordlist de noms de comptes prévisibles.


La particularité de cet outil est qu’il se base sur des appels de sockets directs afin d’optimiser les requêtes de connexion, contrairement à un script développé à la hâte en se basant sur la bibliothèque py3270.

Interception réseau

Outre une attaque par bruteforce il est possible de mener une écoute réseau afin d’intercepter des identifiants transitant en clair sur le réseau.
Wireshark sait prendre en charge l’encodage par défaut sur Z/OS (EBCDIC[4]) et permet de retrouver les identifiants de l’administrateur réseau :


Note : Le charset EBCDIC précède l’ASCII et contrairement à ce dernier, encode les caractères sur 8 bits. La lettre A est ainsi représentée par le nombre 0x55 au lieu de 0x41 (ASCII).

Élévation de privilèges

Récupération d’informations sensibles

Une fois que l’accès à la console TSO a été établi (via interception réseau, mot de passe évident, audit en mode boite grise, etc.), nous nous retrouvons avec l’invite de commande suivant :


Il est possible de lancer des commandes réseaux classiques type ping, nestat et nslookup afin de récupérer la configuration de la pile TCP/IP du Mainframe.

La liste des utilisateurs présents sur le système peut être récupérée via la commande Listuser (LU) :


Comme dans tout test d’intrusion classique, l’étape suivante consiste à récupérer des informations sensibles en parcourant des datasets (fichiers) à la recherche de données clients, authentifiants de la base de données, authentifiants propres à d’autres applications etc.

Ceci peut être effectué via TSO, mais un utilitaire plus convivial est recommandé : ISPF.


En naviguant dans l’option 3.4 (Utilities ->Dslist), il est possible d’effectuer des recherches basées sur le nom du dataset en renseignant le paramètre Dsname Level[5].

Les fichiers sur Z/OS sont catalogués sous forme d’arborescence suivant des noms qualifiés, à la manière d’une arborescence DNS. Il n’existe donc pas de notion de répertoire comme dans l’environnement UNIX/Windows.

Le catalogue des utilisateurs, qui correspond finalement au répertoire personnel des utilisateurs commence par un High Level Qualifier égal au nom de l’utilisateur.

Une recherche sur les fichiers commençant par ‘SOLU.*’ par exemple renverrait l’ensemble des fichiers présents dans son catalogue personnel.


Certains types de fichiers qu’il est intéressant d’inspecter :

  • Les fichiers personnels des utilisateurs (de préférence administrateurs),
  • Les fichiers de backup (HQL : BAKCUP.*),
  • Les fichiers JCL (HQL : JCL.* ou USERNAME.JCL.*) : qui contiennent du code applicatif,
  • Les fichiers REXX (HQL : REXX.* ou USERNAME.REXX.*). Rexx étant un langage de scripting très populaire sur Z/OS,
  • Le dataset SYS1.UADS peut contenir des noms d’utilisateurs non définis dans RACF.

...via Unix

Tout système Z/OS inclut de facto un composant USS (Unix System Services), qui est une variante du système d’exploitation UNIX. Ce composant optimise l’interopérabilité de Z/OS avec le monde dit « open » en prenant en charge par exemple la pile TCPIP, les services FTP, HTTP, OpenSSH, SDK pour Java etc.

Il est possible d’obtenir un shell Linux en lançant la commande suivante sur TSO : OMVS

Mauvaise configuration des classes BPX.*

Les droits hérités sur l’environnement Unix dépendent du segment USS assigné au profil RACF, mais également des droits positionnés sur certaines classes génériques.

Une base RACF non durcie peut ainsi assigner le même segment (BPX.DEFAULT.USER) à l’ensemble des utilisateurs habilités à utiliser OMVS, leur conférant un identifiant générique (parfois root) sur l’environnement UNIX.

Par ailleurs, des droits d’accès permissifs sur la classe BPX.SUPERUSER peuvent conférer le droit root à tout utilisateur faisant appel à la commande su. Il est donc toujours intéressant de tester les droits hérités sur l’environnement UNIX dans le but de valider un scénario d’escalade verticale.

Exploitation de failles

Les failles présentes sur les environnements UNIX classiques peuvent être également présentes sur la partie Unix du Mainframe. Cependant, IBM ne publie pas les détails des vulnérabilités trouvées ni le détail des correctifs. Lorsqu’il s’agit de vulnérabilités critiques le processus de mise à jour est géré directement avec le client[6], si ceux-ci ont souscrit à l’offre de suivi des alertes de sécurité.

Dans le cas de l’incident Logica par exemple, les attaquants auraient a priori exploité deux vulnérabilités zero day présentes sur la partie UNIX :

  • Une faille sur le serveur Web IBM afin d’exécuter des commandes : CVE-2012-5955[7];
  • Une élévation de privilège sur le système UNIX en exécutant un fichier portant un setuid égale à 0 - CVE-2012-5951[8].

Une reconstruction du second exploit en se basant sur les documents diffusés suite à l’investigation de l’attaque a été effectuée par Phil Young (@mainframed767). Le script Geroot.rx[9] permet ainsi d’acquérir les droits root sur l’environnement Unix en prenant comme paramètre un exécutable setuid présent sur le système :


La faille a été corrigée sur les systèmes et versions concernées (Z/OS V1R4 à V1R13) par IBM.

Conclusion

Ce second article présente une première approche générique que l’on pourrait adopter face à un Mainframe. Les articles suivants de la série feront plus le focus sur des produits spécifiques que l’on peut retrouver sur un Mainframe.

Références :
http://packages.ubuntu.com/search?keywords=x3270
http://www-01.ibm.com/software/awdtools/ispf/library/
https://github.com/singe/mainframe_brute
https://github.com/mainframed/MainTP
http://mainframed767.tumblr.com/post/98817247737/ibm-mainframes-and-their-silence-on-security
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5955
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-5951
http://soldieroffortran.org/downloads/getroot.rx
Ayoub ELAASSAL

Aucun commentaire:

Enregistrer un commentaire