This article covers a vulnerability in Plurk’s session management, specifically on their Android apps. This vulnerability can be mitigated if we manually revoke the apps’ authorized sessions from the apps management page. Thanks to Chengda Shen, Plurk’s CTO, for telling me that.
I totally forgot about that page when thinking about the severity of the bug initially, but with the apps management page’s functionalities the risks from the bug can be mitigated. Actually, I had known about the page since a few months ago I tinkered with Plurk’s API and went to the page to see if my test app is properly authenticated. But I totally forgot about it, many thanks to Chengda for answering my stupid question.
Actually, the apps management page is also accessible from the drop-down menu. It’s right above the language settings.
June 9, 2016: A report is made to Alvin Woon, the founder of Plurk, near midnight via email. I didn’t know where to report and some of my friends sometimes just casually mention Alvin on Plurk to ask something, so that’s where I decided to go.
June 10, 2016: Before noon, I forwarded the report to Plurk API developers’ mail since there’s no response for the report I sent to Alvin. Not long after that, Alvin replied the forwarded email and adding Chengda Shen and John Liu to the loop.
June 15, 2016: Asked about the fix and how to mitigate the bug’s effect. The email was answered by Chengda, telling me that they’re currently looking for a way to properly revoke old apps sessions. He also told me that we can use the apps management page to manually revoke the apps’ sessions while they’re working on the fix.
I found the vulnerability by chance when I’m updating my Plurk account’s email address and password. I noticed that when I changed my password, the Plurk Android apps installed on my phone wasn’t logged out.
I tried it again after some time by logging in to Plurk with two browsers. When I changed my password on one of the browsers, the other browser’s session was properly logged out. But when I checked the Plurk Android apps on my phone, it’s still logged in.
The application’s behavior on the web is also different, since it can properly force sessions other than the one requesting password update to log out. This inconsistency might indicate that it’s an unintended behavior from the application. So I consider this a critical vulnerability, especially for Plurk users.
While I haven’t tested it, there’s a good chance that this vulnerability also exists in every apps connecting to Plurk API. I proceed to notifying Alvin Woon and Plurk API developers regarding this bug.
The vulnerability might allow an attacker to persist their access to our Plurk accounts by using our credentials to log in via Plurk Android apps. Since even after we changed our password the device is still logged in, we need to manually revoke the apps’ access from the web to ensure that the apps’ authenticated sessions are dropped. But a lot of people might expect their problem to be solved by simply changing the password, since it’s the expected behavior of many other apps. That’ll leave them feeling safe after changing their password, when actually they aren’t safe yet.
As Chengda told me, at the time of writing, Plurk’s engineering team is still looking for the best way to revoke the old apps’ sessions. So while they’re working on the fix, please use the apps management page to make sure that nobody other than yourself is using your Plurk account from Plurk apps.