New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reporting suspicious activity - revoking all permissions to prevent potential malicious attacks through Github or crates.io #1257
Comments
Nice catch! I am always thankful for your steady dedication to Piston. |
Please change passwords if you think your Github account might be compromised. No detected attacks so far. Inviting back private owners on crates.io, since these are least risky. For safety, I changed access of PistonDevelopers and Admin group on various repositories to "Read". This can be changed back by need, but I prefer to add people as Collaborators to minimize attack surface. I also set a few Collaborators to "Read" that hadn't contributed so far to specific repositories. Hope you don't mind. If there's a problem, I can change this back to "Write". Will have to decide later what to do about the PistonDevelopers ownership on crates.io. I'm thinking about adding the Owner team to crates that doesn't get worked on/published very often. Then, perhaps we'll take a review of the policy for keeping people in PistonDevelopers before turn back "Write", or perhaps we'll do something else. |
Although 2FA is still a bit of a hazzle, and I'm unconvinced about the promised security improvements compared to just using a high-entropy random password. My view on the topic may change when FIDO U2F (or equivalent) gets browser support not only from Chrome. However, while enforcing 2FA for accounts with administrative priviledges could be reasonable I would not want to (yet) have that burden on just any membership including contributors without release permissions (is it possible to enable it selectively like so?). Just my 2cents. |
Currently there's no good way to enforce MFA only to the administrator group. But admins can manually review each other admins' MFA status though. By the way Firefox supports WebAuthn API. They do not support only U2F. |
Yes, I'd highly encourage at least requiring MFA of all owners, and
possibly considering members as well, especially with the presence of
software MFA such as Google Authenticator. The benefit is not about adding
entropy (though that is great and should be encouraged!) but about
preventing replay attacks where a compromised session or machine provides
unlimited access to high-privilege actions to an attacker.
…On Tue, Dec 25, 2018 at 9:08 PM Hyeon Kim ***@***.***> wrote:
Currently there's no good way to enforce MFA only to the administrator
group. But admins can manually review each other admins' MFA status though.
By the way Firefox supports WebAuthn API. They do not support only U2F.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#1257 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAdCxy-74oxXt1DzYWcCie35iCjpt_Loks5u8uhIgaJpZM4ZhNoQ>
.
|
Ekhm… #851 |
I found the invite as hidden comments by using search on the user for this organization. This means that the likelihood of compromised accounts is much lower now. Corrected the top comment. |
After all of these changes I seem to have lost write access to all of the piston repositories. Was this intentional? And if so what is the new process for gaining write/merge access to repositories? |
@fintelia Yes, this was intentional to prevent damage until the situation was analyzed. The Admin group has now "Admin" access to all repositories. This group can add collaborators with write access by need, until the new policy of the PistonDevelopers team is resolved. |
I opened #1263 to update to new policy of inviting people to the PistonCollaborator. If there are no objections or feedback in 24 hours, I will merge this and set back "Write" permissions to all repositories for the PistonCollaborator team. I believe this is the right setting since we get some control over who's get invited as collaborators in other ways (only Admin team should do that). I plan to create a separate team with owner permissions on crates.io. This will split the attack surface into two parts and make the project less attractive as a target. |
The new team is now set up with permissions to publish. See #1265 Closing. |
Attention @PistonDevelopers/pistoncollaborator @PistonDevelopers/admins @PistonDevelopers/owners
17 hours ago, a Github account, who has never contributed to commits or issues, added public deploy key
05:99:67:68:24:55:9f:98:c8:25:44:ec:76:10:ee:aa
to all repositories under the PistonDevelopers organization. These keys were removed immediately upon discovery. The user's membership was removed from the organization.As by default, all members have now their permissions revoked. The Piston project will shut down temporarily until our security policies have been reviewed.
I ran through a todo-list produced by Eco, removed all owners on crates.io except myself. Will check the repositories manually to see if there are remaining crates that might be targeted through crates.io.
There has been no detected attacks so far, but I'll keep looking.
The text was updated successfully, but these errors were encountered: