Remote Desktop via RDP: Testen und angreifen (3/4)
Mit den richtigen Tools und dem Wissen, was sie alles können, können Admins ihre eigenen Server und Netze gezielt testen.
(Bild: Shutterstock.com)
Diese Serie zum Remote Desktop Protocol (RDP) soll vor allem Admins für die damit verbundenen Gefahren sensibilisieren und ihnen helfen, sich davor zu schützen. Der letzte Teil erklärte die verschiedenen Sicherheitseinstellungen rund um RDP; die aktuelle Folge zeigt nun, wie man seine eigenen Systeme auf mögliche Probleme testen kann.
Der Autor Jürgen Schmidt bereitet den Inhalt der kompletten Serie auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen
Das erste Ziel ist es, sich einen Überblick zu verschaffen. Dazu scannt man den entsprechenden IP-Bereich auf offene TCP-Ports 3389. Besonders schnell und effizient erledigt das das Tool masscan von Robert Graham, das – entsprechende Anbindung vorausgesetzt – auch das komplette Internet in wenigen Stunden absuchen kann, wie es etwa die Suchmaschine Shodan regelmäßig tut. (Was jedoch ziemlich sicher für Ärger sorgen würde – also scannen Sie bitte nur die eigenen Systeme).
Ganz gezielt nach Systemen, die für die Bluekeep-Schwachstelle anfällig sind, sucht das Tool rdpscan des gleichen Autors. Es liefert einen Status von SAFE, VULNERABLE oder UNKNOWN, der aber sich explizit nur auf dieses Sicherheitsloch bezieht (CVE-2019-0708). Wer die aktuellen Windows-Patches immer zügig einspielt, braucht hier keine Überraschungen zu befürchten.
NMap for the win
Für den herkömmlichen Einsatz präferiere ich den klassischen Scan mit Nmap (in den Beispielen in Version 7.80), etwa in dieser Form:
nmap -P0 -T4 -p 3389 192.168.6.0/24 --open
Das -P0 schaltet die Ping-Abfrage ab, um auch Systeme zu finden, deren Firewall diese blockiert; -T4 wählt einen schnellen Modus, -p 3389 selektiert den RDP-Port und das abschließende --open zeigt nur die Systeme mit geöffneten Ports, etwa so (farbliche Hervorhebung von mir):
Nmap scan report for 192.168.6.16
PORT STATE SERVICE
3389/tcp open ms-wbt-server
Doch nmap kann mehr als nur Port-Scans. Mit der eingebauten Nmap Scripting Engine (NSE) kann man die gefundenen Dienste gezielt auf bestimmte Informationen abfragen, etwa auf die übermittelten Windows-Netzwerk-Infos:
nmap -P0 -p 3389 --script rdp-ntlm-info 192.168.6.16
...
| rdp-ntlm-info:
| Target_Name: PROBOOK-CT-1
| NetBIOS_Domain_Name: PROBOOK-CT-1
| NetBIOS_Computer_Name: PROBOOK-CT-1
| DNS_Domain_Name: Probook-ct-1
| DNS_Computer_Name: Probook-ct-1
| Product_Version: 10.0.18362
|_ System_Time: 2020-04-23T11:15:34+00:00
Das liefert unter anderem den NetBIOS- den DNS-Namen des Systems und die zugehörigen Domains. NMap beherrscht sogar den eingebauten starttls-Mechanismus von RDP, der die TLS-Verschlüsselung aktiviert, und kann so das eingesetzte Zertifikat abfragen und anzeigen:
nmap -P0 -p 3389 --script ssl-cert 192.168.6.16
...
| ssl-cert: Subject: commonName=Probook-ct-1
| Issuer: commonName=Probook-ct-1
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2020-03-12T14:29:49
| Not valid after: 2020-09-11T14:29:49
| MD5: 279f 401b 20f0 ac8b 196d a771 62d8 703e
|_SHA-1: b7ca 06fa 676a 8c5c 6aa0 ffdf 5d28 9ed9 4e69 cdfb
Wie man sieht, handelt es sich hier um ein selbstsigniertes Zertifikat, bei dem Issuer und Subject übereinstimmen. In vielen realen Szenarios liefern Namen wie BeckDC02.GETRAENKEBECK.local einem Angreifer auch durchaus nützliche Informationen, was man als Verteidiger zumindest wissen sollte.
Böse RDP-Fallbacks
Richtig zur Sache geht es, wenn man die erlaubten Security- und Verschlüsselungsmodi abfragt. Das sieht dann im Idealfall eines fest auf NLA eingestellten RDP-Systems so aus:
nmap -P0 -p 3389 --script rdp-enum-encryption 192.168.6.16
...
| rdp-enum-encryption:
| Security layer
| CredSSP (NLA): SUCCESS
| CredSSP with Early User Auth: SUCCESS
|_ RDSTLS: SUCCESS
Erlaubt ist nur Enhanced RDP Security mit CredSSP und ein spezieller Modus namens RDSTLS, der für zwischen geschaltete RDP-Gateways zum Einsatz kommt (die Bedeutung der verschiedenen RDP-Modi wie Enhanced Security und CredSSP erklärt übrigens der vorhergehende Artikel RDP: Was genau ist das und wieso ist das böse?). Doch auf vielen Systemen sieht das Ergebnis eher so aus:
| Security layer
| CredSSP (NLA): SUCCESS
| CredSSP with Early User Auth: SUCCESS
| Native RDP: SUCCESS
| RDSTLS: SUCCESS
| SSL: SUCCESS
| RDP Encryption level: High
| 40-bit RC4: SUCCESS
| 56-bit RC4: SUCCESS
| 128-bit RC4: SUCCESS
| FIPS 140-1: SUCCESS
|_ RDP Protocol Version: RDP 5.x, 6.x, 7.x, or 8.x server
also in anderen Worten: "anything goes". Dieser Server bietet nicht nur Enhanced Security mit NLA, die zwar bevorzugt wird, sondern auch die kaputte Standard RDP Security mit ihren nutzlosen Krypto-Verfahren, die dann zum Einsatz kommt, wenn der Client sie explizit anfordert. Was ein Angreifer natürlich genau so tun würde.
Problematisch ist übrigens auch die Zeile SSL: SUCCESS. RDPs Enhanced Security gestattet es nämlich nach wie vor, auf die vorgeschaltetete Network Level Authentication (NLA) zu verzichten und die klassische Anmeldung via Windows-Login lediglich mit einem TLS-Tunnel zu versehen (der dann die selber gebastelte RDP-Encryption von Microsoft ersetzt).
Mit FreeRDP auf Erkundungstour
Wer sich nicht auf die Ausgabe von nmap verlassen will, testet das explizit mit einem echten RDP-Zugriff. Bewährt hat sich dabei in meinen Tests der Linux-Client xfreerdp des Open Source Projekts FreeRDP (es gibt auch eine WIndows-Version, aber die habe ich nicht ausprobiert). Er unterstützt nicht nur alle möglichen RDP-Modi, sondern man kann auch auf der Kommandozeile genau festlegen, was man erlauben will. So kann man mit
xfreerdp /sec:rdp /v:<IP> /u:
eine Verbindung erzwingen, die die klassische RDP-Security nutzt. Windows präsentiert dabei dann den Login-Bildschirm; der fehlende Benutzername hinter dem /u: sorgt dafür, dass bei vielen Windows-Versionen eine Auswahl der verfügbaren RDP-Nutzer erscheint. (So habe ich auch die Screenshots der Windows-Anmelde-Seiten in dieser Serie gemacht).
Bei dem oben gescannten System 192.168.6.16, das auf Enhanced Security besteht, scheitert das dann mit einer Meldung zu "Protocol Security Negotiation Failure". Damit kann man sicher sein, dass die kaputte RDP Security wirklich nicht mehr zum Einsatz kommt. Den erwähnten Windows-Login-Screen mit Enhanced Security aber ohne NLA liefert die Option /sec:tls.
Cracking mit Hydra
Im Untergrund werden Tools wie RDP Brute gehandelt, mit denen man nicht nur gezielt nach RDP-Systemen suchen kann, sondern auch gleich komplette Wörterbücher mit potentiellen Passwörtern durchprobieren kann. Wer nur testen will, ob etwa die Anomalieerkennung des Intrusion Detection Systems bei einem solchen Wörterbuch-Angriff anspringt, kann das auch mit frei verfügbaren Tools machen.
Das vielversprechende Tool ncrack blieb jedoch in unseren Tests ohne Ausgabe hängen (vermutlich weil die NLA-Unterstützung fehlte). Doch das Tool Hydra der Hacker-Gruppe THC (Hacker im klassischen Sinne – also kreative Technik-Nerds) funktionierte ab Version 9.0 und lieferte mit
hydra -l jutest -P testpw.txt rdp://192.168.6.16
recht flott das Ergebnis
[3389][rdp] login: jutest password: test123
Und wer ganz genau wissen will, was es mit den im 2. Teil mehrfach erwähnten Downgrade-Angriffen auf sich hat: Das Python-Tool Seth von Adrian Vollmer bringt sich via ARP-Spoofing selbst in eine Man-in-the-Middle-Position zwischen RDP-Client und -Server und handelt die Verbindungssicherheit herunter um schlussendlich Klartext-Passwörter auszuspucken.
Bitte benutzen Sie diese Tools und insbesondere Hydra und Seth nur gegen eigene Systeme beziehungsweise mit explizitem Einverständnis des Eigentümers. Der Einsatz gegen fremde Server wäre ziemlich sicher strafbar, da es einen Versuch darstellt, Zugangsbeschränkungen zu umgehen (§202 Stgb).
Damit Sie nicht selbst Opfer der mit diesen Tools gefundenen Probleme werden, liefert der letzte Teil des Artikels Best Practices zum Einsatz von RDP. Darüber hinaus bereitet der Autor der Serie, Jürgen Schmidt, den kompletten Inhalt auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen.
(ju)
