Windows 7 plus sécurisé sans UAC ?

[celegorm]

bonjour,
je suis en train de tester le leaktester de comodo.( http://download.comodo.com/securitytests/CLT.zip)
Pour ceux qui ne le connaissent pas, ce programme passe en revue de nombreux types d'attaque utilisées par les malware (injection de code, utilisation d'IE pour envoyer des infos...)
Or je viens de constater un comportement assez étrange de ce test.
Lancé dans un compte utilisateur standard sous Windows 7 32bits avec UAC, j'obtiens le score de 16/34.

Lors du lancement du test, l'UAC intervient en demandant si le programme est autorisé à modifier le système.
réponse oui obligatoire et entrée du pass administrateur sinon le programme ne fonctionne pas.
j'ai retenté le test avec l'UAC désactivé. Là, lors du lancement, aucune demande de l'UAC évidemment.
Le score atteint est alors de 27/34 !
je crois comprendre ce qu'il se passe mais j'aimerais confirmation:
lorsque l'uac est sollicité, elle donne un niveau admin à l'application.
lorsque l'uac est désactivée, le programme conserve un niveau utilisateur.
Si c'est celà, ça montrerait qu'avec l'UAC activée à un niveau par défaut, on arrive à un niveau de protection moindre dès lors que l'utilisateur répond oui à l'exécution d'un programme non autorisé. Etonnant non ?

détail du test avec uac:
1. RootkitInstallation: MissingDriverLoad Protected
2. RootkitInstallation: LoadAndCallImage Protected
3. RootkitInstallation: DriverSupersede Protected
4. RootkitInstallation: ChangeDrvPath Vulnerable
5. Invasion: Runner Protected
6. Invasion: RawDisk Vulnerable
7. Invasion: PhysicalMemory Protected
8. Invasion: FileDrop Vulnerable
9. Invasion: DebugControl Protected
10. Injection: SetWinEventHook Vulnerable
11. Injection: SetWindowsHookEx Vulnerable
12. Injection: SetThreadContext Vulnerable
13. Injection: Services Vulnerable
14. Injection: ProcessInject Protected
15. Injection: KnownDlls Vulnerable
16. Injection: DupHandles Protected
17. Injection: CreateRemoteThread Protected
18. Injection: APC dll injection Vulnerable
19. Injection: AdvancedProcessTermination Vulnerable
20. InfoSend: ICMP Test Protected
21. InfoSend: DNS Test Vulnerable
22. Impersonation: OLE automation Protected
23. Impersonation: ExplorerAsParent Vulnerable
24. Impersonation: DDE Vulnerable
25. Impersonation: Coat Vulnerable
26. Impersonation: BITS Protected
27. Hijacking: WinlogonNotify Protected
28. Hijacking: Userinit Vulnerable
29. Hijacking: UIHost Protected
30. Hijacking: SupersedeServiceDll Vulnerable
31. Hijacking: StartupPrograms Vulnerable
32. Hijacking: ChangeDebuggerPath Protected
33. Hijacking: AppinitDlls Vulnerable
34. Hijacking: ActiveDesktop Protected


détail du test sans uac:

1. RootkitInstallation: MissingDriverLoad Protected
2. RootkitInstallation: LoadAndCallImage Protected
3. RootkitInstallation: DriverSupersede Protected
4. RootkitInstallation: ChangeDrvPath Protected
5. Invasion: Runner Protected
6. Invasion: RawDisk Protected
7. Invasion: PhysicalMemory Protected
8. Invasion: FileDrop Protected
9. Invasion: DebugControl Protected
10. Injection: SetWinEventHook Vulnerable
11. Injection: SetWindowsHookEx Vulnerable
12. Injection: SetThreadContext Vulnerable
13. Injection: Services Protected
14. Injection: ProcessInject Protected
15. Injection: KnownDlls Protected
16. Injection: DupHandles Protected
17. Injection: CreateRemoteThread Protected
18. Injection: APC dll injection Protected
19. Injection: AdvancedProcessTermination Protected
20. InfoSend: ICMP Test Protected
21. InfoSend: DNS Test Vulnerable
22. Impersonation: OLE automation Protected
23. Impersonation: ExplorerAsParent Vulnerable
24. Impersonation: DDE Vulnerable
25. Impersonation: Coat Vulnerable
26. Impersonation: BITS Protected
27. Hijacking: WinlogonNotify Protected
28. Hijacking: Userinit Protected
29. Hijacking: UIHost Protected
30. Hijacking: SupersedeServiceDll Protected
31. Hijacking: StartupPrograms Protected
32. Hijacking: ChangeDebuggerPath Protected
33. Hijacking: AppinitDlls Protected
34. Hijacking: ActiveDesktop Protected

[Jejewen]

Salut,

personnellement je connais pas ce test, je me méfie de ce genre de trucs (Comodo est éditeur de produits de sécurité, donc avec ce test il est juge et parti comme disent les juristes...).

Cependant l'UAC ne fait que transmettre la demande des droits administrateurs des applications, et permet de choisir de les donner ou pas. Il permet donc d'utilier quotidiennement une session administrateur, ce qui est dangereux sans l'UAC.


Ton programme a apparemment besoin des droits admin pour faire les tests. UAC activée, tu as une demande de sa part (normal), UAC désactivée il prend les droits admin sans demander rien à personne.

Après pourquoi cette différence de résultats... je pencherais plus pour un "bug" (comme dit, je trouve que ces tests présentent trop de biais pour être fiable) que pour une explication logique.

[celegorm]

Code : Tout sélectionner

Ton programme a apparemment besoin des droits admin pour faire les tests. UAC activée, tu as une demande de sa part (normal), UAC désactivée il prend les droits admin sans demander rien à personne.

bin non justement il doit y avoir une différence puisque je suis en mode utilisateur. Dans ce mode, les programmes ne peuvent pas avoir de droits admin sans accord de l'utilisateur ou alors j'ai rien compris ! (et ce même sans l'UAC).
concernant la validité des tests de clt, moi je serai beaucoup plus prudent: pourquoi crier à la supercherie ou au bug sans preuve ? il y a des programmeurs qui font leur boulot et jusqu'à preuve du contraire, le pare-feu de Comodo est à un très bon niveau. Son leaktest a forcément des parti pris sur les méthodes d'attaque mais c'est comme tout programme de sécurité. Et là, je ne parle pas de tester d'autre parefeu: il ne s'agit que de Windows 7 32 bits "tout nu" et à jour (dans un environnement virtuel vmware).

[Jejewen]

Code : Tout sélectionner

Ton programme a apparemment besoin des droits admin pour faire les tests. UAC activée, tu as une demande de sa part (normal), UAC désactivée il prend les droits admin sans demander rien à personne.

bin non justement il doit y avoir une différence puisque je suis en mode utilisateur. Dans ce mode, les programmes ne peuvent pas avoir de droits admin sans accord de l'utilisateur ou alors j'ai rien compris ! (et ce même sans l'UAC).

C'est justement parce que tu est sur un compte limité que tu dois entrer le mot de passe de la session administrateur pour donner les droits admin à une application.
Sur une session admin avec l'UAC, il suffit de cliquer sur continuer (ou sur annuler selon les cas).


Je ne critique pas Comodo (j'ai utilisé leur parefeu quelques temps, si j'ai changé c'est parce que l'HIPS me gonflait plus qu'autre chose), mais l'objectivité des tests comme celui-ci dont les éditeurs sont aussi éditeurs de solution de sécurité... perso je vois pas l'intérêt ; pour reprendre une expression malekalienne, à mes yeux ces leaktests servent surtout à savoir "ki c qu'à la + grosse" (un peu comme avec les benchmarks des GPU). M'enfin, le débat n'est pas là.

[celegorm]

j'ai dû mal me faire comprendre.

Avec l'UAC et sur compte limité, le programme clt me demande les droits admin. (ok normal). résultat 16/34 (comme sur un compte admin, normal le programme a les mêmes droits).

sans l'UAC et sur compte limité, le programme clt ne me demande plus rien mais : résultat 27/34 ! la plupart des tests échouent.

mon hypothèse: sans l'UAC, le programme n'est pas bloqué mais n'a pas les droits admin. pour autant (normal on est sur un compte limité).

conclusion: sans l'uac, la sécurité est plus élevée car le programme n'a pas, par défaut, les droits admin...

(par contre, sans l'uac, le sandbox d'IE est marqué désactivé mais c'est un autre pb.)

[Jejewen]

Exact, j'avais oublier que tu étais sur un compte limité.

Donc sur un compte limité et sans UAC, l'appli n'a aucun moyen d'avoir les droits admin, donc ça te protège de certaines attaques. Je pense que le test s'exécute avec le maximum de droits qu'autorise la session, donc tu est plus vulnérables avec UAC dans ce cas-là...


Après ça reste un cas particulier, en utilisation standard l'UAC est quand même un gros plus pour la sécurité (pour ceux qui comme moi utilise une session administrateur, si tu as l'habitude d'utiliser un compte limité c'est bien aussi).

[celegorm]

tout à fait d'accord,l'UAC est un gros plus mais en l'espèce, il débouche sur un paradoxe. Et ce d'autant que ce test (pour autant qu'il fasse bien son travail, ce qui reste à prouver) ne dépasse rarement le chiffre de 20 sur 34 avec les parefeux des suites de sécurité.
Ca prouve toute l'efficacité du mode "utilisateur standard". Et ça pose le pb que j'ai soulevé dans un autre thread: est ce qu'il existe encore beaucoup de malware qui fonctionnent durablement sur Windows 7 à jour (64 bits de surcroit) ? (avec toujours l'hypothèse d'un utilisateur qui répond correctement à l'uac)

[Sacles]

Bonjour,

Et ce d'autant que ce test (pour autant qu'il fasse bien son travail, ce qui reste à prouver) ne dépasse rarement le chiffre de 20 sur 34 avec les parefeux des suites de sécurité.

Ce qui est à nouveau la preuve que les pare-feux, même bi-directionnel ne sont pas faits pour ce genre de travail.

Voir ceci "Réussite chez Matousec. Pare-feu ou HIPS?": http://www.wilderssecurity.com/showthread.php?p=1576765
Ou encore "Tests de protection": http://forum.malekal.com/tests-protection-t21613.html
Et ceci: "Testez la résistance aux keyloggers": http://forum.malekal.com/post169496.html

Salut - bon week-end

[celegorm]

Ce que l'on appelle pare-feu dans les suites de sécurité est très souvent accompagné d'un module de contrôle des applications et des comportements... du coup j'imagine qu'on est assez proche des HIPS non ?
En tout cas, les résultats obtenus sont assez peu convainquant.
Je vais voir avec Microsoft pour ce paradoxe avec l'UAC, c'est quand même étonnant.
bonne journée