Hi Eve,
Thanks for the drawing. With regard to
analysis swimlane, I have a few questions.
(1)
How does the client obtain the issuer string to bootstrap? [attack surface 1] – there are real examples for this kind of attack being successful.
(2)
Has the DNS spoofing against the client for issuer combined with falsely issued certificate been considered? [attack surface 2] – there has
been a real attack like this.
(3)
What kind of agent a typical RqP using? If it is a browser, then browser infection to rewrite the request/response is possible. [attack surface
3] – this is a rather common attack.
It really depends on the answer, but unless there are specific considerations to block the surface, the answers to the questions “Can attacker inject
false claims interaction endpoint” and “Does attacker receive claims redirection URI” seem to be both YES to me.
Nat Sakimura
PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please
notify the sender and delete this e-mail.
From: WG-UMA [mailto:wg-uma-bounces@kantarainitiative.org]
On Behalf Of Eve Maler
Sent: Thursday, December 21, 2017 5:59 AM
To: wg-uma@kantarainitiative.org WG <wg-uma@kantarainitiative.org>
Subject: [WG-UMA] Trying to analyze "trust attacks"
In last week's WG call, we discussed the potential for a "mix-up attack" on UMA; please check out my new
analysis swimlane, where the conclusion so far is that this is not a viable attack.
We also started discussing a different sort of attack where a bad RS might be colluding with a bad AS-type service behind the back of the real AS. After doing a bunch of thinking and analysis of this situation and another
similar one, I'm starting to think of them -- not so much as security attacks -- but as "trust attacks". Let me describe them in turn, newest one first.
OAuth/UMA short-circuit attack
Here, the RS has received an access token during a client's resource request that has scopes (or in the case of UMA, permissions) directing it to give access only to extent X, but -- based on its out-of-band recognition
of the client (and/or the requesting party in the case of UMA) -- it decides to go ahead and give further access illegitimately to extent Y.
Mitigation would be in the realm of access auditing, implementation auditing, deployment auditing, trust establishment with the AS and AS/RO, and RS accreditation. Note that adding an endpoint at the AS to enable the
RS to report access given would be a self-reporting function.
Most known UMA ecosystem types to date are relatively "classic" on the server side and involve statically established "identity federation" style trust between the AS and RS (if the two aren't already colocated); this
means the RS has to get OAuth client credentials from the AS and probably agree to an associated contract. The RS then gets a PAT from the AS by authorization of the RO.
(I haven't seen this one discussed before, e.g. in existing threat docs. Has anyone else?)
This attack could be really effective, if Armageddon-y, and if the RS applied it in a very selective way, it's likely it could get away with it for a longer time. A perhaps
analogous example of what may have been "lower-level employees" (insiders) of multiple related companies getting away with price-fixing on a single product type for 14 years just came to light due to auditing.
I don't see anything worth adding to the specs that we haven't already said in our profiling and trust establishment sections. We could add this analysis to a new threat model document if we think it even counts as a
true security threat.
Evil federated authorization attack
Here, the evil RS has a properly formed trust relationship with the true AS, but it has a companion server-side attacker with which it colludes to achieve...I'm not sure what ends yet.
I can see two mechanisms of attack, as outlined below. I haven't yet made swimlanes for this, but perhaps I can do so before the call tomorrow.
Mechanism 1: Bad actors replace the discovery endpoints wholesale
Discussion: The uninvolved requesting-side entities will presumably get any access they request, and RO(good) and AS(good) are none the wiser. Also, AS(bad) got RqP(uninvolved)'s claims.
But RS(bad) has presumably violated its terms of service, which may eventually be discovered through auditing etc., and this seems like an awful lot of trouble to go to vs. the OAuth/UMA short-circuit attack above, since "random" recipients are being given
access to "random" resources rather than in a targeted fashion. In other words, the RS is partnering with another service at great cost and expense to be not just a bad guy but an overall jerk, vs. seeking out specific ways to get the resources out to desired
parties on the sly.
Mechanism 2: AS(bad) functions as a MITM proxying requests to AS(good)
Discussion: Again, it all starts with the RS's conveyance of the
as_uri value. If AS(bad) has to proxy requests to and responses from AS(good), at what point does it actually get to inject something or steal something? If it provides a
false rotated permission ticket, that will fail at the client's next request. It could provide a fake RPT, but it wouldn't work. It could provide a
need_info error that asks the client to push more claim information than needed. But since this type of information is most likely to be pre-negotiated a la SSO attributes,
it may not be understood (and we already have discussions of that and security and privacy considerations around it in the spec). Looking at the AS endpoint responses, I can't think of anything else damaging it could do.
Regarding this whole second "trust attack", even though it's not fully analyzed here, I can't help feeling so far that it's not something that warrants editing the specs further. I would very much welcome input from others.
Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl