When I was at ISC 2015, I decided to run Sensepost’s MANA. I wanted to see what connections and creds that I could get. More a learning experience as I hadn’t yet used that tool in a large public environment. I had also wanted to see if small tweaks I had made worked to run it more efficiently.
No Cert Pining or HSTS/SSL Stripping
While running it, I noticed that MANA kept giving me creds and back-end server details for a large E-commerce site in China. Seems many conference users were utilizing the mobile app and website. As I looked into it more, I was able to session hijack from the cookies and log into users accounts. I was also able to MITM the traffic and using SSLStrip, able to see API calls, purchase data and payment info.
At the time, I was sitting next to a friend and showed him my findings. He also was shocked that I was able to bypass any of their security mechanisms that should have been in place to protect the data as it was in transit. He informed me that he knew one of the heads at the Company and they were also at ISC and would contact them to meet and discuss.
Demonstration to the security team
After meeting with one of the Security team heads, he called his team that was at the conference to watch my attack and asked me to explain what I did so they could see if they could find a way to solve the problem. Most of the team couldn’t exactly follow what was occurring as they didn’t seem to understand that SSL could be stripped and that I was able to see in plain text the contents passed. There was a blanket denial, they seemed to think that it was not possible even after seeing me do it in person which one of the team members accessing the app from their phone.
Advice to remediate the problem
For a month or so after the conference, the team head and I kept in contact as he was trying to learn what was occurring and ways to remediate the issue. I spent time going over the technicals of the attack, and methods such as HSTS and cert pinning to stop the SSL Stripping, better practices to encrypt the data and not rely only on SSL which seemed to be the general practice in China then.
We will solve the problem…soon, or well maybe not
I received assurances that these would be looked into and the problem would get fixed when the next version of the mobile app and the website was updated. Versions would come and go and I would notice none where fixed. Countless messages went back and forth to the contact person asking of the status and kept getting assurances they would look into and fix. I was asked to hold off on public disclosure.
Patience young grasshopper, patience
It has been two years since this occurred. I have kept in contact with the security team head through the time. He also seemed frustrated as it was never a priority. Their company mindset was “it hasn’t affected us enough to want to make a big change“. My patience to not disclose has worn off based on their attitude to not want to fix an issue that could have effects on user data. Chinese companies rarely seem to care unless it affects their profits in a significant way.
Disclosure
I hope someone at VIP.com’s security team or in their Security Resource Center reads this or sees the CVE details. For two years, every version of the VIP mobile application for both IOS and Android was still venerable to the attack vectors I showed the team in 2015. It is 2017, time to care for your user’s data and not just only care when it becomes a larger issue.
Timeline
8/2015 Findings made at ISC 2015
8/2015 Disclosure to VIP.com security team
9/2015 First follow-up to discuss methods to remediate
10/2015 Second follow-up to further discuss remediation
10/2015 Assurances from VIP team that they would fix
12/2015 Follow-up checking on status
Multiple times throughout 2016 Additional follow-up on status
8/2017 CVE applied for and public disclosure, #TrevorForget