Welcome back! And in this section, we're going to cover
assessing repositories for credential leakage. Credentials in
code can be a huge risk for any business.
If an organization is lucky, then exposed credentials may lead
to some limited time and resource spent dealing with the
security incident with little impact.
In the worst case scenario,
it can lead to severe financial loss where business
reputation is negatively impacted.
Some examples of how credentials in code can be exploited include data
breaches, and this is where exposed credentials are found, and this can
result in data taken directly from an organization, and you will have no
doubt seen many of these in the news.
Not all data breaches are severe,
but regardless, this is something you want to avoid.
Lateral movement is where exposed credentials can aid
attackers who already have unauthorized access to systems
in an environment. In this example,
you're effectively handing more keys to an attacker to get access to even
more systems than previously had access to. Detecting the compromise of
systems in an organization is a very difficult task.
It's even harder to detect already authenticated users accessing internal
systems pivoting across systems laterally, so you need to prevent this
early. And we have privilege escalation. Once an attacker is already inside
an organization, they will try to increase their privileges to be able to do
more within an environment. Privilege escalation is very easy to achieve if
the credentials to hide privilege services are discovered by an attacker in
a repo.
In this course, we're only covering GitHub, but at this point,
it's important to mention that code is stored in many areas, and
some are more obvious than others.
Version control like GitHub or BitBucket, where code is typically managed
by developers or testers. Package management software, like pip if using
Python, and this is where existing code is pulled from code sources.
Websites and web pages are written in code, and these can contain
hard‑coded passwords in code and comments.
Microsoft SharePoint and other file sharing, where code and other files
are stored during collaboration between colleagues. More collaboration
tools, like Teams, Slack, and Discord. And finally, the commit history,
and this is where this course is focused.
This course is focused on GitHub and TruffleHog. Within the context of
GitHub, secrets may be committed over a long period of time if left
unmonitored, and the scenarios for this will vary, and this could be. A
developer may realize they've pushed code to a repo containing a
secret, and to correct this,
the developer may push new sanitized code to the repo.
This is committing over code trying to overwrite data. Legacy
features where software is updated many times,
including replacing technology. So consider an example where
developers replace an insecure FTP file upload with a more modern
secure technology. Credentials used to access the Legacy FTP
technology could still be within the commit history.
Also, code reviews, where a team may review the entire code base
of a product and potentially large portions of code removed, maybe
because the code is deemed to be insecure, like hard‑coded
passwords and developer nodes.
Again, the Legacy code is still being retained in the
history after the code review is complete.
GitHub provides a really useful feature called Insights. When
enabled, it provides various graphs, and the graph that's
interesting to review is called code frequency.
Code frequency gives you a visual representation of additions and deletions.
Think of the green as the data the developers and visitors to
a repo will see and generally care about.
The red is the data developers and visitors will not see anymore, and it's
likely still retained in the repo and generally forgotten about data. In
this example, which I obtained freely from a public repo, you can see early
in 2019 there was a large number of additions, and then in early 2021, more
additions, but this time with some deletions. So maybe this code is being
replaced for something more modern. To find out, you would need to inspect
the code.
Now we can have credentials in either area, green or red.
If you review a few more of these graphs in your own environments,
it's interesting to see how the different code bases evolve over time.
You should scan all the repos,
but any reports with large levels of deletions should be reviewed,
particularly if it's a critical business code base.
We've seen some scenarios that would cause you issues,
but how to address them? Security awareness is perhaps the most
important part of secure code development. Here it's your security
team providing advice and steps to help protect code, and there are
many important topics. If developers are aware of the security risks
of the commit history,
this would go a long way to improve security culture and
prevent issues from occurring in the first place.
Code reviews are where developers, testers, and sometimes security engineers
will check the code for errors and omissions prior to release.
It's this stage where code should be inspected for the
common security areas, for example,
hard‑coded passwords. Scanning for credentials during a
code review would be a good opportunity.
There are numerous training courses developers can attend that are aimed towards
secure development of code. Development teams are often under pressure to
deliver, and time allocated just to learn new skills and improve awareness does
reduce the occurrence of security incidents.
If you do find sensitive credentials in the source code, what should you do?
The answer to this is not necessarily clear cut, and
depends on the circumstances of the incident. Removing
code seems to be the obvious choice.
If credentials are found in the GitHub repo,
then remove them, and the problem is solved.
If the code base is simple,
removal of the code will be possible with no lasting impact.
However, if the code base is mature and complex,
removing portions of the commit history could affect rollback operations.
So in this case, consult with your development teams on this.
Disabling is another option where affected credentials are discovered in a repo.
Instead of removing the credentials, they are made ineffective through account
disable or rotation and the details are changed.
This method preserves the commit history and mitigates the risk.
This option again depends on the business circumstance. Settings
will also need to be reviewed, and a good example of this is if
the affected repo is set to public,
the immediate action would be to set to private,
therefore limiting access while the incident is being
investigated. As mentioned previously,
any discovered credentials should be changed immediately on discovery.
The longer credentials are exposed,
the greater the risk to any organization, and this
task should be escalated immediately.
If you work in either a small or large enterprise,
having an incident response process to follow is critical.
This is needed to deal with any occurrence of exposed
credentials in a timely manner and to give assurance the
organization remains protected from threats.
All the points above should be part of an incident response
playbook process. Before we go into a demo, it's also worth
covering another important area, and that's around whether a
repo is set to public or private.
The choice of setting depends on your business requirements, and it's
important to be aware of the risks around this setting.
Setting a repo to public exposes the entire selected repo to public,
meaning anyone with an internet connection will be able to access,
and this can include the commit history, too.
So you need to be absolutely certain this is a setting you need.
If there is any personal data, organizational data,
it will only be a matter of time before someone
will find and use the information.
It's important all sensitive information is removed prior to releasing publicly.
Typically, public settings are used for low risk open projects.
However,
it's not uncommon for an organization to release a private
repo publicly, and when they do, some scrutiny is done
beforehand to sanitize data.
Private marks the repo so that only approved members of
an organization can access the repo.
This is a preferred option where there is any risk of
sensitive data being retained or exposed.
For either public or private, it's recommended all repos are
regularly scanned for credentials and sensitive data.
Regular reviews are the only way to give assurance
sensitive data is not at risk.
Okay, let's perform an assessment of a repo.
I'm going to use a repo that I have created for the purpose of this course.
The installation of TruffleHog is not covered on this course,
but details can be found on the TruffleHog GitHub page.
I will be using the default settings of TruffleHog for this demo.
At the end of this demonstration,
you will learn the advantage of active defense
through the use of decoy credentials.
You will also be able to perform an assessment of a repo,
looking for credential leakage. From the console, the
command I will use is TruffleHog.
I want to use the feature regex,
which I'll cover in the next demo, but this allows you to look for
specific types of credentials using regular expressions.
Next, I want to disable performing an entropy search.
Essentially, this looks for random text strings that could be
a credential. Then the name of the repo, and here I'm using a
private repo that I control.
You would want to substitute this for your own repo.
I run that, and nothing is returned.
It appears as though nothing has happened, and TruffleHog in this
situation will not tell you if there are no results.
Let's repeat the command, but instead enable the entropy.
Now here we have a result. Because we enabled the entropy,
TruffleHog has found text that appears to be random and that could
well be a credential or secret of some sort. You would need to
contact the repo order to confirm.
We can go to the GitHub repo, and we can see the file containing the suspected
credential. As you can see, TruffleHog is very easy to use.
Now you know the danger of credentials in repos, you can use this to
your advantage and implement active defense. Here you can create decoy
credentials in as many repos as you can.
When you do create a decoy credential,
it's essential you document the process and let the entire security
team aware to avoid generating any costly security incidents. For
each decoy, you ideally want some form of trigger or notification,
too, so that you can be alerted.
I've created a repo called internaldecoyrepo.git.
Now I'd recommend not using that name in your
environment, as it's a little bit too obvious.
This is a repo that I have created.
It's got no real purpose, and it will be used to store decoy credentials.
I want attackers to find it,
but only attackers who already have access to my
private repo will be able to see this.
I've also added a website address, and this is only an example, and on
the website you can have some form of basic login.
If a user tries to log in using the credentials from your private repo,
then you have a problem.
If you were an attacker,
this would be very tempting to visit the website and try to log in.
This would be your trigger to notify you when decoy credentials are used.
Decoys are a great cost‑effective defense measure,
but they do require monitoring and upkeep, so use sparingly, as
you could generate lots of work and alerts if deployed too
frequently within your environments.
For example, you could deploy decoy credentials in a public repo that you own.
This will certainly help to identify attackers.
The issue with public repos, however,
is that the number of alerts are going to be higher and will likely include bug
bounty specialists, and even colleagues reporting in, too.
Ultimately,
the decision on the number of decoys is up to you and your organization.
That's the end of this demo.
Next, we will look at customer assessments.