Arbitrary Render Vulnerability

[pruby]

Hello,

There is an arbitrary render call present in this project here:

https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/app/controllers/courses_controller.rb#L64

Render may be invoked with a string of the attacker's choice. The exploitability of this was highly limited by this patch: https://groups.google.com/forum/#!topic/rubyonrails-security/335P1DcLG00

It is not likely to have significant current security impact, but prior to this patch the dashboard was likely vulnerable to remote code execution (see https://groups.google.com/forum/#!topic/rubyonrails-security/335P1DcLG00).

An example exploit could have looked like:

https://dashboard.wikiedu.org/courses/University_of_Arizona/POL_150C2-III_(Spring_2017)?format=json&endpoint[inline]=%3C%25=`whoami`%25%3E

(this triggers an error now - Rails' mitigation kicks in)

• Please consider whether there was a window of vulnerability, and whether there were any indicators of exploitation during that window.
• Please whitelist all calls to render as a matter of good practice. An example might be:

if %w(articles campaigns check course revisions tag tags timeline uploads users).include?(params[:endpoint])
    render params[:endpoint]
end

This issue would be reported by the Brakeman vulnerability scanner, and its presence may indicate that static security checking tools are not used or the results are ignored. Please consider integrating such a tool in to the build process, and thoroughly investigating any warnings emitted.

[ragesoss]

Thanks! Exploitation seems very unlikely to have happened. If I understand correctly, this vulnerability would have allowed rendering of an arbitrary view, but without setting any additional instance variables. I can't think of any private data that could have been extracted with this. Survey and feedback data is private, but would not be accessible without setting the relevant records. User emails are private, but these are part of the users course endpoint for users who are allowed to see them anyway.

I've added whitelisting of the endpoint param in the commit above.

[pruby]

Hi ragesoss,

The bug was originally described as an information disclosure issue in those terms, however people found several ways to exploit this following that. The main method known is that by causing ERB code to be written to the logs, then including a log file, an attacker could cause code to run.

Another method is that by exploiting a type confusion vulnerability, as in the link in the first report there, an attacker could pass a template to the application and have it executed. Prior to the patch, that link would (on the basis of code review - I haven't checked out the old version) execute whoami as a shell command on the server and return the result.

If the application contains relatively few private details, that of course changes how far you need to delve in to the past on this one. If you had any other indications of compromise during that window (details turning up in leaks, etc) then this should probably go on the investigation book for those.

Cheers,

Tim

[ragesoss]

I see. With arbitrary shell access, I suppose any data could have been obtained. There aren't any indications that would point me towards having been exploited, but it sounds like it would be pretty hard to trace.

Thinking through what data it would be possible to leak:

• The auth data is all in the form of OAuth tokens for Wikipedia accounts that would only work when coming through the application's callback url, so those should be useless.
• User emails and names are privileged info not available to all users.
• Survey responses to our instructor and student surveys are private data, although not particularly valuable except to us.