I recently discovered a bug in a product called Rumble (Rumble.run), a network discovery tool. A ticket was opened with support, and while they understood the nature of the situation, they kept blaming the target as being "at fault", despite all evidence provided to the contrary. In my opinion, this problem is more than a simple odd annoyance; it represents a way to evade detection entirely. In this article, we'll go over how to accomplish this, and it's potential ramifications.

In order to really understand the nature of this bug, we need to understand what Rumble is and how (I am told) it works.

In a nutshell, it's a glorified network and port scanner. It's basic function, from the perspective of the Target, is essentially just an nmap port scan. The REAL power of the product comes in the response analysis and following actions. Rather than just "see" the responses, it actually captures the whole package and performs some pretty deep analysis on the responses. Then, it works to identify the actual service running, and performs additional scans/enumeration from there. For example, it can identify DCERPC ports and services, and then further enumerate through it (https://www.rumble.run/blog/research-dcerpc/). It can also poll SNMP for all kinds of info, associate multiple IPs to switches and routers, and build out a network topology. It's got all kinds of fancy reports on a nice WebUI. It has a distributed model where you deploy/install these scanner devices (Explorers) that perform the actual scans, and then report back their findings to the centralized cloud WebUI. It uses a variety of methods to determine whether a device/host is up and responsive; ICMP (ping), TCP, and UDP scans to name the obvious.

The purpose it is sold for is a Network Discovery tool. The general idea is that, using this tool, you can build out an inventory of actually active devices on the network. In theory, you could then refer this inventory to your "Internal Authorized Devices List" (whatever you actually call it), and work to identify any potential rogue/unauthorized devices (and/or maybe network connections and bridges).

This is where this buggy behaviour comes in to play. It's all about hiding a (potentially) unauthorized device on the network from Rumble. There are all kinds of other ways to keep a device as hidden as possible, and we're NOT going to go in to any of those. We're not trying to focus on all the ways to remain hidden... we're trying to focus on this buggy (in my opinion) behaviour and how we can remain hidden due to this behaviour. According to HD Moore, founder and CTO of Rumble, "We don’t try to detect devices that actively hide (through firewalls or honeypot services)."

So let's say you have a device, maybe a Raspberry Pi, a decoy device, a compromised host, or maybe just a VM, that you want to keep hidden, but yet still accessible, whether it be something like Responder or rogue HTTP/S server, or anything similar where you have some kind of port/"service". *IF* you know that there's scanners on the network, AND you know their IP Addresses, it is rather trivial to simply block them using iptables (or only allow specific targets). But chances are, you won't and don't, so here's 1 option to deal with that.

From a technical standpoint, it's rather quite simple: just install and use portspoof (https://github.com/drk1wi/portspoof).

See the full install details here: https://github.com/drk1wi/portspoof/blob/master/DOC

The purpose of portspoof is to not only just reply (SYN ACK) to a to a request (SYN), but take it a step further and "respond to every service probe with a valid service signature", with the explicit purpose to "fool scanners".

Rumble Support stated that their product can, and should, be able to identify simply open ports (that maybe lead to a broken sevice that doesn't necessarily provide a proper service signature, for example) from the "complete" services, and report and show them all.

The tests I performed are as follows:

• my own lab (jonmoore.duckdns.org, go ahead and perform your own port scans and tests to verify)
  • in addition to portspoof, I also have a number of REAL services, like:
    • port 22, SSH
    • port 23, telnet
    • port 53, DNS
    • port 80/443, HTTP/S Website (you're browsing it now ;) )
    • port 5201, iperf3
    • port 8443, SSL VNP / VPN Portal
    • and a few others...
    • all hosted on a variety of different physical servers (my web server and iperf server, for example, are not the same physical servers)
  • Medium Enterprise grade Firewall (not some janky hacked home grade wifi router)
• nmap -p1-65535 shows all* ports open
  • other scans like Rapid7 show all* ports open as well
  • *MOST. TCP port 25 is blocked by my ISP, and as far as I am aware, this is the only one.
• using Rumble's "default" set of ports, scanned target: jonmoore.duckdns.org
  • packet captures on my end show all ports/SYNs/SYN-ACK-further-requests were responded to
  • Rumble doesn't even show the host/target as up at all
    • as in not responsive to *ANY* ICMP, TCP, or UDP requests
  • not the portspoof ports, not the real ports/services.. nothing
• using Rumble to scan all ports (1-65535) gives the same results
• using Rumble on a single port/service DOES show that ONLY the single port is responsive (since it is the only port scanned/requested)

According to what I could gather from Rumble Support, Rumble has a "bogus service detector" of sorts, but was un-able/willing to provide any further detail on how it's supposed to accomplish this. While it is my opinion that this is the "function" that is getting overwhelmed in some manner, Rumble Support puts the blame on various degrees of services disruptions and/or packet loss.

Using this technique, one can "hide" an unauthorized device from a Rumble scan. While not a MAJOR SECURITY PROBLEM in and of itself, it's an interesting way to evade detection from a Network Discovery tool (by replying to "too many" requests?). One of the primary purposes of using this kind of Network Discovery tool would be to discovery these kinds of rogue devices, and it is so easily defeated WITHOUT knowing that it exists beforehand. According to the creators, this is expected behaviour.

While this can likely be replicated by simply setting up portspoof on any device scanned by a Rumble Explorer, a more "truer" representation of my setup (and a potential "rogue" device) would be as follows:

•  a server running some "genuine" services (turnkey Linux LAMP server for something quick and dirty https://www.turnkeylinux.org/lamp)
•  install and run portspoof as per instructions

If anyone goes through this and gets any results, please let me know, whether they be the same OR different. Either way, I would like to know what anyone else sees here.

As a final thought... before anyone starts bombarding me with "this isn't a "real" setup", I would like to point out that Black Hill Information Security did a video/blog about using this (https://www.blackhillsinfosec.com/how-to-use-portspoof-cyber-deception/) where they describe it as a technique for "Active Defense and Cyber Deception". So yes, it is a genuine, valid Security technique. On a more anecdotal point, before I implemented this I would get daily port scans and IPS (Intrusion Prevention System) hits from China and Russia (and a few others). After setting this up, those daily scans became less and less frequent, eventuall falling to weekly, and then monthly. At this point, it's been over 2 years since I've had any port scans and attacks from those countries. So there is DEFINITELY a valid, measurable effect on security with just this.

Disclosure Timeline

I'm not sure this will actually be necessary, I certinaly hope not... but just in case, here's a disclosure timeline.

20/08/2021 - Initial disclosure of potential bug through Support channels.

31/08/2021 - Disclosure to security@rumble.run as per https://hackerone.com/rumble_network_discovery?type=team

31/08/2021 - Response, "We don’t try to detect devices that actively hide (through firewalls or honeypot services)." -HD Moore

Add comment