Unrestricted File Upload vulnerability Found

[espebra]

Unrestricted File Upload vulnerability Found

[atluxity]

You call this "responsible disclosure", but posting this publicly on github is not THAT.

This is a public disclosure.

Also @Ratna037, you do understand that this is a file uploading service?
But as you say, how bad this is depends on what the application does with the uploaded file.

[Ratna037]

@ethlo Thanks for your valuable feedback. As I am in beginner learning phase, this can be addition to my knowledge.

[Ratna037]

@atluxity ,

I tried to find respective's team contact details. But couldn't get that. So I posted here.
Let the respective team check this. If it's not that much critical or false positive, then let them close it.

[espebra]

@Ratna037 Hi, thank you for the report. Can you elaborate a bit on how bad this is? Specifically, how are you able to take over the environment hosting filebin using an executable file that you've uploaded?

Edit; To add, I don't think this is a security vulnerability. Filebin, by design, allows executable files to be uploaded. If you can come up with a way to actually exploit this feature, please elaborate.

[Ratna037]

@espebra Hi, For this vulnerability I have used malicious xssproject.swf file for an example only which is available on Github itself. Attacker can use any other malicious file for this and cause the harm to the web application.

It is possible to make a website vulnerable to XSS if you can upload/include a SWF file into that website.

The xssproject.swf file has Adobe Flash function ExternalInterface.call(...) in it's actionscript code, which implements a JavaScript bridge to the hosting page.

Here is the actionscript code of xssproject.swf

According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.” Therefore, in our case, the string would be converted into JavaScript type.

So this function ExternalInterface.call() can inject malicious JavaScript to the hosting page, which makes the website vulnerable to XSS and attacker can do any admin task also.

References:
[1] The other reason to beware ExternalInterface.call() (URL: http://lcamtuf.blogspot.co.uk/2011/03/other-reason-to-beware-of.html)
[2] Flash ExternalInterface.call() JavaScript Injection – can make the websites vulnerable to XSS (URL: http://soroush.secproject.com/blog/2011/03/flash-externalinterface-call-javascript-injection-%E2%80%93-can-make-the-websites-vulnerable-to-xss/)
[3] Source of Malicious xssproject.swf File:
https://github.com/fuzzdb-project/fuzzdb/blob/master/attack/file-upload/malicious-images

What is XSS ?

Cross-site Scripting, also known as XSS, is a way of bypassing the SOP concept in a vulnerable web application.
The Cross-Site Scripting vulnerability is one of the few vulnerabilities that has made it in every OWASP Top 10 list of most critical web application security risks released.

XSS is a command injection of the client side, like the other user pointed out, it can result in any action that can be performed by the user. Mostly XSS is used for session hijacking where the attacker using javascript makes the victim transmit session cookies to an attacker-controlled server and from there the attacker can perform "session riding".

But XSS can also result in complete application takeover. Consider a scenario in which you inject javascript and it gets stored. The admin then loads that into a web browser (usually logs or CMS). If an XSS is present there you now have the admin session tokens. That is why XSS can be very dangerous.

An XSS attack is not a danger to the server. It's a danger to the reason you have a server. Not in a technical sense but very much a human one, as any kind of XSS attack originating from your site usually ends with your reputation down the toilet. A few test cases:

• Someone redirects from your site to a fake login page. Now you have a potential mass security breach of user accounts on your site.

• Someone puts a cryptominer on your site. This will make your visitors' machines work overtime and when spotted, makes you look either grossly greedy and/or grossly incompetent as a sysadmin. Neither of which is a good look.

• Someone redirects traffic from your site to a competitor. I shouldn't have to explain why this is bad.

• Someone puts some javascript in there that makes your site unusable or even crash browsers. Again, should be obvious why this is bad.

• Someone puts DDOS code in your site to try take down your site or a third party. If aimed at you, should be obvious why this is bad. If aimed at someone else and your site is deemed culpable, your hosting provider can cut you off if you do not fix your site for breach of contract.

• Someone replaces your ads with their own. If you rely on ad revenue, they're stealing that revenue.

• Someone uses it to snoop on your users. Hel-lo, breach of GDPR.

Most of the possible consequences of XSS vulnerabilities affect the user, not your server. So if you don't care about your user getting their accounts on your website compromised or your users seeing content on your website which doesn't come from your server, sure, ignore those vulnerabilities.

But if your users have admin rights, then an XSS vulnerability can easily lead to unintentional admin actions. A classic case of that is a log viewer in your admin area which isn't XSS-proof. Some javascript snippets in your access logs might get executed by your admins and perform administrative actions under their account. This is why you sometimes see javascript snippets in the HTTP headers of the bots which try to hack your website.

Additional damage could have been done by sending a request to the hosting company to cancel the subscription of the server and of the domain and transfer money from his banking account

References:
[1] Cross Site Scripting (URL: https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/ )
[2] How Dangerous is XSS ? (URL: https://security.stackexchange.com/questions/206520/how-dangerous-is-xss )

[ethlo]

I'm all for feedback and reporting issues (even if it may be a false positive). Better safe than sorry and I thank you for coming forward with this. However, this sounds to me like you have no way of exploiting it, but you read about XSS in a book/blog-post and automatically think that allowing user content on a page is an exploit. All the generic references to what an XSS can be just serves as a minor insult IMHO.

If you could inject code into a page that would embed the file, then it would be an XSS. The SWG or any other binary file is never embedded in any page on filebin.net allowing it to be executed, i.e. it is a "dead", binary file. It is just a link to it, and it is served with Content-Type: application/octet-stream, so I see no problem. Nor do I see any way of executing the file on the host file system itself.

[espebra]

I'm closing this now. If it was possible to upload and include, it would have been a vulnerability. I don't see how the current implementation is vulnerable. Please reopen if you find a way to include/inject code in the filebin app itself.

To add to that, I don't currently consider uploading an html file which references the swf file to be a vulnerability either. This is currently allowed and by design, until someone can show that it should be disallowed.