2

A few years ago (a little over three now to be exact), I brought up what I consider to be a rather obvious (and serious) security issue with the Universal Windows Platform (UWP): The ability to use its WebAuthenticationBroker to phish credentials from a UWP application.

I recently brought this issue back up and it has been confirmed that this is still an issue in UWP. I would consider this a security issue that someone could exploit via a phishing attack, so rather than continue the discussion there I am bringing it here to get better understanding around my perception around it.

Now I am by no means an expert in security, but I love learning about it and I always have my eyes and ears open for scenarios exactly like this one. I am grateful for having found out about this site which is why I am posting this here question now. If I had known about this site back on December 2012 when I originally posted this question, I would have posted my original question here rather than on the MSDN forums (where it was basically ignored and not taken very seriously, in my view).

With that said, my understanding of exploiting this process is as follows:

  1. Create a sign-in page that looks exactly like the signin page from Google or Facebook (or your authentication service provider of choice). For starters, you would create this by going to target provider's login page and saving the source of the file and use that as the starting point.
  2. Modify the file made in the previous step so that it takes user input and passes it to the real authentication service provider. Account for when the credentials pass and for when they fail.
  3. Find a server to host the above file, deploy the file(s) (perhaps multiple files, as it could involve server-side magic) to this host and get the URL to the deployed location that loads this file.
  4. Create a UWP application that gets the user to login to a supported credential provider via the WebAuthenticationBroker. In the WebAuthenticationBroker.AuthenticateAsync call, provide the URL to the deployed location in the previous step.
  5. Deploy the application to the Windows Store. Get users to download it and use it (How exactly? That is where your creativity comes in).
  6. Have the user sign into your page (thinking it is a legitimate credential location -- the one you are impersonating). Since it has been confirmed that UWP and WebAuthenticationBroker does not display the URL/domain the user is signing into, it can be anywhere that is under your control and the user will not know.
  7. Validate credentials using the real authentication provider. If it works, pass the user on to the real sign in page (or better yet, simply set cookies on the user's session that makes it seem all is OK).
  8. Once you have obtained validated credentials, store the credentials for a later time, or use them for nefarious purposes immediately.
  9. Rule planet Earth with your new-found powers (OK I made this one up).

First off, I would like to verify with certainty that my understanding on the above process is accurate (last step notwithstanding, of course -- or is it?!). Is there something that I am not accounting for that makes this a non-issue?

If I do understand this correctly, it seems like this is a possible security issue with UWP and one that has not been addressed for over three years now. The guidance given from the MSFT CSG is to open a UserVoice vote for this issue. However, it seems to me that a security issue is one you fix and not one that you vote to address.

So my question is: Is this a legitimate concern? Or am I making a big deal about nothing here? Or is there something I have completely misunderstood (quite possible) that makes this a non-issue?

Thank you in advance for any assistance and/or clarification to my understanding around this issue, and around security in general.

  • 1
    This is a bit opinion-based. However, I will say this. Developers are people with lives and families (don't laugh). They cannot possibly fix everything. Quantifying risk is hard, and it appears that group of people have decided the risk of someone doing contortions to pull off this phishing attempt is too low to expend the effort of fixing it. Low risk and high effort does not make a high-priority bug. The critical show-stoppers get fixed first, and bugs like this just... fall to the wayside. – Ohnana Mar 2 '16 at 17:49
  • 1
    Thank you for the feedback, @Ohnana. Should I remove the fun stuff to make it more inline with what is expected? Sounds like that's a vote for "not a big deal." :) Which is perfectly fine. That is also an acceptable answer and exactly what I am after! Also, I am now even more glad I removed the EXTRA opinionated material that didn't make the cut from the original post. :P – Mike-EEE Mar 2 '16 at 19:05
  • 1
    Fun stuff is okay within reason. I know I giggled at "take over the world." I'm addressing more of the meat of the question -- "should this bug get fixed? why didn't it get fixed" will solicit varying opinions and conjecture. We don't like conjecture, we like cold, hard CASH! Er, facts. We like facts. – Ohnana Mar 2 '16 at 19:18
  • 3
    Essentially, this boils down to the fact that the URL is not displayed to the user? – Robert Fraser Mar 2 '16 at 20:04
  • 2
    I'm not familiar with the WebAuthenticationBroker flow, but is it actually represented to the user that the authentication is passing outside of the control of the spawning application? If not, the user must consider the application trusted, same as if they were typing a password directly into it. Surely there is nothing stopping any application from opening an arbitrary dialog that happens to look like a Facebook login? – bobince Mar 2 '16 at 23:11
2

Speaking of new-found powers. :)

It is now clear to me from the (great!) feedback here that I could have expressed this in a more fact-oriented manner, and that this issue does not seem to be as big of a deal as I am thinking it is. I tried to keep it as objective as possible, but in dealing with an issue that is over three-years-old, I probably let it get to me more than I should have (see: not handled new-found powers appropriately!).

I realize this site isn't meant to be a sounding board, but it took getting this question out to see it for what it was. I appreciate your patience as I learn here.

I have taken the MSFT CSG's advice from the referring thread and have started a UserVoice vote around this item. If you like, you may view and vote for this item here:

Consider Displaying URL/Location/Context to User in UWP Application During Authentication

I am almost tempted to delete this question, but I will let it stand as a reminding lesson in my quest to be a good citizen both here and in general within the broader community. Thanks again to all involved!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.