Posted on

Microsoft Sunrise Phishing Vulnerability

Three familiar options

First off, neither Sunrise’s awesomeness nor it’s recent acquisition by Microsoft is the topic of this post, this is about API permission security. Yeah I know, boring stuff ^^c

To many, Sunrise solves the final quest of calendar management. While Sunrise’s app and web service reaches almost any platform and it’s 3rd party calendar integration covers almost any calendar-enabled API, it could be easily called the #1 approach a truly integrated time management for everybody.

For example, Microsoft Sunrise enables you to integrate your Facebook event dates, Trello due dates and regular Google and/or iCloud calendar dates into one beautiful, simple calendar that can be accessed from any device in your life, no matter if it’s a Mac, PC, Android, iOS or even FireOS. You don’t even have to enter many passwords, just klick trough the API access dialogue of the corresponding service and you’re in.

Unfortunately, Microsoft Sunrise follows a certain new approach in user account management. If you sign up choosing the option “Connect with Email” (rather than “Connect with Google” or “Connect with Facebook”) with a Sunrise-specific password, you’d probably expect that this user account will only be accessible by someone knowing exactly this combination of Email and password. Hint: It’s not quite like this

Three familiar options
three familiar options for signing up to Sunrise

Using Sunrise means adding other accounts to your sunrise account, otherwise your Sunrise calendar will be plain empty. And as soon as you add, say, a Google account to your Sunrise account, Sunrise will start accepting your Google Email/password credential set to access the whole Sunrise account. Add a Facebook acount, and Sunrise will start accepting your Facebook login credentials to log into Sunrise. It’s a careless convenience feature which is not necessary to maintain the Sunrise functionality. So it’s better described as a pool of accounts, in which your Sunrise credentials are just one of many ways to access this pool, which then holds all the other accounts. It actually is quite convenient, at least you can skip remebering your initial Sunrise credentials now. But that’s also a terrible flaw in API permission security. Right now, Sunrise allows anyone full access to your Sunrise account who has, authorized or not, access to only a single one of those accounts added to your Sunrise account. Moreover Sunrise fully merges two distinct accounts as soon as it finds one common account added to both of them.

To see how this is a vulnerability, let’s first take the innocent approach and say, you had a Google account you’re sharing with someone else, i.E. the account of my band, startup company or dance group, and you want to integrate those accounts into your Sunrise account, the following is likely to happen:

  1. You’d connect this Google account, which can be accessed by a group of people, to your Sunrise account
  2. Someone else in the same group of people, who has access to the same, say band-account, also connects this Google account to his/her Sunrise account. And just for fun, let’s say anybody in this group of people does this.
  3. What then happens, and I’ve tested this back and forth, is that all the Sunrise accounts, since they’re sharing one common Google account (the band-account), become one unified Sunrise account. Also all the data will immediately be synced between and pushed to all the devices and accounts.

You’d probably laugh when you suddenly see all your friends or work colleagues private data on your desktop until you realize that he also has yours. And there’s not really an easier way out of this but revoking all the API-grants in each and every account and disconnecting all your accounts from Sunrise. It might help to ask your colleague to also remove all your private data from his machine. And all his other devices.

So, if there’d be only this innocent approach, I’d not call it a vulnerability. But read on, you might already guess it:

  1. Let’s say an attacker gains unauthorized access to only one of your accounts. If you’re using Sunrise with this account, that means the attacker has instantly gained access to all of your Sunrise-enabled accounts.
  2. Let’s say an attacker asks you to join Sunrise and add a certain account with attached credentials to it to collaborate on a project or access some infos. If you’re then tempted to add other private accounts to Sunrise (which is rather likely since Sunrise is awesome, right?), that stranger gains access to all of these accounts.
  3. Let’s say you’re getting an email, maybe even claiming to come from Microsoft Sunrise, but actually by a malicious phishing attacker. It’d tell you that there’s a good reason to add a certain calender with attached credentials to your Sunrise account, maybe to keep track of latest announcements, news, lotterys, gift coupons or vouchers. Maybe it’d tell you that you’ll have to pay for using Sunrise in the future if you don’t. So you (no offense, you probably wouldn’t, but one in 1000 defenitely will) add the calender, and, before you’d even notice what’s happening, the attacker had gained access to all your accounts.
  4. Webservices are compromised by attacks on a daily basis, so there’s always a chance, that one of the credential sets, that is bound to your Sunrise account, might be among those. In consequence, using Sunrise weakens the security of all your accounts down to the strength of the weakest linked webservice.
  5. Users tend to chose weaker passwords for less important accounts containing less important data and also treat them less securely (such as having them on a sticky note on their computer screen). Adding one of those to Sunrise weakens the security of all Surise enabled accounts of this user down to the security of the easiest to crack/guess/obtain credential set.
  6. Either way, this can be exploited too easily.

So, I am not saying here that Sunrise is not awesome in a way, it actually simplifies a lot of the tedious everyday calendar management. All I’m saying is, be careful in how you use it, and have strong passwords for each and every account in Sunrise, no matter how few or unimportant data they might contain. Don’t use accounts with Surise that you share with other people unless you want to actually share the whole sunrise account.

Unfortunately, I also have to say that there’s no way I’d personally ever had used Sunrise in the first place if I had known, that this is how Sunrise treats my accounts. It’s a serious violation of any security precautions I’d expect a private data driven webservice to take.

BTW, here’s my conversation with the Sunrise support. It also shows how I found about the flaw in the first place. The rest I leave uncommented for now:

I contacted the Sunrise support with this request:

Hello Sunrise Team,
we’ve got an interesting issue to report here. Two people (a work colleague and me) created two distinct sunrise accounts (using the “Connect with E-Mail” option in the signup procedure of Sunrise), both registered to our two distinct private email adresses.

So, of course, each of us then started adding several 3rd party accounts to our Sunrise accounts, such as our private iCloud, Facebook, Twitter, Google, Meetup and many more, having all of them lined up nicely within sunrise.

That was nice!

Then, we added the Google account we’re using for our company related appointments and communication, so we could share those through sunrise.

And it was then, when Sunrise suddenly started syncing every account, my colleague had linked to his Sunrise account to my Sunrise account, and vice versa. So I ended up having all his private iCloud, private Google and other stuff in my Sunrise account. And he ended up having all my private Google, Facebook, Meetup and many more accounts.

That was not so nice.

After some back and forth testing, we found that, apparantly, Sunrise regards our sharing of one common Account (in our case, the company’s Google account) it as sufficient criteria to sync all the other accounts between two distinct Sunrise accounts. So as soon as one common account is added to two arbitary Sunrise accounts, they are simply merged into one pool, synced multillaterally. Even if the common account that caused the merge is removed afterwards, the other synced accounts remain persistent in each account, causing them to also pool-sync every new account that is linked to either Sunrise account afterwards.

We also see that Sunrise might not be the intended use for Sunrise to work collaboratively on one connected account but not others. However, we’re also a bit shocked so any statement on this is appreciated.

Kind regards,
Moritz Walter

And this is what came back:

Hi there,

So sorry to hear that trouble. Unfortunately, that situation is happening because you’ve both added an account that is connected to the same email directly to Sunrise, which is interpreting it as being owned to the same person: We recommend to share calendars as explained here (Share Your Calendar) instead of sharing a whole account, which can result in the behavior you’re seeing.

The solution here is to disconnect all the offending shared accounts, and have the second individual log off completely of Sunrise and log back in. This will create a new account for them. Before adding the connected calendar directly to Sunrise again, though, follow the instructions in the link provided (Share your Calendar). This should display everything as you desire.

Let me know if this isn’t clear! We apologize for any inconvenience this may have caused. We’re always working on redesigning the app when things aren’t as intuitive as they should be.


How would you rate my reply?
(Good) (OK) (Not good)

Leave a Reply

Your email address will not be published. Required fields are marked *