Version imprimable
Donc ce que tu me dis c'est que je n'ai pas de moyen direct, ni indirect de lancer un programme depuis une machine distante ?
J'trouve ca fou qu'on ne puisse pas lancer d'executable à distance, dont la sortie visuelle est la machine cliente... En quoi cela est une faille ? Y'a un truc que je comprends pas ^^
Merci de tes infos cependant, je planche dessus !
si tu peux en créant d'abord un binaire qui agisse comme psexecsvc sur la machine distante, le service qu'installe psexec à distance. Les services peuvent être lancés à distance, il se lance dans la session winsta 0, alors que l'utilisateur connecté est en winsta 1 (la session interactive locale).
Ce service est capable d'instancier un programme en utilisant createprocessasuser sur la machine locale. Si l'utilisateur en question est celui de la session interactive alors la fonction lance le processus dans la session winsta 1. si le service de détection de services interactifs est lancé (windows 7) l'utilisateur voit une boîte de dialogue lui indiquant qu'un programme veut interagir avec le bureau, si l'utilisateur accepte le gui se lance.
Et oui c'est une faille de sécurité (shatter attack) qui permettrait d'implémenter du code dans un des tes processus à partir d'un appel distant.
Pour rappel l'architecture windows est ainsi:
Sessions winstations (winsta) - > collection de bureaux et collection de processus
Donc en haut de l'arborescence des environnements windows on trouve la winstation (session terminal server). Dans winxp les services et le premier utilisateur était dans la même session winstation (la winsta 0). Lorsque la possibilité d'injecter du code dans un autre processus est apparue dans le monde windows, cette architecture a compromis la sécurité de l'ensemble.
Raison pour laquelle dans vista et seven les services on été isolés en session 0 et l'utilisateur interactif en session 1, avec un service dédié pour assurer la compatibilité des anciens programmes xp avec l'architecture 7.
Pour WMI c'est pareil, lors d'un appel distant il est invoqué dans une session à part. en fait le but est d'empêcher aux programmes lancés à distance d'accéder à winsta 1.
Donc l'astuce de contournement consiste à disposer d'un programme local à l'écoute de commande réseau et lançant des programmes dans la session interactive via le service de détection des services interactifs. Ainsi le programme n'est plus lancé à distance mais localement et dans la session des services, car seule cette session est écoutée par le service de détection des services interactifs qui demandera à l'utilisateur connecté l'autorisation d'envoyer la sortie du programme sur la session 1.
Je viens d'essayer une commande pour justement retourner en local. Le programme ne s'est pas executé en mode interactif. Ceci dit, ma méthode ne devait certainement pas être bonne (vu le resultat), et j'aimerais savoir si c'est ce à quoi tu pensais:Citation:
Donc l'astuce de contournement consiste à disposer d'un programme local à l'écoute de commande réseau et lançant des programmes dans la session interactive via le service de détection des services interactifs. Ainsi le programme n'est plus lancé à distance mais localement et dans la session des services, car seule cette session est écoutée par le service de détection des services interactifs qui demandera à l'utilisateur connecté l'autorisation d'envoyer la sortie du programme sur la session 1.
Depuis ma machine Linux, j'execute Winexe (Psexec Like ~) qui s'authentifiait avec le compte actif de la machine Windows. Il avait comme paramètre --interactive=1 (même resultat pour 0), --ostype=1 (x64). Winexe allait chercher psexec sur la machine Windows, qui lui allait executer server.exe.
Tu pensais a une méthode ressemblant à celle-ci (mais en mieux) pour executer server.exe en interactif ?
Je dois t'avouer que tu m'as perdu un peu avec tes explications (pourtant importante !). Est-ce si compliqué que ca ?
De plus, j'utilise deja WMIC pour des requetes que j'effectue au prealable. Tu me confirmes qu'on ne peut pas demarrer de programme de manière interactif avec cet outil ?
je confirme que wmic ne peut pas lancer de programmes interactifs.
pour ton test je ne sais pas si ça peut marcher mais lors de l'appel de psexec tu dois passer le commutateur pour interactif (-i je crois).
Sinon la piste que je te propose mais qui est longue à mettre en oeuvre consiste à utiliser wmic pour lancer 2 services surt la cible:
- un service personnalisé orienté réseau à distance
- le service de découverte des services interactifs de MS.
Ton service personnalisé va écouter un port réseau pour recevoir la chaine de commande à exécuter puis va utiliser la fonction createprocessasuser et enumeratesessions pour trouver l'utilisateur connecté en session interactive et lancer le processus qui t'intéresse.
Le service de détection des services interactifs va alors voir qu'un service de la session winsta 0 veut dialoguer avec la session winsta 1 et va donc envoyer une boîte de dialogue à l'utilisateur interactif pour qu'il accepte. Une fois validé le gui va se lancer sur la machine cible.
Et si tu ne veux pas développer le service personnalisé utilise le binaire psexecsvc, c'est lui qui fait ça dans psexec. Je pense qu'avec un petit procmon, regmon et wireshark il est possible de comprendre comment interagir avec lui. Pour récupérer psexecsvc lance psexec sur une machine distante et cherche sur cette machine ce fichier
PSEXEC doit suivre à peu près ce schéma au vu des docs que j'ai pu lire là dessus:
-copie sur la machine cible psexesvc via les partages administratifs (un simple push puis copy)
-enregistrement de psexesvc comme service sur la machine cible (ça je ne sais pas en ligne de commande, je pense qu'avec du wmic on doit pouvoir EDIT avec sc create ou wmic service create)
-utilisation de la commande sc pour lancer le service depuis la source sur la machine cible (commande sc ou wmic service call startservice )
-le service une fois lancé ouvre un socket réseau et l'écoute (là il va falloir descendre dans l'api ou faire du powershell avec les classes tcpclient)
- ouverture d'un socket réseau vers la machine cible depuis le serveur source et passage d'une chaîne de texte qui est la ligne de commande à exécuter sur la machine cible (idem)
- le service psexesvc reçoit la commande et l'enregistre
- le service psexesvc identifie les sessions actuels et trouve la session interactive et l'utilisateur dessus (c'est une fonction de l'api qui s'appelle wtenumeratesessions je crois)
- utilisation de la fonction createprocessasuser pour lancer la commande préalablement enregistrée
A partir de là si le service de découverte des services interactifs est lancé sur la machine cible, il intercepte l'appel du service psexesvc, demande à l'utilisateur actif d'accepter les messages de la session 0, puis redirige la sortie du programme lancé vers la winsta 1
EDIT: ici ils indiquent une astuce pour récupérer psexecsvc
http://forum.sysinternals.com/old-ps...opic13705.html
Salut,
Y a un truc qui n'est pas clair, là :
Est-ce que ça n'est pas plutôt ça :Citation:
Envoyé par SuperKnacky
que tu veux dire ?Citation:
J'veux juste, depuis une machine Linux, faire exécuter sur une machine Windows un processus qui s'appelle server.exe et que l'interface graphique de l'application soit visible.
Auquel cas cette phrase et celle de ton exemple avec "calc" sont en phase.
Si tu sais coder, tu pourrais implémenter un couple client/serveur en TCP (y a des millions d'exemples sur le Web dans tous les langages),
le client Linux envoyant des chaînes au serveur Windows et celui-ci réagissant en fonction du contenu de la chaîne,
par exemple le client envoie "calc" et le serveur écrit en Delphi va exécuter (pseudo-code) ShellExecute('calc.exe', params);
c'est déjà ce qu'il fait mais il est confronté aux sécurités de windows dans ce domaine. le problème est qu'il souhaite interagir avec la session interactive
T'es sûr de ça ? Je ne l'ai pas vu écrit (ou alors j'ai lu en diagonale ?).Citation:
Envoyé par Benjîle
Il parle beaucoup de lancer un exe et d'avoir l'IHM visible (pour le user je suppose)...
Parce que s'il s'agit de "prendre la main", y a plein d'outils (UltraVNC, TeamViewer, etc.) pour ça, non ?
si j'ai bien compris le but est d'envoyer des commandes depuis un serveur sur une batterie de clients qui ouvre un GUI sur les bureaux des utilisateurs connectés localement.
Dans ce cadre, la seule façon d'éviter le problème de l'isolation de session est de faire comme je le propose avec un service qui demande des interactions avec le bureau via le service détection des services interactifs. ceci par ailleurs semble impossible en .NET, car les services .net ne peuvent interagir avec le bureau selon msdn. Donc ici c'est du vbs ou du c++obligatoire
Soit comme vous le suggérez avec un programme démarré à l'ouverture de session de l'utilisateur (et donc s'exécutant dans la même session winsta que l'utilisateur local) qui écouterait le réseau pour lancer des commandes dans l'environnement de l'utilisateur. Certains programmes fonctionnent ainsi. De plus dans ce cas cela peut être du .net. Perso j'opterai pour un petit script powershell ou vbs.
Bonjour,
Désolé pour le retard de la réponse, wkd chargé ...
Ce que je veux, c'est que depuis une interface web, cliquer sur un bouton "Server" qui ira lancer chez les machines que j'ai selectionné dans l'interface l'application server.exe localement sur les machines.
Le serveur n'est la que pour "ordonner" au machines esclaves :aie: de lancer l'application Server.exe. (et que l'interface graphique de server.exe soit aussi presente sur la machine esclave.)
@Benjîle, Je vois bien ce que tu veux que je fasse, mais ca risque d'etre un peu compliquer, enfin ca va prendre du temps !
J'voyais ca beaucoup plus simple pour lancer une application sur une machine distante ... Ok l'histoire des sessions, mais un outils aurait été sympa...
est que tu as un serveur windows dans ton parc?
les clients sont des xp ou des seven?
Oui, j'ai un serveur Windows 2k3. Et mon parc est constitué en quasi-totalité de Win7. Mais nous avons encore des résidus de WinXP récalcitrant ^^
si tu peux t'appuyer sur le serveur 2003 la solution est beaucoup plus simple:
depuis ton serveur linux via wmic tu lances le processus psexec sur le serveur en lui passant la ligne de commande qui exécute le programme sur tes clients
en gros en ligne de commande wmic ca donnerait (en gros)
ouCode:
2
suivant ce que prends ta ligne de commande wmic de linuxCode:WMIC /node:server2003 PATH Win32_Process call create "c:\tools\psexec.exe \\ordi1,ordi2 -i server.exe"
Salut Benjîle,
Je viens de regarder ta proposition, qui pourrait me convenir. Sauf que le /node n'existe pas dans ma version de wmic en ligne de commande.
Mais je vois que ca existe sur le WMIC du 2k3 ... étrange ... Pourtant me semblait que c'etait les même versionCitation:
Usage: [-?|--help] [--usage] [-d|--debuglevel DEBUGLEVEL] [--debug-stderr]
[-s|--configfile CONFIGFILE] [--option=name=value]
[-l|--log-basename LOGFILEBASE] [--leak-report] [--leak-report-full]
[-R|--name-resolve NAME-RESOLVE-ORDER]
[-O|--socket-options SOCKETOPTIONS] [-n|--netbiosname NETBIOSNAME]
[-W|--workgroup WORKGROUP] [--realm=REALM] [-i|--scope SCOPE]
[-m|--maxprotocol MAXPROTOCOL] [-U|--user [DOMAIN\]USERNAME[%PASSWORD]]
[-N|--no-pass] [--password=STRING] [-A|--authentication-file FILE]
[-S|--signing on|off|required] [-P|--machine-pass]
[--simple-bind-dn=STRING] [-k|--kerberos STRING]
[--use-security-mechanisms=STRING] [-V|--version] [--namespace=STRING]
[--delimiter=STRING]
//host query
c'est le //host de ta ligne de commande je présume:
//server2003
Je viens d'essayer ta commande en 2 temps.
=> Le fait d'executer depuis le serveur Linux, vers le serveur Windows pour les machines clientes (je sais pas si tu me suis ...). Je prends une erreor type "ERROR: Retrieve result data". Certainement dur a une incompréhension d'utilisation du soft de ma part parce que j'utilise le compte Administrateur du Domaine
La commande qui ne fonctionne pas :
=> Le fait d'executer depuis le serveur Windows vers les machines clientes fonctionnent plutôt bien.Citation:
./wmic -U domaine\ADMUSER%PWD //target "process call create 'c:\psexec.exe \\host -u domaine\ADMUSER -p PWD -i server.exe'"
La commande qui va bien
Maintenant je dois revenir à mon 1er point, c'est a dire cumuler les 2 outils pour qu'ils agissent ensemble ...Citation:
Psexec.exe -d (pour ne pas attendre) \\target -u domain\user -p PWD -i server.exe
On avance bien ! Merci !
je pense que dans ta ligne de commande Linux ce n'est pas "process call create" qu'il faut utiliser, car process est un alias de win32_process dans la ligne de commande wmic de windows. Donc du coup peut être que ton linux t'explique que la classe cherchée n'existe pas.
La ligne exemple que je t'ai proposé est fictive, je ne connais pas la ligne de commande wmic linux
Je regarde si je peux trouver des exemples avec ta ligne de commande
Dak, je fais de même de mon côté.
Par contre, je ne suis pas sur (et certainement pas expert, donc ce n'est qu'un avis ^^) que le problème viennent de "process call create", puisque c'est wmic qui exécute ca sur la machine hôte ?
et non
ton wmic linux doit invoquer la classe win32_process pour appeler la méthode execute qui aura comme paramètre:
'c:\psexec.exe \\host -u domaine\ADMUSER -p PWD -i server.exe'"
le mot process n'est connu que par la ligne de commande wmic de windows
Ah, ok. Mon avis se basait sur ces exemples, sauf qu'en fait c'est du "requêtage" ...
http://www.krenger.ch/blog/wmic-on-linux-examples/
dans cette page il n'y a aucun exemple d'appel de méthode wmi
il faut fouiller pour voir si le client en est capable