Today I will go over part I of a few tricks we can use to attack Cold Fusion Servers of various versions using a few published methods. Cold Fusion is an Adobe product targeted at Enterprise and Small Business owners. Probably most commonly known for and associated with CFML or Cold Fusion Markup Language, most visually associated with .cfm files on web servers. CF platforms are built on a Java core and as such it also has some built in features which also allow command execution and database interaction. The following should present you with a few methods you can use to check for common vulnerabilities on these platforms, as well as how to exploit them. Most of these were published ages ago in 2010 but there are still many sites which are either running versions which are un-patchable or just simply running unpatched software still....
I will start this series off with the most common vulnerability first, which is the known Local File Disclosure, or LFI, in the 'locale' parameter (also referenced under: CVE-2010-2861). The LFI vulnerability allows us to read files off of the target system, without any authentication. The neat thing that makes this one different than most LFD is that if we play our cards right we can use this vulnerability as a foothold to further penetrate our target, read and see. We first try to find the admin page, as it is the most commonly vulnerable page, but certainly not the only one. You can typically find it at one of the following locations:
Knowing the version is important as it helps us to determine the appropriate path to use to try and turn this LFD into something useful. Now if you know the full path to the CF '.properties' file then you're in business as it contains the CF admin password hashes. The list of possible paths worth trying are as follows:
NOTE: In version 6 & 7 encryption is not enabled by default, although i never seen a server which did not encrypt the password in hash form.
Now you can crack the password hash and login with clear text pass or we can use a little trick to bypass authentication requirements by using a pass-the-hash technique. The login form uses a bit of JavaScript magic to actually create a HMAC hash from the admin password hash and a salt value which is changed every 30 seconds. You can find this salt value by simply viewing the source code for login page, look at second occurrence of the term 'salt' or review form input details. Due to this, we pass the hash and generate the HMAC hash on our own and submit - simulating a successful login! You need to grab the salt from source:
OK, so you now have Password hash and salt in hand....
Here is some code I whipped up to accomplish this task of logging in real quick for you to get the authenticated cookie.
Quickly enter the needed details and run it. If successful, you will have the authenticated cookie presented to you in terminal, like so:
Now once you have the authenticated cookie, you're pretty much in. You can use your favorite cookie editor to load up the new 'CFAUTHORIZATION_cfadmin=<SOMEVALUEHEREONSUCCESS>'. Once loaded you simply refresh your browser and your now logged into the administrative panel for Cold Fusion. Now to try and get a shell up on the server....
If you already know the server path to web facing directory then you can move forward, if not you can check the 'Mappings' link on the left under 'Server Settings'. This will show a mapping of all paths for CF, by default the /CFIDE dir should be mapped giving us a usable path in the majority of cases. Mappings page looks like this:
Once path is known we will move to the 'Schedule Tasks' page located under 'Debugging & Logging' on left menu links.
Now you simply point the task scheduler at your remote CFM/JSP shell hosted on a server you control, stored in txt format like an RFI attack payload. You can schedule for a onetime event, it will default to current time so no need to calculate things if your on different time zone :) If you need a username/password to access the remote shell file source then provide as needed in appropriate fields of task scheduler. The next is key, mark the option to 'Publish" to true so it saves the results to a file (i.e. grab our remote shell source, and save to executable). You then provide it with the full path to where you want to write to. In the majority of cases /CFIDE is writable, otherwise poke around or generate errors in SQL queries on site to get path (standard Full Path Disclosure rules still apply here). When you form is all setup you can submit to create the scheduled task.
You will need to click on the green check-mark icon to run the scheduled task, which actually executes it and grabs our shell. If it has problems with remote file you will likely get a warning message of some kind in admin panel, edit and retry. Upon success, you can point your browser at the path you uploaded your shell to. In most cases Cold Fusion is running on Windows system with full NT AUTHORITY/SYSTEM privileges which means you pretty much own the local box now :)
If you find that 'cfexecute' is disabled and blocking your CFM shell from working properly, you can simply re-enable it from the admin panel since you already have access :)
NOTE: JSP is only supported on Enterprise versions of ColdFusion. You can actually determine Enterprise vs Standard by requesting a non-existant .jsp file and judging how the server responds!
You have now successfully shelled a Cold Fusion Server at this point and in most cases have admin privileges to do what you want (create new user, add to admin group, add/enable RDP, enjoy new RDP). In the rare *nix instances your likely running as nobody or another non-elevated user so the usual post exploit game plan still applies if you want to takeover the whole server (i.e. root the box). Hope you enjoyed this first part of this series, second part to follow shortly....
Until next time - Enjoy!
I will start this series off with the most common vulnerability first, which is the known Local File Disclosure, or LFI, in the 'locale' parameter (also referenced under: CVE-2010-2861). The LFI vulnerability allows us to read files off of the target system, without any authentication. The neat thing that makes this one different than most LFD is that if we play our cards right we can use this vulnerability as a foothold to further penetrate our target, read and see. We first try to find the admin page, as it is the most commonly vulnerable page, but certainly not the only one. You can typically find it at one of the following locations:
- /CFIDE/administrator/index.cfm
- /CFIDE/administrator/enter.cfm
- /CFIDE/componentutils/index.cfm
- /CFIDE/componentutils/login.cfm
Knowing the version is important as it helps us to determine the appropriate path to use to try and turn this LFD into something useful. Now if you know the full path to the CF '.properties' file then you're in business as it contains the CF admin password hashes. The list of possible paths worth trying are as follows:
- v6: locale=..\..\..\..\..\..\..\..\CFusionMX\lib\password.propertiesen
- v7a: locale=..\..\..\..\..\..\..\..\CFusionMX7\lib\password.propertiesen
- v7b: locale=..\..\..\..\..\..\..\..\opt\coldfusionmx7\lib\password.propertiesen
- v8: locale=..\..\..\..\..\..\..\..\ColdFusion8\lib\password.propertiesen
- vJRun: locale=..\..\..\..\..\..\..\..\..\..\JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\password.propertiesen
NOTE: In version 6 & 7 encryption is not enabled by default, although i never seen a server which did not encrypt the password in hash form.
Now you can crack the password hash and login with clear text pass or we can use a little trick to bypass authentication requirements by using a pass-the-hash technique. The login form uses a bit of JavaScript magic to actually create a HMAC hash from the admin password hash and a salt value which is changed every 30 seconds. You can find this salt value by simply viewing the source code for login page, look at second occurrence of the term 'salt' or review form input details. Due to this, we pass the hash and generate the HMAC hash on our own and submit - simulating a successful login! You need to grab the salt from source:
OK, so you now have Password hash and salt in hand....
Here is some code I whipped up to accomplish this task of logging in real quick for you to get the authenticated cookie.
Quickly enter the needed details and run it. If successful, you will have the authenticated cookie presented to you in terminal, like so:
Now once you have the authenticated cookie, you're pretty much in. You can use your favorite cookie editor to load up the new 'CFAUTHORIZATION_cfadmin=<SOMEVALUEHEREONSUCCESS>'. Once loaded you simply refresh your browser and your now logged into the administrative panel for Cold Fusion. Now to try and get a shell up on the server....
If you already know the server path to web facing directory then you can move forward, if not you can check the 'Mappings' link on the left under 'Server Settings'. This will show a mapping of all paths for CF, by default the /CFIDE dir should be mapped giving us a usable path in the majority of cases. Mappings page looks like this:
Once path is known we will move to the 'Schedule Tasks' page located under 'Debugging & Logging' on left menu links.
Now you simply point the task scheduler at your remote CFM/JSP shell hosted on a server you control, stored in txt format like an RFI attack payload. You can schedule for a onetime event, it will default to current time so no need to calculate things if your on different time zone :) If you need a username/password to access the remote shell file source then provide as needed in appropriate fields of task scheduler. The next is key, mark the option to 'Publish" to true so it saves the results to a file (i.e. grab our remote shell source, and save to executable). You then provide it with the full path to where you want to write to. In the majority of cases /CFIDE is writable, otherwise poke around or generate errors in SQL queries on site to get path (standard Full Path Disclosure rules still apply here). When you form is all setup you can submit to create the scheduled task.
You will need to click on the green check-mark icon to run the scheduled task, which actually executes it and grabs our shell. If it has problems with remote file you will likely get a warning message of some kind in admin panel, edit and retry. Upon success, you can point your browser at the path you uploaded your shell to. In most cases Cold Fusion is running on Windows system with full NT AUTHORITY/SYSTEM privileges which means you pretty much own the local box now :)
If you find that 'cfexecute' is disabled and blocking your CFM shell from working properly, you can simply re-enable it from the admin panel since you already have access :)
NOTE: JSP is only supported on Enterprise versions of ColdFusion. You can actually determine Enterprise vs Standard by requesting a non-existant .jsp file and judging how the server responds!
You have now successfully shelled a Cold Fusion Server at this point and in most cases have admin privileges to do what you want (create new user, add to admin group, add/enable RDP, enjoy new RDP). In the rare *nix instances your likely running as nobody or another non-elevated user so the usual post exploit game plan still applies if you want to takeover the whole server (i.e. root the box). Hope you enjoyed this first part of this series, second part to follow shortly....
Until next time - Enjoy!
source : http://kaoticcreations.blogspot.com/
great .. can we also do a log poisoning attack
ReplyDelete?