Researcher Eyal Itkin said in a detailed blog post that the change in work patterns due to the coronavirus pandemic meant that IT solutions for remotely connecting to corporate networks was now being used much more widely.
He said that several critical reverse RDP (remote desktop protocol) vulnerabilities had been found in Guacamole and also affected by a few similar issues in FreeRDP.
"In short, these vulnerabilities allow an attacker, who has already successfully compromised a computer inside the organisation, to launch an attack on the Guacamole gateway when an unsuspecting worker tries to connect to an infected machine," Itkin wrote. "The malicious actor can then achieve full control over the guacamole-server, and intercept and control all other connected sessions."
Outlining the workflow involved, Itkin said an employee would use a browser to connect to an Internet-facing server, go through an authentication process and gain access to his/her own corporate computer.
Said Itkin: "While the employee only uses his browser, the guacamole-server selects one of the supported protocols (RDP, VNC, SSH, etc.) and uses an open-source client to connect to the specific corporate computer.
"Once connected, the guacamole-server acts as a middle-man that relays events back and forth while translating them from the chosen protocol to the special 'Guacamole Protocol', and vice versa."
He said once this workflow had been understood, the next step was to examine likely attack vectors.
One was a reverse attack scenario where a compromised machine within the corporate network used an incoming harmless connection to attack the gateway in order to take it over.
A second, said Itkin, was the malicious worker scenario where a rogue employee would use a computer inside the network to strengthen his hold on both ends of the connection and gain control of the gateway.
Given that FreeRDP had already been found to have holes which Check Point had previously demonstrated, Itkin checked released Guacamole versions to see what version of FreeRDP the Apache software had incorporated.
"By looking at the released versions of Apache Guacamole, we can see that only version 1.1.0, released at the end of January 2020, added support for the latest FreeRDP version (2.0.0)," he said.
"Knowing that our vulnerabilities in FreeRDP were only patched on version 2.0.0-rc4, this means that all versions that were released before January 2020 are using vulnerable versions of FreeRDP."
Itkin said the research could have ended right there with an estimate of the high probability that there were the same bugs in Guacamole as most companies would not have upgraded. But he kept on, looking in particular for support for the RDP protocol in the code of Guacamole-Server and also looking at the code of the latest FreeRDP release.
Three information disclosure bugs were found in Guacamole and two out-of-bounds reads bugs in FreeRDP. The latter two had already been reported.
"At this point, we found five vulnerabilities that could serve as information disclosure exploit primitives in our attack," Itkin said. "However, we had yet to find even a single memory corruption vulnerability.
"Looking for such vulnerabilities in FreeRDP was quite annoying, as every time we had a lead, a check blocked it. Many times, this check was the patch for a vulnerability that we’ve reported, so we can’t really complain too much."
But his persistence finally paid off. The RDP protocol exposes different “devices” as separate “channels”, one for each device. These include the rdpsnd channel for the sound, cliprdr for the clipboard, and so on.
"As an abstraction layer, the channel messages support a fragmentation that allows their messages to be up to 4GB long. To properly support the rdpsnd and rdpdr (Device Redirection) channels, the developers of guacamole-server added an additional abstraction layer, implemented in the file: guac_common_svc.c," Itkin noted.
"We can see that the first fragment must contain the CHANNEL_FLAG_FIRST fragment, and when handled, a stream is allocated according to the overall declared length of the total message. However, what happens if an attacker sends a fragment without this flag? It seems that it is simply appended to the previous leftover stream. At this point, this looks like a very promising dangling-pointer vulnerability. Now we only need to check if the developers remembered to set it to NULL when the previous fragmented message finished its handling.
"After a fragmented message finishes the reassembly and goes on to be parsed, it is freed. And that’s it. No one sets the dangling pointer to NULL!"
He said a malicious RDP server could send an out-of-order message fragment that used the previously freed wStream object, effectively becoming a use-after-free vulnerability.
"On top of that, the wStream is the most powerful object that we could have hoped to get for such a vulnerability, as it can be used for an arbitrary write if the pointer field is set to the desired memory address. On top of all that, we have a useful information disclosure vulnerability in the rdpsnd channel, right after our corrupted wStream object is used. With some effort, a specially crafted wStream object can turn our original vulnerability into a more powerful arbitrary read exploit primitive."
The vulnerabilities have been notified to the Apache Guacamole project which released a patched version on 28 June. Itkin's research did not end there; the additional details, which include techniques for privilege escalation on Apaache Guacamole, are here.