Hacker News Reader

Comment by Goopplesoft | Hacker News Reader

Aside: its not sufficient to look at a file you 'curl | bash' into bash via your browser. It is very trivial to detect curl/wget's UA (mine has: "User-Agent": "curl/7.43.0") and dynamically modify files depending on the request's UI.

    if 'curl' in request.UA:
         return 'something malicious' 
    else:
         return 'something nice'

Always create a local file with the content, read it, then perhaps run it.

View on HN

I use

    curl example.org | vipe | bash -

Which opens vim in the middle there.

http://joeyh.name/code/moreutils/

And remember to use cat -v if you read it with cat.

https://ma.ttias.be/terminal-escape-sequences-the-new-xss-fo...

... so this:

    wget -qO- 'http://example.com/script.sh' | less

won't work to review the script?

no but if you change the user agent of the wget to the same one the curl uses, it would be much harder to figure out the differences.

I'm pretty sure wget still makes it's http requests as version 1.0 rather than 1.1 (which nearly everything else uses), and if you want to change that you need to patch it.

of course. There are also other differences. Actually, I have no idea why it even matters unless you are specifically exploiting curl. And they are not in this case. You can redirect wget output to stdout too...

I think he's suggesting using wget both times, not curl. So it doesn't matter what the UA is.

As other have suggested, there are still possible ways to trick you, but it's getting more and more remote.

No. Totally possible to serve the "bad stuff" only some of the time.

Browser exploit kits commonly will return different stuff depending on user agent, and will track what IPs they have interacted with so that if after someone clicks the link you try to look at it, you'll get something harmless. Nasty business. The only way to be sure is to save it, inspect what you saved (make sure you use something that will show tricky escape sequences trying to hide things), then maybe run it.

I'm not sure why you're taking about browser exploit kits when we're talking specifically about using curl or wget to pipe an HTTP payload into a shell.

All the same tricks could just as easily be applied to (wget|curl) pipe to shell scenarios.

Ok. Someone posed a scenario where an attacker uses the User-Agent to differentiate between a victim vetting the URL via a regular browser and someone using curl/wget to pipe it to the shell. I suggested a simple solution to this specific scenario.

There are any number of scenarios where any given solution could be broken. Why not point out that you OS might be compromised and the wget/curl binary that you're using is patched to present the wrong information to you?

The web server could serve up a different version the 2nd time, to thwart people doing this.

Reply on news.ycombinator.com