BG - Unveiling the Hidden: Discovering RDP Vulnerabilities using PDF Files

uh good afternoon welcome to bsides Las Vegas uh this talk is discovering RDP vulnerabilities by reading PDFs presented by door Dolly uh we'd like to thank our sponsors especially our Diamond sponsor Adobe uh as well as our gold sponsors bluecat Sim grip conductor 1 uh it's uh with their support that we're able to do this event along with other sponsors and donors um a reminder that cell phones are distracting uh these talks are being streamed live uh if you have as a courtesy please put your cell phones on and Silent uh even the vibrate is really annoying uh YouTube can hear them uh if you have questions at the end there'll be time uh there's a mic right

there behind the projector and feel free to come up and use that thank you very much all right so um welcome to my talk uh the talk is going to be on villing theen discovering RDP vulnerabilities using PDF files now I know it might start S very interesting what is the connection between RDP and PDF files and this is what we're going to talk about so first let me let me introduce myself so my name is D do I'm the head of security research at siolo um I have some experience in the appac and the infrastructural security um W over 10 years in the cyber security field pretty much vest background from all different aspects and now I'm the lead I'm the

head of security research at SEO now what we do in SEO pretty simple secure access we help companies to secure their their high-risk access between their clients and the Target computers and servers and this is what we also research we focus our research on remote access applications and remote access protocols now I do have a question for the audience before we start how many of you when you do some security research just read read a big PDF file from A to Z and just by that manage to find five different cves in a high used protocol because this is what I did and when I talk about highly used protocol I talk about something that we are all familiar

with which is RDP so if you are not familiar with RDP this is the the windows uh the dialogue that you most likely seen in your when you use your computer and you use it in order to connect to a Target server so if you want to have some access to a remote server you just use this uh dialogue and you connect to a Target server that you want now RTP has been researched for quite a while but it has all different aspects and this is a pretty big protocol now one part of this protocol is something that is called RDP Gateway now what is the RDP Gateway RDP Gateway is a role in Windows server that allows

you to have some kind of RDP proxy that you can install in your DMZ so this is a server role and it allows you to create an RDP tunnel between a client that is is outside in the wide internet to a server which is inside your on Prem environment and this works by creating a TLS tunnel between the client and the RP Gateway and then the RP Gateway connects to the Target computer so it's very important to remember those uh names the RDP Gateway and the target server because those are the stuff that I will use throughout the presentation so now that we know what is RDP Gateway we need to think of a research methodology how

we can research this thing that is called RP Gateway so I decided to take this quite a unique uh methodology for the research I decided not to use jedra not to use Ida not to use wyb and of course not to use the crowd favorite C I just decided to read a manual this is what I did just read the manual from A to Z and understood how it works so when we talk about the manual we also used a little a little bit more stuff for the research we used some previous research and there was a little bit amount of research on the RDP Gateway um so we use that we used some protocol analysis

tools with the one that's most famous is wire shark just to understand how exactly the protocol looks like we did use a lot some open source implementations now RDP is a closed protocol right it's be it's built by Microsoft and it's pretty closed but there are all different open source implementations for this protocol such as free RDP is the most known one but the one thing that we used the most was protocol specs now if you're not familiar with protocol specs so actually Microsoft releases on their website a list of 1,000 protocols a p list of PDFs for one over 1,000 protocols that they are using in their systems and one of them is the RDP protocol so all the

information about how to implement and how to use the RDP is over there on that their website so also one of the protocol specs is the RDP Gateway protocol spec which is called msts guu which means terminal Services Gateway server protocol so that's what we did we just read this protocol and this is a small glimpse for what this protocol looks like and how it works so first of all we do see that the connection starts with an HTTP connection so in order to create a TLS tunnel between the client and the RDP Gateway we start by creating an HTTP a TLS connection between the two now after we created the TLs connection we have some version and capability

negotiation in order to tell the RDP Gateway what we support and what we don't and by the end of it we get two things we get a tunnel and a channel now in order to understand what are tunnels and channels it's pretty simple I'll use some I'll use some analogy um so the tunnel is like the road that you have and the channel is like the Lanes on the road that you have so that means that you get one tunnel and you can get more than one channel on that tunnel why do you get more than one one more than one channel you'll have to bear with me for the end of the presentation to

understand that because this is very important not for the first vulnerability but to the second one so this is how it works now we need to find our first culprate right we need to find our first vulnerability that's what we are here for right we are all looking for vulnerabilities so we looked at the PDF file and we did notice a very nice pattern each and every time that the RDP Gateway sends a message to the client that connects to the RDP Gateway it it explicitly says that the message need to be null terminated each and every time they say they specifically says null character but there were two different instances where they didn't say it they

actually said just to send a message with no null character so we did it we as we said we are following the manual right we are just reading the manual and we are following what Microsoft told us to do so we sent those two messages with no long termination and we actually noticed that the client kept on crashing pretty interesting just by following the manual I can get an RP client to crash that doesn't make sense of course but that's what that's what happened now I'll talk a little bit about what are those messages so the consent message is a message that shows up once you connect to the RDP Gateway it allows you to to

accept the for example and the service message allows an admin to send for example to tell everyone hey this server is going to be shut down in a couple minutes so those are the stuff and let's see it live right now so as we can see on the left side on the screen we started in RP Gateway and here we are connecting to a server using the RP Gateway so we got connected to a local server on the Target on the place where we are running the server and now we sent a server message with an Al termination and now we're going to send a message with no n termination and we see that it

crashed I mean I just followed the manual I didn't do anything crazy up until now so I know that I promised that we didn't use any of the big guns like wind dbg or JRA and all that stuff but when I saw it I was like I must check what's going on here so I looked into the stock trace and I actually saw that there are some problems with the hip now because because this was pretty easy to do first of all I decided okay I need to report it to Microsoft before I try even to exploit it I first need to report it to Microsoft before someone else will find it because I mean that was very

easy so I did send it to Microsoft and while I was sending it to Microsoft I tried to try to exploit it but before I even got to do it Microsoft told me that I got an rce on RDP client I mean pretty simple pretty simple and pretty insane okay so that was pretty nice I actually then later try to understand what was going on what was going on there and actually there is a one an off by one vulnerability in the hip that kind of like messes up with the hip headers and stuff um that's the story and it's actually explodable and can you can actually get an rce by sending this message so that was nice

right but that wasn't enough for me I wanted something cooler I wanted to find something even bigger just by reading the manual I mean I just read the manual and I and I got an rce I can probably find some some more stuff there so that's what I did so remember that I told you about the lanes and the road so one reason that they allow you to have multiple channels on the same tunnel is to support UDP now as we can as we probably all know um UDP is a lot a lot more faster and allows you to create to have better performance connection so what Microsoft allows you to do with the RDP Gateway is to create a secondary

Channel which is a UDP channel so by the end of creating the main Channel which is the TCP Channel you get something which is called a cookie now this cookie is the one the only authentication mechanism that you are using to authenticate to the ud to the UDP socket of the RDP Gateway so all you get so you get a cookie and you just send it back over the UDP socket and once it verify the cookie you got authenticated so I was like cool what is this cookie contained right so let's let understand what it contains so the manual told us this is signed and encoded bite blob that contains a a struct called authen

cookie data um and the struct contains a lot of very interesting stuff first of all it contains the username it contains the scheme which we are using which is UDP it contains the expiry time the server AP that we want to connect to the server name and the port that we want to connect to so this mean that we have a lane which we can actually control and divert to a different tunnel to a different road so if only we can manage to understand how we can forge this cookie so that's what we tried to do so we looked at the B stream now they didn't tell us how it's signed or how it's encoded but once I looked at the

bite stream I noticed a I noticed a a pattern that was very familiar to me I noticed that the two first bites were 0 x30 and 0x82 in HEX now if you have ever played with certificates and P pkcs so I noticed that this is an ASM sequence now it it's also very easy to understand if you convert it to Bas 64 and you see that it starts with Mii which might sound a little bit more familiar to to the audience and then when once I understood that this is an asn1 I needed to understand whate what exactly type of encoding it was and this was something called CMS cryptographic messaging syntax now what is cryptographic

messaging syntax it's pretty simple to understand essentially you send the data the sign data along with the signature and the public key of the private key that used to sign the data so this mean that anyone who gets this bite that contains the data and the signed the signature and the public key can actually verify that the sign data wasn't tempered with right so what do we do if we want to try to check if Microsoft worked correctly here we just take if we do something very simple we take the we create a self certificate and actually put our own public key that was that was signed using our self sign certificate in that bite and sign it with our own self sign

certificate and that actually worked we actually managed to get an authentication bypass now what it gives us first of all we get Event Viewer log forgery second of all we get the full ssrf from the RDP Gateway into your internal Network and all of that over UDP protocols such as dhtp SNMP DNS C whatever UDP protocol you can think of we can get an ssrf into it the third thing is network denal of service because this is a UDP what Microsoft decided to do in order to work correctly in order for that to be more reliable I would say for each time that you are connecting they are sending three packets over the network to make sure

that at least one of the packets will get there so by sending one packet I get an amplification of three times pretty pretty cool and all of that have been vulnerable since Windows 2008 which is pretty insane now let's see it live so as you can see on the left screen um I'm send I'm creating a cookie with all the data I'm IFD researcher and I'm trying to connect to besides LV server now of course and all of that in Port 5 514 which is a c log port and I'm connecting to a broadcast address now what happens is that I'm sending three broadcast messages in CIS log in the network with some data which means that

I'm going to spam all the CIS loog servers in your network and here you can see how I created a simple Event Viewer log which can which can uh make all the scam people in your organization go wild to understand what the [ __ ] is besides LV and who who is who is if the researcher so that was pretty [Applause] nice so overall during the This research just by reading the manual I managed to find four four different cves we had the rce that we talked about we had the authentication bypass that we talked about we had another CV which was actually the fact that they were using an old version of TLS they actually used

a TLS 1.1 over UDP in in their system and there is one last cve that we cannot yet disclose because they haven't fixed it yet and if you ask me what should be your key takeaways from this presentation first of all the fact that widely used protocols such an RDP such as RDP still have many vulnerabilities in them and you need to be aware of that second of all closed Source isn't necessarily closed I mean we have the manual we can use it and just find vulnerabilities with it right third thing read the manual I mean please if you're a researcher just read the manual before you try to open all those crazy tools and all the reverse engineering

tools and if you're not researcher and you're just a Defender read the manual as well to understand where could be the problems in your system and the last thing patch your software because those vulnerabilities have been ex existed since Windows Server 2008 thank you very [Applause] much [Applause]

all right if anyone's got any questions feel free to come up and use this

mic

all right thank

you