[Ryan Flowers] writes in with a clever little hack that can allow you to hide data where nobody is going to go looking for it. By exploiting the fact that a web server will generally log all HTTP requests whether or not it’s valid, he shows how you can covertly send a message by asking the server for a carefully crafted fictitious URL.
We aren’t talking about requesting “yousuck.txt” from the server that hosts your least favorite website, either. As [Ryan] demonstrates, you can compress a text file, encode it with uuencode, and then send it line by line to the destination server with curl. He shows how the process, which he calls “CurlyTP” can be done manually on the command line, but it would be a simple matter of wrapping it up in a Bash script.
To get the message back, you just do the opposite. Use grep to find the lines in the log file that contain the encoded data, and then put them through uudecode to get the original text back. Finding the appropriate lines in the log file is made easier by prepending a prearranged keyword to the beginning of the URL requests. The keyword can be changed for each message to make things easier to keep track of.
If you’re still wondering why anyone would go through the trouble to do this, [Ryan] provides an excellent example: a covert “dead drop” where people could leave messages they’d rather not send through the usual channels. As long as the sender used a service to mask their true IP address, they could anonymously deliver messages onto the server without having to use any special software or protocol they might not have access to. Even the most restrictive firewalls and security measures aren’t likely to be scanning URLs for compressed text files.
We’ve seen web-based dead drops done with Python in the past, and even purpose built “PirateBoxes” that allow people to covertly exchange files, but we like how this method doesn’t require any special configuration on the server side. You should check your server logs, somebody might be trying to tell you something.
Well, yes, you could do that… although this assumes I have a web server I admin, it’s logging requests, and I’m fond of grepping for dead drop messages. Frankly, easier and more practical solutions exist.
Yeah, sure but isn’t it more fun to be clever about it? Find a friend who does have access to all this and drop some hints that sends them on an enjoyable sojourn into esoteric server log sleuthing.
Cool. Not necessarily useful (which the author acknowledges), but a fun hack.
There’s some interesting black hat applications for this, such as seeding your target machine with a bunch of data before you make the actual attack and breach.
Think of it like hiding guns inside the airplane you’re about to hijack.
I don’t understand, what is the advantage of sending data over an invalid HTTP request compared to sending data over a valid HTTP request? I mean this is just GET form submission. Might as well have CGI on the server side to stash it somewhere handy. That CGI wouldn’t be any more of a give-away than having a script that scrapes the logs…
One advantage here would be that you don’t need any control over the server side to leave a message. Although, yes, I do think you could use a valid url and just tag on a URL parameter as opposed to using an invalid URL. I think the main reason for that was to make it easier to grep out.
Nothing special installed on the server, which gives you plausible deniability that you were expecting said message. You can send messages like this to any server.
You’re assuming the person has any access to configure the system. The point is that they are not modifying an existing server in any ways, yet they can still make it store information that is made useful later when access is gained, or to anonymously signal to some person with access to the server, who does not want to make it apparent that they’re waiting for a message.
Suppose this is a secret agent scenario, and they don’t want to leave any obvious signs of any communication taking place. You wouldn’t have any scripts scouring the logs – you’d just wait for the logs to come in and eyeball the data off the screen – that’s innocent enough – but the seemingly random data has meaning to you.
Made me think of Tor pluggable transports, specifically meek: https://trac.torproject.org/projects/tor/wiki/doc/meek
But the whole set of Tor pluggable transports is a gold mine of packet skulduggery.
It’s a good hack. I’ve been using this for years to send myself things like windows 7 license keys or short reminder messages. Just use a valid url and add ? plus your message. Another use is to send pre-arranged keywords to trigger a response in software like fail2ban which watches the log. I could send “QQNOBAN” to tell fail2ban not to ban the IP I’m hailing from, or “QQLOGINPORT” to create a port forward so I can log into semi-secure web based tools or VNC.
Does anyone remember all of that mysterious traffic from Russia’s Alfa Bank to one of the unused DJT campaign mail servers?
Knew someone that set up their own DNS server for their domains, but then used it to “query” himself messages and data. Specific queries for non-existent records were actually logged and decoded on the DNS server. No one was interested in peeking at DNS queries, and it got through the firewall just fine.
Infiltrate the IT department. Get a job that allows access to the server logs, with permissions to copy files, including the logs. The spy is now inside the target.
Another member of the team runs the script that sends the URL requests, configured in a way that will make them easy to locate, copy and paste.
The inside spy copies the log file then using the utilities already installed on a Linux workstation writes a script to locate the right URL request entries then copy and paste the lines of UUCODE in order to another text file.
The inside spy feeds that text file to uudecode and there’s the logger that the spy will install to monitor intranet traffic for whavever data the spies are wanting to steal. If the spy has the proper permissions, all that encoded data could be deleted from the log lines and the access dates fixed so it looks like nothing was done.
The spy has not brought any data storage device into the secure server area, nor has anything been removed. The logger “just appeared” on the network.
A similar method could be used to encode data to be sent out. Many websites, when you enter a URL, will show the page with some seemingly random gibberish added to the end. Delete that, copy and paste the remainder of the URL to a new browser tab and that addition comes back.
I assume that’s used for some informational purpose by the owners/operators of the site. But what if it was merely some feature of their software the company doesn’t use at all? A bit of an addon could drip feed an encoded file out that way, to an accomplice using a script to make several requests to different URLs on the server in a specific order.