Asus firmware IKEv2 VPN security issue

[galapogos01]

Hi guys,

I was setting up an IKEv2 VPN on my Asus AX86S with stock firmware and I noticed in the official guide the step to disable Extended Key Usage (EKU) checks on the client.
Without doing this, Windows will not connect to the VPN server.

Per the Strongswan documentation,

This is potentially dangerous, as any certificate holder assured by your CA may act as the VPN gateway.

Is anyone else aware of this issue? Does Merlin fix it? Why can't Asus set the EKU flags correctly?

Thanks,
Jason

 

[rung]

This is potentially dangerous, as any certificate holder assured by your CA may act as the VPN gateway.

I don't see how this could possibly be a risk since the router creates both the ca and the server certs.

 

[galapogos01]

It's a risk because making a connection requires that the client has a setting applied that will allow any other certs issued to act as the router. This applies not just to the connection, but to all VPN connections.

There are multiple guides online suggesting this is simply poor configuration of the server cert generation, eg: https://docs.netgate.com/pfsense/en...e-ikev2-client-windows.html#disable-eku-check

When the CA and server certificates are made properly this is not necessary. Ifan improperly generated server certificate must be used, then the Extended KeyUsage check may need to be disabled on Windows.

Warning
Disabling this check also disables validation of the certificate common name and SAN fields, so it is potentially dangerous. Any certificate from the same CA could be used for the server when this is disabled, so proceed with caution.

 

[rung]

Those "other certs" have to be signed by the CA to be an issue. In this case, your router solely holds those CA signing keys.

 

[galapogos01]

I understand what you're saying, but I think you're missing my point.

I have VPN connections configured to many other VPN servers. By forcing this setting on the client, Asus is potentially compromising all other VPN connections my client makes. This is a global setting not per connection.

 

[rung]

Sorry, I did not follow until now. In those cases, it still would require a server cert signed by a ca you already trust in addition to the dns poisoning to redirect you to their special server that would accept the user authentication challenge words during the next phase. Would be interesting to see if that would go undetected by your client.

I do find it interesting that android built-in client doesn't require special changes to the config to work.

 

[rung]

Btw, just checked. My server cert lists my ddns address name both in cert Subject field and the X509v3 Subject Alternative Name field. At least one of those fields has to be verified by the client to match the address I put in the client config. I still can't see the risk from the lack of a key usage field even if not used globally.

 

[rung]

So I've come full circle and agree that this should be fixed by Asus since the change is extremely simple. You could fix this yourself too. The issue is in this Asus script:

/jffs/ca_files/generate.sh

There is a line that generates the server cert:

pki --pub --in /jffs/ca_files/svrKey.pem | pki --issue --cacert /jffs/ca_files/asusCert.pem --cakey /jffs/ca_files/ca.pem --dn "C=TW,O=ASUS,CN=XXXXXX.asuscomm.com" --san="XXXXXX.asuscomm.com" --lifetime 2200 --outform pem > /jffs/ca_files/svrCert.pem

Per the Strongswan documentaion here:
Strongswan Doc

They just have to add one flag:

Some third party VPN clients require that a VPN gateway certificate contains the TLS Server Authentication Extended Key Usage (EKU) flag which can be included with the following option
--flag serverAuth

I tested it and was able to regenerate my server cert with this flag set.