Andreas Happe: security
During a recent presentation on HTTP Header Security I was asked for a “simple” flow chart with directions which headers can be used without too many problems. The result was this: What was the reasoning? Initially, basic headers that unify browser behavior are set. They control behavior that is already set when using modern browsers (e.g., Referrer-Policy) or unify non-standard behavior (e.g, X-Content-Type-Options: nosniff). The basic idea behind those headers is, that web developers need to make sure that their website works with those anyway (otherwise people using modern browsers might complain) so it makes sense to take care of those situations during development.
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.
So my company moved to a new building which uses HID RFID cards for access control. These cards are typically white with some sort of numeric code printed on one side of them. I have not included an image of my card due to (later) obvious reasons.. Setting up my Proxmark3 RDV4 reader Some time ago I joined the Kickstarter for an updated version of the Proxmark3 RFID reader/writer and immediately broke it during the initial flash update.
Wireguard is recently making a splash as human-configurable low-overhead alternative to OpenVPN and IPSec. As some privacy-centric VPN providers are planning to support it (e.g., PIA) or already have a beta running (e.g., IVPN, as tested by Ars Technica) it was time for me to look into it. The Setup To get a better feeling about the used technology I directly connected my laptop to my desktop (gigabit Ethernet with no switch/router in between) and setup OpenVPN with a minimalist configuration as well as with a more realistic TLS-configuration.
I’ve wrote about about creating a simple wireless (WLAN for us right-pondian) http/https interception setup before. Mostly I’m using this as a first step when testing mobile/desktop applications. Linux’ network-manager is perfectly able to create an software access-point with most modern network cards. Alas GNOME’s configuration tool only allows for the creation of ad-hoc networks (and switching to KDE for just this is a bit overkill for me) so you have to setup the access point on the command line with nmtui or nmcli.
Recently I’ve found an old post-it with guidelines I wrote myself a couple of years back, two of those stood out: make mistakes don’t buy stupid stuff Seems like I haven’t been the most consistent person back then. The post-it got discovered during a clean-up session of my flat, the same session brought up the following stupidly-bought-and-never-used gadgets: one BBC micro:bit that should be able to capture Bluetooth Low Energy transmissions one Proxmark 3 RV4 that should be able to do some nifty RFID stuff (and that I was recently able to fix) one Realtek Software-Defined Radio USB Stick (rtl-sdr).
I have a quite simple setup: Fedora 23 on my Desktop, Ubuntu 16.04 on my Notebook and a YubiKey thrown into the mix. I do have my normal GnuPG key DD436203 that I’m using. There’s also an old and revoked key 3F5D00B6 with which I was testing my YubiKey with (note to myself: don’t use an YubiKey-crested private key as you cannot backup it). My main key offers an ElGamal 2048bit subkey – which does not work with the Yubikey (as that only supports 2048bit RSA).
Update 2017: Sadly I found out (thanks due to the comments on this blog post) that using port-share does not encapsulates subsequent traffic in normal TLS. So using this method will not fool Deep-Package Inspection Firewalls. If you need to mask all your traffic, this is not an option – you might need to investigate stunnel, information can be found here, here or here. I assume, that the higher success rate of this method could be related to some firewalls checking the target of the initial https request.
One important part of the European Prismacloud project is dissemination: make ordinary people understand some of our cryptographic directives. Out of this, the following clip originated: The technique in question is called secret-sharing and was originally detailed in 1979.