
Peach App Token Reuse Flaw - wesleyhill
https://www.hakobaito.co.uk/b/peach-app-token-reuse-flaw/
======
narsil
While I agree that the tokens must be expired on logout, it's hard to gain
access to the token via MITM because the API requests are performed over TLS
[0]! This point seems glossed over in the post. You would need access to a
client app directly to be able to inspect its storage or sniff the traffic
yourself to determine the token being used.

Access to an unencrypted client device is usually game over for most apps'
data security anyway.

[0]
[https://www.ssllabs.com/ssltest/analyze.html?d=v1.peachapi.c...](https://www.ssllabs.com/ssltest/analyze.html?d=v1.peachapi.com&hideResults=on)

(OP: love the graphic design and appropriate color scheme!)

~~~
Alex3917
> While I agree that the tokens must be expired on logout

Is there really that much additional security over deleting tokens locally
when logging out, but expiring all existing tokens (using a timestamp) on
password change?

Blacklisting individual tokens requires storing them in the db and then
looking them up each time a user logs in. It seems like given the app already
uses TLS, the tiny security gain isn't big enough to justify the performance
impact.

~~~
dwightgunning
I agree although I think about it more in terms of development and maintenance
effort.

There's plenty of other relatively computationally and IO intensive activity
happening during login so I can't see an extra select having a tangible impact
to performance.

~~~
Alex3917
The issue isn't tokens getting created on login, it's them getting validated
on every request. That's already 40-50ms, even without the db hit each time.

------
ctomaybe
I get that non-expiring tokens are a Bad Idea™, but it's complete bullshit
that this is a groundbreaking security flaw. Any service that uses Bearer
tokens for request authorization is "vulnerable" under these terms --
regardless of whether or not tokens are invalidated on "logout." What's to say
a malicious MITM isn't going to hijack your account while you're still logged
in?

Secure infrastructure isn't the one and only solution, but it certainly means
that "vulnerabilities" like this are pointless unless your malicious attacker
either has the remote server certs or has cracked TLS.

------
nstj
So the article title could be changed to "Peach API has replay vulnerability"?

I haven't actually tried this yet but can someone confirm the app has pinning?
If so, thoughts on how he sniffed the original traffic and ran the replay?

~~~
jorge_leria
If you have a jailbroken iOS device you can use SSL Kill Switch [0] to disable
certificate pinning and get the traffic with MITMproxy [1] or Charles.

[0] [https://github.com/nabla-c0d3/ssl-kill-
switch2](https://github.com/nabla-c0d3/ssl-kill-switch2) [1]
[http://mitmproxy.org/](http://mitmproxy.org/)

------
lyime
Wesley, The readability of your blog is rather poor. You might want to change
the default width `font-size: 2vw;` to a fixed width (Use rem or em). Current
css settings are not user friendly and breaks the browser zoom.

Thanks.

~~~
Freak_NL
When the author of a website does this, there are a few tricks you can use in
modern browsers to help.

In Firefox _shift+ctrl+m_ launches a developer tool that allows you to resize
the viewport (for testing responsive designs) without having to resize your
browser.

Also available in Firefox (and even nicer) is the Reader View, which works on
this blog post. Its icon should be visible on the right hand side of the
address bar.

------
2-m3m3n70
So thoughts on an actual solution? Invalidating tokens means you have to
maintain an infinite growing list of invalidated tokens and perform a lookup
on every login - somewhat defeating the purpose of 'stateless' tokens like
JWTs (ie why not just implement a traditional session store then).

Furthermore, if sniping someone's token like this was doable over MITM, what's
to prevent someone from grabbing a live token and then infinitely refreshing
it (provided there's a /refresh endpoint).

I'm really wondering if anyone has best practices around this because I have
not seen anything.

~~~
Freak_NL
Good point. I wonder if it is sensible to limit the number of refreshes
permitted (by placing a counter in the JWT that gets decreased on every
refresh). That way you could have the JWT be valid for, say, 30 minutes, and
allow up to seven refreshes; after four hours you would have to re-
authenticate.

As for invalidating tokens; if tokens expire after a sensible interval (as
they should), than you would only have to maintain a short list of recently
issued and invalidated tokens. Older tokens can be removed from that list,
because they cannot be used in any case after expiring. You could use a cache
with a TTL set to a bit over the configured expiration interval.

~~~
BillinghamJ
The problem is that having a counter doesn't really work, because you can't
force the client to take the updated JWT. (And the previous JWT is still valid
as it's checked based on signature.)

The way to go is pretty simple - issue a long-term refresh token, and a very
short-term JWT to the client (as little as 5 mins or so). The app can then
make requests directly to the services, which can independently verify the
validity of the JWT.

The services then also check for tokens which have been revoked - using a very
fast mechanism, like holding them in-memory or querying a Redis store. The
token's JTI only needs to be held in the revocation list for a short period of
time - until the JWT expiry time - using a TTL in Redis, or similar.

The app uses the refresh token to get replacement JWTs. It goes with the
refresh token directly to the auth service, which can then check whether the
user should be able to get new tokens or not.

~~~
Freak_NL
When you use JWT with the option to refresh the tokens, you usually set an
expiry date on the token (if not, there is no point in refreshing at all). So
in order to stay authenticated, the client application has to refresh the
token a short while before it actually expires and use the new one (which has
an updated expiry date) or simply get signed off.

The previous token expires automatically — a well-designed back-end checks
against the expiry date and any other claims that should be verified, as well
as the signature. So you can force clients to accept the new token with a
counter that gets decremented at each refresh until you have to re-
authenticate.

There is no need for a separate long-term refresh token.

------
rurounijones
Complete aside: I tried changing the text size and the site dynamically
restored the text size to their preference.

Highly annoying!

~~~
daurnimator
Indeed! I can't even read it without resizing my browser window.

------
namuol
Am I misunderstanding something, or wouldn't this just be solved if they
simply used SSL for all communications?

~~~
wesleyhill
The official Peach app uses SSL and they also do certificate pinning in the
requests, that's not a problem. The problem is that Peach's server side
authorisation token does not expire when you 'log out' and you can reuse the
token.

The issue is mainly got to do with third party apps + this flaw in Peach's
API. There is already one[0] which has reversed the Peach API, and the flaw is
still present. What happens when another third-party Peach app comes out and
does not use SSL, you can still use Peach's API without SSL and it does not
default to HTTPS.

This sort of flaw would lead to a similar issue to the Snapsaved leak[1].

[0] [http://techcrunch.com/2016/01/14/peach-gets-an-unofficial-
we...](http://techcrunch.com/2016/01/14/peach-gets-an-unofficial-web-and-
android-version-called-nectarine/)

[1] [http://techcrunch.com/2014/10/13/snapsaved-takes-
responsibil...](http://techcrunch.com/2014/10/13/snapsaved-takes-
responsibility-for-latest-snapchat-leak/)

~~~
Freak_NL
Then a major factor in this vulnerability is that the API does not exclusively
use TLS to secure all communication. You might want to clarify that in the
blog post.

------
heraclez
What tool does one use to inspect requests?

~~~
xuki
Charles proxy is pretty good
[https://www.charlesproxy.com](https://www.charlesproxy.com)

~~~
heraclez
Fantastic. Is this the defacto tool? Can this be done without a tool?

~~~
balls187
On windows? Try fiddler:
[http://www.telerik.com/fiddler](http://www.telerik.com/fiddler)

~~~
mchahn
Fiddler works on all platforms. It is my proxy cap tool of choice.

~~~
balls187
Oh, very cool. Last I used it (just after Telerik acquired them), it was
Windows only.

