Snapin script interrupted by Hostname Changer before completion (I think)

[ITSolutions]

@michael_f With the new client you are right about it being encrypted in transit. But the snapin’s are transferred to the client and stored in a temp folder under the FOG install location(C:\Program Files(x86)\FOG\tmp) before being executed, this would be the script with the credentials. This could result in the file with the credentials remaining on the client due to various reasons. Such as if the client gets the snapin and is immediately shut down or the service is stopped and the temp files are not removed. Also given that it is saved on the client it is possible to recover the data using file recovery tools even after deletion.

I had come up with the idea of the random password with the old client as it sent in plain text over the network. But as I didn’t have time, I never got around to working on it. Now with the new client it is less likely to get the snapin file, but still very possible. It all depends on the level of security you need/want for the distribution share. If you keep the share locked down, with little or no information other than programs files that can be installed, the risk is very minimal. That is were I am now, doesn’t seem to be worth the effort, security vs convince, there will always be a trade off.

I know I am going way off of the extreme cautious and almost tin-foil hat security concerns, but just thoughts on if you really want to ensure that passwords are truly secure.

[Wayne Workman]

@michael_f said in Snapin script interrupted by Hostname Changer before completion (I think):

@ITSolutions I am using network shares too, and agree with you that deleting the connection at the end and using a restricted account is a quite good idea.

But I still can’t see the security risk in putting the credentials in the script:
The script is stored on the fog server, which should be secure.
It is afaik sent to the client encrypted if using the new fog client.
On the client-side the script is executed with system-privileges, so an eventually logged in user can’t access the script? Or is the script saved readable in a temporary file?
If the credentials are sent encrypted to the server by the “net use”-command (which I assume), how can somebody get access to the credentials?

Maybe I got something wrong? I would really apreciate, if someone could clarify this.

It wouldn’t be difficult to snatch the script with the clear-text passwords in it from the server. It would be a matter of having a MAC (or list of MACs) from your environment (easy), finding the FOG Server’s IP (easy), and then writing a basic script to guess at the taskid. Then it’s just a matter of iterating through a most-probable range of task IDs and through a single or large list of MACs with GET requests… like this one:
http://10.2.1.11/fog/service/snapins.file.php?mac=90:B1:1C:98:03:8C||00:00:00:00:00:00:00:E0&taskid=3274

The most-probable range of task IDs is easy to determine by looking at any c:\fog.log file. Even if you couldn’t access the log to determine a most-probable range of task IDs, you could just iterate through 5,000 of them and likely hit the valid one. Once a valid one is hit, the snapin download starts. An attacker wouldn’t even need to know the task’s name or any associated files names.

Plain-Text passwords are never secure.

[Joe Schmitt]

@ITSolutions just throwing my 2 cents in here. Do not use plain text password hard-coded into a file. In the next version of the client we could easily add a checkbox to snapins “Hide snapin details in fog.log”. With that you could make the password a parameter to the batch script. For example:

RunWith: cmd.exe
RunWithArgs: /c
File: MyBatchScript.cmd
Args: MyPassword

Snapin configuration is transmitted in a secure median whereas the file itself is obtained via a simple http download and then a sha512 is generated and compared against a security transmitted checksum to ensure integrity. Now if you really wanted to be secure you’d also need to disable the legacy client support as a potential attack vector would be to make the legacy client API calls before the new client has a chance to grab the snapin information, thereby giving it in plain text. I’m not sure if we have such a checkbox to disable the legacy client yet so pinging @Tom-Elliott.

Another option:
Bake in your user share password into some SYSTEM read-only file on your image and make your batch script read it for the credentials.

[Wayne Workman]

@Jbob said in Snapin script interrupted by Hostname Changer before completion (I think):

Another option:
Bake in your user share password into some SYSTEM read-only file on your image and make your batch script read it for the credentials.

Even then, the NFS shares are readable by anyone, and one could restore the image to a linux directory via CLI and then browse to the files.

I would urge everyone to stay away from clear-text passwords.

[michael_f]

@Jbob That would mean, i could securly put my arguments here:

and in the script I connect my share like

net use \\share\folder  /user:%1 %2 

That would be a great feature!

[Wayne Workman]

@michael_f That’s the idea. and if this can be removed from the fog logs as @jbob said, it’d be pretty legit.

[michael_f]

@Wayne-Workman Thank you for clarifying this for me!

[ITSolutions]

@Wayne-Workman and @Jbob I fully agree that you should never use plain text passwords, very bad idea! Like I was saying the randomize password script I was thinking about was to work around limitations within FOG at the time, including now for that matter. If the password changed at times the attack window would be minimized. If someone did get the password it would expire during the next change and no longer be good. This also would eliminate the human error of “random” passwords, all random passwords by humans are bad, and mostly predictable over time.

@Jbob That would be great and make it much more secure, if we could hide the snapin details in the log we could negate plaintext passwords all together. But they can still be intercepted using @Wayne-Workman’s example of scanning tasks with MAC’s as the information is still transmitted and read by the client.

The other thought I had in regards to the client being able to support this type of thing is if we could have the option to map a network share through the snapin management. Have a check box for “map network share and use that location”. Then have a configurable share location in the database. The client would map the share, launch the snap in, perform the task, and disconnect when finished.

As for simplicity the hiding details would be easier and less prone to bugs. But a configurable default share with a check box would be a quicker way of reusing a share for multiple snapins over time.

The problem is anything is hack able given the determination of the attacker. The question is how much effort do they need to put in and how much convince do you give up? Not trying to be negative about it, but it is what keeps us in jobs. I enjoy the discussion and glad that we can discuss the ideas/issues/solutions we have to make FOG a better and more secure system.

[Wayne Workman]

@ITSolutions said in Snapin script interrupted by Hostname Changer before completion (I think):

But they can still be intercepted using @Wayne-Workman’s example of scanning tasks with MAC’s as the information is still transmitted and read by the client.

Ah, didn’t even think about that, even when I was looking at the plain-text snapin arguments in a web browser using the below GET method. But I’m positive a determined hacker would have thought about it. I’m not in the business of trying to hack FOG, the things I said below were just passing thoughts, no real effort was put in.

I think what I was looking at though was for Legacy Client compatibility. The New FOG Client gets it’s snapin info via encrypted communication as @jbob said earlier.

So… I guess we need a way to disable legacy client support should someone want that, and again @jbob is two steps ahead and already mentioned it.

[ITSolutions]

@Wayne-Workman I am not in the business to hack FOG either. But as I work in healthcare and we are a small shop one of my many hats is security, with PHI concerns I think about all possible attack surfaces. We have regular audits of our security and have to justify any thing that is of questionable nature. Right now I am working on closing up a few other areas, and I have been thinking of ways to harden software deployment through snapins. Currently we have a separate vlan for FOG and only deploy snapins at time of imaging, then remove the log and use the client just for user tracking and rebooting basically. I will push small single file snapins, if I need to, but nothing that needs to connect to a share due to not having a good way to do so. I love FOG and it works great, just like to include my thoughts on things to help further FOG and keep it as secure as possible along the way.

FOG 2.0 will be a huge advancement again I am sure. Just like 1.3 is truly leaps and bounds better than .3x was. I thought .3x was great, but the issues were definitely addressed. With all software there is always compromises to maintain backwards compatibility for longer than any @Developers would really want to do. In my opinion 1.3 is not just a decimal increment to 1.2, it is much closer to a 2.0 version. But with the true 2.0 they can finally drop support for the legacy client, partimage, and it sounds like move away from PHP. It will definitely be a more robust and modern system.