3 ms·

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 real

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!

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!