📜 ⬆️ ⬇️

Twitter: intercepting the management of views and thoughts

image

What would you do if you could post to Twitter on behalf of any user of the social network? Submitted? Then I ask you under the cat for details.

Foreword


During the study of the safety of the social network Twitter as part of a BugBounty program, I discovered a vulnerability that allowed an attacker to post tweets on behalf of any user of the service without access to the victim’s account. This bug is particularly dangerous due to the fact that a huge number of both media representatives and other well-known personalities have Twitter accounts and use them to publish various news. And the detected security problem allows placing false information not in one, but in several large accounts at once (for example, news publications), and the public is more likely to believe in it. There are real examples when with the help of misinformation malefactors seriously influenced the stock prices of certain companies for their own benefit. More information about such precedents can be read ( here ). This vulnerability was discovered on February 26, 2017 and fixed on February 28, 2017.

We turn to the technical details of the vulnerability.
')

Introduction


Twitter has a service such as ads.twitter.com , it has a media library with the ability to upload media files (videos, pictures, gifs), as well as view previously downloaded media files that were used to post tweets . The library is available at the following link: ads.twitter.com/accounts/id_ your_account / media . Now to the point.

Looking around


Going to the library, we see the function of downloading media files:

image

After we click on the button “Upload media file” and select it, we will see the following picture:

image

By clicking on the downloaded image we see the following:

image

  1. Ability to tweet our media file.
  2. The ability to share a media file with any user.

So, well, let's take a closer look at the tweet function:

image

What do we see? Presumably the following:


We introduce some notation:


Since I don’t remember the exact wording of the errors that are issued, we’ll call them
"Error number 1" and "Error number 2".

We try


What I did to detect the vulnerability:

First, I intercepted the request to publish a tweet and changed the owner_id and user_id parameters in GET and in json-e, which was sent using the POST method, from account id 1 to the corresponding account id 2, but I did not get the expected result, only error No. 1.

After that, I decided to replace owner_id and user_id only in POST, to which I received error No. 2, as far as I remember, the text was like this: “The user with owner_id * the id that I replaced * does not own the media * here media_key *”.

“Good,” I thought, and did the following:

I used account # 2, went to the ads.twitter.com service, to the library, and uploaded the image in order to know media_key in advance.

Go-go


Returning to account number 1:

We intercept the request by tweet and substitute owner_id, user_id in GET and POST with the corresponding data of account No. 2 and media_key with the one we learned by uploading the image on account No. 2. Iiiii ... see the error number 1. Sadness, sadness, longing, though wait. When we previously replaced owner_id and user_id in GET and POST, there was one error (error # 1), and if owner_id and user_id were replaced only in POST, the error was different (error # 2). Let's try?

Replace the owner_id, user_id and media_key in the POST, iiii ... see a response indicating that the tweet was successful! Turning to account number 2, we see that a tweet was posted with a previously loaded picture of account number 2, although the account number 2 did not publish anything.

Try harder


So, at the moment we have the opportunity to publish tweets on behalf of any user, but we have a hard limit that seriously reduces the impact (criticality of vulnerability), namely, we need a user on whose behalf we are going to publish. loaded media file. Moreover, you need to know the media_key of this file, which cannot be picked up, since it consists of 18 digits. Well, we will look for an opportunity to learn media_key. In the process of searching, I did not find a 100% way to find out this media_key, there were always some limitations in the form of certain circumstances, under which, perhaps, we could get that same media_key. Its end? No exit? Report how to eat? Well, I do not! The inner feeling told me that this vulnerability can be brought to the climax of criticality! Remember the opportunity to share a downloaded media file? It occurred to me that maybe when we share our media file with the user on whose behalf we want to publish, he will also be considered the owner of the media file, error No. 2 will not occur and the tweet will be successfully published. And that is exactly what happened :)

To successfully exploit the vulnerability, we lacked media_key, but in the case when we are the owner of the file, we can see its media_key (screenshot No. 3).

Now the script looks like this:

  1. We load our media file.
  2. We share this file with the user, on behalf of whom we want to publish the record.
  3. We intercept the tweet posting request and simply replace the owner_id and user_id in POST with the victim’s twitter account id (it’s easy to learn, there are many online services).
  4. We receive a message about the successful publication of tweet.

Now you can report on vulnerability with peace of mind.

Findings:


RCE, SQLi, XSS - all this is of course very healthy and dangerous, but sometimes logical vulnerabilities are no less a threat to security and are often much simpler to operate than the ones listed above. It is worth paying close attention and attention of living specialists to this, as automated scanners are not capable of such. As for Twitter, it is not yet known how many such vulnerabilities it currently exists and may appear as it develops and adds functionality. Good luck to all bughunting!

Source: https://habr.com/ru/post/327904/


All Articles