Security assessment scan against FOG server

[george1421]

As part of our internal audit program we are required to scan all internal hosts using a SIEM tool to look for vulnerabilities.

Here are several that our FOG server triggered. Understand I’m not implying or forcing anything here only raising awareness to the developers.

1. SSL/TLS: Certificate Expired

Risk: High
Application: https
Port: 443
The certificate of the remote service expired on 2017-02-04 23:55:05.
Certificate details:
subject ...:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
subject alternative names (SAN):
None
issued by .:
1.2.840.113549.1.9.1=#726F6F744073687675786173303439,CN=localhost,OU=SomeOrganizationalUnit,O=SomeO
rganization,L=SomeCity,ST=SomeState,C=--
serial ....: 00A6
valid from : 2016-02-05 23:55:05 UTC
valid until: 2017-02-04 23:55:05 UTC

I assume this is the SSL certificate used to communicate between the FOG server and the clients. I guess from the clients perspective they don’t care or aren’t checking the validity dates of the certificate in use. Should fog have a process to update this self signed certificate? Maybe something to consider for FOG 2.0?

2. http TRACE XSS attack

http TRACE XSS attack
Risk: High
Application: http
Port: 80
Protocol: tcp
Vulnerability Detection Result:
Solution: 
Add the following lines for each virtual host in your configuration file :
   RewriteEngine on
   RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
   RewriteRule .* - [F]
See also http://httpd.apache.org/docs/current/de/mod/core.html#traceenable
Solution:
Disable these methods.

I’ve added these rules to the /etc/httpd/conf.d/fog.conf file to change the file to this:

    <Directory /var/www/html/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On

    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]

I’ll know after the next scan if this fix resolved the issue.

The rest of the discovered issues were not related to FOG but system management on the FOG server, such as supporting weak SSL and ssh Ciphers and TCP timestamps. Surprisingly using NFS v3 did not set off a violation alert.

[Joe Schmitt]

@george1421 there appears to be some miscommunication about the client’s encryption (perhaps I misspoke at some point and used the wrong terms). The client doesn’t use SSL to encrypt traffic. It does use public key infrastructure though, similar to SSL. So your expired certificate should not be because of the client.

[george1421]

@joe-schmitt So fog and/or client did not create this self signed certificate? The server is dedicated to FOG. The concern is mainly around the client stopping top communicate with the FOG server for some unexplained reason. This this is not an issue then I’m good with an expired certificate. I just need to explain it during my audit review.

I also did find I need to disable sslv2, v3 and v1 for compliance too. That doesn’t (shouldn’t) impact fog. Its only an awareness.

[Joe Schmitt]

@george1421 The client does use a self-signed certificate, but its not part of HTTPS at all. You can use your own SSL certificate for the fog server, as long as host computers see it as valid.

[Tom Elliott]

Added the TRACE|TRACK rewrite conditions/rules.

I think this is good enough to solve this bug report then, as the certificate expiring can be easily redone. This simply takes --recreateKeys | -K to recreate the keys on this server. The CA should expire quite a long time from now and as the CA public cert is used on the clients this would prevent any issues.

Thanks for reporting and with suggestions to correct!

[Tom Elliott]

Should add this is for the working-1.5.1 which should become “stable” fairly soon.