Saturday, April 1, 2017

Reporting "HipChat iOS App does not validate TLS certificates"

Overview:

While I was looking into an unrelated application, I noticed requests coming from HipChat's iOS Application were visible to my man-in-the-middle server and quickly found that there was no validation of TLS/SSL certificates.

It took a bit longer to get it patched than I was hoping, but they ended up meeting the timeline outlined in their Security Bugfix Policy.

The fixed version (with nondescript update notes) is 3.16.2:



Correspondance:

On January 8th, 2017, I wrote:
There does not seem to be any validation of the TLS/SSL certificate used by likeabosh.hipchat[.]com, which appears to be the primary API server used by the Hipchat iOS app.

This means that all traffic can be intercepted and manipulated by an attacker in a privileged network position.

I'm attaching a mitmproxy (https://mitmproxy.org/) stream file "mitmproxy-stream.out", which contains the raw data from when I MITM'd traffic coming from my own iPhone. This file can be read into the mitmproxy application and interactively browsed with the command - "mitmproxy -r ./mitmproxy-stream.out".

You can see that session information, channel metadata information, and chat logs are all present in the traffic that was captured.

To reproduce this yourself, you can also use mitmproxy. In my trial, I used the mitmproxy default SSL/TLS certificate file that gets generated on installation.



On January 17th, 2017, I wrote:
Hello,

Could someone confirm that you've received this and can reproduce the issue?

Andy



On January 17th, 2017, I received the reply:
Hi Andy we have received your issue. Sorry for taking so long to reply to you.



On January 19th, 2017, I received the reply:
Hi Andy,

Thank you for sending this notification to Atlassian. This is indeed a vulnerability and an issue has been filed on an internal tracker.

The issue is HCIOS-1033. Unfortunately, this issue is not accessible externally, so you will not be able to monitor its progress. Feel free to check with us for updates.



On January 19th, 2017, I wrote:
Thanks for confirming, [names redacted].



On January 19th, 2017, I received the reply:
Andy,
Here is a coupon for you to use in our store (swag.atlassian[.]com): [redacted].



On February 2nd, 2017, I wrote:
Thanks [name], is there an estimated fix date?

I use the app every day for work, and it's a bit worrying.



On February 2nd, 2017 I received the reply:
Hi Andy

Thanks for checking in. The development teams are working on this and we'll attempt to come up with a fix according to our Security Bugfix Policy (https://www.atlassian.com/trust/policies/security-bugfix-policy). The issue HCIOS-1033 has been filed on an internal tracker. Unfortunately, this issue is not accessible externally, so you will not be able to monitor its progress. Feel free to check with us for updates.



On February 2nd, 2017, I wrote:
Hi [name],
Thanks again for the quick reply & helpful link. That sounds good to me.

Out of curiosity, what severity score (CRITICAL/HIGH/MED) was given to this?

Andy



On February 2nd, 2017, I received the reply:
Andy,
The issue has been given a "High" (CVSSv3 8.9) severity at this moment.



On February 2nd, 2017 I wrote:
Thanks for the additional info.



On February 21st, 2017, I wrote:
Hi [name],
Can you share any information about what progress has been made to patch this? Is there an estimated fix date that you all are targeting?

I received a HipChat update from the iOS app store today but noticed the app is still vulnerable.

Andy



On February 24th, 2017, I wrote:
Bumping this one more time in case it got dropped. Is there a timeline for remediation or any estimate for a fix date?



On February 27th, 2017, I received the reply:
Hi Andy

The fix is in the new version (I believe 3.16.2) which is out in the AppStore. We currently do not see it's possible to proceed with an invalid certificate anymore and thus can't confirm your finding. May I suggest it could be due to the trusted certificate installed on your device for/from mitmproxy? If this still repeats for you would you possibly be able to record a video showing your setup and the flow which you believe is still prone to MITM? That would help us get to the root cause of the issue if it still persists.



On February 28th, 2017, I wrote:
Hi [name],

I am still able to repeat this despite having upgraded to 3.16.2. On my iPhone, I have not added any additional certificates as trusted or jailbroken the device (running iOS 10.2.1).

In the attached video (out.mp4), I have my iPhone connected to the same WLAN access point as my Macbook.

On the Macbook on the left terminal, I have a DNS server that constantly returns the Macbook's IP address. On the Macbook's right terminal, I have a python script that listens on :443 and attempts to make a SSL connection, printing any HTTP-layer data it receives if its SSL certificate is accepted by the client.

When I override the DNS server used by my iPhone to have it use the Macbook as its DNS server, it starts making background requests for various Apple services. These result in SSL exceptions being printed in the right terminal – this is expected behavior for when a client does not accept my Macbook's fake SSL certificate.

When I open the HipChat iOS app, you can see a DNS query is made to likeabosh.hipchat[.]com and when you look at the right terminal, you see HTTP POST requests. This implies my python script's fake SSL certificate is being accepted by the client, and the client is proceeding to communicate, unaware that it's not talking to the "real" likeabosh.hipchat[.]com.

The end of the video is me going into the App Store to show that I have indeed updated to the latest version.

If you are still unable to reproduce this, could you explain any differences in your testing environment?

If you have any questions about my set up, please don't hesitate to ask.

Andy



On March 3rd, 2017 I received the reply:
Andy,

Thank you for your continued effort and the video PoC. Would you please check if:
you wiped the application off your test device after updating to 3.16.2 but before doing MitM
you're able to sign in with your MitM setup on
you're still able to MitM the application as shown in the video PoC after a successful sign-in process

Additionally, what kind of TLS certificate are you using for you Python application? Would you be able to attach it to this issue?

Thanks.



On March 7th, 2017, I wrote:
Hi [name],

I'm traveling this week and I don't think I will be able to test your second question until next week, but I wanted to answer your questions now anyway:

>> "Check if you wiped the application off your test device after updating to 3.16.2 but before doing MitM"
No, I did not remove/reinstall the application after upgrading. I will test this when I get a chance, but it seems unlikely (though technically possible?) that this is the issue.

>> "Check if you're able to sign in with your MitM setup on"
>> ....
>> "Check if you're still able to MitM the application as shown in the video PoC after a successful sign-in process"
I also did not logout/login after the upgrade.
I will try logging out & back in before I test reinstalling the app, but I would note that if TLS cert checking is enforced only at the login stage, that still leaves the vast majority of an average user's session lifetime open to MITM (and being MITM'ed after the login stage is equally damaging if the session token can be captured).
I'll still test this out.

>> "what kind of TLS certificate are you using for you Python application? Would you be able to attach it to this issue?"
I'm attaching these cert/key values, but they were simply generated with openssl without any extra trickery. I don't think they will be especially helpful in understanding what's going on.



On March 7th, 2017, I wrote:
See the earlier comment for more details, but I'm also attaching the "dns.py" and "ssl-server.py" scripts that were used in the video in case you'd like them too.

Both were downloaded from the internet and have had slight modifications made to them.



On March 18th, 2017, I wrote:
Hi [name],
I can confirm the SSL validation works after the user logs out and back in (see attached pictures). "1.png" happens during a MITM'd login attempt, and "2.png" happens if I log in over a valid connection and then later try to MITM the app.

I can also confirm the SSL validation does not come into effect before a log out/in cycle is triggered. Before I logged out and back in, I was able to capture everything in a similar manner as before.

The command I used to do the transparent MITM with recording is:
mitmproxy -w outfile.log -e -b 0.0.0.0 -p 8080 --host

And I had set my iPhone up to point at this server by tweaking the HTTP Proxy settings in the Wifi Connection menu (no DNS server changes are needed with this).

I'd like to ensure everyone I work with trigger the login cycle so they get covered by the update, but if you all think the above information is enough to warrant logging out all users who had previously authenticated with the iPhone app and forcing them to login again, I'll hold off mentioning this to anyone until you have time to do this.

Could you let me know if you plan on doing this?

Thanks,
Andy