[00:14.060 --> 00:19.000] Alright folks, it's almost the end. 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:39.540] If you haven't gotten your shirt yet, [00:39.540 --> 00:45.140] go to appsecvillage.com and pick up your t-shirt. [00:46.720 --> 00:51.060] Also, if you're interested in making sure that this is a lasting thing, [00:51.060 --> 00:53.820] go out and become a SuperFan for us. [00:53.860 --> 00:57.440] That would go a long way towards helping to make sure that [00:57.440 --> 01:01.280] hopefully if next year's DEF CON is in person, [01:01.280 --> 01:03.380] AppSec Village will be part of it. [01:03.820 --> 01:08.320] Alright, without any further introduction or me talking, [01:08.320 --> 01:13.340] we are going to hear a talk from Mehmet Enes, [01:14.240 --> 01:18.560] Managing Partner at Invictus in Cyber Intelligence. [01:18.560 --> 01:22.260] He's going to be talking about A Haven for Hackers, [01:22.260 --> 01:25.980] 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:37.980] In that presentation, I'm trying to take you all to the journey [01:37.980 --> 01:43.260] with me to finding different vulnerabilities in a security solution [01:43.260 --> 01:47.660] and a combination of them will give us a remote code execution [01:47.660 --> 01:49.500] with a root user. [01:50.040 --> 01:55.580] This is Mehmet. I've been doing vulnerability researching since 2005 [01:55.580 --> 02:01.260] 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:08.020] And pentest.blog is a webpage where me and my teammates [02:08.710 --> 02:13.320] 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:29.140] I was doing a pentesting for a company and there was a blue team member [02:29.140 --> 02:32.520] and they were telling me, you are doing this, etc. [02:32.520 --> 02:39.320] And I was thinking about what happens if we somehow manage to break in [02:39.320 --> 02:45.700] to your product that they are using and write a custom rule [02:45.700 --> 02:48.700] in order to become totally invisible. [02:48.700 --> 02:51.980] Because they are telling us what they are seeing in the product [02:51.980 --> 02:55.900] and if we become invisible, that would be so nice. [02:55.900 --> 03:00.080] So, that idea led me to finding remote code execution [03:00.080 --> 03:04.920] on various different seam and log management solutions back in 2017. [03:05.480 --> 03:10.580] And after one year, I was trying to send an email to a friend of mine [03:10.580 --> 03:14.640] and that dude was not receiving any email from me at all. [03:14.640 --> 03:19.580] And it turned out that there was a problem on the email security gateways [03:19.580 --> 03:23.640] and they managed to solve the problem and eventually we started sending [03:23.640 --> 03:27.220] an email to each other and I was thinking that, [03:27.220 --> 03:29.900] all right, there is an email security gateway product [03:29.900 --> 03:35.320] and what happens if I manage to break into your email security gateways [03:35.320 --> 03:40.100] so that I can read all the emails incoming and outgoing. [03:40.100 --> 03:47.840] So, that idea motivated me to finding a zero-day remote code execution vulnerabilities [03:47.840 --> 03:52.100] on Symantec, MacroFocus, and the Tranq macro. [03:52.140 --> 03:56.460] And the previous year, I was working with another client [03:56.460 --> 04:00.780] and the project was hardening the client's network [04:00.780 --> 04:06.060] in order to find data exfiltration scenarios. [04:06.060 --> 04:10.460] And they were telling me we have the web security solutions [04:10.460 --> 04:13.540] and only that device can connect to the internet [04:13.540 --> 04:16.400] so all the clients have to go through that box [04:16.400 --> 04:21.780] and if you find a different way to exfiltrate the data, that would be nice. [04:21.780 --> 04:27.140] And I was like, okay, so what happens if you find another zero-day vulnerability [04:27.140 --> 04:31.360] on especially the web security and the content filtering solutions. [04:31.640 --> 04:37.500] So, when the attacker managed to execute a code on the client network [04:37.500 --> 04:40.880] for the data exfiltration and the CT communication phase [04:40.880 --> 04:44.300] they can exploit the content filtering solutions. [04:44.300 --> 04:46.400] So, this is today's topic. [04:46.400 --> 04:48.860] We are going to talk about the zero-day vulnerabilities [04:48.860 --> 04:54.280] 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:03.660] There is a product from the Trend Macro, InterScan Web Security Virtual Appliance [05:03.660 --> 05:08.540] and I have done the vulnerability research on specifically that solution [05:08.540 --> 05:12.920] and we are going to see what kind of vulnerabilities that I managed to find [05:12.920 --> 05:16.600] and using all of those vulnerabilities together [05:17.240 --> 05:21.380] we are going to see some sort of code executions in the end. [05:21.380 --> 05:25.900] But, before diving into the case study, I would like to talk a little bit about [05:25.900 --> 05:30.460] what is the content filtering in order to make it crystal clear to everyone. [05:30.460 --> 05:33.680] As you can see in the picture, there is a computer on the left [05:33.680 --> 05:36.940] 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:46.360] So, they have to go to the proxy service first [05:46.360 --> 05:49.200] and that proxy service goes to the internet [05:49.200 --> 05:53.940] so that the organization can do some sort of analysis [05:53.940 --> 05:56.620] 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:02.800] We can imagine that the content filtering solutions [06:03.440 --> 06:08.240] they are kind of spatially implemented proxy service [06:08.240 --> 06:12.500] and the term is given to do controlling the type of web content [06:12.500 --> 06:16.820] that employees, guests, customers can access [06:16.820 --> 06:20.480] while they are connected to the business wired or wireless network [06:20.480 --> 06:25.740] so that the business may want to apply control over the type of content [06:25.740 --> 06:33.560] that can be accessed to stop employees by restricting access to certain type of web pages. [06:33.560 --> 06:38.800] And on top of that, also the content filtering is quite a good place [06:38.800 --> 06:43.120] to ensure malicious web pages cannot be accessed [06:43.120 --> 06:49.240] 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:01.860] So, at the beginning, I had two main motivations [07:01.860 --> 07:07.100] like targeting web filtering solutions, why we are doing this. [07:07.100 --> 07:11.240] First and foremost, obviously, you know, all the clients network [07:11.240 --> 07:14.560] are going to the internet through that solutions. [07:14.560 --> 07:18.360] That means if we manage to break in, we are going to see the whole [07:18.360 --> 07:21.500] clients network internet traffic of the organization. [07:21.940 --> 07:24.860] And second motivation is, as I told you before, [07:24.860 --> 07:28.320] clients computer don't have a network access to the internet, [07:28.320 --> 07:31.060] they must go through the web filter. [07:31.160 --> 07:35.000] So, we need to find a better way to CT communication [07:35.000 --> 07:37.360] in the red teaming scenarios. [07:37.360 --> 07:42.500] And I believe web filter solutions is a quite secure and stealth way [07:42.500 --> 07:44.700] 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:00.000] So, all right, that is the brief introduction to the idea [08:00.800 --> 08:02.480] and the main motivation. [08:02.480 --> 08:05.420] And this is the methodology that I usually follow [08:05.420 --> 08:08.620] for my vulnerability research projects. [08:08.720 --> 08:12.980] And there is a seven steps and we're going to see every single step [08:12.980 --> 08:16.240] in details throughout the case study. [08:16.320 --> 08:19.780] And first and foremost, we have to find a way to get a free trial [08:19.780 --> 08:23.040] of the product that we are going to do vulnerability research on it. [08:23.040 --> 08:28.380] Because you have to, you know, break into your operating system level [08:28.380 --> 08:31.320] and you need to find all the source code and etc. [08:31.320 --> 08:34.380] And you have to test your vulnerabilities [08:34.380 --> 08:36.480] and eventually you're going to implement exploits [08:36.480 --> 08:39.100] for the vulnerabilities you found. [08:39.100 --> 08:42.680] So, you have to find a way to get a free trial [08:42.680 --> 08:44.540] and it's not quite easy, guys, always. [08:44.540 --> 08:45.480] It's not quite easy. [08:45.480 --> 08:49.420] It's sometimes and most of the times it requires to have a lot of meetings [08:49.420 --> 08:51.200] with the sales team. [08:51.540 --> 08:55.880] And if you find a free trial of the product, [08:55.880 --> 08:58.300] I strongly suggest you to start by reading the documentation [08:58.300 --> 09:02.200] because there is administrative documentation of this type of solutions [09:02.200 --> 09:06.800] and there is a huge technical information about the product itself. [09:06.860 --> 09:14.820] So, after that, we are going to find a way to have a root SSH access to the box [09:14.820 --> 09:17.460] because we are going to do the vulnerability research [09:17.460 --> 09:22.240] and most of the case there is operating level hardening [09:22.240 --> 09:26.020] and we need to get rid of all of those hardening stuff. [09:26.020 --> 09:29.380] And after that, you know, you are in a situation [09:29.380 --> 09:32.020] where you managed to install the solution, [09:32.900 --> 09:36.680] you read the documentation and you managed to overcome [09:36.680 --> 09:40.220] the operating level system hardening [09:40.220 --> 09:44.440] and that is the moment that you need to start using product itself [09:44.440 --> 09:46.320] like a regular user [09:46.320 --> 09:49.680] because you have to understand all the features [09:49.680 --> 09:53.660] because those information will become so handy [09:53.660 --> 09:57.020] when you need to define a possible attack vector. [09:57.020 --> 10:00.520] So, after that, we are going to talk about the enumeration [10:00.520 --> 10:02.980] and the configuration step [10:03.500 --> 10:07.420] and the most important phase is the defining possible attack vectors [10:07.420 --> 10:10.120] because you got all the information you need [10:10.420 --> 10:13.560] and it is a time to building attack scenarios [10:13.560 --> 10:16.520] 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:23.300] And in that case, I mean the TRANQ macro [10:24.140 --> 10:26.520] Intersecam Web Security Virtual Appliance [10:26.520 --> 10:31.660] 6.5 version. You can download it from the vendor web page. [10:32.160 --> 10:34.720] So, getting a free trial was quite easy [10:35.440 --> 10:37.540] specifically in that case. [10:37.540 --> 10:41.060] If you go to the Google and looking for the administrative documentation [10:41.060 --> 10:43.820] is an important keyword in here for the Google search [10:44.760 --> 10:47.940] you can directly find the administrative file [10:47.940 --> 10:51.340] which is usually like 300 pages. [10:51.440 --> 10:54.240] I strongly suggest you to read [10:55.160 --> 10:56.940] administrative documentation because [10:56.940 --> 10:59.080] you are going to see very very [11:00.800 --> 11:03.340] helpful information about the product. [11:03.340 --> 11:04.780] As you can see in here [11:05.780 --> 11:08.900] administrative documentation tells us there is [11:08.900 --> 11:11.580] different modes of the product. It can be [11:11.580 --> 11:14.600] transparent breach mode, it can be transparent [11:14.600 --> 11:17.040] breach mode with higher availability [11:17.600 --> 11:20.560] forward proxy, reverse proxy, iCAP [11:20.560 --> 11:22.260] WCCP, etc. [11:22.780 --> 11:26.900] That product can be installed in very different modes. [11:27.140 --> 11:29.840] On the right side, you are seeing the forward proxy mode [11:29.840 --> 11:31.040] which tells you [11:31.040 --> 11:35.160] that product can participate in a proxy chain [11:35.160 --> 11:38.360] forward all the traffic to the upstream proxy service [11:38.360 --> 11:41.760] and you will be seeing lots of graphics [11:41.760 --> 11:45.200] on the administrative documentation which will help you [11:45.200 --> 11:48.660] to understand about the product itself. [11:48.660 --> 11:51.360] So we are reading the funny manual as well [11:51.360 --> 11:53.520] and we [11:53.520 --> 11:57.260] of course, for the third step after reading the documentation [11:57.260 --> 11:59.840] you need to install the solution into your [11:59.840 --> 12:02.780] virtualization system. [12:03.760 --> 12:06.560] During the installation, there was an admin user [12:06.560 --> 12:09.580] and the password has been set during the installation [12:09.580 --> 12:11.760] and the product gives you [12:12.390 --> 12:15.680] an opportunity to do SSH connection to the box [12:15.680 --> 12:18.500] with the administrator user. But the problem is [12:18.500 --> 12:21.420] there was a restricted shell on the SSH [12:21.420 --> 12:24.560] there is very limited tools [12:24.560 --> 12:27.860] that you can use in the SSH interface of the product [12:27.860 --> 12:30.340] and we need to find a way to [12:30.340 --> 12:33.960] have a directly SSH connection [12:33.960 --> 12:36.780] with the root user because we are going to do [12:36.780 --> 12:40.600] remote debugging, we want to try to find out [12:40.600 --> 12:43.500] all the source codes and we are going to do [12:43.500 --> 12:45.720] further analysis, etc. [12:45.920 --> 12:49.060] So there is a little bit of a step before [12:49.060 --> 12:51.600] starting the vulnerability research. [12:51.880 --> 12:54.840] In that case, it was quite easy [12:55.540 --> 12:58.880] because the product was distributed [12:58.880 --> 13:01.300] by the vendor as an ISO file [13:01.300 --> 13:03.880] so you can directly install it into your VM [13:05.100 --> 13:07.320] and when you finish the installation [13:07.980 --> 13:10.840] the idea is you can detach the VM [13:10.840 --> 13:14.380] from the virtual machine that you just installed [13:14.380 --> 13:17.820] and then you can attach it to the different Linux machines [13:17.820 --> 13:19.880] and then you are going to mount [13:20.140 --> 13:23.440] a new disk and you are going to find a grab file [13:23.440 --> 13:26.540] because there was a password protection on the grab file [13:26.540 --> 13:29.840] and I want to get rid of that protection as well [13:29.840 --> 13:33.080] and you just need to remove the password protection [13:33.080 --> 13:40.400] line on the graph file. And after that, in order to get rid of the restricted shell thing, [13:40.400 --> 13:46.520] you can go to the SHT config file and you can enable remote root login. And if you do that, [13:46.520 --> 13:51.060] you need to go to the ETC task video file and add binbash for the root user, which will give [13:51.060 --> 13:57.480] us a direct SSH connection with the root user without having any restricted shell at all. [13:57.480 --> 14:02.760] And we have to undo every single thing that we have done so far. So that means [14:02.760 --> 14:08.900] you need to unmount this, detach the VM backup file, and attach it back to the original VM and [14:08.900 --> 14:14.200] reboot the machine, actually. And in that case, you are going to have the direct [14:14.200 --> 14:22.080] root SSH connection to the box. This is important. We need to get rid of, you know, [14:22.080 --> 14:29.840] operating level hardening. So we are kind of ready to start using product itself. In that case, [14:29.840 --> 14:34.880] I choose the reverse proxy mode, but I believe all the vulnerabilities that we have found, [14:34.880 --> 14:42.940] it exists no matter what is the installation mode at all. For the fourth step, I strongly [14:42.940 --> 14:49.700] suggest you to use a product for a day to get used to about the features itself, because [14:49.700 --> 14:56.280] there is a lot of functionality, as you can see in the picture. There is a URL access control, [14:56.280 --> 15:02.880] HTTP decryption. Right now, we know that product can't offload the SSL at all. That means we can [15:02.880 --> 15:08.680] deploy SSL through the administratory interface. And there is an advanced threat protection [15:09.360 --> 15:15.040] on the left side of the menu, as you can see. I hope you are seeing my mouse pointer in here. [15:15.040 --> 15:21.680] There is advanced threat protection. That means all the HTTP or HTTPS traffic will be analyzed [15:21.680 --> 15:28.720] by the product in order to find out malicious activities because of that feature. So later [15:28.720 --> 15:34.860] of that presentation, guys, we are going to see how important it is to understand and getting [15:34.860 --> 15:40.620] familiar with the product interface. Yeah, it's quite important. Just use it like a normal user. [15:40.880 --> 15:47.000] So we have a search access with a root user. So the initial step is always enumerating the [15:47.000 --> 15:52.320] services. This is what I'm doing. Of course, there would be a better way to do it, but this [15:52.320 --> 15:58.780] is my way to do. So I'm always looking for the nested command to find out what kind of services [15:58.780 --> 16:09.280] we have in the product itself. As you can see in here, there is a UWSGI, which listens for 6011. [16:09.360 --> 16:15.520] That means we are doing some sort of assumptions in that phase. So that most probably means [16:15.520 --> 16:22.780] there is a Python project running in the internal system. And there is a Java process which listens [16:22.780 --> 16:29.320] exact port of the administrator interface. That means we are going to deal with the Java [16:29.320 --> 16:36.540] when the time comes to do doing a research on the administrator interface. There's another UWSGI [16:36.540 --> 16:44.100] in here. And that is another important thing because as I said before, that product acts as [16:44.100 --> 16:51.440] proxy service. So that must be as some service on the product itself in order to handle incoming [16:51.440 --> 17:00.880] HTTP connections from the user. So IWSSD process that you are seeing in here, which listens for [17:02.020 --> 17:09.300] 8080801. This is responsible for all the incoming connection from the client's network. So this is [17:09.300 --> 17:16.520] the majority part of the product itself because that is the one who is communicating with the [17:16.520 --> 17:24.460] clients. All right, so those are the services that we have in the product. But we need to find [17:24.460 --> 17:32.960] which of those services are allowed to communicate with the different computers in the network. [17:32.960 --> 17:40.400] Because in the end, we need to exploit at least one of those services. So what I'm doing [17:40.400 --> 17:47.780] to find out that information, I usually run an nmap scan from my main host to the product [17:48.480 --> 17:56.340] IP address. Or you can just use the IP tables dash dash list command to find out the IP [17:56.340 --> 18:03.140] tables rules. So according to that rule, most of the internal services have been forbidden [18:03.820 --> 18:15.660] to network traffic from the outside of the machine. You guys are remembering the IWSGI [18:15.660 --> 18:23.260] service. If you keep doing enumeration, we are seeing very interesting information in here. [18:23.260 --> 18:29.060] As you can see in here, there is a supervisor which is responsible for starting the solar [18:29.060 --> 18:38.080] service. So right now, we know there is Apache Solar and lots of Python services in the box. So [18:38.080 --> 18:46.500] what is Apache Solar? It is an open source enterprise search platform written in Java. [18:46.500 --> 18:53.740] It's a major feature is included full text search, highlighting the time indexing, [18:53.740 --> 19:02.420] dynamic clustering, etc, etc. So that means that Python project that we are seeing in here is [19:02.420 --> 19:09.040] responsible reading and writing the log file into the Apache Solar service. So most probably, [19:09.040 --> 19:14.740] whenever the request comes to the proxy service from the client's network, that proxy service is [19:14.740 --> 19:19.560] sending some sort of signals to the Python project that we have seen in here. It's [19:19.560 --> 19:26.320] something like an internal microservice. So that Python project is taking the information and [19:26.320 --> 19:32.700] writing it into the Apache Solar service. So whenever the administrator user tries to query [19:32.700 --> 19:37.120] something through the administrator interface, that request will be coming to the Python project [19:37.120 --> 19:44.240] as well. Because the naming convention in here says the dashboard parse, mains, [19:44.240 --> 19:49.980] stats parse, summary parse. There's a lot of log parsing and writing to the Apache Solar service. [19:49.980 --> 19:56.800] And whenever it needs to be accessed by the administrator interface, that Python project [19:56.800 --> 20:02.420] is taking the responsibility again. So it is quite important to know there is an Apache [20:02.420 --> 20:08.960] Solar service within the box. But unfortunately, due to the IP tables rule that we have in here, [20:08.960 --> 20:15.180] we're not going to be able to directly communicate with Apache Solar at the beginning. But later on [20:15.180 --> 20:24.060] the presentation, we will find a way to do it. So all right, let's talk about the IWSST process. [20:24.060 --> 20:30.280] If you grab it from the process tree, you are seeing the full path of the binary. And if you [20:30.280 --> 20:38.380] look for the file type, it is a symbolic link to the IWSST process, which is a SUID LFI [20:39.060 --> 20:48.540] binary. And there is a 61 module in that binary. So it's a very huge binary. And we can, of course, [20:48.540 --> 20:55.820] target that process. But it will be requiring lots of reverse engineering. So [20:55.820 --> 21:01.960] of course, we are going to do that at some point. But one of the most important attack [21:01.960 --> 21:09.500] surface, as you can imagine, it is the process itself. So, so far, I believe I just spent 20 [21:09.500 --> 21:21.120] minutes, I guess. And we managed to collect enough level of information about product itself. So it [21:21.120 --> 21:27.720] is time to define attack vectors in a light of those information that we got so far. [21:27.720 --> 21:33.920] So we know that administrator interface is written with Java. And there is a proxy service, [21:33.920 --> 21:41.320] which is written with C++. I haven't told that before, but it is C++, guys. 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:55.220] And you guys are remembering, you know, SSL decryption and advanced threat protection [21:55.220 --> 22:01.060] features of the administrator interface. So we know that it does offloading the SSL, [22:01.060 --> 22:10.140] it parses HTML contents, scan files, et cetera, et cetera. So my idea at that phase, my idea was, [22:10.140 --> 22:17.060] okay, let's start with the administrator interface, and we can go after proxy service, [22:17.060 --> 22:22.240] 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:36.000] One of the... if you want to, let's say, target the HTML parser of the product, [22:36.000 --> 22:44.060] like a browser exploitation, you can just send that phishing email to one of the employees of [22:44.060 --> 22:50.200] the company that contains a link. Whenever the user clicks on that link, that request will be [22:50.200 --> 22:55.520] sent to the proxy service, and proxy service is going to take that request from the client, [22:55.520 --> 23:00.780] and it's going to send exactly the same request to the destination server, which is a webpage that [23:00.780 --> 23:08.660] attacker can control. And whenever the proxy service gets the response, it performs analysis. [23:08.660 --> 23:16.460] It has to parse HTML content and scan the file. So that means you can directly attack to the HTML [23:16.460 --> 23:22.940] parser engine of the product, you know. There is a lot of different possible attack vectors, [23:22.940 --> 23:28.300] you know, that was just one example that just popped in my mind right now during the presentation. [23:29.100 --> 23:33.000] We are going to talk about the administrator interface, and then we're going to talk about [23:33.000 --> 23:41.580] the proxy service. You know, as you know, it is a Java project, and I love, I like to be working [23:41.580 --> 23:46.800] on the Java project. And every single time, whenever I'm facing with a Java application, [23:46.800 --> 23:53.820] I always start by reading the configuration file, because, you know, the web.xml, struct.xml, [23:53.820 --> 24:00.500] you know, all of those XML files contain a very good, high level of understanding information [24:00.500 --> 24:08.040] about the software that we are going to do vulnerability research. And I don't want to [24:08.040 --> 24:15.060] live in an SSH connection during vulnerability research, so we need to find out all the location [24:15.060 --> 24:21.640] of the jar file by using just find command on the step two. And then you can copy all of them [24:21.640 --> 24:29.680] to your main host to further analysis. Because we are going to deal with lots of jar files, [24:29.680 --> 24:40.680] and I strongly suggest you to use IDEs. I used to use gdgui for the compiling of the jar files, [24:40.680 --> 24:47.140] but those kind of project has hundreds of different jar files, and if you put all of [24:47.140 --> 24:53.460] those jar files into the gdgui, it wasn't working for me. It was just crashing or freezing, [24:53.460 --> 24:58.700] because it has to compile all the class and the functions, and they need to find all the cross [24:58.700 --> 25:09.300] calls. So I strongly suggest you to use IntelliJ or Eclipse for that purpose. And if you are up to [25:09.300 --> 25:18.680] use the IntelliJ IDE, there is a java.compiler.jar file under the compiler library, which comes by [25:19.080 --> 25:28.320] default with IntelliJ, I guess. And you can compile all the jar files under the lib folder. [25:28.320 --> 25:36.340] You can change the name, of course. And we are going to put all the compiled files under the lib-decompiled folder. [25:36.600 --> 25:43.120] And if you go to the IntelliJ interface and look for the project settings, there is a library [25:43.120 --> 25:52.480] section in here. You can import those libraries and sources all together, which will tell the [25:52.480 --> 25:59.700] IntelliJ, this is my Java software. IntelliJ will take the rest of the job. It's going to process [25:59.700 --> 26:05.680] all the classes, and you're going to be able to just find a function that you are interested in, [26:05.680 --> 26:11.560] and you will be just clicking it to go to the definition. And also you can find a very [26:11.560 --> 26:19.240] interesting function that might be some problem in the definition. You can just by using the IDEs, [26:19.240 --> 26:24.560] you can find all the different locations where this specific function has been called. So I [26:24.560 --> 26:30.020] strongly suggest you to be a friend with, you know, IntelliJ or Eclipse, if you are up to [26:30.020 --> 26:41.000] one little research on Java application, guys. So I beg your pardon. So we have an access to [26:41.000 --> 26:48.740] the source code of the administrator interface. So we are ready to do for the last step, [26:48.740 --> 26:54.820] which was finding a vulnerability. There is a different approach to do it, like, you know, [26:54.820 --> 27:01.740] top to bottom or bottom to top, you know. Bottom to top means, you know, the potentially vulnerable [27:02.380 --> 27:08.760] functions on the Java, let's say, and you can directly search those functions within the code [27:08.760 --> 27:16.240] base. And if you believe that you just find a very interesting, very easy way to use those [27:16.240 --> 27:22.660] potential vulnerable function, you can start from the bottom to go to the top in order to find out [27:22.660 --> 27:28.720] whether you are controlled to parameter that passed through all the function calls. Or you [27:28.720 --> 27:34.900] can start from top to bottom, which is like, you know, start by reading the filter or the middle [27:34.900 --> 27:41.080] layer definitions and the classes, look for the authentication mechanism, and then search for [27:41.080 --> 27:49.920] all the controller or the request handler definition, which will be important because [27:49.920 --> 27:57.000] that is the location where you can see the user controller parameters, etc, etc. In that case, [27:57.000 --> 28:04.920] I was doing top to bottom approach. I choose that approach because of not very specific reason. I [28:04.920 --> 28:11.040] was like, you know, doing fun, funny time on the Sunday and I was just start reading the source [28:11.040 --> 28:19.020] code and it was like a top to bottom approach. I wish I could show you all the code bases and [28:19.020 --> 28:25.220] everything, but I believe I don't have enough time to do it. So I just grabbed a very specific [28:25.220 --> 28:36.940] function definition, which name is a mount device. It has to be a post request to be able to execute [28:36.940 --> 28:44.320] the function definition. And there is a very interesting if statement in here. It tells you [28:44.320 --> 28:50.340] if the request is coming from the localhost, it is okay. But if the request is not coming from [28:50.340 --> 28:56.720] localhost, I'm going to validate your session and your privilege as well. Since we don't have [28:56.720 --> 29:02.720] the username, the password, you know, this is going to be a problem for us because it is a [29:02.720 --> 29:09.420] password protection if the request is not coming from localhost. And there is a function call in [29:09.420 --> 29:16.560] here, get token, which will have a very important role on our exploitation. 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:31.020] So it tells us that the request must be a post request, and the post body, it is taken [29:31.020 --> 29:36.440] from the request, and it is a JSON object. And we're going to get the mount device string from the [29:37.520 --> 29:45.500] JSON data, and that part is quite interesting because it performs some sort of escaping. So [29:46.060 --> 29:53.500] if the mount device contains a double quote, it will be escaped. If it contains a backtick, [29:53.500 --> 30:01.280] dollar sign, it will be escaped by the backslash. But the problem is, if it contains backslash, [30:01.280 --> 30:07.300] it will escape backslash one more time. So if we have a double quote, it will be escaped one time, [30:07.300 --> 30:12.640] and it will be escaping backslash one more time in here. There is some sort of problem in here. [30:12.640 --> 30:19.080] And after that, there is a function call, which is an IsVioletMountDevice, [30:19.080 --> 30:25.440] and it takes our parameter that we can control. And if we manage to pass that if statement, [30:25.440 --> 30:32.660] we are going to see Exe UI help with CMD, which is tend to execute operating system [30:34.260 --> 30:40.580] command with a parameter that we are controlled. So we need to skip that if statement. It has to [30:40.580 --> 30:49.380] be returned true. So let's have a look at that one. IsVioletMountDevice, it is just like a very [30:49.380 --> 30:55.120] weak blacklisting. It tells you it cannot be contained bash, bin as such, Python, slash, [30:55.120 --> 31:02.940] Perl, Python, et cetera, et cetera. It validates, it performs some sort of blacklisting on that [31:02.940 --> 31:09.800] bounce. But the problem is, it has the white space at the beginning of the Perl and the Python [31:09.800 --> 31:15.780] command in here. So it's a very weak blacklisting. 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:28.600] So all right, we can pass that part and we can reach in here. So it is time to read the Exe UI [31:28.600 --> 31:38.980] helper CMD. And Exe UI helper CMD, it is going to execute UI helper binary with a sub-CMD, which is [31:39.780 --> 31:48.140] a command that we can control. So what is UI helper? It is located in here and it has a root [31:48.140 --> 31:53.880] privilege and there is a suidb. So all the commands will be executed with a root user. [31:53.880 --> 32:00.620] So if you find a way to execute our command, that command will be executed with the root privileges, [32:00.620 --> 32:08.060] which is something very, very important for us. And finally, that function calls Exe CMD, which is [32:09.120 --> 32:16.360] basically calls runtime.getRuntime.exe. So obviously, we have command injection [32:16.360 --> 32:23.440] vulnerability in here. So we believe that we have the vulnerability in here and we need to do the [32:23.440 --> 32:28.340] proof of concept. Thanks to the reading of funny manual and the product feature steps of the [32:28.340 --> 32:38.360] methodology, we know where is which administrator interface, I mean, which many of them it is going [32:38.360 --> 32:43.480] to execute that specific endpoint. Of course, you can build it from scratch, but this is more [32:43.480 --> 32:51.300] easier for me. And as you can see, that is the post request and there is a month device and we [32:51.300 --> 32:59.220] can inject our command in here because the dollar sign, it will be used for the execution and the [32:59.220 --> 33:04.320] dollar sign escape one time and the backslash escape one more time, which means there is no [33:04.320 --> 33:10.200] at all. That backslash escaping did another one and there is nothing related with the dollar sign, [33:10.200 --> 33:16.160] which will be helping us to inject our command. So basically, we are executing sleep command with [33:16.280 --> 33:23.880] a 15 seconds with administrator with a root privilege. So let's talk about the exploitation [33:23.880 --> 33:33.180] of that vulnerability as well. I'm one of the Metasploit contributors and I usually, you know, [33:33.180 --> 33:40.040] using the Python dropper for the exploitation, especially exploiting the Linux machines. [33:40.040 --> 33:46.780] But there's a problem about the Python dropper from the MSF Venom of the Metasploit. It has to [33:47.340 --> 33:54.940] include the double code that wraps up our dropper command in order to pass it to the Python process. [33:54.940 --> 34:00.460] So that means we're not going to be able to directly use it because, as you know, the double [34:00.460 --> 34:08.620] code has been escaped on the backend service. So the idea is that we can use Perl because Perl can [34:08.620 --> 34:17.420] take a parameter with a single code, which is allowed to use. And basically, the idea is simple. [34:17.420 --> 34:26.040] I want to execute Python dropper, but I'm gonna put that Python command into the Perl command. So [34:26.040 --> 34:31.600] basically, during the exploitation, we are going to execute Perl, which is going to execute the [34:31.600 --> 34:37.060] first step of the Python dropper. When the Python executes, it communicates with the handler, [34:37.060 --> 34:41.400] and the handler sends the second stage. So there is, you know, lots of execution, [34:41.400 --> 34:48.860] one and after. And there is a Ruby code, as you can see in here, that we can build a Perl command, [34:48.860 --> 34:53.540] which includes, which contains our Python command. So it's a quite nice trick. [34:54.470 --> 35:00.700] So I reported that vulnerabilities to the ZDI. And of course, ZDI told me that the authentication [35:00.700 --> 35:06.960] is required to exploit that vulnerability, but we are going to see that the exploitation can [35:06.960 --> 35:16.060] be bypassed, guys. So we have to bypass authentication. Those are the initial ideas. [35:16.060 --> 35:20.800] We can find a stored cross-site scripting vulnerability because we can force the [35:20.800 --> 35:28.700] user to send HTTP requests to the device endpoint where we have the command injection. [35:28.700 --> 35:38.380] And since the user is going to be manipulated by JavaScript, that request will be sent to the [35:38.380 --> 35:44.350] endpoint with the authenticated user. So we don't have to be thinking about authentication request, [35:44.350 --> 35:51.250] authentication stuff. And another idea is it would be handy to find something, [35:51.250 --> 35:57.470] SSH vulnerability, some sort of, some type of SSH vulnerability could be handy in order to [35:57.470 --> 36:04.590] communicate with internal services so that we can send a request from the localhost to the endpoint, [36:04.590 --> 36:11.530] or it can go directly after the authentication bypass. I don't have too much time. I'm just [36:11.530 --> 36:18.470] going to show you how I find a stored cross-site scripting on the administrative interface. [36:18.470 --> 36:25.350] So as you can see in here, that is a very basic HTTP request to the proxy service. It tells to [36:25.350 --> 36:31.550] the proxy service that I'm going to, you know, that I want to send a GET request to the pentest.blob [36:31.550 --> 36:38.750] and proxy service does the job and sends the response back to the user. So that activity [36:38.750 --> 36:44.050] has been written into the administrative interface. Guys, remember the Python and [36:44.050 --> 36:50.390] Apache Solr stuff that we have talked about 15 minutes ago. You know, that activity [36:50.390 --> 36:57.370] has been written to the Apache Solr database, which is represented into the administrative [36:57.370 --> 37:02.750] interface. So the idea is that we can control that data in here because we can tell anything [37:02.750 --> 37:09.210] we want to the proxy service. So the idea is quite simple. As an attacker, we are going to [37:09.210 --> 37:17.930] intentionally download a very, very known malware through the proxy service. So proxy product can [37:17.930 --> 37:23.530] detect it and produce a log file and it will be like, you know, ringing all the alarms, you know, [37:23.530 --> 37:32.150] I call the malware, etc, etc. But the data will be written into the Apache Solr, which is being [37:32.150 --> 37:38.370] used in the administrative interface and very, very specifically in here. So when the system [37:38.370 --> 37:45.290] administrator logs in and checks what's happening, we can execute JavaScript code on the [37:45.290 --> 37:51.870] system administrator browser. And thanks to that JavaScript code, we can send the IX request to [37:51.870 --> 37:58.590] the vulnerable endpoint that we have found in the first place. So, you know, there was a quite [37:58.590 --> 38:03.930] interesting XSS vulnerability because whenever the browser is sending requests to the proxy, [38:03.930 --> 38:09.290] they are performing the full URL encoding in here. But I'm manually crafting the HTTP request [38:09.290 --> 38:16.110] to the proxy service. That means there will be no encoding and that data is not being encoded [38:16.110 --> 38:22.710] on the administrator interface. Basically, we have a cross-site scripting, spatially stored [38:22.710 --> 38:28.710] cross-site scripting vulnerability in here. So instead of popping up an alert box, we are just, [38:28.710 --> 38:35.970] we can just call IX request to the endpoint that we have a command injection. So that was, [38:35.970 --> 38:42.850] I reported that vulnerability to the ZDI as well. And as you can see in the vulnerability description, [38:42.850 --> 38:47.610] attacker can leverage this in a conjunction with other vulnerabilities to execute code [38:47.610 --> 38:54.970] in the context of the root user. But guys, you know, cross-site scripting is cool. [38:54.970 --> 39:02.730] I'm not underestimating any kind of vulnerabilities, but it is just not enough for me because there is [39:02.870 --> 39:09.410] a huge setback which requires the user interaction for the exploitation. I was like, okay, I just [39:09.410 --> 39:15.070] find something very cool, you know, intentional downloading of malware, etc, etc. That idea was [39:15.070 --> 39:23.590] simple and cool, but I need to find a better way to continue the exploitation. But, you know, [39:23.590 --> 39:31.070] I got another idea while I was spending a time to find the XSS through the proxy service. So [39:31.070 --> 39:37.430] the idea is targeting proxy service itself. So as you can remember from the previous slides, [39:37.430 --> 39:42.990] that is the HTTP request, a very simple HTTP request to the proxy service itself. It tells [39:42.990 --> 39:48.090] the proxy service that I want to communicate with the Pantheon staff blog. Proxy service [39:48.090 --> 39:54.830] sends the request, gets the response, and sends back to the user, right? So what happens if I [39:54.830 --> 40:01.550] tell the proxy service that I want you to communicate with yourself? In that case, [40:01.550 --> 40:07.430] it told me there is a, you know, self-referential request to proxy are forbidden. And I was like, [40:07.430 --> 40:14.410] all right, that means there is some sort of control and lots of if statements in the proxy [40:14.410 --> 40:19.850] service itself. What happens if I manage to trick the proxy service to communicate with an [40:19.850 --> 40:26.750] internal service? That was the main idea. So that is the function, get end user authentication [40:27.590 --> 40:33.150] function. I set a breakpoint in here, which produced exactly the same error message that [40:33.150 --> 40:40.150] we have seen in here. And I just sent the same request, and it hit the breakpoint, and it tells [40:40.150 --> 40:47.150] you that get user notification or the notification has been called by the prepare proxy loop [40:47.150 --> 40:51.550] rejection, which has been called by the handle proxy loop, which has been called by the due [40:51.550 --> 40:58.890] processing. So we're going to read all of those functions. So within the due processing, there is [40:58.890 --> 41:05.550] one function called, which is an easy reverse proxy. And the function is a member of the proxy [41:05.550 --> 41:11.230] config cache. So basically, products try to understand, like, am I being placed as a reverse [41:11.230 --> 41:17.810] proxy? And in that case, handle proxy loop has been called, this function that we have seen on [41:17.810 --> 41:26.990] the previous slide. And that function calls tm socket address is same ADDR. That is the important [41:26.990 --> 41:35.110] part, because that function performs full URL comparison with the URL of the proxy service, [41:35.110 --> 41:44.550] with a URL of the user try to communicate. So if it is a same address, it calls prepare proxy [41:44.550 --> 41:51.650] loop rejection call, and we are seeing that error message. So I just changed the port number [41:51.650 --> 41:58.090] to the Apache Solr service. And due to that changes, there will be a no match in the full [41:58.090 --> 42:06.390] URL comparison on the proxy service. And there is administrator interface of the Apache Solr service. [42:06.530 --> 42:14.890] I'm just can communicate with it because of a very interesting bug in the proxy service. So [42:14.890 --> 42:20.650] I, as you can see in here, I'm allowed to communicate with the Apache Solr service [42:20.650 --> 42:29.330] administrator interface. So, all right, that was another very, very, very important vulnerability, [42:29.330 --> 42:35.790] because we can, we are going to leverage this vulnerability to the bypass authentication [42:35.790 --> 42:40.690] on the systems. And in the end, we're going to chain all of them together, guys. So [42:42.730 --> 42:48.010] Apache Solr service in the box, I mean, in the product was very old version, [42:48.010 --> 42:52.750] because it's not quite easy to upgrade your third party dependencies like Apache Solr or [42:52.750 --> 43:00.030] database servers. And in these type of solutions, it's quite hard to upgrade to newer versions. So [43:00.030 --> 43:08.170] that was a very, very old vulnerability in Apache Solr service, but it is exactly what I need. [43:08.170 --> 43:15.050] It is arbitrary file read vulnerability. So that is the name of the collection, [43:15.050 --> 43:21.090] and there is a replication endpoint. And the command has to be a file content. And you can [43:21.090 --> 43:27.810] traverse back to the roots folder, and then you can call whatever you want. And that will give [43:27.810 --> 43:36.370] you to reading any content of the file. So at the beginning, I wasn't, there was no way to [43:36.370 --> 43:41.530] communicate with the Apache Solr service, but we find a very interesting bug. And by exploiting [43:41.530 --> 43:50.790] that bug, we are going to read anything we want. So far, so good. I want you to remind the get [43:50.790 --> 43:58.690] token function. You know, it was like way behind of our presentation. Guys, all right. Do you [43:58.690 --> 44:05.590] remember that get token function? It is going to help us what we are going to achieve in here. [44:05.590 --> 44:17.650] Because, let me, yeah. Because that function takes cookies from the HTTP request, and it returns [44:17.650 --> 44:25.330] the value. But the problem is, it prints out the value and the name of the cookies. But the [44:25.330 --> 44:34.610] Java application is running by the Tomcat process. So those standard outputs data will be written [44:34.610 --> 44:42.930] into the log file, which is a Catalina.auth file. So due to that little function, all of those [44:42.930 --> 44:49.970] valid session IDs written into the log file, and we have arbitrary file read vulnerability. [44:50.330 --> 44:56.250] So what we are going to do that, we're going to exploit two vulnerabilities together in order [44:56.250 --> 45:02.750] to get the content of the Catalina.auth file, which contains the valid session IDs. And then [45:02.750 --> 45:09.170] we are going to collect all the session IDs together, and we can go to administrator [45:09.170 --> 45:17.050] interface in order to exploit command injection vulnerability with the active session IDs. So [45:17.490 --> 45:23.590] the idea is actually quite simple, guys. We are going to, in the first step, we are going to exploit [45:24.370 --> 45:30.290] a comparison bug in the proxy service, which helps us to communicate with the Apache [45:30.290 --> 45:38.230] solar service that is running within the product itself. And this is a very old software which has [45:38.430 --> 45:44.670] a vulnerability, and it is arbitrary file reads. And combination of that vulnerability, we are [45:44.670 --> 45:51.250] going to read Catalina.auth file. And we're going to, by using regex, we're going to extract all the [45:51.250 --> 45:57.430] session IDs that we have. And there is a check session endpoint. I haven't talked about it [45:57.430 --> 46:03.250] because it was quite easy. There is a check session endpoint in the product. We are going to [46:03.250 --> 46:09.770] test all the session IDs we have in order to find out whether it is still active or not. And if you [46:09.770 --> 46:17.910] find an active session, we are going to exploit the command injection vulnerability, and we are [46:17.910 --> 46:25.930] going to be executing operating system commands with a root privilege, which will give us a C2 [46:25.930 --> 46:34.550] reverse shellcr command and control server. That is the idea. And of course, I have implemented a [46:34.550 --> 46:41.530] metasplit module that performs all of those steps automatically. And I have a video for it. I would [46:41.530 --> 46:53.660] like to, I guess, yeah, time is good. I guess I still have a minute. So let's see. And by the way, [46:53.660 --> 47:00.240] that metasplit module has been merged to the master branch of the metasplit project. You are [47:00.240 --> 47:06.980] just, you know, can go and fetch the module and install the product on your lab and, you know, [47:06.980 --> 47:14.140] have fun. So when we run, as you can see in here, it's trying to, it exploits reverse process [47:14.140 --> 47:20.280] service and extract the katalina.out file. And that was, of course, this is a demonstration. [47:20.280 --> 47:25.900] There's only one session ID in the log file and it's inactive. And by using that session ID, [47:25.900 --> 47:31.460] it goes to the command injection vulnerability and it executes operating system command, [47:31.460 --> 47:36.820] which is a Perl command. Perl command contains a Python command, you know, and all of those steps [47:36.820 --> 47:44.940] have been automatically done. And as you can see in here, we have a root session on the back filter [47:44.940 --> 47:49.700] solution of the company, guys. That's it. Thank you very much.