start	end	text
1050	9110	All right, so welcome everybody and thank you for taking the time to see our talk.
9110	17170	We are happy to be here at the DEF CON Red Team Village and we are very excited to share with you
17170	28730	some of the findings that we've been doing since we did a talk in the previous Red Team Village
28730	37650	Summit where we try to showcase and expose basically how dangerous is the leakage of
37650	43510	credentials on the internet. And today me and Jose Hernandez, my colleague, are going to be presenting
43510	50170	How'd My Keys Bing Pound API Edition. So let's get going.
52250	58710	So most of you know who we are. I'm a Principal Security Research Engineer at Splunk.
58710	64950	I worked with Jose at Prolexic, which is now Akamai. I worked at Akamai for a while. Then I went to
64950	73510	Caspita and came back at one point to Splunk. I co-founded Hack Miami and Pacific Hacker Meetups
73510	79070	and Conferences and I grow my own CDFs. Some of you may have Bladen, which is the Command and Control
79070	86250	and of course CDF. And Jose, can you tell us a little bit about yourself? Yeah, I'm also a Principal
86250	94150	Security Researcher at Splunk. I'm an old longtime friend of Brock from our Prolexic days, which got
94150	101130	purchased by Akamai. I co-founded a company called Zenitch, which is now Oracle's Web Application
101130	106870	Firewall and DDoS services. And returned to Splunk to do research, security research. And this is one
106870	112890	of the things that we've been working on that I'm super excited about. Awesome, so let's move on.
112890	119250	So just before we get into basically what we're going to show you today, it is important
119790	127630	that we recap a little bit on how we got to this point. And in order to recap to
128630	136930	to a point where we can understand how bad and how we got to this very bad situation, we need
136930	145470	to understand or take a look at what is DevOps. So as we have approached it before and explained
145470	152270	it, DevOps is a set of practices that basically is within software development and team operations.
152270	159010	It has become very popular. It's not really new, but it has become very popular and it has been
160470	170610	widely adopted as most companies are starting to somehow get a foot in cloud platforms.
170610	176770	Some of them have radically moved most of their operations to the cloud. And when we're talking
176770	185390	about developing software and producing software, building, coding it, planning it, testing it,
185390	193310	releasing it, the first thing that comes to your mind is DevOps. And DevOps is a
193310	201630	set of practices usually guided by some software development principles. And the most popular
202170	208430	currently is Agile. And some of you might be familiar with Agile if you have worked in a
208430	213810	software development company. I work for now for three software development companies and
213810	222490	all of them were using Agile. And this is how I was exposed to the, not only the infrastructure,
222490	229870	but the risks that are associated with this. So next slide, please. So one of the things that
230970	238290	I noticed throughout the years, and me and Jose have been researching on, is that when you use
238290	246290	this set of principles and divide it in things that are called tool chains that go in the DevOps
246290	255410	process, there's a number of products and a number of tools that are constantly used, reused, shared
257350	267890	and repurposed. One of the characteristics of the, to say in a certain way, the platform that is
267890	276250	for development, software development is at times his ephemeral character, meaning for example,
276250	283630	that you can create containers, destroy them and then simply recreate them again. So in order for
283630	290770	us to give this a little more structure into what we can look at when we're trying to gauge the
290770	297310	disposal and risks associated with DevOps, we had to look at DevOps tool chains. And DevOps tool
297310	303130	chains basically are a combination of tools that aid in the delivery, development, management of
303130	309130	software and applications for the entire cycle. As you saw previously, there is an actual cycle
309130	317370	where you code, you build, you plan, release, you test it and then you go back again. And if you are
317370	324050	for example, in a specific methodologies, for example, Agile, usually there are sprints and
324050	330730	sprints are sets of times that you have to produce a number of features or bug fixes. And all of this
330730	338170	is based in a flow that goes through what they call the tool chains. So in the tool chains,
338170	343210	you can see there are things that are used for planning, such as Git or Jira. There are things
343210	352390	that are used for coding that involve coding, code repositories. There are things used for
352390	363010	testing that implicate things such as Selenium or Bagram or Docker containers, for example.
363010	372150	There are things that are tools that are made for software build, such as Ansible or Terraform
372150	378790	or Chaff. And then of course, there are things that are within the tool chains for what they call
378790	385910	deployment, which imply things such as Kubernetes. In Docker, for example, most of these things
387010	393970	like Kubernetes at times are throughout the entire process. And depending on your
395670	405770	cloud provider, you may be very familiar with some orchestration automation languages such as
406490	414750	Ansible or Terraform. And then finally, part of this tool chain is the monitoring part. And then
414750	422830	we have things usually the main two monitoring tools are either based on EOK, which is Elastic
422830	435430	Search, and of course, Blunk. Next, please. So once we have seen the picture of the two chains
435430	444670	that are associated with the software development, plus the cycle throughout the flow of planning it,
444670	448310	coding it, building it, testing it, releasing it, and then coming back,
448310	454390	there's one thing that we're focusing today, and that is credentials. Credentials are part of the
454390	463330	entire process. Credentials are needed for many reasons. And here's a little bit of some of the
464370	472310	highlights of what happens in this process with credentials. So developers, for example,
472310	479370	usually have high privilege credentials. Why? Because they had to be able to test things that
479370	486430	would run with low privileges. They are supposed to develop things that may be
487030	494530	kernel libraries, sockets that need to be created with services or connections.
494530	504010	These environments at times are usually ephemeral, like I said, and as a result of that,
504010	511390	many times they're dismissed and poorly monitored. We're seeing cases of developers
511390	518590	downloading anything from Docker Hub or who knows what have you, a container repository on the
518590	524770	internet and simply putting them in their DevOps tool chains without any checking, without any
524770	532010	scanning, and now you may have implanted containers, vulnerable libraries, vulnerable
532010	538750	operating systems that will eventually affect and be published into your production environment.
540070	546510	Obviously, this is related as well. There's a disconnection between development and security
546510	554590	operations. I've been part of this problem many times and I have interacted with developers.
554590	559990	Developers usually don't like when you tell them that their code has bugs or vulnerabilities.
561270	566150	Most of the times there's not a straight link in between what they're developing, so I'll give you
566150	571830	an example. You have a development department and they download, for example, all these containers
571830	579090	or libraries or code. Many times there are no tools to verify this. Many times there are not
579730	585010	inventory of what is it that they're downloading, what is it that they're using, what libraries
585010	595570	they're putting into the software packages. So this by itself is a risk. And as well,
595570	601130	this is also very popular and this is part of the nature of the DevOps process.
601130	609550	There's a spread use of open source tools and code. So basically, many times I notice in this
609550	616050	environment that this code is trusted by default, meaning they just go, oh, I know this developer.
616050	621850	Oh, I know this group. I'm just going to download this and use it in my application. And again,
621850	628150	this goes back to the disconnection, but there is some sort of an honor code between the open
628150	636090	source community where do no harm is always the driver of software development. But it does not
636090	643110	mean, and we have seen this in supply chain attacks, that malicious actors, nation states,
643110	649350	criminals in general, may target these repositories, these open source communities,
649350	657370	and embed by stuff in it. Also, embedded credentials usually end up in public repositories
657370	665130	and that's pretty much what we're going to show you today. How even big companies, how individuals
667390	676590	that... unfortunately, there is no mechanisms. All in all, we don't blame them for what you're
676590	682410	about to see. We don't think that they're purposely leaking these credentials. However,
682410	688310	it is important that we point this out in order to bring awareness that there has to be
688310	696310	mechanisms created in order to avoid the rampant, because there's no other name for it, this rampant
696310	704910	leakage of credentials. And we will show today how bad it can get. So when we have also
705550	714610	dev development departments and DevOps processes, where most of these developers have
715010	723210	high privilege credentials or permissions, there is obviously a higher risk of insider,
723210	730890	because it takes less of an effort to cause harm, to embed malicious stuff in it, or to even destroy
730890	736870	it. Like we have seen in some cases before where a person that was part of a development department
736870	746370	has come back or a system has come back and do harm to an employer. And another couple of points
746370	757430	is that due to the CSD nature, the continuous delivery, basically that cycle that goes around
757430	767630	building, testing, developing, and coming back to planning and on software, these things
767630	774030	get published immediately. That's one of the nature of the DevOps process, is the DevOps
774030	784130	process has shortened the time where you plan, co-build, test, release, basically becomes something
784130	791350	almost immediate that goes into production. And this by itself represents a risk, because when you,
791350	800030	like I told somebody, when you have vulnerabilities in environments that are
800610	805330	driven by CICD and things like, for example, implanted container, and you have very large
805330	811650	environments, the risk and the opportunity of exploitation increases in orders of magnitude.
813290	819750	So finally, and just to put this, to make this even worse, unfortunately, the cloud
819750	825050	environments have made this risk even higher. Why? Because basically you are connected to the
825050	834430	internet, you publish right away, you stage right away, and if there are attackers that are
834430	841090	knowledgeable and are able to pretty much footprint your process, they can do a lot of harm.
841090	848010	Next slide, please. So here's a little bit for you to have a reference of how
848830	856330	the cloud providers manage credentials. We're going to focus mostly on cloud-related environments.
856330	864750	So here's, for example, AWS, they have their own AIM credential service, which usually
864750	873850	have things such as passwords, access keys, key pairs, or SSH keys. And also they do have a number
873850	883370	of temporary security credentials that can be created on the go, and that sometimes have a
883370	890550	feature, whereas you can give a specific user access to, temporary access to a resource that
890550	898930	otherwise that user does not have access for. So next up. Most of the providers have had
898930	907710	sort of similar systems for managing credentials. However, I had to give kudos to Microsoft because
907710	914830	they are trying actually to tackle this problem. And as you can see here, they do have, this is an
914830	923850	example of how they manage credentials. They use the Azure, there's a framework within Azure
924790	935210	Active Directory where it tries to avoid the embedding of creds, and they use a different
935210	943790	mechanism. We're not going to focus on this feature of Azure in this talk, but it's important for you
943790	949810	to consider it and look at it because they definitely seem to be aware of the issue.
949810	959430	Next slide please. And then here's, we wanted to give you a little sample of basically what's
959430	967070	happening with the three main cloud providers, which is AWS, GCP, and Azure. In the case of
967070	975270	GCP or Google Cloud, they are, most of the stuff is based on OAuth, which is a
975270	983470	protocol that's used for identity federation and single sign-on. And for the most part,
983470	991830	because of the constant interaction and services that are present in cloud environments,
991830	999190	obviously these providers have to come up with a way to allow the interaction of either devices,
999190	1005590	users, and services, dividing and trying to establish boundaries between these entities.
1005590	1021810	And as we will see soon, this is very challenging. Next slide. So here's a general,
1021810	1031390	that are usually used and as such, potentially exposed when you have developers that are
1031390	1040630	publishing or storing code in public repositories. So things as email and password, username and
1040630	1047650	password. Remember, there's a difference between your local, for example, Active Directory or LDAP
1047650	1057890	and the cloud identity access management. Sometimes this brings up a lot of confusion.
1060290	1066790	And depending on the integration that you have with your cloud environment, this may or may not
1066790	1073190	play in your favor. Meaning, if you're not very integrated, losing, for example, the username and
1073190	1080250	password from a specific cloud service will not allow the attacker to access your internal
1080250	1091270	environment. Also, multiple factor authentication is something that's been coming and at times it
1091270	1099870	can be bypassed by certain frameworks. We've done some work before with Evil Jinx, which basically
1099870	1108530	is able to capture the second, the authentication or the TLTP, whatever interface is presented to
1108530	1114730	the user and bypass MFA. Access keys, we talked about it. Key pairs, we talked about it.
1114750	1123770	Specific account identifiers and at times they use x.509 certificates. Next up.
1125150	1134110	So, what are the primary source of leak credentials? Well, as you will see soon,
1134110	1142370	GitHub is probably the most popular code repository on the internet. GitHub is now used for many other
1142370	1151870	things, storing files, even hosting web pages, which is kind of cool. So, GitHub is like the
1151870	1160770	reference when it comes to the leading internet code repository, not only publicly, but many
1160770	1166870	companies use it. And then we also have GitLab and we also have Amazon S3
1170550	1177550	buckets, storages, because the reason why I put this here is because you can definitely search
1177550	1185290	for Amazon S3 buckets that are open or have writing or read privileges. And there's not
1185290	1194530	only data stored in it, but tons of code with possibly embedded keys are usually found in this
1194530	1203810	environment. Next up. All right. So, as I was explaining with GitHub and GitLab and even S3
1203810	1212930	buckets, they're not just the only source of leak credentials. As you can see right now,
1212930	1221470	I basically Google, Google dork, aka, which is usually how Amazon permanent keys start.
1221470	1227150	And I was able to find the snippet. Fortunately, the person that posted this sanitizes keys,
1227150	1232850	but that doesn't mean this happens all the time. And with this, I just wanted to show you an
1232850	1238690	example that it's not just code repositories. It can be anything. I actually had a friend that
1238690	1247110	lost his username and password for his Gmail and it turned into an absolute nightmare.
1247150	1253510	The attackers actually reset everything he had and it took him like a week and even him being
1253510	1258790	part of the community to get a hold of Google in order to reset this. So, please be very careful
1258790	1266950	with these things. And that was a... my friend was working for a very large company, but there
1266950	1272030	are other examples that we're going to show you where the attacker may not be so obvious,
1272030	1276330	yet cause even more damage. So, let's go on the next one.
1277990	1285310	So, before we can continue on this presentation, it is important for you to understand
1286010	1296970	that when we look at the context and nomenclature of attacks on the internet, on the cloud, or inside
1296970	1304810	the perimeter, we always look in a MITRE cloud attack matrix in this case. Like I said before,
1304810	1310570	we were going to focus on cloud-related type of environments. So, in this case, we're talking
1310570	1316030	about basically unsecured credentials. Unsecured credentials, for example, if you leave a credential
1316030	1322870	in an Amazon S3 bucket or it's embedded in some code in GitHub, can lead to things such as what
1322870	1327770	is called valid accounts. And valid accounts can be used for initial access, persistence,
1327770	1336030	lateral movement, and privilege escalation. And I'm going to give you an example of it as we move
1336030	1342170	on in this presentation. So, just keep this in mind. So, let's move on.
1344110	1356670	One of the things that we're looking at here is a technique which is T1078.004,
1356670	1365190	which is valid cloud accounts. So, you're obtaining cloud accounts that basically,
1365190	1371450	in one of the scenarios that we're going to propose, we're able to find access keys that
1371450	1377870	then allow you to not only access the provider, but move laterally and escalate privileges.
1379710	1388490	These attack vectors are real. And many times, they get dismissed because the company,
1388490	1395810	and being honest to you, they do not have an awareness of the reach of the cloud within their
1395810	1402330	perimeters. As we move on in the cloud adoption, there is many hybrid environments. And in these
1402330	1408490	hybrid environments, parts of your cloud infrastructure would allow access to your
1408490	1414650	perimeter, either because the developers do it or because you are in IT operations,
1414650	1420730	and there are some servers that have some access to S3 buckets, for example, or you have a WAN,
1420730	1426770	or you have a cloud VPN. So, these are scenarios that are important to consider that are real.
1426770	1432150	There is the line between the perimeter and the internet gets blurred or even disappear
1433230	1439510	with the adoption of cloud technologies. And here's an example, something that you should read
1439510	1446870	on. I know this is an evolving framework, and we may be giving you a number that will change
1446870	1452210	tomorrow or even the definition of it. But it's important to understand that there is some work
1452210	1457710	associated with these attack vectors and these vulnerabilities. And this is what we're trying to
1458270	1461610	showcase today. Next, please.
1462470	1473150	So here, as I set the stage, I wanted to give you a little bit of an example and something that
1473150	1479290	we are actually working right now, and we will be presenting more research in the future, which is
1479290	1487030	lateral movement and escalation of privilege by simply obtaining keys, right? You can obtain
1487030	1496930	keys. Jose and I did a presentation, which was called Red Teaming DevOps in the Mayan Summit of
1496930	1503890	Red Team Village, where we explained ways of either phishing or finding these credentials,
1503890	1508180	which we're going to show part of it today. But for example, if you were able to get...
1509450	1514850	sure if you remember how I was able to go Google for a permanent keys,
1514850	1521550	AWS, which is started A-K-I-A, you can do things as you can, depending on the actual
1523770	1531090	user, you can even create new trust role policies, you can add yourself to role trust policies. So
1531090	1537950	for example, let's say there was a trust policy that allows you to access certain buckets where
1537950	1546330	there is sensitive data, you will be able to basically access that data by simply starting
1546330	1553390	from the compromise of these keys, or you can create temporary keys by either STS assume role
1553390	1560350	or get session token, it will depend on the policies that are in place and the privilege
1560350	1569210	of the users. However, this is not... the boundaries are not that strict. And because
1569210	1575870	this is an evolving and new technology, it's not that difficult, or far fetched to say that if
1575870	1582110	you're able to get a permanent keys that have been leaked on the internet, you might be able to
1582110	1588670	basically go around in its specific environments. So here's an example how you can have used tokens
1589390	1597330	specifically in AWS by either obtaining permanent keys or compromising a session
1597330	1604350	where they're already using temporary keys, which usually start with ASIA. And then from there,
1604350	1610290	you can have used temporary tokens using things such as assume role. Assume role is a
1610290	1617210	cross account feature given by AWS to, for example, provide temporary access to a user to a
1617210	1623490	resource that he may not have access to, or things like get session token, which are permanent,
1623490	1630170	temporary, sorry, temporary tokens that can be used for specific features. So please be on the
1631210	1639590	lookout for these things because they are... this has not really exploited as publicly available,
1639590	1646370	but it's definitely something that is happening right now. To next, please. And with that,
1646370	1650090	I'm going to pass it to Jose, and we're going to see an awesome demo.
1651610	1659510	Hey, so give me two seconds here. I'm going to go ahead and share my terminal as well as the slides.
1662550	1667990	Let me know when... Rock, can you confirm you can see both the terminal and the slides?
1669850	1676730	Perfect. Okay. Sweet. So I want to do a demo live today, if everyone's okay with that. I don't
1676730	1681350	usually do this, but I'm so confident that... again, I'm so confident about how comfortable
1681350	1686450	this tool runs and finds leaks. I want to do it live. And what I'm going to show in the demo today
1686450	1694150	are basically three basic steps of how you would use GitLab, the tool that we built to find new
1694150	1698950	credentials in GitHub. The first step is going to be installing it and deploying it. The second
1698950	1703530	step is going to be searching for leaked AWS credentials. And then the third step, we're going
1703530	1709090	to just really quickly dig into that data that is generated from one of our searches for hunts.
1709370	1717290	So the tool, I already have the tab here prepared. The tool is on GitHub. Unsurprisingly,
1717830	1722250	literally, we're searching GitHub for leaks, and we're also using GitHub to host our code
1722250	1728370	on their DBS1 GitHub. So I'm just going to go ahead and just clone the project really quickly
1728370	1737510	here. And that's going to bring our project down. I'm just going to get back to our slides.
1738750	1746250	So just a few notes. Again, going back to just... while this is cloning down, to Brad's point,
1746250	1752450	this leaking credential is totally normal. I've actually made these mistakes before. I've been
1752450	1759830	in incident responses where colleagues have made these mistakes. It happens, and there's
1759830	1764390	very few mechanisms today out of the box to protect it, but there are good mitigation mechanisms
1764390	1768970	out there. Again, to Brad's point, it hasn't exploded yet, so it's not actively
1769610	1774730	being mitigated for either. So here we go. We've cloned down GitWell Hunt,
1774730	1779450	and the first step to install it is... I'm going to go prepare a virtual environment,
1780970	1786690	and I've used VirtualM for this. So we're creating a virtual environment in Python 3,
1786690	1791250	and this is just in order for us to install all of our dependencies separated from our system Python.
1792170	1795570	And so the next step here is I'm going to activate my virtual environment and then
1796250	1804710	install my required dependencies for the project. The project is pretty lightweight. There's not a
1805650	1812390	lot of dependencies. And now I have a... yeah, the tool should execute just perfectly fine.
1812390	1817350	And the tool is pretty straightforward. There's a config file that you really don't have to do
1817350	1827890	much with it besides configuring the actual GitHub API token. So now that we've configured our token
1827890	1833290	in there, we should be ready to go. And what I'm going to do here in this case is I'm going to
1833290	1840470	use one of the example searches that the tool already has out of the box. By the way, the tool,
1840470	1845250	actually, before I jump into running it really quickly, let me walk you through how the tool
1845250	1851110	kind of functions. The first function of it is you pass it a search parameter, and this is the
1851110	1857810	equivalent of a GitHub advanced search. And we have a few examples in here, like how to find
1857810	1866750	GCP JWT tokens, AWS API secrets, Azure JWT tokens, so on and so forth. And then once,
1866750	1872870	what it does is it's going to go ahead and search GitHub for files that match these patterns. And
1872870	1877710	then it checks, it reads every single file that returns in the results, and it checks whether
1877710	1886710	that file has a valid credential from a set of regexes. And by the way, huge kudos and credits
1886710	1891490	to Trufflehug, which is the project we're actually borrowing a lot of these regexes from.
1891830	1895850	But it's basically a two-step function tool, right? First, it searches for
1896710	1899590	potentially leaked files, and then it verifies that inside those files,
1899590	1906370	you actually have credentials in them. In this case, again, let's try to run an example for
1906370	1914650	pulling back AWS secrets, right? And so once we run it, the first thing we're going to get back
1914650	1921550	is the total results that we found in GitHub for files that match this. And then you're going to,
1921550	1925510	the tool's going to go ahead again and process every single result, right? And it's printing
1925510	1932130	out here the actual URLs, checking whether there's actual credentials in them. And here we have our
1932130	1939330	first kind of hit from Bill Rosey, where he actually committed an AWS secret. And if we
1939330	1946990	actually go into this URI, we should be able to see his AWA access key. I'm just going to open it
1946990	1952670	here in my browser, and yep, there you go. That's literally his secret key, and it's out of the EU
1952670	1960330	central region. So as I explained earlier, with this key, we literally have the exact same
1960330	1967990	permissions that Bill Rosey had in managing AWS. And so the tool, again, the tool runs,
1967990	1972550	and it's going to take a few minutes because there's 200 something results, right? We're about
1972670	1979590	a leap number five, 95. And it collects all this data and saves it into a JSON file, essentially.
1979830	1987690	Now, while the tool is running, I want to go ahead and show you a bit of... so we grabbed the data
1987690	1991670	out of this JSON file. I'll show you at the end of the execution what it looks like. But we grabbed
1991670	1997290	all that data. We've been collecting these leaks for about seven days now. And I pulled some quick
1999110	2005270	reports on what we've collected so far in the past seven days. And for example, for top leaks
2005270	2013070	or top leaks by technology, we have by far a whole lot of AWS API keys out there that we've collected
2013070	2021170	and second to that is GCP actually service accounts. I couldn't say I wasn't... this did
2021170	2024370	not surprise me. I don't know, Rod, if you got surprised when you saw this data set, but this
2024370	2029230	was kind of somewhat expected. AWS by far is the secret that gets leaked the most.
2030330	2034830	Somewhat surprising, there's still a lot of private keys for ISA out there, which I was not
2034830	2044690	expecting. Another thing that, again, just another curiosity is that AWS secrets, if you break this
2044690	2052410	down by the last seven days, it doesn't vary a whole lot. It seems that by far, again, AWS seems
2052410	2059610	to be the normal thing that gets leaked the most, second to GCP. Although what they call
2059610	2065790	YouTube OAuth tokens or the tool calls YouTube OAuth tokens are actually generic OAuth tokens as
2065790	2071630	well for Google. It just considers it like a specific YouTube one, but it's not. And so you
2071630	2078470	can see that actually varies every so often across days. And so for the most part, people are either
2079090	2084470	leaking their Google suite tokens, which is really what the YouTube OAuth token are,
2084470	2089790	or the GCP tokens, which is pretty bad because, again, now you have full access to whatever they
2089790	2099770	can do with Google on their account. We did a breakdown as well by top companies. And mind you,
2099770	2106330	where this data comes from is that if the user, because we're searching GitHub, and GitHub gives
2106330	2111770	users abilities to input things like what blog they have, what their Twitter handle is, and the
2111770	2117010	profile, and what company they work for, we pull that information back when we have a match,
2117010	2124490	since that's open data. And this is just a very, very ugly picture of what the most credentials
2124490	2130750	by company that we collected were. X by Orange is by far the company that leaked the most,
2130750	2133930	or at least that was labeled to leak the most, but we got some pretty big ones out here like
2133930	2142530	Nordstrom, VMware, and again, these are the top. You see here the other flag that means that
2142530	2148250	there's a bunch of credentials that were leaked, but not necessarily multiple of them. These are
2148250	2155710	multiple credentials for some of these companies. Microsoft was in there. Yeah, pretty bad, at least
2155710	2163910	to say. Yeah, so this is very revealing because many times, and it's like what Jose was just
2163910	2170370	saying, there just doesn't seem to be awareness of how bad this is. And we're trying to show you
2170550	2178130	a picture of we collected, what, a week or so, and look all the stuff we have. And we actually,
2178130	2186730	we basically did this for analytic purposes and to show awareness. We could have
2186730	2192270	delved even deeper into this data, and who knows what we would have been able to get. And if we are
2192270	2197210	doing it, bad guys are doing it too. So that's, that's, this is something that's very remarkable
2197210	2202650	that you see some big names in there. I understand there is a number of mitigation issues, like you
2202650	2208350	can say, well, you can get my key, but if your IP is not in my security group, you will not be
2208350	2216310	able to load again. True, but we don't know that. And the fact that you prove that, or the, those
2219250	2225210	keys are being leaked, it opens the possibility. It's almost like an open port. That's how I see
2225210	2228910	it. It's almost like an open port of a vulnerable application.
2230190	2235470	And one note I wanted to say on this data also, and it was a really good point about this. This,
2235470	2241790	again, because this is what individuals have put in their company profile. We, there's some garbage
2241790	2248350	in here too, like this LinkedIn profile or ABC, which we necessarily haven't cleaned out of our
2248350	2254650	data yet. But this is straight up, again, the users that we collected or we've seen leaks for,
2254650	2260150	what companies have put in their profile. And again, we also kind of want to break this down
2260150	2267570	by region. My favorite region so far that users have listed is in your heart. This is pretty sweet.
2270570	2274470	But unsurprising, and actually, Rod, you made this point to me, unsurprising.
2274670	2282070	There is big cities that have a lot of development footprint, right? Like a lot of developers and a
2282070	2288610	lot of huge tech footprint are showing up here, right? New York, New York, Santa Monica, San
2288610	2296550	Francisco, Sweden, Russia, Pittsburgh, right? So again, the cities that typically have huge
2296550	2300930	companies at the development are a lot of developers. And there, again, the data,
2300930	2305970	we haven't really cleaned up the data, hence why you have in your heart in here. But I just want
2305970	2310930	to give you a really rough view of like, what if we were just trying to aggregate this really,
2310930	2314310	really quickly, and we did it for seven days, what it looks like.
2314310	2323410	Right. And if you were targeting a company, right, which is where you and I were talking yesterday,
2323410	2330890	we can hypothesize that by the number of leaks, and if we reduce that to the regions, because we
2330890	2335310	know where most of the developers are working, even though that's changing a little bit because
2335310	2340890	of the work from home, that sort of cuts off a little bit of the work that an adversary
2342070	2350130	needs to do in order to try to infiltrate one of these big companies that by omission or
2350130	2359030	by or willingly may have developers that are posting keys that are revealing too much.
2360330	2365210	That's true. By the way, our tool finished here. I just want to give
2367210	2375930	the viewers here a quick preview of what the results file gets written as. So if I just,
2376810	2381890	since this is a valid JSON, you can see here the data we're collecting, right? So again,
2381890	2389210	we're dumping every result that's getting matched into an array of JSONs here, or actually
2389210	2394830	various JSON objects, and we collect a URL where we found the leak that checked that it actually
2394830	2402270	matched the different matches, right? So in the matches, I purposely went out of my way to not
2402270	2410030	necessarily store the actual secret, but merely just the keys if possible. The owner, so who owns
2410030	2415870	that repository that leaked that credential, owner URL, the type, again, if it's a company,
2415870	2422930	it's going to get listed as a company. The name, email, again, if they listed the company in their
2422930	2427250	GitHub profile, it's in their blog, the location that they got listed in, this is where this data
2427250	2432710	is coming from over here, Twitter handles, so on and so forth, right? And again, some of these
2432710	2440710	fields tend to be null if the users don't allow their profile in GitHub to show this data. That's
2440710	2449670	the only way we can actually read it. But yeah, again, pretty telling dataset. And with that,
2449670	2468800	I kind of want to talk about one example that stood out to the CEO of a telecom. It was pretty
2468800	2477540	wild that, again, because the CTO had listed on his GitHub profile, his Twitter handle,
2477540	2483020	as well as his personal blog site, we were able to find his LinkedIn and essentially...
2483800	2488880	Pretty much everything. We found pretty much everything about this gentleman. And
2491380	2498240	obviously, we have sanitized everything, so you can't find him yourself. But just like him,
2498240	2504580	there's many, many cases of people that we found. Right, it's just an example.
2505080	2508540	We've contacted them, again, to clean things up. Our intent is to make sure these things stay
2508540	2515340	clean up. Again, we want to bring awareness, as this is a big issue. And again, I've made these
2515340	2520900	mistakes in the past, but this is how bad things can get, essentially. Right?
2522160	2527560	You can go for a simple... It's amazing that you can go for a simple key to pretty much everything,
2527560	2537720	from a leak key to opening the doors of your company, revealing your personal life,
2537720	2543760	personal things. So, please be careful with these things and try to implement some measures.