Secumania posted on February 4th a a privilege escalation flaw in Metasploit 3.5.1
By placing a DLL file in the %systemdrive%\framework\postgresql\bin it is possible to get it loaded by a program (postgres.exe) that is executed by the frameworkPostgreSQL´s service executable (pg_ctl.exe), every time the service starts, with NT AUTHORITY\SYSTEM user privileges, being able to run arbitrary code in the local system. Notice the service startup is set to automatic by default.
I know, I know, you’re probably thinking “who runs this on Windows?” Metasploit has fixed the problem, perhaps ironically, by following the Microsoft Windows Application Specification (e.g. Requirement 4.4: Run in a secure Windows environment from January 21, 2000) a little more diligently in their Feb 9th release of 3.5.2. OMG that’s nearly 432,000 seconds in 0-day time since disclosure!
The new installers fix this issue through two changes: first, we’ve moved the default installation to %ProgramFiles%, which does not normally allow non-admin write access; second, we explicitly remove any inherited permissions for the “Users” and “Authenticated Users” groups. For users who prefer not to re-install Metasploit, you can use the following commands to fix the problem:
Vista and newer:
icacls c:\framework /inheritance:d /t
icacls c:\framework /remove *S-1-5-32-545 /t
icacls c:\framework /remove *S-1-5-11 /tFor systems older than Vista, you will need the xcacls.vbs tool available from Microsoft.
xcacls.vbs c:\framework /E /R SID#S-1-5-32-545 /T
Note that the “Authenticated Users” group doesn’t exist before Vista, so you only need to remove “Users”.
This issue is mitigated by the fact that it only affects multi-user Windows installations with low-privileged accounts, a scenario we believe to be a small percentage of our users.
Cue the evil cackle/laugh. Is that meant to be a hint? A liability disclaimer? Metasploit knows full well that those who choose to run Windows installations always run with high-privileges. Srsly now.
Metasploit must monitor download data for Windows version of the program, so maybe they could qualify their statement with something like “a small percentage of our tens of thousands/hundreds of…Windows users”. Even better would be if they could say “Dear HBGary, your installation of Metasploit…”. Kidding. Everyone knows HBGary used home-grown pentest tools as part of their custom CMS.
A quick note on the root cause – we swapped to a new installer framework (Bit Rock from NSIS) for the 3.5.1 release and changed the installer directory to default to C:\Framework. The new installer simply inherits the permissions of the parent by default, in the case of C:\, this allows authenticated users to write new files. The fix was two-fold, first to explicitly remove the users group from the directory (which causes some minor issues in its own right), and second to change the installer default directory to ProgramFiles, which has a “secure” parent permission mask.
Windows sucks :)
HD, thanks for the update. Was wondering why this just showed up. Now tell us how you really feel. Heh