Conference:  Defcon 31

Authors: Tom Pohl Principal Consultant and the Penetration Testing Team Manager at LMG Security

2023-08-01

Firmware and software binaries are littered with private keys, legitimate CA-blessed certificates, and encryption keys—but hardly anyone notices. These secrets are often obfuscated or otherwise hidden in ways that weren’t intended to be found. I’ll show three real-world examples from popular manufacturers (Netgear, Fortinet and Dell), and demonstrate techniques for uncovering them. In the most extreme example, an adversary can use an obfuscated key to gain access to any customer’s vCenter environment. I’ll start with a straightforward look at Netgear firmware and show methods for discovering private keys in PEM-encoded text files. We’ll dig into the Fortinet firmware, which contained custom obfuscated archive files, and show how to extract Apple and Google issued certificates and I will also show that 3 year awaited “fix” did not adequately solve the issue. Finally, I’ll dig into the worst case: a static AES encryption key within Dell software used to connect to vCenter. I'll demonstrate how retrieve, decompile and use a static AES key which will decrypt vCenter credentials. The key is the same for EVERY customer. This has not been talked about anywhere publicly. I’ll conclude by discussing the importance of developer training, proper key management, and (above all), identifying and eliminating this systemic practice.

Conference:  KubeCon + CloudNativeCon Europe 2023

Authors: Cheryl Hung

2023-04-19

The presentation discusses the process of transitioning to ARM architecture in a cloud-native infrastructure and optimizing CI/CD pipelines.

• Inventory the software stack and identify hotspots
• Optimize by provisioning a test environment and making changes
• Decide on how to build the Kubernetes cluster and deploy
• AWS is an example of a cloud provider with ARM support

Conference:  Cloud Native SecurityCon North America 2022

Authors: Rahul Arvind Jadhav

2022-10-25

For Kubernetes, the basic unit of execution is a pod. All the binaries in all the containers have equal access to the volume mount points and thus have direct access to the service account tokens and k8s secrets that the pod mounts. Almost all Kubernetes attacks exploit/leverage this fact. The only thing an attacker has to ensure is to inject a binary into the pod using a known/unknown vulnerability in any of the binaries within any of the containers. Once the attacker injects a malicious binary, it has unrestricted access to the secrets in predefined volume mount points (we are making it so easy for the attacker!). Typically only a few binaries within the pod need access to the tokens/secrets. The access should be restricted to such a list of processes/binaries, and an automated framework should derive this list. This is easier said than done, taking into consideration that the app is updated every few weeks, i.e., the security posture changes with the app updates. The sessions aim to highlight runtime security risks that are inherent to k8s design and possible solutions to alleviate some of these concerns. Rahul is a dev/maintainer of KubeArmor (runtime security engine).