Subject: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Aug 2018 18:20:37 -0400

FYI,

https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf

Sent from my phone

Begin forwarded message:

> 
> https://www.bleepingcomputer.com/news/security/cisco-patches-its-operating-systems-against-new-ike-crypto-attack/
> 
> Cisco Patches Its Operating Systems Against New IKE Crypto Attack
> Catalin Cimpanu
> 
> 
> Cisco, one of the world's largest vendor of networking equipment, released security updates today to patch a vulnerability in the IOS and IOS XE operating systems that run the vast majority of its devices.
> 
> The vulnerability is tracked as CVE-2018-0131 and is one of four CVE identifiers for a new Bleichenbacher oracle cryptographic attack against the IKE (Internet  Key Exchange) protocol.
> 
> Patches address new cryptographic attack
> 
> This new attack is described is a recently published research paper entitled "The Dangers of Key Reuse: Practical Attacks on IPsec IKE," set to be presented at the 27th Usenix Security Symposium later this week in Baltimore, USA. From the paper's abstract:
> 
> In this paper, we show that reusing a key pair across different versions and modes of IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. We exploit a Bleichenbacher oracle in an IKEv1 mode, where RSA encrypted nonces are used for authentication. Using this exploit, we break these RSA encryption based modes, and in addition break RSA signature based authentication in both IKEv1 and IKEv2. Additionally, we describe an offline dictionary attack against the PSK (Pre-Shared Key) based IKE modes, thus covering all available authentication mechanisms of IKE.
> 
> Researchers say their attack works against the IKEv1 implementations of Cisco (CVE-2018-0131), Huawei (CVE-2017-17305), Clavister (CVE-2018-8753), and ZyXEL (CVE-2018-9129).
> 
> The research team, made up of three academics from the Ruhr-University Bochum, Germany and two from the University of Opole, Poland, say they notified vendors that had products vulnerable to this attack.
> 
> "All vendors published fixes or removed the particular authentication method from their devices’ firmwares in response to our reports," researchers said.
> 
> Cisco IOS and IOS XE affected, but not IOS XR
> 
> Cisco was by far the biggest vendor affected by this flaw, and the hardest hit. CVE-2018-0131 affects the company's main product, the IOS (Internetworking Operating System), and its Linux-based offshoot, IOS XE.
> 
> The IOS XR operating system, which runs on a different codebase and is used mainly for carrier-grade routers, is not affected.
> 
> Cisco released patches today for both OSes. The company says that any IOS and IOS XE device that's configured with the "authentication rsa-encr" option is vulnerable.
> 
> Attackers can recover VPN sessions
> 
> According to Cisco, this flaw "could allow an unauthenticated, remote attacker to obtain the encrypted nonces of an Internet Key Exchange Version 1 (IKEv1) session."
> 
> "The vulnerability exists because the affected software responds incorrectly to decryption failures. An attacker could exploit this vulnerability sending crafted ciphertexts to a device configured with IKEv1 that uses RSA-encrypted nonces," Cisco said in a security advisory.
> 
> An attacker that has the ability to recover IKEv1 nonces can recover data sent via IPsec, the protocol at the base of most VPN traffic. With this in mind, applying the Cisco patches is highly recommended.
> 
> Related Articles:
> 
> Get 66% off ProtonVPN Plus Subscriptions Deal
> 
> DNS Leak Fixed in Kaspersky VPN App for Android
> 
> Study: Law Enforcement Need Technical Skills, Not Backdoors
> 
> DOD to Move All Websites to HTTPS by the End of the Year
> 
> Many Bluetooth Implementations and OS Drivers Affected by Crypto Bug
> 
> 
> 
> Sent from my phone
> _______________________________________________
> Security mailing list
> [email-masked]
> https://lists.libreswan.org/mailman/listinfo/security

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Aug 2018 11:13:16 +0300

Hi,

after reading the paper I still don’t understand why authors mentioned IKEv2 there.

Their example attack in Section 4.4 on (allegedly) IKEv2 in fact uses secondary responder 

supporting IKEv1 Public Key Encryption mode, without which the attack is impossible (as far as 

I understand). So, in my opinion, the authors are at least not accurate in claiming

that IKEv2 itself is susceptible. Or am I missing something?

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Paul Wouters
Sent: Tuesday, August 14, 2018 1:21 AM
To: [email-masked]
Subject: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems Against New IKE Crypto Attack

FYI,

Sent from my phone

Begin forwarded message:

 <https://www.bleepingcomputer.com/author/catalin-cimpanu/> Catalin Cimpanu

 Cisco logo <https://www.bleepstatic.com/content/hl-images/2018/02/08/Cisco-logo.jpg> 

The vulnerability is tracked as CVE-2018-0131 and is one of four CVE identifiers for a new Bleichenbacher oracle cryptographic attack against the  <https://en.wikipedia.org/wiki/Internet_Key_Exchange> IKE (Internet  Key Exchange) protocol.

This new attack is described is a recently published research paper entitled " <https://www.ei.rub.de/media/nds/veroeffentlichungen/2018/08/13/sec18-felsch.pdf> The Dangers of Key Reuse: Practical Attacks on IPsec IKE," set to be presented at the 27th Usenix Security Symposium later this week in Baltimore, USA. From the paper's abstract:

"The vulnerability exists because the affected software responds incorrectly to decryption failures. An attacker could exploit this vulnerability sending crafted ciphertexts to a device configured with IKEv1 that uses RSA-encrypted nonces," Cisco said in a  <https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180813-rsa-nonce> security advisory.

An attacker that has the ability to recover IKEv1 nonces can recover data sent via  <https://en.wikipedia.org/wiki/IPsec> IPsec, the protocol at the base of most VPN traffic. With this in mind, applying the Cisco patches is highly recommended.

Related Articles:

 <https://www.bleepingcomputer.com/offer/deals/get-66-percent-off-protonvpn-plus-subscriptions-deal/> Get 66% off ProtonVPN Plus Subscriptions Deal

 <https://www.bleepingcomputer.com/news/security/dns-leak-fixed-in-kaspersky-vpn-app-for-android/> DNS Leak Fixed in Kaspersky VPN App for Android

 <https://www.bleepingcomputer.com/news/government/study-law-enforcement-need-technical-skills-not-backdoors/> Study: Law Enforcement Need Technical Skills, Not Backdoors

 <https://www.bleepingcomputer.com/news/government/dod-to-move-all-websites-to-https-by-the-end-of-the-year/> DOD to Move All Websites to HTTPS by the End of the Year

 <https://www.bleepingcomputer.com/news/security/many-bluetooth-implementations-and-os-drivers-affected-by-crypto-bug/> Many Bluetooth Implementations and OS Drivers Affected by Crypto Bug

Sent from my phone

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Aug 2018 10:48:13 -0400 (EDT)

> that IKEv2 itself is susceptible. Or am I missing something?

I agree. I got limited information before publication (only about the
weak PSK parts, not the RSA parts) and also voiced concerns about their
IKEv2 claims.

While in IKEv1 you have an oracle when the message can be decrypted only
with the right PSK, in IKEv2 there is no such oracle, and you can only
do this online and check for a response or failure on sending a packet.

For the RSA case, it does depend on (Revised or not) Public Key Encryption
mode instead of (RSA or ECDSA) Digital Signatures and the authors do
state that IKEv2 is only 'vulnerable' if the RSA key is shared between
IKEv1 and IKEv2.

They also do some number games about how many packets you need to send
and how fast, and I found their description confusing. I think they
change SPI (cookies) and so these would be "new" exchanges so this has
to be the DH component, but even if you break DH in IKEv2, you haven't
broken the AUTH payload (or done anything to determine the PSK?).
And we all have rate-limits in place so getting even 50,000 packets
(and thus 50,000 half-open SA's) tested before a connection is aborted
is not really feasable (although I guess it was for the vendors mentioned?)

And finally, this is all about RSA v1.5 and does not work with RSA-PSS
which is used when using RFC 7427 ?

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 14 Aug 2018 15:07:45 +0000

> -----Original Message-----
> From: IPsec <[email-masked]> On Behalf Of Paul Wouters
> Sent: Tuesday, August 14, 2018 10:48 AM
> To: Valery Smyslov <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [IPsec] Fwd: [Security] Cisco Patches Its Operating Systems
> Against New IKE Crypto Attack
> 
> I agree. I got limited information before publication (only about the weak PSK
> parts, not the RSA parts) and also voiced concerns about their
> IKEv2 claims.

Their argument is 'if you use the same RSA key for IKEv1 PKE authentication, *and* IKEv2 authentication, then you can use the Bleichenbacher Oracle within IKEv1 to attack a current IKEv2 exchange' (see section 4.4 of the paper).

> with the right PSK, in IKEv2 there is no such oracle, and you can only do this
> online and check for a response or failure on sending a packet.
> 
> mode instead of (RSA or ECDSA) Digital Signatures and the authors do state
> that IKEv2 is only 'vulnerable' if the RSA key is shared between
> IKEv1 and IKEv2.
> 
> They also do some number games about how many packets you need to
> send and how fast, and I found their description confusing. I think they
> change SPI (cookies) and so these would be "new" exchanges so this has to
> be the DH component, but even if you break DH in IKEv2,you haven't broken
> the AUTH payload

This is not a MITM attack, this is an impersonation attack.

> (or done anything to determine the PSK?).

Actually, the Bleichenbacher part of the paper is addressing signature authentication (certificates). 

They do mention an off-line dictionary attack against PSK's, however that's just a cite of previous work.

> And we all have rate-limits in place so getting even 50,000 packets (and thus
> 50,000 half-open SA's) tested before a connection is aborted is not really
> feasable (although I guess it was for the vendors mentioned?)

If the IKEv1 exchanges error out, and hence are closed, they wouldn’t count as half-open; that would make the attack more feasible.  I don't know how real IKEv1 implementations deal with it...

> 
> And finally, this is all about RSA v1.5 and does not work with RSA-PSS which is
> used when using RFC 7427 ?

Actually, going to an alternate RSA signature method doesn't protect you; it's the public key encryption in IKEv1 that is what's critical for the attack (and that you use the same RSA keys for both).

> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Aug 2018 11:33:23 -0400 (EDT)

> This is not a MITM attack, this is an impersonation attack.

If it is not a MITM, then the original connection will establish. If
they then send packets with non-matching SPI's, the packets would simply
be dropped or receive an INVALID_(_IKE_)SPI answer which would not give
them any kind of oracle at all ? If they use the same IKE SPIs then
what would they be attacking? They cannot send IKE_AUTH (or non-Quick
Mode) packets? I mean they can, but any sane state machine will just
drop them or send them an error that is completely independent of the
content of their packet other then the Exchange Type. So I don't
understand how they can learn anything from that.

> If the IKEv1 exchanges error out, and hence are closed, they wouldn’t count as half-open; that would make the attack more feasible.  I don't know how real IKEv1 implementations deal with it...

On the first packet sure, but not on a subsequent packet. That is why I
find the paper confusing. Messing up SPI's shouldn't get you anything
meaningful. It seems to conflate injecting the DH exchange and injecting
after the DH exchange?

> Actually, going to an alternate RSA signature method doesn't protect you; it's the public key encryption in IKEv1 that is what's critical for the attack (and that you use the same RSA keys for both…

Yes, but everyone already knew now to use the same keypair for different
(v1.5 vs PSS) encryption types.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Aug 2018 18:35:28 +0300

Hi Scott,

> Their argument is 'if you use the same RSA key for IKEv1 PKE authentication, *and* IKEv2 authentication, then
> you can use the Bleichenbacher Oracle within IKEv1 to attack a current IKEv2 exchange' (see section 4.4 of the
> paper).

So, this is not an attack against IKEv2 per se. Without running IKEv1 code with enabled (R)PKE the attack is impossible.
So in my opinion the authors are not accurate claiming that this is attack against IKEv2 - after breaking RSA
with  Bleichenbacher Oracle in IKEv1 PKE mode they can use the results against *any* protocol that reuses 
broken key, can't they? Is there any weakness in IKEv2 as a protocol except that its RSA key is usually the same as in IKEv1?
I believe the authors didn't demonstrate such a weakness...

Regards,
Valery.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 14 Aug 2018 15:43:40 +0000

> From: Paul Wouters <[email-masked]>
> Sent: Tuesday, August 14, 2018 11:33 AM
> To: Scott Fluhrer (sfluhrer) <[email-masked]>
> Cc: Valery Smyslov <[email-masked]>; [email-masked]
> >> send and how fast, and I found their description confusing. I think
> >> they change SPI (cookies) and so these would be "new" exchanges so
> >> this has to be the DH component, but even if you break DH in
> >> IKEv2,you haven't broken the AUTH payload
> >
> If it is not a MITM, then the original connection will establish.

What original connection?  Mallet (the attacker) claims to be Alice (a valid node), and initiates to Bob.  When Mallet needs to include Alice's signature in the exchange, he performs a Bleitchenbacher attack against the real Alice, to compute what the signature needs to be.  Then, Mallet uses that signature to fool Bob into thinking he is talking to Alice.  Since Alice never had any idea she was supposed to be talking to Bob, she'll never send any packets his way...

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Aug 2018 11:55:40 -0400 (EDT)

> What original connection?  Mallet (the attacker) claims to be Alice (a valid node), and initiates to Bob.  When Mallet needs to include Alice's signature in the exchange, he performs a Bleitchenbac…

How does Mallet get both Bob and Alice to use the same IKE SPI's ?

AUTH is computed over:

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
    RealIKEHDR =  SPIi | SPIr |  . . . | Length
    RealMessage1 = RealIKEHDR | RestOfMessage1
    NonceRPayload = PayloadHeader | NonceRData
    InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
    RestOfInitIDPayload = IDType | RESERVED | InitIDData
    MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

Note it contains SPIi and SPIr.

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 14 Aug 2018 17:30:56 +0000

> Sent: Tuesday, August 14, 2018 11:56 AM
> Cc: [email-masked]; Valery Smyslov <[email-masked]>
> > What original connection?  Mallet (the attacker) claims to be Alice (a valid
> node), and initiates to Bob.  When Mallet needs to include Alice's signature in
> the exchange, he performs a Bleitchenbacher attack against the real Alice, to
> compute what the signature needs to be.  Then, Mallet uses that signature
> to fool Bob into thinking he is talking to Alice.  Since Alice never had any idea
> she was supposed to be talking to Bob, she'll never send any packets his
> way...
> 

One of us is missing something.

I believe that the attack under discussion was one where the attacker initiates the exchange with Bob, and follows the protocol faithfully with Bob (except where he gets the signature from).  He needs to get the signature of the above InitiatorSignedOctets; he knows what the string 'InitiatorSignedOctets' is; the only thing he can't do easily is generating that signature.

He doesn't try to fool Alice into generating that signature directly; as you point out, that would be difficult.  Instead, what Bleichenbacher's attack does is allow him to compute what the signature would be, given an Oracle that will tell him whether a specific ciphertext will decrypt into a valid PKCS #1 padded plaintext (and making a large number of queries to the Oracle).  That is what he uses the connection with Alice for, to act as that Oracle.  It doesn't matter what SPI's he and Alice is using; the only thing he cares about in the Alice exchanges is whether certain carefully crafted RSA ciphertexts decrypt to plausible RSA plaintexts, or generate errors during decryption.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Aug 2018 21:16:38 +0300

> after reading the paper I still don’t understand why authors

Of course they mention, just to get more exposure...

> Their example attack in Section 4.4 on (allegedly) IKEv2 in fact
> uses secondary responder supporting IKEv1 Public Key Encryption
> mode, without which the attack is impossible (as far as I
> understand). So, in my opinion, the authors are at least not
> accurate in claiming that IKEv2 itself is susceptible. Or am I
> missing something?

That is my understanding also.

On the other hand breaking signature method of the IKEv2 using IKEv1
oracle for the same RSA key is quite clever, and just points out that
we must not use same key pair with different protocols / modes etc.

We had this dicussion in when writing RFC8247 and recommending RFC7427
Digital Signatures using RSASSA-PSS. Some implementors used same key
pair for both RSASSA-PKCS1-v1_5 and RSASSA-PSS. This paper just points
you that you must not do that kind of things.

The text about the IKEv2 pre-shared keys is just already known fact,
and the RFC7296 warns about that several times, i.e., it does say use
EAP for those, and for EAP you should not use the weak EAP methods,
but instead you should use key generating methods. Also because it is
known fact that IKEv2 shared secret authentication is vulnerable to
the off-line dictionary attacks, we created RFC6467 for secure
password methods. I.e., PACE (RFC6631), AugPAKE (RFC6628), abd Secure
PSK Authentication (RFC6617) should all be protected against offline
dictionary attacks.

Anyways, I think proper fix would be to disable IKEv1 support
completely, not to just disable RSA encryption mode...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Aug 2018 21:39:50 +0300

> do this online and check for a response or failure on sending a packet.

Not true.

In IKEv2 you can do active attack to do offline dictionary attack.
When Alice is trying to connect Bob, the Mallery will take those
packets and respond to them, without forwarding anything to Bob. When
Alice will send her IKE_AUTH payload, you can decrypt it as you were
party in the IKE_SA_INIT, i.e., you know the Diffie-Hellman secrets.
Then you simply calculate the InitiatorSignedOctets (you know
everything needed there), and do

for every "Shared Secret" in dictionary
  calculate prf( prf(Shared Secret, "Key Pad for IKEv2"),
                       <InitiatorSignedOctets>)
  if that matches the AUTH payload Alice send you know the Shared Secret

You can do that offline without any problems. That is why RFC7296 says
the Shared Secret needs to be secure, deriving it from weak password
etc is not secure (this is mentioned several times in RFC7296).

Because this is known fact we did create Secure Password Framework
RFC6467 to allow us to make secure password methods for IKEv2. From
the Introduction:

   The IPsecME working group was chartered to provide for IKEv2
   ([RFC5996]) a symmetric secure password authentication protocol that
   supports the use of low-entropy shared secrets, and to protect
   against off-line dictionary attacks without requiring the use of
   certificates or the Extensible Authentication Protocol (EAP).
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Aug 2018 14:50:47 -0400 (EDT)

On Tue, 14 Aug 2018, Tero Kivinen wrote:

> You can do that offline without any problems.

Ah yes, thanks.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Aug 2018 15:26:06 -0400

Valery Smyslov <[email-masked]> wrote:
    > So, this is not an attack against IKEv2 per se. Without running IKEv1
    > code with enabled (R)PKE the attack is impossible.  So in my opinion
    > the authors are not accurate claiming that this is attack against IKEv2

Agreed.
They use IKEv1 RPKE to generate signatures, and then use them.

We use the same keys for IKEv1 and IKEv2 because we want to transition
to IKEv2 in as seamless a way as possible.   Clearly, we could recommend
replacing keys when a node has only IKEv2 neighbours, but at that point,
we can turn off IKEv1 anyway, and the attack isn't possible anymore.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Aug 2018 15:26:59 -0400

> completely, not to just disable RSA encryption mode...

+1

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 14 Aug 2018 15:28:37 -0400

Why aren't these IKEv1 implementation defending against Bleichenbacher by
hiding the nature of error (decryption error or authentication error) like
what TLS 1.2 does [1]? Is this option documented in any of the IPsec/IKE
documents? Is there a reason why it would not work in IKEv1 as it worked
for TLS?

[1] RFC 5246 Sec 7.4.7.1

Hugo

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Aug 2018 23:37:05 +0300

Hugo Krawczyk writes:
> documents? Is there a reason why it would not work in IKEv1 as it worked for
> TLS?

Mostly as those implementations are old, and have not been touched in
last 15 years. IKEv2 obsoleted IKEv1 in 2005, and instead of removing
IKEv1 most of the vendors just put IKEv1 on "low maintenance mode",
meaning they will fix fatal bugs (crashes etc) but will not do any
real development for it.

Also when this was big news in TLS few years back, where this "19 year
old bug" [1] hits servers again, IKEv2 had already moved on. We had
RFC 7427 [2] which allows using RSASSA-PSS and RFC8247 [3] which said
RSASSA-PKCS1-v1.5 is no longer recommended.

I think there was discussion about this attack in IPsec list 15-20
years ago, but could not find the discussion from my archives now.

The IKEv1 uses RSA encryption to encrypt few specific payloads on the
exchange, and there is no text in RFC2409 or other places to tell what
should you do if the encryption fails, but yes similar thing than what
was done for TLS could be done for IKEv1, except IKEv1 is obsoleted,
and there is no point of fix issues in obsoleted protocol (I do not
think we provide fixes for SSL 3.0 anymore either).

I think there is no point of beating the dead horse anymore. I think
we should really have the
draft-ietf-ipsecme-ikev1-die-die-die-die-die-die-die-die-die-die-die-die-die-00.txt...

[1] https://robotattack.org/
[2] https://datatracker.ietf.org/doc/rfc7427/
[3] https://datatracker.ietf.org/doc/rfc8247/
-- 
[email-masked]