> If an attacker is capable of installing apps on your server... you've already lost.
That is a deep misunderstanding of how security works.
The defender’s dilemma states that breaches are inevitable because defenders have to be right 100% of the time whereas attackers only have to be right once. This is why you have to defend in as many layers as possible.
A better way to approach it is to assume that at any given time an attacker can execute code on your systems (because they have knowledge and access to unreleased exploits) and work on ways to detect anomalies and behaviors indicative of compromise as well as limiting the blast radius.
> If an attacker is capable of installing apps on your server... you've already lost.
You're right, but cloudflared is a whole lot easier to get running than previous RATs, and attackers don't need to operate their own c&c infrastructure - you can't defend yourself from such attacks by blanket banning Chinese, Russian, Iranian and North Korean IP addresses (which I honestly advise everyone to do if they don't have business in that country), and you can't easily block outbound to Cloudflare either as half the Internet is hiding behind them.
Basically, cloudflared lowers the price and effort for attackers dramatically, while the effort to defend against this threat model has now risen significantly.
If Cloudflare were to actually be willing to do something against being used by scammers, they'd put the ingress IPs for the C&C infrastructure on dedicated IP ranges and publish these in a machine-readable format so every reasonable person that does not use Cloudflare tunnels can ban them.
This kinda surprises me, what is so "dramatic" about cloudfared specifically? This seems just like another reverse tunnel tool, and there are plenty of them.
I am not working with malware specifically, but in the past I've used ssh tunnels, random one-off websocket thingy we wrote, wireguard tunnel, frp proxy, and even AWS SSM agent to get access to machines with all incoming connections blocked. They are pretty simple to setup and generally cannot be blocked with whitelist block already.
(and I bet that for malware, they are worse than cloudfared. Based on CF's reputation, they take security reports seriously, so I would not be surprised if they take down malicious tunnels fast. While random VM on low-cost hosters will probably takes days to respond.)
> This seems just like another reverse tunnel tool, and there are plenty of them.
These are known though, you can block them without causing issues.
> and even AWS SSM agent to get access to machines with all incoming connections blocked
SSM is awesome, but the ways it works... I have no idea how. I think though that it uses outbound connections, but unfortunately AWS SGs can't do deny rules.
> If Cloudflare were to actually be willing to do something against being used by scammers, they'd put the ingress IPs for the C&C infrastructure on dedicated IP ranges and publish these in a machine-readable format so every reasonable person that does not use Cloudflare tunnels can ban them.
I don't like the idea of making it easier to block certain services, because it goes both ways: it'd also be easier for bad guys to block good guys from using said services.
I'm not seeing how the GP's idea could be used by bad guys to block access to services - it'd be something you could add to your firewall, if you don't use this service, to prevent it's use in gaining persistence.
If the bad guys can modify your firewall config, you already have a problem.
"Winning" and "Losing" are not a great framework for this sort of analysis. In that binary framework, there's no difference between "1 bit of sensitive data was leaked" and "the medical and financial records of every person ever, nuclear launch codes, and the backdoor that causes every nuclear reactor to go critical simultaneously were leaked" - both are just "losing".
This is why various compartmentalization techniques exist throughout the stack - principle of least privilege, network segmentation, acls, and so on. If something is compromised, limit the "blast radius" of what can be done with that compromise.
The other part is containment. By analogy alarm systems and guards. If the alarm system goes off and says an intruder is in the building, well by the "winning and losing" framework, the defender has already lost. (Of course by the binary framework, you don't even need an internal alarm system - once the breach occured you've lost so why bother?). Or you could try to contain the problem and send guards to stop the intruder before they do too much damage.
This is where the cloudflared usage described in the article is problematic. It's a tool that is less likely to trip alarm systems, and further can provide a wide range of access while doing so[1]. If it doesn't trip alarms, a small breach leaking a little data can turn into a big breach leaking lots of data. It absolutely should be considered when designing networks, security methods, etc.
I don't know what the solution here is, that probably depends on the individual/org doing the threat assessment, and probably varies by environment within that domain. Should the tool be blanket banned? Probably not it's also a really useful tool for a lot of people in a a lot of situations. Maybe cloudflare can split the tool in to individual binaries for functionality and have the tool called cloudflared just be a wrapper. Maybe they can change it some other way.
[1] this tool is used for a lot of stuff and may already be on the systems in question, so it's not even installing a program -- just execing it. Since it is used for a lot of different things, it may just be on a blanket "allow this app" list. And so on.
The big thing that I found from my research on this tooling was the ease with which an attacker could a) learn things about a target environment, particularly by enabling RDP and accessing a device directly without generating any red flags and b) more importantly, being able to exfiltrated data over SMB that would appear to be local activity.
Sure, flow data would eventually show the outbound transfer rates suggestive of data exfiltration, but without any other correlative alerts, it's likely to get through before defenders have a chance to respond.
If an attacker is capable of installing apps on your server... you've already lost.
0. https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...