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



  • 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?


  • Moderator

    @Jbob said:

    @mrayzies not a problem. To answer those questions:

    1. Yes, the client installs your servers’ certificate and ours.
    2. 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.
    1. 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


  • Senior Developer

    @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.


  • Moderator

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



  • 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)


  • Senior Developer

    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)



  • @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
    

  • Moderator

    wiki tagging this… good stuff.


  • Senior Developer

    @mrayzies not a problem. To answer those questions:

    1. Yes, the client installs your servers’ certificate and ours.
    2. 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.
    1. 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.



  • @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:

    1. these CAs are installed by the FOG client service, correct?
    2. 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?
    3. 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.


  • Senior Developer

    @mrayzies Our security model is nothing new. Our handshake (involving the CA key) is used across the industry (by that I mean we based it off of how many other pieces of software do handshakes). It is very common to use an asymmetric key to ensure identity and then use that key to create a symmetrical encryption session.

    This security model is nothing like superfish. Superfish created a private CA locally and injected it into your certificate store. It then stripped out any incoming SSL traffic and re-signed it with their key. The vulnerability (outside of stripping ssl) is they used local private keys. The only entity with access to the fog server’s ca key is the root account on the fog server itself.

    Let me repeat, using key pairs to authenticate (this includes using a CA) is used across the industry and is considered good practice. Where others went wrong is giving out their private keys.

    Our security model was not my decision alone, nor only overseen by myself. Several people went into designing it, and others reviewed our implementation.

    References:
    https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
    https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Certificate_and_Public_Key_Pinning


  • Moderator

    @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.


  • Senior Developer

    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.


Log in to reply
 

398
Online

39.3k
Users

11.0k
Topics

104.5k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.