Content type mishap allowing any file upload in cabana.yahoo.com
While doing a security research on Yahoo Inc. systems, I decided to analyze its iOS apps and see how they were handled. Yahoo in general has wide variety of scopes from all of its *.yahoo.com domain to domains of it acquisitions as well. That said, many researchers focus on web application that Yahoo has which leaves some of its iOS apps vulnerable.
First process was to download the app. To test out a security of one of its services, I downloaded Cabana. Cabana is an iOS app developed by Yahoo Inc. : https://itunes.apple.com/us/app/cabana-hang-out-watch-stuff/id1217648367?mt=8. When first downloading it looks that this allows users to send pictures and share live videos with their friends.
After the app was downloaded, it requested that I signup on the website. Once the signup was done, it asked, me to upload a profile picture. While using the app, I used Burp Suite to intercept/monitor every request the app was making. When the picture was uploaded, it sent a POST request to cabana.yahoo.com and uploaded the jpeg image. Cabana mostly relies on image sharing, so I decided to play around with its upload function. It seemed that no matter what was in the POST request, it will by default set the filetype to image/jpeg. This was done through Content-Type header. I forwarded this request to the Repeater tab.
In the repeater tab, I changed the Content-Type from image/jpeg to text/html and added a simple script. When the request was forwarded, in return it gave me a link that had .html extension on it. When the link was copied and browsed to, it showed that the link was actually working.
To further check a basic impact, I went to yahoo.com domain and scanned the cookies on that site. It seemed that both cabana.yahoo.com and yahoo.com shared cookie Id T and F. This is because that the cookies are allowed to be shared in all *.yahoo.com domains. This can allow for session takeover specially in cabana mobile app because it uses T as its main cookie.
04 May 2017 — Report submitted to Yahoo Inc.
05 May 2017 — Report Triaged by Yahoo Security Team.
10 May 2017 — Reply from Yahoo Inc. about a fix being added. Additional recommendation was provided to Yahoo Inc. to create a more appropriate fix because the file was still being created in the backend.
June 1 2017 — Bounty Awarded by Yahoo