A simple patch suggested by him is the following:
So how does this affect BeEF?
The bug is present when using Rack::File or similar directives to mount content in the Thin web server. We use that directive to mount the static content served via the /demos URI.
The affected code in the file.rb Rack library is:
Bear in mind, the demo content should be disabled when using BeEF in production, especially because you're not going to hook browser using the default hook demo page. This is the same as disabling debug logging in your web application when switching to a UAT to production environment.
The exploitability of the bug itself is actually very low, because the 404 page is returned with Content-type: text/plain. To trigger an XSS with such content type you need to rely on browser bugs, which are now mostly patched, and rely on not honoring the content type leading to content type mismatches.
And yes, I patched the bug in less than one hour from the moment I knew about the bug. So even without updating Rack to 1.4.5 or greater versions, your BeEF is gonna be safe.
This is my patch:
which is basically removing completely the reflection point:
Now, as I already knew this could be an issue, something like 8 months ago I changed the default
routing behavior in the BeEF core, creating a routing.rb class that overrides the behavior of the default 404 page from Rack.
So, the whole BeEF UI/Core and RESTful-API was not vulnerable since at least 10 months ago.
The only resources mounted with Rack::File are the /demos stuff, which I honestly never use in production, disabling the extension. You can see below how a not found page is handled in BeEF's router.rb class, which is used by every component of the framework:
So, a limited-exploitability bug, on an handler that is supposed to be not available in production, and last on a library we use (not code we explicitly wrote) :D
But, as we take these things seriously, expect a BeEF module which aims at hooking BeEF itself :D