[00:00.000 --> 00:07.300]  I'm going to start with the reason why we have went ahead and open sourced this project.
[00:07.420 --> 00:16.200]  So before that, welcome to DEF CON SAFEMODE. And about myself, I'm Setu Parimi. I'm a cloud
[00:16.200 --> 00:22.560]  security architect working at Grumman-Foster. And my full-time job is designing and deploying
[00:22.560 --> 00:27.940]  enterprise security solutions as a security consultant. And in my free time, I just work
[00:27.940 --> 00:32.600]  as an independent security researcher with my interests completely towards the cloud
[00:32.600 --> 00:40.180]  native technologies. I'm a cloud member at CloudVillage and coming to the storyline which
[00:40.180 --> 00:49.120]  I was mentioning earlier. So a few years back, the ACME Corp is my friend and all his applications
[00:49.120 --> 00:57.920]  are on-premise. And then he started using AWS. And after that, the cyber team gets notified
[00:57.920 --> 01:04.500]  about it. So when the cyber team gets notified about it, what happens is the cyber team is
[01:04.500 --> 01:12.500]  just wrapped up all the enterprise security controls for the organization. And then the
[01:12.500 --> 01:17.240]  dev folks will come to the cyber team and then they notify like, hey guys, we are just moving
[01:17.240 --> 01:25.660]  all our apps from a data center to the cloud. And a few months later, what happens is there
[01:25.660 --> 01:31.120]  is another business unit like an infrastructure team who are interested in Office 365 and Azure
[01:31.120 --> 01:37.080]  AD, all this other stuff. They want to move to Azure. So now it is on-premise data center and
[01:37.080 --> 01:44.240]  then we have an AWS environment and now the third one is Azure. So again, the cyber security team
[01:44.240 --> 01:52.100]  will be late to the party as usual. So they get notified at the end of signing the NDAs and all
[01:52.100 --> 01:57.580]  the other stuff. Once the cyber security team gets notified, the cyber security team would be in a
[01:57.580 --> 02:03.080]  situation like they have worked so hard in the past few months to go ahead and implement several
[02:03.080 --> 02:08.220]  security controls in cloud. There will be a huge learning curve and all other things. And they just
[02:08.220 --> 02:15.520]  wrapped it up and then the infra team says like, we want to go ahead and move our
[02:15.520 --> 02:21.800]  on-premise exchange boxes to Office 365. We want to move from Skype to Microsoft Teams.
[02:21.800 --> 02:27.880]  We are going to Microsoft Azure. You guys have to secure it. And then the cyber security team
[02:27.880 --> 02:34.260]  has again a learning curve. They go ahead and secure it. So it keeps again. The third team
[02:34.260 --> 02:39.020]  is something like a business intelligence team. They say like artificial intelligence modules
[02:39.020 --> 02:45.600]  services are good in GCP. So they start using GCP and every business unit has their own reason
[02:45.600 --> 02:55.360]  to use their own preferred cloud provider. And the situation gets in a way like an organization
[02:55.360 --> 03:03.500]  with like 50 to 60 applications will be having like four to five public cloud providers. And
[03:03.500 --> 03:10.680]  it's a nightmare for a security team to go ahead and manage the security for all these public
[03:10.680 --> 03:17.640]  cloud providers and also maintain the shadow risk and all the other stuff. To make the scenario a
[03:17.640 --> 03:24.960]  bit more complex, what happens is the dev folks, the DevOps folks, they go ahead and follow
[03:24.960 --> 03:33.160]  something called an environment-based hierarchy. So the resource hierarchy in AWS is something like
[03:33.160 --> 03:40.080]  you can go ahead and have one account for dev, one for prod, one for staging. Again, one for
[03:40.080 --> 03:45.340]  UAT. So they have like for a single application, they have three accounts. And when you think
[03:45.340 --> 03:52.280]  about like an enterprise scale, you grow from three to five AWS accounts to 100 to 150 AWS
[03:52.280 --> 04:00.120]  accounts very quickly. It's same with Google Cloud or Azure. So the resource hierarchy makes the
[04:00.120 --> 04:07.020]  security monitoring a bit more complex and it increases the shadow risk of an organization.
[04:08.440 --> 04:15.000]  So to explain a small problem, it's like we use a lot of open source tools to go ahead and identify
[04:15.000 --> 04:21.860]  the security vulnerabilities across multiple cloud environments. The first issue is like we have
[04:22.480 --> 04:26.540]  multiple accounts, not one account. So we need to go ahead and run the scripts, the open source
[04:26.540 --> 04:34.040]  tools in multiple accounts. And an example is like the tool identifies a security group, which
[04:34.400 --> 04:40.180]  is indicating that all the ports are open to the internet and it's in the DMZ environment.
[04:40.520 --> 04:48.580]  So the cyber team goes ahead and identifies what are the instances behind that security group and
[04:48.580 --> 04:55.460]  they come to know that this is a dead security group. It's an idle security group, which is
[04:55.460 --> 05:02.240]  some developer or someone else forgot to delete it. So there are a lot of challenges like this.
[05:03.080 --> 05:09.640]  And always my dev friends always love to go ahead and make all the admin services open to
[05:09.640 --> 05:19.060]  the internet. So that's another challenge as well. So this is just one service. How big can it get?
[05:19.060 --> 05:24.300]  Like how many services are there which can be open to the internet and which can act as a shadow
[05:24.300 --> 05:30.580]  IT services or shadow IT resources in an enterprise environment? There are a lot. And just for a
[05:30.580 --> 05:37.960]  high-level example, there are several services, popular services, which are being used and the
[05:37.960 --> 05:44.640]  resources in these environments can be easily made public. And there is a huge gap in terms
[05:44.640 --> 05:53.000]  of security monitoring, whether this resource is public to the internet or not. This resource has
[05:53.000 --> 05:58.800]  authentication or not. Is this an API endpoint, which doesn't have any API key or any authorization
[05:59.360 --> 06:07.260]  requirement? So there are like so many other factors. And then to map all these internet
[06:07.840 --> 06:15.160]  resources, what I used a lot is to go ahead and use a few tools like Perimeterate and
[06:15.160 --> 06:21.360]  SmogCloud, CloudMapper, my favorite one. And for Google Cloud environment, we started using Force
[06:22.000 --> 06:29.260]  So the first one is, it goes ahead and periodically scans all the AWS internet services
[06:29.920 --> 06:34.540]  and it identifies the resources which are public to the internet, which are exposed to the internet
[06:34.540 --> 06:45.440]  and it gives a very beautiful JSON format data at the end. So I just, what I do is like,
[06:45.440 --> 06:51.160]  I just collect the data and then upload it to our tools like Shodan Monitor, where we always
[06:51.160 --> 06:57.440]  monitor for vulnerable ports or admin ports being exposed to the internet. And we get email
[06:57.440 --> 07:03.540]  alerts and the SOC team or the incident response team follows up. So the other tool is SmogCloud
[07:03.540 --> 07:10.120]  and Perimeterate and CloudMapper. These three are for AWS. And the fourth security is for Google
[07:10.120 --> 07:18.380]  Cloud. And it's a bit more complex to use. And it's really huge as well. Setting up is easy,
[07:18.380 --> 07:28.240]  maintaining is a bit tough. So the coverage is just, there are open source tools available
[07:28.240 --> 07:35.800]  for a few AWS, I mean, few cloud providers. And there are, these open source tools are
[07:35.800 --> 07:43.200]  offering, I mean, supporting only limited number of resources. So these are the primary challenges
[07:43.200 --> 07:48.800]  that we have faced. Like, if we want to use an open source tool, the open source tool should be
[07:48.800 --> 07:55.320]  going ahead and scanning all the environments, like multiple environments on a periodic basis,
[07:55.320 --> 08:01.480]  without we going ahead and manually running those scripts on every account by switching the roles.
[08:01.480 --> 08:06.730]  It's a complex work, right? And a single tool should be able to monitor multiple clouds.
[08:06.730 --> 08:14.850]  And the third one is the IP addresses collected from all the public cloud environments should
[08:14.850 --> 08:20.510]  be easily ingested into a security monitoring tool, the internet attack surface tool,
[08:20.510 --> 08:26.170]  like short end monitor or something like that, to make sure none of the admin services are exposed.
[08:26.190 --> 08:36.710]  And it drastically reduces the shadow ID actually. So for that, what we did is like,
[08:36.710 --> 08:45.670]  build a security tool, which was initially called as Nightwatch, because my friends,
[08:45.670 --> 08:49.930]  the developer friends, a lot of guys are like, fans of Game of Thrones. So we went ahead and
[08:49.930 --> 08:55.650]  renamed it Nightwatch. And later, when we go ahead and try to create a repo and make it public,
[08:55.650 --> 09:02.990]  we saw that there are already 10 or 15 Nightwatch tools on the GitHub. So we decided like,
[09:02.990 --> 09:08.010]  we need a name change. And then we changed the name from Nightwatch to the Cloud Frontier.
[09:08.010 --> 09:14.810]  So that's how we went ahead and we built the Nightwatch. Nightwatch is a small project to
[09:14.810 --> 09:19.550]  monitor the internet attack surface of public cloud environments. And currently, the cloud
[09:19.550 --> 09:24.650]  providers that are being supported are AWS, Azure, Oracle, DigitalOcean, and Google Cloud.
[09:25.290 --> 09:30.870]  So to give a quick demo of the application,
[09:33.030 --> 09:38.390]  you just click on Get Started. And then you'll be able to see the most commonly used ports,
[09:38.390 --> 09:42.690]  and the administrative ports, and the vulnerabilities, and the total number of
[09:42.690 --> 09:46.250]  ports that are exposed to the internet that belongs to your organization, and the number
[09:46.250 --> 09:53.530]  of IP addresses. And when you click on the Internet Asset tab, you'll be able to see
[09:53.530 --> 10:02.110]  IP addresses, domains, object storages, data storages, API endpoints, content delivery networks.
[10:02.190 --> 10:09.790]  So the Cloud Frontier goes into each and every account, irrespective of the cloud provider,
[10:09.790 --> 10:14.710]  and then grabs all these internet facing assets. First of all, it checks for the internet facing
[10:14.710 --> 10:23.090]  assets, it grabs them, and then it populates it over here. So for each and every IP address,
[10:23.090 --> 10:31.190]  the score is provided, and a tagging, which helps to understand which environment this
[10:31.730 --> 10:35.710]  IP belongs to, and what are the port numbers that are already open.
[10:36.230 --> 10:44.270]  Then going to the domain section, we go ahead and we collect all the public domains of EC2 servers,
[10:44.270 --> 10:52.790]  or else Route 53 subdomains, Google Cloud DNS. And we go ahead and monitor all those domains for
[10:53.090 --> 10:58.710]  that. Let me just go back. Yeah, we just monitor those domains for security
[10:59.650 --> 11:03.970]  posture using Mozilla Observatory and Verisource as well.
[11:04.310 --> 11:11.910]  So the next one is the famous object storages. So the object storages helps us to go
[11:13.530 --> 11:21.190]  collect all the buckets, blobs, spaces, so from multiple cloud providers, and then
[11:21.750 --> 11:27.810]  provide a website URL if there is one available, and indicate whether this resource is public or
[11:27.810 --> 11:34.830]  not. So based on this, a security engineer will be able to go ahead and take some quick actions
[11:35.790 --> 11:43.450]  than drilling down the JSON logs or JSON data from other open source tools.
[11:43.810 --> 11:49.910]  And there are also, we have a lot of snapshots and custom-made images in the enterprise, I mean,
[11:49.910 --> 12:00.970]  our organization. So we decide to go ahead and have an asset collecting metric for the data
[12:00.970 --> 12:08.050]  storages, like if there is any RDS instance or any AMI, we go ahead and collect it, and then
[12:08.050 --> 12:13.730]  we indicate whether it is public or private. It's the same with the API endpoints as well.
[12:13.730 --> 12:18.550]  So we provide what is the endpoint, whether the API key is required or not for this endpoint,
[12:18.550 --> 12:23.570]  and what is the authorization, is it a Cognito authentication or it is anything, something else,
[12:23.570 --> 12:28.490]  Google Cloud Identity or anything else. So that kind of information will be provided for the API
[12:28.490 --> 12:39.530]  endpoints. And last is the content delivery network. It provides the CDNs, and it makes
[12:39.530 --> 12:45.010]  sure whether the CDN is enabled or not, and what the custom domain to which the CDN is being pointed
[12:45.010 --> 12:54.950]  to, and what cloud provider it is. So not everyone likes the light background, so there is a huge
[12:54.950 --> 13:01.310]  fan base for the dark theme. So you can just quickly switch from light mode to the dark mode,
[13:01.310 --> 13:07.710]  and then use the same features in the dark mode as well. My personal preference was dark mode, and
[13:08.410 --> 13:17.370]  yeah, it's pretty much that's it. So let me go to the next slide. I would like to go ahead and
[13:17.370 --> 13:25.490]  quickly explain the components of this tool. It has collectors, analyzers, and outputs. So the
[13:25.490 --> 13:32.390]  collectors are the lambda functions which go ahead and collect the public or internet-facing assets
[13:32.390 --> 13:40.770]  from multiple cloud providers. And the analyzers are the ones which go ahead and check whether
[13:41.430 --> 13:47.810]  the bucket is public or not, or the blob is public or not, or else it goes ahead and identifies
[13:47.810 --> 13:54.170]  whether there's an authorization key or API key enabled for an API endpoint. So all these
[13:54.170 --> 13:59.270]  kind of things will be analyzed. And then if there are like so many IP addresses, what happens is
[13:59.710 --> 14:03.730]  we go ahead and collect all those IP addresses and scan them against
[14:04.390 --> 14:13.190]  Shodan and the virus total. And if it is a domain, a Mozilla Observatory score will be provided.
[14:13.990 --> 14:18.970]  And it says we have an environment file which is pretty much like an
[14:20.330 --> 14:26.870]  input file where you go ahead and input the credentials of your cloud environment. So
[14:26.870 --> 14:32.810]  every cloud has its own environment file. You just have to go ahead and insert the access
[14:32.810 --> 14:37.370]  keys or else the JSON file, I mean the service account JSON file from Google Cloud,
[14:37.370 --> 14:41.310]  just insert it and then you should be able to go ahead and run this
[14:44.050 --> 14:50.970]  service. And currently there are quite a few supported services. And these are the services
[14:50.970 --> 14:58.410]  which have potential internet-facing assets. So all these services are currently monitored
[14:58.410 --> 15:04.610]  and analyzed on a regular basis. So you can always set cron jobs, like it's a CloudWatch
[15:04.610 --> 15:09.050]  rule. You just have to go ahead and simply trigger the CloudWatch rule as per your convenience.
[15:09.090 --> 15:13.430]  If you want to go ahead and make the CloudFrontier to run on a six-hour interval,
[15:13.430 --> 15:17.670]  you just have to go ahead and edit the CloudWatch rule to run it in a six-hour interval.
[15:17.670 --> 15:27.490]  So and these are my friends. So I just moved back to India and then I met new friends.
[15:27.490 --> 15:32.190]  I created the tool and then they are like very good developers who are interested in
[15:32.590 --> 15:38.290]  contributing to the open source community. So we all, I mean not just, we all
[15:38.990 --> 15:45.750]  didn't just have Biryani, but we also had built this tool for the open source community.
[15:47.190 --> 15:54.030]  And you can, yeah, you can access, the documentation is here. And if you see here,
[15:54.030 --> 15:59.010]  we just, yeah, as Jiren has mentioned like 30 minutes back, it has been published.
[15:59.050 --> 16:08.870]  And you can go ahead and review the documentation and have the access keys. I mean, you can go ahead
[16:08.870 --> 16:13.990]  and start using it. And in case if you have any issues or if you have any feedback or
[16:13.990 --> 16:18.690]  place for improvement, feel free to throw out the issues and looking forward for the
[16:18.690 --> 16:26.210]  contribution from the open source community. Yeah, we'll be available for any questions.
[16:28.530 --> 16:39.710]  Hey, just a quick question for me. What kind of, you know, access to the cloud
[16:39.710 --> 16:46.070]  environments does this tool require? So it's just the service accounts and the security audit
[16:46.070 --> 16:54.170]  view only access. Got it. Yeah. And it is documented here where for the Azure,
[16:54.170 --> 16:59.030]  just create an application in AD and then get the subscription ID, get the tenant ID,
[16:59.030 --> 17:04.090]  client ID, secret. And just once you get all these things added to the environment file,
[17:04.090 --> 17:09.170]  same with the solution, Oracle Cloud, Shodan and other API keys from where you can get
[17:09.630 --> 17:16.390]  the information. Seems pretty straightforward. If we wanted to disable certain lookups like
[17:16.390 --> 17:22.890]  VirusTotal or the Firefox one or Mozilla one, are we able to do that?
[17:24.370 --> 17:30.010]  I think there is a flexibility just like you have to just stop that analyzer from running.
[17:30.010 --> 17:33.930]  We have created multiple analyzers for multiple functions.
[17:33.950 --> 17:39.470]  We have an analyzer for Shodan, one for Mozilla Observatory. So you just need to go ahead and
[17:39.470 --> 17:44.890]  disable it. And once you disable that analyzer, I mean, it's not available in the front end,
[17:44.890 --> 17:50.130]  you need to just tweak it in the back end. And once this, because the entire stack is deployed
[17:50.130 --> 17:55.370]  to AWS, so it's not very tightly coupled and it's very loosely coupled. So the tweaks are pretty
[17:55.370 --> 17:55.790]  easy.