Exam Format

The Certified Kubernetes Security Specialist exam is hands-on. You will need to complete approximately 16 tasks within two hours. Upon starting your exam, you’ll get access to a couple of Kubernetes clusters where you can perform the requested tasks. There are no theoretical questions or multiple-choice options; you will simply have access to a VM through which you can operate on different Kubernetes clusters.

The exam includes live proctoring; a person will be watching you throughout the two hours, to ensure that you do not communicate with others, have no books or papers nearby, and do not open any applications other than the exam application. They are very strict! The only resource you are allowed to consult is the official Kubernetes documentation, accessible from the exam's VM.

Requirements

The CKA (Certified Kubernetes Administrator) certification is a prerequisite for taking the CKS exam. This means you will need to pass the CKA exam first. This requirement makes sense, after all, you cannot properly secure a technology you're not familiar with. The Certified Kubernetes Administrator exam ensures that you have real experience with this technology.

The CKA exam format is the same as that of the CKS, you’ll be prompted to complete about 16 tasks within two hours as well. In the case of the CKA, the tasks are related to cluster administration (installing, upgrading, and troubleshooting Kubernetes components) as well as creating the most common Kubernetes objects, such as Pods, Deployments, DaemonSets, ConfigMaps, Services, Volumes, and Volume Claims, Ingress controllers, etc. If you use Kubernetes, these objects should already be familiar to you, as they are commonly used in any Kubernetes workload.

How to Prepare for the CKS Exam

Here are the topics I encourage you to study (and practice!):

• Secrets: Practice creating generic secrets in imperative mode and mounting them as a volume within a pod.
  Documentation: https://kubernetes.io/docs/concepts/configuration/secret/.

• Network Policies: Dive into creating network policies to filter and block incoming traffic to a specific pod. Make sure you know how to use Pod Selectors and Namespace Selectors.
  Documentation: https://kubernetes.io/docs/concepts/services-networking/network-policies/.

• Service Accounts: Practice creating Service Accounts without the automatic mounting of the token within the Pod. Learn how to configure a Pod to use a specified Service Account.
  Documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/.

• Roles and Role Bindings: Practice creating roles with a variety of permissions, and create the necessary Role Binding object to tie the role to a Service Account or User.
  Documentation: https://kubernetes.io/docs/reference/access-authn-authz/rbac/.

• Image Scanning: Learn how to use Trivy for scanning Docker images and detect known vulnerabilities.
  Documentation: https://github.com/aquasecurity/trivy.

• Containers Immutability: Practice setting up a pod with a read-only root file system and blocking privilege escalation.
  Documentation: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/.

• Principle of Least Privilege: Practice configuring Pods to run with a low privileged user. Learn how to spot and disable privileged containers and drop unnecessary kernel capabilities.
  Documentation: Idem (Security Context).

• AppArmor: Play around with enforcing specific AppArmor profiles and configuring them on a Pod. You might not be asked to develop an AppArmor profile from scratch, but knowing how to enforce and set one up is key.
  Documentation: https://kubernetes.io/docs/tutorials/security/apparmor/.

• Seccomp: Practice applying a seccomp profile stored on the host filesystem to a pod. Much like AppArmor, the task will likely be about configuration rather than creation.
  Documentation: https://kubernetes.io/docs/tutorials/security/seccomp/.

• Admission Controllers: Get familiar with configuring an admission controller (crafting the Admission Configuration object) for something like an Image Policy Webhook, and then sorting out the parameters for its use in the Kube API Server.
  Documentation: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/.

• Best Practices for Core Components: Practice configuring the Kube API Server and core components following the recommended secure best practices. For example, enforcing authentication, opting for a secure cipher suite for internal communications, and so on.

Final Tips!

Remember, the CKS is a hands-on exam; you'll need to create and/or configure all those Kubernetes features on real clusters. Therefore, practice as much as you can! I recommend renting a cluster on the cloud or installing Minikube on your local machine.

Time management is crucial; the two hours fly by with 16 tasks to complete. If you're unsure about a particular task, flag it to return to later and move on. Try to complete as many tasks as you can and save for the end those you're less certain about. In my case, I managed to complete 14 out of the 16 tasks before running out of time!

Pay close attention to the cluster context; each task must be completed on a specific cluster. I recommend that before you even start to read the task, execute the command for kubeconfig context switching (this is provided at the beginning of each task).

Be aware, the exam's VM is not user-friendly… it can be quite frustrating to perform tasks remotely connected to a VM that doesn't display in full screen, and where shortcuts don't work properly. Keep in mind the exam environment won't do you any favors.

Also, the process to launch the exam through the live proctoring application is rather cumbersome. It takes at least 20 minutes to download the app, perform the check-in, scan your room, etc. Therefore, I recommend launching the exam 20 or 30 minutes before your scheduled time.

That's all! I hope you find this guide and the tips helpful for your CKS exam preparation. I wish you the best of luck, and don't hesitate to leave a question here if you have any!

Subscribe now

Yet, why is this useful? Nuclei is extremely practical for quickly verifying vulnerabilities, misconfigurations, or whether an application responds as expected to certain HTTP or TCP packets. There are thousands of templates for HTTP requests, which are well-documented with plenty of examples. However, this is not the case for 'network' templates, we'll be delving into these today.

INPUTS

The input is the chunk of bytes we will send to the target application. This can be provided as an ASCII string of characters ('text') or as a hexadecimal string ('hex').

Inputs are a YAML array, and it is possible to specify several.
For example:

Each string will be sent one after the other to the target. You might expect the target to respond to each of these packets individually; we will delve into this shortly.

Now, you might be wondering, where do those strings I use for the input come from? It depends on what you’re testing. When using TCP packets, you will have to speak the ‘language’ of the targeted protocol. To obtain these packets for use in your Nuclei template, you’ll likely first analyze the network traffic during your test to extract the right packets. For this, the most common tool is the popular traffic analyzer, Wireshark. For less complex protocols or simpler cases, you might want to give network-fingerprint a try.

Generally, creating the input part of the template is quite straightforward. However, reading the output and properly matching it with your expected response can sometimes bring issues. Let's jump into it.

OUTPUTS

According to Nuclei’s syntax reference, there are three properties to read the output: read, read-size, and read-all. The most commonly implemented are read and read-size. However, people often tend to confuse these two (well, the difference is not immediately apparent at first sight!), and incorrect usage may compromise the template's effectiveness.

In the simplest case, you might not need to specify any of those, and ‘read-size:1024’ will implicitly be used (which works for most cases). Yet, what’s the actual difference between the three options?

To start with, read is a property of network.Input() and, in case it is used, should be placed within each input statement. On the other hand, read-size and read-all are properties of network.Request(), therefore, they are placed outside the list of inputs.

As mentioned, read-size:1024 will be the default. In case you need to read more bytes (because what you are looking for in the output is not within the first 1024 bytes), you can provide a different size (for example, read-size:2048) or simply use read-all:true, which will read the entire output regardless of its size. Most cases are actually resolved using the read-size property, so what is read used for? Furthermore, the template above - while still working fine in this case - is not properly structured, as using read-size and read together in this way doesn’t really make sense.

It seems there are a few cases where it could make sense to use the read property instead. Let’s see two examples: 1) Matching strings in the response to specific inputs; 2) Using the response from an input to create the next request.

USING THE READ PROPERTY: CASE 1

At the beginning of this post, I shared an image with an example of multiple input requests; this belongs to the ADBHoney-shell detector I developed weeks ago. It sends multiple requests to the target and then matches a chunk of bytes that comes in the response to the last request.

As we can see, there is a read-size:1024 statement in the template. It will read, as seen below, the response to all the requests up to 1024 bytes in total, and then match the expected bytes in the response.

What if we would like to also match the string '=starltexx;ro.product.model=SM-G960F' that comes in the response to the second request? We could simply add one more matcher with this string, and it might work, as long as the response does not surpass 1024 bytes. However, this is where read plays a role! It would be best to use the read attribute, assign a name to the responses, and indicate to the matcher where to find each string. The code would look as follows:

The first modification, outlined in red, involves reading 512 bytes from the response of the second request and naming this "info". Then, in the matchers section, we indicate to look into the part labeled 'info' for the desired string.

That was easy. However, identifying the last chunk of bytes has now become slightly more complicated in this way. This is because ADB responds with two packets (OKAY and WRTE statements) to our last request. Therefore, if we want to match bytes in the last packet (WRTE), we first need to read and ‘skip' the OKAY response.

That’s the reason behind writing two read statements in the template after sending the last packet to the target. The last response is named 'shell-response'. In the matchers section, we specify such a name to match the expected chunk of bytes in this part.

As we can see, it is possible to use the structure of inputs to read from the socket without actually sending data. This approach was particularly useful in this scenario, where the target replies with more than one packet, and we need to match bytes in the last response.

In conclusion, for this case, I believe the read property can be quite useful in complex situations where it's necessary to read specific bytes from certain responses in a series of network packets. If such complexity isn't required, I highly recommend using read-size instead, as it tends to be less prone to failure. Sometimes, the read property can lead to timeouts, especially if you're not reading the exact amount of bytes (since Nuclei keeps waiting for more bytes, resulting in a timeout eventually).

A few weeks ago, I raised an issue related to this in the official Nuclei repository, which was addressed in the release 3.1.2. However, in certain cases, depending on the network protocol you're working with, this issue might still occur.

USING THE READ PROPERTY: CASE 2

Let’s jump into the second use case for the read property: Using the response from one input to create the subsequent request.

This is another complex scenario where - for example - you might be dealing with a network protocol that requires exchanging a few packets, including a challenge, to establish a connection. In such cases, it’s often necessary to take a portion of the target's response, which contains the challenge, and send it back in your subsequent request.

I've crafted a simple example to demonstrate this particular case:

As observed, we read 256 bytes from the response of the first packet and name it “challenge”. Then, we use these received bytes into our second request. The matchers section isn’t of much importance in this example; the key aspect is how we can utilize the response from one packet for a subsequent request. Here's how it looks like when we use netcat for testing:

We successfully receive back the challenge part.

That’s all. I don’t want to extend this post any further. I hope you find these 'advanced' tips for developing Nuclei network templates useful :)

Subscribe now

My first thought was to use a jammer device to inhibit the Wi-Fi signal during the night, and hopefully prevent the noisy neighbor from being able to play online. However, jammers are not easy to purchase due to legal reasons. While it’s possible to build them at home, I opted for an easier, old-school alternative: a simple Wi-Fi DeAuth Attack.

I’m writing this little guide for my friend and for educational purposes for you. Feel free to experiment with your own network ;)

REQUIREMENTS

I will use an Apple MacBook with an M1 chip because that’s my friend's notebook. However, we cannot inject network packets directly from MacOS, so I will quickly spin up a Kali VM using UTM. I recommend UTM instead of VMWare or VirtualBox for Apple's M* chips.

• UTM for MacOS: https://mac.getutm.app

• Kali .iso file for Arm64 (chip M): https://cdimage.kali.org/kali-2023.3/kali-linux-2023.3-installer-arm64.iso 
  (you can always check for the latest release at the official page)

• Tutorial to run Kali on UTM: https://www.kali.org/docs/virtualization/install-utm-guest-vm/.

If you don’t have a MacBook, even better; run your favorite Linux distribution on your notebook and install the aircrack-ng suite :)

Another requirement is to have a Wi-Fi interface with a chipset that supports packet injection. I recommend an Alfa or the classic TP-LINK WN722N.

DRIVERS INSTALLATION

Once you have the Kali VM (or the aircrack-ng installation) ready, you will likely need to install the drivers for the RTL8812AU chipset (Alfa) or RTL8188EUS chipset (TP-LINK).

How do you know if you need the drivers? Connect your Wi-Fi interface to your VM or notebook via USB, and run the iwconfig command. If you don’t see a wlan0 or any wireless interface in the output, then unfortunately, you need to install the drivers.

Note: If you are using UTM, please make sure to allow the USB interface at the top right corner of the view.

Kali will likely still not detect your Wi-Fi interface.

So, let’s install the drivers. The installation procedure is nearly identical for both cases.

Steps for the RTL8188EUS (TP-LINK).

$ git clone https://github.com/aircrack-ng/rtl8188eus
$ cd rtl8188eus
$ make && sudo make install
$ reboot

Steps for the RTL8812AU (Alfa):

$ sudo apt-get install dkms
$ git clone -b v5.6.4.2 https://github.com/aircrack-ng/rtl8812au.git
$ cd rtl*
$ sudo make dkms_install
$ reboot

After the reboot, if we run the iwconfig command again, we should now be able to see the wireless interface, yay!

WI-FI DEAUTH ATTACK

So, we are now ready for action! The idea is to execute a Wi-Fi deauth attack against the target network. This will disconnect all devices connected to it, including the computer or video game console.

First of all, let's put our Wi-Fi interface into monitor mode.

$ sudo airmon-ng check kill
$ sudo airmon-ng start wlan0

Now, let's gather the necessary information from our target network.

$ sudo airodump-ng wlan0

The output will look as follows:

Basically, we can observe:

• BSSID: Mac Address of the Access Point

• PWR: In simple terms, it’s the distance from the Access Point

• CH: Wi-Fi channel

• ESSID: Access Point name

For a successful packet injection attack, the distance from the targeted access point is critical: the closer, the better. How can you determine if you are close or far away? Observe the PWR information; the closer the number is to zero, the closer you are to the access point. In the picture above, I will target the access point with a PWR of -41, as it’s my router and the closest to me.

Let's go! Execute the deauth packet injection attack as follows:

$ sudo aireplay-ng --deauth 0 -a {{TARGET_BSSID}} wlan0

If it's working, you will see in the output that aireplay is successfully injecting packets. Note that the above command will deauthenticate all the devices connected to the target network

While we let that run, devices should not be able to reconnect to the Wi-Fi. If that’s not the case, you can always automate the re-launch of the command every few minutes ;)

Note: In case you encounter the following error:

It seems aireplay-ng is attempting to inject on the wrong channel. I resolved this by stopping and then restarting the interface in monitor mode, but this time specifying the channel of the target network (you can obtain the channel from the airodump-ng information). Note the '11' at the end of the start command.

That's all! I want to thank my friend for taking me back to the past for a while. It's been so long since I last engaged in these basic Wi-Fi 101 hacking stuff, and I had a lot of fun ;)

Thank you for reading.
Sheila A. Berta (@UnaPibaGeek)

Subscribe now

WHAT IS A HONEYPOT?

A honeypot mimics a real system - that can be vulnerable on purpose - to attract attackers and study their TTPs (Tactics, Techniques and Procedures). This is typically done to gather intelligence, attacks statistics, discover new threats and improve the detection systems.

COMMON DETECTION TECHNIQUES

Over the years, security researchers have published different techniques to identify honeypots. Most previous work is based on analyzing the following stuff:

• Default services banner
  (E.g.: 220 mailrelay.local ESMTP Exim 4.81 #1 Thu, 29 Jul 2010 05:13:48 -0700)

• Default response to commands
  (E.g.: cat /etc/passwd shows user “Phil California”)

• Certificates configuration
  (E.g.: Organization issuer/subject: “dionaea.carnivore.it”)

• Suspicious number of open ports in the host
  (E.g.: All ports are open)

• Suspicious hosting provider
  (E.g.: ICS honeypots on Cloud hosting)

MY RESEARCH

I aimed to detect honeypots by abusing a flawed logic in their network packet-handling functions. How? We send a malformed or unexpected network packet to the honeypot and, in case of a flawed logic, it will reply with an error or an unexpected response. We will use such a reply to identify the honeypot.

Why this way? Because this detection mechanism can bypass the countermeasures implemented to avoid the identification methods revealed by previous work. In other words, regardless of whether the banners, certificates, or command's static outputs are customized, we can still detect the honeypot due to the flawed logic issue. This represents a sort of bug that would require patching the honeypot's code in order to fix it, a process typically more complex.

In this research, I also limited my focus to finding a flawed logic issue in the first or second interaction with the honeypot. This was to minimize interaction with the honeypot and enable large-scale analysis for honeypot detection in a fast and efficient way :)

HONEYPOT’S FLAWED LOGIC

I analyzed about 15 of the most popular open-source honeypots and found a flawed logic in all of them. I will describe two examples here to give you an idea of how this detection technique works, and then you can find all the rest in the materials section at the end of this post.

SNARE

Snare is an HTTP (Web server) honeypot.
If we send the following HTTP request with a wrong HTTP version:

GET / HTTP/1337

The honeypot replies with the following error generated by the Python script:

Bad status line ‘Expected dot’

Example:

A suspicious banner can also be observed. However, since banners are customizable, I recommend basing the detection on the flawed logic.

DIONAEA MQTT

A Mosquitto honeypot, part of the popular Dionaea suite.
If we send a v5-format packet (publisher), the honeypot responds with a v3-format packet (susbcriber).

Let’s see how this looks like on the CLI:

If we send a '-V mqttv5' packet to the honeypot, it responds with an unexpected packet for the publisher (mqttv3-format), and the client reports an error.

Below we can observe the network packets exchange:

We can use the flawed replies from the honeypots to identify them.

AUTOMATION

As mentioned, above are just two examples. I discovered flawed logic issues in all the popular open-sources honeypots I analyzed. In order to facilitate and automate the detection, I created about 15 Nuclei templates, one for each honeypot.

Github repository of the templates: UnaPibaGeek/honeypots-detection.

Usage:

Nuclei has already merged these templates to their official templates repository. So you can update your Nuclei installation and use them from there.

Presentation slides (counter-intelligence slides were removed here): Honeypots Detection via Flawed Logic Issues.

If any question, do not hesitate to reach me out.

Sheila A. Berta (@UnaPibaGeek)