WEBVTT 00:14.060 --> 00:17.040 Alright folks, it's almost the end. 00:17.360 --> 00:19.000 But here we are again. 00:19.680 --> 00:25.640 Wanted to take a quick second and give a big thanks to our 2020 sponsors. 00:25.640 --> 00:29.720 That's Checkmarks, Google, and Offensive Security. 00:29.720 --> 00:33.560 Thank you all so much for helping to make the AppSec Village happen. 00:33.740 --> 00:35.900 We could have done it without you. 00:37.160 --> 00:45.140 If you haven't gotten your shirt yet, go to appsecvillage.com and pick up your t-shirt. 00:46.720 --> 00:53.820 Also, if you're interested in making sure that this is a lasting thing, go out and become a SuperFan for us. 00:53.860 --> 01:03.380 That would go a long way towards helping to make sure that hopefully if next year's DEF CON is in person, AppSec Village will be part of it. 01:03.820 --> 01:18.560 Alright, without any further introduction or me talking, we are going to hear a talk from Mehmet Enes, Managing Partner at Invictus in Cyber Intelligence. 01:18.560 --> 01:25.980 He's going to be talking about A Haven for Hackers, Breaking a Web Security Virtual Appliance. 01:25.980 --> 01:29.940 With that, please help me welcome to the stage, Mehmet. 01:29.940 --> 01:33.500 Let's talk about finding zero-day vulnerabilities. 01:33.500 --> 01:49.500 In that presentation, I'm trying to take you all to the journey with me to finding different vulnerabilities in a security solution and a combination of them will give us a remote code execution with a root user. 01:50.040 --> 01:51.420 This is Mehmet. 01:51.420 --> 02:01.260 I've been doing vulnerability researching since 2005 and I'm working for a company, Invictus Cyber Security and Intelligence. 02:01.260 --> 02:03.880 This is my Twitter address, mdisec. 02:03.880 --> 02:13.320 And pentest.blog is a webpage where me and my teammates are sharing our technical research in here. 02:13.500 --> 02:16.840 Okay, so, A Haven for Hackers, third edition. 02:16.840 --> 02:23.840 Actually, there's a story behind that title and it has started back in 2017. 02:24.120 --> 02:32.520 I was doing a pentesting for a company and there was a blue team member and they were telling me, you are doing this, etc. 02:32.520 --> 02:48.700 And I was thinking about what happens if we somehow manage to break in to your product that they are using and write a custom rule in order to become totally invisible. 02:48.700 --> 02:55.900 Because they are telling us what they are seeing in the product and if we become invisible, that would be so nice. 02:55.900 --> 03:04.920 So , that idea led me to finding remote code execution on various different seam and log management solutions back in 2017. 03:05.480 --> 03:14.640 And after one year, I was trying to send an email to a friend of mine and that dude was not receiving any email from me at all. 03:14.640 --> 03:40.100 And it turned out that there was a problem on the email security gateways and they managed to solve the problem and eventually we started sending an email to each other and I was thinking that, all right, there is an email security gateway product and what happens if I manage to break into your email security gateways so that I can read all the emails incoming and outgoing. 03:40.100 --> 03:52.100 So, that idea motivated me to finding a zero-day remote code execution vulnerabilities on Symantec, MacroFocus, and the Tranq macro. 03:52.140 --> 04:06.060 And the previous year, I was working with another client and the project was hardening the client's network in order to find data exfiltration scenarios. 04:06.060 --> 04:21.780 And they were telling me we have the web security solutions and only that device can connect to the internet so all the clients have to go through that box and if you find a different way to exfiltrate the data, that would be nice. 04:21.780 --> 04:31.360 And I was like, okay, so what happens if you find another zero-day vulnerability on especially the web security and the content filtering solutions. 04:31.640 --> 04:44.300 So, when the attacker managed to execute a code on the client network for the data exfiltration and the CT communication phase they can exploit the content filtering solutions. 04:44.300 --> 04:46.400 So, this is today's topic. 04:46.400 --> 04:54.280 We are going to talk about the zero-day vulnerabilities that I found on a very, very interesting product. 04:54.320 --> 04:57.080 And I have a case study for you. 04:57.760 --> 05:21.380 There is a product from the Trend Macro, InterScan Web Security Virtual Appliance and I have done the vulnerability research on specifically that solution and we are going to see what kind of vulnerabilities that I managed to find and using all of those vulnerabilities together we are going to see some sort of code executions in the end. 05:21.380 --> 05:30.460 But, before diving into the case study, I would like to talk a little bit about what is the content filtering in order to make it crystal clear to everyone. 05:30.460 --> 05:36.940 As you can see in the picture, there is a computer on the left which represents a client's network of the company. 05:37.020 --> 05:43.700 And those devices don't have a direct internet access. 05:43.700 --> 05:56.620 So, they have to go to the proxy service first and that proxy service goes to the internet so that the organization can do some sort of analysis and the rules on the client's network. 05:56.620 --> 06:00.500 So, content filtering is happening in here right now. 06:00.500 --> 06:33.560 We can imagine that the content filtering solutions they are kind of spatially implemented proxy service and the term is given to do controlling the type of web content that employees, guests, customers can access while they are connected to the business wired or wireless network so that the business may want to apply control over the type of content that can be accessed to stop employees by restricting access to certain type of web pages. 06:33.560 --> 06:49.240 And on top of that, also the content filtering is quite a good place to ensure malicious web pages cannot be accessed such as those used for phishing, malicious, distributing malware, etc. 06:49.490 --> 06:57.140 So, we are targeting that kind of products in this presentation. 06:57.140 --> 07:07.100 So, at the beginning, I had two main motivations like targeting web filtering solutions, why we are doing this. 07:07.100 --> 07:14.560 First and foremost, obviously, you know, all the clients network are going to the internet through that solutions. 07:14.560 --> 07:21.500 That means if we manage to break in, we are going to see the whole clients network internet traffic of the organization. 07:21.940 --> 07:31.060 And second motivation is, as I told you before, clients computer don't have a network access to the internet, they must go through the web filter. 07:31.160 --> 07:37.360 So, we need to find a better way to CT communication in the red teaming scenarios. 07:37.360 --> 07:44.700 And I believe web filter solutions is a quite secure and stealth way to make a CT communication. 07:45.380 --> 07:49.860 Of course, there is a lot of different approach like DNS beaconing, etc. 07:50.060 --> 07:54.860 But I believe that is a very secure and stealth way. 07:55.760 --> 08:02.480 So, all right, that is the brief introduction to the idea and the main motivation. 08:02.480 --> 08:08.620 And this is the methodology that I usually follow for my vulnerability research projects. 08:08.720 --> 08:16.240 And there is a seven steps and we're going to see every single step in details throughout the case study. 08:16.320 --> 08:23.040 And first and foremost, we have to find a way to get a free trial of the product that we are going to do vulnerability research on it. 08:23.040 --> 08:31.320 Because you have to, you know, break into your operating system level and you need to find all the source code and etc. 08:31.320 --> 08:39.100 And you have to test your vulnerabilities and eventually you're going to implement exploits for the vulnerabilities you found. 08:39.100 --> 08:44.540 So , you have to find a way to get a free trial and it's not quite easy, guys, always. 08:44.540 --> 08:45.480 It's not quite easy. 08:45.480 --> 08:51.200 It's sometimes and most of the times it requires to have a lot of meetings with the sales team. 08:51.540 --> 09:06.800 And if you find a free trial of the product, I strongly suggest you to start by reading the documentation because there is administrative documentation of this type of solutions and there is a huge technical information about the product itself. 09:06.860 --> 09:26.020 So, after that, we are going to find a way to have a root SSH access to the box because we are going to do the vulnerability research and most of the case there is operating level hardening and we need to get rid of all of those hardening stuff. 09:26.020 --> 09:57.020 And after that, you know, you are in a situation where you managed to install the solution, you read the documentation and you managed to overcome the operating level system hardening and that is the moment that you need to start using product itself like a regular user because you have to understand all the features because those information will become so handy when you need to define a possible attack vector. 09:57.020 --> 10:16.520 So, after that, we are going to talk about the enumeration and the configuration step and the most important phase is the defining possible attack vectors because you got all the information you need and it is a time to building attack scenarios and then find a vulnerability as a final step. 10:16.520 --> 10:20.580 We are going to see every single step throughout our case. 10:20.580 --> 10:28.500 And in that case, I mean the TRANQ macro Intersecam Web Security Virtual Appliance 6.5 version. 10:28.500 --> 10:31.660 You can download it from the vendor web page. 10:32.160 --> 10:37.540 So, getting a free trial was quite easy specifically in that case. 10:37.540 --> 10:51.340 If you go to the Google and looking for the administrative documentation is an important keyword in here for the Google search you can directly find the administrative file which is usually like 300 pages. 10:51.440 --> 11:03.340 I strongly suggest you to read administrative documentation because you are going to see very very helpful information about the product. 11:03.340 --> 11:11.080 As you can see in here administrative documentation tells us there is different modes of the product. 11:11.080 --> 11:22.260 It can be transparent breach mode, it can be transparent breach mode with higher availability forward proxy, reverse proxy, iCAP WCCP, etc. 11:22.780 --> 11:26.900 That product can be installed in very different modes. 11:27.140 --> 11:48.660 On the right side, you are seeing the forward proxy mode which tells you that product can participate in a proxy chain forward all the traffic to the upstream proxy service and you will be seeing lots of graphics on the administrative documentation which will help you to understand about the product itself. 11:48.660 --> 12:02.780 So we are reading the funny manual as well and we of course, for the third step after reading the documentation you need to install the solution into your virtualization system. 12:03.760 --> 12:17.360 During the installation, there was an admin user and the password has been set during the installation and the product gives you an opportunity to do SSH connection to the box with the administrator user. 12:17.360 --> 12:38.100 But the problem is there was a restricted shell on the SSH there is very limited tools that you can use in the SSH interface of the product and we need to find a way to have a directly SSH connection with the root user because we are going to do remote debugging, 12:38.100 --> 12:45.720 we want to try to find out all the source codes and we are going to do further analysis, etc. 12:45.920 --> 12:51.600 So there is a little bit of a step before starting the vulnerability research. 12:51.880 --> 13:35.080 In that case, it was quite easy because the product was distributed by the vendor as an ISO file so you can directly install it into your VM and when you finish the installation the idea is you can detach the VM from the virtual machine that you just installed and then you can attach it to the different Linux machines and then you are going to mount a new disk and you are going to find a grab file because there was a password protection on the grab file and I want to get rid of that protection as well and you just need to remove the password protection line on the graph file. 13:35.180 --> 13:45.520 And after that, in order to get rid of the restricted shell thing, you can go to the SHT config file and you can enable remote root login. 13:45.520 --> 13:57.480 And if you do that, you need to go to the ETC task video file and add binbash for the root user, which will give us a direct SSH connection with the root user without having any restricted shell at all. 13:57.480 --> 14:02.040 And we have to undo every single thing that we have done so far. 14:02.040 --> 14:11.040 So that means you need to unmount this, detach the VM backup file, and attach it back to the original VM and reboot the machine, actually. 14:11.040 --> 14:17.560 And in that case, you are going to have the direct root SSH connection to the box. 14:19.280 --> 14:20.600 This is important. 14:20.600 --> 14:24.240 We need to get rid of, you know, operating level hardening. 14:24.240 --> 14:28.680 So we are kind of ready to start using product itself. 14:28.800 --> 14:39.700 In that case, I choose the reverse proxy mode, but I believe all the vulnerabilities that we have found, it exists no matter what is the installation mode at all. 14:40.680 --> 14:53.680 For the fourth step, I strongly suggest you to use a product for a day to get used to about the features itself, because there is a lot of functionality, as you can see in the picture. 14:53.680 --> 14:57.720 There is a URL access control, HTTP decryption. 14:58.080 --> 15:01.940 Right now, we know that product can't offload the SSL at all. 15:01.940 --> 15:06.180 That means we can deploy SSL through the administratory interface. 15:06.480 --> 15:12.020 And there is an advanced threat protection on the left side of the menu, as you can see. 15:12.020 --> 15:15.040 I hope you are seeing my mouse pointer in here. 15:15.040 --> 15:16.740 There is advanced threat protection. 15:16.740 --> 15:27.620 That means all the HTTP or HTTPS traffic will be analyzed by the product in order to find out malicious activities because of that feature. 15:27.720 --> 15:37.300 So later of that presentation, guys, we are going to see how important it is to understand and getting familiar with the product interface. 15:37.300 --> 15:38.380 Yeah, it's quite important. 15:38.380 --> 15:40.620 Just use it like a normal user. 15:40.880 --> 15:44.380 So we have a search access with a root user. 15:44.380 --> 15:47.480 So the initial step is always enumerating the services. 15:47.480 --> 15:48.500 This is what I'm doing. 15:48.500 --> 15:53.940 Of course, there would be a better way to do it, but this is my way to do. 15:53.940 --> 16:02.680 So I'm always looking for the nested command to find out what kind of services we have in the product itself. 16:02.780 --> 16:09.280 As you can see in here, there is a UWSGI, which listens for 6011. 16:09.360 --> 16:13.540 That means we are doing some sort of assumptions in that phase. 16:13.540 --> 16:20.040 So that most probably means there is a Python project running in the internal system. 16:20.040 --> 16:26.540 And there is a Java process which listens exact port of the administrator interface. 16:26.540 --> 16:34.900 That means we are going to deal with the Java when the time comes to do doing a research on the administrator interface. 16:34.900 --> 16:37.580 There's another UWSGI in here. 16:37.580 --> 16:45.540 And that is another important thing because as I said before, that product acts as proxy service. 16:45.540 --> 16:54.100 So that must be as some service on the product itself in order to handle incoming HTTP connections from the user. 16:54.140 --> 17:02.680 So IWSSD process that you are seeing in here, which listens for 8080801. 17:03.340 --> 17:08.700 This is responsible for all the incoming connection from the client's network. 17:08.700 --> 17:17.820 So this is the majority part of the product itself because that is the one who is communicating with the clients. 17:18.360 --> 17:23.140 All right, so those are the services that we have in the product. 17:23.140 --> 17:32.960 But we need to find which of those services are allowed to communicate with the different computers in the network. 17:32.960 --> 17:38.200 Because in the end, we need to exploit at least one of those services. 17:38.200 --> 17:49.520 So what I'm doing to find out that information, I usually run an nmap scan from my main host to the product IP address. 17:49.520 --> 17:58.020 Or you can just use the IP tables dash dash list command to find out the IP tables rules. 17:58.020 --> 18:08.560 So according to that rule, most of the internal services have been forbidden to network traffic from the outside of the machine. 18:10.140 --> 18:17.140 You guys are remembering the IWSGI service. 18:17.480 --> 18:23.260 If you keep doing enumeration, we are seeing very interesting information in here. 18:23.260 --> 18:30.240 As you can see in here, there is a supervisor which is responsible for starting the solar service. 18:30.240 --> 18:38.080 So right now, we know there is Apache Solar and lots of Python services in the box. 18:38.080 --> 18:40.900 So what is Apache Solar? 18:41.100 --> 18:46.500 It is an open source enterprise search platform written in Java. 18:46.500 --> 18:56.060 It's a major feature is included full text search, highlighting the time indexing, dynamic clustering, etc, etc. 18:56.060 --> 19:07.860 So that means that Python project that we are seeing in here is responsible reading and writing the log file into the Apache Solar service. 19:07.860 --> 19:19.460 So most probably, whenever the request comes to the proxy service from the client's network, that proxy service is sending some sort of signals to the Python project that we have seen in here. 19:19.460 --> 19:22.920 It's something like an internal microservice. 19:22.920 --> 19:29.760 So that Python project is taking the information and writing it into the Apache Solar service. 19:29.760 --> 19:38.060 So whenever the administrator user tries to query something through the administrator interface, that request will be coming to the Python project as well. 19:38.060 --> 19:45.960 Because the naming convention in here says the dashboard parse, mains, stats parse, summary parse. 19:45.960 --> 19:49.980 There's a lot of log parsing and writing to the Apache Solar service. 19:49.980 --> 19:58.820 And whenever it needs to be accessed by the administrator interface, that Python project is taking the responsibility again. 19:58.820 --> 20:04.240 So it is quite important to know there is an Apache Solar service within the box. 20:04.240 --> 20:14.380 But unfortunately, due to the IP tables rule that we have in here, we're not going to be able to directly communicate with Apache Solar at the beginning. 20:14.380 --> 20:18.660 But later on the presentation, we will find a way to do it. 20:19.120 --> 20:24.060 So all right, let's talk about the IWSST process. 20:24.060 --> 20:29.680 If you grab it from the process tree, you are seeing the full path of the binary. 20:29.680 --> 20:40.320 And if you look for the file type, it is a symbolic link to the IWSST process, which is a SUID LFI binary. 20:40.320 --> 20:43.400 And there is a 61 module in that binary. 20:43.400 --> 20:45.980 So it's a very huge binary. 20:46.060 --> 20:50.140 And we can, of course, target that process. 20:52.180 --> 20:55.760 But it will be requiring lots of reverse engineering. 20:55.760 --> 20:59.540 So of course, we are going to do that at some point. 20:59.540 --> 21:05.140 But one of the most important attack surface, as you can imagine, it is the process itself. 21:05.520 --> 21:11.580 So, so far, I believe I just spent 20 minutes, I guess. 21:11.580 --> 21:20.720 And we managed to collect enough level of information about product itself. 21:20.720 --> 21:27.720 So it is time to define attack vectors in a light of those information that we got so far. 21:27.720 --> 21:32.060 So we know that administrator interface is written with Java. 21:32.300 --> 21:36.220 And there is a proxy service, which is written with C++. 21:36.640 --> 21:40.000 I haven't told that before, but it is C++, guys. 21:40.000 --> 21:41.320 It's my best story. 21:41.320 --> 21:48.400 And there is a lot of internal services, but most of them are not accessible from outside of the box. 21:48.400 --> 21:57.580 And you guys are remembering, you know, SSL decryption and advanced threat protection features of the administrator interface. 21:57.580 --> 22:05.280 So we know that it does offloading the SSL, it parses HTML contents, scan files, et cetera, et cetera. 22:05.280 --> 22:22.240 So my idea at that phase, my idea was, okay, let's start with the administrator interface, and we can go after proxy service, if it needs to be, you know, let's start with the administrator interface at the beginning. 22:22.500 --> 22:29.580 But there is a lot of possible attack scenarios, as you can imagine, you know. 22:30.280 --> 22:46.600 One of the... if you want to, let's say, target the HTML parser of the product, like a browser exploitation, you can just send that phishing email to one of the employees of the company that contains a link. 22:46.600 --> 23:02.760 Whenever the user clicks on that link, that request will be sent to the proxy service, and proxy service is going to take that request from the client, and it's going to send exactly the same request to the destination server, which is a webpage that attacker can control. 23:02.980 --> 23:08.660 And whenever the proxy service gets the response, it performs analysis. 23:08.660 --> 23:12.900 It has to parse HTML content and scan the file. 23:12.900 --> 23:19.660 So that means you can directly attack to the HTML parser engine of the product, you know. 23:19.660 --> 23:28.300 There is a lot of different possible attack vectors, you know, that was just one example that just popped in my mind right now during the presentation. 23:29.100 --> 23:34.580 We are going to talk about the administrator interface, and then we're going to talk about the proxy service. 23:35.380 --> 23:42.700 You know, as you know, it is a Java project, and I love, I like to be working on the Java project. 23:42.700 --> 24:06.340 And every single time, whenever I'm facing with a Java application, I always start by reading the configuration file, because, you know, the web.xml, struct.xml, you know, all of those XML files contain a very good, high level of understanding information about the software that we are going to do vulnerability research. 24:06.340 --> 24:19.740 And I don't want to live in an SSH connection during vulnerability research, so we need to find out all the location of the jar file by using just find command on the step two. 24:19.940 --> 24:24.780 And then you can copy all of them to your main host to further analysis. 24:25.520 --> 24:35.120 Because we are going to deal with lots of jar files, and I strongly suggest you to use IDEs. 24:36.000 --> 24:51.120 I used to use gdgui for the compiling of the jar files, but those kind of project has hundreds of different jar files, and if you put all of those jar files into the gdgui, it wasn't working for me. 24:51.120 --> 24:59.920 It was just crashing or freezing, because it has to compile all the class and the functions, and they need to find all the cross calls. 25:00.380 --> 25:07.540 So I strongly suggest you to use IntelliJ or Eclipse for that purpose. 25:07.540 --> 25:20.980 And if you are up to use the IntelliJ IDE, there is a java.compiler.jar file under the compiler library, which comes by default with IntelliJ, I guess. 25:21.020 --> 25:28.320 And you can compile all the jar files under the lib folder. 25:28.320 --> 25:30.260 You can change the name, of course. 25:30.260 --> 25:36.340 And we are going to put all the compiled files under the lib-decompiled folder. 25:36.600 --> 25:44.700 And if you go to the IntelliJ interface and look for the project settings, there is a library section in here. 25:44.700 --> 25:55.880 You can import those libraries and sources all together, which will tell the IntelliJ, this is my Java software. 25:56.440 --> 25:58.720 IntelliJ will take the rest of the job. 25:58.720 --> 26:09.360 It's going to process all the classes, and you're going to be able to just find a function that you are interested in, and you will be just clicking it to go to the definition. 26:09.560 --> 26:16.320 And also you can find a very interesting function that might be some problem in the definition. 26:16.380 --> 26:24.040 You can just by using the IDEs, you can find all the different locations where this specific function has been called. 26:24.040 --> 26:34.180 So I strongly suggest you to be a friend with, you know, IntelliJ or Eclipse, if you are up to one little research on Java application, guys. 26:34.920 --> 26:37.900 So I beg your pardon. 26:37.900 --> 26:43.840 So we have an access to the source code of the administrator interface. 26:43.840 --> 26:51.380 So we are ready to do for the last step, which was finding a vulnerability. 26:51.380 --> 26:57.240 There is a different approach to do it, like, you know, top to bottom or bottom to top, you know. 26:57.240 --> 27:09.280 Bottom to top means, you know, the potentially vulnerable functions on the Java, let's say, and you can directly search those functions within the code base. 27:09.280 --> 27:27.920 And if you believe that you just find a very interesting, very easy way to use those potential vulnerable function, you can start from the bottom to go to the top in order to find out whether you are controlled to parameter that passed through all the function calls. 27:27.920 --> 27:45.600 Or you can start from top to bottom, which is like, you know, start by reading the filter or the middle layer definitions and the classes, look for the authentication mechanism, and then search for all the controller or the request handler definition, 27:45.600 --> 27:55.760 which will be important because that is the location where you can see the user controller parameters, etc, etc. 27:55.760 --> 27:59.720 In that case, I was doing top to bottom approach. 27:59.720 --> 28:04.860 I choose that approach because of not very specific reason. 28:04.860 --> 28:14.480 I was like, you know, doing fun, funny time on the Sunday and I was just start reading the source code and it was like a top to bottom approach. 28:15.200 --> 28:22.340 I wish I could show you all the code bases and everything, but I believe I don't have enough time to do it. 28:22.340 --> 28:31.200 So I just grabbed a very specific function definition, which name is a mount device. 28:31.560 --> 28:38.700 It has to be a post request to be able to execute the function definition. 28:38.800 --> 28:43.240 And there is a very interesting if statement in here. 28:43.240 --> 28:48.460 It tells you if the request is coming from the localhost, it is okay. 28:48.460 --> 28:55.760 But if the request is not coming from localhost, I'm going to validate your session and your privilege as well. 28:55.760 --> 29:06.820 Since we don't have the username, the password, you know, this is going to be a problem for us because it is a password protection if the request is not coming from localhost. 29:06.820 --> 29:14.100 And there is a function call in here , get token, which will have a very important role on our exploitation. 29:14.100 --> 29:16.560 We will come back later. 29:16.560 --> 29:24.580 So that was the important part of the function, and we are moving to the more important stuff. 29:24.680 --> 29:33.780 So it tells us that the request must be a post request, and the post body, it is taken from the request, and it is a JSON object. 29:33.780 --> 29:45.500 And we're going to get the mount device string from the JSON data, and that part is quite interesting because it performs some sort of escaping. 29:45.500 --> 29:50.220 So if the mount device contains a double quote, it will be escaped. 29:51.080 --> 29:57.660 If it contains a backtick, dollar sign, it will be escaped by the backslash. 29:57.660 --> 30:03.860 But the problem is, if it contains backslash, it will escape backslash one more time. 30:03.860 --> 30:10.260 So if we have a double quote, it will be escaped one time, and it will be escaping backslash one more time in here. 30:10.260 --> 30:12.640 There is some sort of problem in here. 30:12.640 --> 30:22.440 And after that, there is a function call, which is an IsVioletMountDevice, and it takes our parameter that we can control. 30:22.440 --> 30:37.480 And if we manage to pass that if statement, we are going to see Exe UI help with CMD, which is tend to execute operating system command with a parameter that we are controlled. 30:37.480 --> 30:40.100 So we need to skip that if statement. 30:40.100 --> 30:41.980 It has to be returned true. 30:42.080 --> 30:44.520 So let's have a look at that one. 30:46.640 --> 30:50.680 IsVioletMountDevice, it is just like a very weak blacklisting. 30:50.680 --> 30:58.300 It tells you it cannot be contained bash, bin as such, Python, slash, Perl, Python, et cetera, et cetera. 30:58.300 --> 31:03.380 It validates, it performs some sort of blacklisting on that bounce. 31:03.380 --> 31:11.040 But the problem is, it has the white space at the beginning of the Perl and the Python command in here. 31:11.040 --> 31:13.020 So it's a very weak blacklisting. 31:13.020 --> 31:15.780 We can bypass that without having any problem. 31:15.900 --> 31:20.820 So we have to keep that in our minds if we've managed to find a vulnerability. 31:21.180 --> 31:26.940 So all right, we can pass that part and we can reach in here. 31:26.940 --> 31:30.140 So it is time to read the Exe UI helper CMD. 31:30.820 --> 31:42.180 And Exe UI helper CMD, it is going to execute UI helper binary with a sub-CMD, which is a command that we can control. 31:42.180 --> 31:43.920 So what is UI helper? 31:43.920 --> 31:50.300 It is located in here and it has a root privilege and there is a suidb. 31:50.300 --> 31:53.880 So all the commands will be executed with a root user. 31:53.880 --> 32:03.480 So if you find a way to execute our command, that command will be executed with the root privileges, which is something very, very important for us. 32:03.480 --> 32:13.680 And finally, that function calls Exe CMD, which is basically calls runtime.getRuntime.exe. 32:13.680 --> 32:17.980 So obviously, we have command injection vulnerability in here. 32:17.980 --> 32:24.780 So we believe that we have the vulnerability in here and we need to do the proof of concept. 32:24.780 --> 32:40.800 Thanks to the reading of funny manual and the product feature steps of the methodology, we know where is which administrator interface, I mean, which many of them it is going to execute that specific endpoint. 32:40.800 --> 32:44.820 Of course, you can build it from scratch, but this is more easier for me. 32:45.420 --> 33:05.560 And as you can see, that is the post request and there is a month device and we can inject our command in here because the dollar sign, it will be used for the execution and the dollar sign escape one time and the backslash escape one more time, which means there is no at all. 33:05.560 --> 33:13.200 That backslash escaping did another one and there is nothing related with the dollar sign, which will be helping us to inject our command. 33:13.200 --> 33:21.740 So basically, we are executing sleep command with a 15 seconds with administrator with a root privilege. 33:21.740 --> 33:25.700 So let's talk about the exploitation of that vulnerability as well. 33:25.780 --> 33:40.040 I'm one of the Metasploit contributors and I usually, you know, using the Python dropper for the exploitation, especially exploiting the Linux machines. 33:40.040 --> 33:46.100 But there's a problem about the Python dropper from the MSF Venom of the Metasploit. 33:46.100 --> 33:54.940 It has to include the double code that wraps up our dropper command in order to pass it to the Python process. 33:54.940 --> 34:03.640 So that means we're not going to be able to directly use it because, as you know, the double code has been escaped on the backend service. 34:03.640 --> 34:13.960 So the idea is that we can use Perl because Perl can take a parameter with a single code, which is allowed to use. 34:14.160 --> 34:17.420 And basically, the idea is simple. 34:17.420 --> 34:25.720 I want to execute Python dropper, but I'm gonna put that Python command into the Perl command. 34:25.720 --> 34:33.760 So basically, during the exploitation, we are going to execute Perl, which is going to execute the first step of the Python dropper. 34:33.860 --> 34:39.040 When the Python executes, it communicates with the handler, and the handler sends the second stage. 34:39.040 --> 34:42.480 So there is, you know, lots of execution, one and after. 34:42.480 --> 34:51.840 And there is a Ruby code, as you can see in here, that we can build a Perl command, which includes, which contains our Python command. 34:51.840 --> 34:53.540 So it's a quite nice trick. 34:54.470 --> 34:57.880 So I reported that vulnerabilities to the ZDI. 34:57.880 --> 35:08.700 And of course, ZDI told me that the authentication is required to exploit that vulnerability, but we are going to see that the exploitation can be bypassed, guys. 35:10.040 --> 35:14.060 So we have to bypass authentication. 35:14.120 --> 35:16.060 Those are the initial ideas. 35:16.060 --> 35:28.700 We can find a stored cross-site scripting vulnerability because we can force the user to send HTTP requests to the device endpoint where we have the command injection. 35:28.700 --> 35:40.660 And since the user is going to be manipulated by JavaScript, that request will be sent to the endpoint with the authenticated user. 35:40.660 --> 35:46.010 So we don't have to be thinking about authentication request, authentication stuff. 35:46.090 --> 36:08.530 And another idea is it would be handy to find something, SSH vulnerability, some sort of, some type of SSH vulnerability could be handy in order to communicate with internal services so that we can send a request from the localhost to the endpoint, or it can go directly after the authentication bypass. 36:09.250 --> 36:11.170 I don't have too much time. 36:11.170 --> 36:18.470 I'm just going to show you how I find a stored cross-site scripting on the administrative interface. 36:18.470 --> 36:24.650 So as you can see in here, that is a very basic HTTP request to the proxy service. 36:24.650 --> 36:37.430 It tells to the proxy service that I'm going to, you know, that I want to send a GET request to the pentest.blob and proxy service does the job and sends the response back to the user. 36:37.430 --> 36:42.230 So that activity has been written into the administrative interface. 36:42.230 --> 36:48.470 Guys, remember the Python and Apache Solr stuff that we have talked about 15 minutes ago. 36:48.650 --> 36:58.030 You know, that activity has been written to the Apache Solr database, which is represented into the administrative interface. 36:58.030 --> 37:04.810 So the idea is that we can control that data in here because we can tell anything we want to the proxy service. 37:04.810 --> 37:07.130 So the idea is quite simple. 37:07.330 --> 37:15.530 As an attacker, we are going to intentionally download a very, very known malware through the proxy service. 37:15.730 --> 37:25.770 So proxy product can detect it and produce a log file and it will be like, you know, ringing all the alarms, you know, I call the malware, etc, etc. 37:25.770 --> 37:37.250 But the data will be written into the Apache Solr, which is being used in the administrative interface and very, very specifically in here. 37:37.250 --> 37:48.130 So when the system administrator logs in and checks what's happening, we can execute JavaScript code on the system administrator browser. 37:48.270 --> 37:55.930 And thanks to that JavaScript code, we can send the IX request to the vulnerable endpoint that we have found in the first place. 37:55.930 --> 38:06.770 So, you know, there was a quite interesting XSS vulnerability because whenever the browser is sending requests to the proxy, they are performing the full URL encoding in here. 38:06.770 --> 38:11.150 But I'm manually crafting the HTTP request to the proxy service. 38:11.150 --> 38:18.450 That means there will be no encoding and that data is not being encoded on the administrator interface. 38:18.450 --> 38:25.230 Basically, we have a cross-site scripting, spatially stored cross-site scripting vulnerability in here. 38:25.230 --> 38:34.450 So instead of popping up an alert box, we are just, we can just call IX request to the endpoint that we have a command injection. 38:34.450 --> 38:39.450 So that was, I reported that vulnerability to the ZDI as well. 38:39.750 --> 38:50.810 And as you can see in the vulnerability description, attacker can leverage this in a conjunction with other vulnerabilities to execute code in the context of the root user. 38:50.870 --> 38:54.970 But guys, you know, cross-site scripting is cool. 38:54.970 --> 39:07.630 I'm not underestimating any kind of vulnerabilities, but it is just not enough for me because there is a huge setback which requires the user interaction for the exploitation. 39:07.750 --> 39:14.270 I was like, okay, I just find something very cool, you know, intentional downloading of malware, etc, etc. 39:14.270 --> 39:21.310 That idea was simple and cool, but I need to find a better way to continue the exploitation. 39:21.550 --> 39:30.870 But, you know, I got another idea while I was spending a time to find the XSS through the proxy service. 39:30.870 --> 39:34.430 So the idea is targeting proxy service itself. 39:34.650 --> 39:42.250 So as you can remember from the previous slides, that is the HTTP request, a very simple HTTP request to the proxy service itself. 39:42.250 --> 39:47.530 It tells the proxy service that I want to communicate with the Pantheon staff blog. 39:47.530 --> 39:51.790 Proxy service sends the request, gets the response, and sends back to the user, right? 39:51.790 --> 39:59.970 So what happens if I tell the proxy service that I want you to communicate with yourself? 40:00.630 --> 40:06.570 In that case, it told me there is a, you know, self-referential request to proxy are forbidden. 40:06.570 --> 40:15.330 And I was like, all right, that means there is some sort of control and lots of if statements in the proxy service itself. 40:15.330 --> 40:21.490 What happens if I manage to trick the proxy service to communicate with an internal service? 40:21.490 --> 40:23.290 That was the main idea. 40:23.290 --> 40:28.250 So that is the function, get end user authentication function. 40:28.250 --> 40:34.950 I set a breakpoint in here, which produced exactly the same error message that we have seen in here. 40:34.990 --> 40:52.210 And I just sent the same request, and it hit the breakpoint, and it tells you that get user notification or the notification has been called by the prepare proxy loop rejection, which has been called by the handle proxy loop, which has been called by the due processing. 40:52.210 --> 40:55.450 So we're going to read all of those functions. 40:55.710 --> 41:03.590 So within the due processing, there is one function called, which is an easy reverse proxy. 41:03.690 --> 41:06.970 And the function is a member of the proxy config cache. 41:06.970 --> 41:12.090 So basically, products try to understand, like, am I being placed as a reverse proxy? 41:12.090 --> 41:19.070 And in that case, handle proxy loop has been called, this function that we have seen on the previous slide. 41:19.070 --> 41:24.970 And that function calls tm socket address is same ADDR. 41:24.990 --> 41:38.990 That is the important part, because that function performs full URL comparison with the URL of the proxy service, with a URL of the user try to communicate. 41:38.990 --> 41:48.930 So if it is a same address, it calls prepare proxy loop rejection call, and we are seeing that error message. 41:48.930 --> 41:54.350 So I just changed the port number to the Apache Solr service. 41:54.350 --> 42:00.550 And due to that changes, there will be a no match in the full URL comparison on the proxy service. 42:00.550 --> 42:06.390 And there is administrator interface of the Apache Solr service. 42:06.530 --> 42:14.810 I'm just can communicate with it because of a very interesting bug in the proxy service. 42:14.810 --> 42:23.070 So I, as you can see in here, I'm allowed to communicate with the Apache Solr service administrator interface. 42:23.070 --> 42:36.970 So, all right, that was another very, very, very important vulnerability, because we can, we are going to leverage this vulnerability to the bypass authentication on the systems. 42:36.970 --> 42:40.190 And in the end, we're going to chain all of them together, guys. 42:40.350 --> 42:54.210 So Apache Solr service in the box, I mean, in the product was very old version, because it's not quite easy to upgrade your third party dependencies like Apache Solr or database servers. 42:54.210 --> 43:00.030 And in these type of solutions, it's quite hard to upgrade to newer versions. 43:00.030 --> 43:08.170 So that was a very, very old vulnerability in Apache Solr service, but it is exactly what I need. 43:08.170 --> 43:11.470 It is arbitrary file read vulnerability. 43:11.730 --> 43:17.170 So that is the name of the collection, and there is a replication endpoint. 43:17.490 --> 43:20.250 And the command has to be a file content. 43:20.350 --> 43:26.910 And you can traverse back to the roots folder, and then you can call whatever you want. 43:26.910 --> 43:30.850 And that will give you to reading any content of the file. 43:31.270 --> 43:40.610 So at the beginning, I wasn't, there was no way to communicate with the Apache Solr service, but we find a very interesting bug. 43:40.610 --> 43:46.030 And by exploiting that bug, we are going to read anything we want. 43:46.310 --> 43:48.570 So far, so good. 43:48.830 --> 43:52.050 I want you to remind the get token function. 43:52.050 --> 43:55.990 You know, it was like way behind of our presentation. 43:56.010 --> 43:58.390 Guys, all right. 43:58.390 --> 44:01.170 Do you remember that get token function? 44:01.350 --> 44:05.590 It is going to help us what we are going to achieve in here. 44:05.590 --> 44:09.950 Because, let me, yeah. 44:09.950 --> 44:18.530 Because that function takes cookies from the HTTP request, and it returns the value. 44:18.530 --> 44:24.410 But the problem is, it prints out the value and the name of the cookies. 44:24.490 --> 44:31.210 But the Java application is running by the Tomcat process. 44:31.210 --> 44:38.750 So those standard outputs data will be written into the log file, which is a Catalina.auth file. 44:38.750 --> 44:49.970 So due to that little function, all of those valid session IDs written into the log file, and we have arbitrary file read vulnerability. 44:50.330 --> 45:02.170 So what we are going to do that, we're going to exploit two vulnerabilities together in order to get the content of the Catalina.auth file, which contains the valid session IDs. 45:02.190 --> 45:16.850 And then we are going to collect all the session IDs together, and we can go to administrator interface in order to exploit command injection vulnerability with the active session IDs. 45:16.850 --> 45:20.530 So the idea is actually quite simple, guys. 45:20.530 --> 45:34.910 We are going to, in the first step, we are going to exploit a comparison bug in the proxy service, which helps us to communicate with the Apache solar service that is running within the product itself. 45:35.190 --> 45:41.870 And this is a very old software which has a vulnerability, and it is arbitrary file reads. 45:41.870 --> 45:47.530 And combination of that vulnerability, we are going to read Catalina.auth file. 45:47.530 --> 45:53.310 And we're going to, by using regex, we're going to extract all the session IDs that we have. 45:53.310 --> 45:56.210 And there is a check session endpoint. 45:56.210 --> 45:59.370 I haven't talked about it because it was quite easy. 45:59.370 --> 46:02.330 There is a check session endpoint in the product. 46:02.330 --> 46:09.330 We are going to test all the session IDs we have in order to find out whether it is still active or not. 46:09.330 --> 46:29.470 And if you find an active session, we are going to exploit the command injection vulnerability, and we are going to be executing operating system commands with a root privilege, which will give us a C2 reverse shellcr command and control server. 46:29.510 --> 46:31.330 That is the idea. 46:31.410 --> 46:38.410 And of course, I have implemented a metasplit module that performs all of those steps automatically. 46:38.430 --> 46:40.630 And I have a video for it. 46:40.650 --> 46:43.230 I would like to, I guess, yeah, time is good. 46:43.230 --> 46:44.870 I guess I still have a minute. 46:44.910 --> 46:48.870 So let's see. 46:52.800 --> 47:00.000 And by the way, that metasplit module has been merged to the master branch of the metasplit project. 47:00.000 --> 47:08.040 You are just, you know, can go and fetch the module and install the product on your lab and, you know, have fun. 47:08.380 --> 47:18.120 So when we run, as you can see in here, it's trying to, it exploits reverse process service and extract the katalina.out file. 47:18.120 --> 47:20.280 And that was, of course, this is a demonstration. 47:20.280 --> 47:23.860 There's only one session ID in the log file and it's inactive. 47:24.100 --> 47:33.080 And by using that session ID, it goes to the command injection vulnerability and it executes operating system command, which is a Perl command. 47:33.080 --> 47:38.360 Perl command contains a Python command, you know, and all of those steps have been automatically done. 47:38.360 --> 47:47.100 And as you can see in here, we have a root session on the back filter solution of the company, guys. 47:47.680 --> 47:48.620 That's it. 47:48.620 --> 47:49.700 Thank you very much.