Enforce 2FA for RIPE NCC Access account
Happy New Year, everyone! However, the year begins with some concerning news: RIPE NCC has announced a Security Breach Investigation[0]. It likely relates to the incident where Orange Spain lost credentials[1][2]. This topic has been discussed in the unofficial RIPE Telegram chat[3] and the German network community on Telegram[4], on the discussion mailing list[5][6] and a lot of more places. The primary issue in this case was the lack of 2FA usage. We must not allow ourselves to be distracted by the debate over weak passwords. Even strong passwords can be compromised. A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet. After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered. So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA. To be honest, I don't get the impression that RIPE NCC takes the security of RIPE NCC Access accounts very seriously. How can we, as a community, influence RIPE NCC in this regard? Would it be possible, for example, to develop a policy in the RIPE NCC Services WG that enforces 2FA for RIPE NCC Access accounts? Kind Regards, Benedikt [0] https://www.ripe.net/publications/news/ripe-ncc-access-security-breach-inves... [1] https://twitter.com/Ms_Snow_OwO/status/1742357282917109928 [2] https://twitter.com/vxunderground/status/1742704099035160612?t=GkJ0_jiIGI3NE... [3] https://t.me/ripe_chat [4] https://t.me/bgpde [5] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... [6] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... -- Karlsruher Institut für Technologie (KIT) Scientific Computing Center (SCC) Benedikt Neuffer Netze und Telekommunikation (NET) Büro CN: Hermann-von-Helmholtz-Platz 1 Gebäude 442 Raum 122 76344 Eggenstein-Leopoldshafen Büro CS: Zirkel 2 Gebäude 20.21 Raum 001.1 76131 Karlsruhe Telefon CN: +49 721 608-24502 Telefon CS: +49 721 608-46342 Fax: +49 721 608-47763 E-Mail: benedikt.neuffer@kit.edu Web: https://www.scc.kit.edu Sitz der Körperschaft: Kaiserstraße 12, 76131 Karlsruhe KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Signaturversion: 23.1.0 beta
On 04/01/24 11:04, Benedikt Neuffer wrote:
A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet.
After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered.
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
I agree 100% with this. An LIR administrator should be able to set an enforcing policy that all RIPE NCC Access accounts associated with the LIR account must have 2FA enabled. I also found out today that it is not possible to delete RIPE NCC Access accounts, at least there is no obvious way to do so yourself. (You can de-associate them from LIR accounts, so the security impact is limited, but it seems odd to me that old and unused accounts cannot easily be purged from the system entirely.) Tore
Hello, I agree with MFA requirement in general, but but also RIPE should implement more methods here and don't rely only on TOTP. It's necessary to admit that the development hasn't progressed here too much... There're modern MFA methods like FIDO2/WebAuthn already, unfortunately RIPE access doesn't implement them. There also should opportunity to have multiple methods actived concurrently (to have choice between multiple tokens, for example) - similary to implementations on Google/GitHube etc. - Daniel On 1/4/24 11:04, Benedikt Neuffer wrote:
Happy New Year, everyone!
However, the year begins with some concerning news: RIPE NCC has announced a Security Breach Investigation[0]. It likely relates to the incident where Orange Spain lost credentials[1][2]. This topic has been discussed in the unofficial RIPE Telegram chat[3] and the German network community on Telegram[4], on the discussion mailing list[5][6] and a lot of more places.
The primary issue in this case was the lack of 2FA usage. We must not allow ourselves to be distracted by the debate over weak passwords. Even strong passwords can be compromised.
A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet.
After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered.
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
To be honest, I don't get the impression that RIPE NCC takes the security of RIPE NCC Access accounts very seriously. How can we, as a community, influence RIPE NCC in this regard? Would it be possible, for example, to develop a policy in the RIPE NCC Services WG that enforces 2FA for RIPE NCC Access accounts?
Kind Regards, Benedikt
[0] https://www.ripe.net/publications/news/ripe-ncc-access-security-breach-inves... [1] https://twitter.com/Ms_Snow_OwO/status/1742357282917109928 [2] https://twitter.com/vxunderground/status/1742704099035160612?t=GkJ0_jiIGI3NE... [3] https://t.me/ripe_chat [4] https://t.me/bgpde [5] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... [6] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0...
Hi Daniel, I agree that in the long term, support for FIDO2/WebAuthn would be beneficial. However, as long as a LIR is unable to mandate 2FA or audit whether all accounts have enabled 2FA, methods other than TOTP do not help preventing accounts from disabling 2FA again. RIPE NCC should begin by addressing the basic requirements, and then gradually introduce additional functionalities. Regards, Benedikt On 04.01.24 12:10, Daniel Suchy via ncc-services-wg wrote:
Hello, I agree with MFA requirement in general, but but also RIPE should implement more methods here and don't rely only on TOTP. It's necessary to admit that the development hasn't progressed here too much...
There're modern MFA methods like FIDO2/WebAuthn already, unfortunately RIPE access doesn't implement them. There also should opportunity to have multiple methods actived concurrently (to have choice between multiple tokens, for example) - similary to implementations on Google/GitHube etc.
- Daniel
On 1/4/24 11:04, Benedikt Neuffer wrote:
Happy New Year, everyone!
However, the year begins with some concerning news: RIPE NCC has announced a Security Breach Investigation[0]. It likely relates to the incident where Orange Spain lost credentials[1][2]. This topic has been discussed in the unofficial RIPE Telegram chat[3] and the German network community on Telegram[4], on the discussion mailing list[5][6] and a lot of more places.
The primary issue in this case was the lack of 2FA usage. We must not allow ourselves to be distracted by the debate over weak passwords. Even strong passwords can be compromised.
A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet.
After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered.
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
To be honest, I don't get the impression that RIPE NCC takes the security of RIPE NCC Access accounts very seriously. How can we, as a community, influence RIPE NCC in this regard? Would it be possible, for example, to develop a policy in the RIPE NCC Services WG that enforces 2FA for RIPE NCC Access accounts?
Kind Regards, Benedikt
[0] https://www.ripe.net/publications/news/ripe-ncc-access-security-breach-inves... [1] https://twitter.com/Ms_Snow_OwO/status/1742357282917109928 [2] https://twitter.com/vxunderground/status/1742704099035160612?t=GkJ0_jiIGI3NE... [3] https://t.me/ripe_chat [4] https://t.me/bgpde [5] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... [6] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0...
-- Karlsruher Institut für Technologie (KIT) Scientific Computing Center (SCC) Benedikt Neuffer Netze und Telekommunikation (NET) Büro CN: Hermann-von-Helmholtz-Platz 1 Gebäude 442 Raum 122 76344 Eggenstein-Leopoldshafen Büro CS: Zirkel 2 Gebäude 20.21 Raum 001.1 76131 Karlsruhe Telefon CN: +49 721 608-24502 Telefon CS: +49 721 608-46342 Fax: +49 721 608-47763 E-Mail: benedikt.neuffer@kit.edu Web: https://www.scc.kit.edu Sitz der Körperschaft: Kaiserstraße 12, 76131 Karlsruhe KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft Signaturversion: 23.1.0 beta
Hi Benedikt, this must be solved simultaneously. It's better to have multiple authentication element for one account. Currently, you have only one method (TOTP) and only single authenticator linked to your account. And you have recovery code, which you must have noted somewhere in case the only authenticator fails - and such recovery code can be used to bypass MFA in current implementation. It's necessary to have the possibility of having multiple elements (primary, backup) and remove recovery codes completely. Otherwise it won't be safe in terms of what MFA has to offer. If the organization has a shared account (which is also failure) and the recovery code leaks just like the password, you have similar problem again... - Daniel On 1/4/24 12:21, Benedikt Neuffer wrote:
Hi Daniel,
I agree that in the long term, support for FIDO2/WebAuthn would be beneficial. However, as long as a LIR is unable to mandate 2FA or audit whether all accounts have enabled 2FA, methods other than TOTP do not help preventing accounts from disabling 2FA again.
RIPE NCC should begin by addressing the basic requirements, and then gradually introduce additional functionalities.
Regards, Benedikt
On 04.01.24 12:10, Daniel Suchy via ncc-services-wg wrote:
Hello, I agree with MFA requirement in general, but but also RIPE should implement more methods here and don't rely only on TOTP. It's necessary to admit that the development hasn't progressed here too much...
There're modern MFA methods like FIDO2/WebAuthn already, unfortunately RIPE access doesn't implement them. There also should opportunity to have multiple methods actived concurrently (to have choice between multiple tokens, for example) - similary to implementations on Google/GitHube etc.
- Daniel
On 1/4/24 11:04, Benedikt Neuffer wrote:
Happy New Year, everyone!
However, the year begins with some concerning news: RIPE NCC has announced a Security Breach Investigation[0]. It likely relates to the incident where Orange Spain lost credentials[1][2]. This topic has been discussed in the unofficial RIPE Telegram chat[3] and the German network community on Telegram[4], on the discussion mailing list[5][6] and a lot of more places.
The primary issue in this case was the lack of 2FA usage. We must not allow ourselves to be distracted by the debate over weak passwords. Even strong passwords can be compromised.
A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet.
After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered.
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
To be honest, I don't get the impression that RIPE NCC takes the security of RIPE NCC Access accounts very seriously. How can we, as a community, influence RIPE NCC in this regard? Would it be possible, for example, to develop a policy in the RIPE NCC Services WG that enforces 2FA for RIPE NCC Access accounts?
Kind Regards, Benedikt
[0] https://www.ripe.net/publications/news/ripe-ncc-access-security-breach-inves... [1] https://twitter.com/Ms_Snow_OwO/status/1742357282917109928 [2] https://twitter.com/vxunderground/status/1742704099035160612?t=GkJ0_jiIGI3NE... [3] https://t.me/ripe_chat [4] https://t.me/bgpde [5] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... [6] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0...
Daniel Suchy via ncc-services-wg wrote on 04/01/2024 11:31:
Otherwise it won't be safe in terms of what MFA has to offer. If the organization has a shared account (which is also failure)
RIPE Database passwords and API keys are also "shared accounts", of a sort. Nick
On 04/01/2024 12:04, Benedikt Neuffer wrote: I believe I have found a bug in RIPE Portal 2FA access. To whom should I report it? Thanks, Hank
Happy New Year, everyone!
However, the year begins with some concerning news: RIPE NCC has announced a Security Breach Investigation[0]. It likely relates to the incident where Orange Spain lost credentials[1][2]. This topic has been discussed in the unofficial RIPE Telegram chat[3] and the German network community on Telegram[4], on the discussion mailing list[5][6] and a lot of more places.
The primary issue in this case was the lack of 2FA usage. We must not allow ourselves to be distracted by the debate over weak passwords. Even strong passwords can be compromised.
A while ago, I raised a concern with RIPE NCC about the inability to check if 2FA is activated for an account linked to a LIR. It’s also not possible to enforce 2FA for accounts associated with a maintainer object in RIPE DB. Unfortunately, there has been no progress or action taken on this matter yet.
After some thought, I've come to the conclusion that RIPE NCC's services are so essential to the internet that enforcing 2FA for RIPE NCC Access accounts globally should be considered.
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
To be honest, I don't get the impression that RIPE NCC takes the security of RIPE NCC Access accounts very seriously. How can we, as a community, influence RIPE NCC in this regard? Would it be possible, for example, to develop a policy in the RIPE NCC Services WG that enforces 2FA for RIPE NCC Access accounts?
Kind Regards, Benedikt
[0] https://www.ripe.net/publications/news/ripe-ncc-access-security-breach-inves... [1] https://twitter.com/Ms_Snow_OwO/status/1742357282917109928 [2] https://twitter.com/vxunderground/status/1742704099035160612?t=GkJ0_jiIGI3NE... [3] https://t.me/ripe_chat [4] https://t.me/bgpde [5] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0... [6] https://www.ripe.net/ripe/mail/archives/ripe-list-unmoderated/2024-January/0...
Hi, On Thu, Jan 04, 2024 at 11:04:02AM +0100, Benedikt Neuffer wrote:
So, I propose a discussion urging RIPE NCC to either enforce 2FA on RIPE NCC access accounts globally, allow a LIR to enforce 2FA for linked RIPE NCC Access accounts, or at the very least, provide visibility in the LIR portal to identify which linked accounts have not activated 2FA.
Provide visibility, and enforce 2FA for all accounts hat have "interesting" permissions (modify RPKI objects, transfer resources), at least. So, yes. Please. Monday? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On 1/4/24 16:58, Gert Doering wrote:
Provide visibility, and enforce 2FA for all accounts hat have "interesting" permissions (modify RPKI objects, transfer resources), at least.
from this perspective, even maintainers (linked not only to SSO accounts; [1]) accounts are interesting asset. At least those linked to route/route6 and as-set objects. Deleting them can also cause a lot of operational damage, as filters are processed automatically according to IRR data at many places. And the maintainers are tied directly to all objects, there's no link back to the LIR portal. It's not only about RPKI-related objects. The problem is more complex from this point of view. Only the unwanted ROA modification pointed to it, but the same issue can occur with other kind of objects id DB. Transfers are better protected I think, as there's always some manual intervention (and legal authorization). - Daniel [1] https://apps.db.ripe.net/docs/Authorisation/Using-the-Authorisation-Methods/
Colleagues I almost get tired of saying it, but the RIPE Database is based on a 25+ year old design and technology. Nothing related to the security of your data in the database should be public. Some time ago we filtered the password encrypted string and SSO name. I don't need to know ANY details of your security. Do you use passwords or SSO or PGP or X.509. How many passwords you have. How many SSO accounts are linked. The MNTNER object should not be public!!! The whole security module of the RIPE Database should be redesigned, even if we do nothing else. We currently have an LIR portal, only for people/organisations who are resource holders. But the RIPE Database is a combined number and routing registry. There are people who manage routing data who may not be resource holders. The LIR portal should become an RIR portal. Anyone who maintains data in the RIPE Database should have an account. ALL security arrangements should be managed through the portal account. This needs a completely redesigned security model. Notifications are a form of audit trail. This should be built into a new security model and taken out of the public database, or at least hidden from public view. I don't need to know anything about how you audit changes to your data. It can also be managed through your portal account. EVERY time I raise the subject of the RIPE Database design or technology, EVERY one of you completely blanks the subject. When a service at the core of internet operations is built on a 25+ year old design and technology, why are you surprised it has vulnerabilities The RIPE community's complete refusal to even engage in any conversation about the RIPE Database design and technology and how it secures data is so unprofessional. I know I will be heavily criticised for saying that, but you need to be hit with a dose of reality. It is time for some of you to wake up and smell the coffee. Of course it will cost the RIPE NCC membership money to redesign (part of) the RIPE Database. But how much will it cost you not to do it? Drop this community wide obsession with ignoring this topic and at least discuss the basic question, "Is it time to discuss redesigning (parts of) the RIPE Database?". cheers denis co-chair DB-WG On Thu, 4 Jan 2024 at 17:44, Daniel Suchy via ncc-services-wg <ncc-services-wg@ripe.net> wrote:
Hi,
On 1/4/24 16:58, Gert Doering wrote:
Provide visibility, and enforce 2FA for all accounts hat have "interesting" permissions (modify RPKI objects, transfer resources), at least.
from this perspective, even maintainers (linked not only to SSO accounts; [1]) accounts are interesting asset. At least those linked to route/route6 and as-set objects. Deleting them can also cause a lot of operational damage, as filters are processed automatically according to IRR data at many places.
And the maintainers are tied directly to all objects, there's no link back to the LIR portal.
It's not only about RPKI-related objects. The problem is more complex from this point of view. Only the unwanted ROA modification pointed to it, but the same issue can occur with other kind of objects id DB.
Transfers are better protected I think, as there's always some manual intervention (and legal authorization).
- Daniel
[1] https://apps.db.ripe.net/docs/Authorisation/Using-the-Authorisation-Methods/
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg
On 4 Jan 2024, at 18:55, denis walker <ripedenis@gmail.com> wrote:
"Is it time to discuss redesigning (parts of) the RIPE Database?”
IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-) The first priorities should be to plug the security issue(s), secure the exposed LIR accounts and do an audit/impact analysis. Discussions about next steps can wait until these have been done. Those next steps may well include a redesign of the RIPE database. Though I think other things would need attention before that: revising the RIPE Access requirements, introducing 2FA, assessing the report about the latest breach, etc. It seems premature to debate changes to the database when it’s not yet clear what needs to be done. That may well be clear to you Denis. But perhaps your thoughts will need a reassessment in light of this security breach.
Hi, Denis is right, the problem isn't only RIPE access and I aggre DB needs to be redesigned in terms of security - we're talking not only about LIR portal and RPKI dashboard, which caused issue with Orange. If you break objects in DB in similar manner (as-sets, route objects), you'll cause similar outage - just because many upstreams and IXP use these data to build their prefix filters. Maybe the destruction will not be so fast... For some methods (restAPI) you need password linked to maintainer object. And all passwords here are still stored in MD5! Yes, this is year 2023. There's no other option [1]... All this is one big ticking bomb... I don't want to guess what could happen if the internal in case of internal RIPE database leak. Just because we're still storing some passwords in prehistoric way. It's not only about LIR accounts, risks are also hidden in maintainer objects, which can be used outside LIR portal. And it's out of reach of one working group. Trivialization of risks is highway to hell. And there're more things, which needs better protection - not only RPKI ROAs. - Daniel [1] https://apps.db.ripe.net/docs/Authorisation/Authorisation-Model/#solving-aut... On 1/4/24 21:24, Jim Reid wrote:
IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-)
The first priorities should be to plug the security issue(s), secure the exposed LIR accounts and do an audit/impact analysis. Discussions about next steps can wait until these have been done. Those next steps may well include a redesign of the RIPE database. Though I think other things would need attention before that: revising the RIPE Access requirements, introducing 2FA, assessing the report about the latest breach, etc.
It seems premature to debate changes to the database when it’s not yet clear what needs to be done. That may well be clear to you Denis. But perhaps your thoughts will need a reassessment in light of this security breach.
"Is it time to discuss redesigning (parts of) the RIPE Database?”
for some folk, it's always the same agenda
IMO, no. Your question is a bit like asking what colour the new carpets should be while the house is on fire. :-)
not even that. we need to lock the doors. and some security in depth. randy
participants (9)
-
Benedikt Neuffer -
Daniel Suchy -
denis walker -
Gert Doering -
Hank Nussbacher -
Jim Reid -
Nick Hilliard -
Randy Bush -
Tore Anderson