Audience::All
UUID: e62e4ab8-ad7e-449d-9a4b-d2f2f2dd459e
This morning, I happened across this dead as I write this link. It goes to the FedBizOpps.gov site, and was original for Solicitation Number N0018915T0245, titled 70--Common Vulnerability Exploit Products. I happened to open it in another browser because I was curious about a rendering problem, which can be seen in the text below. I suspected it was due to the common mislabeling of content as charset=iso-8859-1 in HTML files.
By 2015-06-12 0715 PDT it was gone; a reload in that browser landed on a search page. Back in the original browser, I saved a copy of the original solicitation as usn_exploit_request-1.pdf (229 KiB).
For a very few minutes it could be found by solicitation number from that search page, though the link presented did not do anything when clicked. That result became usn_exploit_request-2.pdf (131 KiB).
Within a very few more minutes it had disappeared from the search, and could no longer be found at all, by solicitation or title, even when the the search included both active and archived documents. I included archived documents purely because I thought that even though it was well before the original archive date, perhaps the request had been filled, and the document archived early. That result became usn_exploit_request-3.pdf (183 KiB).
It seems to have been simply deleted. There are many reasons that this might happen. Perhaps too many news sources had discovered it, it was causing an unfavorable reaction, and it was pulled for simple PR reasons. Though one takeaway from this is yet another lesson in not assuming that government archives are complete.
For those who don't want to look at PDFs, here is some of the relevant text, emphasized, with a bit of commentary from me.
This is a requirement to have access to vulnerability intelligence, exploit reports and operational exploit binaries affecting widely used and relied upon commercial software.
In a bit, they become rather more focused of exploits than the defense side of things.
These include but are not limited to Microsoft, Adobe, JAVA, EMC, Novell, IBM, Android, Apple, CISCO IOS, Linksys WRT, and Linux, and all others.
So, all of the most commonly-used operating systems, including mobile, an interest in storage (and possibly VMWare), and some common networking gear (including a wireless router commonly deployed in home, small branch offices, etc.). As well those long-time security horror stories, JAVA [sic] and Adobe.
The vendor shall provide the government with a proposed list of available vulnerabilities, 0-day or N-day (no older than 6 months old). This list should be updated quarterly and include intelligence and exploits affecting widely used software. The government will select from the supplied list and direct development of exploit binaries.
So, either 0-day, or at least not too stale.
Completed products will be delivered to the government via secured electronic means. Over a one year period, a minimum of 10 unique reports with corresponding exploit binaries will be provided periodically (no less than 2 per quarter) and designed to be operationally deployable upon delivery.
This qualifies as high volume.
Based on the Governmentâ€TMs direction, the vendor will develop exploits for future released Common Vulnerabilities and Exposures (CVEâ€TMs).
An obvious flaw here is that not even remotely all vulnerabilities ever receive a CVE number. Assignment of a CVE number, to the extent that it has any effect at, would tend to decrease the number of vulnerable systems, shortening the useful life of the vulnerability that the Navy had just purchased. Naval armament apparently includes footguns. Also, here is that rendering flaw.
Binaries must support configurable, custom, and/or government owned/provided payloads and suppress known network signatures from proof of concept code that may be found in the
wild.
Suppress is a poor choice of words. What they are after are exploits that don't present a signature that is already known to suppliers of Network Intrusion Detection Systems (NIDS). I am curious about why host-based antivirus and IDS (HIDS) isn't mentioned.
Innocent? Incompetent? Generic FUBAR?
This could be completely innocent; even an interest in 0-day or low n-day exploits may be an effort to provide their penetration testers with better tools. In the few contest between government employees and the private sector that I am aware of, feds of any stripe were trounced.
So, why was it pulled? Bad PR? Poorly written? Even a mistaken project approval? These are all possibilities, but it seems just as likely that it was a coordination issue. That could take a couple of forms. One is purely financial: duplicate efforts between government departments might well lead to the same exploit being purchased, perhaps from two different vendors.
The second form involves operations. Suppose that the Navy is unknowingly using a given vulnerability against a target of value x. Meanwhile, some random three-letter agency is using the same vulnerability to collect against a target of value 10x. If the Navy were detected, and a NIDS signature is created, the random three-letter agency could lose access.
Whatever the reason, it is not a sterling example of government competence. Someone needs to go shine their Cyber or something.
