5 ms·

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": "

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.

pyre 11y ago
... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?
- lqdc13 11y ago
  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.
  - ryan-c 11y ago
    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.
    - lqdc13 11y ago
      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...
  - vectorjohn 11y ago
    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.
- ryan-c 11y ago
  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.
  - pyre 11y ago
    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.
    - ryan-c 11y ago
      All the same tricks could just as easily be applied to (wget|curl) pipe to shell scenarios.
      - pyre 11y ago
        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?
- e40 11y ago
  The web server could serve up a different version the 2nd time, to thwart people doing this.
mortenlarsen 11y ago
And remember to use cat -v if you read it with cat. https://ma.ttias.be/terminal-escape-sequences-the-new-xss-for-linux-sysadmins/ https://ma.ttias.be/terminal-escape-sequences-the-new-xss-fo...
Sir_Cmpwn 11y ago
I use curl example.org | vipe | bash - Which opens vim in the middle there. http://joeyh.name/code/moreutils/ http://joeyh.name/code/moreutils/

pyre 11y ago

... so this: wget -qO- 'http://example.com/script.sh' | less won't work to review the script?

lqdc13 11y ago
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.
- ryan-c 11y ago
  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.
  - lqdc13 11y ago
    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...
- vectorjohn 11y ago
  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.
ryan-c 11y ago
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.
- pyre 11y ago
  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.
  - ryan-c 11y ago
    All the same tricks could just as easily be applied to (wget|curl) pipe to shell scenarios.
    - pyre 11y ago
      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?
e40 11y ago
The web server could serve up a different version the 2nd time, to thwart people doing this.

mortenlarsen 11y ago

And remember to use cat -v if you read it with cat. https://ma.ttias.be/terminal-escape-sequences-the-new-xss-for-linux-sysadmins/ https://ma.ttias.be/terminal-escape-sequences-the-new-xss-fo...

Sir_Cmpwn 11y ago

I use curl example.org | vipe | bash - Which opens vim in the middle there. http://joeyh.name/code/moreutils/ http://joeyh.name/code/moreutils/