Note: This issue has been resolved (months ago… I have been lazy).
Two issues exist in Atlassian’s HipChat desktop client that allow an attacker to retrieve files or execute remote code when a user clicks on a cleverly crafted URL. This vulnerability works against OS X version 3.0.6 (132), iOS 2.3.3 (20307) and potentially others.
XSS in a Native App?
The client examines incoming messages looking for messages that contain data it should transform. The client supports common protocols such as “http://”, “ftp://”, and “file://”. In addition the parser seems to support [any word][the colon character][a forward slash][another slash or word]. Any match for this pattern is turned into a clickable link for user convenience.
Now we are cooking!!
Remote Code Execution
Run My File
We need to be able to introduce our own application or script, but how? We need a file that we control in a known location.
Now this is something truly crazy to me. What is the default behavior if we delegate ftp:// link? Well, when the FTP URL contains a username and password OS X it automatically connects. It treats it as a volume and automatically mounts it. ftp://anonymous:[email protected]/ will automatically connect and be mounted to file:///Volumes/220.127.116.11/.
SO put that with the XSS from above and we get one click XSS to RCE:
POC Desktop Image:
Note: In this example we use a .terminal file for a specific reason. Terminal.app has a property file with an option to specify a startup command. This is necessary to run things from a specific path while bypassing any code signing or executable permission requirement on a standard shell script. Hack.app also exists in this directory and would also execute.
Bonus File Desclousure
We have the XSS is the mobile app as well, but not the RCE, but what can we do? With this “XSS” we can make an XHR request to the local file system, using “file://”. We take advantage of a weakness in the “Same Origin Policy” in the embedded Webkit engine. A second Ajax request can send that data to a remote URL. This would allow an attacker to steal any local documents like configuration files, cached files, cookies or chat logs. This is true for both iOS and OSx.
- First e-mail to Atlassian that I discovered the issue.
- Same day reply “we are looking into it” (thumbsup)
- At some point Atlassian replies saying “someone internally already found this issue”, and this disqualified me from the “Atlassian Security Hall of Fame”.
- I send them 2 more XSS vectors (urls for github project home page and user “blog”). I also really try to explain that the XSS only makes the exploit one click. The protocol handler is the real issue leading to RCE.
- With the XSS still working in web, desktop, and mobile apps after 20 days and 2 automatic updates without a fix I pushed for a little more information. Still working on it / waiting to deploy.
- Two months and a few desktop versions later the bug was fixed.
- They send me a free T-shirt.
As of today the app still doesn’t appear to handle protocols correctly. The app is still one XSS away from another RCE. Can’t wait to see some of the new API intergration features.
Update: Atlassian did end up adding me to the hall of fame. I believe when I reported this was right when Hipchat was being merged into Atlissian which explains some of the turn around time. The timeline above makes it sound like it was not a great experience working with them. However that could not be further from the truth. They have been great.