Giteabot account was compromised #4167
Comments
lafriks
added
topic/security
|
In the meantime please be careful when downloading our released binaries, especially the windows ones, until further notice. E.g. keep an eye on the size of the binaries, or a double We work hard to follow all trails, clean up and get back to daily business as soon as possible. |
|
@daviian Maybe then it is necessary to sign releases? |
|
@Mauladen Thank you for your input. We definitely will discuss this. |
|
Ouch! Yeah, signed binaries would be ideal. |
|
|
|
@Mauladen We've rebuilt the binaries for 1.4.2 release just to be sure we provide safe ones. Or did you mean something else? |
|
This is normal. We retaged 1.4.2 to retrigger CI to rebuild binaries as windows binary for that release was removed and there was added new one malicious one |
|
Still need to edit the list of changes |
|
@axifive commit where not gpg signed by user but github that does it automaticaly (with github key) when the merger is the same the PR author. I wouldn't it consider more safer because if github account were compromised I will been also show as "verified". But we could start to sign tag from now (to be discuss). For information we are, working on signing binary since it is more easy to corrumpt thzan binary as the git commit tree. |
|
You should upload a tarball created by
Libressl uses the same technology. |
|
Is there anymore information on this? What was the payload of the binary? Are users going to be informed about this through a blog post or anything? Were any of the linux binaries compromised? I'm rather concerned about what these things may have done to my servers. I'm doubly concerned that I only found out about this browsing the issue page by chance vs an official notice on the project page/blog |
|
Is the Gitea 1.4.2 release safe to update to from source code at this point in time? |
|
At this point, it's not clear to me whether only binaries were affected. How did you verify this? Are your branches protected? |
|
shasums differ on binaries I downloaded on 6/4 and 6/7 though they are the same number of bytes: |
|
Feel like hosting those somewhere so folks can tear them apart? |
|
Uploaded the binaries here: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. I'll put them somewhere more permanent if necessary. |
|
Question - is it just the binaries on the website that were affected, or were the repositories also affected? I ask because yesterday I heard about Gitea and cloned and built the v1.4 branch. |
|
Would really like some more info if the source itself is compromised or just the binaries. I run a script to check for updates/build from git nightly and was lucky enough to miss this because of the timing. Is the current 1.4.2 release verified to be clean? If we know that's tainted we should pull that ASAP and put it somewhere else for analysis, otherwise people will still be downloading that if they don't see this issue. I agree with @CountMurphy, can we add something to the README so it's really visible? |
|
Can we get hashes so we can check if our binaries are affected? My gitea 1.4.1 (linux amd64) looks like this: |
|
I just downloaded gitea 1.4.1 linux-amd-64 and I got d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 as the sha256 too |
|
To make it overwhelmingly clear: nobody knows anything and the only safe hashes are the ones currently found here: https://github.com/go-gitea/gitea/releases For Gitea 1.4.2 on amd64, that means: Sorry, I misunderstood #4167 (comment) to mean that both binaries were compromised. I've edited this post to remove any ambiguities about what we actually know. |
|
Hold on: according to this comment (#4167 (comment)), there are two shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 from June 4th and c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d from June 7th. Are we saying that both of these are compromised or just one of them? For the record the one on my server is e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 from June 5th. |
|
@christianbundy, Please, don't make hasty conclusions, wait for a response from the Team member |
Sorry about that, I thought the file hashes would be posted by a team member immediately and didn't realize that the info was coming from someone else who was also in the dark. Is this the correct channel to watch for the latest developments? I've powered off my server and need more information to tell whether I've been infected. |
|
I see your edits crossing out the entry I pointed to. HOWEVER, isn't this too early to draw conclusion from? How do we know for sure e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 is fine? We're still missing a couple pieces of information (likely non-exhaustive):
|
|
I got: # ls -la gitea-1.4.1-linux-amd64
-rwxr-xr-x 1 gitea gitea 53663640 May 3 08:02 gitea-1.4.1-linux-amd64With sha256sum and I just downloaded # ls -la gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 root root 53674800 Jun 7 14:18 gitea-1.4.2-linux-amd64With sha256sum
I uploaded Going to watch this issue and keep my gitea installation offline for the time being. |
|
Since you will start signing binary releases, could you also consider signing the Docker images pushed to the registry? |
Just emailed their contact people directly, in case they're not looking at their GitHub issues yet. |
|
@graystevens Should the pastebin staff be contacted to kill that pastebin address, or is it better to fully analyse the malware first so it's properly understood? |
|
Thanks everyone.. Would re download and put my server back up |
|
@justinclift I’ll report the paste to PasteBin now - I’ve got a copy of the contents so we can recreate the output for the malware should we need to. Good shout |
|
To be fair, go is now has reproducible build : https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/ |
|
Just for information, the previous rebuild and un-touched hash list. If you have those hash it means you have the binary before the rebuild we have done to reset the 1.4.2 release and also before the attack. If it is the case, you can stay with them. |
|
The install.exe cleanup pass seems to have missed quite a few repositories:
Most of these are old and not exactly relevant, but it's probably not a good idea to keep malware around. |
|
Ugh, thanks. What's the approach you're using to locate these? It seems that whatever approach the GitHub staff have used hasn't really been 100% effective. 😦 |
|
@jvanraaij @yaggytter thanks. |
|
As after our investigation nothing else was affected and no more information was given by GitHub I think this issue can be closed. Anyone to write blog post about this? |
|
@lafriks I posted this blog post back within a couple of days of this all kicking off - its more of a look at the malware than the issue at hand, but I'm happy to update it if you feel something is worth documenting 👍 |
|
I think he wants to write a post-mortem blog post on the gitea blog :) |
|
@graystevens BTW your site notice link is a 404 one. 😄 |
As a data point, although GitHub haven't said anything about this in public, privately they've responded (via email) to say effectively "Thanks, we're investigating." The above comments by @jvanraaij and @yasuokav seemed to help too, as (weirdly, from my PoV) GitHub don't seem to have found those particular instances of the malware prior to that. |
|
For example, all of the repo's listed by @yasuokav here still have the malware: crossoverJie/SSM#36 I'll email GitHub staff again to point it out. They seem to get things taken care of within a few days when contacted directly with an exact list to look at. |
|
This is sad for all the other projects, but at least for Gitea we have solved the issues properly, hopefully... :) |
|
Closing this issue as binaries are now signed, and 2FA is implemented. |
and others
We are currently investigating suspiscious activity from an account with write access priviledge to go-gitea organization. A binary was added to releases across multiple go-gitea repositories. We cleaned up all releases and drop temporarily access from the account. We will investigate futhermore to understand what really happen to prevent it in the future and be transparent with you trough the process. In the meantime, if you find any suspicious activity please report them under this issue.
UPDATE: No source code or other Gitea infrastructure was affected, including https://dl.gitea.io/ so it's safe to use it to download Gitea binaries.
GitHub account that was hacked is under full control and also have set 2FA so this should not happen in future again.
What was done:
go-giteaorganization repositories new release&tag was created with name0and addedinstall.exebinary (13KB in size) to that release that was malicious (from our analysis contained crypto currency miner). All these releases and binaries was deleted within 2-3 hours from when they were added.We have contacted GitHub but have not received any answer from them, yet
UPDATE2:
No actual gitea binaries were compromised so all hashes mentioned in comments below are safe.
SHA256 of malicious
.exefile:bfc5a0358b1ad76ffbc1e1f4670bd3240536e2fbac88272cee3003322a15fffeUPDATE3:
v1.4.2 has been rereleased at about 2018-06-07 20:00:00 UTC+08
The text was updated successfully, but these errors were encountered: