WEBVTT 00:00:00.000 --> 00:00:06.280 align:middle line:90% 00:00:06.280 --> 00:00:09.820 align:middle line:84% Welcome back to Insufficient Logging and Monitoring session. 00:00:09.820 --> 00:00:12.910 align:middle line:84% In this second part, we will exploit our target application 00:00:12.910 --> 00:00:16.462 align:middle line:84% while analyzing its logging and monitoring approach. 00:00:16.462 --> 00:00:18.670 align:middle line:84% We will jump straight to our intentionally vulnerable 00:00:18.670 --> 00:00:21.970 align:middle line:84% application, and then move on to the mitigation part. 00:00:21.970 --> 00:00:23.770 align:middle line:84% In our broken authentication session, 00:00:23.770 --> 00:00:25.840 align:middle line:84% we exploited our target application 00:00:25.840 --> 00:00:29.440 align:middle line:84% using a brute force attack called Credential Stuffing. 00:00:29.440 --> 00:00:32.170 align:middle line:84% We will do the same, but now, we will focus on 00:00:32.170 --> 00:00:34.330 align:middle line:84% what is logged by our target application 00:00:34.330 --> 00:00:37.270 align:middle line:84% and how it looks like while it is under attack. 00:00:37.270 --> 00:00:40.510 align:middle line:84% To do that, we will access Juice Shop server, running 00:00:40.510 --> 00:00:42.760 align:middle line:84% on a virtual machine in our one computer, 00:00:42.760 --> 00:00:45.780 align:middle line:84% using the terminal window in the top right corner of the screen. 00:00:45.780 --> 00:01:03.630 align:middle line:90% 00:01:03.630 --> 00:01:06.660 align:middle line:84% Juice Shop runs in a Docker container and logs 00:01:06.660 --> 00:01:07.890 align:middle line:90% are kept locally. 00:01:07.890 --> 00:01:09.570 align:middle line:84% To be able to inspect the logs, we 00:01:09.570 --> 00:01:11.790 align:middle line:84% have to access the container itself. 00:01:11.790 --> 00:01:19.440 align:middle line:84% To do so, we ran the sudo docker exec -it juice-shop/bin/sh. 00:01:19.440 --> 00:01:25.880 align:middle line:90% 00:01:25.880 --> 00:01:29.330 align:middle line:84% Inside the container, we can see a directory called Logs, 00:01:29.330 --> 00:01:30.755 align:middle line:90% where log files are stored. 00:01:30.755 --> 00:01:37.320 align:middle line:90% 00:01:37.320 --> 00:01:39.620 align:middle line:90% There are only access log files. 00:01:39.620 --> 00:01:42.100 align:middle line:84% Apparently there is no effort logging at all, 00:01:42.100 --> 00:01:45.570 align:middle line:84% but we will discuss it later in the mitigation part. 00:01:45.570 --> 00:01:47.520 align:middle line:84% Let's see what is written to the log file 00:01:47.520 --> 00:01:49.800 align:middle line:84% while the user performs authentication in the web 00:01:49.800 --> 00:01:51.210 align:middle line:90% application. 00:01:51.210 --> 00:01:56.400 align:middle line:84% Let's type tail - n 0 - f, followed 00:01:56.400 --> 00:01:58.350 align:middle line:84% by the name of the access log file. 00:01:58.350 --> 00:02:01.130 align:middle line:90% 00:02:01.130 --> 00:02:03.980 align:middle line:84% Now let's use the login form to log in as admin 00:02:03.980 --> 00:02:05.480 align:middle line:90% using the wrong passwords. 00:02:05.480 --> 00:02:16.900 align:middle line:90% 00:02:16.900 --> 00:02:18.430 align:middle line:90% We've got three new entries. 00:02:18.430 --> 00:02:22.870 align:middle line:84% Two of them to the /rest/users/whoami endpoint, 00:02:22.870 --> 00:02:26.440 align:middle line:84% and the third one to the /rest/user/login endpoint. 00:02:26.440 --> 00:02:29.740 align:middle line:90% 00:02:29.740 --> 00:02:34.130 align:middle line:84% The log entry includes the user source IP, the request date 00:02:34.130 --> 00:02:38.090 align:middle line:84% and time, the end point, the URL from where 00:02:38.090 --> 00:02:42.815 align:middle line:84% the request came from, and finally, the user agent. 00:02:42.815 --> 00:02:46.540 align:middle line:90% 00:02:46.540 --> 00:02:50.560 align:middle line:84% We also have the HTTP response that is code, in this case 00:02:50.560 --> 00:02:51.280 align:middle line:90% the 401. 00:02:51.280 --> 00:02:54.010 align:middle line:84% On a successful login, we should expect 00:02:54.010 --> 00:02:56.780 align:middle line:90% it to be a 200 status code. 00:02:56.780 --> 00:02:59.660 align:middle line:84% Now we will keep monitoring the access log and start 00:02:59.660 --> 00:03:02.120 align:middle line:84% the credential stuffing attack the terminal window, 00:03:02.120 --> 00:03:04.730 align:middle line:84% at the bottom right of the screen. 00:03:04.730 --> 00:03:08.230 align:middle line:84% Let's first clear the screen and monitor the access log file 00:03:08.230 --> 00:03:11.220 align:middle line:90% using the same commands. 00:03:11.220 --> 00:03:13.110 align:middle line:84% To start the credential stuffing attack, 00:03:13.110 --> 00:03:16.800 align:middle line:84% we run our scripts, passing the admin, email address, 00:03:16.800 --> 00:03:18.270 align:middle line:90% and a password list. 00:03:18.270 --> 00:03:23.660 align:middle line:90% 00:03:23.660 --> 00:03:26.780 align:middle line:84% At first, we have solved two Juice Shop challenges. 00:03:26.780 --> 00:03:30.290 align:middle line:84% We have done it before on our broken authentication session. 00:03:30.290 --> 00:03:32.180 align:middle line:84% Let's focus on the new entries in the log 00:03:32.180 --> 00:03:35.340 align:middle line:90% file on the top right terminal. 00:03:35.340 --> 00:03:40.150 align:middle line:84% We can see several new entries in the log file, 00:03:40.150 --> 00:03:44.620 align:middle line:84% all of them to the /rest/user/login endpoint, 00:03:44.620 --> 00:03:47.440 align:middle line:84% with a 401 HTTP response status code. 00:03:47.440 --> 00:04:06.160 align:middle line:90% 00:04:06.160 --> 00:04:09.670 align:middle line:84% Suddenly, we have a 200 that should be a response status 00:04:09.670 --> 00:04:11.920 align:middle line:84% code to that same endpoint, meaning 00:04:11.920 --> 00:04:13.480 align:middle line:84% that we got the right user account 00:04:13.480 --> 00:04:17.610 align:middle line:84% password, via our credential stuffing attack. 00:04:17.610 --> 00:04:21.089 align:middle line:84% Clearly, logging does not include sufficient details. 00:04:21.089 --> 00:04:24.370 align:middle line:84% We have several failed login attempts with the 401 response 00:04:24.370 --> 00:04:27.240 align:middle line:84% status code, but we don't know if several accounts are 00:04:27.240 --> 00:04:30.540 align:middle line:84% being used or they are all targeting the same account. 00:04:30.540 --> 00:04:32.540 align:middle line:90% What is the case? 00:04:32.540 --> 00:04:35.900 align:middle line:84% Juice Shop does not include any monitoring or alerting. 00:04:35.900 --> 00:04:38.300 align:middle line:84% Attackers may use different source IP addresses 00:04:38.300 --> 00:04:40.010 align:middle line:90% to perpetrate such attacks. 00:04:40.010 --> 00:04:41.750 align:middle line:84% And entries in the log file may be 00:04:41.750 --> 00:04:44.270 align:middle line:90% confused with regular activity. 00:04:44.270 --> 00:04:48.440 align:middle line:84% What we have here is definitely insufficient monitoring. 00:04:48.440 --> 00:04:51.440 align:middle line:84% Next we will discuss what makes the application vulnerable 00:04:51.440 --> 00:04:54.040 align:middle line:90% and how to prevent it. 00:04:54.040 --> 00:04:56.000 align:middle line:90%