Invalid Security Token without any Security tokens being set -- Also CA SSL security concerns

mrayzies

While working on setting up FOG from the dev git branch (our current production FOG server is version .32 and can’t support our new hardware, requiring an upgrade), I noted that there was now a new FOG client service. When setting up my image for upload, I tried out the new FOG client service.

I’m still having issues getting the client service to run (I’m plagued by invalid security tokens that resetting the encryption data won’t fix: https://forums.fogproject.org/topic/5088/could-not-get-security-token-token-dat/3 https://forums.fogproject.org/topic/6130/certificate-issues-since-moving-fog-from-ubuntu-to-fedora/10 https://forums.fogproject.org/topic/5259/hostnamechanger/4); however, while looking through those links I realized that the new FOG client service installs a CA into client machines.

Am I missing something, or isn’t this just as bad as things like SuperFish, Dell or ESET?
http://fortune.com/2015/11/23/dell-laptop-security-problem/
https://www.reddit.com/r/technology/comments/3twmfv/dell_ships_laptops_with_rogue_root_ca_exactly/
http://www.zdnet.com/article/lenovos-superfish-its-worse-than-we-thought/
https://device5.co.uk/blog/do-not-use-eset-ssl-protocol-filtering.html

What is the motivation to shift to this new style of client service? Is there some other flaw with the legacy client service that makes this model that much better? And if we must move to the new client service model, could FOG be modified so that we could provide our own certificates and rely on existing CAs instead of making one specifically for FOG?

Tom Elliott

What?

The FOG CA (from the fog server) is generated the first time to establish a proper trust relationship. This trust relationship ensures the fog server is only created at a specific point. This allows the client to trust that the server is who he says he is. The security token is created by the server and passed to the client during the initial authorization sequence. This security token allows the server to more appropriately trust the clients.

You are more than welcome to create your own CA’s and certificates as needed and use whatever means you deem fit for your organization. We do it because the installer does everything in attempt to make things “run right out the gate”.

We aren’t allowing the certificates stored on the FOG Server to be easily retrieved and I think for good reason.

There is a second CA that you may see, which is related to the one we are creating so we can sign the code base. This is yet another attempt at security assurance that the file you are installing is indeed one that we built and created.

Wayne Workman

@mrayzies Thanks for raising these concerns.

All computers ship with public root certificates already installed. This includes Windows, OSX, Android, Linux, iOS, and so on.

The Dell laptops sound like they were shipped with Dell’s PRIVATE key… big no-no… someone should be fired over that.

Superfish had the functionality to install a new public root cert on the system it ran on without the user’s permission, which is why it was dangerous.

The ESET antivirus was just outright terribly written and designed antivirus.

@Jbob could best explain how the FOG Client’s public cert and authority is set up, since he designed the new client.

mrayzies

@tom-elliott

The client has a “FOG Project” and “FOG Server CA” certificate – if I’m understanding you correctly, the “FOG Server CA” certificate is generated by the installation script for secure communication between the server and clients and the “FOG Project” certificate is for this project to sign the code, correct? Some follow up questions to that:

these CAs are installed by the FOG client service, correct?
is how would the client actually use the “FOG Project” certificate to verify the code, since the code runs on the server and isn’t directly accessible by the client?
if this is all done for secure communication between client and server, then why in the fog log do I see it attempting to communicate over insecure HTTP? Is this feature just not ready yet?

@Wayne-Workman @Jbob

Thanks for clarifying what you (and the industry) do differently and why those other issues don’t pertain to this situation, I appreciate the knowledge.

Wayne Workman

wiki tagging this… good stuff.

mrayzies

@Jbob

Ahhhh okay, now I believe I am understanding the situation better.

If it’s not too much of a sin to hijack and redirect the thread now, I would really appreciate help on figuring out what’s gone wrong with my client (since now I want to use the new client if I can).

As I initially posted, I am getting invalid security token errors in the fog log on the client. Like many of the links suggested, I tried to reset the encryption values for my client, but that has done nothing.

The log (which repeats this endlessly):

------------------------------------------------------------------------------
--------------------------------Authentication--------------------------------
------------------------------------------------------------------------------
 12/9/2015 2:09 PM Client-Info Version: 0.9.9
 12/9/2015 2:09 PM Middleware::Communication URL: http://fog/fog/management/other/ssl/srvpublic.crt
 12/9/2015 2:09 PM Middleware::Authentication ERROR: Could not get security token
 12/9/2015 2:09 PM Middleware::Authentication ERROR: Could not find file 'C:\Windows\system32\token.dat'.
 12/9/2015 2:09 PM Data::RSA FOG Server CA cert found
 12/9/2015 2:09 PM Middleware::Authentication Cert OK
 12/9/2015 2:09 PM Middleware::Communication POST URL: http://fog/fog/management/index.php?sub=authorize
 12/9/2015 2:09 PM Middleware::Communication Response: Invalid security token
 12/9/2015 2:09 PM Service Sleeping for 120 seconds

If I manually nagivate to the authorize URL, the webpage reads only:

#!im

Even though I have reset the encryption data, the database is pretty much blank for that host:

*************************** 1. row ***************************
          hostID: 1
        hostName: hostname
        hostDesc: 
          hostIP: 
       hostImage: 1
    hostBuilding: 0
  hostCreateDate: 2015-12-08 15:00:57
  hostLastDeploy: 0000-00-00 00:00:00
    hostCreateBy: fog
       hostUseAD: 0
    hostADDomain: 
        hostADOU: 
      hostADUser: 
      hostADPass: 
hostADPassLegacy: 
  hostProductKey: 
hostPrinterLevel: 
  hostKernelArgs: 
      hostKernel: 
      hostDevice: 
     hostPending: 
      hostPubKey: 
    hostSecToken: 
     hostSecTime: 0000-00-00 00:00:00
    hostPingCode: 
    hostExitBios: sanboot
     hostExitEfi: sanboot

Joe Schmitt

Sounds like a possible sever error. @Tom-Elliott

As for why you get #!im when you go their manually, that url in the log is a POST request with hidden data in it (the encrypted token / key)

mrayzies

To sum up for anyone who stumble across this post (though sadly the title may lead many people away):

There was a bug in the FOG client service and jumping to this commit seemed to fix it: 4adc2c2c02a19edbc8f8b6d7db63cad9ad2572fb (special thanks to @Jbob and @tom-elliott)

Wayne Workman

@mrayzies What cloud version is that commit? (top left corner of the web interface)

Tom Elliott

@Wayne-Workman He was using the current 5680 when he was seeing the issue, and we upgraded him to current (as of now) to 5688.

The problem was he still had the “cannot modify headers” information being sent at inopportune times. So this was invalidly acting like the host had a security token, and would immediately fail to send one. I fixed the header problem some time last night, and only had two (4 cloud versions) today so it was relatively easy to figure out and fix.

He also had some customizations for his own nfs situation that needed to be set. So part of the issues were also cause, but again easily fixed.

I’ve modified the title a bit to hep others find this issue more easily too.

Wayne Workman

@Jbob said:

@mrayzies not a problem. To answer those questions:

Yes, the client installs your servers’ certificate and ours.

The “FOG Project” CA (made by us) servers 2 purpose.

SYSTEM level services need to be digitally signed otherwise windows will throw security errors (I have seen this issue when imaging a machine with an unsigned client). This can also be used to ensure no tampering was done with the client files

That certificate is used to “verify” upgrades. Lets say we release v0.9.10, the client will download the msi from your server and check if it was signed by us. If the msi was somehow tampered, the digital signature would no longer be valid.

Using HTTP over HTTPS has no security benefit to the client. Why? Because all traffic is already encrypted. Here’s a very basic overview of how the new client communicates

Each client has a security token. This is used to prove to the server that the client is the actual host and not an impersonator. This token gets cycled constantly. When the client first makes contact, it encrypts its token and a proposed AES 256 key using RSA 4096 using your server’s public key. (This public key is verified against the pinned server CA certificate by checking the x509 chain and fingerprints).

If the server accepts the security token and the new AES key, all traffic from that point on is AES 256 encrypted using that securely transmitted key.

The whole point of our security model is to allow for secure communication over insecure medians.
Even then, the client installation has an HTTPS option, but it serves no real security benefit.

This stuff and a little other stuff has been added here:
https://wiki.fogproject.org/wiki/index.php/FOG_Client#Security_design

Invalid Security Token without any Security tokens being set -- Also CA SSL security concerns

220

11.7k

17.1k

154.6k