Defending Attacks Part 1: Password Cracking With Hydra and John The Ripper

    This is my first post in my series "Defending Attacks". In this series I will break down real world attacks, explaining how they occur, why they matter, and what you can do to protect yourself.

Some initial thoughts

    We like to think that we choose good passwords when we create new accounts. In some cases we choose passwords that are quite secure. In other cases we unfortunately do not. When it comes to password attacks the attacker has very little to lose, and a lot to gain. Poorly chosen passwords can lead to drastic outcomes such as an organization falling victim to ransomware, identity theft, and many other unpleasant situations. In this article I will cover what password attacks look like, distinguishing between a weak and strong password, as well as some additional defensive measures that can mitigate attacks.

 

What is a password attack?

    A password attack is as simple as it sounds. For this article we will assume the attacker already knows your login username and the only thing they need is your password. With this in mind a password attack is simply the process of an attacker testing many passwords in hopes that one of them is the correct one. Their end goal of course is to gain unauthorized access to your account and leverage this for some sort of malicious behavior.

    Now, while it's possible for an attacker to simply try typing in passwords manually, this is typically not the case. A common technique used by attackers is to use a large word list of known passwords (for instance see the common "rockyou.txt" linked here) along with an automated attack tool. An attacker could simply download this list, and test every password on the list with the known username of your account. More advanced password cracking including word list permutations will be covered later in the article.

 

Online vs Offline Cracking

    An important distinction between the types of password cracking is worth mentioning. If you imagine cracking someone's password you might think of writing a script to make an HTTP/HTTPS request to the desired server that loops through every (username, password) pair. This is what's called online password cracking because you are sending real time (online) requests to some server. Another form of cracking is known as offline password cracking. An example of "offline" cracking would be if an attacker has intercepted a hashed version of your password and they know the hashing function. Because they have this hash physically on their computer they don't need to make any requests to a server. In this case the attacker can write a script that loops through all possible passwords, hashing them with the appropriate function, and testing if the hashes match. There are other examples of offline cracking scenarios, but in general the idea is similar.

 

Case Study 1: John the Ripper

    A common tool used by attackers is "John the Ripper" (JtR) hosted here. There are many functions included with this tool, but the main two I would like to cover are:

             1) Word list permutations

             2) Offline cracking

    To explain why word list permutations matter let's imagine a company called "Company X". Let's also imagine that the password of each employee can be found on the already mentioned "rockyou.txt" word list. Suppose the CEO of the company, concerned about security, orders all employees to add some combination of 3 numbers and or symbols to their current password. So for example consider Bob has the password "flower123". Following his CEO's orders he might choose a new password such as "flower123$$1", "flower123#99", etc.

    While these new passwords for Bob are more secure, and in fact are not found on the "rockyou.txt" list, it would not be hard for an attacker to crack said password using JtR. Let's suppose Bob chooses "flower123$$1" as his new and improved password. And let's suppose an attacker has access to "rockyou.txt" as well as an intercepted SHA256 hash of this password which is "bd19086be36efcffef6af83dd6eca872eed76cf1717fa4c09c07bde4049d9121".

    Included in JtR is a configuration file. On my system it is located at /etc/john/john.conf and contains rules which allow for creating a word list that is a permutation of the original. The syntax of the configuration file is beyond the scope of this article, but a good tutorial can be found here. Using this configuration file I created the following rule:

To understand how this rule works consider a word list has one word "test" stored in a file called "wordlist.txt". A permutation of this word list could be generated as shown below:

 You can see that JtR takes in a word list "wordlist.txt", applies the rule I created, and creates a permutation of the original word list stored in "permutation_wordlist.txt". This permutation word contains the word test with all permutations of 3 letters and or symbols as shown by the output of the head and tail commands above.

Now, for perspective, the size of the "rockyou.txt" word list is 134MB in size:

 My original "wordlist.txt" was 4B in size and "permutation_wordlist" was 539KB in size.

    Doing some basic math in your head you can see that applying this rule to the "rockyou.txt" file would create a massive file on the computer. This brings up why JtR is good at offline password cracking. Rather than create an entirely new file, JtR can create each permutation on the fly. What I mean by this is it can loop through "rockyou.txt" and its associated permutations without creating a new file. For example, the following command takes in a word list, a rule, a hash function, a hash to crack, and uses 12 threads to do so:

(Under the hood JtR is testing all passwords found in "rockyou.txt" as well as all permutations of those passwords using the rule described above)

 As I write this article the date is 2022-11-17. So you can see that it will take about 2 days for John to crack this password. While this may seem like a long time, consider the motivation for the attacker. If Bob is a senior member of the company, breaking into his account could lead to sever consequences.

So although the CEO's recommendation slowed down the attacker, a smart attacker knows the wait is worth it and will likely wait the two days.

Just to show the full completion of the hash being cracked, below is an example using a much smaller (and fine tuned) word list that succeeds:

 

This is what the attacker would see once they waited the two days. At which point they could use the password to sign in as Bob.

An important note: It is worth mentioning that obtaining a password hash is not as simple as snapping your fingers. Even with tools like Wireshark, most communications are encrypted using HTTPS or some other secure protocol and so dissecting the hash from within this is not an easy task. However some possible scenarios where a password hash could be found are insecure public facing databases (where there is no password or only default credentials), hashes being sent over an unencrypted channel like HTTP (Wireshark would work here), or unauthorized local/remote access to an employee computer and therefore local password files (in this case there is likely a bigger issue at hand). Point being is that password hashes are not easy to directly intercept, though it can and does happen in the real world.

Case Study 2: Hydra

    Since I already discussed word lists and permutations of them in the above case study I will not discuss them here. What I would like to highlight specific t o Hydra is its aptitude for online password cracking. Hydra can attack many different protocols such as HTTP/HTTPS, FTP, SSH, and many others.

    As a simple example I have setup an FTP server on my local machine. This FTP server has a user "honeypot" with password "honeypot". Assuming I have a word list containing this password, along with the username, and IP address of the FTP server, breaking into this service is as simple as the command below:

(Under the hood, hydra is making a request to the ftp server hosted on the IP address, brute forcing username and password pairs, looking for a successful login response. Hydra is able to detect successful logins for many different protocols)

    While this example is trivial the concepts can be applied to a more severe scenario. Revisiting our imaginary company, "Company X", assume the CEO setup an SSH service for his employees. Assume he set it up on the same computer hosting their databases, so they remotely make changes when necessary. However, this SSH service does not lock users out when they enter the wrong password too many times. Assuming you have the IP address of the computer running the SSH service, and assuming Bob is a user on this machine, gaining access would be as simple as the following one line command:

hydra -l Bob -P {WordlistWithBobPassword.txt} {IP Address} ssh

For a more detailed look at Hydra please see here.

Bigger Picture and Defensive Measures You Can Take

    The bigger point I hoped to have highlighted with this post is that secure passwords are a serious matter. One weak password in an organization can effect everyone. With that being said, there are steps you can take to help improve password security at your organization including:

• Create longer passwords, apply variations in capitalization, add random numbers/letters/symbols to the beginning, middle, and end of your passwords. Many word lists are based on common normally spelled words such as names, sports, music, etc. For example changing the password "basketball" to "#!ba$Ketb4LeL%3" makes the password immediately more secure. The password is longer, has clever variations, and contains random insertions throughout. These features increase the total attack time, and increase the complexity of a successful attack which means less attackers are likely to succeed.
• For websites, and easy way to get a secure password is to use the suggested strong passwords provided by your web browser. These passwords apply best practices, and are offered by your web browser when you create new accounts. 
• A follow up to the previous point, do not reuse passwords. Creating strong passwords means they are harder to remember, and may tempt you to reuse passwords across sites. This however is a bad defensive mistake, because losing a password that you use everywhere, means an attacker gains access everywhere. Instead consider using a password manager like 1Password, or the password manager implemented by Google Chrome.
  
• Enable two factor authentication whenever possible. Whether it's through a text, email, or app on your phone, two factor authentication would have completely prevented both of the case study attacks above!
• A final security measure is to only use services that implement good security. If your organization offers RDP but doesn't lock users out after a certain number of login attempts do not use it! If a website is only using HTTP don't use it! Overall we can't always know the specific details of a service, but in general use good judgement, and never share your passwords with a service using questionable security practices.