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

Unauthenticated Stored Cross-Site Scripting (XSS) - Admin Account Takeover #7830

Closed
007-prankster opened this issue Dec 17, 2019 · 5 comments
Labels
stale Stale issues & PRs flagged for closing

Comments

@007-prankster
Copy link

1. Bug Summary:

Stored 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.

Scenario:

When an end user is searching (http://hostname/search?search=term) for any results logs are being generated in admin panel (http://hostname/_profiler/).When an end-user inputs malicious payload such as
URL-Encoded: %3Cimg%20src%3Dx%20onerror%3Djavascript%3Aconfirm%28113%29%3E
Decoded: <img src=x onerror=javascript:confirm(113)>
Javascript is being executed on Database page of the admin panel (http://hostname/_profiler/token?panel=db) and unauthenticated attacker can use such malicious payloads to perform various exploits and phishing,Implement keylogger, CSRF Token Stealth,Session Aware Keylogger,etc.

2. Steps to Reproduce:

Navigate to http://host/
Click on Search
Input payload from above

end-user-payload

To validate the finding login to admin console and navigate to http://hostname/_profiler and select the log with payload navigate to database (http://hostname/_profiler/token?panel=db)
Selecting Logs:

admin-logs

Navigating to Database:

admin-logs2

Payload Executed:

admin-logs3-paylod-reflected

3. Mitigation:

  • Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
  • Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
  • Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

References:
https://portswigger.net/web-security/cross-site-scripting/
https://portswigger.net/web-security/cross-site-scripting/stored
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
https://www.checkmarx.com/2017/10/09/3-ways-prevent-xss/

@UtechtDustin
Copy link

Good Catch !
But i think its not an issue of bolt, its a issue of the https://github.com/symfony/web-profiler-bundle
Also the profile should NOT deployed to any production systems.

@Mikescops
Copy link
Member

Even if it's not on Bolt side, we need to make sure that he doesn't happen for the users. We can't rely on people not using profile in production mode.

@bobdenotter
Copy link
Member

Apart from the "boilerplate" content of this report, there is an issue somewhere.

Not sure if we can fix it, though. Like @UtechtDustin says, it's certainly a bug in the profiler. It looks to be this exact issue, which was fixed in SF 3.3.6: https://vuldb.com/?id.119510

However, as Bolt 3 runs on SF 2.8 components, it doesn't seem likely the fix will get "downstreamed".

We can't rely on people not using profile in production mode.

@Mikescops Well, no, but there's a few things to consider:

  • All this "hack" does is self-xss on a page that shouldn't be public. There's no escalation, no RCE, or any kind of injection. Keep in mind that this isn't the "admin" as the reporter suggests, but merely the profiler
  • People really shouldn't run with debug on in PROD. The backend warns you if you do. And if you ignore that warning, your diskspace will soon run out, as the profiler generates 400kb of data per request, with no automatic cleanup whatsoever.

So, while I agree that this should ideally be fixed, i'm not certain that we can, or whether it's feasible.

I verified that this issue is no longer present in V4 of bolt. Testing it did bring another issue to light, so i'll be sure to fix that. Thank you, @007-prankster .

@007-prankster
Copy link
Author

007-prankster commented Dec 18, 2019

@bobdenotter there are a few things to consider:

  • This hack isn't "Self-XSS" this is "Stored XSS" where in payload is getting stored on Administrator logs panel of Database Section.Upon exploiting, an attacker can easily gain access to Administrator account

  • Currently all Bolt 3 would be running SF 2.8 and which makes it still vulnerable and would leave all the Bolt 3.7.0 deployed servers still vulnerable

  • Version deployed for testing is the current latest (3.7.0)

Steps I've used to deploy bolt:

  1. php app/nut init

  2. php app/nut server:run

image

This issue will still affect all the users who deployed with the same steps leading to Administrator account takeover. This severity of this issue is much higher due to the following reasons:

1. Unauthenticated attack:
This is the type of attack where attacker does not need any credentials to perform the attack thus requiring no prior data while performing attack.

2. Stored XSS:
In case of reflected XSS where malicious payload is not been stored exploiting it in real-life scenario becomes quite complicated/challenging and requires social engineering for successful execution.

But in case of stored XSS payload is being stored in the back-end database and is executed whenever user (Admin) visits the affected page.

Mitigation for this vulnerability: UPDATED

While it was observed Bolt is making use of SF library as a security defense but these 3rd party libraries cannot be reliable or is Hack Proof. So as per security best practices developers are always recommended to ensure user input is properly sanitized and output is encoded which will further mitigate this issue.

@stale
Copy link

stale bot commented Feb 17, 2020

This issue has been automatically marked as stale because it has not had recent activity. Maybe this issue has been fixed in a recent release, or perhaps it is not affecting a lot of people?
It will be closed if no further activity occurs, because we like to keep the issue queue concise and actual.
If you think this issue is still relevant, please let us know. Especially if you’d like to help resolve the issue, either by helping us pinpointing the cause of a bug, or in implementing a fix or new feature.

@stale stale bot added the stale Stale issues & PRs flagged for closing label Feb 17, 2020
@stale stale bot closed this as completed Feb 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Stale issues & PRs flagged for closing
Projects
None yet
Development

No branches or pull requests

4 participants