Re: [Dime] Benjamin Kaduk's Discuss on draft-ietf-dime-rfc4006bis-08: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

> On May 24, 2018, at 8:16 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> [trimming some quoted material]
> On Thu, May 24, 2018 at 08:01:04AM -0500, Spencer Dawkins at IETF wrote:
>> Keeping in mind that this is Benjamin's ballot thread, so what he thinks
>> matters more than what I think ...
>> 
>> On Thu, May 24, 2018 at 1:20 AM Yuval Lifshitz <yuvalif=
>> [e-mail]> wrote:
>> 
>>> *inline*
>>> 
>>> On Wednesday, May 23, 2018, 4:58:32 p.m. GMT+3, Benjamin Kaduk <
>>> [e-mail]> wrote:
>>> 
>>> 
>>> On Wed, May 23, 2018 at 08:31:51AM +0000, Yuval Lifshitz wrote:
>>>>   On Wednesday, May 23, 2018, 6:32:47 a.m. GMT+3, Ben Campbell <
>>> [e-mail]> wrote:
>>>> 
>>>> 
>>>>> On May 22, 2018, at 8:48 AM, Benjamin Kaduk <[e-mail]> wrote:
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> DISCUSS:
>>>>> ----------------------------------------------------------------------
>>>>> 
>>>>> With the redirection schemes covered in Section 5.6.2, it sounds
>>>>> like the user can be redirected (at the application protocol level,
>>>>> e.g., HTTP or SIP) to a top-up server to purchase more credits.  I
>>>>> don't see a way described how user agents can distinguish between a
>>>>> Diameter-induced redirect and an attacker-induced redirect to a
>>>>> (potentially phishing) site that accepts payment information.  To be
>>>>> clear, the scenario here is that a user is using a credit-controlled
>>>>> application session to talk to "arbitrary application servers",
>>>>> including potentially attacker-controllled HTTP/SIP/etc. servers;
>>>>> the attacker could introduce a redirect to a phishing page that asks
>>>>> for payment information, and the user would be led to believe that
>>>>> this was the normal flow for "my prepaid balance has been used up",
>>>>> and give their payment information to the phishing site. I think
>>>>> that either user agents need to give some indication that this
>>>>> DIAMETER-level redirect is different than an
>>>>> application-protocol-level redirect (e.g., http) or the Security
>>>>> Considerations need to mention the risk of acclimating users to
>>>>> arbitrary websites redirecting to sites asking for payment
>>>>> credentials, which may or may not be legitimate sites.
>>>>> 
>>>> 
>>>> I think it’s reasonable to mention the concern in the security
>>> considerations. But I don’t see how a redirection based on this
>>> specification is any different than any other time an HTTP browser or SIP
>>> UA connects to a resource based on an arbitrary URL.
>>> 
>>> In some sense, it's not.  My claim is more that users are being
>>> conditioned to expect payment prompts to appear at "arbitrary times"
>>> than a specific flaw in this workflow.
>>> 
>>> 
>>>> But to put some more context around this, the Diameter client is
>>> typically a Network Access Server (NAS) that the end user is using for
>>> network access. The user is already at the mercy of that NAS, and that NAS
>>> is at the mercy of the credit-control application server. The user’s trust
>>> in that NAS seems to have the same issues whether or not this Diameter
>>> application is used.
>>>> 
>>>> [yuval] agree with Ben, if someone bad took control over the NAS, they
>>> can do much worse
>>> 
>>> I agree that the NAS could send traffic to "wherever", but my
>>> objection could perhaps be categorized as more "social" than
>>> "technical".  Maybe I should attempt to give an example (and you can
>>> point out if I misunderstand things).
>>> 
>>> I believe that a "normal usage" of this technology could be for a
>>> user with a prepaid data plan to be using a web browser, and, e.g.,
>>> connect successfully to https://example.com. Suppose that this
>>> request used up their last remaining credits, and they click on a
>>> link from that page.  Instead of going to the actual target of that
>>> link, they are redirected to the data plan owner's top-up page,
>>> which displays a message "your balance is zero; please enter credit
>>> card information to purchase more data", the user pays, and can
>>> potentially even be redirected back to the actual target of the link
>>> they clicked on (though that's not key to my example).  Let's
>>> consider what would happen in an "attack scenario", where the same
>>> user has plenty of data quota remaining, and goes to
>>> https://honest-achmed.com. They click on a link from that page,
>>> which instead of going to an "actual site" that would be expected
>>> from the context surrounding the link, actually goes to
>>> http://[IP address controlled by attacker]/topup.html, which is
>>> designed to look as similar as possible to the actual data plan
>>> owner's top-up page.  The user may then enter their payment
>>> information, and get redirected to a site with actual content,
>>> believing that they have obtained more data quota from their
>>> provider, when in reality they have given their credit card
>>> information to a phisher.
>>> 
>>> I don't see what mechanism is in place to allow the user to be able
>>> to distinguish between the "normal usage" scenario and the "attack
>>> scenario".  I also understand that this sort of technology is
>>> already deployed and is seen as useful by both users and data
>>> providers, so it seems unrealistic to expect to be able to get rid
>>> of this usage entirely.  I do think that it is unreasonable for us
>>> to enable this behavior without documenting the risks to the user,
>>> though.
>>> 
>>> *[yuval] I guess that there is nothing in the spec that technically
>>> enables phishing, however, it makes the social engineering part of it
>>> easier. How about the following addition to the security sections:*
>>> *"It is RECOMMENDED that operators put in place mechanisms that would help
>>> their subscribers identify a valid redirect operation from a malicious one"*
>>> 
>> 
>> I wouldn't dream of saying this is not a good idea, but I do wonder if this
>> is the right document to call attention to that problem. It sure sounds
>> more generic than "topping off my access credit".
> 
> I also am not saying this is not a good idea, but...
> 
>> Are the right people who need to be aware of that problem in order to fix
>> it going to look to this document for guidance?
>> 
>> If the answer is "yes", go for it, but if that advice needs to be somewhere
>> more visible, please do the right thing.
> 
> ... it's unclear to me that this document is the right place for
> such guidance.  That is, instead of a concrete recommendation, I had
> in mind just giving some extra facts that would allow the reader to
> consider the security implications of their deployment (this is the
> Security Considerations, after all), as in something like:
> 
> This document includes a redirection facility whereby the service
> provider can redirect (in an application-specific way) the end user
> to an alternate location when their credits have expired.  This is
> useful in that it allows for the user to return to normal service
> quickly, but also exposes additional risks and attack surface.  In
> particular, this redirection can potentially occur at an
> arbitrary point in a user's session, potentially without any
> additional contextual confirmation available to the user that the
> redirection is driven by the network.  Such a confirmation is
> important because, in many application protocols, the communication
> peer is also capable of inducing redirection, and when the peer is
> an attacker, the redirection can be to an attacker-controlled site.
> In particular, such sites may be "phishing" sites designed to appear
> similar to legitimate payment sites in an attempt to obtain users'
> payment information for fraudulent uses.  Because of the potentially
> harmful consequences of arbitrary redirection by an attacker (such
> as to phishing sites), it can be important for users and service
> providers to be aware of the risk and take measures to ensure that
> sensitive information (such as payment information) is only used for
> legitmiate purposes.  If an out-of-band signalling channel is
> available to provide contextual information that a redirection is
> triggered by the network as opposed to a communications peer, that
> can provide a highly effective mechanism for remediating this class
> of risk.
> 
> (The above may well be too wordy and could benefit from editing, of
> course.)

Based on our discussion on the telechat, how about something like the following?

"This document includes a redirection facility whereby the service
provider can redirect (in an application-specific way) the end user
to an alternate location when their credits have expired.  This is
useful in that it allows for the user to return to normal service
quickly, but also exposes additional risks and attack surface.  In
particular, this redirection can potentially occur at an
arbitrary point in a user's session, potentially without any
additional contextual confirmation available to the user that the
redirection is driven by the network.  This lack of confirmation matters
because, in many application protocols, the communication
peer is also capable of inducing redirection. When the peer is
an attacker, the redirection can be to an attacker-controlled site.
In particular, such sites may be "phishing" sites designed to appear
similar to legitimate payment sites in an attempt to obtain users'
payment information for fraudulent uses. When users become used
to such redirection, they may have difficulty distinguishing such
attacks from legitimate redirections.

Because of the potentially
harmful consequences of arbitrary redirection by an attacker (such
as to phishing sites), it can be important for users and service
providers to be aware of the risk and take measures to ensure that
sensitive information (such as payment information) is only used for
legitmiate purposes. Operators should follow industry best practices
for the specific application layer protocol to reduce the chances that
such attacks could be mistaken for legitimate redirection. The details
of such practice are out of scope for this document."



> 
> -Benjamin
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime