You are a good target for a brute- force Attack
Introduction
One of the most common threats web developers face is brute force attacks. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works.
If your web site requires user authentication, you are a good target.
A good thing website administrators do is to increase possible combinations for user passwords, this can depend on the password’s length and complexity, make it alot more complex to crack.
How this attack can happen.
Imagine yourself are the attacker. You visit a website and observe that your credentials upon logging in are being sent in plain text. This is achieved by tunnelling traffic (simply means, passing your traffic over a connection to monitor what information you send and receive) using a proxy, for example, Burp Suite Proxy(a man in the middle communicating with your browser and the server on your behalf).
On this website, you have to create an account and log in to your profile. Sending this information, you discovered that all your login credentials are sent in clear text (see example below):
This situation already tells the attacker two things, Their credentials might be stored in plain text in the database (calamity) and the website would be vulnerable to other attacks now back to brute force.
The attacker can then visit the target page on Linkedin, get the name and possibly email address of an employee of this target website company and enter that email with any fake password into the login page, they then intercept this traffic on burp by sending a copy of the request as shown to the intruder tab. At this point, the attacker can use a dictionary attack to guess the passwords of the victim. This is where it gets serious, if the website allows an unlimited number of password trials, then the attacker would keep guessing the password until it works.
How can this be mitigated?
Indeed web developers can implement simple practices to mitigate this against these attacks.
1. Account Lockout procedures: What every web admin would think of is to block multiple password attempts from users this is called an Account Lockout. Account lockouts can last a specific duration, for example, one hour, or the accounts could remain locked until manually unlocked by an administrator. This is logical but here is a problem, with that because someone could easily abuse the security measure and lockout hundreds of user accounts. Some Web sites experience so many attacks that they are unable to enforce a lockout policy because they would constantly be unlocking customer accounts.
Locking accounts can cause the following problems:
- DDoS attacks— when hundreds of accounts are locked, it could cause a denial of service as they are constantly trying to gain access back into their accounts and the organization may not want to invest the manpower in constantly unlocking users accounts. Just not productive
- Locking user accounts is Jackpot for the attacker as only existing email accounts can be locked hence the attacker can harvest these emails and perform phishing or other social engineering attacks on these individuals
- An attacker who has the whole time to play could just keep locking every unlocked user account and that would not be a good use of the software administrators time.
- A locked account would not work if the attacker is performing a cluster bomb attack, that is trying out different usernames and passwords or if the attacker is performing a very slow attack that is texting a new password after ever hour or a specified number for hours.
- Powerful accounts such as administrator accounts often bypass lockout policy, but these are the most desirable accounts to attack. Some systems lockout administrator accounts only on network-based logins
I am not saying that account lockout is bad, not it is effective in a controlled situation or if the user data compromise is much more sensitive and overrides the DDos attack effects.
2. Cookie Authentication: Another way to prevent this is to use cookies to block authentication attempts from the known and unknown browser or devices.
3. Random Delay: You could inject random pauses (delays) that would not slow a user down but would slow a computer time programmed attack.
Example of a simple password authentication delay:
private void AuthenticateRequest(object obj, EventArgs ea)
{
HttpApplication objApp = (HttpApplication) obj;
HttpContext objContext = (HttpContext) objApp.Context;
// If user identity is not blank, pause for a random amount of time
if ( objApp.User.Identity.Name != “”)
{
Random rand = new Random();
Thread.Sleep(rand.Next(minSeconds, maxSeconds) * 1000);
}
}
Other techniques you might want to consider are:
- For advanced users who want to protect their accounts from attack, give them the option to allow login only from certain IP addresses.
- Assign unique login URLs to blocks of users so that not all users can access the site from the same URL.
- Use a CAPTCHA ( a program that allows you to distinguish between humans and computers)to prevent automated attacks
- Instead of completely locking out an account, place it in a lockdown mode with limited capabilities.
Detecting these attacks
Although brute-force attacks are difficult to stop completely, they are easy to detect because each failed login attempt records an HTTP 401 status code in your Web server logs. It is important to monitor your log files for brute-force attacks — in particular, the intermingled 200 status codes that mean the attacker found a valid password.
Here are conditions that could indicate a brute-force attack or other account abuse:
- Many failed logins from the same IP address
- Logins with multiple usernames from the same IP address
- Logins for a single account coming from many different IP addresses
- Excessive usage and bandwidth consumption from a single-use
- Failed login attempts from alphabetically sequential usernames or passwords
- Logins with a referring URL of someone’s mail or IRC client
- Referring URLs that contain the username and password in the format <http://user:password@www.example.com/login.htm>
- If protecting an adult Web site, referring URLs of known password-sharing sites
- Logins with suspicious passwords hackers commonly use, such as ownsyou (ownzyou), washere (wazhere), zealots, hacksyou, and the likes.
Examples of brute force attacks
Brute force attacks take place all of the time and there are many high profile examples to speak of. We likely don’t even know about many bygone and ongoing attacks, but here are a few that have come to light in recent years:
- Alibaba: A massive 2016 brute force attack on the popular eCommerce site affected millions of accounts.
- Magento: In March 2018, Magento had to warn users that up to 1,000 admin panels had been compromised as a result of brute force attacks.
- Northern Irish Parliament: Also in March 2018, the accounts of several members of the Northern Irish Parliament were accessed by brute force attackers.
- Westminster Parliament: An earlier attack hit Westminster Parliament in 2017 where up to 90 email accounts were compromised.
- Firefox: It was revealed early in 2018 that Firefox’s ‘master password’ feature can be easily brute-force attacked. This means that over the past nine years, many users’ credentials may have been exposed.
Conclusion
A lot of accounts has been compromised because passwords were sent in plain text. Web developers are in constant haste to meet up with deadlines hence pushed a very perfect working app that may be susceptible to potential security flaws. It is a very common issue and still exists to this day.
The best defence is to make sure that users follow basic rules for strong passwords these include:
- Use long unpredictable passwords
- Avoid dictionary words
- Avoid reusing passwords
- Change passwords regularly.
This is common to a lot of companies especially in Africa, We face two major problems.
- Cybersecurity is still a very new concept and has not been widely adopted by companies
- When you report these issues, the company may file a legal action against you which could land you in a lot of trouble tho your intention was purely to help.
References:
https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/
https://www.comparitech.com/blog/information-security/brute-force-attack/
