The aftermath of stolen and abused credentials

Premeditated damage control

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

🔒 Related Stories: Cybersecurity for Executives

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Attackers will steal credentials. As history shows us, it is not a matter of if, but when. I’ll talk about ways to help prevent that in the next blog post, but for now, I’d like to consider a different question in my next post on Cybersecurity for Executives: How much damage can an attacker inflict on your company using stolen credentials and what can you do about it?

The term Blast Radius refers to how far-reaching the effects are of some adverse event. Initially, it was used to refer to the impact a bomb would have on its surroundings, but the same concept applies to cybersecurity incidents and the specific vulnerabilities that cause them, including an open network port, CVE, or credential theft. I felt like this term was over-used at one of my employers. Consider the blast radius in the context of all aspects of your infrastructure and architecture, so your protection still allows work to get done and doesn’t cause some other architectural problem, but do keep it in mind when implementing security controls to limit harm. When an attacker steals credentials, how much can they do with that access?

Earlier this year, Microsoft reported a breach in which a single set of user credentials enabled an attacker to see information from potentially tens of millions of Microsoft email users. How could this system design be improved? Access should be granted as needed for the account in question during the time of an incident. Yes this is hard to do and it costs more to build systems with these types of controls in place, but security is not free.

In a related incident a Facebook security analyst was fired for using private data to stalk women. How did he have such broad access to personal data? When designing systems people should have access to data on a need to know basis to handle a specific incident. Systems can be designed so the system giving the temporary access is not the person using the access.

These are two examples of cases where organizations gave users credentials with very broad access. Not thinking through how that access could be misused had negative consequences. In one case, the access was stolen and in another a person abused the access. Either case can lead to a data breach. I talked about some of the ways employees can misuse their access in my last post. Let’s look at some of the ways credentials can be stolen and what can happen as a result.

On January 17th, 2019, Troy Hunt wrote a blog post regarding over 773 million compromised credentials. What is interesting is that the number of unique passwords is much lower than the total number of unique usernames. What does that tell us? Even with some room for error and unrecoverable passwords in the dump, a lot of people are picking the same passwords or reusing identical passwords on different accounts. Reused passwords enable attackers to take stolen credentials from one breach and attempt to log into and compromise other unrelated systems. This is known as credential stuffing. Many additional systems are then compromised beyond the one that leaked credentials because people reuse the same password for multiple accounts. Dunkin Donuts and Intuit, maker of TurboTax reported attackers were able to access customer accounts for this reason.

Note that these compromises were the fault of the users who used the same password in multiple places or the vendor who initially lost the passwords, or both, depending on your point of view. Although the company hit by the credential stuffing attack can try to identify these attacks, it is sometimes nearly impossible for them to know the owner of the credentials is not the person using them. That is because the whole point of usernames and passwords is to prove who you are — because you have them. Because you know them you are let into the system. The system you are logging into presumes no one else has them. If someone else gets your credentials, they are effectively you as far as the website or application you log into is concerned. That is the concept of identity — proving who you are by entering credentials

The actual solution to the credential stuffing problem is not preventing the attackers from using the stolen passwords, but instead, not exposing credentials in the first place, and not reusing the same password in many locations. Some other proposed solutions include password managers, password-less solutions, biometrics, and MFA (multi-factor authentication), which I’ll cover in my next post. For now, let’s consider how bad actors obtain credentials and system access.

Google revealed that it had stored plaintext (unencrypted) passwords for 15 years, potentially readable by their employees. System design can get very complex in a hurry. Companies need to have developers and software architects that examine the entire system for data exposure. Sensitive data may be written to log files when an error occurs, exist in emails, backups, caches, or URLs (links used to access the system) if organizations are not careful. Rogue employees, malware, website attacks, or accidents could all lead to credential exposure.

All the people involved in designing and building systems should be aware of and on the lookout for improper handling of any secret used to access an application or data. A mechanism should be in place for reporting these system implementation errors. Not only could employees who had access to the unencrypted credentials see them, but any malware that could infiltrate the employee’s laptop, for example, could in turn potentially access the unencrypted credentials.

Yahoo and LinkedIn suffered massive breaches that exposed usernames and passwords. The Yahoo breach settlement was still on-going as of April 2019 and up to $117.5M. I had a yahoo account. I wonder if I will see any of that settlement as every single Yahoo user account was compromised. The LinkedIn breach was potentially the work of the attackers, and that breach resulted in a $1.25M settlement. Even though these companies encrypted the passwords, the attackers were able to figure out what a lot of them were. How did they do it? Let’s dive a bit deeper and see how this all works.

When a person or device logs into a system, they may have to show who they are, and that they are allowed to access the system. Proving who you are is known as authentication. Usernames and passwords or keys (a set of random numbers and letters) may be used as a form of identity, as explained previously. The credentials prove who the person is and in turn, what they have permission to do in the system. Authorization is the term security professionals use for the actions the owner of a set of credentials is allowed to take in a system. A common analogy for authentication is showing your drivers license to prove who you are in the United States. Because you have that driver’s license, you are authorized to drive a car on US roads.

A secure system will track the when credentials are used to authenticate, and when any denied or authorized action occurs, as well as the username, the time, and the date. Each set of credentials should be associated with one system or person so you can clearly identify which user or resource that took an action without question (assuming your system logs are secure, adequate, and accurate). The ability to prove who performed an action in a way that the person cannot deny is called non-repudiation and is very important when investigating data breaches.

If credentials are shared or not distributed securely, it will not be possible to determine the source of a violation or crime that leveraged those credentials. You also won’t have a case that stands up in court if you cannot show without a doubt that the person whom you claim accessed the system inappropriately did so. That’s why many security standards state that each user should have his or her own set of credentials. This assignment of one person to one set of credentials is also how systems can identify who is logging in. If the system says you logged in but you know you didn’t, you know someone has compromised your credentials.

Passwords should be stored in a hashed format. A hash is one-way encryption of a file or value, meaning you pass the data through the hashing process and when it comes out the other side you can’t reverse the process to get back the original value. Hashes differ from two-way encryption where you encrypt the data with an encryption key and then can decrypt it to get it back to the corresponding plain-text value using a key. More on encryption in future posts but in regards to passwords, know that best practices dictate they should be stored as hashes, not using two-way encryption.

One thing hackers may try to do with a hash is to try to guess the password (a method called “brute force.”) Tools exist that try to make this process easier. The more complex and long a password is, the longer it will take to crack (guess) because the attacker has to guess and exponential set of combinations (length times number of possible values for each character). For example, if your password is “dog” and you only use lowercase letters from the alphabet (a-z) I’d have to guess 26 times for each possible value times the number of positions (3 in d-o-g) and all the possible combinations (meaning if I want to try the letters abc I’d have to try aaa, aab, aba, baa, abb, bab, abc, acb, cab, cba…) and so on. If you do the math — adding uppercase alphabet letters turns 26 into 52 — so that’s more guesses. A longer password also adds additional positions. I hope you get the idea!

Often these brute force attempts start by adding common passwords and words or numbers likely to be in the target passwords to a word list used by the password cracking tool. For example, it’s baseball season in Seattle, so I might add “Mariners” to my wordlist so I can guess any password with that word in it more quickly. Yes, baseball fans, you might want to change those passwords! Ok let’s say you made your password one of the most commonly problematic passwords out there: Summer2019 or whatever month, quarter, or variation of the current date and time applies to all the people out there who have done this. Oh, that’s your current password? Sorry, I just told everyone. Go change it now. I’d be able to crack it in seconds because it’s one of the first passwords added to any word list for these cracking tools.

When possible, the attacker will merely look up the password associated with the hash. Here’s how it works. Using a standard hashing algorithm (an algorithm is part of a computer program which is like a formula with inputs and outputs), my password enters the algorithm, and the result is some unreadable value. Let’s just say it is: X1yZ23AQ4. It’s not. I just made that up, but just pretend it is for this example. That’s the hash of my password.

Now the next person comes along and creates the same password and it goes through the hashing algorithm. What does it turn out to be? X1yZ23AQ4.

The same password passed through the same encryption algorithm produces the same hash unless we do something to mix it up as I’ll explain in a minute. If I can crack (guess) or otherwise obtain the password associated with that hash, I now have the password for anyone whose password is represented by that hash (X1yZ23AQ4). In other words, when I see that hash, I can just look up the password because I already discovered that hash is associated with the password Summer2019.

Over time attackers have created something called Rainbow Tables, which are basically an enormous database (or a bunch of files) of every password and its associated hash that they have encountered. Any time a set of credentials is compromised, they will search for the values they discovered in these tables to find the corresponding password if they can. It’s a lot faster to use a rainbow table than to try to crack the password.

How can system implementers avoid these problems? Use a sufficiently complex hashing algorithm and a salt. Other factors, as mentioned, include password length, complexity (which some people debate), and how often you change the password. If you change the password while an attacker is in the middle of guessing it, they will have to start over. More on good passwords in the next post. For now let’s talk about the algorithm and the salt.

Which algorithm should you use? That depends on what type of encryption you are trying to implement. In this case, we want to hash some data. If your developers are still using MD5 (like Yahoo) or SHA1, security organizations like NIST, and Bruce Schneier, one of the world’s leading cryptography experts recommend against it. OWASP (the Open Web Application Standards Project) has some recommendations on their Password Storage Cheat Sheet.

What exactly is a salt and why do you need one? It is a random value passed into an algorithm with the username and password to generate a unique hash. Let’s say my password in the example above (Summer2019) goes through the hashing algorithm along with the salt (some random value) to produce a hash. Then a different random value was used for the salt in conjunction with each hashed password. The algorithm would then produce ciphertext (encrypted output or hash), which would be different for every person, even if their passwords were the same. Rainbow tables won’t work as well in this scenario (but the bad guys can still guess your over-used common password so seriously, go change it.)

Make sure your developers are hashing passwords with the most up to date recommended algorithm and using a random salt for each hash.

Unfortunately, passwords aren’t our only source of worry. After a person logs into a system, often a type of token is returned by the application that authenticated the person. The value is generally another sufficiently random (hopefully) string of letters and numbers or some other more specific structure. Instead of passing around the user credentials and checking them each time the system checks to see if the user has a valid token, often referred to as a session id (or another named format but I’m going to skip that for now to avoid a sea of acronyms, and the concept is the same). Systems do this for efficiency and to reduce the risk of stolen credentials. The session ID will last for a certain amount of time, referred to as a session. Even if someone obtains the token, it is only usable for a [hopefully reasonably short!] time. The session ID may expire or an administrator may revoke it in the case of a compromise, but the credentials (the user name and password used to log in) will still be valid.

A number of mechanisms exist to try to steal session ids and other types of hashes and tokens used to manage a user’s session. These tokens are effectively as good as credentials if obtained during the active session. Sometimes developers pass around and store tokens in ways that are not recommended such as in URLs where they end up in logs and store them in insecure cookies (bits of data stored for each site by web browsers like Google Chrome, Firefox, Safari, or Internet Explorer). I’ve even seen developers, who didn’t understand the impact of their choice, use the session ID as the name of files generated by a system that users downloaded from the web application. Anyone with access to those files could then use the token to take action as the logged-in user if the session had not expired. Who knows where that file name was logged and displayed in the system for other people to see.

Without going into the details, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) are types of web attacks that may leverage the permissions of a logged-in user to perform actions a user did not intend (like transferring money from a bank account) if developers and architects do not design systems with security in mind. Developers should be familiar with the OWASP (Open Web Application Security Project) Top Ten — current and previous versions, in my opinion — which lists top software flaws in web applications. Developers should also be aware of other types of attacks, such as those outlined by Mitre ATT&CK.

Other attacks involve breaking into a system and using the privileges assigned to that system. Server Side Request Forgery (SSRF) entails obtaining access to a web server, for example, and then leveraging the permissions of the web server to access data and other resources on the network. Let’s say, for example, a web server retrieves data from a database on behalf of authenticated users. An attacker will attempt to use access provided to the web server to obtain data in that database.

In a more tricky example, stolen credentials found in one system are used on a completely separate vulnerable system to pull data from a database in the RSA and AWS re:Invent presentation I gave with my co-presenter, Kolby Allen. This presentation explains the importance of both protecting credentials and correctly configuring your network as I explained my prior blog posts on cybersecurity for executives. We talk specifically about AWS in our presentation called Red Team vs. Blue Team on AWS, but the concepts apply to any cloud provider and even on-premises systems.

If an attacker obtains credentials or a token that does not give them a lot of access, the next step is to attempt privilege escalation. The attacker will seek flaws and vulnerabilities that allow actions greater than what the stolen credentials can do. The attacker may find admin credentials on the accessed system they will try to crack, or leverage one machine to access other connected systems that have more privileges.

In cloud environments, it attackers have enough permissions via stolen credentials, they can create a new virtual machine with permissions greater than the original credentials they obtained. Then they can connect to the system that has more privileges and do more harm. They may be able to shut down or terminate resources, install cryptominers (software that mines cryptocurrency using your resources that cost you money), or access additional data. They may create backdoor accounts so in the event you find and shut down the original credentials, they have a backup way to get into the system.

Another technique an attacker can use to escalate privileges on an operating system like Windows or Linux is called process injection. Operating systems have different processes running with different privileges. An attacker may find a way to inject malware into a running process that has full system access. These types of attacks are hard to spot since the process they have hijacked will look legitimate. Most modern operating systems have many mechanisms to prevent this, but determined attackers may eventually discover a way in, based on things I learned getting a certification in reverse-engineering malware and related research. The attack may come in the form of “file-less malware” which executes in memory only, not from a file on disk which a person investigating the breach could discover. At this point, I hope you are monitoring your network and access logs for suspicious actions such as many failed login attempts or repeated access denied error messages.

One of the considerations an organization should take when designing systems is not only how to protect credentials, but how much damage could an attacker do if a particular set of credentials are compromised. In the case of the root credentials of a cloud account, the attacker could delete the entire account. In the case of the domain administrator for a company, the attacker could do almost anything they want on a corporate network. Credentials of a database administrator may have unfettered access to all your data.

At some point, it is highly likely that attackers will get credentials of someone in your organization — a computer or a person that leverages credentials to take actions in your environment. This fact is why giving someone too much system access can be especially risky. Not only do you need to worry about the actions people take on purpose, as I explained in my last blog post on zero trust, you also need to consider how much damage is possible if those credentials are stolen and abused by someone other than the owner. What could an attacker do with one set of credentials? Instead of giving full administrative access to one set of credentials, determine how you can structure access to systems in your organization in a manner that minimizes risk.

Consider the story of Code Spaces. Many people who worked on AWS for a whole have heard this story, but I’m often surprised how many people haven’t so I’m going to repeat it. Code Spaces was a company that hosted code and project data for its customers. At some point, an attacker stole their administrative credentials. The attacker demanded money, and Code Spaces refused. The attacker proceeded to delete everything in the account. Code Spaces tried to change the admin password, but the attacker had already created additional credentials. It was no use. I call Code Spaces the “company that got deleted” because after that they went out of business. This tale is a sad example of why you need to be very careful how much access you give any single set of credentials and how important it is to protect those root credentials.

How much damage can any single set of credentials do in your environment? There’s always someone with “the special keys.” You know — that person who can fix anything. Allowing someone to have this almighty access is a risk to your organization. Consider how you might instead construct your credentials and system access to limit the potential damage if an attacker obtains those credentials. Limit broad access to systems and give them only the permissions people require to do their jobs. When setting up cloud environments, lock away the administrative or all-powerful root user. At the very least make sure your users can’t delete your account — and your unaltered logs.

Besides attackers stealing credentials, Unfortunately your own employees will sometimes misuse the access you have granted them. The 2019 Verizon Data Breach Report said that a number of incidents related to misuse of privileges involved employees using their credentials on the way out the door to steal data that would give them a competitive advantage at their next job.

You can limit the amount of damage a single set of credentials can do by using the concept of segregation of duties. Give different people access to different parts of a system. Ensure one individual can’t access the system as a whole. As a result, it takes of two or more people to cooperate to steal sensitive data. Banks do this all the time. Processing a large transaction generally requires two people. A company that wanted to move drug production to Asia split the formulation of the drug into multiple locations. (This presumes no one single government could demand all the facilities to give up the information.)

I don’t understand why this is concept is not leveraged more widely in IT and software design, but I have seen some organizations implement it in creative ways. I worked on a project at one company that stored half of a credit card in one system and the other half in another. I interviewed one vendor that designed their architecture in such a way that it would take a three-party collusion to access data. AWS requires two people to initiate a production deployment. I talk about how to structure teams in my cloud security class to achieve a similar objective in relation to cloud deployments. The structure needs to support moving fast while at the same time, having checks and balances in place for critical high-risk functions that could lead to a breach.

One person I know in a large company told me the pentesters (people who test for security flaws — like me!) accessed his “special keys” by running a cron job (a scheduled script they wrote to run over and over) that would periodically pull his AWS credentials off his laptop. With those access keys, they owned the account (or pwned in hacker lingo). He asked me, “Who looks for cron jobs on a Mac?” Well, he’s lucky it was people hired to intentionally test the system and not someone with more devious objectives!

And by the way, there’s no cheating when it comes to hacking. The defenders have to play by certain rules. Pentesters can do anything in scope for a pentest. True attackers have no rules to follow. That’s how it goes, and that’s one of the reasons attacking is easier than defending. Sorry, my friend!

One of the hardest and most important jobs in any company, in my opinion, is managing and monitoring credential use and abuse. Tracking all the ways credentials can be compromised is, at times, overwhelming. Systems need to be architected correctly. Credential-assignment needs to be architected as well when you think about it. The layers and structure of credentials can lead to gaping holes, overly permissive configurations, or in the extreme opposite scenario, an environment where no one can do their job effectively. Certain vendor products try to make credential management easier in large organizations.

That brings me to question number five in my list of 20 questions that executives can ask security teams. Make sure that the person designing the systems and structure for IAM (Identity and Access Management) at your company understands the risk and can tell you what the maximum potential damage to the organization could be if any single set of credentials fall into the hands of a malicious person. Understand who has the risky credentials in your organization. Monitor them closely. If overly permissive credentials exist, work to reduce the risk of exposure in ways that still allow your staff to get things done. They may not be as fast as they would be with unfettered system access, but they can be efficient enough while at the same time keeping your company out of the headlines as the victim of the next mega-breach.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2019

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab