Coldfusion 2018 Lockdown Tool failure

[JD-16]

Hi folks,

I am hoping someone can point me in the right direction to fixing a problem I am having with the lockdown tool. I have been following the CF2018 lockdown guide, I installed Coldfusion 2018 developer edition on a Server 2016 OS.

• I applied hotfix 3, only weird thing I found was that the ODBC server service would not start after.
• I checked the hotfix log and found no errors.
• Spent of a ton of time researching that problem, found there was issues in previous versions of CF, realized I don't have any ODBC datasources to worry about, so I set the ODBC Agent and ODBC Server service to be disabled following guidance from several of those threads.
• Successfully logging into CF Administrator. Followed the guide.
• Ran the lockdown tool following the guide, only major change's was that I selected no to the coldfusion update since I manually updated it, and I had the lockdown tool create the ColdFusion Runtime User for me. In checking the lockdown the log, I found it successfully created the user at one point, before it reverted several of the changes it made. This tells me the windows administrator account password should have been correct.
• The lockdown failed, relevant log entries below:

I am hoping someone can shed some light on what may cause this failure. Thanks in advance for your help.

JD

2019-05-31 09:26:45 INFO  - Change Permissions of ColdFusion file system: Error Logs

2019-05-31 09:26:45 INFO  -

2019-05-31 09:26:45 INFO  - Permissions changed for the user: IUSR for the path: "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts"

2019-05-31 09:26:45 INFO  - Folder permissions changed!

2019-05-31 09:26:45 INFO  - Successfully setup file system permissions for ColdFusion!

2019-05-31 09:26:45 INFO  - Setting up registry permissions for ColdFusion!

2019-05-31 09:26:45 INFO  - Now starting to change registry permissions!

2019-05-31 09:26:45 INFO  - ColdFusion version is: 2018

2019-05-31 09:26:45 INFO  - Now getting all registry keys!

2019-05-31 09:26:45 INFO  - All registry keys to change received!

2019-05-31 09:26:46 INFO  - Registry permissions were successfully changed!

2019-05-31 09:26:46 INFO  - Successfully changed the registry permissions for ColdFusion!

2019-05-31 09:26:46 INFO  - Changing logon users for ColdFusion services

2019-05-31 09:26:46 INFO  - Trying to change logon user for ColdFusion

2019-05-31 09:26:47 INFO  - Changing for: ColdFusion2018Add-onServices

2019-05-31 09:26:47 INFO  - [SC] ChangeServiceConfig SUCCESS

2019-05-31 09:26:47 INFO  - Changing for: ColdFusion 2018 Application Server

2019-05-31 09:26:47 INFO  - [SC] ChangeServiceConfig SUCCESS

2019-05-31 09:26:47 INFO  - Changing for: ColdFusion 2018 ODBC Agent

2019-05-31 09:26:47 INFO  - [SC] ChangeServiceConfig SUCCESS

2019-05-31 09:26:47 INFO  - Changing for: ColdFusion 2018 ODBC Server

2019-05-31 09:26:47 INFO  - [SC] ChangeServiceConfig SUCCESS

2019-05-31 09:26:47 INFO  - All permissions changed!

2019-05-31 09:26:47 INFO  - Restarting ColdFusion using ColdFusion services!

2019-05-31 09:26:47 INFO  -

The ColdFusion 2018 Add-on Services service was stopped successfully.

2019-05-31 09:26:57 INFO  - The ColdFusion 2018 Application Server service is stopping....

The ColdFusion 2018 Application Server service was stopped successfully.

2019-05-31 09:26:57 INFO  - The ColdFusion 2018 ODBC Agent service is not started.

More help is available by typing NET HELPMSG 3521.

2019-05-31 09:26:57 INFO  - The ColdFusion 2018 ODBC Server service is not started.

More help is available by typing NET HELPMSG 3521.

2019-05-31 09:26:57 INFO  - Not all services could be stopped!

2019-05-31 09:27:00 INFO  - The ColdFusion 2018 Add-on Services service could not be started.

A system error has occurred.

System error 1067 has occurred.

The process terminated unexpectedly.

2019-05-31 09:27:05 INFO  - The ColdFusion 2018 Application Server service could not be started.

A service specific error occurred: 2.

More help is available by typing NET HELPMSG 3547.

2019-05-31 09:27:05 INFO  - System error 1058 has occurred.

The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

2019-05-31 09:27:05 INFO  - System error 1058 has occurred.

The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

2019-05-31 09:27:05 INFO  - Not all services could be restarted!

2019-05-31 09:27:05 INFO  - All ColdFusion services restarted successfully!

2019-05-31 09:27:05 INFO  - Successfully changed the logon users for ColdFusion services!

2019-05-31 09:27:05 INFO  - Trying to restart ColdFusion

2019-05-31 09:27:05 INFO  - ColdFusion restarted successfully!

2019-05-31 09:27:05 INFO  - Setting up virtual directory for cf_scripts!

2019-05-31 09:27:05 INFO  - Trying to add virtual directory for cf_scripts

2019-05-31 09:27:05 INFO  - Adding virtual directory for cf_scripts!

2019-05-31 09:27:06 INFO  - Successfully added virtual directory for cf_scripts!

2019-05-31 09:27:06 INFO  - Changing scripts source in ColdFusion Administrator

2019-05-31 09:27:07 INFO  - Old Value for scripts source: none

2019-05-31 09:27:07 INFO  - It seems there has been an error while getting the script source values.

2019-05-31 09:27:07 INFO  - Failed to change cf_scripts source in Administrator

2019-05-31 09:27:07 INFO  - Failed to add virtual directory for cf_scripts

2019-05-31 09:27:07 INFO  - Rolling back the changes because of the Lockdown failure

2019-05-31 09:27:07 INFO  - Removing the alias created for ColdFusion scripts

2019-05-31 09:27:08 INFO  - Successfully removed the alias created for ColdFusion scripts

2019-05-31 09:27:08 INFO  - Reverting back the service logon users for ColdFusion services

2019-05-31 09:27:08 INFO  - The ColdFusion 2018 Add-on Services service is not started.

**There are more log entries about reverting and rolling back, but I didn't want to overload the post. I included a lot of the success entries at the top to provide context.

[Dave Watts]

Honestly, I'm amazed that the lockdown tool works at all. It's doing a lot of complicated and somewhat fragile things, and having done these things by hand for many years I can attest that there are lots of opportunities for things to go wrong during this process. So personally, I'd recommend following the lockdown guide for the previous version and at least reading it to understand the different things the lockdown tool is doing.

That said, it looks like the problem here is pretty specific. The lockdown tool can't find the current location for where scripts live ("cf_scripts"). This can be assigned a value in the CF Administrator, but can also be left empty. So go in the CF Administrator and assign a value here if there isn't one already.

Beyond that, I'd recommend either taking advantage of Adobe's installation support if you can, or using someone like Charlie Arehart to step through the process. It's very helpful to have a second set of eyes looking at things exactly when they go wrong, instead of relaying errors through the forums.

Dave Watts, Eidolon LLC

[JD-16]

Hi Dave,

I appreciate your reply. Your sentiment regarding the lockdown tool appears to be widely shared from my searching on this and related topics.

I took this opportunity to rebuild the web server on Windows Server 2019; reinstalled ColdFusion (this time without ODBC), and installed latest hotfix (no errors on either install).

I checked CF Admin -> Server Settings -> Settings, and the Default ScriptSrc Directory was set to "/cf_scripts/scripts/" before I ran the lock down tool. I ran the lockdown tool again and received very similar output from the log file. It is below if you are interested.

I have sent an email to cfinstal@adobe.com requesting assistance, I will see what they say. Thanks again for your input.

2019-06-04 14:02:20 INFO  - Not all services could be restarted!

2019-06-04 14:02:20 INFO  - All ColdFusion services restarted successfully!

2019-06-04 14:02:20 INFO  - Successfully changed the logon users for ColdFusion services!

2019-06-04 14:02:20 INFO  - Trying to restart ColdFusion

2019-06-04 14:02:20 INFO  - ColdFusion restarted successfully!

2019-06-04 14:02:20 INFO  - Setting up virtual directory for cf_scripts!

2019-06-04 14:02:20 INFO  - Trying to add virtual directory for cf_scripts

2019-06-04 14:02:20 INFO  - Adding virtual directory for cf_scripts!

2019-06-04 14:02:21 INFO  - Successfully added virtual directory for cf_scripts!

2019-06-04 14:02:21 INFO  - Changing scripts source in ColdFusion Administrator

2019-06-04 14:02:22 INFO  - Old Value for scripts source: none

2019-06-04 14:02:22 INFO  - It seems there has been an error while getting the script source values.

2019-06-04 14:02:22 INFO  - Failed to change cf_scripts source in Administrator

2019-06-04 14:02:22 INFO  - Failed to add virtual directory for cf_scripts

2019-06-04 14:02:22 INFO  - Rolling back the changes because of the Lockdown failure

2019-06-04 14:02:22 INFO  - Removing the alias created for ColdFusion scripts

2019-06-04 14:02:23 INFO  - Successfully removed the alias created for ColdFusion scripts

2019-06-04 14:02:23 INFO  - Reverting back the service logon users for ColdFusion services

2019-06-04 14:02:23 INFO  - Failed to revert back the service logon users for ColdFusion services

2019-06-04 14:02:23 INFO  - Reverting back the registry permissions changed during Lockdown

JD

[JD-16 · Accepted solution]

Hi folks,

I just wanted to provide an update. I worked with Adobe support, and ended up solving this issue. In my case, I was a victim of my own good server hardening practices before installing ColdFusion.

I usually only allow SYSTEM, and Administrators full control of the additional NTFS volumes. It turns out that the lockdown tool for some reason needs the "localserver\Users" group to have read/execute access to the volume where ColdFusion is installed. The account I was using to install ColdFusion and run the lockdown tool is in the Administrators group. All others installs succeeded until the lockdown tool was run.

Once I added this permission back to the volume, it worked as expected. Thanks for the replies and help.

JD

[WolfShade]

I'm glad that A) you figured it out (granted, with some help from Adobe), and B) you shared the solution with us.  I have little doubt that someone else will benefit from your experience.

V/r,

^ _ ^

[Charlie Arehart]

I find it hard to believe that the tool presumes you must give USERS r/w access to the volume running CF. That would of course be very weak from a security perspective. Are you really saying, JD, that Adobe told you that, specifically? Or is it what you found from experimentation?

Couldn't it be simply that a) you would just need to add YOUR user (whoever you are logged in as, while running the tools) to have those rights? Or better b) that if you ran the tool "as admin" that then you'd not even need that?

I just checked the docs for the tool (Install ColdFusion Server Auto-Lockdown ), and I don't see it indicating that one should "run as admin". It literally says to just double-click it. That said, when I do that on my machine, I do get the Windows UAC popup asking me to confirm giving it control. That would make it seem it DOES run as admin, regardless.

But before we leave it at "everyone running the lockdown tool should give USERS r/w access to the CF volume", can you confirm for us JD if a) you got that Windows popup when you ran it? Or b) did you by any chance TRY to use "run as admin"? Or c) did you try just giving YOU (as logged in, running the tool) that permission?

I would love to hear from someone facing this problem if they may confirm that doing THAT alone was "the solution", rather than this current recommendation. And all the more, if one could then REMOVE such granted permissions AFTER running the tool.

(I mean no offense to you for offering the above, JD, especially if you would say Adobe told you to. I appreciate that you wanted to help other readers. I just want to get to the most secure solution, if better than the most expedient one that was presented. I will admit that I have not had much experience helping people use it, as very few of my clients have wanted to or done it, or presented problems to me if they did. And like Dave I have been reluctant to recommend it, because of the large number of changes and seeming brittleness I have seen reported by some. It's unfortunate, of course, because the goal of the tool was indeed to help folks implement security more easily. It's just the first release, of course.)

[JD-16]

I am new to administering ColdFusion servers, but not systems administration in general. I want the most secure solution as well. My post is not intended to provide instructions that others should follow, more so to document the issue I found and encourage conversation. I would hope that anyone setting up a new server would take any forum advice with the appropriate grain of salt.

I found this by experimentation when they could not reproduce my problem. In order to secure the NTFS volume, I had to take other measures. Adobe pointed me in the direction to solve my issue.

As I stated previously (but will now more state in more detail), the user I ran the lockdown tool as, as well as the administrative user that the tool used (tool asks for an administrative account), was part of the administrators group which had full control of the volume. The lockdown tool was run in administrative security context (run as admin, UAC prompt occurred). It still failed until I added the "localserver\users" permission of read\execute.

As it stands, the localserver\users group now needs to be pruned of any account or group that should not be there (This should have occurred in the first place). There should be no actual users in this group at all. Other security groups can be created to provide other accesses if required.

This problem can be quickly reproduced in a VM. To reproduce the problem create a VM running Server 2016 or Server 2019, create a new logical volume and assign it a drive letter. Remove all groups from the permissions of this logical volume save for "Administrators" and "SYSTEM". Ensure those have full control. Take a snapshot of the VM so you can roll back. Install ColdFusion 2018. Install latest security hotfix 4. Run the lockdown tool (current one, it was updated recently with hotfix 4's release). See if you get a failure in a similar spot as my originally reported failure. Now roll back to the snapshot. Add the localserver\Users group with read/execute permissions to that volume. Install ColdFusion 2018. Install latest security hotfix 4. Run the lockdown tool. It should succeed.

Let me know your results.

Regards,

JD

[pete_freitag]

Hmm, I agree with Charlie, that it should not be necessary to give the Users group r/w access to the entire drive...

The Users group is telling here because the IIS IUSR account (the account that anonymous requests to IIS are authenticated as) is implicitly a member of the Users group, you cannot remove it from this group and it doesn't show up in the GUI as a member, but it just IS a member of Users always.

Looking at where the lockdown installer failed, I would guess that the actual problem is that IUSR did not have permission to the cf_scripts directory in your CF installation folder when it tried to create a virtual directory. Giving full read/write permission to the entire drive would "solve" the problem if that were the cause, but it is also way more than should be necessary. It should only need to grant read permission to that folder, maybe it is trying to write a web.config or something as well?

[Charlie Arehart]

Thanks, Pete. That seems a good target.

And JD, again, I said I meant no offense. (Perhaps none was taken, but your response comes across just a tag defensive.) I appreciate that you were sharing what you observed, and now are sharing both where you're coming from and what you saw, in more detail.

But you also end with "let me know your results", implying that you expect me or someone to replicate the problem. Perhaps you meant implicitly, "if someone tries it, let me know the results". Fair enough. I say this to clarify that I am not able to commit to doing that, and we can't expect that Adobe (or anyone here) necessarily will, but perhaps they will. Again, you've given good insight for them to do so.

I'll be curious to hear instead if perhaps you may find Pete's observation to be on target, and especially if you may be in a position to test things in a VM, it would be great to hear what you find, pro or con.

[JD-16]

Hi Charlie,

Tone is difficult in written text, so I tend not to take offense. If I sound defensive, I just write. I am focused on the problem and my technical observations. I appreciate the opportunity to converse with you and Pete in this forum, I have read both of your works.

I wrote my last reply before I saw this post. I encourage you to give it a read, the log files on this topic are illuminating. I understand if you do not have the time to replicate. But to analyse this issue, replicating does help.

Please give my reply to Pete a read through, and let me know what you think of those log entries given Pete's reply regarding IUSR. If the lockdown tool gives IUSR permission to those directories, why did it fail?

Regards,

JD

[Charlie Arehart]

JD (and Pete), sorry. It was my mistake to assert JD was reporting having to apply "r/w" access. I see now instead it was indeed "read/execute". My bad. And Pete may have read what I wrote without noticing the inconsistency with what JD had written. My apologies to you both.

And JD, I am going to bow out for now. I don't have enough day to day experience with the Lockdown tool to offer more help. I read your replies (to me and to Pete), sure. I just don't see readily what we can make of things, and I'm just not in a position to setup an environment and run the tool against it.

I will say that it seems a KEY POINT that you clarified that you had 'ensured "localserver\users" group did not have any users in it'. That at least mitigates the concern I raised--at least until somehow some end up there. My bigger worry was that by default, most servers WOULD have users and groups in the USERS group, and I wasn't keen on the idea of opening up access to the entire volume for all those users--even just as read (and as execute) access.

But hopefully Adobe or other dedicated folks interested in this topic will chime in. You might even reach out to the cfinstal@adobe.com address and ask them to chime in here. You mentioned having work with someone at Adobe. You may reach someone else this way, and they (being the front line for support for people installing and initially configuring CF) may well have seen this issue--or at least be interested in it.

[JD-16]

Hi Charlie,

No worries

I provided this solution to Adobe when I was closing my ticket with them (ticket was opened through: cfinstal@adobe.com), and mentioned I didn't like leaving it there. My hope would be that they would look at this further.

Warm Regards,

JD

[JD-16]

Hi Pete,

Just to clear something up from your comment: I did not give read/write access to the ColdFusion install volume. I gave "localserver\users" Read/Execute access to the volume; no write/modify permissions at all. I then ensured "localserver\users" group did not have any users in it. This permission entry is added by default by Windows when you create a new NTFS volume. It is just a matter of not removing this particular entry when hardening (of course I would prefer not to leave this here).

It makes sense what you say about the IIS IUSR account being part of that Users group, and why keeping this permission on the volume works. I checked the permissions on my "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts\scripts" directory. IUSR has Read/Execute permission inherited from "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts". It also has IUSR with Read/Execute applied directly to "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts\scripts" directory.

The following entries are seen in the lockdown tool log:

2019-06-13 12:03:52 INFO  - Permissions changed for the user: IIS AppPool\DefaultAppPool for the path: "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts"

2019-06-13 12:03:52 INFO  - Change Permissions of ColdFusion file system: Input Logs

2019-06-13 12:03:55 INFO  - Successfully processed 3899 files; Failed processing 0 files

2019-06-13 12:03:55 INFO  - Change Permissions of ColdFusion file system: Error Logs

2019-06-13 12:03:55 INFO  -

2019-06-13 12:03:55 INFO  - Permissions changed for the user: IIS AppPool\DefaultAppPool for the path: "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts"

2019-06-13 12:03:55 INFO  - Change Permissions of ColdFusion file system: Input Logs

2019-06-13 12:03:57 INFO  - Successfully processed 3899 files; Failed processing 0 files

2019-06-13 12:03:57 INFO  - Change Permissions of ColdFusion file system: Error Logs

2019-06-13 12:03:57 INFO  -

2019-06-13 12:03:57 INFO  - Permissions changed for the user: IUSR for the path: "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts"

2019-06-13 12:03:57 INFO  - Change Permissions of ColdFusion file system: Input Logs

2019-06-13 12:03:59 INFO  - Successfully processed 3899 files; Failed processing 0 files

2019-06-13 12:03:59 INFO  - Change Permissions of ColdFusion file system: Error Logs

2019-06-13 12:03:59 INFO  -

2019-06-13 12:03:59 INFO  - Permissions changed for the user: IUSR for the path: "D:\ColdFusion2018\cfusion\wwwroot\cf_scripts"

2019-06-13 12:03:59 INFO  - Folder permissions changed!

2019-06-13 12:03:59 INFO  - Successfully setup file system permissions for ColdFusion!

These log entries are before the attempt to  change the scripts source in the log.

So it appears the lockdown tool knows to apply those permissions before hand. However when I did not have that "Users" permission on the root of the volume, it failed, even though it should have succeeded since the tool would grant those permissions.

Thoughts?

Have you tried to recreate this issue on your end yet? If you did a install using this tool where you removed those permissions, it should fail. Any advice for a better solution is welcome.

JD