Bitchat Plugin Support on SPR​

I've released a proof of concept for Bitchat running on Linux, along with a plugin configuration for SPR!

Background​

Since we last wrote about Bitchat, the security response for Bitchat been pretty much perfect. Jack quickly added prominent warnings that Bitchat was in development, and very quickly (as in within a week or so), the protocol moved to use Noise Encryption, providing strong security guarantees. Not long after Bitchat made it to the App Store. And even more impressively a little while later support for Nostr made it in. Recently I got a patch in for a small security fix for handling plaintext DMs.

Our new SPR PoE+ router, built on the Raspberry Pi CM5 platform, delivers great performance. In this test, we pushed packets to the limits by running simultaneous throughput tests on both the 2.5 Gbps Ethernet port and a 160 MHz WiFi 6 connection, achieving a combined throughput of over 3 Gbps.

The CM5 exposes a single Gen 2 PCIe lane (Gen 3 can be configured). The SPR PoE+ router splits the lane with a Gen 2 2:1 ASM1182e packet switch to share between the WiFi AP and 2.5GbE port, and a key question has been how the packet switch setup fares under real world conditions.

Hardware Overview​

The SPR PoE+ router features:

• CPU: Raspberry Pi CM5 Carrier Board with CM5104032 (4GB RAM, 32GB eMMC, WiFi)
• Connectivity:
  • MT7916 3x3 802.11AX WiFi 6
  • 1x 1Gbps Ethernet port, 1x 2.5Gbps Ethernet port
  • 2x USB 3.0 ports, 1x USB 2.0 port
• Power: PoE+ (802.3at) capable on 2.5 Gbps port, USB PD Power
• Antennas: FlexMIMO Antennas from Laird

Test Setup​

Our test configuration consisted of:

• WiFi Client: M2 MacBook Pro with 2 spatial streams and WiFi 6 capability
• Wired Endpoints: Two routers with R8125 2.5GbE cards
• Network Path: Connected through two separate 2.5 Gbps switches with jumbo frames enabled on both ends
• WiFi Distance: 6 feet between the MacBook and AP
• WiFi Configuration: 160 MHz channel width, 2 spatial streams, WPA3, DFS Channel 100; RSSI -45

The Intersection of Vibe Coding and Security​

Many of us have seen glimpses of what agentic generative coding does for security. We see the missteps, and sometimes wonder about the shallow bugs that pile on. Config managers that are almost always arbitrary file upload endpoints. Glue layers that become bash command launch as a service. And most frustratingly, code generation that's excellent at pretending forward progress has been made when no meaningful change has occurred. One of the most impressive parts of agentic coding is exactly that: how convincing it is by appearance and how easily we're tricked about the depth of substance in the code gen. In some ways we extend our trust of people to the stochastic code parrots, assuming that generative coding produced the actual work a human would have probably performed.

Vibe Identity: An Obvious Flaw​

I'm no stranger to e2e breaks, and have been following along over the past decade. Some of my favorite breaks I have found personally include Vaudenay oracles against Kakao, LINE, and bypassable OTR signature verification in iCloud Keychain compromising the password sync.

So this morning when bitchat came up I took some time to look through the code and write up some demos. My first thought was we really don't want or need another protocol, many aspects of Noise would fit in for finer points around true forward secrecy.

But bitchat's most glaring issue is identity. There's essentially no trust/auth built in today. So I would not really think about this as a secure messenger. The protocol has an identity key system, but it's only decorative as implemented and has misleading security claims. The 32-byte public key gets shuffled around with ephemeral key pairs as an opaque blob. The user verification is unfortunately disconnected from any trust and authentication. These are the hallmarks of vibe code (in)security.

Supernetworks macOS SMB Client Vulnerabilities

What to Know​

Supernetworks identified several vulnerabilities in macOS Sequoia’s SMB client code.
The worst of which can result in remote kernel code execution via an SMB URL delivered through any application that allows clickable URLs (e.g. messaging apps. Browsers, email client). This isn’t necessarily a one click attack, as a user may need to click through some UI elements to trigger the exploit. A privileged network position could also be used to carry out a man-in-the-middle attack against a user that typically uses SMB shares. It goes without saying that this also operates as a local privilege escalation from a non privileged user to kernel code execution.

SPR now supports dedicated Guest WiFi networks! This convenient feature provides internet access to visitors while maintaining separation from your primary network.

uBlock Origin is the best browser-based content blocker available on the web today. And it's user supported, free to use. Sadly today Google just pulled the plug on it by enforcing their new v3 manifest.

Users need to migrate or employ dns based content and ad blocking, which SPR can provide.

Pioneering WiFi Security​

Supernetwork's flagship project, SPR, is a pioneer in WiFi security and we've supported multi-pass WPA3 from the inception of the project in 2022.

To use newer protocols like WiFi 6-e and 7, users can not fall back to WPA2, which is excellent since WPA2 suffers from passive sniffing & password cracking attacks.

WPA3 provides a zero knowledge proof: there's no handshake to sniff and crack -- but the protocol is rigid and makes it hard to support multi-pass. So most products only do it for WPA2 sadly, meaning they can't operate on 6-e or 7. This leaves users making more bad security tradeoffs. SPR works to give people the best security choices by default but the user experience could still vastly improve.

A new project, DecoyAuth, by Mathy Vanhoef, seeks to do that just that and make WPA3 better support multipass.

The project was presented at PAKE25 and the slides are here.

How to Sleep Better When Your Bed is a Backdoor​

The folks at over at Truffle Security performed some excellent research on the Eight Sleep Internet connected bed "Removing Jeff Bezos From My Bed ◆ Truffle Security Co. . It will come as no surprise to anyone who follows IoT security that the bed has some serious security problems, most notably the ability for Eight Sleep's engineering team to be able to ssh in to the bed's on-board computer, via what appears to be a shared support account.

Anvil Secure recently published a post and whitepaper covering conntrack flaws that are common with many linux routers and linux "multihomed" devices. In this post we'll cover SPR, how our process mitigated the highest risk vulnerabilities, how we fixed the rest and other improvements we're making to be resilient against attacks like this in the future.

Overview​

Conntrack is part of Linux Netfilter and is an integral part of a stateful firewall for allowing Network Address Translation on a network. A router uses it to allow clients to establish connections through the uplink interfaces.

Anvil Secure published details on how devices often fail to lock down their firewalls correctly since Conntrack operates at layer 3. External attackers that are one hop away can abuse this to spoof IP addresses and send traffic to internal interfaces on devices and routers for an established connection managed with conntrack. For most of our users, this limits the attack to compromised or hostile ISP providers, which is an uncommon (but not unheard of attack vector). However, since the WiFi Pod can be used as a travel router, it's important to us that they are can withstand being attached to a hostile network.

The riskiest of the attacks happen to not affect SPR.

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.