WEBVTT 00:00:01.040 --> 00:00:03.650 Welcome back! And in this section, we're going to cover 00:00:03.650 --> 00:00:06.840 assessing repositories for credential leakage. Credentials in 00:00:06.840 --> 00:00:09.010 code can be a huge risk for any business. 00:00:09.060 --> 00:00:12.270 If an organization is lucky, then exposed credentials may lead 00:00:12.270 --> 00:00:15.270 to some limited time and resource spent dealing with the 00:00:15.270 --> 00:00:17.260 security incident with little impact. 00:00:17.340 --> 00:00:18.760 In the worst case scenario, 00:00:18.770 --> 00:00:21.350 it can lead to severe financial loss where business 00:00:21.350 --> 00:00:23.250 reputation is negatively impacted. 00:00:23.440 --> 00:00:27.440 Some examples of how credentials in code can be exploited include data 00:00:27.440 --> 00:00:31.430 breaches, and this is where exposed credentials are found, and this can 00:00:31.430 --> 00:00:35.070 result in data taken directly from an organization, and you will have no 00:00:35.070 --> 00:00:36.990 doubt seen many of these in the news. 00:00:37.060 --> 00:00:38.670 Not all data breaches are severe, 00:00:38.680 --> 00:00:41.160 but regardless, this is something you want to avoid. 00:00:41.240 --> 00:00:43.870 Lateral movement is where exposed credentials can aid 00:00:43.870 --> 00:00:47.230 attackers who already have unauthorized access to systems 00:00:47.230 --> 00:00:49.280 in an environment. In this example, 00:00:49.290 --> 00:00:52.820 you're effectively handing more keys to an attacker to get access to even 00:00:52.820 --> 00:00:56.440 more systems than previously had access to. Detecting the compromise of 00:00:56.440 --> 00:00:59.580 systems in an organization is a very difficult task. 00:00:59.590 --> 00:01:03.560 It's even harder to detect already authenticated users accessing internal 00:01:03.560 --> 00:01:07.290 systems pivoting across systems laterally, so you need to prevent this 00:01:07.290 --> 00:01:11.570 early. And we have privilege escalation. Once an attacker is already inside 00:01:11.570 --> 00:01:15.330 an organization, they will try to increase their privileges to be able to do 00:01:15.330 --> 00:01:19.650 more within an environment. Privilege escalation is very easy to achieve if 00:01:19.650 --> 00:01:23.280 the credentials to hide privilege services are discovered by an attacker in 00:01:23.280 --> 00:01:23.860 a repo. 00:01:24.620 --> 00:01:27.240 In this course, we're only covering GitHub, but at this point, 00:01:27.240 --> 00:01:30.570 it's important to mention that code is stored in many areas, and 00:01:30.570 --> 00:01:31.980 some are more obvious than others. 00:01:31.990 --> 00:01:35.890 Version control like GitHub or BitBucket, where code is typically managed 00:01:35.900 --> 00:01:39.690 by developers or testers. Package management software, like pip if using 00:01:39.690 --> 00:01:42.940 Python, and this is where existing code is pulled from code sources. 00:01:42.940 --> 00:01:46.020 Websites and web pages are written in code, and these can contain 00:01:46.020 --> 00:01:48.460 hard‑coded passwords in code and comments. 00:01:48.740 --> 00:01:52.260 Microsoft SharePoint and other file sharing, where code and other files 00:01:52.260 --> 00:01:55.960 are stored during collaboration between colleagues. More collaboration 00:01:55.960 --> 00:01:59.850 tools, like Teams, Slack, and Discord. And finally, the commit history, 00:01:59.930 --> 00:02:01.660 and this is where this course is focused. 00:02:02.840 --> 00:02:06.310 This course is focused on GitHub and TruffleHog. Within the context of 00:02:06.310 --> 00:02:10.280 GitHub, secrets may be committed over a long period of time if left 00:02:10.289 --> 00:02:14.540 unmonitored, and the scenarios for this will vary, and this could be. A 00:02:14.540 --> 00:02:17.440 developer may realize they've pushed code to a repo containing a 00:02:17.440 --> 00:02:19.060 secret, and to correct this, 00:02:19.060 --> 00:02:22.060 the developer may push new sanitized code to the repo. 00:02:22.220 --> 00:02:25.970 This is committing over code trying to overwrite data. Legacy 00:02:25.970 --> 00:02:28.480 features where software is updated many times, 00:02:28.580 --> 00:02:31.950 including replacing technology. So consider an example where 00:02:31.950 --> 00:02:36.080 developers replace an insecure FTP file upload with a more modern 00:02:36.080 --> 00:02:39.500 secure technology. Credentials used to access the Legacy FTP 00:02:39.500 --> 00:02:42.440 technology could still be within the commit history. 00:02:42.740 --> 00:02:46.210 Also, code reviews, where a team may review the entire code base 00:02:46.210 --> 00:02:49.920 of a product and potentially large portions of code removed, maybe 00:02:49.920 --> 00:02:52.900 because the code is deemed to be insecure, like hard‑coded 00:02:52.900 --> 00:02:54.250 passwords and developer nodes. 00:02:54.690 --> 00:02:56.970 Again, the Legacy code is still being retained in the 00:02:56.970 --> 00:02:59.160 history after the code review is complete. 00:03:00.740 --> 00:03:03.840 GitHub provides a really useful feature called Insights. When 00:03:03.840 --> 00:03:06.540 enabled, it provides various graphs, and the graph that's 00:03:06.540 --> 00:03:08.990 interesting to review is called code frequency. 00:03:09.080 --> 00:03:13.240 Code frequency gives you a visual representation of additions and deletions. 00:03:13.250 --> 00:03:16.010 Think of the green as the data the developers and visitors to 00:03:16.010 --> 00:03:18.390 a repo will see and generally care about. 00:03:18.400 --> 00:03:21.720 The red is the data developers and visitors will not see anymore, and it's 00:03:21.720 --> 00:03:25.870 likely still retained in the repo and generally forgotten about data. In 00:03:25.870 --> 00:03:29.510 this example, which I obtained freely from a public repo, you can see early 00:03:29.510 --> 00:03:34.530 in 2019 there was a large number of additions, and then in early 2021, more 00:03:34.530 --> 00:03:38.290 additions, but this time with some deletions. So maybe this code is being 00:03:38.290 --> 00:03:41.780 replaced for something more modern. To find out, you would need to inspect 00:03:41.780 --> 00:03:42.300 the code. 00:03:42.310 --> 00:03:45.240 Now we can have credentials in either area, green or red. 00:03:45.290 --> 00:03:48.450 If you review a few more of these graphs in your own environments, 00:03:48.460 --> 00:03:51.960 it's interesting to see how the different code bases evolve over time. 00:03:52.040 --> 00:03:53.440 You should scan all the repos, 00:03:53.450 --> 00:03:56.980 but any reports with large levels of deletions should be reviewed, 00:03:57.050 --> 00:03:59.500 particularly if it's a critical business code base. 00:04:00.740 --> 00:04:03.260 We've seen some scenarios that would cause you issues, 00:04:03.270 --> 00:04:07.070 but how to address them? Security awareness is perhaps the most 00:04:07.070 --> 00:04:10.240 important part of secure code development. Here it's your security 00:04:10.240 --> 00:04:13.480 team providing advice and steps to help protect code, and there are 00:04:13.480 --> 00:04:16.870 many important topics. If developers are aware of the security risks 00:04:16.870 --> 00:04:17.910 of the commit history, 00:04:17.980 --> 00:04:20.760 this would go a long way to improve security culture and 00:04:20.760 --> 00:04:22.860 prevent issues from occurring in the first place. 00:04:22.940 --> 00:04:26.840 Code reviews are where developers, testers, and sometimes security engineers 00:04:26.850 --> 00:04:29.690 will check the code for errors and omissions prior to release. 00:04:29.750 --> 00:04:32.010 It's this stage where code should be inspected for the 00:04:32.010 --> 00:04:33.700 common security areas, for example, 00:04:33.700 --> 00:04:36.770 hard‑coded passwords. Scanning for credentials during a 00:04:36.770 --> 00:04:38.630 code review would be a good opportunity. 00:04:38.980 --> 00:04:42.360 There are numerous training courses developers can attend that are aimed towards 00:04:42.360 --> 00:04:45.760 secure development of code. Development teams are often under pressure to 00:04:45.760 --> 00:04:50.360 deliver, and time allocated just to learn new skills and improve awareness does 00:04:50.360 --> 00:04:52.360 reduce the occurrence of security incidents. 00:04:54.340 --> 00:04:58.250 If you do find sensitive credentials in the source code, what should you do? 00:04:58.490 --> 00:05:01.020 The answer to this is not necessarily clear cut, and 00:05:01.020 --> 00:05:03.740 depends on the circumstances of the incident. Removing 00:05:03.740 --> 00:05:05.640 code seems to be the obvious choice. 00:05:05.710 --> 00:05:07.840 If credentials are found in the GitHub repo, 00:05:08.050 --> 00:05:10.120 then remove them, and the problem is solved. 00:05:10.380 --> 00:05:11.860 If the code base is simple, 00:05:11.940 --> 00:05:14.890 removal of the code will be possible with no lasting impact. 00:05:14.900 --> 00:05:17.320 However, if the code base is mature and complex, 00:05:17.440 --> 00:05:21.460 removing portions of the commit history could affect rollback operations. 00:05:21.470 --> 00:05:24.000 So in this case, consult with your development teams on this. 00:05:24.190 --> 00:05:28.180 Disabling is another option where affected credentials are discovered in a repo. 00:05:28.180 --> 00:05:32.020 Instead of removing the credentials, they are made ineffective through account 00:05:32.020 --> 00:05:35.060 disable or rotation and the details are changed. 00:05:35.170 --> 00:05:38.380 This method preserves the commit history and mitigates the risk. 00:05:38.390 --> 00:05:42.120 This option again depends on the business circumstance. Settings 00:05:42.120 --> 00:05:45.040 will also need to be reviewed, and a good example of this is if 00:05:45.040 --> 00:05:46.940 the affected repo is set to public, 00:05:46.950 --> 00:05:49.120 the immediate action would be to set to private, 00:05:49.180 --> 00:05:51.590 therefore limiting access while the incident is being 00:05:51.590 --> 00:05:54.330 investigated. As mentioned previously, 00:05:54.390 --> 00:05:57.640 any discovered credentials should be changed immediately on discovery. 00:05:57.820 --> 00:05:59.630 The longer credentials are exposed, 00:05:59.640 --> 00:06:02.280 the greater the risk to any organization, and this 00:06:02.280 --> 00:06:04.290 task should be escalated immediately. 00:06:04.740 --> 00:06:07.040 If you work in either a small or large enterprise, 00:06:07.050 --> 00:06:10.100 having an incident response process to follow is critical. 00:06:10.270 --> 00:06:12.670 This is needed to deal with any occurrence of exposed 00:06:12.670 --> 00:06:15.690 credentials in a timely manner and to give assurance the 00:06:15.690 --> 00:06:18.180 organization remains protected from threats. 00:06:18.190 --> 00:06:20.800 All the points above should be part of an incident response 00:06:20.800 --> 00:06:25.500 playbook process. Before we go into a demo, it's also worth 00:06:25.500 --> 00:06:28.340 covering another important area, and that's around whether a 00:06:28.340 --> 00:06:30.190 repo is set to public or private. 00:06:30.290 --> 00:06:33.110 The choice of setting depends on your business requirements, and it's 00:06:33.110 --> 00:06:35.390 important to be aware of the risks around this setting. 00:06:35.510 --> 00:06:39.730 Setting a repo to public exposes the entire selected repo to public, 00:06:39.750 --> 00:06:42.770 meaning anyone with an internet connection will be able to access, 00:06:42.880 --> 00:06:44.850 and this can include the commit history, too. 00:06:44.940 --> 00:06:47.800 So you need to be absolutely certain this is a setting you need. 00:06:47.990 --> 00:06:51.310 If there is any personal data, organizational data, 00:06:51.420 --> 00:06:53.370 it will only be a matter of time before someone 00:06:53.370 --> 00:06:54.930 will find and use the information. 00:06:55.000 --> 00:06:59.050 It's important all sensitive information is removed prior to releasing publicly. 00:06:59.130 --> 00:07:02.660 Typically, public settings are used for low risk open projects. 00:07:02.740 --> 00:07:03.150 However, 00:07:03.150 --> 00:07:05.860 it's not uncommon for an organization to release a private 00:07:05.860 --> 00:07:09.040 repo publicly, and when they do, some scrutiny is done 00:07:09.040 --> 00:07:10.960 beforehand to sanitize data. 00:07:11.840 --> 00:07:14.650 Private marks the repo so that only approved members of 00:07:14.650 --> 00:07:16.750 an organization can access the repo. 00:07:17.010 --> 00:07:19.250 This is a preferred option where there is any risk of 00:07:19.250 --> 00:07:21.920 sensitive data being retained or exposed. 00:07:21.930 --> 00:07:25.020 For either public or private, it's recommended all repos are 00:07:25.020 --> 00:07:27.760 regularly scanned for credentials and sensitive data. 00:07:27.840 --> 00:07:30.410 Regular reviews are the only way to give assurance 00:07:30.410 --> 00:07:32.250 sensitive data is not at risk. 00:07:33.940 --> 00:07:36.090 Okay, let's perform an assessment of a repo. 00:07:36.320 --> 00:07:39.590 I'm going to use a repo that I have created for the purpose of this course. 00:07:39.900 --> 00:07:42.820 The installation of TruffleHog is not covered on this course, 00:07:42.830 --> 00:07:45.980 but details can be found on the TruffleHog GitHub page. 00:07:46.060 --> 00:07:49.360 I will be using the default settings of TruffleHog for this demo. 00:07:49.910 --> 00:07:51.450 At the end of this demonstration, 00:07:51.650 --> 00:07:53.810 you will learn the advantage of active defense 00:07:53.820 --> 00:07:55.660 through the use of decoy credentials. 00:07:56.340 --> 00:07:59.250 You will also be able to perform an assessment of a repo, 00:07:59.370 --> 00:08:02.940 looking for credential leakage. From the console, the 00:08:02.940 --> 00:08:04.640 command I will use is TruffleHog. 00:08:05.340 --> 00:08:07.120 I want to use the feature regex, 00:08:07.230 --> 00:08:10.230 which I'll cover in the next demo, but this allows you to look for 00:08:10.230 --> 00:08:13.490 specific types of credentials using regular expressions. 00:08:13.760 --> 00:08:16.680 Next, I want to disable performing an entropy search. 00:08:16.850 --> 00:08:19.830 Essentially, this looks for random text strings that could be 00:08:19.830 --> 00:08:23.380 a credential. Then the name of the repo, and here I'm using a 00:08:23.380 --> 00:08:25.350 private repo that I control. 00:08:25.440 --> 00:08:28.050 You would want to substitute this for your own repo. 00:08:28.340 --> 00:08:30.050 I run that, and nothing is returned. 00:08:30.520 --> 00:08:33.600 It appears as though nothing has happened, and TruffleHog in this 00:08:33.600 --> 00:08:35.980 situation will not tell you if there are no results. 00:08:36.840 --> 00:08:39.960 Let's repeat the command, but instead enable the entropy. 00:08:49.340 --> 00:08:52.550 Now here we have a result. Because we enabled the entropy, 00:08:52.550 --> 00:08:56.630 TruffleHog has found text that appears to be random and that could 00:08:56.630 --> 00:08:59.610 well be a credential or secret of some sort. You would need to 00:08:59.610 --> 00:09:01.660 contact the repo order to confirm. 00:09:02.540 --> 00:09:06.550 We can go to the GitHub repo, and we can see the file containing the suspected 00:09:06.550 --> 00:09:12.060 credential. As you can see, TruffleHog is very easy to use. 00:09:12.340 --> 00:09:15.740 Now you know the danger of credentials in repos, you can use this to 00:09:15.740 --> 00:09:19.970 your advantage and implement active defense. Here you can create decoy 00:09:19.970 --> 00:09:22.590 credentials in as many repos as you can. 00:09:22.610 --> 00:09:24.570 When you do create a decoy credential, 00:09:24.730 --> 00:09:28.220 it's essential you document the process and let the entire security 00:09:28.220 --> 00:09:32.440 team aware to avoid generating any costly security incidents. For 00:09:32.440 --> 00:09:35.670 each decoy, you ideally want some form of trigger or notification, 00:09:35.670 --> 00:09:37.850 too, so that you can be alerted. 00:09:38.840 --> 00:09:42.010 I've created a repo called internaldecoyrepo.git. 00:09:42.180 --> 00:09:44.290 Now I'd recommend not using that name in your 00:09:44.290 --> 00:09:46.490 environment, as it's a little bit too obvious. 00:09:46.500 --> 00:09:48.300 This is a repo that I have created. 00:09:48.470 --> 00:09:52.460 It's got no real purpose, and it will be used to store decoy credentials. 00:09:52.940 --> 00:09:54.500 I want attackers to find it, 00:09:54.610 --> 00:09:56.820 but only attackers who already have access to my 00:09:56.820 --> 00:09:58.850 private repo will be able to see this. 00:09:59.310 --> 00:10:03.010 I've also added a website address, and this is only an example, and on 00:10:03.010 --> 00:10:05.450 the website you can have some form of basic login. 00:10:05.580 --> 00:10:09.170 If a user tries to log in using the credentials from your private repo, 00:10:09.180 --> 00:10:10.290 then you have a problem. 00:10:10.420 --> 00:10:11.680 If you were an attacker, 00:10:11.780 --> 00:10:15.030 this would be very tempting to visit the website and try to log in. 00:10:15.200 --> 00:10:19.250 This would be your trigger to notify you when decoy credentials are used. 00:10:19.440 --> 00:10:21.900 Decoys are a great cost‑effective defense measure, 00:10:22.040 --> 00:10:25.420 but they do require monitoring and upkeep, so use sparingly, as 00:10:25.420 --> 00:10:28.320 you could generate lots of work and alerts if deployed too 00:10:28.320 --> 00:10:30.180 frequently within your environments. 00:10:30.320 --> 00:10:34.670 For example, you could deploy decoy credentials in a public repo that you own. 00:10:34.870 --> 00:10:37.110 This will certainly help to identify attackers. 00:10:37.380 --> 00:10:39.470 The issue with public repos, however, 00:10:39.500 --> 00:10:43.400 is that the number of alerts are going to be higher and will likely include bug 00:10:43.400 --> 00:10:46.460 bounty specialists, and even colleagues reporting in, too. 00:10:46.640 --> 00:10:47.150 Ultimately, 00:10:47.150 --> 00:10:50.930 the decision on the number of decoys is up to you and your organization. 00:10:51.040 --> 00:10:52.240 That's the end of this demo. 00:10:52.390 --> 00:10:54.320 Next, we will look at customer assessments.