Thu, Oct 8, 2015
When opening a newly-generated vulnerability report, one’s focus immediately turns towards the “High” risk vulnerabilities on the credit union’s critical devices. Next, focus shifts to examine the “Medium” and then “Low” vulnerabilities. And lastly, depending on resources available, perhaps the “Informational/None” vulnerabilities are attended to. This approach makes sense and is certainly not bad, but unfortunately, those “Informational/None” vulnerabilities may never be reviewed because the report indicates that the risk to the device under this categorization is, well, none.
The typical approach described can lead to dangerous oversight and ultimately weaken an otherwise strong information security program. This is not an uncommon experience, as many credit unions focus solely on the “High” and “Medium” risk vulnerabilities and then on to others as time permits.
Recently, after reviewing one such report during an onsite engagement, it was found that the Security Officer had made a practice out of focusing on the “High” vulnerabilities. Upon seeing the first vulnerability listed as “Informational/None”, he would shift his focus to other items that required attention. During our engagement’s exit meeting, the Security Officer seemed surprised that during the Internal Penetration Testing portion of the assessment, TraceSecurity was able to compromise the network through one of the “informational” vulnerabilities on a web server and ultimately create a domain administrator account without his knowledge. What we did to accomplish the compromise wasn’t particularly crafty or an exotic exploit. It was, in fact, just a web server sitting on the network with no associated “High” vulnerabilities and only appeared within the “Informational/None” vulnerabilities section in the report.
Problems arose because this server had software that wasn’t vulnerable itself but that was hosting a help desk ticketing system that had weak password requirements and used Lightweight Directory Access Protocol (LDAP) for authentication. The vulnerability scanner used for testing could not detect these characteristics, and the only result that could be reported was that the server was online and port 80 was open. Our recommendation to this organization was to review the report in its entirety every other time it was run. This might have led him to question what this server was doing online or what purpose it served.
Again, this is not an uncommon occurrence. TraceSecurity has seen it happen more than once. The takeaway is that a false perception of “Informational/None” vulnerabilities can lead to oversight and, as in this case, domain compromise. In the example above, the creation of a domain administrator account was just one aspect of the weaknesses found in this organization. This particular finding demonstrated that the organization had gaps in its configuration management and/or system hardening procedures.
In addition, asset management can also come into play, as accountability for that device seemed to shift from one owner to another with no real ownership confirmed by the end of the engagement.
TraceSecurity would advise this organization to dedicate some time and resources to reviewing those “Informational/None” findings within a vulnerability report. The fact that you operate a DNS server may not be news to you, but the fact that your vulnerability scan shows five in operation probably is.