3 ms·

This attempt is blatant and obvious, but what about a more serious attempt where you first establish some credibility with a couple of "good" PR that fix major

This attempt is blatant and obvious, but what about a more serious attempt where you first establish some credibility with a couple of "good" PR that fix major problems and then add a tiny little backdoor that loads code from somewhere else. Distribute the relevant code over a couple of commits and you might just slip it in. With Githubs ease of merging and automatted testing by Travis, it's easy to forget that changes may be actively malicious and not just buggy.

EthanHeilman 14y ago
Why not just find an exploit in the code. Spending months building trust while creating a giant trail of information that can be used to find you and then really pissing off the open-source community seems like a bad plan for someone that is attempting to quietly gain root. Might work if one project is attempting to discredit another project (think closed source vendor trying to steal clients who use opensourced github projects). I'm not saying someone wont do it, I suspect it has been done a few times, but it is a dumb way to break into computers and far more work/risk than downloading metasploit and using a public exploit.
- Xylakant 14y ago
  Because it works even if you can't find a proper codepath to exploit. It might gain you anything you want: A quiet path to leak admin account info to a server of your choice. An attack vector into a system trusted by more than one person. You don't need to provide much information to get a github account, so the risk is not very much elevated.
  - EthanHeilman 14y ago
    >You don't need to provide much information to get a github account, so the risk is not very much elevated. 1. Unless you are extremely lucky, you have to gain someones trust by posting fixes that do not contain backdoors. This leaves a trail in terms of: coding style, word usage, editor settings (tabs vs spaces), and ip records/timestamps in github. It's not much but it is additional unnecessary exposure. 2. Since the code is publicly available on github it stands a much better chance of discovered later. If you own a server, do you business and change the logs, you have a very very low chance of someone discovering the intrusion after the fact. 3. If someone discovers the backdoor they can setup a honey pot. They might even allow the change to be merged and then wait for you to connect, although this is unlikely. An attacker is potentially forfeiting the element of surprise. 4. Gaining access to a remote server is trivially easy (just use a publicly available exploit before it is patched on your target server), especially if it is a webapp, especially if you have access to the code. I'm not saying there isn't someone out there that thinks this is great attack method. I'm just saying that an attacker that uses this method is either doing it because they think it is funny or a stupid attacker (there is not shortage of stupid attackers).
    - Xylakant 14y ago
      Editor settings are not much of a record if you just follow the projects code guidelines. ip-records with github are more of a problem, but I guess you can fake those by using tor or any proxy. And to embed your malicious code over a series of innocent looking commits, have a look at the underhanded c contest: http://underhanded.xcott.com/ http://underhanded.xcott.com/ There are some true marvels, code that looks innocent as a baby but does malicious things. So yes, owning a server might be easier in some respects, but owning a project might own you a server you'd never get access to - a machine that runs behind a firewall e.g.
  - chii 14y ago
    or better yet, write some code in the same way like this coding contest (where you write some innocent looking code that contains a subtle bug that you can plausibly deny it was intentional...http://underhanded.xcott.com/?page_id=7 http://underhanded.xcott.com/?page_id=7). This way, the blame trail isn't useful in proving anything!
    - EthanHeilman 14y ago
      Thats the ticket!
user24 14y ago
Something similar to this was attempted with the Linux kernel once: https://freedom-to-tinker.com/blog/felten/linux-backdoor-attempt-thwarted/ https://freedom-to-tinker.com/blog/felten/linux-backdoor-att... I say similar because it was not a trusted contributor going rogue but someone actually hacking the public CVS repo.
- gioele 14y ago
  It is claimed that it also happened to the OpenBSD crypto code: marc.info/?l=openbsd-tech&m=129236621626462&w=2 (a bit of analysis on the story: https://threatpost.com/en_us/blogs/experts-openbsd-backdoor-allegations-almost-certainly-false-121510 https://threatpost.com/en_us/blogs/experts-openbsd-backdoor-... ). Long story short. The FBI put on its payroll a well paid crypto analyst trusted with commit access to the OpenBSD code. Years after that, somebody claims that the analyst has put on the FBI payroll to implant an hidden weakness in the crypto code. Audit follows; nothing found in the code. FUD still remains.
  - user24 14y ago
    Someone should write a book about that, it's a great conspiracy theory. Reminds me of Robert Harris - The Ghost in a way.
Firehed 14y ago
I think that largely depends on who's maintaining the official repo. See what happened when oh-my-zsh got careless in testing pull requests: https://github.com/robbyrussell/oh-my-zsh/pull/1395/files#L1R7 https://github.com/robbyrussell/oh-my-zsh/pull/1395/files#L1... everyone who got the update (tons of people, as it's self-updating) had their $HOME screwed up, basically breaking the entire shell. Point being that trust only goes so far here: proper code reviews are what stop these problems.

EthanHeilman 14y ago

Why not just find an exploit in the code. Spending months building trust while creating a giant trail of information that can be used to find you and then really pissing off the open-source community seems like a bad plan for someone that is attempting to quietly gain root. Might work if one project is attempting to discredit another project (think closed source vendor trying to steal clients who use opensourced github projects). I'm not saying someone wont do it, I suspect it has been done a few times, but it is a dumb way to break into computers and far more work/risk than downloading metasploit and using a public exploit.

Xylakant 14y ago
Because it works even if you can't find a proper codepath to exploit. It might gain you anything you want: A quiet path to leak admin account info to a server of your choice. An attack vector into a system trusted by more than one person. You don't need to provide much information to get a github account, so the risk is not very much elevated.
- EthanHeilman 14y ago
  >You don't need to provide much information to get a github account, so the risk is not very much elevated. 1. Unless you are extremely lucky, you have to gain someones trust by posting fixes that do not contain backdoors. This leaves a trail in terms of: coding style, word usage, editor settings (tabs vs spaces), and ip records/timestamps in github. It's not much but it is additional unnecessary exposure. 2. Since the code is publicly available on github it stands a much better chance of discovered later. If you own a server, do you business and change the logs, you have a very very low chance of someone discovering the intrusion after the fact. 3. If someone discovers the backdoor they can setup a honey pot. They might even allow the change to be merged and then wait for you to connect, although this is unlikely. An attacker is potentially forfeiting the element of surprise. 4. Gaining access to a remote server is trivially easy (just use a publicly available exploit before it is patched on your target server), especially if it is a webapp, especially if you have access to the code. I'm not saying there isn't someone out there that thinks this is great attack method. I'm just saying that an attacker that uses this method is either doing it because they think it is funny or a stupid attacker (there is not shortage of stupid attackers).
  - Xylakant 14y ago
    Editor settings are not much of a record if you just follow the projects code guidelines. ip-records with github are more of a problem, but I guess you can fake those by using tor or any proxy. And to embed your malicious code over a series of innocent looking commits, have a look at the underhanded c contest: http://underhanded.xcott.com/ http://underhanded.xcott.com/ There are some true marvels, code that looks innocent as a baby but does malicious things. So yes, owning a server might be easier in some respects, but owning a project might own you a server you'd never get access to - a machine that runs behind a firewall e.g.
- chii 14y ago
  or better yet, write some code in the same way like this coding contest (where you write some innocent looking code that contains a subtle bug that you can plausibly deny it was intentional...http://underhanded.xcott.com/?page_id=7 http://underhanded.xcott.com/?page_id=7). This way, the blame trail isn't useful in proving anything!
  - EthanHeilman 14y ago
    Thats the ticket!

user24 14y ago

Something similar to this was attempted with the Linux kernel once: https://freedom-to-tinker.com/blog/felten/linux-backdoor-attempt-thwarted/ https://freedom-to-tinker.com/blog/felten/linux-backdoor-att... I say similar because it was not a trusted contributor going rogue but someone actually hacking the public CVS repo.

gioele 14y ago
It is claimed that it also happened to the OpenBSD crypto code: marc.info/?l=openbsd-tech&m=129236621626462&w=2 (a bit of analysis on the story: https://threatpost.com/en_us/blogs/experts-openbsd-backdoor-allegations-almost-certainly-false-121510 https://threatpost.com/en_us/blogs/experts-openbsd-backdoor-... ). Long story short. The FBI put on its payroll a well paid crypto analyst trusted with commit access to the OpenBSD code. Years after that, somebody claims that the analyst has put on the FBI payroll to implant an hidden weakness in the crypto code. Audit follows; nothing found in the code. FUD still remains.
- user24 14y ago
  Someone should write a book about that, it's a great conspiracy theory. Reminds me of Robert Harris - The Ghost in a way.

Firehed 14y ago

I think that largely depends on who's maintaining the official repo. See what happened when oh-my-zsh got careless in testing pull requests: https://github.com/robbyrussell/oh-my-zsh/pull/1395/files#L1R7 https://github.com/robbyrussell/oh-my-zsh/pull/1395/files#L1... everyone who got the update (tons of people, as it's self-updating) had their $HOME screwed up, basically breaking the entire shell. Point being that trust only goes so far here: proper code reviews are what stop these problems.