RDP hijacking
Det är inte ovanligt att man stöter på terminalservrar som nyttjar Remote Desktop Protocol för att upprätta anslutningar. Medan en sådan uppsättning i grund och botten inte är osäkrare än alternativa lösningar (givet att terminalservern är korrekt konfigurerad och härdad) så finns en del unika problem som kommer med just RDP.
I dagens blogg tänkte jag skriva om just ett sådant problem. RDP hijacking är en metod som kan brukas av en angripare med SYSTEM-behörigheter för att kapa sessioner tillhörande andra användare utan krav på kännedom av lösenord eller annan information. Då detta är en attack som varit känd länge men än idag går att utnyttja så dras slutsatsen att Microsoft inte betraktar detta som en bug utan en funktion.
RDP hijacking i praktiken
Innan vi går in på hur attacken utförs så tänkte jag först skriva om vad vi får ut av angreppet. Vi är trots allt redan SYSTEM (motsvarande root på ett *nix-system) och borde redan ha åtkomst till samtliga användares data. Vad mer kan vi önska?
Kort och gott kan de praktiska fördelarna med RDP hijacking kontra att utföra angrepp från SYSTEM-kontot summeras på två punkter: tredjepartsapplikationer och OPSEC
Vad gäller tredjepartsapplikationer så får vi tänka oss in i ett scenario där terminalservern används för att komma åt en applikation som antingen är installerat lokalt eller nås via terminalservern. Trots SYSTEM-behörigheter så är åtkomst till tredjepartsapplikationen inte garanterad, men om vi kan kapa en session där användaren redan loggat in så har vi en väg in till applikationen.
För perspektivet OPSEC så flyttar vi fokus från åtkoms till data till att förbli oupptäckta. Detta är främst relevant för red team-övningar eller statsaktörer som vill undgå det säkerhetsoperativa centrets fokus. SYSTEM och andra konton med höga behörigheter är ofta under strikt övervakning och operationer så som exekvering av okända skript eller tillägg av schemalagda uppgifter lyser upp som en falukorv i en julgran i det säkerhetsoperativa centrets dashboards. Istället vill vi hålla fortsatta angrepp till konton där de lättare smälter in i bakgrunden.
Steg-för-steg
RDP hijacking är väldigt simpelt i sitt utförande men som ni kanske redan förstått från texten så länge så är metoden i högsta grad att betrakta som s.k. post-exploitation. Det vill säga att angriparen redan etablerat ett fotfäste på servern och eskalerat sina behörigheter till SYSTEM. Lättare sagt än gjort, däremot är det inget jag kommer gå igenom i den här bloggen.
Om alla parametrar bemöts så kan vi utföra RDP hijacking med tre enkla kommandon i Windows terminal CMD.
Query user – Med det här kommandot får vi fram en lista över sessioner. Notera att kommandot listar aktiva sessioner och sessioner markerade som ”disconnected”. Mer om dessa senare.
sc.exe create getdesktop binpath= “cmd.exe /c tscon 5 /dest:console” – Vi använder verktyget sc för att skapa en tjänst som startar en session med tscon under en annan användares ID (ID är i detta fall 5 och noteras i delen /c tscon 5). Som först noterat under 2017[1] så kräver tscon inget lösenord för att ta över en annan användares session. Detta kan ställas i jämförelse med det grafiska gränssnittet som kräver användarens lösenord, oavsett om du är SYSTEM eller annan högprivilegierad användare.
net start getdesktop – Vi startar tjänsten vi tidigare skapade. Om allt gått rätt så kommer vi efter ett kort avbrott vara inloggade som användaren med ID 5.
Kort om disconnected-sessioner
En intressant abrovink för det här angreppet är att den även funkar för sessioner markerade som disconnected. Typiskt sett uppstår detta läge när en användare avbryter en RDP session genom att klicka på X:et istället för att aktivt logga ut. Sessionen är således pausad och kan återaktiveras av en angripare med SYSTEM-behörigheter.
Åtgärder
Eftersom angreppet fortfarande befinner sig i gränslandet vad gäller funktion kontra bug (och har varit sedan 2017) så bör vi inte sätta för höga förhoppningar på att detta åtgärdas i en framtida patch. Allt hopp är däremot inte förlorat och vi kan fortfarande vidta åtgärder för att göra det svårare för en angripare att utföra angreppet. Förutom att nämna det självklara att strikt övervaka aktivitet från SYSTEM och andra konton med höga behörigheter så kan terminalservrar konfigureras med gruppolicyer som automatiskt loggar ut avbrutna sessioner[2]. Vi kan även försöka begränsa exponeringen av terminalservern. Terminalservrar bör i första hand inte exponeras mot internet, men om vi inte har det alternativet så bör de skyddas med multi-faktorautentisering av något slag.
För att summera:
- Övervaka och larmsätt aktivitet från SYSTEM och andra högprivilegierade konton som inte bör ha någon aktivitet.
- Konfigurera terminalservern sådant att avbrutna sessioner avslutas.
- Begränsa exponeringen av terminalservern. Undvik exponering mot internet om möjligt, om det inte är möjligt- Applicera MFA på terminalservern.
[1]www.korznikov.com/2017/03/0-day-or-feature-privilege-escalation.html
[2] https://tecadmin.net/windows-logoff-disconnected-sessions