Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WordPress amtyThumb 8.1.3 Cross Site Scripting #1

Closed
Neorichi opened this issue Nov 23, 2017 · 29 comments
Closed

WordPress amtyThumb 8.1.3 Cross Site Scripting #1

Neorichi opened this issue Nov 23, 2017 · 29 comments
Labels

Comments

@Neorichi
Copy link

The XSS reflected because the values are not filter correctly:
amtyThumbAdminPg.php: Line 33:

amtyThumbAdminPg.php: Line 67:

[POC]

POST
/wordpress/wp-content/plugins/amty-thumb-recent-post/amtyThumbPostsAdminPg.php?"><script>alert("XSS")</script>=1
HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: es-ES,es;q=0.9
Cookie:
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

amty_hidden=1

@amitguptagwl
Copy link
Member

Thanks to highlight the issue. I worked on this plugins many years ago so not able to link the issue, however this plugin was not meant to accept any external request but to read posts and find out the relevant post with thumbnails. So I doubt for this vulnerability. However let me check.

@amitguptagwl
Copy link
Member

BTW what is the impact. I believe someone who doesn't have the access to the wp-admin should not be accessible this page. And if they login as admin try to inject XSS, it'll not be saved anywhere.

tell me if I'm wrong.

@Neorichi
Copy link
Author

Hi.
You can exploit it without login :).
Thanks

@amitguptagwl
Copy link
Member

oh :( sad to hear that. I've not changed in this plugin from a long time. so I was expecting it's very less usages. But yes, give me some time to fix that.

@Neorichi
Copy link
Author

No problem. thanks for you time :)

@fgeek
Copy link

fgeek commented Dec 1, 2017

CVE-2017-17059 has been assigned for this issue.

@PluginVulnerabilities
Copy link

PluginVulnerabilities commented Dec 1, 2017

What is claimed to be a vulnerability here wouldn't usually be an issue since the value of $_SERVER['REQUEST_URI'] is normally encoded by the web browsers, which would prevent reflected XSS from being able to occur in code like this.

In amtyThumb posts there is an actual reflected XSS issue. Is there a way we can privately disclose that to you?

In both plugins there isn't code that would actually restrict direct access to the files generating the admin pages. Adding something like the following would do that:

if ( ! defined( 'ABSPATH' ) )
     exit;

@amitguptagwl
Copy link
Member

@Neorichi Can you please tell me how you tested that? I tried to test it using postman, and by passing script code in fields on the admin page. Both ways I seen no issue.

If you can plz write down the steps to reproduce it, it'll help me a lot.

@amitguptagwl
Copy link
Member

Thanks @PluginVulnerabilities I have implemented this change for the time being, until I reproduce the vulnerability myself. I hope it should short out the issue.

@amitguptagwl
Copy link
Member

Updating changes to wordpress svn from git repo is like a nightmare. It is taking ages to sync the workspace. If it doesn't work well then I'll do it using svn some other day.

@fgeek
Copy link

fgeek commented Dec 2, 2017

@PluginVulnerabilities I didn't request the CVE identifier. Just mentioned here for cross-reference. If it is false-positive it should be requested to be rejected using https://cveform.mitre.org/

@Neorichi
Copy link
Author

Neorichi commented Dec 2, 2017

It is not a false-positive.... you can replicate it with Burp APP...
captura de pantalla 2017-12-02 a las 11 44 59
captura de pantalla 2017-12-02 a las 11 45 36

@Neorichi
Copy link
Author

Neorichi commented Dec 2, 2017

I´ve attached an other evidence..tell me if you need more information but i think that evidences are very clear :)
dic-02-2017 11-54-02

@amitguptagwl
Copy link
Member

Thanks @Neorichi I'm just looking for the steps to reproduce it. I believe above fix solve the issue. However I am facing issue to publish the changes.

@Neorichi
Copy link
Author

Neorichi commented Dec 2, 2017

@amitguptagwl thanks for you job... It is fine..publish it when you can ...don´t worry about it :)

@amitguptagwl
Copy link
Member

@Neorichi I have finally publish changes in both plugins using old svn way. I hope you should not see the issue now.

@amitguptagwl
Copy link
Member

Has it solved your issue?

@Neorichi
Copy link
Author

Neorichi commented Dec 4, 2017

Yes, is fixed :)

@amitguptagwl
Copy link
Member

thanks then I'm closing this.

@PluginVulnerabilities
Copy link

@Neorichi If you can only exploit this through Burp and not directly in a web browser then it wouldn't be a vulnerability, since a reflected cross-site scripting (XSS) vulnerability be exploited through a web browser and not Burp in a real attack.

If the vulnerability existed before it would still exist with the change made, since the only change made was to restrict direct access to the file, but the code will still run from the admin area. So either the vulnerability hasn't existed or it hasn't been fixed with the change made.

@amitguptagwl Is there a way we can privately disclose the actual vulnerability in amtyThumb posts to you?

@Neorichi
Copy link
Author

Neorichi commented Dec 4, 2017

You can exploit it with a simple post inside a website... the last example is just a example.
The XSS reflected is not working with the restriction that @amitguptagwl did so to me is fixed... I've notified this bug only to help him.

@Neorichi
Copy link
Author

Neorichi commented Dec 4, 2017

Sorry i mean without login

@PluginVulnerabilities
Copy link

@Neorichi We tried your proof of concept and it didn't work. The reason for that, as we explained before, is that $_SERVER['REQUEST_URI'] is normally encoded by the web browsers, which would prevent reflected XSS from being able to occur in code like what you care claiming is vulnerable. The testing tool you are using doesn't do that encoding, so it produces a different result than would occur during an actual attempt to exploit this.

The restriction put in place restricts direct access to the file, but the same exact code still runs when visiting /wp-admin/options-general.php?page=amtyThumbPostsOptions, so if the vulnerability existed, it still exists, you would just need to send a request to different URL.

It sounds like you are using an automated tool to try to find vulnerabilities. While tools like that can be useful, they also produce a lot of false positives. If you are going to contact developers about those results you should let them know that the results are unreliable or, preferably, do additional checking to confirm an issue truly exists before contacting them.

@Neorichi
Copy link
Author

Neorichi commented Dec 4, 2017

@PluginVulnerabilities i am not using a automated tools and i am not need to demonstrate you my experience with this vul.
To me, only the XSS without login are important.
Also i put this issue here because @amitguptagwl told me it.
Anyway, I am going still searching bugs without economic reward.
Good luck :)

@PluginVulnerabilities
Copy link

@Neorichi By an automated tool, we were referring to Burp, which you are using. So far you have not demonstrated that this is a vulnerability, which is the issue at hand. You need to understand what is and isn't a vulnerability, so you don't waste developers' time with false claims, as those make it harder to get real vulnerabilities fixed.

Even if you are not interested in cross-site scripting (XSS) that involve a login, you shouldn't tell developers that a vulnerability is fixed when it hasn't, just because it now requires someone to be logged in to exploit it.

@amitguptagwl
Copy link
Member

thanks @Neorichi & @PluginVulnerabilities both of you to show your deep interest. This plugin is opensource so feel free to do any change on github directly. I'll publish them on wordpress later.

@Neorichi I respect your effort to find the issue. No matter which tool a hacker uses, if any plugin allows someone to leak server information, or to inject undesirable code, it should be fixed. However I'm not sure how severe it was in this case. But thanks for your time.

@PluginVulnerabilities thanks for your quick fix suggestion. As I have moved to support other opensource projects and left the wordpress and PHP a long time back, it is difficult to me to provide quick support. However I'll try my best to discuss any issue as early as possible.

@ethicalhack3r
Copy link

ethicalhack3r commented Dec 9, 2017

Regarding the original XSS vulnerability reported by @Neorichi:

Although exploitation is limited, it is exploitable.

This vulnerability is exploitable in Internet Explorer as it does not encode the contents of the address bar.

This does limit exploitation considerably. Additionally, IE's XSS filter would need to be disabled, which it is not by default. Further limiting exploitability.

The following payload was used to remove any spaces:

"><img/src/onerror=alert('XSS')><"

Screenshot (IE 11):

screen shot 2017-12-09 at 20 31 40

@amitguptagwl
Copy link
Member

Is it after the changes, I mean with the latest version? Or with the old version?

@ethicalhack3r
Copy link

I tested the older version.

But, looking at your code changes, the newer version looks like it is also vulnerable to authenticated users.

The WordPress esc_url() function might be a good solution https://codex.wordpress.org/Function_Reference/esc_url

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants