Memory Corruption Hardening is Controversial Now?​

Social Media has a lot of criticism lately for the push for memory safety as a metric for the labeling of software security. Between software supply chain susceptibility, command injection, and logic bugs obliterating software regularly, it doesn't seem like its the best candidate for a software safety metric.

The background for why the federal government is reporting in the area is E.O. 14028

From the EO there's several pushes for software and network safety. These are things like requiring Zero Trust Access for the Federal Government, EDR on federal systems for monitoring and responding to attacks, SBOMs for supply chain safety, and creating safety standards for IOT devices. Although the main focus is the federal government there's an aim to push out software safety standards to the public as a whole.

And it's regulation for consumers that I see getting some criticism. NIST's key areas interact with the labeling of safety for IOT and consumer software -- which has everyone skeptical because the government may not seem to be the best equipped for leading edge software practices, and regulatory overhead will raise the burden for software developers without necessarily moving software security forward.

On memory safety specifically, two key documents have been released over the past two quarters. The first is CISA's report on Memory Safety. The second is the ONCD Report on Measuring Memory Safety.

The I Soon Dump​

"The documents come from iSoon, also known as Auxun, a Chinese firm headquartered in Shanghai that sells third-party hacking and data-gathering services to Chinese government bureaus, security groups and state-owned enterprises. "

The Washington Post writes that "The documents show that iSoon met and worked with members of APT41, a Chinese hacking group that was charged by the U.S. Justice Department in 2020 for targeting more than 100 video game firms, universities and other victims worldwide."

Alerting Made Easy​

We've rolled out a lightweight alerting mechanism built right inside of SPR.

So SPR already has an event system and we wanted to improve the existing notification system as well as persist alerts for later.

We wanted something with the following properties:

• Allow powerful matching expressions
• Work with our lightweight key-value database for concurrent access
• Minimal system performance impact
• User Customizable, in UX with minimal coding

What a year it's been for the Secure Programmable Router (SPR) project! We've made great strides in empowering users to take control of their networks, prioritize privacy, and unlock network configurability. Let's dive right into the highlights of 2023 and peek at what's in store for the future.

Nzyme lets people monitor their wifi networks with sensors that collect wifi data (as well as network traffic).

It can detect common wifi attack tools and tactics like deauths for getting WPA2 handshakes to crack, rogue APs, and more.

We've put together a plugin that can run alongside the SPR AP without affecting the channels, by creating a monitor interface. While this won't be able to detect Rogue APs, it can detect some anomalous activity.

The plugin is available at https://github.com/spr-networks/spr-nzyme-tap/

Update​

This post has become a guide which is being kept up to date, check it out!

Overview​

In this post we'll show how PLUS members can add a mitmproxy plugin to their SPR setup, and then use the Programmable Firewall (PFW) plugin to redirect traffic through mitmproxy with DNAT forwarding.

We do not need to configure our clients with proxy settings to point to mitmproxy, or rewrite DNS responses, since we are using the PFW feature to do the redirection.

This plugin is available on github.

The built-in wifi radio on a Raspberry Pi 4 is kind of sad, as it does not support monitor mode. Luckily the hackers at Seemo Labs have fixed this.

In this post we'll describe how to load Seemoo's Nexmon onto a pi4 running a modern kernel, and package it into a SPR Plugin named spr-nexmon. We'll demonstrate that packet capture and injection works.

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)

Noppenheimer​

At Defcon CTF Finals, the Final round of LiveCTF went into sudden death. The challenge was named Noppenheimer, a play on the Oppenheimer film that was released, and NOP (NO-OP) instructions.

Contestants had to turn a random sequence of bytes into a gadget/shellcode cave by converting bytes into NOPs, by sending "nuke" Launch commands.

Options:
LAUNCH x,y - Launch a test at position x,y
VIEW - See state of test site
ENDTEST - Conclude testing
>

Both teams solved locally. But they couldn't exploit Noppenheimer against the remote system.

Introduction​

This guide allows you to setup your own cloud VPN using SPR for $4/month on the DigitalOcean Marketplace. It features ad blocking, firewall rules, and device micro-segmentation.

If you want to dive in directly: Click here to create a droplet using the SPR image. Else, follow along in the steps below.