Anatomy of the Dark Side
If you run a service with authentication, your servers will be targeted with brute force attempts. There are a couple of interesting attacks here that we will explain, and cover controls for including
Standard Brute Force,
Wordlists,
Targeted Wordlists and
Credential Stuffing.
Brute Force and Password Entropy
An actual brute force attack involves iteratively/repetitively generating possible passwords. Think ‘A’, ‘B’, … ‘AA’, ‘AB’, … and so on. This kind of attack is unlikely to occur over network due to the number of attempts expected to succeed. Although, theoretically, this could ultimately break any password, the network is too slow to try this. For instance, a week password of just 5 characters would like ~(95)^5 about 7 Billion passwords. Trying passwords randomly, we expect a 50% chance of success after covering 50% the space or 3.5 Billion. At 10 passwords per second this would take 4,000 years. This tactic simply isn’t viable. Traditional brute forcing is used mostly for offline password cracking where millions of attempts per second can be had.
To deal with this problem of limited numbers of guesses, attackers must control the passwords they want to guess out of the “keyspace”. This is a good tactic because humans don’t generally choose random passwords. Some are far more likely than others.
Wordlists : Controlling the Keyspace
Mostly commonly, untargeted attacks with try commonly used and default credentials to computers or services using specially designed programs. Think (admin/password), (rot/toor) combinations. These combinations are placed on a list called a “Wordlist”. This kind of attack is as old as passwords, and used in the movie the 1995 movie “Hackers”. As sad as it is, attackers do this because it works, and your server will be a target. If you are reading this, this attack is unlikely to succeed against your admin accounts, but it can still clutter logs, waste disk space, network bandwidth, and processor power, and you may have users.
Targeted Attacks with Custom Wordlists
A more targeted attack might use a wordlist customized to your footprint by taking into account content you have posted (wordhound), a website (ceWL) or other details about likely account usernames and passwords from (OSINT), and / or by clever construction of possible possible passwords with rules (hashcat), or prince attack to align with ways users, including possibly you, generate passwords. You are much less likely to be a victim of this kind of attack, if only, because the targeting requires more effort.
Credential Stuffing with Breach Data
Finally, attackers may use “Breach Data” - data taken from other, less protected services, and attempt to reuse credentials. This is an attacker obtaining passwords you or your uses might be likely to use on your service, by leveraging a list of passwords that you or your users have used on other services which have been broken into. This technique assumes password reuse. This technique is likely to be of little value for an admin account on a server (although it might work!), but increases in value as the number of users increases.
An Overview of Defense
Passwordless Authentication : More Entropy
The number one best defense you can have against password brute forcing is simply not having passwords. If your service supports alternative authentication methods USE THEM. For instance, SSH , which this article was written with in mind, and is most commonly brute forced, supports Public-Key Authentication. Choosing an SSH key gives you 256 to 512 bits of real entropy from the signature used to authenticate you, equivalent to an actually random 38 character password whereas humans choose passwords that appear on wordlists with far higher frequency due to requirement to memorize. Don’t use passwords. SSH, and many other UNIX services support a wide variety of authentication methods through PAM (Pluggable Authentication Modules).
Compensating Controls for Passwords if you must
If you must use password, consider compensating controls like 2 Factor Authentication where more than simply guessing a password is required. You can also make passwords harder to guess by enforcing password complexity requirements. However, you should be aware that password complexity requirements usually result in users writing down passwords - which may not be undesirable.
Don’t Use Common Usernames
An important thing to consider, is does your username actually have to be public. Although usernames are not passwords, they do represent 50% of authentication information, and by refusing to use commonly used accounts, you can deny low-skill attackers/ untargeted attacks the ability to even get started. Don’t enable root login via ssh. Don’t use the username admin.
Monitoring Breach Data
If you have users, as it is unlikely the reader of this does, given the nature of where this is published, consider monitoring for breach data. If you have users, there is a very reasonable chance that they are reusing passwords. Force users to reset passwords after a breach occurs weather the password is an exact match or not; Any information on a users password allows refining the keyspace. Monitoring for breach data can is an OSINT discipline.
Reducing Attempts instead of Entropy
All of the above defenses, passwordless authentication, not using commonly used usernames, 2 Factor Authentication[1] and password complexity, try to make the keyspace larger by adding additional entropy. 2 Factor Authentication is famously difficult to implement at scale, password complexity policies frustrate users, Breach Monitoring is labour intensive. Another type of control focuses limiting the ability to attempt authentication: IP Blacklisting and account lockouts. By limiting the number of attempts a party can make, we can make even low entropy authentication methods impossible to brute force. Imagine trying to guess a 5 digit password with three attempts per day. Although this cannot prevent default credentials from working on the first attempt, it can limit an attackers ability to explore the keyspace in any real way at all. Either you have the password, or you don’t get in. This can be effected by locking users out of their accounts, which predictably results in angry users, and support costs OR by limiting the number of attempts at the IP level.
Comments
Post a Comment