4

In April 2022, GitHub suffered an attack involving stolen OAuth tokens:

Interestingly, GitHub OAuth tokens have a very long expiry -- they expire only if they haven't been used for one year. An alternative described in the OAuth spec is to use short-lived access tokens with long-lived refresh tokens. GitLab does this -- the access tokens expire after 2 hours and each refresh token may be used at most once.

Would a short access token expiry have prevented or mitigated the GitHub attack? Are refresh tokens as easy to steal? Are stolen refresh tokens as dangerous?

3
  • Short-lived access token would have reduced the timeframe available to the attacker to crawl private GitHub repositories that were accessible with the compromised tokens. The fact that the attacker did not steal the refresh token from Heroku could be because it is stored somewhere protected or Heroku was not storing it at all because of long expiry time of access token. The security of Oauth tokens is entirely on the client.
    – defalt
    Jul 13, 2022 at 11:38
  • How many times can a refresh token be used? According to the OAuth RFC "The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client" Jul 17, 2022 at 8:23
  • As many times as you want. It is up to the Identity Provider to revoke it on refresh. Keycloak doesn't do it.
    – defalt
    Jul 17, 2022 at 16:01

1 Answer 1

1

In principle, once an attacker obtains valid credentials there's little you can do to prevent illegal data access, most of which involve behaviour monitoring(1) and IP whitelisting(2). However, these solutions require extra effort to setup and maintain and, as such, may not be justified for publicly accessible systems with non-critical functionality.

Would a short access token expiry have prevented or mitigated the GitHub attack?

Credential expiration is used to narrow the window of opportunity of the attacker. So, if the attacker had obtained e.g. 10.000 account tokens, each of which had an expiration period of e.g. 2 hours, then the attacker would have to be very fast in using the tokens before they expired. Else the attacker would be able to abuse only as many tokens as (s)he manages, within the valid period. However, setting a shorter expiration time would not have prevented an attacker to abuse the token at will (within the time limits)

Are refresh tokens as easy to steal? Are stolen refresh tokens as dangerous?

It depends on the implementation; if the refresh token is stored alongside the access token, then it should be equally easy to steal as stealing the access token. Then, it can be used to maintain access to the target systems, just like using an access token with a very long expiration time. Some implementations replace the refresh token with each access token renewal, in order to render stolen tokens ineffective (i.e. the attacker would have to steal the tokens after each token replacement or, in case of session highjacking, the legit user can react when (s)he realizes any problem with the session). However, this too is not a countermeasure against the extend to which a token can be abused, but is used to narrow the window of opportunity as explained above.


(1) one method would be to build an access pattern baseline, that will be used to compare against each subsequent access, in order to estimate whether the latter is legit or not

(2) IP whitelisting would be used to only allow access to a system from specific boxes. So, in our case, github repositories would be accessed by specific heroku or travis ci boxes; thus, an attacker operating outside of those IP addresses would not be able to directly access the repos.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .