[..] Information cryptage mot de passe et compilation

[win43]

Tout d'abord bonjour à tous et merci pour cette aide francophone sur ce fabuleux Autoit !

Je suis administrateur système et réseau, j'utilise essentiellement les scripts autoIt pour le déploiement de logiciels et de taches d'administration sur les postes clients. Mes scripts sont très simples et j'arrive à me dépatouiller en farfouillant dans le forum ou sur le net.

J'ai en faite une problématique : La plupart de mes scripts lance simplement une install silencieuse en admin du domaine, ex :

Code : Tout sélectionner

If FileExists("C:\Program Files\PDFCreator") Then
    Exit
EndIf
If FileExists("C:\Program Files (x86)\PDFCreator") Then
    Exit
Else
    RunAs("administrateur", "domaine", "password", 0, "\\monserveur\deploiement$\PDFCreator\PDFCreator-1_6_2.exe /ForceInstall /Printername=PDFCreator /SILENT /NOCANCEL /NORESTART /LANG=french /NoIcons=1 /Components=program,ghostscript,languages,languages\english,languages\french /tasks=!desktop_icon /f", @SystemDir)
EndIf

Cela fonctionne parfaitement. J'ai, par curiosité, voulu voir si il était facile de dé-compilé mes exe pour en récupérer le code et donc le mot de admin, et la consternation, il m'a fallu 5 minutes pour trouvé le soft qui va bien et récupérer le password .
Dans l'optique de rendre la chose un peux plus complexe à récupérer, n'y aurait t'il pas possibilité de crypter le password (j'ai des doutes...) ou mettre ce mot de passe dans un autres exe avec une clef de cryptage ?

En faite j'aimerai me prémunir du vol de mes exe pour décryptage à l’extérieur, je me dit que si le mot de passe n'est pas directement dans l'exe exécuté ça limite les risques...

J'attends vos réflexions !

[jguinch]

Salut win43.
Effectivement, les mots de passe ne doivent surtout pas être inscrits en dur dans les scripts.
Comme tu as pu le constater, c'est facile de récupérer le code. Il n'existe pas de solution 100% efficace.
Quand on déploie un script, il faut toujours garder à l'esprit que l'utilisateur final possède en quelque sorte le code source.

Comme tu l'as suggéré, on peut externaliser le mode de passe, que ce soit dans un partage de fichiers, un serveur Web ou autre mais à partir du moment où on peut récupérer le code source, on peut aussi récupérer le mot de passe...

Je ne suis pas expert en la matière mais n'ayant pas trouvé de solution suffisamment sécurisée, je pense essayer de mettre en place le mécanisme suivant pour mes prochains déploiements :
- DLL externalisée sur un serveur Web
- Script AutoIt sans login/mdp en dur (le script télécharge la DLL)
- La DLL contient le checksum du programme AutoIt et le mot de passe
- La DLL dispose d'une fonction qui renvoie le mot de passe, uniquement si le checksum du programme qui a appelé la fonction correspond.

Forcément, ce n'est pas sécurisé à fond, mais "décompiler" un exécutable AutoIt et décompiler une DLL n'est pas du même niveau je pense.

Si quelqu'un a une meilleure/autre idée, je suis également preneur.
En attendant, c'est peut être une piste...
Bon courage.
A+

[lesolutionneur]

Le mieux reste d'utiliser Autoit3Cano qui à ce jour ne peut-être décompilé par aucun décompilateur.

http://www.autoitscript.com/forum/topic ... age__st__0

Par contre les exécutables produits par lui sont détectés comme des virus par certains antivirus.

[Tlem]

Il n'y a pas de solutions.
Au mieux, vous pouvez complexifier la lecture du code ou rajouter l'utilisation de programmes externe ou DLL, mais celui qui voudra le mot de passe, finira par l'avoir.
Demandez-vous si le temps passé vaut la protection ou si il ne vaut pas mieux procéder autrement !
Si vous exécutez une commande DOS avec mot de passe par le biais d'Autoit, il y a forcément une plaie béante.

[win43]

Le mieux reste d'utiliser Autoit3Cano qui à ce jour ne peut-être décompilé par aucun décompilateur.

http://www.autoitscript.com/forum/topic ... age__st__0

Par contre les exécutables produits par lui sont détectés comme des virus par certains antivirus.

Je viens d'essayer, en effet avec le décompilateur que j'avais ça ne fonctionne plus mais.. j'en ai téléchargé un autre qui la dé-compilé sans problème....

Je vais déjà créer un utilisateurs admin temporaire, juste le temps de déployer... c'est vraiment pas top mais ça sera déjà mieux... Je vais me pencher du coté de OCS, je l'ai déployé par autoit sur mon parc récemment... ça sera surement un peu plus "secure".

L'idée serai peut être de créé un client/serveur autoit avec des exe signé qui eux seul puissent récupérer les passwords sur le serveur. Ainsi les exe de déploiements ne contiendraient pas de données sensible , ce n'est pas infaillible, mais on passe déjà au level au dessus.
Des motivés

[jguinch]

Je vais me pencher du coté de OCS, je l'ai déployé par autoit sur mon parc récemment

Oui, il y a le télé-déploiement de paquets qui lui, n'aura pas besoin du mot de passe puisque l'agent OCS tourne/peut tourner en tant que service.

[Sea]

Envoie moi un pm je te passerai un truc pour rendre plus chiant le reverse d'autoit(aucun tool peux le reverse du moins j'ai pas encore trouvé ^^)

(je le donnerais pas a tous car il s'agit d'un patcheur qui modifie le binaire donc logiquement si ce patch est répendu sur le net ça serai useless mais vu qu'il s'agit d'une société ici je veux bien aider )

[Maurice]

Je suis confronté aussi à ce désagrément !
Je n'ai pas trouvé de solution 100% fiable, aussi j'ai testé plusieurs voies.
1 - OCS qui fonctionne plutôt bien,
2 - WSUS et son LUP qui fonctionne bien, mais dont le retour en arrière laisse à désirer,
3 - la gestion de comptes temporaires dédiés dans le domaine (+ Obfuscator), qui est plus lourd mais qui te laisse
maitre de ton déploiement.

J'avoue que la 3ème soluce me tente beaucoup pour les déploiements, car admettons que l'utilisateur récupère le scripte, admettons qu'il craque le code et admettons qu'il récupère le sésame .... Le compte reste actif très peu de jour puis est dévalidé.

C'est pas du 100%, mais qu'est ce qui est 100% en matière de sécurité informatique ?

[Sea]

Voici comment marche mon patcheur ^^

Le script autoit est contenu dans le l'OEP du programme en gros un exécutable autoit c'est un stub C contenant toute les fonctions nécessaire pour exécuter le code autoit.
Il suffit de modifier l'adresse du call pour qui ne lise plus l'OEP mais une autre partie de notre programme et après il nous suffit de mettre notre script autoit(compiler donc notre actuel OEP à l'adresse du call modifié et à la limite on met un fake code autoit compiler dans l'OEP comme ça tout les dessassembleur sont berné et prenne ce fake code ^^)

Si t'es sadique tu peux rajouter en plus une fonction de cryptage mais la c'est un peux plus chiant qu'une simple adresse de call à changer mais bon je te laisse chercher sur google pour ça ^^

@Tlem je préfère 100 fois debug sous ODBG une DLL en C/C++ que de me frotter a de l'autoit qui est un réel bordel ^^

[SkyCritters]

Bonjour,

Si vous tournez sur Windows quel qu'il soit, il n'y aura jamais 100% de sécurité pour les comptes admin.
La solution est de changer régulièrement le mot de passe admin ... Pas impossible avec les bons logiciels.

[Sea]

Si tu changes le mot de passe admin il faut que tu le change dans ton programme aussi... Donc au final ça sers à rien...

Et puis c'est pas parce que vous êtes sur windows... Sur mac et unix il existe des débogueur donc y'aura toujours moyen de trouver le mot de passe...