 Hi. Yeah, it's good to be back. Nowadays, virtual private network becomes more and more prevalent. For enterprise, SSL VPN is the most convenient way for their employees to connect the cooperation network. For hackers, it's also the shortest path to compromise your intranet. So today, let's take a look at how your SSL VPN could be wrong. Oh, before that, is there any NSA here? Okay, sorry for the title. Hi, I'm Orange. We are from Devcore Research Team in Taiwan. And now we're a zero day researcher and focusing on web and application security. Apart from that, I'm also a speaker, CTF player, and a bug bounty hunter. Hello everyone, I'm Mei Zhang. I'm a security researcher from Devcore. And I play CTF in Hiccown and 217 CTF team. I mainly focus on binary exploitation. Here is the highlight today. We will discuss pre-orth-remocal execution on both Fortinet and Pro-Secure SSL VPN. In the Fortinet case, we will show you the hard core, the reliable binary exploitation with the magic string to open the door. In the Pro-Secure, we will present the out-of-box web hacking and how we bypass the two, uh, bypass the two factor authentication on Twitter and hack into their most important server. Last but not least, we will introduce how we leverage a hidden feature to take over not only your SSL VPN, but also all of your clients. And this is the agenda. We first introduce the SSL VPN and why we focus on that. Most of the SSL VPN don't provide a shell. We will elaborate how we jailbreak the appliance and introduce the attack vectors to discover bugs. Of course, we will have case studies and demonstration. And the last is the SSL VPN weaponization and recommendations. So, what is SSL VPN? Compared to the side to side VPN such as the IPsec or PPP, SSL VPN is more of use and compatible with any network environments. All you need is just a browser. Because of the convenience, SSL VPN becomes the most popular remote access way for enterprise. SSL VPN are everywhere and protect cooperation access from internet exposure. They are trust to be secure and consider as the only way to your private network. But what if your trusted SSL VPN are insecure? They will become your virtual public network. Yes, public. So that's why we focus on SSL VPN. They are important, but a blind spot. They are widely used by corporations of all size, but only few vendor dominate the market. According to our survey on Fortune 500, the top three SSL VPN vendors dominate about 75% market share. So if you find a high impact vulnerability on one of the leading SSL VPN, you can hack the planet. The most important is SSL VPN must be exposed to outside. So it must have direct internet access. Due to its importance, even an SA is hunting for SSL VPN bugs, such as the Equation Group leaks. SSL VPN is charged by large corporations, industry leaders, and tech giants, such as the Facebook, Twitter, and Marvel. Yeah, the logo is very cool. Even an SA uses the SSL VPN. They are everywhere, and they are everywhere but usually forgotten. Sometimes even hacker knows your SSL VPN more. For example, we discussed a previous remote execution on Palo Alto SSL VPN one month ago. We find a bug accidentally. However, while reproducing on the latest version, we failed. So we start to doubt if this is a known vulnerability. We search all over the internet but could not find anything related. There's no CVE, advisory, or any official announcement. Therefore, we believe this is a silent fix one day. We surveyed all over the world and find Uber suffered from this. So we report to their bug bounty program. This is not a fault on Uber. They are also the victim. We also report this to the Palo Alto P-3rd, but we got a following reply. They do not CVE items find internally. So that's the reason why there is no official advisory. Okay, this is fine. There is no CVE, so there is no vulnerability. Anyway, Palo Alto still assign a CVE for that. Just right after we publish all the story. Once we decide to research into SSL VPN, the next question is how to choose the targets. We did a little survey on leading SSL VPN. As you can see, even in the high civility label CVE, the Perl Secure and Fortinet are still the most secure one. We want to challenge you the mission impossible. So we put our priority on Perl Secure and Fortinet more. Perl Secure is the most famous VPN solution in the world and has the latest high label CVE. It's trusted by large corporations, service providers, and government departments. Fortinet is more used by end users, medium sized enterprise. It's common in Asia and Europe. Both vendors have little high label CVEs, so our mission is to find the most remote execution on them. So let's start hacking. To kick-start new research is always not easy. SSL VPN is a black box and closing source appliance. They usually build their own architecture stack from scratch and don't provide a shell to dive into. So the jail break is the essential step for researchers to turn the black box into the gray box. As you can see, most of the SSL VPN only provide a restricted shell. So let's talk about how to jail break then. We are not hardware guys, so we start researching from the virtual appliance. All the virtual appliance can be classified into the typical one and the encrypted one. It's trivial for typical one, so we don't pay a lot of time here. You can just enter the single user mode or mount the virtual disk on your box to modify the file since turn to get a shell. But what if the disk has been encrypted? Without the booting process, we cannot see anything. So today we will show you a trick to bypass the encryption. Here is the linear booting process. The common way in the past to break the encryption is to analyze or reverse the VM linear kernel to get the encryption key. However, we focus on another stage. Here we give an example to show how memory forensics takes us to the wing. As we know the booting process, it starts from the BIOS, the loader, and the kernel to drop the first process to initialize the operating system. In Procure, the initial process shows you a prompt. Press enter to view or update your appliance settings. And once we press the enter, the initial process spawns another process to allow you modify and view the settings. So we suspend the virtual machine at this time and scan the entire memory to do the memory forensics on the host OS. From the memory forensics, we observe that the spawned process is a Perl script, the name is dsconfig.pl. And since it can be the weak point of hold the booting process, so it's time to show the magic. We will just patch a few bytes to pop out the shell. We patch the memory and replace the dsconfig.pl to the bing.sh. Once the modification is done, the only thing we need is just press the enter. And we got the shell. Now, thank you. So now we have the full control of the system and can do further debugging and analyzing. Okay, so now we can start hacking SSO VPNs. But where's the bug? There are many demons running on the server. They're usually complicated and hard to analyze. Digging at the correct place is important for us. So we propose some attack vectors specific for SSO VPNs. We'll talk about a special feature called WebVPN. It's powerful but also vulnerable sometimes. We got lots of bounty from this feature. It's like our slot machine. The next one is the native script language extensions on SSO VPNs and how they can be dangerous. And we also introduce some multi-layered architectural problems. WebVPN is a convenient proxy feature. It's portable and clientless. It proxies all kinds of traffic through the web browser. It's supports various protocols like HTTP, FTP and RDP. It also handles many web resources such as WebSocket, JavaScript and Flash. We don't need to install any software. Only click on the browser and we can connect to other services. Sounds powerful, right? Apparently it's not easy to implement this feature. Some vendors choose to implement by themselves. However, protocols and web resources handling are prone to memory bugs. Think about SSO VPN processing SMB or Flash. You know how hard it could be. Also, this requires high security awareness. For example, we found some debug functions and sensitive data without encryption and information exposed carelessly. Some vendors decided not to reinvent the wheel. They modified from an open source project directly. But they copied the code and also copied the box. This kind of software are hard to maintain, update or patch. Or some vendors choose to co-existing libraries. But the vendors are often neglect to update these libraries. We found Live Curl and Live XML from over 10 years ago. Implementing WebVPN is really not easy. This is the most serious attack vector we found under SSO VPNs. During our research, we found that most SSO VPNs have their own native script language extensions. Like PHP extensions returning C or Pro extensions returning C++. Vendors like to use these extensions to do encoding, decoding or other operations to improve efficiency. Which may be vulnerable. And it's really prone to type confusion between different languages. As we know, string operation is always difficult for C. Like buffer size calculation, dangerous functions such as string copy or misunderstood functions. For example, do you really know how the return value of SM print F should be? Can it exceed the buffer size? Actually it's possible. So calculation like this will cause an integer overflow. The type of these extensions are also confusing. Although it seems the same. But do you really know what type it is? Do you know if you are using it safely? Who knows? And this may cause serious problems. The last one is the multilayer architecture problems. When there are different standards for processing the same thing, the inconsistency between them will lead to problems. Such as the attack surface on reverse proxy and Java web back end. The talk from Orange in DEF CON last year. And here we gave another case. This is also an SS control bypass. It's on C web server and RESTful back end. The regular expression dot plus matches too much. So we can leverage this to match the dot dot slash to assess the privileged pages. Okay, so here is the special attack vectors we found on the SSO VPNs. Following, we are going to talk about two case studies. We will show how we get the pre-orced remote code execution on Frosigate and Post Secure. Here is the disclaimer. All the CVS mentioned below have been reported and patched by Frosignet, Post Secure and Twitter. So please go update your SSO VPNs as soon as possible. The case one is Frosigate. We first show break the Frosigate and look into the binaries. We try to list the binaries in slash bin and we found there are all symbolic links point to the slash bin in need just like this snapshot. Frosigate compiles all the programs and configurations into one single binary. This makes the in need program really huge and annoying. The IDV file of in need is up to 500 megabytes with 85,000 functions and they are all stripped, no single. It contains plenty of function tables to manage each program, including the WebDemon. Throughout the investigation, we found the web service is modified from a patch, but it's a patch from 2002. So the web server running on your SSO VPN is actually as old as your grandmother. Compared to the admin page, the user login interface is the only one that definitely exposed to the internet. It looks like this. A simple login page, no other buttons or functions. So we're gonna exploit through this interface without authentication. We will talk about three bugs today. First is the pre-auth removal execution chain. We combine two bugs. A pre-auth arbitrary file reading to log in and a post of heap overflow to get a shell. We also introduce an interesting bug, the magic backdoor, which can modify any user's password with a magic key. Let's start with the file reading part. It was a function used to show corresponding language for users. It concatenates strings directly without a dot dot slash filter, but adjacent extension appended automatically. So it seems like we can only read adjacent files. Think about it. Can we remove the adjacent and read any file we want? The answer is yes. We can utilize the feature of S1 print F. According to the main page, it writes at most size minus one. The buffer size is fixed here so we only need to make it exceed the buffer size, like this. We fill it up with slashes. So the path after S1 print F becomes like this. The pending JSON exceeds the buffer size and is stripped by the S1 print F. Then we can read however we want. After getting our virtual file reading, we found something interesting. We call it an SSL VPN mystery. It appears in many products, not only for the gate, but for secure or other vendors. The mystery is they hold an excessively detailed session file on the SSL VPN. The file is called SSL VPN with session. What's the content? Session token? Of course. IP address? Sure. Here's a name indeed. Plantex password. Are you kidding? You should never store any Plantex password. We really wonder how this become popular. Let me guess. Maybe they learned it from Google or Facebook or Twitter. Who knows just kidding. Anyway, these Plantex passwords are really convenient. We don't need to crack password anymore and we can log in easily. Today we're going to utilize the WebVPN feature. As you can see, it supports many protocols. Let's try the HTTP. We only need to type URL and we can connect to the website through WebVPN. And we look at the URL. We can see that we're still connecting to the SSL VPN. So it practices the whole website for us. And if we look into the elements, we can find the URL of resources are also from SSL VPN. It rewrites all the URLs for us. As you can imagine, this involves in heavy string operation. So here is the heap overflow. It occurs in JavaScript parsing and it's simply because they could flinch check while memory copy. The buffer is only 0x2000 but the input string is unlimited. Generally, we do some heap feng shui to overflow a nice target and control the program counter and do code execution. But the situation is difficult in Fridgate. We face something destabilizing. First of all, the WebDemon handles connections with Epo, so it's a single thread process. And the main process and libraries use the same heap. It means all the memory allocations of all the operations in all the connections are the same heap. So the heap is really unstable. Moreover, there are some operations regularly triggered. They interfere the heap arrangement and it's uncontrollable. Therefore, we cannot arrange the heap allocation carefully. That would just make a mess. And there is something even more ironic. A patch implements an additional memory management. So there's no free until the connection ends. We cannot arrange the heap in a single connection. The allocator also limits our exploit. It's called Jemilock. It centralizes more objects. It calls a block of allocating memory origin and then maintains these regions in a round with a bitmap. This effectively reduces interference between small and large objects. It also limits our target options. It's hard to put small objects nearby our buffer. So we're stuck at that time and therefore we started to fuzz the server and it crashed. And we almost controlled the program counter. And yet this is why we love fuzzing. We crushed a function table pointer in an SSL structure. This structure stores information of each connection. It's used for connection handling and is an ideal target for our heap exploit. First, every new connection allocates an SSL structure. So we can trigger it easily. And its size is close to our JavaScript buffer. And therefore it can be placed nearby our buffer with a regular offset. The most important is it has some useful structure members. It contains a function table pointer called method. And this is how we triggered the crash. But we found one even better. It's a function pointer called handshake function. With this, the exploit can be much easier. We don't need a whole function table anymore. We only need a function address. All the connections are on the same heap. So we can mess up connections and overflow the SSL structure. So we send lots of normal requests and attack the server with an overflow request in the meantime. If we look into the heap, there may be several SSL structures on the heap. For example, here are three SSL structures for three connections. And the SSL structure is like this. Some basic information and the function table. And the function pointer is now pointing to an SSL function, SSL accept. Now if we trigger the JavaScript parsing. And the JavaScript buffer is allocated ahead of these SSL structures. Then we can trigger the overflow and override the SSL structure members like this. So now we fill up the SSL structure with capital A's and make the program crashes. What we need to do next is clear. We only need to forge the SSL structure with a fake function pointer like the address of system. So when the victim connection is trying to do handshake, the program executes whatever we want. Anyway, the heap is unstable. So we need to send fuzzy connections to meet the condition. The server may crash sometimes, but it's fine. Furgate has a reliable watch dog. We just need several attempts taking about one to two minutes to get a shell. So this is the whole details of how we achieve remote execution. Maybe some of you are not binary guys, so you may wonder, is there any other way to get into the server? So why not find another door to make your life easier? We found a magic backdoor in the login page. This function was originally used to update outdated password. However, they failed to authenticate. So we can simply use this secret key which is called magic to reset any user's password. Now we're going to demonstrate how we pop a root shell from the only exposed HTTP export. We put our PHP exploit on an HTTP server and this is our export. In order to control the perimeter of system, we first do a stack pivot and make our buffer become the stack. After that, we do an RLP chain to call system. And here is the reverse shell command. We use Python to build a reverse shell. And we concatenate these strings to overflow the SSL structure. Now we can start hacking. In the first panel, we open a port to receive the reverse shell. And we start a filing thread to build multiple normal connections. Then we attack the server. We first try to leak username and 10 hex password from the web session. As you can see, we found an username, main. And password, this is password for main. We can use this account to log in and make the SSL VPN proxy or PHP export. We only need to wait a few seconds. Okay, here we got the root shell. Thank you very much. The next class we talk about is Perl secure. Perl secure is the market leader of SSL VPN and was formed a diverse teacher of Juniper networks. They are a pro lover and built all the architecture stack from scratch. The architecture is old but stable and secure. And it's worth to mention, Perl secure hooks all the process by LD preload due to the due to the monitor and security consideration. We will discuss this later. Here is the vulnerabilities we find. Among them we will introduce the pre-auth arbitrary file reading and the post-auth command injection. We change these two bugs into the pre-auth remote call execution. The first bug is the pre-auth file reading. Perl secure introduce a new feature called HTML file access since version add .2. It can access the tail net SSH and remote desktop by browsers. In order to adapt the new feature, Perl secure create a new if condition to handle all static resources. Thanks to the new feature, the original strict validation has been bypassed. So, and not effect by this, all unpatched version except the end of live version are affected. Here is the payload for you to check your SSL VPN. When there is a special pass in the end of the URL, the pass validation become loose. And what can we get from this? We can get numbers used for information such as the server private key to decrypt the SSL connection. We can also get information, we can also get important configurations such as the radius and all of that password. And all users password hash and sensitive cookies which are cached in the web VPN like Google, Dropbox and iCloud. The last and the most important is the cached plain text password. Yes, plain text again. For now we get a credential so we are able to access the corporation network easily. However, our goal is to get call execution for persistent and further actions. So here we change a command injection in management in the face together. From this call fragment, it's very obvious and straightforward. If we can control the options, we can inject arbitrary command to this Perl function. And of course we can. We can control the options from the troubleshooting patch. So is that simple? No, I don't think so. In order to avoid potential vulnerabilities, Perl secure applied a lot of hardening on their products. Such as the system integrity check and the rate only files instant to protect the back door from, to protect from back doors in Chrome tab or web load. The most effective hardening is the DSSF module. It's like the safeguard to protect Perl from dangerous operations. The DSSF is the Perl module which is written in C++. The module implements its own command parser and hooks several dangerous functions, such as the since turn, open, and back stick. It also disallows numbers, bad characters, and we implement the Linux IO redirection in Perl. So due to the hardening, we cannot perform any command injection. We try several ways to bypass the hardening. Of course the first count out of my mind is the argument injection. However, the TCP dump in Perl secure is too old. So we failed because it didn't suppose several juicy features, such as the post-rotate command. While examining the since turn, we find Perl secure stole the template cache in a directory. We try to write into this directory. But we can't use standard out because it's already directed to the neural device. What we can do is only abusing the saved file argument. But it seems there is no way to generate a polygraph file in both Perl and pcap format. So it's time to dig deeper. We dive into the DSSF implementation to see is there anything we can leverage. We found a flaw in the command parser. When there's an incomplete IO redirection, the rest of the IO part will be truncated. However, also we can re-control the standard out. We still can't find any way to generate a valid Perl. So let's think out of the box. Standard out is uncontrollable. But could we write a script by a standard error? When you force the TCP dump to open an non-existent file, it will show the error, no such file or directory. From the error, it seems we can partial control the message. We try to pipe the standard error to Perl. But we still get nothing. However, when we try to use another file name, such as the print 123 with a hashtag, we try to pipe the standard error to Perl again. And the magic happens. The Perl print out the 123 without errors. So, okay, the Perl 101. Perl suppose the go to label. So the TCP dump with a column becomes a label in Perl. And we use the hashtag to comment the rest of the part. So the standard error becomes a valid Perl now. This is our final expiry. We will explain the payload one by one. The first is to make the TCP dump open an non-existent file. The file name will be part of the error message in standard error. And then we redirect the standard error into the cache directory. Here we name the file as set cookie dot tht n error dot ttc. The last is the incomplete IEL symbol. This symbol abuse the command parser to ignore the rest of the IEL redirection. Once our standard error has been written into the cache directory, we can just fetch the corresponding patch to execute our command. By training these two vulnerabilities, we can get a reliable pre-off remote call execution. We have a report of our finding to Perl secure p cert. And this is the response from them. They fix all the bugs we seen amongst. Their reaction is very quick and professional. It's a great time to work with Perl secure. They are such a really responsible vendor. After Perl secure release all the patches, we kept monitoring the internet to see the large corporations response time. Twitter is one of them. They are known for their bug bounty program and nice to hackers. However, it's not good to exploit a one day right after the patch released. So we wait 30 days for Twitter to upgrade their SSO VPN. This is the Twitter SSO VPN. It's just a simple looking patch. From the reconnaissance, we know the last time Twitter upgrade is in last December. So Twitter is likely vulnerable. We have verified the bug and got a bunch of user credentials in plain text. However, we encounter some problems while trying to pop out a shell from Twitter. Yes, the first problem is the two-fact authentication. Due to the two-fact authentication, also we can get the plain text password. We still can't do anything. So the first thing we need is to find a way to bypass that. We observe Twitter enable the roaming session. Longing session is a feature to enhance the mobility. It allows a session from multiple IP locations. So once we know that, we download the database and for the session to bypass the two-factor authentication. And finally, we log into their system. The next problem is the SS control in management interface. As we mentioned before, we have a command injection here. However, for security consideration, most of the corporation disable this interface on public. So we need to find another way to access the interface. We leverage the web VPN feature again to connect to itself. It's just like the SSRF. We use the zero to bypass the SSRF protection and access the management interface. And finally, we got there. However, the last problem is that we don't find any manager's plain text password in cache. Practically, most of the manager only log into their system at the first time. The only thing we have is the password hash in sorted and if I creep and shot 256 format. So, we launch a 70 core AWS to crack the hash. And see hours later. We crack the hash and successfully log into their management interface. We are lucky because the length of the password is only 10. And the first character is capital B. It's a very early stage of our quaking queue. We exploit our command injection and try to run the command ifconfig. And we got a shell. We report all of our findings. Thank you. We report all of our findings to their bug bounty program. And got the highest bounty from Twitter. Also, we cannot prove that. It seems this is the first remote call execution on Twitter. Okay, the last is the bonus for you. Our company Devcore provides the most professional rating service in Asia. So, let's talk about how to make the rating more read. In a rating operation, the personal computer is more valuable. So, in order to take control of all the clients, we need to weaponize the SSL VPN. There are several old school methods before, such as the waterhole attack and repress the VPN installer. But here we propose a new method. It's the logon script. Logon script is the feature in almost every SSL VPN. It can ask you to corresponding script to mount the network file since turn or change the routing table. So, here we will show you a demo to show you that how we compromise all the VPN clients. Okay, this is our demonstration. As you can see, the exploit need one argument. So, we append our target right after the exploit. Here we got a username and hash of admin. Also, we could not find the plain text password. We can still change our cookie to the session ID of admin. Okay, once our modification is done, we can access the management in the fast. And we have become the admin. Thank you. Here we leverage the feature on the user roles and the VPN tunneling. We find the logon script section. Here you can see the logon script supports not only Windows but also Linus and Mac OS. So, we use the calculator as our backdoor. And once our modification is done, we change to the laptop of our victim. Yeah, it's cute. The victim launched a per-skill agent. And try to connect to the SSL VPN with his username and password. And once the connection has been established, the calculator will be popped automatically. Okay, here we finish all of our slides. But how to mitigate such attacks? Here we give several recommendations. The first is to, is the client science certificate. We saw the certificate, the malicious connection will be dropped during SSL negotiation. The next is to enable multi-factor authentication. It can decrease number of attack surface. And the last, remember to enable full log audit and subscribe to vendor's advisory to keep your system updated. This is the end of our presentation. And here is our contact information. We will, okay. Okay. We will post all the detail right after our talks. So please check that and let us know if you have any further questions. Thank you for being here again. Thanks.