Skip to main content

Locking Down Multicast Services with SPR

· 4 min read
Alex Radocea

Here is an overview of how SPR helps defend users against attacks with multicast services. The capabilities let SPR users enjoy the benefits of multicast while also being able to constrain the attack surfaces to trusted devices only.

Overview​

  1. Every WiFi device is placed on its own VLAN and has a unique Group Key blocking Direct Station to Station Multicast traffic
  2. We employ a configurable multicast proxy to relay whitelisted multicast services. It support mDNS and SSDP by default for ease of use. The multicast proxy and mDNS & SSDP relaying can be completely turned off though.
  3. We also support setting a tag for multicast services to limit relaying traffic to only devices with the same tag applied.

Understanding Multicast & Risks​

IP-Based multicast networking allows sending packets to multiple devices with a single packet. It differs than the broadcast traffic because clients can additionally choose to subscribe to a group and let a router intelligently forward packets to group members, using protocols such as IGMP.

Multicast services tend to only be reachable as roughly 'one-hop' away, meaning an attacker must be network adjacent to a victim to carry out an attack. The packets are one-way, so TCP is not possible but UDP is. Furthermore firewalls can validate that multicast traffic has TTLS set to 1, meaning they won't be forwarded.

That said, multicast has been a source of security holes in the past, in Avahi, mDNSResponder, and more recently in CUPS: where a multicast trigger affected Apple devices, among others; when users attempt to use maliciously injected printer profiles.

WiFi Group Keys Can Transmit Multicast Without The Access Point​

One way to WiFi Clients get Multicast Packets on an encrypted Access Point are directly from other clients with the Group Key that is shared.

Or, they can get the packets with unicast, and receive multicast packets when the Access Point intelligently forwards the packets only to the clients that joined the group destination. This method is preferred for maximizing battery life on nearby devices.

warning

Critically, this means that clients can send multicast to one-another without the access point or router bridging/forwarding packets.

Actually there's 3 ways to send a multicast packet to consider.

  1. Use the shared GTK directly from Client Station to Client Station
  2. Send to AP. Set the 'DA' to the victim MAC address and 'RA' as the Access Point BSSID, for layer 2 bridging. This is the default way stations talk to each other over unicast packets on a subnet without routing. ap_isolate= blocks this method.
  3. Assuming the multicast listener fails to filter for the multicast destination IP: Send to the AP again. This time set the 'DA' and 'RA' as the Access Point BSSID and rely on layer 3 IP forwarding to send to the client's IP. For UDP this works great but the round trip may not happen unless the peer is on a wired medium. Most consumer WiFi Devices are vulnerable to this in their Guest Network Isolation feature. MAC/IP filtering on the firewall helps stop this.

How SPR Performs Multicast Between Client Stations​

In hostapd we set the following key features:

per_sta_vif=1 # one vlan per device
ap_isolate=1 # drop layer 2 bridging
multicast_to_unicast=1 # since each GTK is unique anyway

Part of what makes this all work without losing functionality is that each device is dropped into its own subnet. This means that when devices do want to communicate with one-another they will not expect layer-2 bridging to occur but instead route to each other via layer 3 forwarding.

To re-enable multicast we use a multicast udp proxy written in Golang. This will configurabily forward SSDP and mDNS by default.

Users can define new services to relay, disable multicast services altogether, or apply a tag to filter the multicast to designated clients only.

How SPR Impacts the Recent CUPS Vulnerabilities​

By default, SPR has mDNS on. This means that unless a user has turned it off, a malicious device could advertise to automatically install a malicious foomatic profile.

However, unless a victim device is also in the same group as the attacking device, or the victim has a lan policy set, the victim will be unable to retrieve the malicious printer profile, blocking the attack.

Multicast Roadmap​

In the future we plan to continue to make multicast management more seamless and improve visibility and workflows.

One area of improvement in particular is Wireguard support so that devices can potentially multicast to each other across the VPN if a user chooses the functionality.

Have a feature idea or request? Let us know!.