By: Will Cayo Account Admin 01 Apr 2021 at 1:20 p.m. CDT

7 Responses
Will Cayo gravatar
Hello Gluu Support, Recently in the midst of testing authentication use case flow (via Jmeter) of fido devices against the Gluu oxauth with fido2 authentication, we noticed a security behavior that allowed any valid PublicKey created with previously registered fido devices to work regardless, if the Public key was associated or not with that device in the first place. So long as the PublicKey was able to be decoded successfully by the bouncyCastle's 'decodePublicKey()' the 'org.gluu.oxauth.crypto.signature.checkSignature()' calling method, in the , always 'verified' the signature as 'success' of the u2f authentication challenge JSON response. For example, the following are the different public keys which I updated manually in the Couchbase in the fido device Document JSON record in the 'gluu_user' bucket. "publicKey": "BKCANcBmaS-CH0SA_NLYduw_ANxbVZE4p5zUCSBE-CyAdH1K1A0z09YbBSlRuBPdtH1nMgknltEBkqBsy-uV4GI" "publicKey": "BB-XcZTAqeW7rIUZuS-uNemkqLkLNBtra-Bn_bB65xfmApEU3tl59UENKrZrAYU5ijtdU_u82Dt3a1S2R_PSQkk" "publicKey": "BP0LKzUqsWkilGwZt5Pn7LspsiLYEEyG6Fxt4awlrkpNli1DbgfAPZOWpWX5DsfdqSTjLcPJzDONPSm67MifsGM" The same private-key was then used to sign on the Challenge-response of the u2f authentication endpoint /restv1/fido/u2f/authentication, and the created 'tokenResponse' parameter POSTed back to the /oxauth/restv1/fido/u2f/authentication endpoint. The Response back from gluu was always a Success. Example: {"status":"success","challenge":"B....kf0"} We think the issue is in line#64 of '': 'signatureVerification.checkSignature(signatureVerification.decodePublicKey(publicKey), signedBytes, rawAuthenticateResponse.getSignature());' Here the signatureVerification.checkSignature() method returns a boolean to indicate that the signature is a Valid signature. However the return boolean condition is never evaluated by the calling method, but only and only encloses it with a try-catch{..} block. I suppose the expectation may have been that a failed signature will always throw an error, which may or may-not be the case. This we think is why the various PublicKeys passed the signature verification and with no signature failed validation response. We thought it important for you to verify and look into the logic. Regds, Jacob

By Michael Schwartz staff 01 Apr 2021 at 2:07 p.m. CDT

Michael Schwartz gravatar
Very good feedback. We will look into this asap.

By Yuriy Movchan staff 01 Apr 2021 at 2:55 p.m. CDT

Yuriy Movchan gravatar
Hi Jacob, Thank you about research. Yep I think you find right place with root case. I've applied patch to 4.2.1 and rebuild it. Can you try to deploy new [oxauth.war]( from our maven repo? Let me know if this fixed issue. Regards, Yuriy

By Jacob Verghese user 02 Apr 2021 at 1:55 p.m. CDT

Jacob Verghese gravatar
Thank you for your fast response. Our deployment is on EKS, any chance we can get a container image for the fix? Regds, Jacob

By Mohib Zico staff 12 Apr 2021 at 9:02 a.m. CDT

Mohib Zico gravatar
@Mohammad.Abudayyeh: What do you think on last comment?

By Jacob Verghese user 12 Apr 2021 at 9:19 a.m. CDT

Jacob Verghese gravatar
HI. We would not be able to test this out via the oxauth.war, since all our gluu stack deployment is step up on EKS. Restarting oxauth on EKS will cause the old oxauth.war to be pulled in again. Would you be able to get a container image for the fix? Thx. ~Jacob

By Mohammad Abudayyeh staff 12 Apr 2021 at 9:30 a.m. CDT

Mohammad Abudayyeh gravatar
Hey, Jacob please use image tag `4.2.3_dev` which contains the latest with the above fix. Once you confirm a new official image will be pushed out.

By Jacob Verghese user 15 Apr 2021 at 9:26 a.m. CDT

Jacob Verghese gravatar
Hello Gluu-Support, Thanks for the patch fix. Unfortunately in our local testing, the authentication does not seem to work at all now. It fails for even a case of valid signatures using correct private, public key pair. This fails were noticed in the local Jmeter testing, and we tested it out on valid mobile devices in dev environment which had been enrolled with u2f signatures. These devices are now failing u2f authentication signatures with the following error. ``` ... 2021-04-15 06:31:39,556 DEBUG [qtp1671846437-18] [] ( - Startig authentication with username 'null', ke 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.CookieService] ( - Found cookie: 'dc8ec1dd-3635-40e0-a7d2-a95dc6219194' 2021-04-15 06:31:39,562 DEBUG [qtp1671846437-17] [] ( - Found ses 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] ( - Request data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc62191 2021-04-15 06:31:39,563 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] ( - Loaded data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc621919 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] ( - Put data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc6219194,o 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.SessionIdService] ( - Try to get session by id: dc8ec1dd-3635-40e0-a7d2- 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.SessionIdService] ( - Session dn: oxId=dc8ec1dd-3635-40e0-a7d2-a95dc6219 2021-04-15 06:31:39,567 DEBUG [qtp1671846437-17] [] ( - Check ses 2021-04-15 06:31:41,000 DEBUG [qtp1671846437-11] [] ( - Finishing authentication for username 'null' w 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [] ( - Client data HEX '65794a30655841694f 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [] ( - Signature data HEX '415145414141417 2021-04-15 06:31:41,071 ERROR [qtp1671846437-11] [] ( - Exception happened Signature is not valid at ~[classes/:?] at ~[classes/:?] at ~[classes/:?] at ~[classes/:?] at$Proxy$_$$_WeldClientProxy.finishAuthentication(Unknown Source) ~[classes/:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke( ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke( ~[?:?] at java.lang.reflect.Method.invoke( ~[?:?] at org.jboss.resteasy.core.MethodInjectorImpl.invoke( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.SynchronousDispatcher.preprocess( ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] ... ``` Please can you review the patch fix again. Thanks. Regds, Jacob