Read-only application can publish/delete fleets

Summary

If you want to read my write-up in Japanese, you can visit my blog.

TL;DR

I found a flaw that allows a read-only application to publish/delete fleets while creating an unofficial API document for the Fleet API.

New feature - Fleet

Twitter released a feature named Fleet in Japan on November 10th. A day later, I got an update for my Twitter for Android. Since I was bored and trying to find something to do, I decided to reverse engineer it.

Try to analyze

Twitter for Android is written in Java like a normal Android app, and although it is obfuscated, it is not so difficult to analyze. Therefore, I decompiled it using [apktool] (https://ibotpeaches.github.io/Apktool/),[`dex2jar`] (https://github.com/pxb1988/dex2jar), and [CFR] (https://www.benf.org/other/cfr/) to make it somewhat readable state. (I won't go into the details of decompiling here, but if you google it, many resources will come out, so please refer to that.) We can't analyze the API without knowing the endpoint name, so I used grep to find the .java file that contains the string fleet, then I found a file that contains /fleets/v1/user_fleets. When I examined the files in the same directory, I found other strings that seemed to be other endpoints, so I analyzed them and wrote the documentation in Gist.

During verification...

After that, while checking the contents of Gist, I found that hitting the fleet-related API while authenticating as a third-party application worked fine. I thought "Isn't this good news for the creators of unofficial Twitter clients?", so I wrote more detailed API documentation. Before publishing, I was verifying that the contents of this Gist are correct, but when I sent a request to POST /fleets/v1/create as an application with only read permission, a fleet was created. {F1120781}

Is this a vulnerability?

At first, I thought that I had accidentally given write permission to my application, so I checked the permission, but apparently, only read permission was given. At this point, I started thinking "is this a vulnerability?", but I couldn't confirm it, so I decided to investigate a little deeper. As a result, in the normal Twitter API (POST /1.1/statuses/update.json, etc.), the permission of the application was checked before the API processing started (it is natural), but apparently, the fleet-related endpoint wasn't. It turns out that these APIs do not perform permission checks.

{
     "request": "\/1.1\/statuses\/update.json",
     "error": "Read-only application cannot POST."
}

Let's report it!

Since it turned out to be a vulnerability, I decided to postpone the release of the fleet-related API document and reported it to Twitter. The report was made on November 12th, and it was fixed on November 18th (I think it was actually a few days before the 18th), which was a very impressive remediation speed. Unfortunately, the fact that the fleet-related API could be used by a third-party application itself was a problem, and it was fixed by changing the fleet-related API so that it would not be hit by a third-party application anymore :(

After the report

Three days after Twitter fixed the vulnerability, there was a person who analyzed the fleet's API and tweeted that the fleet's image was not deleted from the CDN even after 24 hours. As it looks like the period that could be used to implement the fleet function was very short, I felt sorry for the developer inside Twitter.

Conclusion

This report shows the importance of constantly checking for new features and that even the large companies create vulnerabilities. If you have any questions, send a message to @ryotkak on Twitter.