Sometimes you need to get in the way of a hardware device and its controller, and see what it has to say for itself. If you are lucky, the two parts are communicating using a serial port, and then it’s relatively simple to do. In this post, I will explain two scenarios where I had to do this, and the approach that I took in each. As a bonus, I’ll also show some hardware that I put together to make it easier.
After publishing my blog post about running P4wnP1 on an LTE modem, where I explained how to install Linux and P4wnP1 on an actual LTE modem for sneaky USB attacks, and then trying and failing to do an internal presentation to show it off to folks, I realised that I had not completely documented the process. In fact, I had left it rather incomplete as it turned out! As I was intending to give a public demonstration of P4wnP1-LTE, I had some work to do.
I’ve written a couple of blog posts in the past in which I explain how to use Marcus Mengs’ truly excellent P4wnP1. The most common deployment scenario involves a Raspberry Pi Zero W, or possibly a FriendlyArm NanoPi R1S. The downside of these platforms is that you need to be in fairly close physical proximity in order to access the WiFi interface, or even closer to access Bluetooth. The NanoPi R1S can support an LTE modem, to give you much bigger range, but the downside to that is that it looks pretty clunky.
Rogan brought half of his hardware parts bin to the hackathon! Michael Rodger, Daniel Scragg, Isak van der Walt, Thulani Mabuza and Rogan Dawes formed the Chubby Hackers team to investigate the Wink Hub 2 during SenseCon 2023. This was building on our project from SenseCon 2022 where we looked at the Wink Hub 1, particularly the various debug interfaces for the main i.MX28 and the peripheral radio controller chips. There is quite a lot of detailed information available online for the Wink Hub 1, but not a whole lot for the Wink Hub 2. In fact, there is practically nothing! We aimed to change that.
TL;DR: I couldn’t make a custom BlazorPack editor work in Burp, so I used Mallet instead. From an indecipherable binary mess to this, in about 100 lines:
Decoded BlazorPack messages For details on how to do this yourself, even for other protocols, read on!
On a recent assessment, Marianka ran into a website using BlazorPack. As Microsoft describes it: “Today’s modern apps are expected to deliver up-to-date information without hitting a refresh button. Add real-time functionality to your dashboards, maps, games and more.”
When conducting a red team exercise, we want to blend in as much as possible with the existing systems on the target network. For most large networks, that means looking like a Windows machine when you request a DHCP address.
In a lot of cases, though, the machine that we connect to the target network is not going to be running Windows, but more likely, a variant of Linux. By default, Linux DHCP requests don’t look the same as Windows DHCP requests. One way of visualising this would be to take packet captures from Wireshark, copying DHCP requests into a text file and comparing them using Meld.
In part 1 of this series, we set up the NanoPi R1S as a USB attack tool, covering OS installation, installation of P4wnP1, and even keylogging a “passed through” keyboard. In this part, I am going to focus on operations as an Ethernet attack tool, using two scenarios. Firstly, as a box which can be connected to an unused Ethernet port, and provide remote access to the target’s network, and secondly, as an Ethernet Person in the Middle (PitM), where it can be placed in between a legitimate device and its upstream switch, and mask its own traffic using the legitimate device’s IP address and MAC address. In the second scenario, we can also defeat Network Access Control measures, because the legitimate device will handle all of that.
As part of our preparations for our upcoming RingZer0 “Q Division” Training, I have been working on making a software image for the FriendlyArm NanoPi R1S Single Board Computer (SBC) that we’ll be using to demonstrate some close quarters techniques. I will detail the process of configuring an R1S by installing the Armbian distribution as well as P4wnP1 ALOA. We will also take a quick look at getting USBProxy configured to act as a keylogger.
BMC makes a number of mainframe-focused applications, one of which is Control-D. Control-D is a “Report Distribution system for distributed and mainframe platforms”. This blog post describes an authentication bypass vulnerability that was found, allowing access to restricted reports.
To make mainframe-based reports accessible outside the mainframe, and to avoid having to create mainframe accounts for every report consumer, BMC provides a web application, making the reports available via a browser.
In this post, I will recap some of the security research conducted on wireless keyboards and mice, and eventually show how current wireless keyboards and mice can be used to obtain a covert shell on a target computer.
Around 2009, Max Moser realised that most wireless keyboards were simply transmitting the keystrokes in clear text. His initial research targeted systems using 27MHz radios. In 2010, he presented followup research targeting systems using 2.4GHz radios, which suffered from similar vulnerabilities. Manufacturers responded (eventually!) by encrypting the keystrokes, but most elected not to encrypt the mouse movements, because that would introduce latency and increase power consumption for no real benefit.