Sometimes I want to work on client assignments (penetration-tests) from home, if I do that I am using my company VPN so that all traffic is routed thorugh their public IP address (which is white-listed by the client). I do not want for traffic to ever leave that VPN as that would look like as if I’d be performing cyber attacks from my private home IP address. The same requirements arise for different use-cases, e.
So I held a lecture on “Web Application Security” for the FH/Technikum Wien last spring and wrote a small booklet for my students (partially because I wanted to avoid discussions during the final exam). I did volunteer for a anonymous feedback round which turned out very positive for me, the booklet was repeatatly mentioned positively. So I distilled and refined it, tried to improve its focus. As I will do the same lecture next year, I am in dire need of feedback so that I can improve it, so I went to dark places and published it on reddit.
I spent some time playing around with various LTE-options for my Raspberry Pi Access Point/Router setup. My Huawei E3372 USB LTE modem works find but only implements a fake network card. This means that a virtual network card is emulated, all traffic is NATted over a virtual router located behind that virtual network card. This happens in addition to the network translation (NAT) that my Raspberry Pi access point already does.
Most of you (and there are a couple of thousands of you) come for my tech-posts, but it seems that some of you get lost reading my non-techie posts too. Time to add on of those, it’s been a while.. I breathe books, they give my brain constant input to thrive on. Recently I went through my goodreads list of reread-good-books to check what influences me and started to reread some of them.
In one of my last experiments I replaced my crappy T-Mobile (now Magenta) 4G modem/access point with an OpenWRT-based cheap travel router and a 4G USB LTE modem. That doubled my speed over the wireless (WLAN) network but the setup was limited by the outdated and under-powered travel rooter. So I got myself a cheap Raspberry Pi 3b+ and created a minimal Linux-based 4G router/access-point. My basic goal was to create the minimal feasible configuration so that I have a good starting point for future IoT/VPN/SmartHome experiments.
Recently I upgraded from my “old” Motorola/Lenovo G6 plus to a Xiaomi Mi Mix 2s. Why the new phone? Main reasons for that upgrade were: The old phone started to look like a banana. Seriously, I carry my phone in my back pockets and after a year that.. let to a more-than-slightly bent phone. This might have let to another problem: random vibra-call activation. Originally I thought that I was just imagining them, but recently my phone started to vibrate while it was in my hand — while no notification or interaction at all was happening.
My LTE internet connection (70 Mbit downstream, 15 MBit upstream) came with a combined Huawei B315s LTE modem/access point. As I was using it for the last two to three years a couple of problems did arise: the internet connection was often shaky, oftentimes the uplink connection got lost and I had to power-cycle the modem/access point. Subjectively this got improved with the last system upgrade. while the internet down speed on the wired connection was good, the speed achieved through the wireless connection was atrocious (see measurements later in this blog post) the power supply is badly built and takes the space of two power outlets.
During a recent assignment the customer server was utilizing a WebSocket for some notification transport, part of my assignment was to fuzz-test the used WebSocket (and the messages transported over it). To do this, I turned to my typical tools: PortSwigger BURP only supports display of WebSocket messages but not altering and/or automated fuzzing of websocket messages. OWASP ZAP can inject and fuzz web sockets (e. g. using FuzzDB vectors), alas the tested application disconnects the websocket and thus prevents ZAP from performing the fuzzing attack.
During a recent pen-test I stumbled upon a JSON Web Token(in short: JWT) based authorization scheme. JWTs consist of three parts: header, payload and verification information. The initial header part contains the name of the algorithm that will later be used to generate the verification part of the JWT. This is dangerous as an attacker can change this information and thus (maybe) control what scheme will be used for verification by the server.
There’s power in switching mental models. In my work, switching from “there might be a vulnerability in this software” to “i just haven’t found the vulnerability” was a game changer for me. I get nervous prior to presentations; one switch that helped me was that instead of thinking “my goal is to look bright” I try to remember that my goal is to teach the audience something and it doesn’t matter who stupid I look as long as they gain something from me.