WEBVTT 00:00:00.000 --> 00:00:06.110 align:middle line:90% 00:00:06.110 --> 00:00:09.470 align:middle line:84% Welcome back to Insecure Deserialization session. 00:00:09.470 --> 00:00:11.420 align:middle line:84% In this second part, we will exploit 00:00:11.420 --> 00:00:15.390 align:middle line:84% insecure deserialization in our target application. 00:00:15.390 --> 00:00:17.840 align:middle line:84% We will jump straight to our intentionally vulnerable 00:00:17.840 --> 00:00:21.170 align:middle line:84% application and then move on to the mitigation part. 00:00:21.170 --> 00:00:24.890 align:middle line:84% We are about to exploit insecure deserialization in our target 00:00:24.890 --> 00:00:26.810 align:middle line:84% intentionally vulnerable application, 00:00:26.810 --> 00:00:29.250 align:middle line:84% and we will do it in a specific address-- 00:00:29.250 --> 00:00:29.750 align:middle line:90% api-docs. 00:00:29.750 --> 00:00:38.820 align:middle line:90% 00:00:38.820 --> 00:00:40.830 align:middle line:84% This is a common API address where 00:00:40.830 --> 00:00:42.750 align:middle line:90% Swagger is made available. 00:00:42.750 --> 00:00:46.380 align:middle line:84% To find common addresses, you can use specific word lists. 00:00:46.380 --> 00:00:48.510 align:middle line:84% There are plenty of them available as well as 00:00:48.510 --> 00:00:51.360 align:middle line:84% several tools to run through their entries. 00:00:51.360 --> 00:00:53.820 align:middle line:84% Swagger is an open source software framework 00:00:53.820 --> 00:00:55.950 align:middle line:84% backed by a large ecosystem of tools 00:00:55.950 --> 00:00:59.220 align:middle line:84% that helps developers design, build, document, 00:00:59.220 --> 00:01:02.540 align:middle line:84% and consume RESTful web services. 00:01:02.540 --> 00:01:05.180 align:middle line:84% What we have here is the Swagger UI, 00:01:05.180 --> 00:01:09.500 align:middle line:84% which provides documentation of available API methods, what's 00:01:09.500 --> 00:01:12.740 align:middle line:84% expected as request payloads, and possible responses. 00:01:12.740 --> 00:01:25.940 align:middle line:90% 00:01:25.940 --> 00:01:29.060 align:middle line:84% This tool also allows us to test the API 00:01:29.060 --> 00:01:32.440 align:middle line:84% issuing requests and watching responses data in place. 00:01:32.440 --> 00:01:55.830 align:middle line:90% 00:01:55.830 --> 00:01:58.650 align:middle line:84% We will need an account to test API. 00:01:58.650 --> 00:02:01.140 align:middle line:84% We will create one and grab the authorization token 00:02:01.140 --> 00:02:02.760 align:middle line:90% to provide it to Swagger UI. 00:02:02.760 --> 00:02:10.800 align:middle line:90% 00:02:10.800 --> 00:02:12.720 align:middle line:84% We can now pick the authorization token 00:02:12.720 --> 00:02:14.790 align:middle line:84% from the browser's local storage. 00:02:14.790 --> 00:02:17.850 align:middle line:84% It is just a matter of copy and paste into Swagger UI. 00:02:17.850 --> 00:02:50.310 align:middle line:90% 00:02:50.310 --> 00:02:52.840 align:middle line:84% We should now be able to successfully execute 00:02:52.840 --> 00:02:53.865 align:middle line:90% the example request. 00:02:53.865 --> 00:03:09.160 align:middle line:90% 00:03:09.160 --> 00:03:11.800 align:middle line:84% Let's have a closer look at the example request payload. 00:03:11.800 --> 00:03:30.570 align:middle line:90% 00:03:30.570 --> 00:03:34.470 align:middle line:84% orderLines and orderLinesData properties are quite similar, 00:03:34.470 --> 00:03:38.670 align:middle line:84% but while the former is a JSON array, the latter is a string. 00:03:38.670 --> 00:03:44.170 align:middle line:84% In fact, the latter looks to be a JSON stringified array. 00:03:44.170 --> 00:03:46.690 align:middle line:84% We can check request data schema's documentation 00:03:46.690 --> 00:03:48.040 align:middle line:90% provided by Swagger UI. 00:03:48.040 --> 00:04:19.100 align:middle line:90% 00:04:19.100 --> 00:04:21.769 align:middle line:84% Regarding orderLinesData property, 00:04:21.769 --> 00:04:25.190 align:middle line:84% it says it is a customer specific JSON format. 00:04:25.190 --> 00:04:27.200 align:middle line:84% Let's change the request and see what 00:04:27.200 --> 00:04:30.230 align:middle line:84% happens when we send a malformed orderLinesData property. 00:04:30.230 --> 00:04:49.500 align:middle line:90% 00:04:49.500 --> 00:04:53.080 align:middle line:84% This time, we got a 500 internal server error response, 00:04:53.080 --> 00:04:55.380 align:middle line:84% and the response body includes a lot of details, 00:04:55.380 --> 00:04:58.665 align:middle line:84% such as a stack trace, commonly leaked on unhandled errors. 00:04:58.665 --> 00:05:08.150 align:middle line:90% 00:05:08.150 --> 00:05:10.880 align:middle line:84% The message says a is not defined. 00:05:10.880 --> 00:05:14.030 align:middle line:84% What sounds that API server was looking for a variable 00:05:14.030 --> 00:05:17.240 align:middle line:84% called a, meaning that the property value was 00:05:17.240 --> 00:05:19.940 align:middle line:90% executed as JavaScript. 00:05:19.940 --> 00:05:22.520 align:middle line:84% The stack trace shows that the error was thrown 00:05:22.520 --> 00:05:24.890 align:middle line:90% by the NotEvil node package. 00:05:24.890 --> 00:05:27.100 align:middle line:90% Let's check its documentation. 00:05:27.100 --> 00:05:51.600 align:middle line:90% 00:05:51.600 --> 00:05:54.240 align:middle line:84% In fact, based on NotEvil documentation, 00:05:54.240 --> 00:05:57.960 align:middle line:84% orderLinesData property is evaluated as JavaScript. 00:05:57.960 --> 00:06:00.090 align:middle line:84% It doesn't sound right, but it might 00:06:00.090 --> 00:06:01.980 align:middle line:84% have been used to convert the string back 00:06:01.980 --> 00:06:05.250 align:middle line:90% to array for some reason. 00:06:05.250 --> 00:06:07.910 align:middle line:84% Not only we have found an insecure deserialization, 00:06:07.910 --> 00:06:10.510 align:middle line:84% but also a remote code execution issue. 00:06:10.510 --> 00:06:17.380 align:middle line:90% 00:06:17.380 --> 00:06:20.650 align:middle line:84% Let's change our request and try some valid JavaScripts. 00:06:20.650 --> 00:06:31.930 align:middle line:90% 00:06:31.930 --> 00:06:34.930 align:middle line:84% We've got a successful HTTP response. 00:06:34.930 --> 00:06:37.930 align:middle line:84% We can now try to crash the server with an infinite loop. 00:06:37.930 --> 00:07:00.550 align:middle line:90% 00:07:00.550 --> 00:07:03.940 align:middle line:84% This time, we've got an internal server error response. 00:07:03.940 --> 00:07:08.590 align:middle line:84% Our infinite loop was detected and max iterations reached. 00:07:08.590 --> 00:07:11.500 align:middle line:84% This would have been enough to cause a denial of service 00:07:11.500 --> 00:07:14.850 align:middle line:84% if there was no protection in place. 00:07:14.850 --> 00:07:18.240 align:middle line:84% Next, we will discuss what makes the application vulnerable 00:07:18.240 --> 00:07:20.840 align:middle line:90% and how to prevent it. 00:07:20.840 --> 00:07:22.000 align:middle line:90%