DISA plugs hole in security scripts

The Defense Information Systems Agency has corrected a flaw in tools used to ensure that Defense Department computers are securely configured — but had inadvertently exposed those computers to malicious code.

Although the tools are again available for DOD use, they no longer are available to the public. The military services and many DOD contractors must use the scripts for their systems to verify compliance with DOD security implementation guidelines, and the scripts also had been publicly available online.

The problem in the Security Readiness Review (SRR) scripts was discovered by security researchers in September 2009 and made public in December when DISA removed the affected scripts from an online library of tools and advised users not to run them. DISA updated the scripts and republished them online several days later. However, the problem persisted, so DISA quickly withdrew them.

Three weeks later, DISA made the tools available again for DOD use, agency officials said.

“DISA performed a comprehensive source-code level review to address all methods of vulnerability checking used within the scripts,” William Keely, chief of DISA’s Field Security Operations division, said Jan. 13 in a statement. “This review included several hundred such scripts. This comprehensive analysis was completed and the revised toolset made available to the DOD community on Dec. 21, 2009.”

“All tools developed by DISA for performing an assessment of DOD's IT environments have been limited to authorized government users,” Keely said. “This limitation in distribution will be in effect pending a review of DISA's policy on making such tools available external to the DOD."

DISA develops Security Technical Implementation Guides for DOD users to standardize the secure configuration and operations of hardware and software through the life cycle of the device or program. DISA also publishes SRR scripts for a number of operating systems used to automatically verify STIG compliance. The scripts are run from the root directory — with administrative privileges — on the machine being reviewed. During the review, the script searches for discrepancies that could create vulnerabilities and checks the release version of applications to ensure they are up-to-date.

The problem was that the SRR scripts for several UNIX operating systems would run a number of applications, including Java, OpenSSL, PHP, Snort, Tshark, VNCserver, and Wireshark, to check the version. Therefore, the script was running an application with root privileges before the application was verified as trusted.

If an attacker could insert a malicious file labeled as one of those programs, it could install malicious software, such as a root kit, on the computer when executed by the SRR script. It could then cover its tracks by telling the script that the proper version had been found and everything was all right.

Following the second removal of the SRR scripts from the Web site in December, Keely issued a statement saying, “the UNIX scripts in question were a residual part of an earlier toolset that did not go through the same rigorous security testing as the more recent [information assurance] tools. We are reviewing all of the older toolsets to ensure that they all exceed our current security requirements.”