PulseReport: a navigation vulnerability in the desktop app
A record of a vulnerability reported by an external researcher and what we did about it.
This is a template for publishing a security event. Where an event is found to have affected users, UNCHAIN, Inc. publishes the background, what was done and who was affected, and thanks whoever reported it. When publishing an actual event, we use this structure: summary, how it arose, what we did, who was affected, preventing recurrence, acknowledgements, further reading. What follows is a worked example. Dates, reporter names, numbers of people and items, and version numbers are left as placeholders, to be replaced with the real values on publication. Where a third-party supplier is named, agree it with them before publishing.
Summary
In some in-app notifications shown in the desktop app, text entered by a user was rendered as it stood. By including crafted text there, it was possible to cause a user who clicked the notification to be navigated to an unintended external page. Given how the app then handled navigation, there was scope for such a page to reach the signed-in session information and data on the machine.
We began investigating the day the report arrived and applied a server-side fix to all users the next day. We also added navigation restrictions to the desktop app itself.
| Item | Details |
|---|---|
| Date reported | Please contact us |
| Reported by | [reporter name] ([reporter's organisation]) |
| Affected | Desktop app [affected versions] |
| Server-side fix applied | Please contact us |
| App-side fix released | Please contact us |
| Fix confirmed | Please contact us |
| Evidence of exploitation | None found, other than the reporter's proof of concept |
| Action needed by users | None |
How it arose
This event arose from two implementations coming together: how user input in a notification was rendered, and how the desktop app handled navigation.
Background
Pulse's in-app notifications let you move directly to the relevant screen, such as a note that has been shared. Some of those notifications included the display name set by another user, and a display name was a field a user could set to any text they liked.
Exploiting it required causing a notification to be raised for the target user (by requesting access to a private note, for example) and then getting that user to click the link inside it. Because a specific person had to be targeted, it was not structurally easy to carry out at scale.
Direct causes
- Handling of input — the display name a user could set was rendered in the notification in a form that could be interpreted as a clickable element.
- Handling of navigation — the desktop app navigated without checking whether the destination was trusted. A destination page was in a position to reach the signed-in session and data visible on the machine.
What we did
| Date | What was done |
|---|---|
| Please contact us | Report received. Reproduced the same day and began investigating |
| Please contact us | Fixed server-side so that user-entered text in notifications is rendered as plain text. Applied to all users without waiting for an app update |
| Please contact us | The reporter pointed out a way around the fix |
| Please contact us | Applied a further fix addressing that bypass |
| Please contact us | Added and released a control in the desktop app prohibiting navigation to untrusted destinations |
| Please contact us | The reporter confirmed the issue was resolved |
We applied the server-side fix first so that everyone was protected without having to update the app. On top of that, we made a change on the app side that revisits how navigation is handled, rather than addressing the individual technique.
Who was affected
- So far as we could see from access logs and the app's operational records, there is no evidence of this being exploited, other than the reporter's proof of concept.
- Exploitation required preparation aimed at a specific user; it was not structured in a way that could be carried out against large numbers of people at once.
- No action is needed by users, and we are not asking anyone to change their password or sign in again.
Where personal data is leaked, lost or damaged, or there is a risk of that, the nature of the case may make it necessary to report to the Personal Information Protection Commission under Article 26 of the Act on the Protection of Personal Information (a preliminary and a final report) and to notify the individuals concerned. The situations that must be reported are set out in Article 7 of the Enforcement Rules, the reporting deadlines in Article 8, and what must be notified to individuals in Article 10. When publishing an actual event, decide whether these apply and, where they do, say so and set out what was done. In this worked example, no situation amounting to a leak of personal data was found.
This page is published as something UNCHAIN, Inc. does of its own accord. No law generally requires private businesses to publish security events. The obligations that can arise in law are reporting to the Personal Information Protection Commission and notifying individuals under Article 26 of the Act on the Protection of Personal Information; reporting a leak of the secrecy of communications where registered as a telecommunications carrier; and notification under contracts with corporate customers.
Preventing recurrence
- Consistent handling of input — we reviewed how text a user can enter is rendered wherever it appears in notifications and note lists, and made the implementation consistently treat it as plain text.
- Navigation controls — we added an allowlist check to navigation from the desktop app. Destinations that are not allowed open in an external browser rather than inside the app.
- Reviewing similar places — we identified the screens other than notifications that display user input and checked that the same problem does not remain in them.
- Regression tests added — we added automated tests so that the rendering of input and the navigation controls are not lost in future changes.
Acknowledgements
Our thanks to [reporter name] ([reporter's organisation]), who reported this with a clear proof of concept, went on to point out a way around the fix, and helped us confirm the fix afterwards.
Further reading
- Vulnerability disclosure policy — the scope of permitted research, how to report, and how we respond to reporters
- Application terms of service — desktop app updates and supported environments
- Our security arrangements — the technical and organisational safeguards in place day to day
- Enquiries about this matter: tharada@the-unchain.com / vulnerability reports: tharada@the-unchain.com
Where the reporter or an external researcher has published technical information, link to it here. Agree with whoever published it whether and when to include it.