 Hey everyone. Thank you for joining me today on this webinar by CNCFQC. As we explore the topic of harnessing the power of Kubernetes actual scanning for improved security posture, my name is Karanjot Singh and I'm excited to be your presenter for the day session. Before we dive into the details, let's start with a brief introduction. As you know, Kubernetes is an open source container orchestration platform that has gained immense popularity in recent years with its ability to manage and scale containerized applications. Kubernetes has become the core to choice for many organizations. However, with the increasing adoption of Kubernetes, the security concerns have also surfaced. This is where Cubescape really comes into the play. So today we are going to see how Cubescape will help to increase your security posture in Kubernetes through network scanning. Before that, let me introduce myself. I'm Karanjot Singh. I love doing security and open source work. I've been a contributor to open source for five long time. I'm currently interning as a Google Summer of Code student at KDE. I worked previously as an Elefix Linux Foundation mentorship being done at CNC at Cubescape. We are worked over this project of Cubescape Network Stanner, which I'm going to showcase you to do. So for today's session, we are going to see what Cubescape really is and how it helps you to secure your Kubernetes security posture. Then we are going to see what is network scanning. Our network scanning really works inside codes and related use cases like network is network scanning really important. Then we are going to look into Cubescape Network Stanner and how it's different and there are a lot of other scanning in the market. What makes Cubescape Network Stanner unique basically its features. Then we are going to look into the engineering side of Cubescape Network Stanner like how Cubescape Network Stanner really works. Then there's this fun and interesting part which is a live demo where I'm going to showcase how we can upgrade the Cubescape Network Stanner to discover open ports and services. Then we are going to look into the future of Cubescape Network Stanner but the plans we have to future about its integration and the call to action. So after that, I'm going to summarize all these points and make a conclusion out of it or whether you should try Cubescape Network Stanner or not. Or how is it going to help you in your security posture. So what is Cubescape? Cubescape is an open source Kubernetes security platform which is also a CNC assigned box project. It helps in securing your Kubernetes clusters, CICD pipelines. It defines and enforces the best practices from frameworks like NSA, Mitre, and you can also build upon custom frameworks. So basically Cubescape provides Kubernetes arning and attacks of this reduction. It has really easy to use CLI which offers multiple output formats. It has also automated vulnerability scanning. Which helps to save a lot of time for Kubernetes user and admins. Basically, it's the best tool to have into your Kubernetes clusters to help you secure your clusters. It promotes a lot of misconfigurations and role-based access violations. So it's a really good tool to have. Then we're going to work into network scanning inside ports. So basically, as you can see, there's a Kubernetes cluster over here and there are multiple services running inside these containers inside ports. And you can see how everything is connected to each other. The QBDS server, QLED, the board, and DIN. So there could be a lot of hidden services which may be overlooked and are becoming hidden. So these services poses a great amount of risks. So these compromised services, if compromised, within a container can result in compromising the entire cluster. This is really bad. So network scanning is really essential. It is essential to identify these services which may be running vulnerable softwares or are vulnerable to some attacks. So we need a good network scanning with scanning services. So now we're going to look into the gaining access point. What if there is a service running which is vulnerable? How can I tag it with a shell? So let's assume that there's an attacker and there's a vulnerable host-based service running inside one of the containers within a port. So this vulnerable service, the attacker can gain access or shell inside the containers. Let's assume that the vulnerable service was using some older version or was set up with the default credentials. So the attacker can easily access inside the container. The attacker can also try accessing the community's API without the credentials. If the cluster is based on the previous release of Kubernetes which allow access to Kubernetes API without credentials. Then again, the attacker can try to look into other exposed services or scan the network. Like at-city because many people try to install at-city to manage network policies outside the fixer. So it is really possible that if an attacker gains access to the at-city and he can remove the network policies, then it's a piece of cake to gain control inside the Kubernetes cluster and compromise the whole cluster. So you see a point that we can't really have vulnerable software running inside the container. It's really dangerous for Kubernetes. So network scanning is really essential. We saw that. We saw what if an attacker gains a shell inside the container. It's really dangerous and it could happen because of maybe he itself is so vulnerable, so this is running inside the containers. So here comes the rescue, the CubeScape network scanner, which is a network scan and service discovery package. So the question arises, why? Why do we need CubeScape network scanning? And there are a lot of network scanners already in the market. What makes CubeScape network scanner really different from them? So I'm going to answer this in the next slide. This is this. So these are the really great features which makes CubeScape network scanner really different from those in the market. So there's no board mapping approach to discover services. Like more scanner uses a board service map to discover service. For example, like we know that for 4.4.3, it's running S2QPS. So many scanners try to find these open ports. If the open port is 4.4.3, they map it to S2QPS and show you that S2QPS was running over that. But it is possible that the service may not be running only. Maybe the person configured this board to run other service. It could happen like it's possible. So this service might get written and there might be false negation on the scanner, which CubeScape network scanner doesn't do because it uses a different approach, which involves pinging back the service and trying to identify if it's really that service run or not. So you can discover hidden services with a CubeScape network scanner. Due to above approach, more scanners will fail to find hidden services running on different ports. It will result in false negatives, whereas CubeScape network scanner is really good with this. Then again, if you look in the most scanners, they try to discover open ports and only the service is running. They don't tell you if it is authenticated or not, if it is an exposed service or not, if it's running a vulnerable version or not, or if it has default credentials set or not, which CubeScape network scanner does. So it's really a plus point for CubeScape network scanner that it helps to also tell that if the service is authenticated or not, if it is exposed or not. Then let's see the insuring behind CubeScape network scanner, what makes it different from the power box. So CubeScape network scanner is totally based on the OSI model, which you can see, and it's heavily involved. And on this, we basically use the transport layer, session layer presentation layer, and then the application layer. So it scans from layer by layer, from scanning from the transport layer to application layer. Try to discover services running on each layer. For example, if you are trying to scan a DCB port, it will tell us that the transport layer is running DCB. Then it looks for the session layer. If the authentication is enabled, like if there's a TLS configuration when it was not, then it results in TLS. Then it scans for presentation layer. If it's running STP or not, or GPRC, or any other service, then it discover the application layer, the service running on the application layer. So basically tries to maintain a seamless connection between layers, because each layer depends upon the previous layer. Like the session layer would depend on the transport layer, presentation layer would depend on the session layer, and application layer would depend on the presentation layer. So each layer depends on the other, and it maintains a connection. What also tells the version that is running, like for, if it tries to discover presentation layer, that's both in TLS and GPRC, then it tries to discover the version it is running on, and it might be a vulnerable version. So this helps to maintain an easy flow of discovering that service. And now let's start on the hands-on demo of this, and I'm going to show you how Cubescape.net works. So I'll show you the code demo first, like how the code looks and what is behind the Cubescape.net works, then I'll show you some practical demo with discovering service. So I had to discover three services, namely one would be authenticated, and one would be authenticated to show you how it tells if it is authenticated or not, or what properties does it provide. Also, just to make sure to tell you that Cubescape.net works scanner is still an all-in-level project, and still there needs a lot of development on it. It's just an idea that works really well. Okay, so this isn't a mean rubble for the Cubescape.net works scanner, it is a network scanner and service discovery package. We have to find the main interface and this interface store here. We have to find the numerous number of interfaces, strengths, and you can see functions to make it work seamlessly. Let's go inside the package. So inside the Cubescape network scanner package, there are two packages for discovery and service discovery. Let's first explore the board discovery package. So in the board discovery package, it is same as how the other network scanners for development using the nut library we are trying to edit. Okay, so it is used to scan only a single target. If you want to scan multiple targets, it is just this. Then you need to pass flights, like if you want to scan ECB and if you want to scan UDP. Or if you don't mention these, you basically scan both. So this is just a little go through those packets. We have tried to implement board routines in this using which the network scanner was pretty fast. And now the service discovery package, which does not speak, which is different from most of the network scanning, I mean, every network scanning. So we have in types where we have implemented the different interfaces. So, like previously, I was telling you about this in the how Cubescape network scanner works slide that tries to maintain a seamless connection. This is how it does that. We have defined a interface for every layer. As you can see, and basically each interface is dependent on the previous, like it is dependent on the session handle. Provide it with the session so that it maintains that session over the time to help other layers discover the service upon it. So if you can see it depends upon the previous layer, the session layer. And if you can see the application layer depends on the presentation discovery results. So, it maintains connection between each layer. Now the work campaigns. Our session where discovery is implemented. So it's just use the TLS library to create a config file and use a dialog to connect and discover that it is TLS. And then if we move to let's move to the main part, which is how it discovered the applications for each application. The discovery is different. Like if I show you the example of QB4. So you basically know you can access QB API by sending requests to some right. And if you can see it depends on the session layer and then also the presentation layer depends upon the presentation discoveries as well. So basically creates a secure client. Which connects which tries to connect with the QBPS server and checks the response code. So basically that was something which we observe that the kind foods kind header is set to API engines. When we detect the QBPS network. So basically then it is detected true and it's not authenticated. And if we look at another status post. So we basically scan the kind response in this too. And if the response header has kind. So basically it's detected it's QBPS server, but it does require authentication. So each discovery is implemented a different way. So these are the packages. So let's move to the demo part. We discovered practical service. So here, stop the QBS game. Okay. So basically you need to use the scan command here. So the scan command also switch flags does it means. So it needs a DC flag or UDP. And if you leave this out it will scan for both. And you need to add a host address or IP address or a list of IP addresses. You can also add the domain name. Rather than an IP address. You need to mention the ports. If you don't mention the ports. So let's try. Let's try to scan at city first. Let me start at city server. So I started at city server. And at city runs on 2379 port. If you can see variable to foster tries to identify votes. And then it tries to discover services on it. And if we know that at city doesn't chooses a session layer. It connects with the presentation layer which is at city P. Then it tries to discover the at city servers. And if it is authenticated. And then it returns true. And if you look at it. We are not able to get any properties because it is authenticated. That's like the security posture. So let's try to discover some of the service. What about. You will be a server. So you can see here. It's exactly the same results. The QB and the DC server is also authenticated. And you are able to discover the results. Now let's try to discover the last six search. And I've made the last six search unauthenticated. Okay. So we're not trying to scan. So here you can see the last six search is authenticated. It does not have any properties. It does not have any properties. It does not have any properties. It does not have any properties. So here you can see the last six search is authenticated. It uses the STP presentation layer. And we are able to get that it is not authenticated. That's why we're able to get these properties. That what is the name of the cluster. The cluster ID. And the name of the system. It's running. So that's how you can discover services with cubes. You can also export this result into friendly. Let's say. Jason from C. Jason. Jason. Okay. So start that. Friendly. Jason. Yeah, you can see. We have started. So that's how Cubescaping works. This was just a little demo. You can try it out yourself and try to identify authenticated, authenticated services. Again, this is just an early development of the project. There's a lot of work to be required to be done on it. To integrate it into Cubescaping. So that's for the demo part. Now let's go to the next slide. I hope you really enjoyed the demo. And if you have questions, let us know in the comment sections. So let's look into the future of CubeScape Network Scanner. And as we look toward the future of CubeScape Network Scanner has exciting plans for further growth and enhancements. One of our primary goals is to integrate CubeScape Network Scanner into the CubeScape ecosystem. And the larger Kubernetes community. This integration will allow us to extend the reach of our network scanning capabilities and would provide a more comprehensive solution for securing Kubernetes environments. In addition, we plan to enhance CubeScape Network Scanner by incorporating advanced vulnerability scanning. This could include scanning for like big credentials and exploring other potential security risks that organization may face in their Kubernetes deployments. Our ongoing commitment is to provide you with a more detailed output and actionable insights. We want to deliver comprehensive reports that not only highlight vulnerabilities, but also provide guidance on how to mitigate these risks effectively and strengthen your security measures. So that's so far for the future of CubeScape Network Scanner. As we come to the end of this webinar, I want to emphasize the importance of harnessing the power of Kubernetes and foot scanning to improve your security posture. So take action by exploring CubeScape Network Scanner and integrating it into your security practices. That advice I will give is continuously scan your Kubernetes clusters, identify vulnerabilities, reduce your tax office and fortify your requirements by CubeScape. Remembering that securing a Kubernetes environment is an ongoing journey. And so staying up to date with the latest security best practices, engaging with the community and always prioritizing the security of your performance. So thank you all for joining me today. I hope you found this webinar really insightful and that it sparks further exploration into the realm of Kubernetes. So stay secure, stay engaged and keep harnessing the power of CubeScape Network Scanner. If you have time, you can also contribute to CubeScape Network Scanner and CubeScape system. We are always looking for new contributors to join us. And you can always be board reviewers and containers. Thank you all for joining us.