Slack authentication middleware for Slim Framework

At $work we use Slim for powering our slack / command bot. It's a really nice minimalist framework in PHP which has a nice set of helpers and features whilst still being very lightweight.

Since we're using it for responding to slack requests, we need to validate whether the headers that slack commands send for auth are all correct (the basic idea is that you generate a HMAC hash using your secret key and the details in the header and see if it matches the hash slack sent). Thankfully, Slim has a pretty lean middleware system, which made the code pretty easy to implement.

I've put the code for it on gist for anyone to use under the Mozilla Public License 2.0:

It assumes you are using phpdotenv to store your shared secret as SLACK_SECRET, but if not you can change this on line 43.

There is also, on lines 20-24 the option to have an AUTH_BYPASS env var set to skip checking for the header, but if you don't need this it can safely be removed.

Deploying an image via the digest in Kubernetes

It's possible in kubernetes to specify an image digest when putting together the spec for a pod or deployment, but this doesn't seem to be documented in the documentation itself.

Fortunately, it's really easy to do, and just involves you using an @ instead of a : between the image name and the digest, being sure to include the leading sha256: so if your image definition looks like this with a tag:

image: foo/bar:latest

Change it to:

image: foo/[email protected]:8dc07735a8ffe78835c91e1e278b8cd75ce7ca6e08ed3d36d4b46e9297434157

to deploy the image by its digest.

Redstar OS Server

For a few years now, iso files of both the desktop and server edition of North Korea's homegrown linux distribution, Redstar OS, have been floating around the internet. There's been an awful lot of analysis of the desktop edition, made famous in part by the blatant aping of MacOS and the kernel level file watermarking it does (Which you can read up on Here
and Here). However there doesn't seem to be that much information on the server edition.

So what better way than to setup a server with Redstar OS and see what's what? The system seems geared towards web servers and comes with packages for the full LAMP stack with httpd 2.2, PHP 5.3 and MySQL 5.5. If you're curious for the full package list on the disk, you can view it here (that is the only source of packages, no yum repos are added as default). You can view the whole site here. EDIT: The server has been taken down as I needed the IP!

At its core the OS seems to be based on RHEL 6 and is running kernel version 2.6.32-201305.RSS3.i686 (Only an i686 version of the server seems to be floating around publicly, but apparently an x64 version does exist). There's no redhat-release or lsb-release, but /etc/system-release gives the OS name as: 《붉은별》봉사기용체계 3.0(갱신판 1) which according to google translates to "Red Star" Service System 3.0 (Update 1).

Installation was a relatively simple TUI and I was able to guess what needed to go where on the pages without too much hassle, though I did need to manually adjust the ifcfg-eth0 file since it seems I filled some details in incorrectly, but nothing too major. Within the OS itself, the kernel boot flags set the system language to ko_KP.UTF-8 and most config files for the web services are in Korean. Interestingly, despite the desktop OS having selinux enforced, this isn't the case in the server edition. Nothing in the grub.conf and getenforce returns a Disabled response. Unlike the desktop edition, which doesn't provide root access, the setup here prompts you for a root password and the account is fully enabled and usable.

The server edition also comes with iptables, so the first thing I did (as little as it may help) was block and for both INPUT and OUTPUT which are the two ranges North Korea are known to use. I also deactivated access logging in the httpd.conf and just disabled rsyslog completely just in case there was something streaming data off somewhere in spite of the iptables block.

I then started tcpdump running on the VM's vnet device on my node, and after approximately ten minutes, there was nothing I could see that looked suspect in terms of network traffic in or out. Just the odd https requests, a few OVH health checks and of course attempts to get at SSH from miscellaneous locations (One from Japan, none from anywhere else in East Asia).

Next I was interested in the kernel module called rtscan that handles the watermarking as mentioned in the above post. Unfortunately, an lsmod seems to show this wasn't loaded and modprobe doesn't show it as being installed. However, I still wanted to test this, so I uploaded a set of files of different formats (.doc, .docx, .jpg, .mp4 and .txt) and md5'd them before uploading them to the server, and got the following outputs:

MD5 (kimjongun.doc) = 9c1bb78d8eb1daebd94ef93f6f981669
MD5 (kimjongun.docx) = d59a2e0aaf3a488183325918d4e130d1
MD5 (rat-with-teddy.jpg) = 9569b73ca7e41099aca434fb6f54e99d
MD5 (text.txt) = cae9c9e0816032b265c58db8e96afc70
MD5 (waterfall.mp4) = 33cdd0d874dcf9cc653f98164b3efb72

Post upload to the server (and after moving them around/touching/etc as both root and a new user) and rsyncing them back md5 gave this output:

MD5 (kimjongun.doc) = 9c1bb78d8eb1daebd94ef93f6f981669
MD5 (kimjongun.docx) = d59a2e0aaf3a488183325918d4e130d1
MD5 (rat-with-teddy.jpg) = 9569b73ca7e41099aca434fb6f54e99d
MD5 (text.txt) = cae9c9e0816032b265c58db8e96afc70
MD5 (waterfall.mp4) = 33cdd0d874dcf9cc653f98164b3efb72

As you can see, no difference. But just to be doubly safe, I popped open both the original file and the modified one in a hex editor side by side to look at Offset 80 for the watermark that has been added (original on left, downloaded off of the server on the right):


As you can see, no watermark or change to the file at all.

So from poking at the server edition, unless they're being very very sneaky, it doesn't seem to have the same sort of tracking code that the desktop edition comes with. Of course, due to the context and history of this release, I personally still find it quite interesting. However, from a technical perspective, it's basically your run of the mill Red Hat inspired distribution albeit somewhat crippled in terms of available packages.

There is apparently a version 4 of Redstar in existence, but as yet, there doesn't seem to be a copy of it on the internet, perhaps that will end up being more interesting?

Add a valid SSL to r1soft server web interface

When you setup r1soft for backups, it will generate its own self-signed SSL for the browser UI. Although it worked fine, the SSL warnings annoyed me and at $work we have a multi-year wildcard for the domain the backup servers sit on, so I decided to sort out a valid SSL for the service.

Unfortunately the r1soft wiki is not great for this as it can be a bit unclear, with the link to key tool they tell you you need being dead, and it took a little bit of fiddling and wrangling with java (one of my favourite things). And why not do their wiki maintainer's job for them?


First you'll need the ImportKey tool to generate the keystore file. The link on the r1soft wiki is dead, but you can get the java file from this git repository. Put the file in /usr/sbin/r1soft/jre/bin

Although r1soft bundles its own version of java, it doesn't include javac which is required to build the ImportKey tool. You should be able to get this from your repos by installing openjdk. The java bundled with r1soft is openjdk 1.7.0, so I downloaded the matching version (package name java-1.7.0-openjdk-devel in centos 7), but in theory openjdk 1.8.0 should also be fine if you don't have repos for 1.7.0, but I haven't tested with this.


First things first, you'll want to ensure you have your SSL certificate in DER format with the cabundle added to the certificate. If you want/need to generate your own from PEM, you should create two files: example.crt and example.key where the example.crt contains your Certificate followed by your CABundle one after the other, and the example.key should contain your Private Key.

Once you have these files, you can run the following openssl commands to convert them to DER files (I do this in /root, but it's up to you where, you'll just need to adjust the upcoming ImportKey commands accordingly):

openssl pkcs8 -topk8 -nocrypt -in example.crt -inform PEM -out examplecert.der -outform DER

openssl x509 -in example.key -inform PEM -out examplekey.der -outform DER

Now you have the necessary certificates, cd to /usr/sbin/r1soft/jre/bin and chmod the file java and keystore to 755 to make them executable. But before we can use the ImportKey file, we need to build it, which you can do by running:


With that done, we can use the included java with r1soft to generate the keystore file, as follows:

./java ImportKey /root/examplekey.der /root/examplecert.der cdp

n.b. Despite the file being, you need to run the command on just ImportKey, otherwise java will complain about not being able to load the class

This will have created a file in /root called keystore.ImportKey and we now need to change the passwords on the keystore since this is hardcoded to just password in r1soft (Yay, security!).

First run:

./keytool -storepasswd -keystore /root/keystore.ImportKey

When prompted for the keystore password, just put in importkey and when prompted for the new keystore password, set it to password. Then we need to change the key password to, which we do with:

./keytool -keypasswd -alias cdp -keystore /root/keystore.ImportKey 

On the first password prompt ('Enter keystore password:') enter the new keystore password, which should be password and on the second prompt ('Enter key password for <cdp>:') put in importkey and then on the final prompt ('New key password for <cdp>:') enter password.

And with that you're basically done, you just need to replace the existing keystore with

cp /root/keystore.ImportKey /usr/sbin/r1soft/conf/keystore

Then just restart the r1soft service (called cdp-server) and you'll be done.

PHP Manager for IIS Fatal Error during installation

Adding new programming language functionality to IIS is pretty streamlined these days via the use of Microsoft's Web Platform Installer which bundles together installers and modules for various languages and handles all the setup for you with a couple of clicks.

However, there is a slight stumbling block when trying to add PHP support to IIS in Windows Server 2016. Specifically, when you go to use Web Platform Installer to install a PHP version, the PHP binaries and modules will install fine, but you'll encounter the following fatal error when the automatically included PHP Manager for IIS tries to install:

Now, strictly speaking you don't need this, it just provides a UI for managing loaded extensions in the php.ini, etc., but it's definitely a nicety to have for managing the config directly within the IIS. Fortunately the fix is easy, albeit involving a bit of registry hacking (Or as my coworker would prefer to call it 'Configuration Changing').

First things first, hit start and in the start menu, type in regedit and open it. In here, via the left, browse through the folder structures to the following location:


Your regedit window should look as follows:

Double click on the MajorVersion value, and in the window that pops up, set the Base to Decimal and the Value Data to 8, so the resulting window should look like:

Save, and then without closing regedit, go to Web Platform Installer and you should be able to install PHP Manager without any issues. Once installed, go back to the regedit window and edit the same MajorVersion Value in the same way, but set the Value back to 10.

Essentially we're spoofing our windows version to the installer as the error occurs due to it checking which windows you're running and failing due to it not matching what it thinks it can support. This is exactly why I'd consider it Registry Hacking rather than simple configuration changes, and also why you should put the value back as there's probably a number of fun ways having software thinking you're running a different version of windows than you are can cause you issues.