Monday, January 2, 2017

Brute Forcing Web Authentication - Detection

In the previous post, we looked at performing a brute force attack against authentication. So let's take a second to see how this can be detected.

The reality is, this can be either easy or difficult to detect, based on your environment's configuration. If your environment has no logging enabled, then you should stop reading, as this post will do you no good. However, even for those environments that have logging enabled, they may only be logging successful or failed attempts and not both. If you really want to benefit from this post, then your environment should be logging both successful and failed attempts. Let's look at the events from the previous post to get a better understanding of why.

Before moving on, it is important to note that these authentication requests are being made via a "POST" method, as a result you should not expect on a regular day to see these entries in your web server logs. Below shows an example of logs from the web server:

------------------- - - [05/Nov/2016:12:56:42 -0500] "POST /mut/index.php?page=login.php HTTP/1.1" 200 53225 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" - - [05/Nov/2016:12:56:42 -0500] "POST /mut/index.php?page=login.php HTTP/1.1" 200 53225 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" - - [05/Nov/2016:12:56:43 -0500] "POST /mut/index.php?page=login.php HTTP/1.1" 200 53225 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0 - - [05/Nov/2016:12:56:44 -0500] "POST /mut/index.php?page=login.php HTTP/1.1" 200 53225 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0" - - [05/Nov/2016:12:56:45 -0500] "POST /mut/index.php?page=login.php HTTP/1.1" 200 53225 "" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0"


So if information is not in the web server logs, where are we getting it from? Well in this case we have to get it from the authentication system or some other system that allows us to retrieve those logs. From our perspective we will look at the logs from Mutillidae's system. Below is a snapshot.

From the above we see an example of a username not existing. Unless an attacker has successfully enumerated all the usernames within your environment, there will be occasions that you will see this as part of a brute force attempt. Looking at the time, we see in come cases the time is practically the same down to the second.

Let's perform some additional analysis on the full log.

Total unique source IPs attacking us?

sansforensics@securitynik:~$ cat mutillidae-logs.txt | cut --fields 1 | sort | uniq --count | sort --numeric --reverse | more

From the above it looks like there were 188 attempts from one source IP. This should be an immediate cause for concern.

What type of computer is the person attacking us from?

sansforensics@securitynik:~$ cat mutillidae-logs.txt | cut --fields 3 | sort | uniq --count | sort --numeric --reverse | more

From the above we can conclude that all of these attacks came from a system running Windows 10 and the user is running Firefox. Note, we are trying to draw our conclusions based on the "User-Agent" string. However, this value can be easily forged. However, let's assume it is not.

Learning a bit more about the access attempts.

sansforensics@securitynik:~$ cat mutillidae-logs.txt | cut --fields 4 | sort | uniq --count | sort --numeric --reverse | more

From above we get a better insight into to what transpired.

Let's draw some conclusions.
- There were 62 attempts (from various users, etc) to access "login.php"
- User "securitynik" attempted to authenticate 14 different times. More than likely with different passwords. However, the account "securitynik" does not exist.
- Similarly user "sa", "nik", "guest" and "tes" do not exist. There were 11 failed attempts for these accounts.
- It also looks like user "admin" had "10" failed attempts.
- "admin" also had 3 successful logins

Let's take a final look at what transpired with "admin"

Looking at the date and times these access attempts were made we see the following.

sansforensics@securitynik:~$ cat mutillidae-logs.txt | grep --perl-regexp "User\sadmin" | awk --field-separator " " '{ print $17 " " $18 }'

We see that these attempts were made on November 5, 2016 between 12:56:40 and 13:51:54. Looking at the information we can draw some possible conclusions. It looks like there was one activity that lasted from 12:56:40 to 12:58:29 for a duration of 1 minute+. Another attempt was seen at 13:40:05 and another at 13:51:54.

Looking for the successful attempt

sansforensics@securitynik:~$ cat mutillidae-logs.txt | grep admin | grep Succeeded | awk --field-separator " " '{ print $12 " -> " $13 " -> " $17 " -> " $19 " " $20 }'

So  what can we do to help make this a bit more difficult for the potential attacker?
- For starters we should have a lockout policy. This allows the targeted account to be placed in a "disabled" state after a certain amount of failed tries and for a specific period. This is not bulletproof but can definitely slow down your attackers.
- Ensure you are logging both failed and successful authentication attempts. Being able to detect the reconnaissance is just as important as detecting the successful authentication attempt.

Good luck with your environment's logging. See my "building a forensically capable network infrastructure" for more guidance.

No comments:

Post a Comment