Welcome back to insufficient logging and monitoring session
in this second part. We will exploit our
Target application. While analyzing its logging and
monitoring approach. We will jump straight to
our intentionally vulnerable application, and then move on to the mitigation
part in our broken authentication session. We
exploited our Target application, using a Brute Force
attack called, credential Staffing. We
will do the same, but now we will focus on what is logged
by our Target application and how it looks like.
Like while it is under attack to do that. We will access
to shop server running on a virtual machine. In our one
computer, using the terminal window in the top right corner
of the screen.
Just shop runs in a Docker container and logs are
kept locally to be able to inspect the logs. We have
to access the container itself to do. So, we
ran the pseudo Docker, exact Dash
it Joyce, that shop.
Slash bin, slash sh.
Inside the container, we can see a directory called locks
where log files are stored.
There are only access log files. Apparently,
there's no error logging at all. But we will discuss
it later in the mitigation part. Let's
see what is written to the log file, while the user performs authentication
in the web application. Let's type
tail dash, n 0, Dash,
F, followed by the name of the access log
file.
Now, let's use the login form to login as admin
using wrong password.
We've got three new entries, two of them to the /,
rest / user, / Omi and point. In
the third one, to the / rest slash user slash
login and point.
The log entry includes the user Source IP.
The request date and time the endpoint,
the URL from, where the request came
from.
And finally, the user agent.
We also have the HTTP response status code. In
this case, a 401 on access says, for
login. We should expect it to be a 200 status code. Now.
We will keep monitoring the access log and start the
credential stuffing attack in the terminal window at the bottom right
of the screen. Let's first clear, the screen
and monitor the access log file using the
same command.
To start the credential stuffing attack. We ran our
scripts, passing the admin, email address, and
a password list.
At first we have solved to Juice Shop challenges. We
have done it before on our broken authentication session. Let's
focus on the new entries in the log file. On
the top right terminal. We can
see several new entries in the log file.
All of them to the slash rest slash user slash
login and point with the 401 HTTP
response status code.
Suddenly, we have a 200 HTTP response,
status code to that same endpoint meaning
that we got the right user account password via our credential
stuffing attack. Clearly
logging does not include sufficient details. We
have several failed, login attempts with the 401 response
status code, but we don't know if several accounts
are being used or they are all targeting the same
account. What is the case?
Joyce shop does not include any monitoring or alerting attackers,
may use different Source. IP addresses, to perpetrate such
attacks and entries in the log file. May be
confused with regular activity. What we
have here is definitely insufficient monitoring. Next.
We will discuss what makes the application vulnerable and
how to prevent it.