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

14 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 RawAuthenticationService.java , 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 'org.gluu.oxauth.crypto.signature.RawAuthenticationService.java': '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 Account Admin 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](https://ox.gluu.org/maven/org/gluu/oxauth-server/4.2.1.Final/oxauth-server-4.2.1.Final.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] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:80) - Startig authentication with username 'null', ke 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.oxauth.service.CookieService] (CookieService.java:156) - Found cookie: 'dc8ec1dd-3635-40e0-a7d2-a95dc6219194' 2021-04-15 06:31:39,562 DEBUG [qtp1671846437-17] [gluu.oxauth.session.ws.rs.CheckSessionStatusRestWebServiceImpl] (CheckSessionStatusRestWebServiceImpl.java:52) - Found ses 2021-04-15 06:31:39,562 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:37) - Request data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc62191 2021-04-15 06:31:39,563 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:39) - Loaded data, key 'oxId=dc8ec1dd-3635-40e0-a7d2-a95dc621919 2021-04-15 06:31:39,566 TRACE [qtp1671846437-17] [org.gluu.service.BaseCacheService] (BaseCacheService.java:84) - 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] (SessionIdService.java:821) - 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] (SessionIdService.java:823) - Session dn: oxId=dc8ec1dd-3635-40e0-a7d2-a95dc6219 2021-04-15 06:31:39,567 DEBUG [qtp1671846437-17] [gluu.oxauth.session.ws.rs.CheckSessionStatusRestWebServiceImpl] (CheckSessionStatusRestWebServiceImpl.java:68) - Check ses 2021-04-15 06:31:41,000 DEBUG [qtp1671846437-11] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:141) - Finishing authentication for username 'null' w 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [gluu.oxauth.service.fido.u2f.AuthenticationService] (AuthenticationService.java:161) - Client data HEX '65794a30655841694f 2021-04-15 06:31:41,056 DEBUG [qtp1671846437-11] [gluu.oxauth.service.fido.u2f.AuthenticationService] (AuthenticationService.java:162) - Signature data HEX '415145414141417 2021-04-15 06:31:41,071 ERROR [qtp1671846437-11] [oxauth.ws.rs.fido.u2f.U2fAuthenticationWS] (U2fAuthenticationWS.java:175) - Exception happened org.gluu.oxauth.model.fido.u2f.exception.BadInputException: Signature is not valid at org.gluu.oxauth.service.fido.u2f.RawAuthenticationService.checkSignature(RawAuthenticationService.java:66) ~[classes/:?] at org.gluu.oxauth.service.fido.u2f.AuthenticationService.finishAuthentication(AuthenticationService.java:167) ~[classes/:?] at org.gluu.oxauth.service.fido.u2f.AuthenticationService.finishAuthentication(AuthenticationService.java:135) ~[classes/:?] at org.gluu.oxauth.ws.rs.fido.u2f.U2fAuthenticationWS.finishAuthentication(U2fAuthenticationWS.java:157) ~[classes/:?] at org.gluu.oxauth.ws.rs.fido.u2f.U2fAuthenticationWS$Proxy$_$$_WeldClientProxy.finishAuthentication(Unknown Source) ~[classes/:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:543) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:432) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:393) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:395) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:364) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Fi at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138) ~[resteasy-jaxrs-3.13.0.Final.jar:3.13.0.Final] ... ``` Please can you review the patch fix again. Thanks. Regds, Jacob

By Mohib Zico staff 25 Apr 2021 at 9:58 a.m. CDT

Mohib Zico gravatar
**Status** Trying to reproduce the issue locally.

By Andrzej Lisowski named 26 May 2021 at 8:40 a.m. CDT

Andrzej Lisowski gravatar
Hello, could you let us know if you have reproduced the issue successfully? Do you want us to provide additional information? Regards, Andrzej

By Mohib Zico staff 26 May 2021 at 9:11 a.m. CDT

Mohib Zico gravatar
Hi Andrzej, Honestly speaking, I am having little difficulty to create the environment. How exactly you are facing this? I mean, - `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.` Question: Where are you getting 'public key' to push that manually in CB entry? Is it coming from old registered device?

By Jacob Verghese user 26 May 2021 at 2:05 p.m. CDT

Jacob Verghese gravatar
Hello Mohib, Maybe a little more background here might help you.  I originally had a Jmeter test user along with its Jmeter fido user device from a prior GLuu version(v3), in .ldif format. The user was imported into CB for Gluu4 testing. It was understood as part of u2f fido authentication, the challenge-response from Gluu is signed by the device using its private key and sent to gluu. The public key is then used by Gluu to sign the incoming payload along with the challenge Gluu for signature matching. However in my case, in my test, I was getting a strange exception with a bouncy castle as an Invalid point encoding (..org.bouncycastle.math.ec.ECCurve.decodePoint(ECCurve.java:441) )exception during the signature verification. I had limited information on the history of this particular Jmeter test user and unsure if the device key-pair used were matching in the first place. So I began a more exploratory process of just randomly testing different public key values of other development team test users' fido devices, who had since registered with gluu4 after the system was stood up. This was done by logging into couchbase and overwriting the device "publicKey" record for the Jmeter user fido record 'publicKey' value with another user's fido record publicKey value in CB. This actually did the trick. I even tried different public keys from 3 -4 different registered devices in Couchbase and using them Gluu was 'successfully' confirming the signature of the 'challenge token response' from Jmeter and I was able to complete the testing, when the signature verification should have failed.

By Mohib Zico staff 14 Oct 2021 at 1:16 p.m. CDT

Mohib Zico gravatar
Hi Jacob, I am extremely sorry late response! I believe we were able to reproduce something like that. With highest priority, I am re-engaging here now.

By Mohib Zico staff 18 Oct 2021 at 12:13 p.m. CDT

Mohib Zico gravatar
Hello again Jacob, I would like to share the scenario we used to test this situation: - Enroll user "foo" with his own key. - Enroll user "bar" with her own key. - Cracker will have to connect to internal LDAP and modify `oxDeviceRegistrationConf`. Replace "foo" user's `oxDeviceRegistrationConf` attribute with "bar" user's key. - In that way, "bar" can login ( 2nd factor ) [ still have to pass first username/password phase ] with user "foo" key. What do you think about above scenario?

By Mohib Zico staff 31 Oct 2021 at 9:13 p.m. CDT

Mohib Zico gravatar
Hi, Please reopen the ticket if required. Thanks!