As part of my current focus on Appsec I wanted to explore various security areas that either had common issues or I found interesting to research and write about.
I thought I would start with your everyday Username and Password functionality as:
- Almost every application or service has some form of this. Even my young kids know how this system works as they attempt to shoulder surf my iPad password and gain access to unlimited Peppa Pig access
- It’s arguably the weakest point of a system (excluding some form of manipulation/social engineering) and also the one that can provide the most value to an attacker
- There’s some easy to implement defences that can make an attackers job much, much harder
Where did usernames and passwords come from?
It seems very likely that some form of secret phrase or sign has been used since ancient times as a form of authentication and there’s records of various code systems reliant on a passphrase or secret knowledge being used in ancient times.
The computer based username/password system we’re all familiar with was invented in the early 1960’s by Dr Corbato at MIT who was developing an operating system called the Compatible Time Sharing System or CTSS to its friends.
At the time computers supported just a single concurrent user and the good doctor was developing a way to divide up the processing power of a computer allowing more people to make use of its resources.
Usernames/Passwords were introduced as a solution to hide away files and folders from other users accessing the same machine. You can read more about this on the BBC’s site.
The problem(s) with Username & Passwords
Whilst a Username and Password system is a (mostly) convenient approach to authenticating a user and straight forward to implement* it has 3 big flaws:
- It requires a human to remember something – and er the vast majority of humans are not very good at this and there’s certainly a limit to the number of things that we can all remember
- A username/password generally requires a secret to be transmitted from one machine to another over a network which of course leaves opportunity for someone to intercept these communications
- Username and passwords can be very annoying to regularly enter leading folks to find easier (and less secure) ways to make this easier such as short, easy to enter passwords
* There’s certainly some traps waiting to catch you out as we’ll see
So how might an attacker approach the humble login?
Whilst you are probably familiar with some techniques we’ll discuss such as brute forcing a login let’s put ourselves in the position of an attacker and consider all the ways we could go about attacking an application or solution.
This is a good exercise to carry out with your own solutions (threat modelling) and various frameworks such as STRIDE assist with this.
Of course not all applications are equal and a system designed to hold confidential info or deal with financial transactions is likely to attract more malicious interest than your cat’s fan page (if your cat is of interest to nation state actors then I wish you the best of luck).
Having said this poorly secured applications can (and have) provided a stepping stone for an attacker to gain entry into a network or system. Over the years I’ve seen many dev focussed solutions or systems that perform some highly privileged functions (e.g. talking to databases/copying code/allowing file upload/transfer) that are poorly protected, not maintained or forgotten about and could just provide the entry point someone malicious is looking for..
Obligatory Warning – don’t do illegal stuff and get fired/sued/go to Jail etc
Before we talk about approaches it should go without saying that you should never try any of these methods or tools on services you don’t own or have written permission to.
Attempting to gain unauthorised access is illegal and using some of the techniques we’ll discuss against stuff you don’t have permission to could see you ending up in jail.
If you want to learn how to use some of the tools and techniques there’s plenty of great services that offer VM’s you can legitimately target to develop your skills such as TryHackMe, HackTheBox or deliberately vulnerable applications such as the OWASP juice shop.
We’ll also be developing our own sample application shortly to attack and then implement defences for.
Username and Password functionality initially seems to offer limited attacking options given its simplicity.
Well, there’s actually rather a lot of options and below is a list of things I could come up with in a short time and I’m sure there are more that more experienced folks could think of.
It is unfortunately rather common for folks to leave default login credentials on services. Hardware devices such as routers are particularly bad for this and indeed you’ve probably seen this yourself in organisations you work in or with.
A quick google with the name of a service or device will soon locate a default login for a device or application if one exists and given the low effort to do this I suspect this would be one of the first things an attacker might try.
The other pretty common approach is to have a login that’s the same as the product name due to lack of imagination e.g. “payroll”, ” payroll”.
Guessing common logins
It’s pretty common for folks to create dumb passwords many of which should know better. Combinations of strings such as “admin”, “root”, “administrator” or “password” & “password123” will likely be tried given how common this is and the ease of which it can be done.
It is also pretty common for organisations to append the month, season or year on common terms e.g. winter2021 or <companyname>winter2021 so this approach may be tried too.
Guessing credentials with a bit of research/OSINT
If you know some of the users of a system (say via a LinkedIn search or even just a look on company website’s staff page) a bit of research may yield likely passwords candidates.
Maybe one of the potential users is blogging/tweeting about a particular sports team or hobby this could yield potential password options.
Another option an attacker could take might be to find out a supplier or partner that possesses login details and utilise these.
Credential stuffing is where attackers use a list of credentials from other systems in the hope that users have reused them. There are many password dumps around and paid services to make them easy to search.
My favourite example of this was in Darknet Diary episode about the LinkedIn breach and Donald Trump. Can you guess what Trump’s Twitter password was in ~2013 when he was the host of a popular TV show?
Using a list of passwords
There are many lists of common and real passwords compiled from login dumps at sites such as https://github.com/danielmiessler/SecLists/tree/master/Passwords.
Attackers can make use of tools such as Hydra and Burp that make it easy to utilise these lists and test for valid logins. These tools send a large amount of requests and then responses can be compared to check for signs of a successful login e.g. specific text such as “Logged in successfully”, different HTTP status codes or content length. With a fast connection and machine hundreds of thousands of passwords can be tried very quickly.
Trying every possible combination of characters, numbers and symbols
Whilst this will likely take a while and is very noisy this approach it will eventually yield results especially if there are no complexity requirements on your passwords.
This could also crash a poorly written application resulting in a Denial of Service.
A buffer overflow in a login function is probably one of the most critical issues an application could have due to its ability to be exploited remotely. This very issue occurred in SLmail 5.5 and is now often for teaching buffer overflow concepts.
You might be thinking ok I can see how you can try various passwords from lists etc but how will an attacker know the username?
There’s several options an attacker could take to find out a username such as:
- Some systems may leak details of usernames (e.g. a blog that shows the username on posts)
- Maybe it’s a popular system that most folks will use and their email/username can be found elsewhere
- An easy to guess system is used such as an incrementing number
- It may be possible to setup a user yourself to work out the format
- Forgotten password functionality could expose valid/invalid usernames (we’ll go back to this)
- Valid usernames could be enumerated by sending a large amount of requests and examining timing differences that may occur when a valid username is supplied. Some older versions of SSL in a certain configuration suffer from this and there is even a metasploit module to check/exploit this.
If somethings been transmitted over a network then there is the potential for it to be intercepted unless its transmitted using secure protocols.
Of course, some attackers (e.g. government agencies) almost certainly possess the resources to read even encrypted communications.
Certificate based attacks and SSL stripping
Whilst communications can be sent over SSL if an attacker can redirect them to an unsecured connection or somehow obtain the certificate key or compromise the certificate issuing authority then communications could be intercepted.
Tricking users into using a fake login page
If an attacker can somehow trick users into using what appears to be a legitimate login page maybe via phishing or social engineering they could then pickup their credentials and forward them onto the real site and the user be non the wiser.
There’s some scary real world examples of this such as Tunisia, Facebook incident back in 2011.
If a user is already logged into an application and CRSF defences are not utilised it may be possible with approaches such as phishing emails to access privileged functionality especially if it doesn’t require login details to be re-entered.
Whilst I think most folks are becoming aware that they shouldn’t share their login credentials or hand them over the phone its likely there are many folks that could be tricked into handing over credentials. Think a phone call from “IT Support” that just need your credentials to do..
Some users could be enticed/bribed, blackmailed or threatened into revealing important details.
Denial of service
It might be possible for an attacker to create a high load on a system by bombarding it with login requests and prevent anyone else from using it.
Looking for unsecured areas of the application & poorly implemented session handling
Whilst not strictly a login issue there may be unsecured components in an application that don’t even need valid login details that could be found by directory busting using tools such as gobuster.
If you can guess a users session identifier you could potentially take it over.
Using credentials of inactive users or staff that have left
Many organisations have a huge number of systems that their staff will use and it can pretty hard without centralised authentication to ensure that access is disabled.
We all know how good most companies are at making sure all access is disabled.. (not very).
Hopefully not so common now but authenticating against a database is pretty common and it may be a poor implementation vulnerable to SQL injection. I should note this issue seems to crop up fairly regularly in training environments/CTF machines so worth checking for.
Insecure implementations of Remember Me functionality
Some applications will supply a cookie to the users so they can avoid having to login to an application again. Poor implementations may store a user id in a form that can be easily modified to elevate access.
Insecure Password Reset
Going to a password reset page may allow an attacker to determine if a username is valid or not. For example the attacker could enter a username to test and the application may indicate whether the login was valid or not with a message such as “invalid username” or even tiny differences in the HTML returned.
Sometimes password reset functionality may ask questions to authenticate a user. Unfortunately some of these questions can be pretty easy to find out such as a persons date of birth (quite likely on social media), school etc. See Sarah Palin hack for an example of where attackers used this approach.
An attacker could add a malicious program or device to log users keystrokes. I’ve seen some financial applications implement a keypad that appears at random positions to try and mitigate this. Whilst this probably raises the bar if someone has a keylogger on your machine they could grab screen images too..
Physical changes on a device
This is more relevant for physical security devices such as a keypad entry system that due to physical characteristics may reveal the login detail. I remember seeing a keypad recently where 3 keys were very visibly more used than others. Guess which 3 keys are likely to be used in the entry code..
As you can see there are many potential options – can you think of any others?
Join me in Part 2 where we’ll begin to implement a .NET Core application for playing with Offensive and Defensive techniques and look at how we can defend against most of these methods we’ve discussed above.