@JB, that's indeed a gnarly one. I found I'd been hit by it as well (also on Dec 25, in my case at 12:31am). Happy freakin' holidays. 😞 So thanks very much for for sharing this news.
I do have answers for you, and also info for others who may come across this.
How it got there:
As for your not having found any trace of it, I suspect it's because you're looking in the IIS logs for some one site--but it must then have gotten in on another site (either one you're not considering, or one for which you're not doing logging).
I found a request for the following: /CFIDE/adminapi/administrator.cfc and then later a post to /CFIDE/Administrator/scheduler/scheduleedit.cfm. I won't share details beyond that, for now, to avoid this being exploited by others. But anyone looking to see how/when this h.cfm file got in there should look for that.
As for the http.log entry you saw, that was the result of the scheduled task (cfprobe) they created. The task called that URL, and the result was saved to this h.cfm file. So the http call was not "sending" info, it was "getting" it.
At a minimum, you (and anyone reading this who finds that h.cfm file) will want to delete it as wel as the scheduled task if it's there. (I could see in the IIS logs that the exploit tried to do that itself, to remove its tracks, but I found the task was still there, created that day.)
Protecting against this attack (for other readers), Step 1:
As for how others reading this can protect themselves against the attack, as the first link above shows, they're using an exploit in the Admin API. The bottom line protection for this is one that is often shared: lock down access to the CFIDE/administrator AND ALSO the CFIDE/adminapi directories. Whether you do that by IP address or by requiring other than anonymous authentication, you want to prevent unfettered access. You don't want to lock down the ENTIRE CFIDE, as there are other folders in there that do generally need to remain open for public access.
This is all discussed further in the lockdown guides available for CF 8, 9, and 10. Just google for that, or see the recent discussion of it in the Adobe CF blog, which is linked to on the right side of this page.
Now, someone may say, "so Charlie, you didn't have your CFIDE admin directories locked down"? Well, I did, at least for what I thought was the only publicly accessible site on my server. But it turns out I had a CFIDE in another site, the "default site".
Let me share a tip/warning about that: many people may assume their "default site" (if not bound to any domain) is accessible then only via localhost. But note that most times, it's also bound to all IP addresses. So if a hacker knows your IP address (or any that your server will respond to), or if somehow some domain resolves to your server's IP address, then this default site will respond. I have now locked mine down (and again, there's more on this in the lockdown guides).
Beware too that on CF10, if you use the web server config tool and set it to connect CF for "all sites", the tool adds a CFIDE virtual directory to every site. Again, someone may not think of that, and may not think to lock down the admin directories in each of those sites. Forewarned is forearmed.
Update (added since initial posting): Finally, note that there's still another way that requests to the CFIDE/adminapi (and /administrator) directory might work, even if you have no such real or virtual directory defined for a site. See the discussion in the "part 2" blog entry that I refer to also in my additional comments below.
Protecting against this attack (for other readers), Step 2:
Of course, one should also be sure to implement all the security hotfixes available for their version of CF, as also linked to on the right side of this page and also discussed in the lockdown guide. I was running 9.0.2 without the latest two security fixes (though they're there now). I've not yet confirmed if I can recreate the exploit now Adobe has since confirmed that the exploit could happen even with current security hotfixes in place (but again, having locked down the adminapi directory, that's the more important point of prevention, for now.)
Determining what was done:
As for determing what, if any, the hacker may have done, one should look in their web server logs (if you've have enabled them, I hope) to find any references to that h.cfm file. You may see some that get a 404 (made before they succeeded in getting it in place). But then once it's in place you may then see other calls to it, perhaps indicating a fuseaction in the query string showing what it was doing. Not all the things that can be done with the tool result in a fuseaction, though. It may just do a post back to itself, as I find for the things on the page that are form submissions (the command feature, the search feature, etc.) But the tool always calls itself, so look for that h.cfm file in your logs. (Of course, at some point the hacker may realize we're on to them and change the file to a new name.)
Determining what can be done:
While any who get hit with this should delete the h.cfm file if it's there, you may want to move it somewhere else (in a protected directory) to explore more about what it can or can't do. I don't mean so much to "discover how it can be used" (the code in the file is open, not encoded or precompiled), but to find out what if anything could have been done with it on your own server, depending on what protections you may have in place.
For instance, I found that on my server, the feature it tries to use to obtain datasources did not work. The drop-down of DSNs was never populated. That may be because of other security fixes already in place (9.0.2 does contain all those that existed for 9.0.1 as of the time 9.0.2 was created in May).
In fact, I found that the hacker only hit the h.cfm page one time, and not again (even over the 3 days since). Perhaps they felt that since they couldn't get that info, they weren't as interested in trying to use it further. That said, many other features of the hack tool did work, so again it's very important that people remove it, and also do what they can to prevent it hitting them (lock down those adminapi and administrator directories!)
Conclusion:
I'll continue to research and will decide how best to share my findings (whether here, in a blog entry, or just with Adobe). Of course, there's always a balancing act in sharing too much info publicly about an exploit. It can give info to others who might also leverage the exploit, and of course it also lets the bad guys of this one know we're on to them. But that was true as soon as you posted this, if they may find it.
Of course, I do thank you very much for sharing it. (And I realize someone from Adobe may even remove my entry here, if they feel that it shares too much info already, though I've tried to be careful to share only info on mitigating/analyzing the problem, not leveraging its exploits.)
/Charlie (troubleshooter, carehart.org)
1 Correct answer
25
Replies
AdChoices