A series of avoidable errors.

A brief note in regards to legality

I’d love to start off the blog by explaining how I’ve been teetering on the edge of legality through clever interpretation of terms of service, and perhaps some new and as of yet unregulated technology, however sadly this hasn’t been the case. Instead what follows is a tale of continuous failure, or how I’d like to put it to universities, my courageous perseverance in the face of adversity and repeated hardship. 

The original plan

The plan was simple. Wake up and reset my Kali machine as used in the last project, set up the right drivers for my Alfa adapter, figure out how to enable monitor mode, and get sniffing some packets on my local network. I figured that could be a project in it’s own regards, almost as a staging ground for future assaults on the security of my own and any other willing victims' precious security. After that I planned to investigate various apps and their traffic using a combination of netsniff-ng, due to my previous “success” using the -ng toolset previously, and Wireshark, as I’ve had some experience with it, and I was already trying to do too many new things at once here.

How the original plan was a disaster

The plan was ineffective. My slightly elderly and potentially senile WiFi adapter combined with my almost certainly unstable Kali box provided me with enough error messages to last a lifetime. Below is one of my favourites.

Note to self, don’t mix the airmon-ng tool with trying to change an interfaces mode manually. Not that either worked on their own consistently either. I eventually got to the point where I found a script to virtually reboot my adapter without unplugging it manually, as this seemed to provide some brief respite from the onslaught of error messages. The script can be found here if you're particuraly intrested, you can compile it using the command line then run it as an executable, when it's been given the relevant permissions ("chmod +x" comes in handy here).

Even while making little progress, I ended up sidetracked, testing the aircrack-ng tool on my own network, after apparently capturing some packets in one of my many attempts while connecting to the network on my phone (after a deauth attack of course).

Ironically, the task I had no intention of completing on the day appears to have been the easiest, although I’m not sure about the repeatability of this attack on an unknown network - you’d need to at least know the general syntax of the passkey for that brand of router, or else you wouldn’t be able to generate a wordlist. In this case, as I was merely attempting to test if it would work, I used a wordlist of one word, with that one word being the passkey for the router. At least nothing went wrong here.

Even without the BSSID of the router available online, I’m still not trusting the internet with the passkey.

After growing bored of my constant success, I decided to move back and work on what I’d been avoiding due to a personal disagreement between my VM and WiFi adapter. Unfortunately, I was never able to get the adapter into a stable state while in monitor mode, despite brief moments of success. I believe this is down to the version of Kali I’m running not supporting the drivers necessary for the adapter to properly function. Another alternative issue could be the network manager providing interference, as I found I had greater success when I killed and disabled its attached process - however this then resulted in further issues related to general use of the machine; good luck connecting to an access point when the GUI physically can’t show you available access points. Amusingly this rather foreshadows issues I have later - you may read about them in a future blog post.

The second plan

This plan was far more achievable. Use Burp Suite, a tool I’ve had quite a lot of experience with, to view the traffic between my phone and the internet by routing through my Kali box. In fact this plan was almost superior to the first, as I’m far more comfortable with request analysis than I am packet analysis; even if this has the downside of potentially not showing the full story in terms of data exchange. You may get far more detailed information by viewing individual packets, as they're a far lower level of communication - 3 layers down if you fancy using the OSI model.

How the second went well - technically speaking

By technically speaking I do in fact mean speaking of the technical nature of this project, or series of small failed projects, which I haven’t quite delved into yet. No clever wordplay here I'm afraid.

In order to view requests from my phone in Burp Suite on my Kali machine, I’d need to set up a proxy so that the requests are passed through, allowing Burp Suite to properly delay them, allowing me to examine or change them as I see fit. I’d also gain access to the full range of tools offered by even the free version of Burp Suite, the community edition, such as the repeater, allowing me to store requests to edit, send, and view responses continuously, the decoder, useful for data such as JWT tokens where base64URL encoded is constantly in use, and the proxy history, allowing me to backtrack through my last requests when I inevitably miss something frightfully obvious. Fortunately Burp Suite comes with inbuilt proxy functionality, even for devices on a LAN, although this does require some more work. Specifically this involves setting up a proxy in the devices advanced network settings, nothing particularly taxing. However, due to the nature of security these days, without a valid certificate, only HTTP traffic could be inspected by Burp; this obviously isn’t good enough.  This is because without a valid certificate, encrypted HTTPS data can't be decrypted.

The "foxy proxy" extension allows me to easily update whether I want to route my traffic through Burp Suite using preset proxy settings. For usual browsing, you don't need a proxy at all.

A certificate here is an SSL/TLS certificate, which Burp Suite can generate, and they allow for data to be encrypted and decrypted only by the sender and intended recipient. As this can have some pretty major security concerns if a rogue app or such was to install it’s own certificates on android, to protect the user, only a root access user can install new SSL certificates on android Nougat and up. This means you’d have to root your phone in order to install a new certificate, say for example a Burp certificate. Which is what I need to do. I do have an android phone which is the good news. The bad news is all explained in the next blog. My god there’s a lot of it.