Vous êtes sur la page 1sur 40

Scurit de RDP

Aurlien

Bordes, Arnaud Ebalard et Raphal Rigo


prenom.nom@ssi.gouv.fr
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 dtails et leurs faiblesses rsiduelles dcrites. En particulier, les modes historiques de protections oerts par RDP, propritaires, sont particulirement 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.

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] , 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 principalement sur les solutions serveur et client Microsoft, intgres au systme
d'exploitation.

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

Scurit de RDP

1.2 Besoin d'administration distance


La plate-forme Windows, de par son utilisation massive et historiquement obligatoire des interfaces graphiques, rend ncessaire l'utilisation
d'un protocole de dport d'achage pour de nombreuses tches d'administration 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, notamment 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 malgr

une scurit des plus limite dans son implmentation usuelle. Certaines 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 attendues 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 horsligne 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

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 asymtriques 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 prcdemment 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'informations : 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'administration. 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 modication 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 propritaires faibles peuvent avoir un impact fort sur la condentialit ou l'intgrit 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, toujours 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

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 lments 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 facilement 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.

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 spcications 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 priphriques 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

presse-papiers local et distant ou encore l'impression ct client font galement 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 . 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. Dnomm

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

Bitmap Updates, sont galement transSlow-Path et Fast-Path introduits prcdemment.

client. Ces lments, dnomms


ports dans des PDU

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 .


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 paramtrage 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 virtuels permettant les communications entre composants du systme local
et du systme distant. Ce mcanisme est utilis notamment pour le transport 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.

Scurit de RDP

1. les direntes fonctionnalits supportes par RDP, amenant chacune


sa part de complexit l'ensemble protocolaire, par des liens supplmentaires 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 mcanismes 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.

Ports
srie
et //
Systme
de chier

Pressepapier

Sessions
Accl.
GDI
Remote

Fonctionnalits

Protocol

Imprimante
Audio
in/out

Proprio.
MS

Carte
puce

Scurit
low

TSSP

Kerberos

ASN.1

Plomberie

Desktop

USB

NTLM

UIT
T.120

X.224

SPNEGO

CredSSP

Enhanced
RDP
Security

Standard
RDP
Security

clientcompat.

high

TLS
FIPS

Figure 1. Vue d'ensemble du protocole

IETF

A. Bordes, A. Ebalard, R. Rigo

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 .


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 . 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 dplacement 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 ----->
<--- IP/TCP/TPKT/X.224Data/T.125-SendDataIndication ------ IP/TCP/TPKT/X.224Data/T.125-SendDataRequest ----->

8. Contrairement Wireshark, les versions rcentes de Network Monitor sont capables 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

<--- IP/TCP/TPKT/X.224Data/T.125-SendDataIndication --...


Dans la terminologie RDP, les paquets dcrits prcdemment sont dnomms

Slow Path.

Pour diminuer la bande passante consomme et amliorer la ractivit,


Microsoft a introduit partir de RDP 5.0 (Windows 2000) des optimisations permettant de supprimer une partie de l'encapsulation pour certains
paquets courts comme les entres souris/claviers et les mises jour graphiques.
Ces optimisations prennent la forme d'un nouveau type de paquet,
dnomm

Fast-Path,

qui suppriment les headers TPKT, X.224 et T.125

pour transporter de manire compresse leur contenu.

Exemple de monte de session

La liste ci-dessous prsente squen-

11 et type de messages changs lors d'une monte


tiellement les 8 tapes
de session RDP. Elle reprend ainsi la squence dcrite en section 1.3.1 de
[28], en se concentrant sur les aspects scurit.
1.

Connection Initiation
Client
Serveur
---- X.224 Connection Request PDU ----------------->
<--- X.224 Connection Confirm PDU -----------------L'change de ces paquets X.224 permettent d'initier la connexion. Tous
les paquets changs par la suite seront encapsuls dans des paquets
de donnes X.224.
Le premier paquet contient la liste des protocoles de scurit supports
par le client, sous la forme d'un champ de bits, autorisant le choix des
ags suivants :




PROTOCOL_RDP : Standard RDP Security


PROTOCOL_SSL : TLS 1.0
PROTOCOL_HYBRID : CredSSP 12

La rponse du serveur contient sa dcision sur le mcanisme slectionn

Standard ou Enhanced RDP Security ). Dans ce cadre :


Enhanced RDP Security a t slectionn (CredSSP ou TLS ), une

 si

session TLS est monte entre le client et le serveur, et les messages


suivants sont donc changs sous la protection de cette session ;

11. Les noms anglais des tapes ont t conservs pour plus de lisibilit.
12. Dans ce cas, le ag PROTOCOL_SSL est aussi positionn (CredSSP utilise TLS).

A. Bordes, A. Ebalard, R. Rigo

 si

Standard RDP Security

11

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
---- MCS
GCC
<--- MCS
GCC

Serveur
Connect Initial PDU with ----------------->
Conference Create Request
Connect Response PDU with ----------------Conference Create Response

Ces deux paquets T.125 sont encods en ASN.1. Les donnes utilisateurs transportes dans le premier paquet (mis par le client)
contiennent notamment des informations sur la machine cliente (taille

layout, etc). Le protocole de scurit slectionn prcdemment par le serveur y est galement rpt (Standard
RDP Security ou Enhanced RDP Security ).
de l'cran, type de clavier,

Par ailleurs, les donnes utilisateurs transportes par le paquet client


incluent galement,

via

le champ

encryptionMethod, les combinai-

sons d'algorithmes et de tailles de cls supportes par le client pour le


mode

Standard RDP Security

 cls de 40 bits pour RC4 et le MAC ;


 cls de 56 bits pour RC4 et le MAC ;
 cls de 128 bits pour RC4 et le MAC ;
 triple DES avec cls de 168 bits et HMAC-SHA1 (Mode FIPS).
Le choix de la mthode de protection (algorithme et taille de cls) slectionne par le serveur dans le second paquet dpend de sa conguration (niveau

low, client-compatible, high ou FIPS ). Ce paquet intgre


Standard RDP Security le nonce serveur (32

galement pour le mode

octets, mis en clair) utiliser pour la drivation de cl, ainsi que la


cl publique signe

13 du serveur. Cette cl sera utilise par le client

l'tape 4 pour la transmission chire de son

nonce

(32 octets), par-

ticipant galement la drivation de cl.


3.

Channel Connection
Client
------<------

MCS
MCS
MCS
MCS

Serveur
Erect Domain Request PDU ----------------->
Attach User Request PDU ------------------>
Attach User Confirm PDU ------------------Channel Join Request PDU ----------------->

13. Voir la description du

CVE-2005-1794. en section 3.8.

12

Scurit de RDP

<--- MCS Channel Join Confirm PDU --------------------- MCS Channel Join Request PDU ----------------->
<--- MCS Channel Join Confirm PDU -----------------...
---- MCS Channel Join Request PDU ----------------->
<--- MCS Channel Join Confirm PDU -----------------Les 3 premiers paquets sont associs au protocole T.125 et n'ont

MCS
Channel Join Request PDU et MCS Channel Join Confirm PDU perpas d'intrt particulier pour la discussion. Chaque change de

met au client RDP de l'utilisateur de joindre les canaux virtuels de


son choix.
Suite cette tape, l'ensemble des messages changes entre le client
et le serveur sont respectivement des

MCS Send Data Request et

MCS Send Data Indication.


Pour le moment, si Standard RDP Security a t choisi, les PDU changes ne sont toujours pas protges.
4.

RDP Security Commencement


Client
Serveur
---- Security Exchange PDU ------------------------>
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 attaquant 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 rcentes), 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

autologon.

le systme distant, pour permettre l'

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

6.

13

Licensing
Client
Serveur
<--- License Error PDU - Valid Client -------------Ce message est utilis pour le transfert d'une licence du serveur au
client, dans le cas o RDP est utilis avec un serveur de licence.

7.

Capabilities Exchange
Client
Serveur
<--- Demand Active PDU -------------------------------- Confirm Active PDU --------------------------->
Cet change permet au client et au serveur de se synchroniser sur
les fonctionnalits supportes (taille de buer de compression MPPC,
niveau de support GDI+, etc).
Aprs cet change, le client peut commencer mettre vers le serveur
des entres souris et clavier.

8.

Connection Finalization
Client
---------------<--<--<--<---

Serveur
Synchronize PDU ------------------------------>
Control PDU - Cooperate ---------------------->
Control PDU - Request Control ---------------->
Persistent Key List PDU(s) ------------------->
Font List PDU -------------------------------->
Synchronize PDU ------------------------------Control PDU - Cooperate ----------------------Control PDU - Granted Control ----------------Font Map PDU ----------------------------------

Ces changes permettent notamment la synchronisation graphique.


Aprs rception du paquet

Font List PDU, le serveur peut commencer

l'mission de donnes graphiques au client.

Historique de RDP
Le protocole RDP est apparu avec Windows NT Server 4.0, dans sa

version

Terminal Server Edition (TSE), avec l'objectif initial de supporter

le dport d'achage dans des solutions de clients lgers.


La fonctionnalit de bureau distance permettant d'administrer graphiquement un systme Windows s'est ensuite dmocratise avec Windows 2000. Depuis, le protocole a volu rgulirement, au l des diffrentes versions et

service pack

(SP) de Windows : support du dport

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 nombreuses sources [8,9,7,1], retrace l'historique des versions du protocole en
donnant notamment les versions de systmes avec lesquels ils ont t introduits, 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 

dium

(dfaut),

high

low, me-

 dcrits en section 4. Avec RDP 4.0, ces dirents

niveaux reposent tous sur l'utilisation d'un chirement RC4 40 bits. L'intgrit est assure

via

un pseudo-HMAC

16 .

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

Standard RDP Security dcrit en section 4.1) sont cette poque

tocole (

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

Enhanced RDP

version 5.2, introduite avec Windows Server 2003 SP1 (

Security dcrit en section 4.2).

3.2 RDP 5.0 (Windows 2000)


Introduite avec Windows 2000, cette version apporte de nouvelles fonctionnalits : 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 MS02051 [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 apporte 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, Windows 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'envisager 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 versions 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 support 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

20 du mcanisme CredSSP
21
et aprs installation de la version 6.1 ou suprieure du client RDP .
fonctionnel qu'aprs passage au SP3, activation

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 version 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 rfrences. 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 Lead
to Information Disclosure
KB275727 [13] : High Encryption on a Remote Desktop or Terminal Services Session Does Not Encrypt All Information
Forsberg03 [20] : Microsoft Terminal Services vulnerable to
MITM-attacks
CVE-2005-1794 [21] : shared RSA key is embedded in RDP
library mstlapi.dll
Les quelques dnis de services rfrencs sont probablement le reet
de la complexit du protocole et de la dicult en raliser une implantation 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 historique 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).

erreur de conception cryptographique gnrique dcrite par Hugo Krawczyk dans [31], connue sous le nom
authenticate-and-encrypt. Elle consiste calculer un motif d'intL'une d'elle est une

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


deux rsultats. Deux clairs identiques possdent alors le mme motif 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 transportes 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 capable, par une analyse frquentielle des valeurs de MAC, d'en dduire 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 pressepapiers mais galement les redirections d'impression.

Forsberg03

[20] : Dbut 2003, Eric Forsberg signale Microsoft

que 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 mcanisme d'authentication du mode

Standard RDP Security (dtaill

en section 4.1) pour les serveurs RDP dploys sur les systmes jusqu' Windows XP inclus.
Mme si des alternatives sont disponibles sur les systmes Microsoft plus rcents, des arguments de rtrocompatibilit font que ce
mcanisme reste utilisable sur certains d'entre eux.

A. Bordes, A. Ebalard, R. Rigo

19

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 niveaux de protection dirents, que les clients et serveurs peuvent ngocier.
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 protocoles 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

HMAC-SHA1.

Low Le premier niveau, dnomm

low,

Triple DES

et

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

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

notamment la saisie de son mot de passe dans la GINA

25 ou

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'authentication 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 imposant 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

Low
Client Compatible
High
FIPS

cs
chir
chir
chir
chir

sc

clair

chir
chir
chir

mthode

algo

MAC

max serveur
n/a

RC4
RC4
RC4
3DES

MD5/SHA1
MD5/SHA1
MD5/SHA1
HMAC-SHA1

max client
max client

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 concurrentes, 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

change de cls

21

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

ClientRandom ). Le serServerRandom de 32 octets (non chir) lors de

de 32 octets produit par le client (appel

veur envoie galement un


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

cl ngocie. Le mode

EncCount

salted MAC

ou

MACKey128,

selon la taille de

intgre un compteur supplmentaire,

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


MACSignature = First64Bits(MD5(MACKeyN + Pad2 + SHAComponent))
EncCount reprsente le nombre d'oprations de chirement qui ont
ralises jusqu'ici, dans le sens de communication concern (CS ou

Ici
t

SC).

22

Scurit de RDP

Analyse de scurit L'analyse ne concernera que les niveaux de chiffrement compatible client
et niveau lev, qui sont ceux gnralement
rencontrs. Les niveaux faible et FIPS ne sont en pratique jamais rencontrs 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, Standard 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.

Security Support

Les mcanismes de protection externes sont les SSP (

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 une

authentication 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 luimme 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 mcanisme 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

NTLM

TSSSP

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 problmatique est abord en section 5.2.

CredSSP :
Credential Security Support Provider [24] est le SSP apparu avec Windows Vista/2008

28 . Dans le principe, ce SSP implmentant un mcanisme

Network Level Authentication) vise ren-

d'authentication appel NLA (

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 dtailles 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

Serveur

Client

tablissement
session TLS
Client Hello, Server Hello, Certificate, Key Exchange

(Kerberos ou
dfi rponse NTLMSSP)

SPNEGO : NTLMSSP ou Kerberos (KRB_AP)


Protection SPNEGO (Ka)
Kerberos ou NTLMSSP

Protection TLS (Kt)

Phases
3
2

Authentification

Validations
(cl et session
dauthentification)

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

Dlgation
(des information
didentification)

mot de passe ou code PIN

RDP
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 Negotiate 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 NTLMSSP ou Kerberos.

26

Scurit de RDP

si le compte utilis par le client est un compte local, le serveur


rcupre 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 NTLM


est 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 Kerberos 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 (
tre associ au SPN

i.e. l'Active Directory), un compte doit

30 demand. Pour le service Terminal Server, le

SPN est de la forme

TERMSRV/nom serveur.

Le secret associ ce

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

compte (

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

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

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

30. Service Principal Name.

A. Bordes, A. Ebalard, R. Rigo

27

en possession de la mme cl (Ka ) lie l'authentication de la phase


prcdente. 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

(et TLS). Le serveur compare

Kt

Ka

celle qu'il a envoye, puis la renvoie

incrmente de 1, toujours chire avec

Ka

(et TLS). Si les changes ont

abouti, 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 lments 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 automatiquement (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 Security 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 mcanismes 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 certicat 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 pratiquement 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 automatiquement 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


33 dans le tunnel TLS, pour ensuite permettre la
Kerberos via CredSSP
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 Microsoft 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 interactive 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

Depuis Windows Vista, il est galement possible,


groupe

via

34 .

les stratgies de

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 manire globale et impactent donc tous les services du systme utilisant TLS
au moyen de ce SSP. Dans la pratique, aucun administrateur ne se risquera 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 depuis 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 possible de forcer un ordre prcis pour les suites cryptographiques. Le principe
consiste congurer, sur le serveur, une liste d'algorithmes dont les premiers 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 supportant

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 authentication SPNEGO (NTLM ou Kerberos), l'tablissement d'un canal
chir bas sur l'authentication ralise, puis la validation de la cl publique contenue dans le certicat prsent par le serveur au client.
Concernant l'authentication base sur SPNEGO, il n'est pas possible 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 serveur indiqu par le client (le SPN recherch est de la forme

serveur).

TERMSRV/nom

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 rcuprer 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 dans


la mise en place de la session TLS ;

la seconde repose sur l'utilisateur du protocole CredSSP, seulement


si 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.

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

vice Pack

Ser-

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


Niveau

2000
dispo

en fonction des versions de Windows.

2003
dispo

2003 SP1
dispo

2008
dispo

XP
GPO

Vista / 7
GPO

Low
dfaut?
Client comp. 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

TLS
CredSSP
par dfaut

2000
N.D.
N.D.
N.A

2003 2003 SP1


2008
XP Vista / 7
N.D. disponible disponible N.D. disponible
N.D.
N.D.
disponible N.D. disponible
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 primordial, 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'utilisation 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'quipements 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'implmentation 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 signicative 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 CredSSP arrive avec le client 6.1. Il reste nanmoins impossible de spcier
dans la conguration du client la couche de scurit utiliser. Le choix

Standard

entre

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

ensemble des composants Windows utilisant de la cryptographie.

sur l'

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 minimum. 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'empreinte 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.

Recommandations
Cette partie prsente l'ensemble des recommandations relatives aux

aspects conguration et architecture permettant une utilisation plus scurise 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 permet par exemple sur un Windows XP SP3 de bncier nativement de
TLS pour protger les sessions RDP. Ceci permet gnralement de proter 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 disponibles 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'exploitation : 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 forcer l'authentication du serveur et de contrler la raction du client en
cas d'chec d'authentication du serveur. L'option

connexion permet ainsi :

1. de dsactiver l'utilisation de

Ne pas tablir la

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 coupera 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 celleci choue, un d/rponse a malgr tout t transmis.

On retombe alors sur des recommandations classiques lies NTLMSSP, 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

connexion peut tre dploye via

Ne pas tablir la

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 protection 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, Services Bureau distance, Client Connexion Bureau Distance, Congurer l'authentication 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 la


connexion et du dport d'achage, CredSSP est utilis ;

si la connexion s'tablit et que les authentiants sont demands dans


l'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 fournissant un minimum de scurit ; il est utiliser avec les options

--sec tls

Ct serveur

et

a minima

avec

--salted-checksum.

Sur un systme Windows serveur (2003 SP1 2008 R2), plusieurs options de conguration sont disponibles dans l'interface de conguration du
service Terminal Server. Les paramtres recommands sont les suivants :

Couche de scurit
forcer le mode

SSL (TLS 1.0) : cette option permet de

Enhanced RDP Security ;

N'autoriser que la connexion des ordinateurs excutant le Bureau


distance avec authentication NLA

= activ : cette option permet

d'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 (validation 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, Services 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 Authentication

La 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 cration d'une PKI pour supporter la gnration des certicats client et serveur.
Sur un domaine Active Directory, l'utilisation de Kerberos pour l'authentication 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'administration installs localement sur le serveur.
Or certains services peuvent tre administrs distance et pas ncessairement 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 quasitotalit 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'administration 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'administration des services Microsoft

42
ou ADWS .

via des services Web de type WinRM 41

Nanmoins, ces alternatives se limitent gnralement aux services Windows et ne permettent donc pas nativement de supporter les besoins d'administration 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 protocole 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'administration accder au service RDP.
Dans un environnement Active Directory, la segmentation au niveau
2 trouve rapidement ces limites, notamment du fait que la seule conguration 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

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

comme le montrent les nouvelles fonctionnalits ajoutes au l des versions. 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 niveau de scurit, sous rserve de conguration.
Nanmoins les points suivants viennent ternir le tableau :
 pour supporter les besoins de rtro-compatibilit, l'architecture actuelle des mcanismes de scurit est extrmement complexe ;
 de par leur conception et malgr l'utilisation sous-jacente de protocoles 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 Architectural 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 Services 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 Terminal 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 Terminal 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.
securityfocus.com/archive/1/317244, May 2003.

http://www.

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 Protocol 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 Desktop 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 Desktop 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 Protocol 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 Specication. 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 communications (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.