Reducing Attack Surfaces (Part 1)
SPR lets users create adaptive, micro-segmented networks for connecting and managing devices. In addition to fine-grained network visibility we also build hardened software and work to avoid common security flaws. As SPR has matured we've started taking on further efforts to eliminate attack surfaces.
When it comes to native code: we introduce none. As in, we have not written new native code for SPR anywhere. We have one BPF filter, and its otherwise golang all the way down. We also do not run standard native services where we can avoid them. We have replaced traditional C code for services such as DNS and DHCP with golang implementations, namely CoreDNS and CoreDHCP.
The remaining native code targets that we have in SPR are as follows:
- The Linux kernel. For example: ethernet, the tcp/ip stack, nftables, the mac80211 framework and vendor drivers
- 802.11 Firmware, Ethernet Firmware
- Hostapd
- PPP Daemon (off by default)
- OS Services (Ubuntu)
Targeting the Whole WiFi Stack
We believe the wifi firmware to be today's most insecure target (along with the vendor drivers). Many firmwares are blackbox, poorly documented, and opaque to public security research. We want SPR to be immune to attacks like Broadpwn and Qualcomm Exploitation.
We've previously published barely-ap to teach people about WiFi authentication. It can and does work with real wifi chips running in monitor mode to connect clients over the air. We've tested with Android, iOS, and Linux devices.
The plan is to build a series of experiments to host high-speed wifi.
In the near term:
- Develop a Proof-of-Concept AP with scapy in monitor mode (DONE)
- Develop a shim from monitor frames to hostapd running under mac80211_hwsim. This is a work in progress. We would like to see a rust kernel driver/userland daemon for this
Future:
- A full AP written in rust, operating on raw 802.11 frames (not relying on the Linux kernel 802.11 subsystem)
- Rust protocol firmware for a wifi chip.
Developing a Shim Explained
By running the card in monitor mode, protocol parsing in the card firmware is substantially reduced if not altogether eliminated.
And with relaying frames over to macsim, hostapd is good to go. What needs to happen however is making this incredibly fast, and researching rate negotiation and what calls might need to be made to firmware to enable higher coding rates.
By using hostapd and the kernel mac80211 stack, we still maintain some native attack surface, however we get a known working, security-tested AP that will be compatible with a wide variety of devices, without the firmware protocol parsing and the vendor driver parsing.
For next steps, a proof-of-concept with scapy is actually much too slow. We want to start with a rust userland daemon leveraging iouring. If that doesn't fly then we'll go to a shim in the kernel.
Interested in working with us? Please reach out
We are actively seeking an intern to help develop rust+wifi for SPR.
You can contact us at spr-wifi [ a-t ] supernetworks.org or hop on the discord