This is going to be one of those posts that some may scratch their head at and say, “why is he bothering to write this?” And this will not be the last of these types of posts – I promise you that.
The fact of the matter is that people getting into hacking (ethical I hope) may overlook things which, to those with more experience, stick out like a sore thumb. If you’re like me, this is something that needs to be learned. You experience it, make a note of it, and add it to your toolbelt and methodology. Once you experience this – whether it’s getting ahold of easy credentials or something else seemingly trivial – you grow as a hacker and begin to progress to more sophisticated topics. Again, this may be obvious but to those starting out or who lack a particular background/skillset, they jump straight to more complex attack vectors. Not everything is or should be difficult. Why jump straight to a SQL authentication bypass when the credentials were admin:admin… Yes, bypassing authentication with SQLi is still on the basic side of things but not when compared to default credentials.
Start easy and work your way up. This is true even for those who are hacking veterans. No sense trying to throw something sophisticated at a box if you can easily open the front door and walk inside.
Having said all that, I break “Easy Credentials” into 3 categories:
- Default
- Hardcoded
- Common
Default credentials are exactly what they sound like. A person or organization sets up a device or application and does not change the password that was originally set by the vendor. The purpose is to perform configuration and then change it to something secure. This does not always happen. Take a look at the screenshot below of default Tomcat credentials. (Source: https://github.com/netbiosX/Default-Credentials/blob/master/Apache-Tomcat-Default-Passwords.mdown)
The next category would be hardcoded. This could be as a comment on the source code of a page within a website or it could be in the files within an application on GitHub. I have seen web applications that have a pair credentials – username and password – in the source code. There could be a chance that these were never removed. Lets say the application has a SQL backend that stores the credentials. The source code may reveal the SQL code that creates the table and inserts some example data. Now we have a potential credential pair–or at the least a username to try. Hardcoded credentials could fall under the category of default as well but more often than not they’re something a bit more distinct.
Finally, we have common credentials. If you haven’t already, take a look at Daniel Miessler’s SecLists GitHub project – linked below. If you’re going through a CTF challenge or a vulnerable box, you’ll probably just use the tried and true rockyou.txt wordlist. Otherwise, you may want to use a shorter more general dictionary. Some of these common passwords are easy wins and can be sprayed without locking out users if you throttle the number of attempts. A point to drive this home is taking one of these and checking a site like HaveIBeenPwn to see how many times that password or a hashed version was compromised. I believe they also have an API that allows this so it can be done fairly efficiently.
Resource: https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials
Team-53 InfoSec Blog 