WEBVTT - This file was automatically generated by VIMEO 1 00:00:00.800 --> 00:00:03.600 Welcome back to insufficient logging and monitoring session 2 00:00:03.400 --> 00:00:06.300 in this second part. We will exploit our 3 00:00:06.300 --> 00:00:09.200 Target application. While analyzing its logging and 4 00:00:09.200 --> 00:00:12.100 monitoring approach. We will jump straight to 5 00:00:12.100 --> 00:00:15.600 our intentionally vulnerable application, and then move on to the mitigation 6 00:00:15.600 --> 00:00:18.500 part in our broken authentication session. We 7 00:00:18.500 --> 00:00:21.200 exploited our Target application, using a Brute Force 8 00:00:21.200 --> 00:00:24.100 attack called, credential Staffing. We 9 00:00:24.100 --> 00:00:27.300 will do the same, but now we will focus on what is logged 10 00:00:27.300 --> 00:00:29.800 by our Target application and how it looks like. 11 00:00:30.100 --> 00:00:33.500 Like while it is under attack to do that. We will access 12 00:00:33.500 --> 00:00:36.300 to shop server running on a virtual machine. In our one 13 00:00:36.300 --> 00:00:39.600 computer, using the terminal window in the top right corner 14 00:00:39.600 --> 00:00:40.300 of the screen. 15 00:00:58.200 --> 00:01:01.400 Just shop runs in a Docker container and logs are 16 00:01:01.400 --> 00:01:04.200 kept locally to be able to inspect the logs. We have 17 00:01:04.200 --> 00:01:07.400 to access the container itself to do. So, we 18 00:01:07.400 --> 00:01:11.300 ran the pseudo Docker, exact Dash 19 00:01:11.300 --> 00:01:14.400 it Joyce, that shop. 20 00:01:15.800 --> 00:01:17.900 Slash bin, slash sh. 21 00:01:20.400 --> 00:01:23.900 Inside the container, we can see a directory called locks 22 00:01:23.900 --> 00:01:25.600 where log files are stored. 23 00:01:31.900 --> 00:01:34.800 There are only access log files. Apparently, 24 00:01:34.800 --> 00:01:37.400 there's no error logging at all. But we will discuss 25 00:01:37.400 --> 00:01:40.300 it later in the mitigation part. Let's 26 00:01:40.300 --> 00:01:43.800 see what is written to the log file, while the user performs authentication 27 00:01:43.800 --> 00:01:46.500 in the web application. Let's type 28 00:01:46.600 --> 00:01:49.700 tail dash, n 0, Dash, 29 00:01:49.700 --> 00:01:52.400 F, followed by the name of the access log 30 00:01:52.400 --> 00:01:52.900 file. 31 00:01:55.600 --> 00:01:58.500 Now, let's use the login form to login as admin 32 00:01:58.500 --> 00:02:00.000 using wrong password. 33 00:02:11.400 --> 00:02:14.500 We've got three new entries, two of them to the /, 34 00:02:14.500 --> 00:02:17.500 rest / user, / Omi and point. In 35 00:02:17.500 --> 00:02:20.400 the third one, to the / rest slash user slash 36 00:02:20.400 --> 00:02:21.500 login and point. 37 00:02:24.300 --> 00:02:26.500 The log entry includes the user Source IP. 38 00:02:27.800 --> 00:02:30.900 The request date and time the endpoint, 39 00:02:30.400 --> 00:02:33.400 the URL from, where the request came 40 00:02:33.400 --> 00:02:34.000 from. 41 00:02:35.700 --> 00:02:37.700 And finally, the user agent. 42 00:02:41.100 --> 00:02:44.300 We also have the HTTP response status code. In 43 00:02:44.300 --> 00:02:47.100 this case, a 401 on access says, for 44 00:02:47.100 --> 00:02:51.800 login. We should expect it to be a 200 status code. Now. 45 00:02:51.800 --> 00:02:54.200 We will keep monitoring the access log and start the 46 00:02:54.200 --> 00:02:57.600 credential stuffing attack in the terminal window at the bottom right 47 00:02:57.600 --> 00:03:00.500 of the screen. Let's first clear, the screen 48 00:03:00.600 --> 00:03:03.200 and monitor the access log file using the 49 00:03:03.200 --> 00:03:04.100 same command. 50 00:03:05.700 --> 00:03:08.400 To start the credential stuffing attack. We ran our 51 00:03:08.400 --> 00:03:11.700 scripts, passing the admin, email address, and 52 00:03:11.700 --> 00:03:12.800 a password list. 53 00:03:18.300 --> 00:03:21.500 At first we have solved to Juice Shop challenges. We 54 00:03:21.500 --> 00:03:25.100 have done it before on our broken authentication session. Let's 55 00:03:24.100 --> 00:03:27.200 focus on the new entries in the log file. On 56 00:03:27.200 --> 00:03:30.200 the top right terminal. We can 57 00:03:30.200 --> 00:03:32.400 see several new entries in the log file. 58 00:03:34.700 --> 00:03:37.700 All of them to the slash rest slash user slash 59 00:03:37.700 --> 00:03:40.600 login and point with the 401 HTTP 60 00:03:40.600 --> 00:03:42.000 response status code. 61 00:04:00.800 --> 00:04:03.700 Suddenly, we have a 200 HTTP response, 62 00:04:03.700 --> 00:04:06.400 status code to that same endpoint meaning 63 00:04:06.400 --> 00:04:09.700 that we got the right user account password via our credential 64 00:04:09.700 --> 00:04:12.800 stuffing attack. Clearly 65 00:04:12.900 --> 00:04:15.800 logging does not include sufficient details. We 66 00:04:15.800 --> 00:04:18.700 have several failed, login attempts with the 401 response 67 00:04:18.700 --> 00:04:21.600 status code, but we don't know if several accounts 68 00:04:21.600 --> 00:04:24.200 are being used or they are all targeting the same 69 00:04:24.200 --> 00:04:26.000 account. What is the case? 70 00:04:27.300 --> 00:04:31.000 Joyce shop does not include any monitoring or alerting attackers, 71 00:04:30.100 --> 00:04:33.700 may use different Source. IP addresses, to perpetrate such 72 00:04:33.700 --> 00:04:36.200 attacks and entries in the log file. May be 73 00:04:36.200 --> 00:04:39.200 confused with regular activity. What we 74 00:04:39.200 --> 00:04:43.600 have here is definitely insufficient monitoring. Next. 75 00:04:43.600 --> 00:04:46.200 We will discuss what makes the application vulnerable and 76 00:04:46.200 --> 00:04:47.300 how to prevent it.