Bonjour,
Le conteur incrémente son compteur. Un vieux Microsoft Windows 2000 serveur, qui fût en quelque sorte livré avec les murs, compromis depuis des années - toute la boite le savait mais personne n'osait - de peur que tout s'écroule. Après avoir désactivé les fonctionnalités d'un rootkit connu depuis la saint-glinglin, voici qu'apparait des fichiers, des processus, des connexions,.. Bref, la routine en quelque sorte, si ce n'est l'usage d'une méthode de "résurrection" assez rigolote, compte tenu de l'époque.
Le répertoire $ était masqué par le rootkit.
C:\$>cacls c:\$\bin\.ttc
Accès refusé.
Pourtant, les droits sont corrects.
C:\$>cacls bin
C:\$\bin BUILTIN\Administrateurs:(OI)(CI)F
AUTORITE NT\SYSTEM:(OI)(CI)F
BUILTIN\Utilisateurs:(CI)(accès spécial :)
SYNCHRONIZE
FILE_WRITE_DATA
FILE_APPEND_DATA
BUILTIN\Utilisateurs:(OI)(CI)R
Le listing ne donne rien.
C:\$>dir /a bin
Répertoire de C:\$\bin
Fichier introuvable
Le listing de $ nous en apprends +
C:\$>dir
Répertoire de C:\$
01/01/200? 00:00 <REP> .
01/01/200? 00:00 <REP> ..
01/01/200? 00:00 <JONCTION> bin
Il s'agit d'un point de jonction NTFS.
À nuancer des liens symboliques que vous connaissez ( voir mklink )
L'accès refusé vient du fait que les ACL des points diffèrent de ceux de la cible.
Les versions récentes de Windows, gèrent bien l'affichage depuis l'explorateur
de fichiers ainsi que l'interpréteur de commandes, par exemple, la commande
DIR affiche correctement entre crochets la cible d'une jonction, ce qui n'était
pas du tout le cas pour Windows 2000 serveur. Il fallait utiliser des outils.
Identification du point d'analyse.
C:\$>fsutil reparsepoint query bin
Valeur de la balise d'analyse : 0xa0000003
Valeur de balise : Substitut de nom
Valeur de la balise : Point de montage
GUID : {00??0000-00??-0000-??00-??00??00??00}
Longueur des données : 0x00000022
Données d'analyse :
0000: 63 00 3a 00 5c 00 24 00 5c 00 24 00 24 00 00 00 c.:.\.$.\.$.$...
0010: 00 00 ad ba 0d f0 ad ba 0d f0 ad ba 0d f0 ad ba ................
0020: 0d f0 ..
Suppression du point d'analyse.
C:\$>fsutil reparsepoint delete bin
Même si les points ont été supprimés, il faut également éliminer les originaux.
Un mécanisme pourrait ( et c'était le cas ) détecter et régénérer les points manquants.
Affiche les permissions. ( l'origine du "Accès refusé" ).
C:\$>cacls c:\$\$$
c:\$\$$ AUTORITE NT\UTILISATEUR TERMINAL SERVER:(OI)(CI)F
Modifie les permissions.
C:\$>cacls c:\$\$$ /G Administrateur:F
Êtes-vous sûr (O/N) ?o
répertoire traité : c:\$\$$
Cette fois, le listing fonctionne.
C:\$>dir /a bin
Répertoire de C:\$\bin
01/01/200? 00:00 874 631 .ttc
Suppression de la cible.
C:\$>del /f /q "c:\$\$$\.ttc"
Je ne pense pas trop me tromper en disant qu'une majorité des administrateurs de l'époque ( il y a ~ 6 ans ) ne devaient pas maitriser, aussi bien qu'aujourd'hui, ce type de spécificités sur NTFS. Ces intrus étaient peut être abonnés aux newsletters de chez Redmond...
Liens connexes:
→ Windows 10^H^H Symbolic Link Mitigations : Abusing symbolic links like it's 1999!
Point de jonction NTFS sur répertoire avec ACL
-
- Sujets similaires
- Réponses
- Vues
- Dernier message
-
- 18 Réponses
- 430 Vues
-
Dernier message par Malekal_morte
-
- 5 Réponses
- 249 Vues
-
Dernier message par Loriot8/3
-
- 1 Réponses
- 20 Vues
-
Dernier message par Parisien_entraide
-
- 2 Réponses
- 449 Vues
-
Dernier message par lacosta
-
-
Suppression point de restauration d'image système [résolu]
par gandalf2b » » dans Windows : Résoudre les problèmes - 12 Réponses
- 290 Vues
-
Dernier message par Malekal_morte
-