#OnFireHawk | Firefox Accounts

#OnFireHawk | Firefox Accounts

HawkAuth protocol is widely adopted by Firefox Accounts and appears in Postman in a very short list of supported API authentication methods which indicates HawkAuth is vastly more popular than you might first expect.

HawkAuth protocol history
The origins of HawkAuth appears to be with Eren Hammer then shortly sponsored by hapijs before being completely acquired by Mozilla in "maintenance mode" and renamed to just "hawk", which we will learn here that removing the "auth" from the name serendipitously accurate, as you only get Authentication optionally.

How is the HawkAuth protocol implemented?
The protocol is an adaptation of  IETF draft where the Hawk API is describe in this document.

There are many client and server side implementations that are disparate in their interpretations of the API.

Where is HawkAuth utilised?
There are several libraries that are available for projects to consume and implement Hawk Authentication:

What exactly is HTTP Holder-Of-Key Authentication?
Simply put; If you have an API (server) that you want to ensure the requester (client) is whom they claim to be and the request you received (payload) is not modified from what was sent (integrity), then you can pre-share a secret with the client to 'sign' the request which proves they have the secret without them exposing it or giving it back to you and you can only get this proof if the server verifies the request using the secret and payload too.

The literal definition of Authentication

Hawk does not do the server verification by default, therefore Hawk may never actually do any Authentication at all unless you very explicitly and far too onerously tell it too do the verification on purpose.

This is Hawk

Are there any fixes?
Watch this space

How does this effect Firefox Accounts?
FXA is where Authentication is handled for Firefox Accounts, the following list are the public endpoints that are easily observable by just running Firefox and observing where the Authentication is included:

  • /account/create
  • /account/login
  • /account/keys
  • /account/devices
  • /account/device
  • /account/device/destroy
  • /account/device/commands
  • /account/devices/invoke_command
  • /account/devices/notify
  • /account/status
  • /account/reset
  • /account/destroy
  • /recovery_email/status
  • /recovery_email/resend_code
  • /recovery_email/verify_code
  • /recovery_email/secondary/verify_code
  • /recovery_email/secondary/resend_code
  • /session/verify_code
  • /session/resend_code
  • /certificate/sign
  • /password/change/start
  • /password/change/finish
  • /password/forgot/send_code
  • /password/forgot/resend_code
  • /password/forgot/verify_code
  • /password/forgot/status
  • /account/lock
  • /account/unlock/resend_code
  • /account/unlock/verify_code
  • /account/attached_client/destroy
  • /session/destroy
  • /session/reauth
  • /session/duplicate
  • /account/sessions
  • /account/attached_clients
  • /session/status
  • /securityEvents
  • /account/profile
  • /account
  • /sms
  • /sms/status{country}
  • /recovery_emails
  • /recovery_email
  • /recovery_email/destroy
  • /recovery_email/set_primary
  • /account/login/send_unblock_code
  • /signinCodes/consume
  • /signinCodes
  • /totp/create
  • /totp/destroy
  • /totp/exists
  • /session/verify/totp
  • /recoveryCodes
  • /session/verify/recoveryCode
  • /recoveryKey
  • /recoveryKey/{recoveryKeyId}
  • /recoveryKey/exists
  • /introspect
  • /oauth/authorization
  • /oauth/token
  • /oauth/destroy
  • /account/scoped-key-data
  • /oauth/subscriptions/clients
  • /oauth/subscriptions/plans
  • /oauth/subscriptions/active
  • /oauth/subscriptions/updatePayment
  • /oauth/subscriptions/customer
  • /oauth/subscriptions/active/{subscriptionId}
  • /oauth/subscriptions/reactivate

There is also the FXA server side that has patched the risk by changing from default to the payload verification that will do the HTTP Holder-Of-Key Authentication (which is the one and only expected function of Hawk).

Finally, the FXA Payments Server is at risk and Mozilla claim it is "a significant vulnerability" but they ignored my significant updates for 6 months. Complete silence. Now 9 months with no input from Mozilla.

I refuse to publish the proof-of-concept, any specifics about how an attack can work, or be specific about the flaw. I only discuss there is a disputed vulnerability, sharing only public information.

If Mozilla read this, please contact me using Bugzilla 1719614