Awesome work and happy that nothing bad has happened.
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
On Tue, Jan 25, 2011 at 1:14 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
Summary: Fedora infrastructure intrusion but no impact on product integrity
On January 22, 2011 a Fedora contributor received an email from the Fedora Accounts System indicating that his account details had been changed. He contacted the Fedora Infrastructure Team indicating that he had received the email, but had not made changes to his FAS account. The Infrastructure Team immediately began investigating, and confirmed that the account had indeed been compromised.
At this time, the Infrastructure Team has evidence that indicates the account credentials were compromised externally, and that the Fedora Infrastructure was not subject to any code vulnerability or exploit.
The account in question was not a member of any sysadmin or Release Engineering groups. The following is a complete list of privileges on the account: * SSH to fedorapeople.org (user permissions are very limited on this machine). * Push access to packages in the Fedora SCM. * Ability to perform builds and make updates to Fedora packages.
The Infrastructure Team took the following actions after being notified of the issue:
- Lock down access to the compromised account
- Take filesystem snapshots of all systems the account had access to
(pkgs.fedoraproject.org, fedorapeople.org) 3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the present Here, we found that the attacker did: * Change the account's SSH key in FAS * Login to fedorapeople.org The attacker did not: * Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way * Generate a koji cert or perform any builds * Push any package updates
Based on the results of our investigation so far, we do not believe that any Fedora packages or other Fedora contributor accounts were affected by this compromise.
While the user in question had the ability to commit to Fedora SCM, the Infrastructure Team does not believe that the compromised account was used to do this, or cause any builds or updates in the Fedora build system. The Infrastructure Team believes that Fedora users are in no way threatened by this security breach and we have found no evidence that the compromise extended beyond this single account.
As always, Fedora packagers are recommended to regularly review commits to their packages and report any suspicious activity that they notice.
Fedora contributors are strongly encouraged to choose a strong FAS password. Contributors should *NOT* use their FAS password on any other websites or user accounts. If you receive an email from FAS notifying you of changes to your account that you did not make, please contact the Fedora Infrastructure team immediately via admin@fedoraproject.org.
We are still performing a more in-depth investigation and security audit and we will post again if there are any material changes to our understanding.
-- Jared Smith Fedora Project Leader -- announce mailing list announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/announce
25.01.2011, 08:24, "Jose Manimala" josemanimala@gmail.com:
Awesome work and happy that nothing bad has happened.
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
On Tue, Jan 25, 2011 at 1:14 PM, Jared K. Smith jsmith@fedoraproject.org; wrote:
Summary: Fedora infrastructure intrusion but no impact on product integrity
On January 22, 2011 a Fedora contributor received an email from the Fedora Accounts System indicating that his account details had been changed. He contacted the Fedora Infrastructure Team indicating that he had received the email, but had not made changes to his FAS account. The Infrastructure Team immediately began investigating, and confirmed that the account had indeed been compromised.
At this time, the Infrastructure Team has evidence that indicates the account
credentials were compromised externally, and that the Fedora Infrastructure was
not subject to any code vulnerability or exploit.
The account in question was not a member of any sysadmin or Release Engineering groups. The following is a complete list of privileges on the account: * SSH to fedorapeople.org (user permissions are very limited on this machine). * Push access to packages in the Fedora SCM. * Ability to perform builds and make updates to Fedora packages.
The Infrastructure Team took the following actions after being notified of the issue: 1. Lock down access to the compromised account 2. Take filesystem snapshots of all systems the account had access to (pkgs.fedoraproject.org, fedorapeople.org) 3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the present Here, we found that the attacker did: * Change the account's SSH key in FAS * Login to fedorapeople.org The attacker did not: * Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in any way * Generate a koji cert or perform any builds * Push any package updates
Based on the results of our investigation so far, we do not believe that any Fedora packages or other Fedora contributor accounts were affected by this compromise.
While the user in question had the ability to commit to Fedora SCM, the Infrastructure Team does not believe that the compromised account was used to do this, or cause any builds or updates in the Fedora build system. The Infrastructure Team believes that Fedora users are in no way threatened by this security breach and we have found no evidence that the compromise extended beyond this single account.
As always, Fedora packagers are recommended to regularly review commits to their packages and report any suspicious activity that they notice.
Fedora contributors are strongly encouraged to choose a strong FAS password. Contributors should *NOT* use their FAS password on any other websites or user accounts. If you receive an email from FAS notifying you of changes to your account that you did not make, please contact the Fedora Infrastructure team immediately via admin@fedoraproject.org.
We are still performing a more in-depth investigation and security audit and we will post again if there are any material changes to our understanding.
It could be done by compromising his email address.
BTW, you don't have to register in FAS to figure out the address. Just connect to IRC Freenode and message Zodbot: .fasinfo [nickname]
On Tue, 25 Jan 2011 23:59:38 +0800 Misha Shnurapet shnurapet@fedoraproject.org wrote:
It could be done by compromising his email address.
I'm not sure what you mean here... how?
BTW, you don't have to register in FAS to figure out the address. Just connect to IRC Freenode and message Zodbot: .fasinfo [nickname]
Yes, email address is NOT a private part of account information.
kevin
On 2011-01-25 01:24:54 PM, Jose Manimala wrote:
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
Good point, password complexity checks are still listed as a TODO in FAS (although we do have a minimum length of 8 implemented), looks like we just never got to doing it. I've added a note about those in https://fedorahosted.org/fedora-infrastructure/ticket/2574, which we will discuss in the next infra meeting.
Thanks, Ricky
On 01/26/2011 06:51 PM, Ricky Zhou wrote:
On 2011-01-25 01:24:54 PM, Jose Manimala wrote:
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
Good point, password complexity checks are still listed as a TODO in FAS (although we do have a minimum length of 8 implemented), looks like we just never got to doing it. I've added a note about those in https://fedorahosted.org/fedora-infrastructure/ticket/2574, which we will discuss in the next infra meeting.
Maybe we should add a captcha after three (3) failed login attempts ?
Sign up page already has a captcha
On Wed, Jan 26, 2011 at 1:44 PM, Athmane Madjoudj athmanem@gmail.com wrote:
On 01/26/2011 06:51 PM, Ricky Zhou wrote:
On 2011-01-25 01:24:54 PM, Jose Manimala wrote:
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
Good point, password complexity checks are still listed as a TODO in FAS (although we do have a minimum length of 8 implemented), looks like we just never got to doing it. I've added a note about those in https://fedorahosted.org/fedora-infrastructure/ticket/2574, which we will discuss in the next infra meeting.
Maybe we should add a captcha after three (3) failed login attempts ?
Sign up page already has a captcha
-- Athmane Madjoudj
I'm a big fan of eliminating passwords as an authentication option altogether. Though, that's likely to be impractical as a global policy change.
Here's some other ideas that I don't think have been mentioned (on list):
* Tracking unique source IPs of logins, and sending an e-mail to the account owner's e-mail address when we detect a login from a new/unknown IP source. This doesn't solve anything, but may reduce the time between compromise and notifying someone that there's a problem.
* Allow users to establish a white list of allowed source IPs for their login. This will add an additional set of requirements an attacker needs to compromise an account.
However, this would potentially create some chicken-and-egg problems, which would increase support costs when users lock themselves out of their account. It would likely also require additional logic to deal with potential logistical issues related to conventions and other travel.
* Allow users to disable the use of password auth on their account if they have an alternative method configured (e.g. yubikey).
* Password expiration and forced rotation. The typical, "rotate every M days, and the new password can't be any of your last N number of passwords," policy will at least keep the window for compromise a moving target.
---Brett.
On 26/01/11 22:16, brett lentz wrote:
On Wed, Jan 26, 2011 at 1:44 PM, Athmane Madjoudj athmanem@gmail.com wrote:
On 01/26/2011 06:51 PM, Ricky Zhou wrote:
On 2011-01-25 01:24:54 PM, Jose Manimala wrote:
One question is should a password length and secure password creation check be enforced on the FAS system. Like regular expression checks and stuff. I know this is asking a lot, the current implementation allows me to have a simple password if I remember(need to check) been long. And password expiry? :)
Good point, password complexity checks are still listed as a TODO in FAS (although we do have a minimum length of 8 implemented), looks like we just never got to doing it. I've added a note about those in https://fedorahosted.org/fedora-infrastructure/ticket/2574, which we will discuss in the next infra meeting.
Maybe we should add a captcha after three (3) failed login attempts ?
Sign up page already has a captcha
-- Athmane Madjoudj
I'm a big fan of eliminating passwords as an authentication option altogether. Though, that's likely to be impractical as a global policy change.
Here's some other ideas that I don't think have been mentioned (on list):
- Tracking unique source IPs of logins, and sending an e-mail to the
account owner's e-mail address when we detect a login from a new/unknown IP source. This doesn't solve anything, but may reduce the time between compromise and notifying someone that there's a problem.
- Allow users to establish a white list of allowed source IPs for
their login. This will add an additional set of requirements an attacker needs to compromise an account.
However, this would potentially create some chicken-and-egg problems, which would increase support costs when users lock themselves out of their account. It would likely also require additional logic to deal with potential logistical issues related to conventions and other travel.
- Allow users to disable the use of password auth on their account if
they have an alternative method configured (e.g. yubikey).
- Password expiration and forced rotation. The typical, "rotate every
M days, and the new password can't be any of your last N number of passwords," policy will at least keep the window for compromise a moving target.
---Brett. _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Passwords are not the issue. We have got yubikey support, and for a good authentication mechanism, you need a multi-factor authentication mechanism, be it two factor or three factor (probably too hard for our purpose). Two-factor involves something somebody holds, that is a password, and something somebody has, hardware authentication token (yubikey). The GnuPG smart cards, which the FSF also uses, provide this all in one, including a self-destruct option, so nobody who has the card, can keep guessing the password. Maybe if we can, we should implement a password + yubikey option and introduce a password lock, if more than 20 auths have happened, on a yubikey+password enabled account.
Just using the yubikey itself is dangerous. Which , although I own a few yubikeys, do not use for FI/People.
Regards,
Tristan
Hi guys, just so people don't think we aren't listening etc. We are following standard operating procedures around an incident. We have one point of contact for giving out information so that conflicting/incomplete versions aren't given. He is however in Australia at the moment so we are going to have a face-to-face summary to finalize the report at Fudcon and will then let sleep deprived Jared do his part :).
On 1/26/2011 5:24 PM, Stephen John Smoogen wrote:
Hi guys, just so people don't think we aren't listening etc. We are following standard operating procedures around an incident. We have one point of contact for giving out information so that conflicting/incomplete versions aren't given. He is however in Australia at the moment so we are going to have a face-to-face summary to finalize the report at Fudcon and will then let sleep deprived Jared do his part :).
In an odd turn of events, I just received an email from Sourceforge about this: http://sourceforge.net/blog/sourceforge-net-attack/
Coincidence? No idea.
Jima
infrastructure@lists.fedoraproject.org
-
Athmane Madjoudj -
brett lentz -
Jima -
Jose Manimala -
Kevin Fenzi -
Misha Shnurapet -
Ricky Zhou -
Stephen John Smoogen -
Tristan Santore