[HN Gopher] Threat Actors Abuse Cloudflare Tunnel for Persistent...
       ___________________________________________________________________
        
       Threat Actors Abuse Cloudflare Tunnel for Persistent Access, Data
       Theft
        
       Author : LinuxBender
       Score  : 47 points
       Date   : 2023-08-06 16:42 UTC (6 hours ago)
        
 (HTM) web link (www.securityweek.com)
 (TXT) w3m dump (www.securityweek.com)
        
       | yodelshady wrote:
       | The everlasting cycle of security fuckwittery (with some
       | apologies to Randall Munroe's "sandboxing cycle").
       | 
       | 1) There is a protocol for communication that encodes some useful
       | heuristic for regular operations - IP addresses, for example, or
       | ports. 2) Idiots decide that ONLY EVER COMPLETELY SAFE traffic
       | should be allowed. As a result, all communications are gone. 3)
       | That's not workable, so some channels have to be opened. 4)
       | Someone develops a way to encode all the previous uses, including
       | the necessary administrative ones, AND necessarily the malicious
       | ones, over this protocol. 1 _) as 1) but with an extra layer that
       | now does nothing.
       | 
       | A _very* similar process exists for scripting languages. "Why are
       | our employees so unproductive, manually doing easily automated
       | things that security won't let them automate? -> Hey, wouldn't it
       | be great if we could automate all the things with [X]? -> Oh
       | noes, malware!".
        
       | badrabbit wrote:
       | It's common to block ngrok and the like using their domain
       | exactly for this reason. Although CF and their SNI encryption
       | will be much more difficult.
        
         | InvaderFizz wrote:
         | In Cloudflare's case they specifically do tunnels on port 7843.
         | Just block TCP/UDP outbound on those pots and CF Tunnels won't
         | work.
         | 
         | See: https://developers.cloudflare.com/cloudflare-
         | one/connections...
        
         | DistractionRect wrote:
         | It's really not. There's different ways one can do this, but
         | it's not hard down to lock down outbound traffic.
         | 
         | On a more general note, tangential to the article and
         | specifically regarding blocking DoH and friends, it's pretty
         | trivial to do this with a DNS backed firewall. I do this for my
         | IoT vlan:
         | 
         | - default deny all outbound
         | 
         | - set dnsmasq to populate an ipset/nftset with DNS responses
         | 
         | - have a firewall rule that hole punches for traffic destined
         | for any ip in the set
         | 
         | - now it's just DNS filtering like usual
         | 
         | This means any successful outbound connection must be prefixed
         | with a successful DNS query that is resolved by the local
         | Dnsmasq instance. Any query that hits an unblocked DNS endpoint
         | does not populate the set used for whitelisting, and is dead in
         | the water - making DoH, DoT, DoQUIC, and such unviable.
         | 
         | Obviously, hole punch exceptions as needed (E.g. For direct
         | connects to static ip addresses).
        
           | kkielhofner wrote:
           | Once you authorize any domain that resolves to Cloudflare POP
           | IPs you're going to end up with gigantic holes that
           | essentially neuter this approach.
           | 
           | It may work in the limited context that is your IoT network
           | but for any corp, user of the web, etc Cloudflare IPs will
           | open almost immediately for all but the most selective (non-
           | CF) DNS records.
           | 
           | Or you don't allow any CF DNS records or IP ranges and cut
           | yourself off from half the internet.
           | 
           | That's what parent meant.
        
           | badrabbit wrote:
           | Your suggestions don't work well at scale and when restricted
           | to specific firewalls and other infra, especially at large
           | orgs.
        
       | [deleted]
        
       | sfeng wrote:
       | I'm sorry, but once an attacker can run arbitrary commands on
       | your machines, it seems like your personal security battle has
       | been lost. Cloudflare Tunnel isn't doing anything that an
       | attacker couldn't do with a huge list of other tools, including a
       | script that just loads some remote HTTP address for evil things
       | to do next.
        
       | waihtis wrote:
       | "Bank robbers abuse Toyota for bank robbery, escaping police"
        
         | woleium wrote:
         | Toyota must do something to prevent bad actors from using their
         | vehicles, like only selling them to people with a driving
         | license.
         | 
         | Government must issue driving licenses and restrict who gets to
         | drive vehicles.
        
           | voxic11 wrote:
           | There is no restriction on buying vehicles, or even driving
           | them on private property. You only need a license to drive
           | them on public roads.
        
           | mcpackieh wrote:
           | You don't actually need a drivers license to buy a car. You
           | need a drivers license to use one on public roads, and you'll
           | probably need some form of government ID to register and
           | insure the car, and the dealer might ask for _some_ sort of
           | ID to verify your identity, but you don 't need a drivers
           | license just to buy one.
        
             | mistrial9 wrote:
             | yankee running dog speaks lies
        
             | Ms-J wrote:
             | Why would you have to verify your identity just to buy a
             | car? That sounds very draconian and I never have had to.
        
               | leesalminen wrote:
               | Depends on if you're paying cash or not. If you're using
               | credit to buy the car, expect to show ID.
        
           | soraminazuki wrote:
           | What exactly are you suggesting here? Link every online
           | device to a government-issued ID?
        
             | ripply wrote:
             | It's sarcasm demonstrating the absurdity of this article.
        
               | MattPalmer1086 wrote:
               | In what way is the article absurd?
               | 
               | Nobody is suggesting shutting down Cloudflare or its
               | services. It's just pointing out an attack technique that
               | is being used.
               | 
               | This thread is absurd!
        
               | bob-09 wrote:
               | "Commenters abuse thread for absurdity, additional
               | comments follow"
        
       | mike_d wrote:
       | Cloudflare's business has always been that your ISP is just a
       | dumb pipe not to connect you to the internet but the
       | Cloudflarenet. All routing, security, etc decisions should happen
       | inside Cloudflare and you should be helpless to do any local
       | security on your network.
       | 
       | It is amazing to me that if AT&T came out and said they were
       | buying up every other ISP in the world to form one big unified
       | network HN would be losing their shit, but Cloudflare slowly
       | boils the frog and everyone cheers and evangelizes for them.
        
         | intelVISA wrote:
         | Only ppl I really see evanglizing CF on HN are CF employees
         | themselves, most of us are well aware of the damage they're
         | doing to the free internet
        
           | psd1 wrote:
           | ...and the people who wake up one day to 200Gb/s of DDoS
        
         | Ms-J wrote:
         | Cloudflare is one of the biggest threats to internet
         | decentralization out there. I actively avoid sites that use CF
         | for their TLS, if possible.
         | 
         | Avoid these predators.
        
       ___________________________________________________________________
       (page generated 2023-08-06 23:02 UTC)