7 ms·

curl|bash allow personalized attacks... If for example you have an IP address from a certain company. (if you have access to ad targeting data you can refine a

curl|bash allow personalized attacks... If for example you have an IP address from a certain company. (if you have access to ad targeting data you can refine a lot further - just remember web site visits from an IP and match them to IP from curl command) repos are mirrored, come with signing keys and any successful attacks are detected sooner or later and become public knowledge.

oblio 6y ago
> repos are mirrored, come with signing keys and any successful attacks are detected sooner or later and become public knowledge. 1. Not all package managers come with signing keys or actually check them. 2. "Sooner or later" - weasel words. Some of these breaches have been discovered years after the fact. Who really cares if they get discovered after 3 years? By that point all the harm has been done plus the attacker could have taken control of the systems in more varied ways so even removing the initial entry point won't save you.
- adriancr 6y ago
  > 1. Not all package managers come with signing keys or actually check them. Seems like a very big problem with those package manager... Ubuntu as far as I'm aware does proper signing. (as any sane distro and hell, microsoft too) I would not be using those package managers. > 2. "Sooner or later" - weasel words. What's your point?, I trust Ubuntu/Red Hat to keep their keys safe. I trust that google project zero and others would notice anything spooky. I do not trust a random distro with only a few users to keep their keys safe and I do not use that. It's also hard to do a proper attack when you have: ubuntu -> (n) mirrors -> me Ubuntu can't push a malicious package directed at me (I go via mirrors which can be picked at random) Mirrors can't push a malicious package directed at me (they would need ubuntu signing keys, and someone would need to own all of them or be very lucky) And if someone does compromise Ubuntu's keys, they're not going to go after me and risk getting detected that way. There is a lot more security built into package managers then what I said compared to 0 you get on curl|bash.
  - oblio 6y ago
    Package managers include npm, bundler, maven, gradle, cargo, etc, not just distro ones.
    - adriancr 6y ago
      and those package managers need to have security built into them as well.
  - simiones 6y ago
    That's true if you're using Ubuntu's repos. But a lot of software on Linux comes as a key that you need to tell apt to trust, and then a repo that uses that key. This is just as unsafe, if not more unsafe, than curl | bash - it gives me a way to not just send you malicious code today, but also any other time you apt upgrade.
    - adriancr 6y ago
      We are talking on an article that highlights a major flaw of curl|bash. The website owner can determine if you are just downloading to investigate script or if you are downloading and running. In the last scenario the owner can decide to give you bad code and you won't know what happened / can't prove that the website owner did anything to you. With APT the owner cannot see which case it is in, someone can always investigate what is being published by just downloading a package. Otherwise, as you noted - if you trust the wrong person you will get owned either way, but curl|bash is inherently more dangerous due to easy targeting. (I can push a package in apt via curl|bash too so it gets upgrade regularly)
      - mannykannot 6y ago
        While this technique allows an attacker to avoid revealing the exploit if you simply redirect the curl output to a file, it will contain tell-tale information (in this case, bufferloads of zero bytes) allowing one to discern that it is up to no good. The author hints at other techniques for detecting curl|bash (http or dns callbacks), which would obfuscate but not completely mask the attacker's intentions. Note that I'm not advocating for using curl|bash: it's a technique for gathering low-hanging fruit, and there's no point in putting yourself in that position.
rnijveld 6y ago
I wasn't arguing that official distro repositories are unsafe, I was actually saying user provided repos are almost as bad (or even worse in some ways, given that give the feeling of being way more secure) as `curl|bash`. Even if they are signed (such as AUR and PPA) most people will blindly add signing keys for people or organisations they do not know, giving them the feeling that they have secured themselves, but have they really? I guess detecting attacks is easier if all files have to be uploaded to a central service, which does allow everyone to see the personalized attack (I mean adding `if (targetUser()) attackTarget()` isn't that hard, but it would be visible for everyone compared to doing that server-side). But then if I'm a sophisticated attacker I'd be sure to make that way less obvious in my code. My feeling is that it would be detected later rather than sooner if hidden well enough. And that is excluding things like non-official apt repositories.
YetAnotherNick 6y ago
Is `curl raw.githubusercontent.com/.. | bash` fine for you? I think most of the curl | bash uses github master branch. Using your own domain is actually scary as owner have to be sure that they never lose control of them.
- adriancr 6y ago
  I would never pipe something to bash. Always download, inspect, run. (maybe even backup if something strange happens)
  - Uehreka 6y ago
    Really though? What are you looking for in this inspection? This strikes me as one of those things where the “inspectors” underestimate the security of “curl|bash from a known HTTPS origin” and overestimate their ability to detect anything that could evade that security. At that point you’re dealing with a g0d level hacker, or your cert trust has been broken, and in either of those cases you were already pwned.
    - adriancr 6y ago
      I read the script and see if I like what I see. As example: https://sh.rustup.rs https://sh.rustup.rs It's really easy to read and useful to understand what it does. If it's too obfuscated and I can't understand it I don't run it and look for other install options or give up If I do spot bugs, I'll go to their github and provide a PR. If I spot something malicious I'll check the github to see who put it in and raise the problem. (if it's not on github then alarm bells)
corobo 6y ago
Anyone that dedicated would probably more likely bash you over the head with a rock until you give up your password
- adriancr 6y ago
  why would they do that when they can run a script from halfway around the world and take profit without getting caught? I'm thinking ransomware attacks, bitcoin mining farms set up on AWS accounts after stealing keys / racking up huge costs, bank account takeovers, stock market account takeovers... Someone hitting you in the head is easier to avoid / easier to recover funds from. (and if you're in the US and have a gun, that person trying to hit you in the head is going to have a bad time)
  - corobo 6y ago
    I mean they'd more likely do that than target you personally with a curl|bash. That's a very noisy and blatant move, super unlikely to work on anyone techy enough to know what curl and bash is, probably the last resort. Other exploits are on the table and indeed much more likely too
- Ivoah 6y ago
  https://xkcd.com/538/ https://xkcd.com/538/

oblio 6y ago

> repos are mirrored, come with signing keys and any successful attacks are detected sooner or later and become public knowledge. 1. Not all package managers come with signing keys or actually check them. 2. "Sooner or later" - weasel words. Some of these breaches have been discovered years after the fact. Who really cares if they get discovered after 3 years? By that point all the harm has been done plus the attacker could have taken control of the systems in more varied ways so even removing the initial entry point won't save you.

adriancr 6y ago
> 1. Not all package managers come with signing keys or actually check them. Seems like a very big problem with those package manager... Ubuntu as far as I'm aware does proper signing. (as any sane distro and hell, microsoft too) I would not be using those package managers. > 2. "Sooner or later" - weasel words. What's your point?, I trust Ubuntu/Red Hat to keep their keys safe. I trust that google project zero and others would notice anything spooky. I do not trust a random distro with only a few users to keep their keys safe and I do not use that. It's also hard to do a proper attack when you have: ubuntu -> (n) mirrors -> me Ubuntu can't push a malicious package directed at me (I go via mirrors which can be picked at random) Mirrors can't push a malicious package directed at me (they would need ubuntu signing keys, and someone would need to own all of them or be very lucky) And if someone does compromise Ubuntu's keys, they're not going to go after me and risk getting detected that way. There is a lot more security built into package managers then what I said compared to 0 you get on curl|bash.
- oblio 6y ago
  Package managers include npm, bundler, maven, gradle, cargo, etc, not just distro ones.
  - adriancr 6y ago
    and those package managers need to have security built into them as well.
- simiones 6y ago
  That's true if you're using Ubuntu's repos. But a lot of software on Linux comes as a key that you need to tell apt to trust, and then a repo that uses that key. This is just as unsafe, if not more unsafe, than curl | bash - it gives me a way to not just send you malicious code today, but also any other time you apt upgrade.
  - adriancr 6y ago
    We are talking on an article that highlights a major flaw of curl|bash. The website owner can determine if you are just downloading to investigate script or if you are downloading and running. In the last scenario the owner can decide to give you bad code and you won't know what happened / can't prove that the website owner did anything to you. With APT the owner cannot see which case it is in, someone can always investigate what is being published by just downloading a package. Otherwise, as you noted - if you trust the wrong person you will get owned either way, but curl|bash is inherently more dangerous due to easy targeting. (I can push a package in apt via curl|bash too so it gets upgrade regularly)
    - mannykannot 6y ago
      While this technique allows an attacker to avoid revealing the exploit if you simply redirect the curl output to a file, it will contain tell-tale information (in this case, bufferloads of zero bytes) allowing one to discern that it is up to no good. The author hints at other techniques for detecting curl|bash (http or dns callbacks), which would obfuscate but not completely mask the attacker's intentions. Note that I'm not advocating for using curl|bash: it's a technique for gathering low-hanging fruit, and there's no point in putting yourself in that position.

rnijveld 6y ago

I wasn't arguing that official distro repositories are unsafe, I was actually saying user provided repos are almost as bad (or even worse in some ways, given that give the feeling of being way more secure) as `curl|bash`. Even if they are signed (such as AUR and PPA) most people will blindly add signing keys for people or organisations they do not know, giving them the feeling that they have secured themselves, but have they really? I guess detecting attacks is easier if all files have to be uploaded to a central service, which does allow everyone to see the personalized attack (I mean adding `if (targetUser()) attackTarget()` isn't that hard, but it would be visible for everyone compared to doing that server-side). But then if I'm a sophisticated attacker I'd be sure to make that way less obvious in my code. My feeling is that it would be detected later rather than sooner if hidden well enough. And that is excluding things like non-official apt repositories.

YetAnotherNick 6y ago

Is `curl raw.githubusercontent.com/.. | bash` fine for you? I think most of the curl | bash uses github master branch. Using your own domain is actually scary as owner have to be sure that they never lose control of them.

adriancr 6y ago
I would never pipe something to bash. Always download, inspect, run. (maybe even backup if something strange happens)
- Uehreka 6y ago
  Really though? What are you looking for in this inspection? This strikes me as one of those things where the “inspectors” underestimate the security of “curl|bash from a known HTTPS origin” and overestimate their ability to detect anything that could evade that security. At that point you’re dealing with a g0d level hacker, or your cert trust has been broken, and in either of those cases you were already pwned.
  - adriancr 6y ago
    I read the script and see if I like what I see. As example: https://sh.rustup.rs https://sh.rustup.rs It's really easy to read and useful to understand what it does. If it's too obfuscated and I can't understand it I don't run it and look for other install options or give up If I do spot bugs, I'll go to their github and provide a PR. If I spot something malicious I'll check the github to see who put it in and raise the problem. (if it's not on github then alarm bells)

corobo 6y ago

Anyone that dedicated would probably more likely bash you over the head with a rock until you give up your password

adriancr 6y ago
why would they do that when they can run a script from halfway around the world and take profit without getting caught? I'm thinking ransomware attacks, bitcoin mining farms set up on AWS accounts after stealing keys / racking up huge costs, bank account takeovers, stock market account takeovers... Someone hitting you in the head is easier to avoid / easier to recover funds from. (and if you're in the US and have a gun, that person trying to hit you in the head is going to have a bad time)
- corobo 6y ago
  I mean they'd more likely do that than target you personally with a curl|bash. That's a very noisy and blatant move, super unlikely to work on anyone techy enough to know what curl and bash is, probably the last resort. Other exploits are on the table and indeed much more likely too
Ivoah 6y ago
https://xkcd.com/538/ https://xkcd.com/538/