JSON Web Tokens

The open standard of JSON Web Tokens allows parties to securely transfer claim information. Furthermore, signed tokens allow for verification of the token itself.

One of the most common use-cases of the JWT is for authorization. Once a user’s secrets have been verified, they are issued a JWT containing claim information. This token is then attached to further requests that allows server applications to assert user’s access to services, resources, etc.

JWTs can also be used for adhoc information transfer. A token’s ability to be signed is an important characteristic providing information verifiability between parties.

Structure

A JWT is divided into three primary components:

• Header
• Payload
• Signature

The header contains information about the type of token; this article assumes that JWT is the type and the hashing algorithm. An example header might look something like this:

{
  "alg": "RSA",
  "typ": "JWT"
}

The payload part is expected to have some standard attribute values. These values can fit into the following categories:

A simple payload for a user might look something like this:

{
  "sub": "1",
  "email": "test@test.com",
  "name": "Tester"
}

Finally, the last piece of the JWT is the signature. The signature of the message depends on the hashing algorithm that you’ve selected in your header.

The calculation is going to look something like this:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  "secret"
);

For instance, the following JWT:

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "1",
  "email": "test@test.com",
  "name": "Tester"
}

Computes down to the following JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxIiwiZW1haWwiOiJ0ZXN0QHRlc3QuY29tIiwibmFtZSI6IlRlc3RlciJ9.mFv3TbmAMWui0w8ofwREb9xFqRRl0_Igahl8tbosHMw

You can see that the token itself is split into three encoded strings: header.payload.signature.

This token is now used in the Authorization header of your HTTP requests!

References

• jwt.io
• rfc-7519

Mounting S3 in Ubuntu

Getting the s3 storage mechanism can be easily integrated into your local linux file system using the s3fs project.

Install the s3fs package as usual:

sudo apt-get install s3fs

Configure authentication using a home-folder credential file called .passwd-s3fs. This file expects data in the format of IDENTITY:CREDENTIAL. You can easily create one of these with the following:

echo MYIDENTITY:MYCREDENTIAL >  ~/.passwd-s3fs
chmod 600  ~/.passwd-s3fs

Finally, mount your S3 bucket into the local file system:

s3fs your-bucket-name /your/local/folder -o passwd_file=/home/michael/.passwd-s3fs

That’t it. You can now use S3 data, just as you would local data on your system.

Create a systemd daemon

Like it or hate it, you’ll find systemd on any modern linux system these days. This management subsystem is the newer replacement for the older init scripts-based systems.

In today’s article, I’m going to show you how to create a daemon that will sit under the management of systemd.

.service file

A service file instructs systemd how to interact with the deployed application. It’s referred to as the service unit configuration. The following is an example:

[Unit]
Description=My Service
After=network.target

[Service]
ExecStart=/usr/bin/my-service
Restart=on-failure

[Install]
WantedBy=multi-user.target

Installation

This file, once you’ve created it gets deployed to systemd with a cp. You also need to notify systemd.

sudo cp my-service.service /lib/systemd/system

sudo systemctl daemon-reload
sudo systemctl enable my-service

Interacting with the service

Once the service is in place, you can start to interact with the daemon using systemctl.

sudo systemctl start my-service
sudo systemctl status my-service

You can also get a hold of any log pushed out to the standard system file descriptors:

journalctl --unit my-service --follow

Removal

Once you no longer need your service, you can remove it simply my rm‘ing the .service file. Of course, you’ll need to disable your service first.

That’s it for creating a systemd service.

vim Tips

Getting the most out of vim is really about committing commonly used key stokes/patterns into muscle memory. Once you have the basics of these movements, your text editing experience becomes a lot more optimised and efficient.

This blog post is just an index of useful keystrokes that I use.

Misc. stuff

Macros

Adding text

Buffer management

Navigation

Split management

NERDTree

Executing shellcode in C

A fairly common technique when welding chunks of executable code together is to have the ability to flexibly execute that code. In today’s article, I’ll take you through extracting the shellcode for a function that you write along with the hosting C code that will execute the shellcode for you.

Starting with a C function

First up, we’ll create some shellcode to execute. This is just going to be a very simple function and we’ll compile-only; no linking. Once we have an object file, we’ll use objdump to view the dissassembly and extract the shell code.

Here’s the function.

int foo() {
  return 10;
}

Not the most exciting; but we should take note of the function’s signature at this point. We’re going to create a pointer that points to a function of this signature when we go to execute this code.

For reference, a function pointer that points to a function of this signature would be int (*f)().

Compile, and dissassemble.

gcc -c -03 ex.c
objdump ex.o -d

The shellcode

The output of this function will look something similar to this:

ex.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:	b8 0a 00 00 00       	mov    $0xa,%eax
   5:	c3                   	retq

objdump gives us the dissassembly to the right-hand side; but the hex breakdown to the left is what we’re interested in. Concatenating all of these bytes together, we’re given b80a000000c3. This is our shell code!

Execution

This is all pretty simple.

• Setup the shellcode in an array
• Create a function pointer that points to the shellcode
• Execute that function

#include <stdio.h>

unsigned char code[] = "\xb8\x0a\x00\x00\x00\xc3";

int main(int argc, char **argv) {
  int foo_value = 0;

  int (*foo)() = (int(*)())code;
  foo_value = foo();

  printf("%d\n", foo_value);
}

The variable code holds the shellcode, and you can see it in string form there. We’ve just taken the objdump output and prepared it for a unsigned char string.

We create the function pointer called foo to point to that block of code. Execute the code, grabbing the return value and then print it to screen.

The only tricky part about this is compiling the host program. We need to specify two switches to allow our binary to run.

-z execstack and --fno-stack-protector. Without these our code will just segfault.

gcc -fno-stack-protector -z execstack test.c -o test

This code runs as expected now, pushing a 10 out the STDOUT through printf.