> Tech > Déchiffrer la sortie

Déchiffrer la sortie

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Avant de nous plonger dans l'information fournie par le rapport, il faut comprendre ce qui constitue une vulnérabilité pour l'usurpation de User profile.
Si j'ai même des droits *USE ou mieux (*CHANGE *ALL, par exemple) sur le profil utilisateur de quelqu'un d'autre, je peux usurper son profil et m'en servir

Déchiffrer la sortie

pour exécuter des
commandes et des processus batch. Il me suffira d’exécuter
une commande SBMJOB spécifiant le nom de l’autre profil
utilisateur dans le paramètre USER, comme dans

SBMOBJ CMD(CPYF FROMFILE(PAYROLL)
TOFILE(*PRINT) USER(OTHERUSER)

(où OTHERUSER est un profil sur lequel j’ai au moins l’autorité
*USE). Cette commande soumet un job batch à  exécuter
sous le profil utilisateur OTHERUSER et peut imprimer les
enregistrements dans le fichier de paye (auquel je n’ai pas
accès, contrairement à  OTHERUSER).
Une autre méthode d’usurpation, un peu plus complexe,
consiste à  utiliser les API du profil User Profile Swap fournies
par IBM pour définir mon job courant pour qu’il s’exécute
sous l’autorité d’un profil utilisateur différent. (Ces API
(QSYSGETPH et QWTSETP) sont documentées dans l’iSeries
Information Center à  http://publib.boulder.ibm.com/iseries/
v5r2/ic2924/info/apis/QSYSGETPH.htm et http://publib.
boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QWTSETP.
htm.
Si j’ai au moins l’autorité *USE sur d’autres profils
utilisateur, c’est que j’ai les droits suffisants pour utiliser ces
profils pour effectuer un travail pour le compte de ces
utilisateurs. Je peux soumettre des jobs batch pour leur
compte ou permuter dynamiquement mon job pour qu’il
s’exécute sous leur profil au lieu du mien. Ce faisant, j’usurpe
et utilise leurs autorités OS/400. Si j’ai l’autorité *USE ou
mieux sur un autre profil, je n’ai même pas besoin de
connaître les mots de passe des utilisateurs victimes pour
exécuter des commandes et des jobs comme si j’étais eux.
Forts de tout cela, revenons à  la figure 1. On observe plusieurs
profils utilisateur imprimés en rouge. L’autorité *PUBLIC
sur eux est *USE ou supérieure, donc je peux usurper
n’importe quel profil affiché en rouge. Particulièrement important
: *PUBLIC a l’autorité *USE sur le profil utilisateur
QSECOFR. Cela permet à  n’importe quel utilisateur d’exécuter
des commandes et des jobs comme QSECOFR, le profil
utilisateur le plus puissant du système, et cela me donne la
possibilité de faire n’importe quoi sur cette machine. C’est
une situation particulièrement dangereuse que j’ai rencontrée
fréquemment en production dans des entreprises de
toutes tailles.
La figure 2 contient toutes les autorités, à  la fois publiques
et privées. Dans ces profils sélectionnés, vous constaterez
que *PUBLIC (en rouge) a l’autorité *USE sur les deux
profils de ce rapport, donc n’importe qui sur le système
pourrait usurper l’un ou l’autre. Mais vous pouvez aussi noter
(en rouge) que les profils individuels PRTACRX et
DRIEHL ont l’autorité *ALL sur un profil utilisateur. Cette situation
permet à  ces utilisateurs d’usurper AXXGEDS et QSECOFR
pour effectuer un travail sous l’autorité de leur propre
profil.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010