9 ms·

Giteabot account was compromised

134 points by sarif 8y ago

saagarjha 8y ago
Has anyone taken a look at the binaries themselves to see what they do and how they differ from the official releases?
- sarif 8y ago
  Far as I know, no. Asked this question on the issue page. Really want to find out as I have at least one server that could have been affected. Kind of frustrating that this is all the information there is.
- dabber 8y ago
  This comment links to them: https://github.com/go-gitea/gitea/issues/4167#issuecomment-395579466 https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...
- rmsaksida 8y ago
  The creator of the GitHub issue said the binary contains a cryptocurrency miner.
  - saagarjha 8y ago
    Where does he say that?
    - rmsaksida 8y ago
      It's in the issue body, first bullet point. https://github.com/go-gitea/gitea/issues/4167#issue-330114075 https://github.com/go-gitea/gitea/issues/4167#issue-33011407... > Most of go-gitea organization repositories new release&tag was created with name 0 and added install.exe binary (13KB in size) to that release that was malicious (from our analysis contained crypto currency miner)
- graystevens 8y ago
  I've started to take a look at the binary that was uploaded - it seems it wasn't just Gitea that got hit by this, but also https://github.com/opencompany/www.opencompany.org https://github.com/opencompany/www.opencompany.org which too has a strange release associated with the repository. My findings as they go are being shoved into a blog post: https://grh.am/2018/a-look-at-the-compromised-gitea-release/ https://grh.am/2018/a-look-at-the-compromised-gitea-release/
amaccuish 8y ago
ouch, this is a case where things like red october by cloudflare could be a great idea. Having to have a minimum number of signers to agree to sign a package would be a good way to prevent this.
- ljm 8y ago
  Even simpler, have the releases performed by a human account. It can still be compromised but you're not going to be storing your own GitHub credentials on a server or inside a CI flow so it can automatically write on your behalf. You probably shouldn't be releasing so often that it's a pain in the ass to perform it manually (in terms of tagging in git rather than doing a full on deploy to a server or something). It also means that maintainers are accountable for each release and if something like this happens, you know exactly who you need to talk to to get the situation resolved, which might be something as simple as setting a stronger password or not committing a GitHub token into their public dotfiles.
- m_sahaf 8y ago
  This approach is probably an overkill, but this project called Cothority[0] can be used to verify binaries by semi-independent authorities to be released. One of the applications referenced in their dotSecurity talk[1] was this usecase. [0] https://github.com/dedis/cothority https://github.com/dedis/cothority [1] https://www.youtube.com/watch?v=YostyJRwqVU https://www.youtube.com/watch?v=YostyJRwqVU
josteink 8y ago
Funny to see this news posted on github, after people having suggested gitea as a viable platform to migrate your github projects to ever since the MS buyout. Good thing on them being open about it though, despite it probably costing them some potential traction.
- the_common_man 8y ago
  Many projects are ironically this way. Gitea, gogs, yunohost, sandstorm to name a few.
  - aphextron 8y ago
    I think they solve different problems. Gogs is amazing for a self hosted git repo. Not so much for collaborating with thousands of people around the world. Centralization can be a very good thing if done by an ethical company with the right incentives. The only reason decentralization is useful is when you can't trust anyone for anything. I'd rather live in, and work towards, a world where that's not the case.
    - Zamicol 8y ago
      Would decentralization's value also hold true as technical barriers fall? The costs of centralized organization must continue to fall (even "negative" costs) to compete against any advantage decentralized solution realize as the cost of the technology falls.
  - tboerger 8y ago
    But some (like Gitea) are working on it to start hosting it on their own. Gitea will also get federation features to make contributions between independent Gitea instances possible. But even when it starts to host, it will get GitHub OAuth2, just to keep the barrier small to receive contributions.
- tpfour 8y ago
  Gitea isn't meant to replace Github... it's meant to be a self-hosted alternative to it. That's subtly different. I use it for as my local git server on Debian 9. Binary is in the /home/me/gitea directory. Run the usual gitea setup, then copy this to /home/me/.config/systemd/user/gitea.service: [Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target [Service] RestartSec=2s Type=simple WorkingDirectory=/home/me/gitea ExecStart=/home/me/gitea/gitea web Restart=always [Install] WantedBy=default.target Then just systemctl --user daemon-reload && systemctl --user enable gitea. Then visit localhost:3000 and add it to your remotes (git remote add local ...) and you can push your changes to your own gitea instance.
megaman22 8y ago
Yikes, no code signing certificate, no details filled out for details or even a copyright, at least on the exe I examined.
deleted 8y ago
[deleted]
soulchild37 8y ago
Was thinking to install Gitea earlier and saw this on hackernews, is it safe to install using binary yet?
- cosmojg 8y ago
  Yeah, it should be safe now. They re-released the binaries and set up 2FA.
  - kingosticks 8y ago
    Why is it possible to even create a group that doesn't mandate all users have 2FA?
- lucb1e 8y ago
  Linux version has always been safe as far as I understand it. Not sure what platform you would have downloaded. Some distributions also have it in their repositories, and those were not affected either. It was really just the Windows binary hosted there.
peterwwillis 8y ago
I haven't actually done cryptographically signed continuously released applications before. I was just thinking about how it should work, and it seems a little complicated. I'm not sure how to safely sign the build. 1) You have to sign your code, obviously. If the code isn't signed, none of the resulting build artifacts can be trusted, because where did the code come from? 2) Once your code is signed, you can run a build on verified-only code artifacts, which can produce a build artifact. But if the server doing the build is compromised, you can just put anything at all in the built artifact before it's signed. Sure, you had signed code, but if I can inject my own code into the compiler (or whatever) or just take over the build process and give it my own code, then I can make any kind of build artifact I want. The only way I can think to "confirm" this build artifact is genuine is to get multiple hosts to independently build the artifact identically and compare them. So you have to have reproducible builds. Which I don't think many people have. So, what part of the pipeline am I missing?
- mikeash 8y ago
  You need reproducible builds, a trusted compiler, or an audit of the compiled binaries. Most of us go for the “trusted compiler” approach, and just really hope we’re right.
- aaron_m04 8y ago
  > The only way I can think to "confirm" this build artifact is genuine is to get multiple hosts to independently build the artifact identically and compare them. So you have to have reproducible builds. Which I don't think many people have. This is an excellent idea, and has been done for Bitcoin and other projects: https://github.com/devrandom/gitian-builder https://github.com/devrandom/gitian-builder It's probably troublesome to setup for a new project of significant size.
deleted 8y ago
[deleted]
mhils 8y ago
GitHub's permission system is quite brittle here: Anyone with write access to a repository can silently swap out binaries on the releases page, which are then still listed as "Verified" if the commit is signed. It's a complex problem, but the current approach feels subpar.
- aaron_m04 8y ago
  Sounds like a good opportunity for integration with GPG, keybase, and other signing tools.
  - kingosticks 8y ago
    I was surprised that there was no gitlab integration with keybase when I signed up last night to check it out. Not just to save me manually copying my key but for the cross-platform identity verification.
  - Boulth 8y ago
    It's not that easy to solve in general. Usually these artifacts are built by CI so it'd have to sign them too (if they are not reproducible the you can't build them locally and check if they are the same). So a person that has admin access in CI can do that too. Of course current design leaves much to be desired.
- deleted 8y ago
  [deleted]
rightos 8y ago
Anyone have the known bad .exe.exe? I'd like to take a shot at analysis on it.
- justinclift 8y ago
  dabbler's HN comment a few below yours has a link to them. https://github.com/go-gitea/gitea/issues/4167#issuecomment-395579466 https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...
  - dabber 8y ago
    Haha, I appreciate your typo in my username. When I created this account a little over two years ago I mistakenly dropped the "l" and didn't realize for a few months (having only copied it from a pw manager.) By that point what was done was done. Years later it makes me a bit happy to think people may actually be reading it as it was intended.
    - justinclift 8y ago
      Heh Heh Heh Didn't even realise I'd gotten it wrong until you mentioned it. :)
deleted 8y ago
[deleted]

134 points by sarif 8y ago

saagarjha 8y ago

Has anyone taken a look at the binaries themselves to see what they do and how they differ from the official releases?

sarif 8y ago
Far as I know, no. Asked this question on the issue page. Really want to find out as I have at least one server that could have been affected. Kind of frustrating that this is all the information there is.
dabber 8y ago
This comment links to them: https://github.com/go-gitea/gitea/issues/4167#issuecomment-395579466 https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...
rmsaksida 8y ago
The creator of the GitHub issue said the binary contains a cryptocurrency miner.
- saagarjha 8y ago
  Where does he say that?
  - rmsaksida 8y ago
    It's in the issue body, first bullet point. https://github.com/go-gitea/gitea/issues/4167#issue-330114075 https://github.com/go-gitea/gitea/issues/4167#issue-33011407... > Most of go-gitea organization repositories new release&tag was created with name 0 and added install.exe binary (13KB in size) to that release that was malicious (from our analysis contained crypto currency miner)
graystevens 8y ago
I've started to take a look at the binary that was uploaded - it seems it wasn't just Gitea that got hit by this, but also https://github.com/opencompany/www.opencompany.org https://github.com/opencompany/www.opencompany.org which too has a strange release associated with the repository. My findings as they go are being shoved into a blog post: https://grh.am/2018/a-look-at-the-compromised-gitea-release/ https://grh.am/2018/a-look-at-the-compromised-gitea-release/

amaccuish 8y ago

ouch, this is a case where things like red october by cloudflare could be a great idea. Having to have a minimum number of signers to agree to sign a package would be a good way to prevent this.

ljm 8y ago
Even simpler, have the releases performed by a human account. It can still be compromised but you're not going to be storing your own GitHub credentials on a server or inside a CI flow so it can automatically write on your behalf. You probably shouldn't be releasing so often that it's a pain in the ass to perform it manually (in terms of tagging in git rather than doing a full on deploy to a server or something). It also means that maintainers are accountable for each release and if something like this happens, you know exactly who you need to talk to to get the situation resolved, which might be something as simple as setting a stronger password or not committing a GitHub token into their public dotfiles.
m_sahaf 8y ago
This approach is probably an overkill, but this project called Cothority[0] can be used to verify binaries by semi-independent authorities to be released. One of the applications referenced in their dotSecurity talk[1] was this usecase. [0] https://github.com/dedis/cothority https://github.com/dedis/cothority [1] https://www.youtube.com/watch?v=YostyJRwqVU https://www.youtube.com/watch?v=YostyJRwqVU

josteink 8y ago

Funny to see this news posted on github, after people having suggested gitea as a viable platform to migrate your github projects to ever since the MS buyout. Good thing on them being open about it though, despite it probably costing them some potential traction.

the_common_man 8y ago
Many projects are ironically this way. Gitea, gogs, yunohost, sandstorm to name a few.
- aphextron 8y ago
  I think they solve different problems. Gogs is amazing for a self hosted git repo. Not so much for collaborating with thousands of people around the world. Centralization can be a very good thing if done by an ethical company with the right incentives. The only reason decentralization is useful is when you can't trust anyone for anything. I'd rather live in, and work towards, a world where that's not the case.
  - Zamicol 8y ago
    Would decentralization's value also hold true as technical barriers fall? The costs of centralized organization must continue to fall (even "negative" costs) to compete against any advantage decentralized solution realize as the cost of the technology falls.
- tboerger 8y ago
  But some (like Gitea) are working on it to start hosting it on their own. Gitea will also get federation features to make contributions between independent Gitea instances possible. But even when it starts to host, it will get GitHub OAuth2, just to keep the barrier small to receive contributions.
tpfour 8y ago
Gitea isn't meant to replace Github... it's meant to be a self-hosted alternative to it. That's subtly different. I use it for as my local git server on Debian 9. Binary is in the /home/me/gitea directory. Run the usual gitea setup, then copy this to /home/me/.config/systemd/user/gitea.service: [Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target [Service] RestartSec=2s Type=simple WorkingDirectory=/home/me/gitea ExecStart=/home/me/gitea/gitea web Restart=always [Install] WantedBy=default.target Then just systemctl --user daemon-reload && systemctl --user enable gitea. Then visit localhost:3000 and add it to your remotes (git remote add local ...) and you can push your changes to your own gitea instance.

megaman22 8y ago

Yikes, no code signing certificate, no details filled out for details or even a copyright, at least on the exe I examined.

deleted 8y ago

[deleted]

soulchild37 8y ago

Was thinking to install Gitea earlier and saw this on hackernews, is it safe to install using binary yet?

cosmojg 8y ago
Yeah, it should be safe now. They re-released the binaries and set up 2FA.
- kingosticks 8y ago
  Why is it possible to even create a group that doesn't mandate all users have 2FA?
lucb1e 8y ago
Linux version has always been safe as far as I understand it. Not sure what platform you would have downloaded. Some distributions also have it in their repositories, and those were not affected either. It was really just the Windows binary hosted there.

peterwwillis 8y ago

I haven't actually done cryptographically signed continuously released applications before. I was just thinking about how it should work, and it seems a little complicated. I'm not sure how to safely sign the build. 1) You have to sign your code, obviously. If the code isn't signed, none of the resulting build artifacts can be trusted, because where did the code come from? 2) Once your code is signed, you can run a build on verified-only code artifacts, which can produce a build artifact. But if the server doing the build is compromised, you can just put anything at all in the built artifact before it's signed. Sure, you had signed code, but if I can inject my own code into the compiler (or whatever) or just take over the build process and give it my own code, then I can make any kind of build artifact I want. The only way I can think to "confirm" this build artifact is genuine is to get multiple hosts to independently build the artifact identically and compare them. So you have to have reproducible builds. Which I don't think many people have. So, what part of the pipeline am I missing?

mikeash 8y ago
You need reproducible builds, a trusted compiler, or an audit of the compiled binaries. Most of us go for the “trusted compiler” approach, and just really hope we’re right.
aaron_m04 8y ago
> The only way I can think to "confirm" this build artifact is genuine is to get multiple hosts to independently build the artifact identically and compare them. So you have to have reproducible builds. Which I don't think many people have. This is an excellent idea, and has been done for Bitcoin and other projects: https://github.com/devrandom/gitian-builder https://github.com/devrandom/gitian-builder It's probably troublesome to setup for a new project of significant size.

deleted 8y ago

[deleted]

mhils 8y ago

GitHub's permission system is quite brittle here: Anyone with write access to a repository can silently swap out binaries on the releases page, which are then still listed as "Verified" if the commit is signed. It's a complex problem, but the current approach feels subpar.

aaron_m04 8y ago
Sounds like a good opportunity for integration with GPG, keybase, and other signing tools.
- kingosticks 8y ago
  I was surprised that there was no gitlab integration with keybase when I signed up last night to check it out. Not just to save me manually copying my key but for the cross-platform identity verification.
- Boulth 8y ago
  It's not that easy to solve in general. Usually these artifacts are built by CI so it'd have to sign them too (if they are not reproducible the you can't build them locally and check if they are the same). So a person that has admin access in CI can do that too. Of course current design leaves much to be desired.
deleted 8y ago
[deleted]

rightos 8y ago

Anyone have the known bad .exe.exe? I'd like to take a shot at analysis on it.

justinclift 8y ago
dabbler's HN comment a few below yours has a link to them. https://github.com/go-gitea/gitea/issues/4167#issuecomment-395579466 https://github.com/go-gitea/gitea/issues/4167#issuecomment-3...
- dabber 8y ago
  Haha, I appreciate your typo in my username. When I created this account a little over two years ago I mistakenly dropped the "l" and didn't realize for a few months (having only copied it from a pw manager.) By that point what was done was done. Years later it makes me a bit happy to think people may actually be reading it as it was intended.
  - justinclift 8y ago
    Heh Heh Heh Didn't even realise I'd gotten it wrong until you mentioned it. :)

deleted 8y ago

[deleted]