Flawed Logic
Let's first understand how these system actually works. I'll be using Twitters Fleets for example and Instagram Stories are not way behind on this approach!
From users point of view:
- User choose image/tweet to share on their story/fleet
- User adds some graphic to composer view
- Story/Fleet is published
From developers point of view:
- User choose image/tweet to share on their story/fleet
- User adds some graphic to composer view
- App does screen grab of composed view and turns it into image/video
- App uploads that created image/video to server
- App sends correspondent JSON to describe created story/fleet
- App gets network status code if everything went smoothly
From developers point of view you can probably guess where flaw is?
Direct flaw here is in trusting integrity of uploaded image with correspondent description on server. Therefor steps 3 and 4 are perfect candidates for evil actor to change integrity of shared values.
Servers can record different description that does not equal to sent media. That shows two separate truths and as that should be concerning!
Example:
On image above we can see two different JSON structures. First JSON structure is one before MITM modification, second one shows data after modification.
In this example we changed original tweet_id to totally different one (have in mind this can be any valid tweet id). We also modified width and height of view that will get redrawn once Fleet has been open. Adding width of 1000px and height of 1000px will result in end user unableness to skip that Fleet and force user to open it!
With further research I have also concluded that this can result in crash on Android app! If we modify width and height values to larger numbers we can effectively crash Android app when user gets to that Fleet in their timeline!
Show case video:
Fleet flaw showcase
Android crash showcase
Here I would argue that system is simply flawed because it's not checking for changes in media and if they directly correspond to description of data!
This flaw shows that server does not check for data validation on its side, so malicious values can be passed!
Why it "can't be" fixed?
Good question! There is always possibilities someone else will find way to make this "spoofing/integrity compromising" attack more difficult but, reality is that client is vulnerable to runtime modifications. In story/fleets case, client is one creating media to be shared, researcher can find way to modify output of called method and we are back on square one!
But when you think about it, this is case in every issue in cyber security, we as developers frequently put various blockades to try and mitigate attacks, this is no different. One more more blockade can go long way!
I thought a bit, what that blockade can be in our case and I came up with this type of "fix"! There is probably plenty more and I would be happy to learn about them, just tag me on Twitter @nedimcodes
Possible added step to mitigate threat
First I would add some metadata to image describing most important values, if post/tweet is in question that should be post/tweet original ID.
On server I would check for post/tweet ID does it match with received metadata, if not then server returns error code! This would simply unable attacker from performing any spoofing on story/fleet.
Issue with this mitigation:
Attacker can simply find what method on client side is responsible for handling appending metadata to image, and modify it on runtime!
I tested my theory on two apps Twitter and Instagram! On Twitter I have managed to modify all sorts of data from size of bounds that gets redrawn in each new fleet view to changing what tweet id is actually getting called!
I've got written confirmation from Twitter to share my findings, after they have labeled my report as "informative". Read more about it here How I compromised integrity of Twitter Fleets (iOS and Android)
Note:
Both Twitter and Instagram were notified about these issue trough their bug bounty programs, both platforms responded that they don't think about it as valid security threat!
Appreciation
I would like to thank wongmjane for inspiring me to try iOS security path! I would also love to thank April King from Twitter security for giving me green light to disclose this publicly!
