In Rustici Engine version 2017.1 and above, the player (both modern and legacy) is a static page that is given a url to use in retrieving the information it needs to launch the registration. Improper validation of this url parameter by the player created a potential XSS vulnerability.
When Engine is hosted on the same domain as the customer application, this XSS vulnerability could be exploited to send forged requests to the application as the authenticated user.
184.108.40.206 and below
220.127.116.112 and below
2019.1 (all versions)
2018.1 (all versions)
2017.1 (all versions)
Any customers who are using versions of Rustici Engine on one of the impacted versions listed above, and who launch the player on the same domain as other protected resources, are vulnerable.
There are several conditions that have to be in place, however, for this to actually be exploited:
- Engine 2017.1 or later must be in use (see Impacted Versions above).
- A user must be logged in to a session that protects a resource on the same domain as Rustici Engine’s player.
So, for example, if you have session-protected resources on `mycompany.com` but Engine is launched on `lms.mycompany.com`, the resources on `mycompany.com` will not be accessible from the attacker’s script due to CORS restrictions.
- An attacker must craft a payload which operates on the protected resource, and get a user to click on it while logged in to a session giving them access to that resource.
For example, the attacker sends an email with a specially crafted link to Engine’s player page, and gets the user to click on it while logged into the application.
- The protected resource must not require re-authentication.
Some high value resources or operations require re-authentication to use (think, typing in your old password in order to change to a new one). This would effectively mitigate the vulnerability, for that resource.
If the above conditions are met, an attacker will be able to impersonate a user and make requests to resources they are authorized to hit. Note that a CSRF token will not mitigate this access, as the script will be running in the context of the Engine domain.
The severity of this impact will be dependent on what resources are available in this context. In particular consider:
- Are there administrative accounts with sessions on this domain?
- What can those administrators do with that access?
We are not aware of any cases where this vulnerability has been exploited, but now that information about it is published, the risk does increase.
We were made aware of the cross-site request forgery exploit mentioned above by a security research team in March. We had already removed the vulnerability in a release of 21.1 Engine, but it had not been deployed in the environment where they discovered it.
While we had recognized earlier that an attacker could potentially run arbitrary scripts in the context of the player page, we did not recognize the full severity of the issue until seeing the sample exploit provided by the research team. Our focus had been on the use of this for the purpose of cheating (by modifying the player state), which could be accomplished through easier mechanisms due to the nature of SCORM.
Once we were aware of the broader implications, we began the process of backporting our changes to 20.1 and preparing to notify customers.
Hosting the Engine player on a domain that is different from your application should prevent effective exploitation as long as overly permissive cookie domains or CORS headers are not in use.
To remove the vulnerability completely, remediation requires upgrading to a fixed version.
Note: if you are using the RemoteDeliverPageUrl setting to host the player files on a different domain from the Engine application, you will need to take some additional steps to whitelist the url from which the Player loads its configuration from Engine.
2022-03-01 (for Engine 21.1)
2022-05-26 (for Engine 20.1)
Exploit Use Identification
Access logs can be reviewed for requests to the modern.html or legacy.html pages where they have a non-standard 'playerConfUrl' query parameter. In affected versions, the value of this parameter should be something like "playerConfUrl=%2FRusticiEngine%2FPlayerConfiguration.jsp" (the path will depend on where your Engine application is hosted and the RusticiEngineUrl setting).