Udvidelse af Microsofts RDP-klient med API-hooking i Remote Desktop Manager

Af alle de protokoller og platforme, som Remote Desktop Manager understøtter, er RDP på Windows langt den mest populære. Microsoft tilbyder deres officielle klient til fjernskrivebord på alle platforme undtagen Linux, men den eneste RDP-klientgrænseflade, der er eksponeret til tredjepartsintegration, findes på Windows. FreeRDP er den eneste egnede RDP-klient på tværs af platforme, men den kommer aldrig på højde med den officielle Windows-RDP-klient (MSTSC). Virkeligheden er, at vi for at levere de funktioner, kunderne ønsker, har brug for fleksibiliteten i FreeRDP (open source), men inde i Microsofts RDP-klient (closed source).

Vi bygger vores egne døre

Microsofts RDP-klient er fremragende, men den eksponerer ikke alt det, der skal til for at implementere alle de funktionsønsker, vi får. Når man rammer en mur, kan man vælge at stoppe eller forsøge at bygge nye døre de steder, hvor der ikke var nogen. Det er det, vi har arbejdet på med Devolutions-projektet MsRdpEx: et sæt nye „døre“, vi har åbnet ved hjælp af Microsoft Detours Library til API-hooking. Det bygger oven på den offentlige RDP ActiveX-grænseflade for at eksponere interne komponenter og egenskaber, som ellers ikke er tilgængelige. En tidlig funktion til RDP API-hooking er allerede tilgængelig i RDM 2022.2.

Hvad er API-hooking?

API-hooking lyder mere skræmmende, end det er: det ændrer et program i hukommelsen for at opfange et funktionskald og omdirigere det til en „hook“-funktion, som du styrer. Ved for eksempel at hooke LoadLibrary-funktionen kan man justere dens adfærd, så indlæsning af „mstscax.dll“ i stedet indlæser „MsRdpEx.dll“. Med andre ord kan du „lyve“ over for programmet ved at ændre det, funktionen faktisk gør. Ikke alle funktioner kan hookes lige let: nogle er mere udsat for ændringer end andre, eller simpelthen uden for rækkevidde.

Reverse engineering

Det er closed source, ikke? Det betyder ikke kun, at der ikke er dokumentation, men også at der ikke er kildekode at grave i. Du kan læse mere om reverse engineering af Microsoft-binære filer i vores blogindlæg „Sådan finder du hemmelige RDP-registreringsnøgler med IDA Free“. Det er langt den mest omstændelige og tidskrævende proces, selv når slutresultatet bare er at vende en bit et sted. Vores uofficielle MSRDC-integration gik for eksempel i stykker for nylig med en mystisk fejlkode 3334, og det tog to hele dage med intens fejlfinding at finde ud af, at en ny intern egenskab skulle sættes til „true“.

Udvidede RDP-indstillinger

Hvilken slags indstilling i RDP-klienten kræver API-hooking? Her er en kort liste:

• UserSpecifiedServerName: En intern indstilling, der skal bruges til at angive servernavnet til validering af TLS og Kerberos, og som bruges sammen med RD Gateway-protokollen, men som ikke er eksponeret for almindelige RDP-forbindelser som dem, vi opretter til Devolutions Gateway.
• KDCProxyName: En offentligt dokumenteret indstilling til dynamisk at indsætte en KDC-proxyserver, så Kerberos kan bruges, men den anvendes kun på RD Gateway-forbindelser.
• UsingSavedCreds: En intern indstilling, der sættes forkert, hvis en adgangskode angives ved forbindelsestidspunktet, selv om den ikke er gemt. Det ødelægger indsprøjtning af legitimationsoplysninger, når gruppepolitikken „Always prompt for password upon connection“ er aktiveret.
• DisableUDPTransport: tro det eller ej, denne interne indstilling kan kun sættes via registreringsnøgler, hvilket forhindrer finkornet styring fra et værktøj til forbindelsesstyring.

De to første indstillinger, UserSpecifiedServerName og KDCProxyName, er afgørende for at gøre Kerberos muligt uden for virksomhedsnetværket, men de er begrænset specifikt til RD Gateway-protokollen. Vi har en KDC-proxyfunktion på vej i Devolutions Gateway, som skal udnytte dem, men vi ville hellere have undgået så lang en omvej med API-hooking for overhovedet at gøre det muligt.

Azure Virtual Desktop

Mange brugere har efterspurgt understøttelse af Azure Virtual Desktop, og vi er i øjeblikket halvvejs. Hvis det går godt, bør vi have en første AVD-integration i RDM 2022.3, med forbedringer senere. Her er en liste over de udfordringer, vi står over for:

• MSRDC er påkrævet til AVD, men eksponerer officielt ikke et API til integration
• MSRDC kræver RDP, der er signeret på serversiden, hvilket forhindrer administration af indstillinger på klientsiden
• Protokoludvidelserne til AVD er ikke dokumenteret, i modsætning til den almindelige RDP-protokol
• AVD-kontrolkaldene til RDP-webfeedet, som laves med Azure, er heller ikke dokumenterede

Første skridt er allerede taget: vi har formået at integrere MSRDC til almindelige RDP-forbindelser, både i indlejret og ekstern tilstand. MSRDC leveres med en færdig DLL (rdclientax.dll), der eksponerer den samme RDP ActiveX-grænseflade som den indbyggede MSTSC-DLL (mstscax.dll).

AVD tilføjer omkring 10 nye indstillinger i RDP-filer med tilhørende interne egenskaber til ActiveX. Bare det at finde ud af, hvad de var, og hvad de betød, var en udfordring, men vi har i det mindste formået at importere og eksportere dem korrekt i RDM indtil videre.

En problematisk signatur

Det gik fint, indtil vi ramte den første store blokering: AVD-RDP-filer signeres på serversiden og udgives via et særligt webfeed, som kun MSRDC ved, hvordan man henter. MSRDC opretter dog ikke AVD-forbindelser med usignerede RDP-filer, og du kan ikke ændre RDP-indstillinger på klientsiden uden at bryde signaturen. Houston, vi har et problem.

Når Remote Desktop Manager starter MSTSC eller MSRDC i ekstern tilstand, genererer den en midlertidig .RDP-fil med alle indstillingerne fra forbindelsesposten. Hvis du redigerer RDP-forbindelsesposten i RDM, får du en anden RDP-fil. Den eneste vej udenom er at oprette en forbindelsespost, der er knyttet til en lokal, uændret RDP-fil, men så kan du stadig ikke ændre den.

Hvorfor ikke signere filerne lokalt? Vi har overvejet det, men det kræver et certifikat fra en kendt, betroet udsteder. Strategier med API-hooking til at bruge en gyldig signatur fra et selvsigneret certifikat var også begrænsede. Det tog omkring to ugers arbejde endelig at finde en måde at omgå signaturkontrollen af RDP-filer for AVD-forbindelser på og få den første AVD-forbindelse startet med MSRDC fra RDM.

Er vi der snart?

Vi gør langsomme, men stabile fremskridt. AVD-forbindelser har en ekstra godkendelseskontekst med Azure, og det bliver et projekt i sig selv at håndtere den pænt. Indsprøjtning af de almindelige RDP-legitimationsoplysninger er også i stykker, så vi skal sandsynligvis finde en anden måde at gøre det på. Brugergrænsefladen til de AVD-specifikke indstillinger er ikke færdig endnu, og det er svært at navngive og strukturere dem ordentligt, når de ikke er dokumenteret. Fokus lige nu er at få det til at virke med MSRDC som et eksternt program først, fordi AVD-forbindelser med MSRDC i indlejret tilstand kommer med et andet sæt udfordringer.

Konklusion

API-hooking er godt, men det bør betragtes som en sidste udvej. Ideelt set ville de fleste af disse udvidede indstillinger have været offentligt eksponeret officielt, så vi ikke behøvede at bruge al den tid på reverse engineering og API-hooking. Er du kunde på Azure Virtual Desktop? Hvis ikke, er du så interesseret i at bruge MSRDC i stedet for MSTSC? Da ingen af de to tilfælde er officielt understøttet, vil vi sætte pris på, hvis du sender feedback til Microsoft om det.