Securite de RDP Article

download Securite de RDP Article

of 40

description

rdp

Transcript of Securite de RDP Article

  • Scurit de RDP

    Aurlien Bordes, Arnaud Ebalard et Raphal Rigo

    [email protected]

    ANSSI

    Rsum Cet article prsente une tude de scurit de RDP (Remote

    Desktop Protocol). Il tire son origine du constat eectu sur le terrain

    que le protocole est trs largement (mal) utilis pour l'administration

    distance de systmes Windows.

    Aprs une revue du besoin et des proprits attendues, une prsentation

    du protocole est ralise, suivie d'un historique orient scurit.

    Les mcanismes de scurit mis en uvre sont ensuite analyss en d-

    tails et leurs faiblesses rsiduelles dcrites. En particulier, les modes his-

    toriques de protections oerts par RDP, propritaires, sont particulire-

    ment vulnrables et permettent un attaquant d'attenter l'intgrit et

    la condentialit des changes.

    La ralit des implmentations client et serveur Microsoft est ensuite

    dtaille. Tous ces lments sont enn pris en compte dans un ensemble

    de recommandations et de bonnes pratiques d'utilisation de RDP visant

    renforcer la scurit de l'administration distance de systmes Windows.

    1 Introduction

    1.1 Primtre de la discussion

    D'une simple solution de dport d'achage dans Windows NT 4.0

    TSE, l'cosystme RDP a volu au l des annes, initialement pour

    supporter un plus grand nombre de priphriques et de fonctionnalits.

    Aujourd'hui, le protocole est au cur d'une architecture de services com-

    plexe [5]

    1

    , ncessitant dans certains cas plus d'une demi-douzaine de rles

    serveur dirents.

    L'analyse de scurit prsente dans cet article se concentre sur le

    cur du protocole permettant la protection des donnes changes et vise

    principalement les utilisations classiques de RDP, pour la connexion

    distance ou pour des besoins d'administration. Elle ne couvre ainsi pas les

    volutions d'architectures rcentes (supportes par Windows 2008 R2), le

    dploiement de RemoteApp, etc.

    Du point de vue des implmentations, l'analyse se concentre principa-

    lement sur les solutions serveur et client Microsoft, intgres au systme

    d'exploitation.

    1. Une imprimante A2 est ncessaire pour l'impression de ce poster.

  • 4 Scurit de RDP

    1.2 Besoin d'administration distance

    La plate-forme Windows, de par son utilisation massive et historique-

    ment obligatoire des interfaces graphiques, rend ncessaire l'utilisation

    d'un protocole de dport d'achage pour de nombreuses tches d'admi-

    nistration distance. En eet, mme si de nombreux services Windows

    peuvent maintenant tre administrs via l'utilisation de RPC

    2

    depuis

    un systme distant, cette technique n'est pas toujours applicable, no-

    tamment pour les systmes hbergeant des applications non Microsoft.

    Pour satisfaire ce besoin de dport d'achage, de nombreuses solutions

    existent, aux caractristiques trs direntes :

    VNC : cette solution historique reste encore trs utilise malgrune scurit des plus limite dans son implmentation usuelle. Cer-

    taines versions proposent nanmoins des fonctionnalits de scurit

    avances (TLS, authentication Windows, etc.) ;

    RDP : il s'agit de la solution dveloppe par Microsoft, extrme-ment utilise, objet de l'tude ;

    divers produits propritaires (DameWare, PC anywhere,NetOp, etc.) : la scurit de ces solutions varie mais est en gnral

    peu tudie.

    1.3 Proprits de scurit attendues

    Cette sous-section rappelle les principales proprits de scurit atten-

    dues d'un protocole d'administration distance. La majorit de celles-ci

    pourront s'apparenter pour le lecteur du simple bon sens ; malgr tout,

    nous verrons dans la suite de l'tude que la plupart des versions de RDP

    ne satisfont pas ces proprits.

    Authentication La premire proprit attendue concerne l'intgration

    de mcanismes d'authentication srs. Ceux-ci doivent notamment tre

    conus de manire garantir le caractre mutuel de l'authentication entre

    l'administrateur et le systme vis. Mais il doivent galement prvenir les

    possibilits de rejeu, les attaques par le milieu ainsi que les attaques hors-

    ligne visant remonter aux secrets d'authentication client ou serveur.

    La multiplication des schmas d'authentication au sein d'un protocole

    doit aussi prendre en compte les possibilits de ngociation la baisse

    (downgrade) et les prvenir.

    2. Remote Procedure Call.

  • A. Bordes, A. Ebalard, R. Rigo 5

    change de cl De nombreux protocoles scuriss d'change de donnes

    (SSH, TLS, etc.) supportent dirents schmas d'change de cl pour la

    mise en place de cls de session visant protger le trac, en condentialit

    et intgrit.

    Certains de ces schmas d'change bass sur des mcanismes asym-

    triques autorisent le dchirement ultrieur des sessions au possesseur de

    la cl prive du serveur. La compromission de cette cl remet donc dans

    ce cas en cause la condentialit de l'ensemble des changes prcdem-

    ment raliss. D'autres schmas, fournissant une proprit dite de PFS

    (Perfect Forward Secrecy), prviennent cette ventualit en dcorrlant

    les cls de session du secret d'authentication. Cette proprit prvient

    le dchirement des sessions passes par un attaquant en possession du

    secret du serveur et ncessite la mise en uvre d'attaques actives pour

    tirer un quelconque bnce de la possession de ce secret.

    Condentialit et intgrit des changes Les protocoles d'adminis-

    tration distance sont utiliss pour l'change de tous types d'informa-

    tions : des donnes pures mais galement des informations de contexte et

    de contrle sur le systme voire le rseau administr, comme des mots de

    passe d'authentication d'autres systmes, des habitudes d'administra-

    tion. La garantie forte de condentialit de l'ensemble des informations

    changes est donc une ncessit.

    L'intgrit des changes est galement primordiale pour viter la mo-

    dication la vole par un attaquant de commandes d'administration.

    L'utilisation d'algorithmes de chirement et d'intgrit l'tat de

    l'art au sein de schmas prouvs permet gnralement de traiter cette

    problmatique [6]. A contrario, le maintien pour des questions de rtro-

    compatibilit d'algorithmes dpasss ou l'utilisation de schmas propri-

    taires faibles peuvent avoir un impact fort sur la condentialit ou l'int-

    grit des changes.

    Anti-rejeu Il est primordial de prvenir tout type de rejeu, aussi bien au

    niveau des mcanismes d'authentication comme voqu prcdemment

    qu'au niveau des changes de trac ou de signalisation. Le protocole doit

    galement garantir le bon squencement des messages la rception, tou-

    jours dans le but d'viter les modications des changes par un attaquant

    sur la base d'changes prcdents ou en cours.

    Surface d'attaque Hormis les bonnes proprits cryptographiques pr-

    cdentes, le protocole doit galement limiter la surface qu'il expose sur les

  • 6 Scurit de RDP

    serveurs sur lesquels il est dploy. Ainsi, celui-ci devrait tre dvelopp en

    limitant les traitements raliss, notamment avant authentication. Dans

    une dmarche de dfense en profondeur, les liens avec les dirents l-

    ments critiques du systme devraient tre limits par conception, pour

    viter les impacts de vulnrabilits ventuelles.

    Scurit par dfaut et simplicit de conguration La simplicit

    de conguration cts client et serveur, ainsi que la mise en uvre de

    paramtres solides par dfaut est essentielle pour viter les surprises.

    De plus, les lments de conguration accessibles la fois ct client

    et ct serveur devraient permettre l'administrateur de congurer fa-

    cilement les dirents aspects de scurit du protocole, et notamment

    les paramtres associs l'authentication, le chirement et l'intgrit.

    L'interface devrait galement fournir un statut clair sur les mcanismes

    slectionns.

    2 Prsentation fonctionnelle de RDP

    2.1 Prsentation gnrale du protocole

    Cet article n'a pas vocation dtailler le fonctionnement du protocole

    et se limite donc une introduction : en eet, les bases de RDP sont

    spcies dans un document de plus de 400 pages [28] renvoyant lui-mme

    vers plusieurs dizaines de spcications Microsoft, UIT

    3

    et IETF

    4

    . Ce

    document dcrit galement les dirents mcanismes de scurit utiliss

    par les direntes volutions de RDP. Au total, l'ensemble des spcica-

    tions publies par Microsoft associes RDP et ses extensions dpasse

    les 2000 pages.

    Le protocole RDP vise initialement le transport :

    des entres utilisateur ; des donnes d'achage du systme distant au systme local.

    Additionnellement, un nombre important de fonctionnalits ont t

    ajoutes au protocole, permettant notamment le dport de divers priph-

    riques du client vers la machine distante (port srie, port parallle, lecteur

    de SmartCard, port USB, entres/sorties audio, etc.). Les changes entre

    3. Union Internationale des Tlcommunications.

    4. Internet Engineering Task Force.

  • A. Bordes, A. Ebalard, R. Rigo 7

    presse-papiers local et distant ou encore l'impression ct client font gale-

    ment partie des amliorations protocolaires. La manire dont le protocole

    supporte celles-ci est dtaille par la suite.

    Les entres utilisateur se rduisent initialement des vnements sou-

    ris et clavier. Pour les transporter, RDP utilise deux types de PDU

    5

    . Le

    premier, dnomm Slow-Path est calqu sur des PDU du protocole UIT

    T.128. Le second, plus courant en pratique, est optimis en taille. D-

    nomm Fast-Path, il a t introduit par Microsoft dans la version 5.0 de

    RDP pour optimiser la bande passante. Ces PDU transportent les frappes

    clavier (keycodes, enfoncement/relche de touche) et les dplacements de

    souris (coordonnes de curseurs), ainsi que des signaux de synchronisation.

    En retour, une fois les commandes du client relayes au niveau du

    serveur, celui-ci transmet des mises jour graphiques destination du

    client. Ces lments, dnomms Bitmap Updates, sont galement trans-

    ports dans des PDU Slow-Path et Fast-Path introduits prcdemment.

    Une fois traits par le client, ils produisent des mises jour locales des

    donnes d'achage de la session utilisateur. Ces donnes graphiques b-

    ncient d'une compression spcique RLE

    6

    .

    Outre les lments graphiques, le protocole ore galement un moyen

    de compresser les autres donnes changes avec MPPC

    7

    [32]. D'un buer

    de 8Ko dans la version initiale (RDP 4.0), celui-ci a t tendu pour passer

    64Ko ds RDP 5.0.

    De plus, divers mcanismes de scurit permettent en fonction du pa-

    ramtrage de chirer et protger en intgrit tout ou partie des donnes,

    ds le premier paquet chang ou aprs une squence de ngociation. Ces

    mcanismes sont dtaills en section 4.

    Largement bas sur une sous-partie des protocoles du standard UIT

    T.120, RDP reprend de ceux-ci un mcanisme extensible de canaux vir-

    tuels permettant les communications entre composants du systme local

    et du systme distant. Ce mcanisme est utilis notamment pour le trans-

    port des entres utilisateurs et des mises jour graphiques. Il a permis de

    nombreuses volutions du protocole au l des versions, et notamment le

    support de nouvelles fonctionnalits.

    2.2 Vue d'ensemble

    La gure 1 donne une vue d'ensemble de RDP, prsentant les trois

    facettes principales du protocoles :

    5. Protocol Data Unit.

    6. Run Length Encoding, algorithme de compression graphique Microsoft.

    7. Microsoft Point-to-Point Compression Protocol.

  • 8 Scurit de RDP

    1. les direntes fonctionnalits supportes par RDP, amenant chacune

    sa part de complexit l'ensemble protocolaire, par des liens suppl-

    mentaires avec les dirents couches du systme ;

    2. la plomberie protocolaire, permettant l'change d'informations entre

    clients et serveurs. La concision obtenue par l'utilisation de protocoles

    UIT (relativement complexes et bass sur ASN.1) et de divers mca-

    nismes de compression participe la complexit de l'ensemble ;

    3. les mcanismes de scurit intgrs au protocole voluent depuis plus

    de 15 ans. Les dcisions de conception et de conguration par dfaut

    associes aux besoins de rtrocompatibilit avec les systmes dploys

    rendent leur comprhension et leur conguration diciles.

    Remote

    Desktop

    Protocol

    Scurit

    Standard

    RDP

    Security

    low

    client-

    compat.

    high

    FIPS

    Enhanced

    RDP

    Security

    TLS

    CredSSP

    SPN-

    EGO

    Kerb-

    eros

    NTLM

    TSSP

    Fonction-

    nalits

    Accl.

    GDI

    Sessions

    Presse-

    papier

    Ports

    srie

    et //

    Systme

    de chier

    USB

    Audio

    in/out

    Carte

    puce

    Impri-

    mante

    Plomberie

    X.224

    UIT

    T.120

    ASN.1

    IETF

    Proprio.

    MS

    Figure 1. Vue d'ensemble du protocole

  • A. Bordes, A. Ebalard, R. Rigo 9

    2.3 Dtails protocolaire

    Encapsulations protocolaires Cette sous-section tend la prcdente

    en prsentant (trs succinctement) une squence de connexion RDP. Elle

    intressera principalement le lecteur bahi devant le volume important de

    donnes changes dans une trace rseau capture

    8

    .

    Pour tre utilisable sur les rseaux IP, RDP est transport au dessus

    de TCP. Par dfaut, le serveur est en coute sur le port 3389.

    Le transport de protocoles ISO au dessus de TCP passe par une couche

    d'abstraction dnomme TPKT, qui mule le service de transport ISO

    COTP. En pratique, celle-ci se matrialise par la prsence au dessus de

    TCP d'un simple header de 4 octets renseignant (sur deux octets) la

    longueur du paquet transport. Les paquets X.224 qui constituent la base

    du protocole sont donc ensuite transports dans ces paquets TPKT.

    Aprs un change permettant la monte de la connexion X.224 (X.224

    Connection Request PDU du client au serveur et X.224 Connection

    Conrm PDU du serveur au client), les paquets changs par TPKT sont

    ensuite tous des paquets de donnes appels X.224 Data PDU.

    Cette connexion X.224 sert au transport du protocole T.125

    9

    . Un des

    aspects fondamentaux de ce protocole concerne sa capacit, aprs une

    phase initiale de connexion, transporter dirents canaux d'changes

    de donnes, dnomms canaux virtuels

    10

    (virtual channel). Cette fonc-

    tionnalit fournie par les bases du protocoles est celle qui a permis de

    supporter les nombreuses volutions de RDP.

    Ces canaux transportent notamment les entres claviers et les dpla-

    cement de souris depuis la premire version du protocole. Le dport du

    presse-papier ou le dport d'impression ont ainsi chacun t associs un

    canal virtuel spcique.

    D'un point de vue protocolaire, les paquets changs prennent donc la

    forme gnrique suivante :

    Client Serveur

    ...

    ---- IP/TCP/TPKT/X.224Data/T.125-SendDataRequest ----->

    8. Contrairement Wireshark, les versions rcentes de Network Monitor sont ca-

    pables d'aller assez loin dans la dissection du protocole.

    9. Multipoint Communication Services Protocol (MCS), de la suite T.120 de l'UIT.

    10. L'article ne fait volontairement pas la distinction entres canaux virtuels statiques

    et dynamiques.

  • 10 Scurit de RDP

  • A. Bordes, A. Ebalard, R. Rigo 11

    si Standard RDP Security a t slectionn, les changes conti-

    nuent en clair jusqu' la n de la ngociation. Celle-ci est dcrite

    ci-dessous.

    2. Basic Settings Exchange

    Client Serveur

    ---- MCS Connect Initial PDU with ----------------->

    GCC Conference Create Request

  • 12 Scurit de RDP

    Ce paquet transmis par le client contient son nonce (32 octets) chir

    avec la cl publique transmise prcdemment par le serveur. Aprs ce

    paquet, les changes sont protgs

    14

    avec les cls drives des nonces.

    La scurit de la session dpend donc de l'impossibilit pour un at-

    taquant de remonter au nonce transmis chir par le client. Cette

    scurit est donc directement lie la taille de cl RSA utilise (512

    bits jusqu' Windows Server 2003, 2048 bits pour les version plus r-

    centes), et indirectement l'authentication.

    5. Secure Settings Exchange

    Client Serveur

    ---- Client Info PDU ------------------------------>

    Ce paquet est donc le premier paquet chir. Le client y passe des

    informations comme le nom de l'utilisateur, le domaine. Une option

    du client RDP permet de retenir le mot de passe

    15

    ; dans ce cas, celui-

    ci transite dans ce paquet pour l'authentication de l'utilisateur sur

    le systme distant, pour permettre l'autologon.

    14. Avec le niveau low, le sens serveur vers client n'est pas protg.

    15. Ou le code PIN dans le cas d'utilisation de carte puce.

  • A. Bordes, A. Ebalard, R. Rigo 13

    6. Licensing

    Client Serveur

  • 14 Scurit de RDP

    d'imprimantes (2000), du dport du son (XP), introduction de TLS (2003

    SP1), Network Level Authentication (NLA, depuis Vista), etc.

    Sans prtendre l'exhaustivit, la liste ci-dessous, base sur de nom-

    breuses sources [8,9,7,1], retrace l'historique des versions du protocole en

    donnant notamment les versions de systmes avec lesquels ils ont t intro-

    duits, ainsi que les amliorations fonctionnelles majeures et les volutions

    sur le plan de la scurit.

    Il est important de noter que si la version de RDP qu'un serveur

    supporte est intimement lie la version de systme sous-jacent, il est

    possible sur un systme client de mettre jour son client RDP. Ainsi,

    Windows XP supporte par exemple des clients RDP 6.0 et RDP 7.0.

    En revanche, le serveur RDP disponible sur un Windows Server 2003

    (version 5.x) ne pourra pas voluer vers une version 6.x.

    3.1 RDP 4.0 (Windows NT Server 4.0 TSE)

    Introduite avec Windows NT Server 4.0 TSE [3], en 1996, il s'agit de la

    premire version du protocole RDP. A l'poque, cette version reste assez

    limite fonctionnellement : elle a pour principal objectif de fournir une

    solution de dport d'achage sur un terminal utilisateur et de permettre

    le transport chir des entres souris et clavier de cet utilisateur.

    Le protocole ore le choix de trois niveaux de chirement low, me-

    dium (dfaut), high dcrits en section 4. Avec RDP 4.0, ces dirents

    niveaux reposent tous sur l'utilisation d'un chirement RC4 40 bits. L'in-

    tgrit est assure via un pseudo-HMAC

    16

    .

    Les mcanismes d'authentication et d'change de cl intgrs au pro-

    tocole (Standard RDP Security dcrit en section 4.1) sont cette poque

    inecaces et vulnrables des attaques par le milieu. Ils autorisent

    galement le dchirement du trac chang au cours d'une session. Ces

    faiblesses ne seront corriges que prs de 10 ans plus tard, partir de la

    version 5.2, introduite avec Windows Server 2003 SP1 (Enhanced RDP

    Security dcrit en section 4.2).

    3.2 RDP 5.0 (Windows 2000)

    Introduite avec Windows 2000, cette version apporte de nouvelles fonc-

    tionnalits : cache local persistant de bitmap, reprise de session, impression

    locale, partage de presse-papier, optimisations rseau.

    16. Ce pseudo-HMAC est dcrit en section 5.3.6.1 de [28]

  • A. Bordes, A. Ebalard, R. Rigo 15

    A cette poque, Windows 2000 supporte une taille de cl de 56 bits

    pour le chirement RC4.

    L'installation du Windows 2000 High Encryption Pack

    17

    [10] ou du

    SP2 permet l'poque d'activer ensuite l'utilisation d'une taille de cl de

    128 bits.

    En pratique, il faudra de toute manire attendre au moins le SP2 pour

    que les donnes des canaux virtuels transportant notamment les mises

    jour du presse-papiers et les impressions soient galement protges

    en condentialit et intgrit [13].

    Par ailleurs, jusqu' correction par le SP4 de la vulnrabilit MS02-

    051 [18] (dtaille en section 3.8), il est important de noter que les touches

    claviers sont trivialement accessibles un attaquant.

    3.3 RDP 5.1 (Windows XP)

    Introduite avec Windows XP Professionnel, en 2001, cette version ap-

    porte notamment le support des couleurs sur 24 bits, la redirection de

    disque, de l'audio et des ports COM. Elle apporte galement le support

    de l'ouverture de session par carte puce.

    Un client 5.1 est disponible pour Windows 2000, Windows 9x, Win-

    dows NT 4.0. C'est avec cette version que le nom du client est modie

    de Terminal Services Client pour devenir Remote Desktop Client.

    Du point de vue de la scurit, cette version ajoute aux trois niveaux

    bass sur RC4 introduits prcdemment un nouveau niveau, FIPS, utili-

    sant Triple DES pour le chirement et HMAC-SHA1 pour l'intgrit.

    Le bug MS02-051 [18] rendant trivial l'accs un attaquant aux

    touches clavier changs durant la session est corrig partir du SP1,

    sorti n 2002.

    3.4 RDP 5.2 (Windows Server 2003 SP1)

    Cette version introduite avec Windows Server 2003 SP1

    18

    permet l'uti-

    lisation de TLS pour la protection des sessions RDP : l'un des bnces

    de cet ajout est la capacit pour le client d'authentier le serveur. De

    plus, l'utilisation de TLS pour la protection des ux RDP permet d'envi-

    sager l'utilisation de modes d'change de cls, de chirement et d'intgrit

    prouvs.

    17. installer avant le client : http ://support.microsoft.com/kb/257894/en-us

    18. Un Server 2003 sans SP1, galement en version 5.2, ne permet pas de congurer

    TLS.

  • 16 Scurit de RDP

    3.5 RDP 6.0 (Windows Vista)

    Cette version a t introduite avec Windows Vista, en 2007. Des ver-

    sions de clients RDP 6.0 sont disponibles pour Windows Server 2003 et

    Windows XP SP2.

    D'un point de vue fonctionnel, cette version ajoute notamment le sup-

    port d'un mode couleur 32 bits et le support du multi-crans.

    Une des volutions majeures en matire de scurit apporte par RDP

    6.0 concerne l'intgration de NLA, dtaill en section 4.2

    19

    . Fonctionnel-

    lement, NLA permet de fournir directement les identiants utilisateurs au

    serveur, permettant ainsi de raliser l'authentication au tout dbut de

    la session RDP. Visuellement, la mire d'authentication n'apparat donc

    plus lorsque NLA est utilis.

    Sous Windows XP, il faut noter que le support client de CredSSP n'est

    fonctionnel qu'aprs passage au SP3, activation

    20

    du mcanisme CredSSP

    et aprs installation de la version 6.1 ou suprieure du client RDP

    21

    .

    3.6 RDP 6.1 (Windows Server 2008)

    Cette version a t introduite avec Windows Vista SP1 et Windows

    Server 2008. Des mises jour clientes pour cette version sont disponibles

    pour Windows Vista SP1 et Windows XP SP2.

    3.7 RDP 7.0 (Windows 7)

    Cette version a t introduite avec Windows 7 et Windows Server 2008

    R2. Des mises jour sont disponibles pour les clients pour Windows XP

    SP3, Windows Vista SP1 et SP2. D'un point de vue fonctionnel, cette ver-

    sion apporte notamment le support audio bidirectionnel, une acclration

    des changes de bitmap, le support d'Aero et le support d'un vrai mode

    multi-crans.

    En matire de scurit, un certicat auto-sign RSA de 2048 bits d'une

    validit de 6 mois est gnr par le systme et utilis par dfaut pour la

    session TLS. Les dtails sont discuts en section 4.2.

    3.8 Panorama historique des vulnrabilits

    Depuis la premire version de RDP, les implmentations Microsoft

    (client, serveur) ont connu prs d'une quinzaine de vulnrabilits rfren-

    ces. Celles-ci sont reprises ici et classes en trois catgories principales.

    19. En pratique, l'implmentation de NLA est ralise par CredSSP.

    20. http://support.microsoft.com/kb/951608

    21. http://support.microsoft.com/kb/951616

  • A. Bordes, A. Ebalard, R. Rigo 17

    Les bulletins de scurit Microsoft sont utiliss de prfrence comme

    rfrence mais sont remplacs par les CVE, KB et autres annonces

    associes aux vulnrabilits dcouvertes lorsque Microsoft n'a pas produit

    de bulletin de scurit.

    Dni de service

    MS01-006 [14], MS01-040 [15], MS01-052 [16], MS05-041 [22],MS11-065 [27] ;

    Excution de Code

    MS02-046 [17], MS09-044 [23], MS11-017 [25], MS11-061 [26],MS12-020 [30] ;

    Conception/Crypto

    MS02-051 [18] : Cryptographic Flaw in RDP Protocol can Leadto Information Disclosure

    KB275727 [13] : High Encryption on a Remote Desktop or Ter-minal Services Session Does Not Encrypt All Information

    Forsberg03 [20] : Microsoft Terminal Services vulnerable toMITM-attacks

    CVE-2005-1794 [21] : shared RSA key is embedded in RDPlibrary mstlapi.dll

    Les quelques dnis de services rfrencs sont probablement le reet

    de la complexit du protocole et de la dicult en raliser une im-

    plantation sre. Les liens troits avec les nombreux lments critiques du

    systme apparaissent galement au travers des vulnrabilits autorisant

    une excution de code. Mais la partie la plus intressante de cet histo-

    rique concerne les quatre vulnrabilits places ci-dessus dans la catgorie

    Conception/Crypto. Celles-ci sont dtailles ci-aprs :

    MS02-051 [18] : le bulletin de scurit, publi en septembre 2002 22,rfrence deux vulnrabilits aectant Windows 2000 (RDP 5.0) et

    Windows XP (RDP 5.1).

    L'une d'elle est une erreur de conception cryptographique g-

    nrique dcrite par Hugo Krawczyk dans [31], connue sous le nom

    authenticate-and-encrypt. Elle consiste calculer un motif d'int-

    grit sur le texte clair puis chirer le clair et transmettre les

    deux rsultats. Deux clairs identiques possdent alors le mme mo-

    tif d'intgrit. Dans le cas de RDP, il s'agit du schma utilis depuis

    la conception du protocole.

    22. Microsoft a t noti de la vulnrabilit le 16 avril 2002.

  • 18 Scurit de RDP

    A partir de RDP 5.0, les entres clavier de l'utilisateur, sont trans-

    portes dans des PDU spciques (Fast Path PDU) de taille rduite :

    2 octets d'en-tte, 8 octets de MAC et 2 octets de donnes chires.

    Les 2 octets chirs contiennent le type d'vnement clavier (touche

    enfonce, touche relche) et la touche concerne.

    Si susamment de trac a t chang, un attaquant est donc ca-

    pable, par une analyse frquentielle des valeurs de MAC, d'en d-

    duire les touches enfonces, et donc le texte clair.

    KB275727 [13] : Par dfaut, avant le SP2 pour Windows 2000,les informations changes par les canaux virtuels RDP (utiliss par

    le protocole pour certaines fonctionnalits) ne sont pas chirs par

    dfaut. Cet oubli expose donc notamment les changes de presse-

    papiers mais galement les redirections d'impression.

    Forsberg03 [20] : Dbut 2003, Eric Forsberg signale Microsoftque le schma utilis pour l'change de cl est trivialement sujet

    une attaque par le milieu. Le serveur transmet en eet au client une

    cl publique RSA que celui-ci n'authentie pas.

    La vulnrabilit est corrige silencieusement par Microsoft en

    intgrant ses implmentations une cl RSA xe. La partie prive

    est utilise ct serveur pour signer une seconde cl publique gnre

    localement. La partie publique est utilise ct client pour vrier

    la signature sur cette seconde cl. Ce schma nous amne donc la

    vulnrabilit suivante.

    CVE-2005-1794 [21] : La correction propose pour la vulnrabi-lit ci-dessus, consistant masquer une cl de signature/vrication

    dans une bibliothque du systme est videmment dcouverte mais

    ne fait pas l'objet d'un bulletin de scurit : en eet, elle n'a jamais

    t corrige.

    Cette cl est aujourd'hui rfrence dans la spcication de RDP [28]

    (en section 5.3.3.1.1) et constitue toujours aujourd'hui le seul mca-

    nisme d'authentication du mode Standard RDP Security (dtaill

    en section 4.1) pour les serveurs RDP dploys sur les systmes jus-

    qu' Windows XP inclus.

    Mme si des alternatives sont disponibles sur les systmes Micro-

    soft plus rcents, des arguments de rtrocompatibilit font que ce

    mcanisme reste utilisable sur certains d'entre eux.

  • A. Bordes, A. Ebalard, R. Rigo 19

    4 Mcanismes de scurit de RDP

    RDP ore deux modes principaux de scurit pour la protection des

    changes.

    Le premier, dnomm Standard RDP Security

    23

    , correspond au mode

    de protection historique intgr au protocole. Contrairement au second

    mode, qui rutilise en grande partie des schmas connus, celui-ci repose

    sur l'utilisation directe de primitives cryptographiques. Il ore quatre ni-

    veaux de protection dirents, que les clients et serveurs peuvent ngo-

    cier.

    Le second mode, dnomm Enhanced RDP Security

    24

    , correspond

    l'utilisation pour la protection des changes RDP d'un protocole externe

    parmi les deux disponibles, TLS ( partir de 2003 SP1) ou CredSSP (

    partir de Vista). Cette approche permet RDP de reposer sur des proto-

    coles prouvs pour la scurit des changes.

    4.1 Standard RDP Security

    Introduction Comme voqu prcdemment, Standard RDP Security

    supporte quatre niveaux de protection en condentialit des changes

    entre le client et le serveur.

    Tous les niveaux de chirement hormis FIPS utilisent l'algorithme

    RC4, seule la taille de cl peut changer entre 40, 56 ou 128 bits. La taille

    de cl ngocie est galement utilise pour la cl d'authentication des

    paquets (MAC). Le niveau FIPS utilise les algorithmes Triple DES et

    HMAC-SHA1.

    Low Le premier niveau, dnomm low, n'impose que le chirement des

    donnes du client vers le serveur, le canal inverse restant en clair. L'objectif

    est ici de protger les donnes d'authentication mises par le client et

    notamment la saisie de son mot de passe dans la GINA

    25

    ou via les

    Credentials Providers depuis RDP 6.0 (Vista). La taille de cl selectionne

    par le serveur est la plus grande supporte par le client.

    En niveau low, les donnes provenant du serveur sont considres

    comme moins condentielles et ne sont pas chires.

    23. Standard RDP Security est spci en section 5.3 de [28]

    24. textitEnhanced RDP Security est spci en section 5.4 de [28]

    25. Graphical Identication and Authentication, la bote de dialogue d'authentica-

    tion avant Vista

  • 20 Scurit de RDP

    Client compatible Le second niveau, client compatible, tend la pro-

    tection aux deux sens de communications, toujours avec la taille de cl la

    plus grande supporte par le client.

    High Le troisime niveau, high, impose galement un chirement des

    deux sens de communication, mais cette fois-ci en utilisant la taille de

    cl la plus grande supporte par le serveur. Les clients qui ne supportent

    pas les algorithmes proposs par le serveur ne sont pas autoriss se

    connecter.

    FIPS Le dernier niveau est une extension du troisime niveau impo-

    sant l'utilisation de primitives de chirement valides FIPS 140-1 [12].

    C'est dire Triple DES pour le chirement et HMAC-SHA1 pour le MAC.

    En pratique, un cinquime niveau de chirement existe, qui correspond

    une absence de chirement des ux.

    Le tableau suivant rsume les dirents niveaux :

    Niveau cs sc mthode algo MACLow chir clair max client RC4 MD5/SHA1

    Client Compatible chir chir max client RC4 MD5/SHA1

    High chir chir max serveur RC4 MD5/SHA1

    FIPS chir chir n/a 3DES HMAC-SHA1

    Figure 2. Rsum des principaux paramtres de scurit associs au choix du niveau

    de chirement RDP (Encryption Level)

    Authentication Il convient de distinguer les deux modes de fonctionne-

    ment : le mode autonome et le mode Terminal Server. Le mode autonome

    est le mode par dfaut permettant la monte de deux sessions concur-

    rentes, et ne ncessitant pas la mise en uvre de serveur de licence. Il

    s'agit de celui considr dans l'article.

    En mode autonome, le mcanisme d'authentication propos de base

    par le protocole est en pratique inexistant :

    le client n'est pas authenti par le serveur ;

    le serveur prsente sa cl publique, signe par une cl prive connue

    de tous [20,21] car spcie dans la documentation Microsoft [28].

  • A. Bordes, A. Ebalard, R. Rigo 21

    change de cls Par ailleurs, le mcanisme d'change de cl utilis re-

    pose sur un simple chirement par la cl publique RSA du serveur d'un

    nonce de 32 octets produit par le client (appel ClientRandom). Le ser-

    veur envoie galement un ServerRandom de 32 octets (non chir) lors de

    l'change.

    Ces valeurs sont ensuite utilises pour driver trois cls de session de

    128 bits chacune, l'aide des fonctions de hachage MD5 et SHA-1.

    la cl de chirement client vers serveur ;

    la cl de chirement serveur vers client ;

    la cl d'authentication utilise pour le MAC.

    Dans le cas o la taille de cl ngocie est infrieure 128 bits, seule une

    partie de ces 128 bits sont utiliss, le reste tant remplac par des valeurs

    xes.

    Si un attaquant peut dcrypter le ClientRandom, alors celui-ci pourra

    accder l'intgralit des communications. La scurit de la transaction

    dpend donc de la taille de la cl publique RSA utilise ; la taille minimale

    recommande par le Rfrentiel Gnral de Scurit (RGS) [6] est 2048

    bits.

    Intgrit Lors de la ngociation l'tablissement de la connexion,

    partir de RDP 5.2, le client et le serveur peuvent ngocier l'utilisation de

    salted MAC au lieu d'un simple MAC. Cette option intgre un compteur

    de chirement / dchirement dans le calcul du MAC des paquets.

    En mode normal, le MAC du paquet est calcul de la manire suivante :

    Pad1 = 0x36 rpt 40 fois pour obtenir 320 bits

    Pad2 = 0x5C rpt 48 fois pour obtenir 384 bits

    SHAComponent = SHA(MACKeyN + Pad1 + DataLen + Data)

    MACSignature = First64Bits(MD5(MACKeyN + Pad2 + SHAComponent))

    MACKeyN est soit MACKey40, MACKey56 ou MACKey128, selon la taille de

    cl ngocie. Le mode salted MAC intgre un compteur supplmentaire,

    EncCount :

    SHAComponent = SHA(MACKeyN + Pad1 + DataLen + Data + EncCount)

    MACSignature = First64Bits(MD5(MACKeyN + Pad2 + SHAComponent))

    Ici EncCount reprsente le nombre d'oprations de chirement qui ont

    t ralises jusqu'ici, dans le sens de communication concern (CS ouSC).

  • 22 Scurit de RDP

    Analyse de scurit L'analyse ne concernera que les niveaux de chif-

    frement compatible client et niveau lev, qui sont ceux gnralement

    rencontrs. Les niveaux faible et FIPS ne sont en pratique jamais rencon-

    trs car il faut les congurer explicitement.

    Authentication Comme prcis prcdemment, l'authentication du ser-

    veur est inexistante. En eet, la cl publique du serveur est signe par une

    cl prive connue de tous.

    change de cl Si le mcanisme de drivation de cl partir des donnes

    alatoires changes ne prsente pas de vulnrabilit vidente, il n'en va

    pas de mme pour l'change. En eet, le mcanisme de transport de cl

    ne possde pas la proprit de Perfect Forward Secrecy et donc la com-

    promission de la cl prive du serveur permet la compromission de toutes

    les communications observes, mme auparavant.

    Ainsi, l'utilisation de cls publiques RSA de 512 bits sur les serveurs

    RDP anciens (jusqu' XP et 2003) ne permet absolument pas de garantir

    la condentialit des changes. En eet, les cls de cette taille peuvent

    tre factorises trs rapidement, y compris avec peu de moyens de calcul

    [6,19].

    Un attaquant ne pouvant pas raliser d'attaque active (MITM) mais

    disposant de capacits d'coute est donc capable de dcrypter les changes

    et la complexit protocolaire reste donc le seul rempart empchant l'accs

    pratique aux informations changes : frappes clavier (y compris les mots

    de passe saisis), presse-papier, donnes graphiques et autres canaux de

    communication.

    Chirement L'utilisation de cls de 40 ou 56 bits, avec RC4, ne permet

    videmment pas de garantir la scurit, l'entropie de la cl tant trs faible.

    L'idal est donc d'utiliser des cls de 128 bits.

    Intgrit D'une manire gnrale, on pourra noter l'utilisation d'un

    schma spcique et non d'un rel HMAC. De plus, la valeur rsultante

    est tronque 64 bits. A priori, aucune attaque ne semble nanmoins

    ralisable en pratique.

    Le mode normal ne dispose pas de protection anti-rejeu en tant que tel.

    Il devrait donc tre en thorie possible de rejouer des paquets. En pratique,

    sans tre une garantie de scurit forte, l'utilisation d'un chirement par

    ot rend l'exercice dicile.

    Nanmoins, le principal problme de ce mode de calcul d'intgrit n'est

    justement pas li la protection de l'intgrit mais la condentialit. En

  • A. Bordes, A. Ebalard, R. Rigo 23

    eet, contrairement aux bonnes pratiques, le calcul d'intgrit se fait sur

    les donnes en clair et le MAC rsultant n'est pas chir. Donc au cours

    d'une session, deux paquets de donnes identiques auront le mme MAC.

    Ce qui est particulirement problmatique pour les frappes clavier : les

    Fastpath PDU sont trs petites et il est tout fait possible de retrouver

    les touches partir du ux RDP sans attaque active.

    Ce problme a t corrig avec MS02-051 [18] avec l'introduction du

    mode salted MAC, qui en rajoutant un direnciateur, correspondant aux

    nombre de chirements eectus, permet d'obtenir un MAC dirent pour

    deux clairs identiques, corrigeant ainsi la vulnrabilit du mode classique.

    4.2 Enhanced RDP Security

    Introduction Contrairement au mode historique et propre RDP, Stan-

    dard RDP Security, le mode Enhanced RDP Security dlgue la protection

    en condentialit et intgrit des changes un mcanisme externe. Le

    protocole RDP, en clair, sera donc encapsul dans ce mcanisme.

    Les mcanismes de protection externes sont les SSP (Security Support

    Provider). Sous Windows, ces bibliothques permettent de raliser une

    authentication, la drivation de cls, puis la protection des messages.

    RDP supporte deux SSP :

    Secure Channel (ou Schannel) qui met en uvre TLS pour l'au-thentication et la protection des changes ;

    CredSSP qui met galement en uvre TLS pour transporter uneauthentication base sur SPNEGO [29]

    26

    et la dlgation des in-

    formations d'identication. Dans la pratique, CredSSP fait appel

    d'autres SSP : Negotiate pour la ngociation SPNEGO, (qui lui-

    mme fait appel NTLM ou Kerberos) et TSSSP

    27

    pour la dlga-

    tion. La gure 3 prsente l'imbrication de ces SSP.

    L'utilisation d'un des deux mcanismes externes de scurit peut tre

    ngocie (Negotiation-Based Approach) ou directe (Direct Approach).

    La premire approche a l'avantage d'tre rtrocompatible avec le m-

    canisme historique ; la communication dbute ainsi par l'change, en clair,

    d'une requte et d'une conrmation de connexion X.224. Le mcanisme

    de scurit externe est ensuite mis en oeuvre pour protger le reste de la

    session.

    La seconde approche permet la mise en oeuvre directe du mcanisme

    de scurit externe, avant tout change RDP. Elle favorise la scurit

    l'interoprabilit.

    26. Simple and Protected GSS-API Negotiation Mechanism Protocol Extensions.

    27. TS Service Security Package.

  • 24 Scurit de RDP

    CredSSP

    SPNEGO TSSSP

    NTLM Kerberos

    Figure 3. Imbrication des SSP dans CredSSP

    TLS :

    Lorsque TLS est utilis, une session TLS est tablie par le SSP entre

    le client et le serveur. Le tunnel TLS ainsi tabli est ensuite utilis pour

    la scurisation en condentialit et intgrit de l'intgralit des changes

    de la session RDP.

    L'apport majeur de l'utilisation de TLS est la possibilit de pouvoir

    authentier le serveur via un certicat X.509. Celui-ci peut tre auto-

    gnr (ce qui est le cas par dfaut depuis Windows Vista ou 2008) ou

    import dans le magasin de certicats du serveur.

    Si TLS propose l'authentication du serveur via un certicat, la vali-

    dation de celui-ci est entirement du ressort du client et dpendra de son

    paramtrage (stratgie et ancres de conance congures). Cette probl-

    matique est abord en section 5.2.

    CredSSP :

    Credential Security Support Provider [24] est le SSP apparu avec Win-

    dows Vista/2008

    28

    . Dans le principe, ce SSP implmentant un mcanisme

    d'authentication appel NLA (Network Level Authentication) vise ren-

    forcer l'authentication entre un client et un serveur puis permettre

    la dlgation des informations d'identication. Dans les faits, le service

    Terminal Server est le seul utilisateur actuel de CredSSP.

    L'authentication et la dlgation des informations d'identication via

    CredSSP sont ralises en quatre phases prsentes en gure 4 puis d-

    tailles ci-dessous.

    28. CredSSP est galement disponible sous Windows XP Service Pack 3, mais n'est

    pas activ par dfaut (cf. KB951608).

  • A. Bordes, A. Ebalard, R. Rigo 25

    Client Serveur

    1 1

    tablissementsession TLS

    2 2

    Authentification (Kerberos ou

    dfi rponse NTLMSSP)

    3 3

    Validations(cl et session

    dauthentification)

    4 4

    Dlgation(des informationdidentification)

    RDP

    Client Hello, Server Hello, Certificate, Key Exchange

    SPNEGO : NTLMSSP ou Kerberos (KRB_AP)

    Cl pub. TLS (Kt) / Cl pub. TLS+1

    mot de passe ou code PINPr

    ot

    ec

    ti

    on

    T

    LS

    (

    Kt

    )

    Pr

    ot

    ec

    ti

    on

    S

    PN

    EG

    O

    (K

    a)

    Ke

    rb

    er

    os

    ou

    N

    TL

    MS

    SPP

    ha

    s es

    Figure 4. Les 4 phases de CredSSP

    Phase 1 Dans la premire phase, le client et le serveur tablissent une

    session TLS. La mise en place de cette session permet, d'une part, au

    client d'authentier ventuellement le serveur via le certicat X.509

    qu'il prsente et, d'autre part, de bncier d'un canal de communication

    protgeant tous les changes suivants. La ralisation de cette session TLS

    est assure par le SSP Secure Channel.

    Phase 2 Aprs la mise en place de la session TLS, l'utilisateur doit

    s'authentier auprs du serveur. Pour cela, CredSSP utilise le SSP Nego-

    tiate qui permet de ngocier un protocole d'authentication : Kerberos

    ou NTLMSSP. Aprs authentication, le SSP correspondant au protocole

    choisi est en mesure de chirer des messages ce qui permet de mettre en

    place un second canal de chirement utilis pour la suite des changes

    29

    .

    Pour pouvoir utiliser ce canal de chirement, le serveur doit avoir

    accs d'une matire ou d'une autre au secret de l'utilisateur ou aux cls

    de chirement :

    29. Le mcanisme de gnration de cls et de chirement est dirent suivant NTLM-

    SSP ou Kerberos.

  • 26 Scurit de RDP

    si le compte utilis par le client est un compte local, le serveurrcupre dans sa base SAM locale l'empreinte NTLM du compte

    puis drive les cls ;

    si le compte du client est un compte de domaine et que le SSP NTLMest utilis, le serveur doit valider auprs d'un contrleur de domaine

    le compte du client. Pour cela, le serveur tablit avec un contrleur

    de domaine un canal scuris (Secure Channel) pour valider la r-

    ponse du client puis le contrleur de domaine lui transmet les cls

    de chirement. Pour tablir le canal scuris, le serveur doit tre

    membre du domaine (ou disposer au moins d'un compte machine) ;

    si le compte du client est un compte de domaine et que le SSP Kerbe-ros est utilis, le client doit obtenir auprs d'un KDC (un contrleur

    de domaine) un ticket prsenter au serveur. Pour cela, partir du

    nom rfrenant le serveur, le client demande un ticket de service

    au KDC o, dans sa base (i.e. l'Active Directory), un compte doit

    tre associ au SPN

    30

    demand. Pour le service Terminal Server, le

    SPN est de la forme TERMSRV/nom serveur. Le secret associ ce

    compte (i.e. l'empreinte NTLM) est utilis pour chirer le ticket de

    service transmis au client qui le transmet son tour au serveur. Il

    est donc ncessaire que le serveur connaisse le secret utilis par le

    KDC an de dchirer le ticket et rcuprer la cl de chirement.

    Dans le principe de l'authentication Kerberos, si le serveur peut

    utiliser la session chire (ce qui sera fait l'tape suivante), cela

    prouve qu'il connat la mme cl que celle connue par le KDC, donc

    que c'est le serveur lgitime.

    Si Kerberos, via CredSSP, est utilis pour l'authentication, le

    serveur est authenti. En revanche, l'utilisation de NTLMSSP ne

    permet pas d'authentier le serveur.

    partir de cette tape, en plus d'tre chirs par TLS, les changes

    des tapes 3 et 4 sont chirs par NTLMSSP ou Kerberos, suivant la

    mthode d'authentication utilise.

    Phase 3 La troisime phase a deux objectifs. Le premier est de valider

    la cl publique contenue dans le certicat prsent par le serveur lors de

    la ngociation TLS de la phase 1. Cette vrication permet de s'assurer

    que la cl n'a pas t substitue par une attaque de type man in the

    middle. Le second objectif est de s'assurer que les deux parties sont bien

    30. Service Principal Name.

  • A. Bordes, A. Ebalard, R. Rigo 27

    en possession de la mme cl (Ka) lie l'authentication de la phaseprcdente. Pour ce faire, le client commence par envoyer la cl publique

    Kt inclue dans le certicat X.509 reu. Cet envoi est chir par la cl Ka(et TLS). Le serveur compare Kt celle qu'il a envoye, puis la renvoieincrmente de 1, toujours chire avec Ka (et TLS). Si les changes ontabouti, les deux parties sont assures que leur correspondant connat la

    cl Ka et que la cl Kt n'a pas t altre.

    Phase 4 Enn, la dernire phase consiste dlguer les informations

    d'identication du client. Pour cela, CredSSP transfre au serveur les l-

    ments d'authentication du client (son mot de passe ou son code PIN et la

    rfrence de carte puce). Grce ces lments, le serveur peut ouvrir une

    session interactive de l'utilisateur. Cette dlgation peut tre manuelle (le

    client doit saisir les lments lors de la connexion au serveur) ou automa-

    tiquement (le mot de passe de l'utilisateur est transmis automatique au

    serveur)

    31

    .

    Avec RDP, quelque soit le mode de scurit utilis, le mot de

    passe de l'utilisateur ou son PIN de carte puce nit par tre

    transmis au serveur.

    La suite des changes RDP reste protge par la session TLS.

    Analyse de scurit

    TLS Tout d'abord, sous Windows XP, le mode Enhanced RDP Secu-

    rity n'tant pas support, il n'est pas possible d'authentier un systme

    Windows auquel on accde en RDP.

    partir de Windows 2003 SP1, l'utilisation de TLS pour la protection

    des changes RDP ncessite un minimum de conguration ct client et

    ct serveur, notamment pour paramtrer l'authentication et les mca-

    nismes cryptographiques utiliss.

    Pour activer la protection TLS avec RDP, un certicat X.509 doit tre

    prsent dans le magasin de certicats de l'ordinateur et slectionn depuis

    l'interface de conguration du service Terminal Server.

    partir de Windows 2003 SP1, il est ncessaire d'importer un certi-

    cat X.509 issu d'une PKI

    32

    pour utiliser TLS. En gnral, cette opration

    31. Cette fonctionnalit n'est pas active par dfaut.

    32. Infrastructure de Gestion de Cl, i.e. IGC

  • 28 Scurit de RDP

    est rarement eectue par les administrateurs ; TLS n'est donc pratique-

    ment jamais utilis avec Windows 2003.

    Depuis Windows Vista ou 2008, TLS est congur pour tre utilis

    par dfaut. Un certicat X.509 tant ncessaire, le systme gnre au-

    tomatiquement un certicat autosign au nom du serveur. Ce certicat

    tant autosign, il n'est pas possible de le vrier, donc d'authentier le

    serveur. En revanche, sa prsence permet de d'activer et d'utiliser TLS,

    sans authentication. L'authentication du serveur sera ralise par

    Kerberos via CredSSP

    33

    dans le tunnel TLS, pour ensuite permettre la

    validation de la cl publique prsente initialement par le serveur dans son

    certicat. La session TLS sera ainsi en quelques sorte "post-authentie".

    Toute cette logique est mise en oeuvre pour supporter la philosophie Mi-

    crosoft de limiter les besoins de conguration. En pratique, ceci impose

    tout de mme l'utilisation de Kerberos et donc l'accs des clients au KDC.

    Sur les ditions serveur de Windows, l'interface de conguration du

    service permet de choisir le certicat utiliser : soit le certicat autosign

    par dfaut ou un autre certicat, par exemple, import de sa propre PKI.

    An d'authentier correctement le serveur, le client RDP doit valider

    le certicat prsent. Les critres de validation sont les mmes que pour

    n'importe quelle connexion TLS (nom du serveur, date de validit, chane

    de certication, rles du certicat, etc.). L'implmentation du mcanisme

    de validation, qui dtermine en particulier le comportement adopter

    en cas d'chec de la validation, est fondamentale du point de vue de la

    scurit. Cela peut tre aucun avertissement, une simple alerte ou un

    refus de connexion en cas d'chec d'authentication. La partie 5.2 dcrit

    l'implmentation du client Microsoft. videmment, si la validation du

    certicat a chou, mais que le client continue la session TLS, rien n'assure,

    via le mcanisme des certicats X.509, que le serveur soit authentique.

    Concernant l'authentication du client via un certicat X.509 m-

    canisme disponible nativement dans TLS celle-ci n'est tout simplement

    pas utilise par Microsoft. Dans la conception de RDP, l'authentication

    du client n'est pas ralise par TLS, mais par l'ouverture de session in-

    teractive sur le serveur ou par l'authentication SPNEGO si CredSSP est

    utilis.

    Concernant la ngociation des algorithmes cryptographiques utiliss

    par TLS dans le cadre de RDP, aucune interface graphique ne permet de

    dterminer la liste des algorithmes utilisables. Cependant, il est possible de

    restreindre la liste des algorithmes et mthodes d'change de cls proposs

    33. Le lecteur attentif se sera rendu compte que NTLMSSP peut tre choisi, auquel

    cas l'authentication chouera.

  • A. Bordes, A. Ebalard, R. Rigo 29

    ou accepts par le SSP Secure Channel, qui met en uvre TLS. Cette

    conguration s'eectue via un ensemble de cl dans la base de registre

    34

    .

    Depuis Windows Vista, il est galement possible, via les stratgies de

    groupe

    35

    , de restreindre ou de changer l'ordre des suites de chirements

    proposes (ct client) ou acceptes (ct serveur).

    Cependant, ces paramtres congurent le SSP Secure Channel de ma-

    nire globale et impactent donc tous les services du systme utilisant TLS

    au moyen de ce SSP. Dans la pratique, aucun administrateur ne se ris-

    quera modier ces paramtres de peur des consquences fonctionnelles.

    En particulier, ces paramtres inuent sur la bibliothque WinHTTP utilise

    par des composants tels qu'Internet Explorer, Windows Update, etc.

    Par dfaut, l'algorithme retenu (TLS_RSA_WITH_AES_128_CBC_SHA de-

    puis Vista) pour la protection des changes TLS ne permet pas d'obtenir

    la proprit de PFS. Au moyen du paramtre indiqu ci-dessus, il est pos-

    sible de forcer un ordre prcis pour les suites cryptographiques. Le principe

    consiste congurer, sur le serveur, une liste d'algorithmes dont les pre-

    miers sont ceux bass sur une mthode de ngociation des cls de type

    ECDHE. Ceci permet de privilgier le choix de ces protocoles par le serveur

    et d'obtenir ainsi la proprit de PFS. Cependant, les clients ne suppor-

    tant ECDHE (comme Windows XP) pourront tout de mme se connecter.

    La seule manire de pallier ce problme est de dsactiver les suites non

    ECDHE : ce paramtrage aecte encore une fois l'ensemble des services du

    systmes utilisant TLS.

    CredSSP Comme vu en section 4.2, la premire phase de CredSSP

    consiste en la mise en place d'une session TLS. Les problmatiques de

    scurit dcrites ci-dessus s'appliquent donc galement.

    Cependant, l'utilisation de CredSSP apporte la ralisation d'une au-

    thentication SPNEGO (NTLM ou Kerberos), l'tablissement d'un canal

    chir bas sur l'authentication ralise, puis la validation de la cl pu-

    blique contenue dans le certicat prsent par le serveur au client.

    Concernant l'authentication base sur SPNEGO, il n'est pas pos-

    sible de forcer l'utilisation de Kerberos par rapport NTLMSSP,

    bien que ce dernier ore moins de protection.

    Il n'est notamment pas possible au client, avec les protocoles LM ou

    NTLM, de valider l'identit du serveur auquel il se connecte. Ainsi, en cas

    34. HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    35. Conguration Ordinateur, Modles d'administration, Rseau, Paramtres de

    conguration SSL

  • 30 Scurit de RDP

    de compromission d'un compte de machine d'un domaine, un attaquant

    aura la possibilit, avec NTLMSSP, d'usurper l'identit de n'importe quel

    serveur.

    En revanche, si Kerberos est utilis, le client est assur de l'identit

    du serveur auquel il se connecte. En eet, le contrleur de domaine, qui

    joue le rle de KDC, donne au client un ticket de service destin au ser-

    veur indiqu par le client (le SPN recherch est de la forme TERMSRV/nom

    serveur). Ce ticket est ensuite prsent par le client au serveur dans la

    phase 2 des changes CredSSP. Seul le serveur ayant la cl partage avec le

    KDC peut dchirer les informations contenues dans le ticket et ainsi r-

    cuprer la cl de chirement du canal scuris utilis dans la phase 3. Cela

    ncessite que le client et le serveur puissent raliser leur authentication

    au moyen de Kerberos.

    Cependant, l'utilisation de Kerberos impose que le client et le serveur

    soient membres d'un mme domaine Active Directory. De plus, le client

    doit avoir un accs rseau avec le KDC, ce qui n'est pas toujours possible,

    par exemple dans le cadre d'un accs distant.

    La phase 3 des changes CredSSP (envoi cl publique, retour cl+1)

    a deux objectifs. D'une part, le serveur s'assure que le client a bien reu

    la mme cl publique que celle qu'il a envoye dans le certicat X.509.

    D'autre part, elle permet au client et au serveur de s'assurer que leur

    homologue est bien en mesure d'utiliser le canal scuris SPNEGO. Si

    Kerberos a t utilis pour la mise en place de ce canal, cela assure au

    client que le serveur a pu dchirer le ticket qu'il lui a envoy et donc que

    le serveur est reconnu par le KDC.

    4.3 Conclusion

    Le mode Enhanced RDP Security apporte, outre l'utilisation de TLS

    pour la protection des changes RDP, surtout la possibilit d'authentier

    le serveur vis--vis du client. Cette authentication peut prendre deux

    formes :

    la premire repose sur le certicat X.509 prsent par le serveur dansla mise en place de la session TLS ;

    la seconde repose sur l'utilisateur du protocole CredSSP, seulementsi Kerberos est utilis. Dans ce cas, le certicat X.509 n'est plus

    vri, mais seulement la cl publique contenue dans le certicat et

    le serveur est authenti via Kerberos.

  • A. Bordes, A. Ebalard, R. Rigo 31

    Si CredSSP utilise NTLMSSP pour l'authentication, celle-ci ne

    peut reposer que sur le certicat X.509 qui doit absolument tre

    correctement valid.

    5 Implmentations

    5.1 Ct serveur

    Microsoft La partie historique (voir section 3) a prsent les direntes

    volutions du protocole qui correspondent aux direntes versions et Ser-

    vice Pack de Windows. Cette partie prsente des spcicits d'implmen-

    tation des serveurs Microsoft.

    La gure 5 rsume les dirents niveaux disponibles ct serveur en

    Standard RDP Security en fonction des versions de Windows.

    Niveau 2000 2003 2003 SP1 2008 XP Vista / 7

    Low dispo dispo dispo dispo GPO GPO

    Client comp. dfaut dfaut dfaut dfaut dfaut dfaut

    ?

    High dispo dispo dispo dispo GPO GPO

    FIPS N.D. dispo dispo dispo GPO globale GPO globale

    Lgende :

    dispo : disponible et congurable ;

    GPO : disponible et congurable par GPO ;

    GPO globale : GPO inuenant tout le systme ;

    N.D. : non disponible.

    ?: la documentation spcie que le niveau par dfaut est High, mais en pratique ce

    n'est pas le cas

    Figure 5. Niveaux de scurit, ct serveur, disponibles et congurs par dfaut

    La gure 6 rsume les dirents protocoles disponibles ct serveur en

    Enhanced RDP Security en fonction des versions de Windows.

    Au niveau de la scurit du mode Standard RDP Security, jusqu'

    Windows 2003 inclus, la cl publique RSA utilise pour le transport de la

    cl de session est en pratique limite 512 bits, la cl gnre par le serveur

    tant systmatiquement de cette taille. Il est donc impossible de garantir

    la scurit des communications dans ce mode (voir section 4.1). Windows

    2008 supporte des cls de taille suprieure mais propose nanmoins un

    mode de compatibilit permettant de repasser de 2048 bits 512 bits,

  • 32 Scurit de RDP

    Protocole 2000 2003 2003 SP1 2008 XP Vista / 7

    TLS N.D. N.D. disponible disponible N.D. disponible

    CredSSP N.D. N.D. N.D. disponible N.D. disponible

    par dfaut N.A N.A. standard ngoci N.A ngoci

    Lgende :

    disponible : disponible et congurable (serveur) ;

    standard : Standard RDP Security ;

    ngoci : ngoci la connexion ;

    N.D. : non disponible ;

    N.A. : non applicable.

    Figure 6. Rsum de la disponibilit des protocoles enhanced et de la conguration

    par dfaut

    pour les clients (tels que Citrix) ne supportant pas les signatures trop

    grandes

    36

    .

    Lorsque TLS est utilis, le choix des suites de chirement est primor-

    dial, notamment pour obtenir la proprit de PFS. Or, sous Windows, la

    conguration de cette option ne peut se faire qu'au niveau du systme dans

    son intgralit. La partie recommandations prsente la marche suivre

    (voir section 6). Il reste de plus impossible de forcer l'approche directe

    (direct approach), la ngociation initiale tant obligatoire. Mais le plus

    problmatique reste l'impossibilit d'utiliser l'authentication mutuelle de

    TLS base sur un certicat client. Bien que le protocole le supporte en

    thorie, l'interface de conguration ne permet pas une telle utilisation.

    Lorsque CredSSP est congur, il est impossible de forcer l'utilisa-

    tion de NTLM ou de Kerberos.

    Malgr l'utilisation massive de TLS (nativement ou par CredSSP,

    il n'est pas possible de raliser l'authentication cliente via TLS.

    Il est impossible de congurer les suites cryptographiques TLS

    utilises par RDP (ct serveur ou client) sans aecter l'ensemble

    de la conguration du systme. Cette modication n'est donc pas

    raliste en pratique.

    Autres implmentations En dehors de l'implmentation de Microsoft,

    il existe quelques implmentations de serveurs RDP. Bien qu'il soit dicile

    36. KB949914 : http://support.microsoft.com/kb/949914

  • A. Bordes, A. Ebalard, R. Rigo 33

    de les numrer, car elles peuvent parfois tre intgres au sein d'quipe-

    ments embarqus, on peut noter parmi les implmentations propritaires

    celle de VirtualBox, disponible dans les plugins non-libres. Implmente

    en C++, elle semble dirente des autres implmentations connues mais

    implmente (au moins) TLS.

    Du ct des implmentations libres, deux produits relativement

    proches implmentent le protocole : FreeRDP [2] et xrdp [11]. L'implmen-

    tation de FreeRDP reste exprimentale et propose d'exporter un serveur

    X via RDP. xrdp est un peu plus complexe et dispose d'un gestionnaire de

    session intgr lui permettant d'authentier l'utilisateur localement mais

    galement de faire passerelle vers d'autres serveurs RDP.

    5.2 Ct client

    Microsoft (mstsc.exe) Le client ociel de Microsoft est intressant

    tudier, son interface et son comportement changeant de manire signi-

    cative au l des versions. Comme prsent dans l'historique, le support

    de TLS n'apparat qu'avec le client pour 2003 SP1. Le support de Cred-

    SSP arrive avec le client 6.1. Il reste nanmoins impossible de spcier

    dans la conguration du client la couche de scurit utiliser. Le choix

    entre Standard et Enhanced RDP Security sera donc ngoci chaque

    connexion, ce qui pose videmment un problme tant donn l'infriorit

    fondamentale du mode standard.

    Standard RDP security :

    Pour les clients utilisant le mode standard, il est impossible de choisir

    ou mme d'obtenir des informations sur la taille de cl utilise pour le

    chirement. Il en est de mme pour l'utilisation des salted MAC.

    La conguration du niveau FIPS ne peut tre par ailleurs ralise que

    par un paramtre

    37

    global du systme ( partir de XP) ayant un impact

    sur l'ensemble des composants Windows utilisant de la cryptographie.

    Il est donc impossible d'avoir une indication sur le niveau de scurit

    en pratique : taille de la cl publique du serveur, algorithme et taille de

    clef utilise ou encore utilisation de salted MAC. La seule solution est

    d'analyser les paquets rseau dans le dtail.

    Enhanced RDP Security (TLS et CredSSP) :

    L'utilisation de CredSSP ncessite un client en version 6.1 au mini-

    mum. Lors de l'utilisation de ce moyen d'authentication, la logique de

    37. http://support.microsoft.com/kb/811833

  • 34 Scurit de RDP

    connexion et de validation de l'authentication du serveur par le client

    est relativement complexe. Le client, en version 7 et suprieure, considre

    le serveur comme authenti lorsque :

    la connexion est tablie en Enhanced et :

    le certicat X.509 est valid par une chane de certication valide

    ou

    l'authentication CredSSP s'eectue avec Kerberos.

    Le client ache alors un cadenas dans la barre d'tat suprieure, indiquant

    le type d'authentication ayant t utilise.

    Contrairement la version 7, la version 6.1 prsente une vulnrabilit :

    le client considre qu'une authentication CredSSP avec NTLMSSP sut

    authentier le serveur.

    Les dernires versions du client Microsoft (versions 6.0 et suprieures)

    proposent en cas d'chec d'authentication de garder un condensat du

    certicat

    38

    dans le but de ne plus importuner l'utilisateur avec un mes-

    sage d'avertissement lors des prochaines connexions au mme serveur,

    la manire des clients SSH. Dans ce cas, la barre d'tat aprs connexion

    ne montre pas de cadenas.

    Tous les autres cas vont donc dclencher l'achage d'un avertissement

    lorsque l'option de scurit est positionne M'avertir. Dans cette

    conguration, le client eectue les tapes suivantes :

    1. tablissement de la premire connexion au serveur ne disposant pas

    d'un certicat valide ;

    2. coupure de la connexion TCP ;

    3. prsentation du certicat serveur l'utilisateur pour validation ou va-

    lidation implicite si l'utilisateur a coch ne plus m'avertir ;

    4. tablissement d'une nouvelle session TCP ;

    5. tablissement du canal TLS ;

    6. ici, le client ne vrie pas que le certicat prsent par

    le serveur correspond celui prsent lors de la premire

    connexion ;

    7. envoi du login / mot de passe protg avec le mode de scurit ngoci.

    Il est donc possible pour un attaquant pouvant raliser un MITM

    d'obtenir le mot de passe de l'utilisateur en clair, sans que celui-ci puisse

    le dtecter. Il lui sut de laisser la premire connexion TCP s'tablir de

    manire transparente et d'eectuer une attaque MITM classique sur la

    38. Le condensat du certicat est stock dans l'attribut CertHash sous la cl

    HKCU\Software\Microsoft\Terminal Server Client\Servers\Nom Serveur.

  • A. Bordes, A. Ebalard, R. Rigo 35

    deuxime connexion TLS. Nanmoins, une bonne conguration, dcrite

    dans la partie 6, permet d'viter ce problme.

    Il est important de noter que mme si le client disposait dj de l'em-

    preinte du certicat (si l'utilisateur l'avait au pralable sauvegarde) lors

    de la premire connexion, celui-ci coupe toujours la connexion et ne valide

    pas le second certicat prsent.

    Autres clients Les autres clients les plus connus sont bien videmment

    rdesktop [4] et FreeRDP [2], le second tant un fork du premier, dont

    le dveloppement stagnait quelque peu. Ils sont principalement utiliss

    pour se connecter depuis des machines non-Windows. FreeRDP volue

    trs rapidement et supporte depuis peu la majorit des fonctionnalits de

    la version 7 du protocole. Au niveau des options de scurit, il supporte

    CredSSP et TLS.

    rdesktop ne supporte quasiment aucune fonction de scurit : ni

    salted MAC, ni TLS, ni CredSSP. FreeRDP n'utilise pas les salted

    MAC par dfaut et ne supporte pas Kerberos.

    Il existe galement de nombreux clients propritaires, notamment pour

    plate-formes mobiles.

    6 Recommandations

    Cette partie prsente l'ensemble des recommandations relatives aux

    aspects conguration et architecture permettant une utilisation plus s-

    curise de RDP.

    6.1 Congurer les options lies RDP

    Ct client :

    Indpendamment du systme d'exploitation, si le client Microsoft est

    utilis (mstsc), la premire recommandation est de le mettre jour an

    de disposer de la dernire version (actuellement la version 7.0). Ceci per-

    met par exemple sur un Windows XP SP3 de bncier nativement de

    TLS pour protger les sessions RDP. Ceci permet gnralement de pro-

    ter d'amlioration d'ergonomie et de corrections de bogues. Toutefois,

    mme avec un client jour, l'ensemble des fonctionnalits supportes par

    la version du protocole RDP associe ne sont pas ncessairement dispo-

    nibles automatiquement. C'est notamment le cas pour les mcanismes

    de scurit. Par exemple, un client 7.0 sous Windows XP SP3 jour ne

  • 36 Scurit de RDP

    pourra pas s'appuyer sur CredSSP, sauf activer spciquement celui-ci

    via la base de registre. Il est donc important de bien comprendre le niveau

    de scurit atteint par la combinaison du client et du systme d'exploita-

    tion : ceci demande un eort consquent qui est en pratique dicilement

    ralisable du fait du volume de la documentation Microsoft.

    Concernant les possibilits de paramtrage de la scurit sur le client,

    celles-ci sont limites. En pratique, l'interface permet uniquement de for-

    cer l'authentication du serveur et de contrler la raction du client en

    cas d'chec d'authentication du serveur. L'option Ne pas tablir la

    connexion permet ainsi :

    1. de dsactiver l'utilisation de Standard RDP Security, qui ne permet pas

    d'authentier le serveur et autorise donc des attaques par le milieu ;

    2. de stopper la connexion si l'authentication choue.

    Toutefois, mme avec cette option active, si NTLMSSP est utilis

    par CredSSP pour l'authentication, le client avertira l'utilisateur et cou-

    pera la connexion uniquement aprs avoir transmis le d/rponse (LM,

    NTLM ou NTLMv2).

    Le client mstsc ne permet pas de congurer spciquement le SSP

    (Kerberos ou NTLMSSP) que CredSSP va utiliser.

    Si CredSSP utilise NTLMSSP pour l'authentication et que celle-

    ci choue, un d/rponse a malgr tout t transmis.

    On retombe alors sur des recommandations classiques lies NTLM-

    SSP, qui sont de disposer d'une politique de mots de passe forts et d'utiliser

    exclusivement NLTMv2. Ceci permet de se prmunir contre le cassage de

    mot de passe partir d'un d/rponse.

    Dans un domaine Active Directory, l'option Ne pas tablir la

    connexion peut tre dploye via une stratgie de groupe

    39

    . Cette stra-

    tgie, une fois active, empche l'utilisateur d'ouvrir une session sur une

    machine non authentie par certicat (TLS) ou Kerberos (CredSSP).

    Malgr tout, il est important de noter que le seul mode de protec-

    tion des changes disponibles sur un serveur RDP sous Windows XP est

    le mode Standard RDP Security. La recommandation concernant le com-

    portement adopter par le client empche donc la connexion ce type de

    systme.

    39. Conguration Ordinateur, Modles d'administration, Composants Windows, Ser-

    vices Bureau distance, Client Connexion Bureau Distance, Congurer l'authenti-

    cation du serveur pour le client.

  • A. Bordes, A. Ebalard, R. Rigo 37

    Quant CredSSP, il amliore le processus d'authentication mais son

    utilisation ne peut tre force au niveau du client. Il est donc ncessaire

    d'duquer les utilisateurs an qu'ils puissent dterminer si CredSSP est

    utilis (ou non) :

    si les authentiants sont demands avant la mise en place de laconnexion et du dport d'achage, CredSSP est utilis ;

    si la connexion s'tablit et que les authentiants sont demands dansl'achage dport, via les classiques Credentials Providers, CredSSP

    n'a pas t utilis. Dans ce cas, il ne faut pas continuer la session

    (et surtout ne pas saisir ses authentiants).

    Le client mstsc ne permet pas de forcer l'utilisation de CredSSP ;

    il permet au mieux de dsactiver Standard RDP Security.

    Parmi les clients libres, FreeRDP est actuellement le seul four-

    nissant un minimum de scurit ; il est utiliser avec les options

    --sec tls et a minima avec --salted-checksum.

    Ct serveur :

    Sur un systme Windows serveur (2003 SP1 2008 R2), plusieurs op-

    tions de conguration sont disponibles dans l'interface de conguration du

    service Terminal Server. Les paramtres recommands sont les suivants :

    Couche de scurit = SSL (TLS 1.0) : cette option permet deforcer le mode Enhanced RDP Security ;

    N'autoriser que la connexion des ordinateurs excutant le Bureau distance avec authentication NLA = activ : cette option permetd'imposer CredSSP pour l'authentication.

    Ces paramtres peuvent tre dploys au moyen d'une GPO

    40

    .

    6.2 Mettre en place une PKI

    L'authentication du serveur lors de la monte de session TLS (vali-

    dation du certicat serveur) est la seule solution d'authentication dans

    les environnements sans domaine Active Directory ou lorsque le client ne

    peut pas joindre un KDC (par exemple dans le cas d'accs distants).

    Aprs la mise en place d'une PKI, un certicat X.509 doit tre install

    sur le serveur et slectionn dans l'interface de conguration des services

    40. Conguration Ordinateur, Modles d'administration, Composants Windows, Ser-

    vices Bureau distance, Hte de la session distance, Scurit.

  • 38 Scurit de RDP

    Terminal Server. Le Common Name de l'objet du certicat doit corres-

    pondre au nom utilis par les clients pour rfrencer le serveur. De mme,

    les attributs suivants doivent tre positionns dans le certicat :

    X509v3 Key Usage = Key Encipherment, Data Encipherment ; X509v3 Extended Key Usage = TLS Web Server AuthenticationLa conguration du client pour permettre la validation du certicat est

    galement un prrequis l'authentication du serveur. Pour cela, l'ancre

    racine de l'autorit doit tre installe sur le client.

    Malgr tout, dans un domaine o Kerberos est fonctionnel, CredSSP

    sera utilis plutt que TLS pour l'authentication du serveur. Dans ce cas,

    bien que CredSSP monte une session TLS, il n'imposera pas la validation

    du certicat prsent par le serveur, l'authentication du serveur pouvant

    intervenir ensuite via Kerberos. Dans ce cas, la mise en place d'une PKI

    n'apporte malheureusement rien.

    6.3 Utiliser IPsec

    IPsec, nativement intgr aux systmes Windows depuis la version

    2000, peut tre utilis pour protger le trac rseau li RDP. L'utilisation

    d'IPsec permet l'authentication mutuelle par certicat du client et du

    serveur lors de la ngociation IKE initiale.

    La mise en uvre d'une telle architecture ncessite nanmoins la cra-

    tion d'une PKI pour supporter la gnration des certicats client et ser-

    veur.

    Sur un domaine Active Directory, l'utilisation de Kerberos pour l'au-

    thentication mutuelle lors de la ngociation IKE pourra se substituer

    l'utilisation de certicats. Malgr tout, ce mode ncessite l'accs au KDC

    et limite donc son dploiement au rseau local.

    Mme si les garanties obtenues sont fortes, la mise en uvre d'IPsec

    dans les environnements Windows a un cot lev.

    6.4 Changer les pratiques d'administration

    Un autre moyen pour scuriser RDP est de ne pas l'utiliser.

    De manire gnrale, les administrateurs utilisent RDP an d'ouvrir

    une session graphique sur un serveur dans le but d'utiliser les outils d'ad-

    ministration installs localement sur le serveur.

    Or certains services peuvent tre administrs distance et pas n-

    cessairement depuis le serveur sur lequel ils s'excutent. Dans ce cas, la

  • A. Bordes, A. Ebalard, R. Rigo 39

    mthode consiste utiliser des outils d'administration depuis un systme

    distant ddi.

    C'est en particulier le cas pour les services Microsoft dont la quasi-

    totalit sont administrables distance, gnralement au moyen des RPC.

    De mme, les outils baptiss Outils d'administration de serveur distant

    permettent d'administrer tous les rles et les fonctionnalits d'un serveur

    Windows (contrleur de domaine, gestion des utilisateurs, DNS, DHCP,

    etc.).

    Microsoft pousse d'ailleurs de plus en plus vers cette mthode d'ad-

    ministration distance avec les versions dnommes Server Core des

    ditons serveur de Windows qui sont dpourvues d'interface graphique.

    Enn, Powershell prend une part de plus en plus importante dans l'ad-

    ministration des services Microsoft via des services Web de type WinRM

    41

    ou ADWS

    42

    .

    Nanmoins, ces alternatives se limitent gnralement aux services Win-

    dows et ne permettent donc pas nativement de supporter les besoins d'ad-

    ministration d'applications tierces. De plus, mme si ceux-ci ne ncessite

    pas le transport du mode de passe ou du code PIN de l'utilisateur, leur

    scurit reste tudier, ceux-ci ayant gnralement t dvelopps bien

    avant RDP et pour une utilisation sur le rseau local, suppos de conance.

    6.5 Architecturer le rseau

    Au nal, si RDP doit tre utilis, il faut le considrer comme un pro-

    tocole d'administration et donc l'isoler des ux clients au moyen d'une

    architecture rseau adapt.

    Ainsi, des rseaux d'administration ddis doivent tre crs, spars

    des rseaux utilisateurs. Ceci peut tre ralis

    par de la segmentation au niveau 2 (VLAN ou commutateurs ddis)

    au niveau 3 en plaant les rseaux d'administration sur des plans

    d'adressage spciques ; l'accs aux serveurs administrer tant

    alors rout et ltr pour n'autoriser que les machines d'adminis-

    tration accder au service RDP.

    Dans un environnement Active Directory, la segmentation au niveau

    2 trouve rapidement ces limites, notamment du fait que la seule congu-

    ration support pour un DC se limite une interface rseau unique. Elle

    reste nanmoins utilisable pour les autres serveurs.

    41. Windows Remote Management.

    42. Active Directory Web Services.

  • 40 Scurit de RDP

    7 Conclusion

    D'un point de vue fonctionnel, RDP est un protocole bien architectur

    comme le montrent les nouvelles fonctionnalits ajoutes au l des ver-

    sions. Il est galement particulirement ecace en matire de ractivit et

    de bande passante. En revanche, ces avantages sont obtenus au prix d'une

    complexit protocolaire qui rend sa comprhension et son implmentation

    diciles.

    De plus, les mcanismes de scurit ad-hoc intgrs initialement se sont

    avrs vulnrables de nombreuses attaques lmentaires. Les corrections

    et volutions apportes depuis ont permis d'amliorer sensiblement le ni-

    veau de scurit, sous rserve de conguration.

    Nanmoins les points suivants viennent ternir le tableau :

    pour supporter les besoins de rtro-compatibilit, l'architecture ac-

    tuelle des mcanismes de scurit est extrmement complexe ;

    de par leur conception et malgr l'utilisation sous-jacente de proto-

    coles prouvs (TLS), les nouveaux mcanismes propritaires restent

    diciles valuer ;

    les implmentations de Microsoft ne permettent ni la conguration

    ni la visualisation des paramtres de scurit.

    Au nal, si RDP doit tre utilis, il est ncessaire de mettre en uvre

    les recommandations prsentes en section 6 pour atteindre un niveau de

    scurit acceptable.

  • A. Bordes, A. Ebalard, R. Rigo 41

    Rfrences

    1. Blog de l'quipe Remote Desktop Services. http://blogs.msdn.com/b/rds/.

    2. FreeRDP. http://www.freerdp.com/.

    3. Microsoft Windows NT Server, Terminal Server Edition, version 4.0 : An Archi-

    tectural Overview. http://technet.microsoft.com/en-us/library/cc751283.

    aspx.

    4. rdesktop : A Remote Desktop Protocol client. http://www.rdesktop.org/.

    5. Remote Desktop Services Component Architecture Poster. http://www.

    microsoft.com/download/en/details.aspx?id=3262.

    6. Rfrentiel Gnral de Scurit. http://www.ssi.gouv.fr/fr/

    reglementation-ssi/referentiel-general-de-securite/.

    7. Various RDP-related articles on MS Technet. http://technet.microsoft.com/

    en-en/.

    8. Wikipedia Article : Remote Desktop Protocol. http://en.wikipedia.org/wiki/

    Remote_Desktop_Protocol.

    9. Wikipedia Article : Remote Desktop Services. http://en.wikipedia.org/wiki/

    Remote_Desktop_Services.

    10. Windows 2000 High Encryption Pack. http://www.microsoft.com/download/en/

    details.aspx?id=15667.

    11. xrdp. http://www.xrdp.org/.

    12. FIPS 140-1 : Security requirements for cryptographic modules. http://csrc.nist.

    gov/publications/fips/fips1401.htm, 01 1994.

    13. Microsoft KB275727 : High Encryption on a Remote Desktop or Terminal Ser-

    vices Session Does Not Encrypt All Information. http://support.microsoft.

    com/default.aspx?scid=kb;en-us;275727, 2001.

    14. Microsoft Security Bulletin MS01-006 : Invalid RDP Data can cause Ter-

    minal Server Failure. http://technet.microsoft.com/security/bulletin/

    MS01-006/ et http://support.microsoft.com/default.aspx?scid=kb;en-us;

    286132, 01 2001.

    15. Microsoft Security Bulletin MS01-040 : Invalid RDP Data can Cause Memory

    Leak in Terminal Services. http://technet.microsoft.com/security/bulletin/

    MS01-040/ et http://support.microsoft.com/default.aspx?scid=kb;en-us;

    292435, 07 2001.

    16. Microsoft Security Bulletin MS01-052 : Invalid RDP Data can Cause Ter-

    minal Service Failure. http://technet.microsoft.com/security/bulletin/

    MS01-052/ et http://support.microsoft.com/default.aspx?scid=kb;en-us;

    307454, 10 2001.

    17. Microsoft Security Bulletin MS02-046 : Buer Overrun in TSAC ActiveX Control

    Could Allow Code Execution. http://technet.microsoft.com/security/

    bulletin/MS02-046/ et http://support.microsoft.com/default.aspx?scid=

    kb;en-us;327521, 08 2002.

    18. Microsoft Security Bulletin MS02-051 : Cryptographic Flaw in RDP Protocol

    can Lead to Information Disclosure. http://technet.microsoft.com/security/

    bulletin/MS02-051/ et http://support.microsoft.com/default.aspx?scid=

    kb;en-us;324380, 09 2002.

  • 42 Scurit de RDP

    19. Factorisation de clef RSA 518 bits. http://www.mersenneforum.org/showpost.

    php?p=124079&postcount=97, 2003.

    20. Microsoft Terminal Services vulnerable to MITM-attacks. http://www.

    securityfocus.com/archive/1/317244, May 2003.

    21. CVE-2005-1794. http://cve.mitre.org/cgi-bin/cvename.cgi?name=

    CVE-2005-1794 et http://www.oxid.it/downloads/rdp-gbu.pdf, 05 2005.

    22. Microsoft Security Bulletin MS05-041 : Vulnerability in Remote Desktop Proto-

    col Could Allow Denial of Service. http://technet.microsoft.com/security/

    bulletin/MS05-041/ et http://support.microsoft.com/default.aspx?scid=

    kb;en-us;899591, 08 2005.

    23. Microsoft Security Bulletin MS09-044 : Vulnerabilities in Remote Desk-

    top Connection Could Allow Remote Code Execution. http://technet.

    microsoft.com/security/bulletin/MS09-044/ et http://support.microsoft.

    com/default.aspx?scid=kb;en-us;970927, 08 2009.

    24. Credential Security Support Provider (CredSSP) Protocol Specication. http:

    //microsoft.com/, 09 2011.

    25. Microsoft Security Bulletin MS11-017 : Vulnerability in Remote Desktop

    Client Could Allow Remote Code Execution. http://technet.microsoft.com/

    security/bulletin/MS11-017/ et http://support.microsoft.com/default.

    aspx?scid=kb;en-us;2508062, 03 2011.

    26. Microsoft Security Bulletin MS11-061 : Vulnerability in Remote Desk-

    top Web Access Could Allow Elevation of Privilege. http://technet.

    microsoft.com/security/bulletin/MS11-061/ et http://support.microsoft.

    com/default.aspx?scid=kb;en-us;2546250, 08 2011.

    27. Microsoft Security Bulletin MS11-065 : Vulnerability in Remote Desktop Proto-

    col Could Allow Denial of Service. http://technet.microsoft.com/security/

    bulletin/MS11-065/ et http://support.microsoft.com/default.aspx?scid=

    kb;en-us;2570222, 08 2011.

    28. Remote Desktop Protocol : Basic Connectivity and Graphics Remoting Specica-

    tion. http://microsoft.com/, 03 2011.

    29. Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Extension.

    http://microsoft.com/, 09 2011.

    30. Microsoft Security Bulletin MS12-020 : Vulnerabilities in Remote Desktop Could

    Allow Remote Code Execution. http://technet.microsoft.com/security/

    bulletin/MS12-020/ et http://support.microsoft.com/default.aspx?scid=

    kb;en-us;2671387, 03 2012.

    31. Hugo Krawczyk. The order of encryption and authentication for protecting com-

    munications (or : how secure is ssl ?). IACR Cryptology ePrint Archive, 2001 :45,

    2001.

    32. G. Pall. Microsoft Point-To-Point Compression (MPPC) Protocol. RFC 2118

    (Informational), March 1997.