[Looking for Charlie's main web site?]

Part 3: Adobe hotfix released for "Serious security threat for ColdFusion servers"

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Adobe has come out with a new security hotfix for a very serious attack on ColdFusion servers which had hit many (perhaps most) CF shops over the past couple of weeks, and it's vital that all shops apply that fix. (Even if you think you've protected yourself in other ways

There is a new Adobe CF blog entry pointing to the new hotfix, and I point that out rather than the technote for the hotfix itself, because as often is the case, there has been some useful discussion related to applying the fix. Indeed, there's a warning I've shared there about a problem (hopefully temporary) with the hotfix file for users of ColdFusion 9.0.2. (Update: the confusion about 9.0.2 is resolved. The technote has been corrected. See the comments in the Adobe blog entry for more details.)

Users of ColdFusion 10, 9.0.2, 9.0.1, and 9.0 should certainly proceed to implement the fix.

I address several questions and other observations about this hotfix below.

"Where can I learn more about this hotfix?"

Well, the security bulletin for the hotfix has more information, as does a security bulletin that Adobe posted last week and has updated today. And the bulletin points to a technote which has some more details and the specific steps for applying the hotfix.

Also, some readers will know that I posted two recent blog entries with information about the issue when it was first discovered two weeks ago (before any hotfixes or bulletins had been offered):

Of course, my goal with these was not to propagate information that could lead others to exploit the vulnerability, so I had to be careful in what I shared. Also, more has been learned about the issue since then. In particular, note that besides blocking public, unfettered access to the CFIDE/adminapi and /CFIDE/administrator directories, it's become clear that you should also now protect the /CFIDE/componentutils directory (used by the CFC browser which has been in CF since CF 6.)

As I discuss in those entries, the best thing is to make it so these directories either are only accessible on the local server running ColdFusion, or you require some additional web server authentication (besides the ColdFusion Administrator password).

I'll offer still more information and post mortem in a planned (at least) Part 4 blog entry.

"What if I protected those folders already? Do I still need to bother with the hotfix?

I would absolutely recommend that every CF 9 or 10 shop apply the hotfix. As I discuss in the part 2 entry above, there is a way that a site could still expose these directories EVEN THOUGH YOU DO NOT HAVE ANY FOLDER OR VIRTUAL DIRECTORY FOR CFIDE in the site. Adding the hotfix (well, applying it properly) will ensure that the vulnerability cannot be exploited if someone can get past your web server defenses.

Also, since hotfixes are cumulative, applying this latest one will also give you the benefits of the previous ones, of which there have been several for CF 9 and 10.

(I don't see that as a "problem", but rather as Adobe being responsive to close holes when they are found. All software, and especially all web-accessible software, is susceptible to vulnerabilities, as even the recent java browser plugin scare showed.)

"I'm on ColdFusion 8. When will Adobe release a fix for that?"

Sorry, friend. Adobe no longer formally supports ColdFusion 8, as of the release of ColdFusion 10. This is the long-standing pattern for ColdFusion support. This is another good reason to consider moving to ColdFusion 9 or 10. (If you may wonder, "what are the changes in CF10?", as Jimmy Durante used to quip, "I gotta million of 'em". Ok, how about 200? See Charlie Arehart's Ultimate List of 200+ New #ColdFusion 10 Features.)

"I'm running CF 9.0.2. Why shouldn't I apply the fix (yet)?"

I mentioned at the opening that those running ColdFusion 9.0.2 should beware applying the new hotfix.

Sadly, at least in these first few hours since its release, the cf902.zip file pointed to in the technote does NOT included a needed web-inf.zip file that is referred to in the instructions. I fear that many people, who by now may have applied these sort of hotfixes dozens of times, may not even read the note carefully enough to even notice that they are skipping a step.

It's not clear what the implications would be if a shop put the hotfix jar and CFIDE updates in place (which ARE provided in their respective zip files) but did NOT put the updated web-inf files in place. So until Adobe updates the hotfix with the missing zip (again, web-inf.zip, which should be found in cf902.zip), it seems best for 9.0.2 shops to not yet apply the fix (as much as it pains me to say that.) As always, forewarned is forearmed.

When this issue is corrected, I'll edit this entry to strike out this section.

"I have CF10 but don't see the update in the CF Admin. Where can I download it, and how would I apply it?"

This seems to happen for some people with each update (fortunately, it doesn't seem to happen to most.) There are three ways to answer that, with increasing generic usefulness for future fixes:

  1. First, if you really JUST want the URL to download this one hotfix, it's http://download.adobe.com/pub/adobe/coldfusion/hotfix_007.jar
  2. Second, if you would like a URL to be able to see all the CF10 hotfix jars, there is a URL for that. Note, though, that it's an xml feed, so you may or may not see the results easily, depending on your browser: http://download.adobe.com/pub/adobe/coldfusion/xml/updates.xml
  3. Finally, if you want instructions on how to apply that hotfix manually for CF10, or want a LOT MORE information on the CF10 hotfix mechanism in general, see this excellent resource available as an Adobe CF Blog entry: https://coldfusion.adobe.com/2012/12/coldfusion-hotfix-installation-guide/. I like to refer to that as "50 faqs on the CF10 updater". Great job, Krishna.

"I get an error, 'Failed checksum verification', while applying the hotfix on CF10

I'm repeating this "old news" because I suspect there may be lots of shops who may for the very first time be applying any of the CF10 hotfixes. The good news, again, is that they are cumulative, so you'll get all the updates by applying just the latest.

The bad news, if this is your first attempt at any CF10 updates, is that you will get this error, '"Error occurred while downloading the update. Failed checksum verification', because of a very unfortunate problem at adobe that happened right after CF10 came out (though it's not related to CF10, and it's not at all a "CF bug" or "mistake by the CF team").

The solution is simply: you need to apply the "mandatory update" first, and THEN apply any other CF10 updates.

The problem was an issue with Adobe certificate (used for verification of automated downloads for all Adobe software, not just CF). It just happened to have have hit just after CF10 came out, so it looked to many to be a "CF problem".

For more background, see the discussion, especially the comments, in the CF Blog entry on the mandatory update, from the timeframe when it was released.

"I'm scared/annoyed by these security breaches. Why hasn't Adobe done more to protect CF?"

We've been hearing this one a lot more lately. To such folks, I would repeat what I said in the previous two blog entries: Adobe HAS given you the information you need to make CF more secure, in the lockdown guides that have existed for CF10, CF9, and CF8.

Some of the challenges you face are things that they cannot reasonably protect for you, so the guides discuss added measures that you can and should consider. The sad truth is that many who knew about the guides still ignored their recommendations (the old, "it won't happen to me" syndrome), while those who did, and who where hit by the recent exploit, found that either the exploit could access nothing, or it exposed so little that the hackers moved on. There is specific evidence one can look for in their logs to confirm that, as I have done with many folks over the past couple of weeks. Again, I plan to share more about that in a part 4/post mortem entry.

Second, and as important, note that CF10 has specifically been updated for improved security. In fact, one aspect of the recent exploit indeed prevented from working on CF10 servers. There are many aspects of CF10 that are just more secure out of the box, and still others are made more secure by your choice (offered during installation) to enable what's called the "secure profile". For more information, see the CF 10 documentation as well as this article from CF security czar, Shilpi Khariwal: Security improvements in ColdFusion 10 , which itself ends with pointers to the docs and still other resources.

"Can't I just get someone to help take care of this stuff for me?"

You can, indeed. There are two resources I'd like to point out, first my own services, and those of others.

My own consulting services

I didn't mention this in my first two entries on this, because my focus really was just to get the info out ASAP, but I do provide CF server troubleshooting services as an independent consultant. I can help folks remotely (yet no need to provide me remote access), generally very quickly (many problems can be solved in less than an hour), and on-demand (or scheduled). For more on my approach, rates, and even my satisfaction guarantee, see my consulting services page.

Indeed, I was so busy helping my clients (old and new) the past week+ that I just have not had time to write that post-mortem entry, but I hope to do so this week. With the release of the hotfix today, though, I really wanted to get this part 3 out. And as you can see, these are never just quick notes (and certainly far more than could ever be communicated in a tweet, though I did tweet about the hotfix earlier today, as soon as I saw it. Different media for different messages.)

In fact, if I'm ever too busy, or unavailable, or you may want to consider others, I don't begrudge that. In fact, I'll even point you to them, whether for security or general troubleshooting.

Services from others

When it comes to CF security consulting, I point people to Pete Freitag and his company, Foundeo. He's become the go-to guy in the CF community for consulting, and since it's such a specialized area, I have tended to just point people in his direction when they wanted security consulting. (Pete also write the CF 9 and 10 lockdown guides.)

That said, I've learned in this experience that I can certainly help people get a LOT closer to being secured than if they've done nothing at all. And I can certainly help them. I liken it to the difference between seeing a neighborhood clinic and seeing a specialist. The former can certainly help with a lot of important needs, but there's no question that there are times when you'll want to bring in the specialist. :-)

Beyond Pete, I'll note as well that I even have a resource on my site pointing you to still others who can help. See the category CF-oriented Troubleshooting Consultants in my CF411 catalog of over 1700 tools and resources for CFers. Pete's on that list of consultants, too! :-)

Some might call it crazy that I'd share links to my competitors. Others might call it confident. I prefer to let my customers/prospective customers decide, and you can read what they've had to say. :-)

A free CF security scanning service: HackMyCF

Separate from my mention of Pete and Foundeo above, let me point out also that they offer an excellent free service called HackMyCF, which can help you at least assess how much help you need (how vulnerable you are to many important CF security concerns), and can provide you info you need to address the problems yourself (or have someone else help you).

I had mentioned it as a comment in the Part 2 entry, but had not promoted it in the main entry because at the time it did not identify this particular exploit. But Pete has since updated it, so I do want to point it out again.

With the service, you point it to your site, and it will (from the outside) try to detect various vulnerabilities. It's not performing a full-scale scan of your application; it's looking for several high-level things that are often the crux of CF security problems.

Indeed, even though it did not (then) detect this recent vulnerability, it would at least have pointed out any of the many other opportunities for improvement (including many in the lockdown guides), which again for those who had applied them, they might have at least exposed less information if the hackers did exploit this vulnerability.

And if you really like what the HackMyCF service does, note that there is a commercial version of the tool, discussed on the site, whereby you place a probe (a simple CFC) within your site, which then he is able to call, to check on still other vulnerabilities that simply can't be identified "from the outside".

So even if you won't read the lockdown guide, or won't hire anyone to help you, do at least run Pete's free tool against your site. It's fast, free, and won't cause any harm in running.

That said, he does require that you provide an email with a domain on the site you want to test, as a way to confirm you really do represent that site. The email is also used to email you the report, with recommendations and help. You won't be spammed. Don't delay using the tool.

The end (well, of Part 3). More to come

Phew, lots to cover, lots to consider. I think this event, though painful to some, has been a real wake-up call, and for that, we have to see the silver lining in the cloud.

I may come back and move some of these sections into their own blog entry, as some deserve to stand on their own, and may be missed by those who won't wade through all this when looking for that specific question to be answered. We'll see. If I do, of course I will change the appropriate section here to point to that new entry, in context.

Finally, look for part 4 in this series to come soon, I hope.

And let me know your thoughts on the above, and this whole incident. Again, there are pluses and minuses, on all fronts (the bad guys, Adobe's response, my entries here, and so on). Hey, it's a fallen world, which is ours to live in, and to find hope, solace, grace, and fellowship where we can.

"As always, just trying to help."

(I was just going to close with that, unquoted, but I do find myself writing it a lot, to clarify where I'm coming from even when saying things some may not like to hear or might misconstrue. I guess if I had to have a catch phrase, it's not a bad one to adopt!)

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Comments
Hi All,

CF9.0.2 doesn't include WEB-INF.zip . Thank you Charlie for pointing it out .

There was a mistake in instructions for ColdFusion 9.0.2. The correct set of instructions are as follows -


ColdFusion 9.0.2

1. Download CF902.zip and CFIDE-902.zip. Extract both zip files.

2.In ColdFusion Administrator, select System Information page by clicking the icon "i" in the upper-right corner.

3. In the "Update File" text box, browse and select hf902-00003.jar located under CF902/lib/updates.

4. Click Submit Changes.

5. Stop the ColdFusion instance.

6. Go to {ColdFusion-Home}/lib/updates (for Server installation) or {ColdFusion-Home}/WEB-INF/cfusion/lib/updates (for Multiserver and J2EE installations) directory. If hf902-00001.jar, hf902-00002.jar exist, delete it. Otherwise, ignore this step.

7. Go to {CFIDE-HOME} and take a backup of CFIDE folder.

8. Extract all the files in CFIDE-902.zip to merge in the web root directory that has {CFIDE-HOME} folder.

9. Start the ColdFusion Instance.

10. If there are multiple instances, repeat steps 2 through 9 for each instance.

These instructions are also updated on technote.

Thanks & Regards,
YASHAS RATTEHALLI ( ADOBE COLDFUSION TEAM )
# Posted By YASHAS RATTEHALLI | 1/15/13 11:23 PM
@YASHAS Thanks so much for the update. I also saw the comment from Shilpi on the CF Team blog, and I have now updated the blog entry here to remove my warning about this issue for 9.0.2, as well as have sent out a tweet retracting my warning there, and of course I have left a note of thanks for her clarification on that CF team blog entry.

Was all in the spirit of making sure things were clear and correct, given how important this fix was. Glad to see it so. :-)
Well, I tried the hotfix on my local dev machine and no problem. I then went to our production server and it appears that something isn't loading properly, as the update page isn't tabbed and I trying to download the update doesn't do anything.

So, I uninstalled the update on my dev box and tried running the .jar update manually, with the intention of doing that on production.

I now have a kaiboshed dev box, which is creating a system error log event of "cannot find the file specified"

Any thoughts on best updating the production box when the admin interface isn't working without just running the .jar?
# Posted By Garry | 1/17/13 6:04 AM
@Garry, sorry for the delay in responding. I can't always stay up on the blog comments every day, because it's just one of many ways that I help people throughout the day.

There can be any number of possible explanations for the problems you are seeing, both with respect to the prod box and the tabs not appearing in the CF10 updates page, and with the dev box and the command-line JAR not working.

I'll give it a shot, especially in case they may help others who may find this some day, even if they may not necessarily all apply to you (but I think the key points will).

1) First, for the failure to see the tabs on the prod box, I suspect it's that there's a problem with the browser not getting a response for the calls made within the page to show those tabs. The code calls into the /CFIDE/scripts directory.

So before going any further, have you done anything to block the entire /CFIDE directory? Many people over-reacted to this recent attack and did just that. I warned several times in my entries here not to do that, but of course many are not reading these, or missed it if they did read it.

You don't want to block /CFIDE/scripts because that's used by many things (CFML tags like CFFORM and all the Ajax tags/functions), and it's used by this CF10 updates page, because it uses tabs, as created by the CFLAYOUT type="tab" tag (at least, that's what I discern from looking at the web server request logs when this page is called).

So as a simple test, on your server where you "don't see the tabs on the updates page", what happens if you browse:

/CFIDE/scripts/ajax/resources/ext/images/default/tabs/xd-tab-strip-bg.gif

By this I mean, once you have your CF Admin on screen, modify the URL to remove the /CFIDE/administrator/index.cfm and replace it with that line above. Does it work, returning an image? Or do you get some error? It could be, again, that someone has inappropriately blocked all access to the /CFIDE/, thus blocking the /CFIDE/scripts folder.

Or maybe there's something that has caused this or other files deep in that folder structure to not be there.

Note also that someone on your CF Admin may have changed the scriptsrc location, so that CF is now building the HTML for that page to use a different path for these files. So if you do a view source on the frame (in that Admin page), find a line near the top of the page in a line that should look like this:

script type="text/javascript" src="/CFIDE/scripts/ajax/package/cfajax.js"

The starting folder for path listed in the SRC attribute may vary for you. Anyway, whatever value is in that src attribute, what happens when you browse that, as above? In this case, for this cfajax.js file, you should be shown or prompted to download a javascript file. If not, if you get some error, then again it says that's there's something wrong with either your web server or CF configuration.

One other related tip: it can be helpful (whenever any web page's interface if not working as expected) to use a tool to help you identify if there are any errors on the page (such as missing files for images, javascript, css, etc.) For identifying such problems, it's best to use one of many developer tools, either available within the browser or as an add-on. See a blog entry I did on that last year, http://www.carehart....

If that is not enough to help you, or if it's not that, you can write back but I can't promise to respond here today (and would not respond tomorrow, Sunday), but if you contact me for support (www.carehart.org/consulting) then I should be able to respond today. More on that in a moment.

2) Second, as for your problem when you tried to run the update jar from the command line, when you say "system error log event", I'll assume you mean an entry in the Windows Event Viewer, specifically in the system log. That often happens when people try to change their JVM (the java.home line in their jvm.config or the corresponding "java virtual machine path" field in the CF Admin "java & jvm" page. Did you by any chance make that change before restarting the instance after you'd applied the hotfix?

Or if that's not it, rather than focus on the Windows event log, look instead at the coldfusion-out.log which you'll find in the [cf10]\[instance]\logs directory (if you only have one instance, then it's [cf10]\cfusion\logs). That log holds the equivalent of the CF "console log" information, since there is no "console" because you are starting CF as a service (which we can assume because of the error you report happening in the Windows Event Viewer).

The coldfusion-out.log should have information reflecting more details on what's happening during the startup of CF, which should explain why it failed to start.

One other problem could be a permissions issue. For instance, perhaps you or someone there changed the account under which CF is being started in the Windows service (using the "Log on" tab in the Service's properties). Well, if you run the update (the jar) from the command line as a user that differs, or does not share the same privileges, that could cause a problem.

For folks who leave the service running as "System" (the local system account), they can get into trouble running the jar from the command line if they don't start that command prompt with administrating privileges (even if they are a user in the Windows "administrator" group).

So you may want to try it again, by launching the command-prompt using a right-click and choosing "run as administrator". Then run the jar as you did before.

Finally, if none of that helps, then with respect to the application of the update, note that there is a log created in the [cf10]\[instance]\hf-updates\ directory, within a folder named for each update applied.

3) I do hope some of that may help. Sorry it wasn't a quick answer, but as I said at the outset, you could have any number of problems. And some people reading this may have ones that you don't, but they may find this some day in searching for a solution.

<CFSoapBox>

Of course, some people reading this will sniff that I can't seem to say anything in less than a paragraph! They may even assert that I make troubleshooting seem "complicated".

I would counter (since this is all I do all day each day, helping people solve CF troubleshooting problems) that I've simply learned that few problems are simple.

As we've seen above, there can be many interrelationships of things, even in one seeming "problem and its solution". There are also different ways that you or someone else on your server may have changed things which could be causing your problem.

Rather than just say "try this", I share the details to try to help you solve the problem, diagnostically, which is what I do when I help people in a consulting session.

It's like the difference between giving someone turn-by-turn directions, and giving them a map. With the former, if you miss one turn, you might go a long time before realizing it and get horribly lost.

I see that happen a lot with people when they try to solve problems with twitter-length answers or one-paragraph blog entries, forum messages, or mailing list messages that they may find, which "seem related to their problem".

So whether I'm offering possible solutions to someone's problem in a blog comment (or forum thread, or list message) or in a consulting session, I tend to offer the additional detail because my experience tells me that most people would benefit. For those who don't, well, I guess the help is not for you.

</CFSoapBox>

Anyway, let me conclude by saying that if these challenges are important and time-sensitive for you, I'd recommend that it may be more effective for us to work together looking at your machine online, and talking on the phone. You can learn more about my troubleshooting services at www.carehart.org/consulting/. I may or may not get back to any reply you offer today (and won't see any tomorrow, Sunday.)

Again, hope some of this helps. I'll look forward to feedback from you or others on any of that (the technical discussion or the soapbox), as I may consider turning either or both into a blog post of their own. :-)
I had meant to make mention in the last comment of also using any of the many cool browser developer tools to observe the communication between the browser and server, which would also have helped identify the failing requests for files within the cf10 updates page and the failing "tabs" that Garry reported.

I just tweaked that last comment to add a mention of that, in context (rather than adding it here).
Charlie,

Thank you for your incredibly detailed input!

I have to confess that I fell into the "knee jerk" category, and had placed a request filtering rule on the /scripts directory, mainly because our site doesn't use any of the CF Ajax functions. Once I'd removed that everything was back to normal.

Thanks again.
# Posted By Garry | 1/21/13 5:47 AM
so I patched with the latest patch and seem to still got hacked...any suggestions?
# Posted By mike | 4/8/13 2:17 PM
Mike, I can think of at least one way, yes. And I discussed it in the Part 2 entry in this series (linked to above). See specifically the section there, "Caution: Don't be lulled into a false sense of security/confidence!".

Also, you say you "got hacked", but you don't give enough info for us to know that you were hacked by the same exploit described here (and addressed in that hotfix by Adobe).

Then too, you refer only to "the patest patch". It's not clear if you also undertook the steps to modify your web server configuration for the vital CFIDE/administrator, CFIDE/adminapi, and CFIDE/componentutils folders that were key in this hack (and could lead to still others). Even if you did, see my first point in the comment here about how one even doing that may not do all they need to.

Finally, beware also that in "applying the patch" you may well have simply made a mistake, and therefore not have been protected in the way you assume. I have seen that happen very often, and in fact I blogged substantially on it a couple of years ago. You should check that out as well (and don't let the title fool you, if you don't feel that your CF or admin is necessarily "busted"):

http://www.carehart....

And if you feel like there's just too much in all these entries for you to track, note then also the section above (in this Part 3 entry), "Can't I just get someone to help take care of this stuff for me?" :-)

Hope that helps.

PS To others who have commented in recent weeks, again I've been overwhelmed. I will get to them. I just had a moment to reply to Mike here, with what seemed especially important information to re-assert.
Here are more details that we got from the server admins..

When I checked the server, I found 20+ cmd.exe executables running from under the ColdFusion jrun processes. These executables, running as NT\System were executing a number of exe files loaded to the base of the OS drive. At this point, the server is considered to be compromised. We recommend killing off the executable processes and migrating off this server asap. As the server is system-level compromised, we not not offer a route at the software level to fully clean the server as it would be impossible to clean the OS 100%.
# Posted By mike | 4/9/13 10:34 AM
They also found a file called wtf.exe. I guess what I am curious about is if they potentially got in a different way and not by this way at all?
# Posted By mike | 4/9/13 10:37 AM
@Mike, your first note simply confirms you were compromised, yes. I'm not seeing if that's supposed to be a reply to my response to your note yesterday. As for your second note, yes, that file could have gotten in there this way or others. It's not always easy (or even possible) to discern how such a bad file got in.

Bottom line: as you say, you would do best to reinstall the OS and all else. Just be very careful that in doing that, you don't bring along the same bad files, which could be sprinkled anywhere throughout your file structure, including in executable web directories (or not). So do beware even in bringing over simply your "web application".

If you have a local dev or test copy of the code, you could compare what's in prod to that, and perhaps identify any other unexpected files. Similarly, if you have source control or backups, you could compare the current files to a point in time in the past (whether days, weeks, or months ago).

I do realize that doing that will be harder if you have yourselves put lots of new files on the server since then, but at least with a comparison you can eyeball the differences and maybe recognize what you've done versus what others (bad guys) may have done.

No question, it stinks when you've been compromised. It's just like when one's own personal privacy is compromised. It can take a long and painful time to get everything back to normal.
Well, I was compromised around Christmas, and discovered it in early Jan, and it's been a battle ever since. I locked everything down thanks to Charlie's blog posts in Feb, but still had files changed. Turns out there were multiple files uploaded all over the site. They were smart - they were dropping them in folders that hadn't been modified in years, and they were putting old modification dates on things so I couldn't just look at a folder and know something new was in it.

After reading Mike's posts I realized I probably had malware on there as well. Yup, a whole bunch of it. I also discovered Kaspersky Security Center 9 should definitely NOT be installed on a machine running ColdFusion (it totally borked CF and took hours to fix). Managed to get the malware removed (I hope), and locked the machine down further.

We now have CF running under its own account, and it's limited to the web directory. Also, we've limited the folders and files it has write access to, so even if they gain access in the future, they shouldn't be able to upload or modify anything.

Such a frustrating time.
# Posted By GordL | 4/19/13 6:53 PM
Thank you for the post. I was hit with h.cfm. Once you find it in the logs, you can note the IP address and search again on that IP address for activity. 37.235.49.168 is the IP address of all the attacks. Curious if others found the same.

I renamed cfide as an added precaution after applying the fixes and following tips to make more secure. Haven't found a problem with that yet, it was an old tip and then name it back while using. Just another layer.
# Posted By Bob Whitman | 4/19/13 7:18 PM
Well, my tale of woe isn't over yet. Got hit again last night, even after the changes I made the other day. Turns out they created an account that had admin permissions, so they still had full run of the server.

I was also hit by at least two groups since Christmas, as I found some very different templates that did the same things. Some were encrypted templates, some weren't. What a mess.
# Posted By GordL | 4/20/13 8:59 AM
Catching up on a couple of old comments here:

@GordL, sorry to hear your tale of woe. Sadly, there were many CFers in the same boat. Hopefully they took heed of the protections discussed in these 3 entries and/or the Lockdown Guide(s) to protect themselves going forward. But of course, once the bad guys are inside the house, locks on the windows are of less value (for those, but still warranted to keep other bad guys out).

@Bob W, let's not leave the impression that everyone would see that same IP address. Not only would they not (I saw many others, even on a single server), but I even saw requests in sequence for different files (as part of the break-in) where the IP address was changing on each request. The bad guys will do all kinds of things to try to shake us off their trail.

Finally, and most important (to your comment), I would really beware the idea of just renaming the CFIDE to something else and "renaming it back while using it", if by that you mean the CF Admin. I repeated this several times in the entries, and I will one more time:

Don't assume that the CFIDE is used only for the CF Admin. It's not. Many CFML tags and functions generate HTML that then tries to link back to the CFIDE/scripts, for example. You may find in your web server logs requests to files in /CFIDE/scripts, as regular users of your apps, which may fail with 404 (or 403) errors.

In that case, you need to either leave that CFIDE/scripts open or change to using an alternative CFIDE scripts location, as supported by the CF admin and as discussed in a blog entry from Pete: http://www.petefreit...
A client we don't host, but do develop for and help out when she needs it ran into this just yesterday on her CF9 server that hadn't been updated. Luckily, it's a server with only one website, and it appears that the hackers really only wanted access in order to send emails out from the server (which is not great, but at least they didn't damage the server or the site!). Also luckily, they were stupid enough to use an existing run-once-a-minute scheduled task instead of creating a new one, and they also left it changed instead of changing it back once the script was on the server - the client noticed when that task wasn't working.

Thank you so much for the detailed information that helped me figure out exactly what happened and what they did and how to keep it from happening again!

Was there ever a part 4 to this?
# Posted By SC | 9/6/16 11:39 PM
SC, thanks for the comment. Great to hear that it was helpful.

It is indeed a shame that many shops on 9 or 8 still have never applied the needed security updates (or the later CHFs that included them). In fact, I have helped two such shops in just the past couple of weeks to apply them (that in addition to dozens I've helped with updates to 10, 11 or 2016 in that time, thankfully).

And as for a part 4, I know I said in the post I had one planned, I just never got around to doing it. :-( But I do still have the notes! Might be worth a follow-up, even this many years later (because of the need of reminder for some, especially!)
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting