Breaking down firewalls with BPFDoor (no e!) – How to detect it with Falco

BPF (not eBPF), typically viewed from a defender/sysadmin’s perspective, provides easy access to network packets and the ability to take actions via programs written based on custom filters BEFORE they ever reach a (local) firewall. This same power, according to the PWC report and pending conference talk, was leveraged by a threat actor named Red Menshen, where the attackers have used BPFDoor technique to gain stealthy remote access to compromised devices from at least 2018 to the present.

Defenders should note that root access is required in order to set a BPF filter, however, in a world of increasingly available Local Privilege Escalation exploits, this is not the barrier to entry that it once was.

This article will summarize what BPF is and does, and how it was used by Red Menshen to turn a powerful system introspection tool into an extremely stealthy backdoor.

BPF breakdown

Berkeley Packet Filter (and its non-acronym descendent eBPF) has been getting a lot of press in recent months, however it is not a recent technology. The original USENIX paper explains “BPF provides a raw interface to data link layers, permitting raw link-layer packets to be sent and received.”

BPF supports filtering packets, allowing a userspace process to supply a filter program that specifies which packets it wants to receive. For example, a tcpdump process may want to receive only packets that initiate a TCP connection. BPF returns only packets that pass the filter that the process supplies.

Red Menshen breakdown

Red Menshen is an institutional threat group based in China, with observed regular working hours Monday-Friday between 01:00 and 10:00 UTC. Red Menshen were identified by PwC as the actors behind the main BPFDoor payloads found in the wild, however, Pangu Lab first identified the technique in the wild and attributed it to the US’s Equation Group during a 2013 analysis. PwC were able to identify victims in the telecom, government, and education sectors throughout Asia. They then analyzed network telemetry in relation to the aforementioned victims, and discovered hundreds of suspected compromised routers in Taiwan, used as proxies to access threat actor infrastructure and for web browsing.

BPFDoor BPF bytecode explanation

Linked is the disassembled, commented bytecode of the BPF used by BPFDoor. Thanks to Sandfly Security for the work.
Below is the pseudocode for the (BP)filter used by BPFDoor: “return false” means the packet doesn’t match; “return true” means the packet matches.

if (EtherType == IPv4) {
    if (Packet is an additional piece of a fragmented packet)
    {
        return false;
    }
    else
    {
        if (Protocol == UDP && data[0:2] == 0x7255)
        {
            return true;
        }
        else if (Protocol == ICMP && data[0:2] == 0x7255 && ICMP Type == Echo Request)
        {
            return true;
        }
        else if (Protocol == TCP && data[0:2] == 0x5293)
        {
            return true;
        }
        else {return false;} //ipv4 packet, not our magic tcp/icmp/udp
    }
}
// Not ipv4 packet
else {return false;}

A one-sentence summary of the above pseudocode – if we get our “magic” packet (with packet data[0:2] == 0x7255(UDP/ICMP) or 0x5293(TCP)), pass it to our backdoor program for further parsing.

After password authentication, the backdoor takes one of three actions, assuming it received a valid “magic packet”:

• Case 1 is getshell, where it uses iptables to create temporary firewall rules redirecting traffic to a TCP bind shell, and then later deletes these rules once it receives a connection, which, thanks to Linux iptables state-tracking, keeps the effect of the rules in-place for the existing connection even though the rules themselves were deleted.
• Case 0 is shell, where the backdoor attempts a traditional reverse shell, calling back to the source of the magic packet.
• The last case, 2, mon, is just a ping or liveness check, where the backdoor reports back to the magic packet sender that we are up and running.

BPFDoor Detection with Falco

Runtime detection of BPFDoor is difficult, since most runtime agents operate at the same privilege level (root) as what is required to apply a BPF.

However, detection is possible with Falco, a CNCF incubating project. Falco is an open source tool that detects anomalous executions at runtime in your cloud-native environments.

This rule will trigger when BPFDoor (or any other program, minus the exception listed) successfully uses the setsockopt syscall to attach a BPF.

- rule: Possible Backdoor using BPF
  desc: A process was seen using BPF on a network socket, this could indicate packet sniffing for use in a backdoor such as BPFDoor. Network diagnostic tools may also trigger this rule.
  condition: "evt.type=setsockopt and evt.dir=< and evt.rawres=0 and evt.arg[3]=SO_ATTACH_FILTER"
  exceptions:
  - name: proc_names
    fields: proc.name
    comps: in
    values: ["tcpdump"]
  output: Possible BPFDoor Attempt Detected (proc.cmdline=%proc.cmdline port=%fd.sport domain=%fd.sip.name image=%container.image.repository)
  priority: WARNING
  tags: [network]

Conclusion

In terms of prevention, removing certain Linux system capabilities from host binaries (cap_new_raw, cap_net_bind_service) could prevent proper function of BPFDoor, were it to be executed as a non-root user. However, given that it expects to be run as a root user, these mitigations would be rendered ineffective.

One can use AppArmor profiles to ensure that no user can capture packets on a raw socket.

---