National Vulnerability Database taken down by vulnerability-exploiting hack

There's no indication when service will be restored to official catalog.

The federal government's official catalog of software vulnerabilities was taken offline after administrators discovered two of its servers had been compromised. By malware. That exploited a software vulnerability.

The National Vulnerability Database is maintained by the National Institute of Standards and Technology and has been unavailable since late last week, according to an e-mail sent by NIST official Gail Porter published on Google+. At the time of this article on Thursday afternoon, the database remained down and there was no indication when service would be restored.

"On Friday March 8, a NIST firewall detected suspicious activity and took steps to block unusual traffic from reaching the Internet," Porter wrote in the March 14 message. "NIST began investigating the cause of the unusual activity and the servers were taken offline. Malware was discovered on two NIST Web servers and was then traced to a software vulnerability."

There's no evidence that any NIST pages were used to infect people visiting the site. Ars has e-mailed Porter for further details, and this post will be updated if additional information is available.

The infection is a graphic reminder that just about anyone on just about any complex system can be compromised. The hack was reported earlier by The Register.

Promoted Comments

Well, that's what vulnerability-exploiting hacks do, isn't it? I mean, imagine there's a critter called the Totally Lethal Poisonous Genital-Biting Ant. Someone goes out into the savanna to collect data on them, and then what? You expect them to get shot up in a gangland drive-by? No! They get bitten in the genitals with a totally lethal poison from the Totally Lethal Poisonous Genital-Biting Ant! The National Vulnerability Database knew the risks when it signed on for the job is all I'm saying.

I love the humor here. =)

That being said, just in case anyone else was curious, the NVD does not keep exploit samples. It is, however, a central repository and cross-reference site between vendor notifications, private run databases like http://cve.mitre.org and Bugtrack, and other government resources. If, for example, VMWare releases a notification on a vulnerability, I'll want to know the impact levels its estimated to have (to prioritize it among other fixes) as well as the other IDs its associated under for reporting purposes. This is one of the first sites I'll check for that sort of information.

Well, that's what vulnerability-exploiting hacks do, isn't it? I mean, imagine there's a critter called the Totally Lethal Poisonous Genital-Biting Ant. Someone goes out into the savanna to collect data on them, and then what? You expect them to get shot up in a gangland drive-by? No! They get bitten in the genitals with a totally lethal poison from the Totally Lethal Poisonous Genital-Biting Ant! The National Vulnerability Database knew the risks when it signed on for the job is all I'm saying.

Well, that's what vulnerability-exploiting hacks do, isn't it? I mean, imagine there's a critter called the Totally Lethal Poisonous Genital-Biting Ant. Someone goes out into the savanna to collect data on them, and then what? You expect them to get shot up in a gangland drive-by? No! They get bitten in the genitals with a totally lethal poison from the Totally Lethal Poisonous Genital-Biting Ant! The National Vulnerability Database knew the risks when it signed on for the job is all I'm saying.

I love the humor here. =)

That being said, just in case anyone else was curious, the NVD does not keep exploit samples. It is, however, a central repository and cross-reference site between vendor notifications, private run databases like http://cve.mitre.org and Bugtrack, and other government resources. If, for example, VMWare releases a notification on a vulnerability, I'll want to know the impact levels its estimated to have (to prioritize it among other fixes) as well as the other IDs its associated under for reporting purposes. This is one of the first sites I'll check for that sort of information.

Apparently, at that time, they were using MS Server 2008 with IIS but they no longer are. Interesting eh?

At any rate, I can imagine hackers wanting to know who is looking up what database entries. It's likely that if a visitor is interested in a specific entry in the database then they're either vulnerable or compromised. Talk about fish in a barrel.

Well, that's what vulnerability-exploiting hacks do, isn't it? I mean, imagine there's a critter called the Totally Lethal Poisonous Genital-Biting Ant. Someone goes out into the savanna to collect data on them, and then what? You expect them to get shot up in a gangland drive-by? No! They get bitten in the genitals with a totally lethal poison from the Totally Lethal Poisonous Genital-Biting Ant!

Didn't NIST also publish guides for the government workers for securing various Operating Systems?

They write more general (yet highly useful) guides. The 800-53 is the keystone document, covering the general principles of security controls from disaster recovery to account management and encryption.

On an added note: while it's tempting to quickly point the finger at NIST for suffering a compromise being that they're the same organization that writes guides for securing systems, the reality is that security is very hard. Systems in the current age are vastly complex, and face a range of determined threats for which they can only be reactive towards. Balance this with the need to provide services to thousands of users and maintain stability in a complex environment, and you have a real challenge, no matter how good your IA team is.

Of course, that's not to say that there are no lessons to be learned, or that they can't do better. While I cannot fault them for suffering a compromise, what they can do in this instance is use this incident to impress upon others the other domains of computer security beyond prevention, namely incident handling. Here's some questions I'd be asking:

-How soon was the intrusion detected?-How were the intruders detected? In particular, did the "continuous monitoring" components (this is a HUGE control in the 800-53) function as designed?-Was damage/disclosure contained or mitigated through defense-in-depth?-Did the incident response (notification of affected parties, collection of forensic information) work as planned?-Did the continuity of operations plan get executed as designed? (Note: The site is still down. Depending on the agreed recovery timeline, this could be compliant or not.)

In addition, I'd hope they'd publish an after-action report that detailed the events that happened, including any faults.

To reiterate, this is a tough job. Too often breaches are looked as as embarrassing. When it's something dumb (default password, blatantly violated controls, etc.) then it can be. Often, it's just one that got through. Being open with the information gathered and sharing it to the rest of the info tech community no only makes you look competent and responsible in being able to learn from mistakes, but helps the rest of the community learn from yours and be proactive in turn.

Apparently, at that time, they were using MS Server 2008 with IIS but they no longer are. Interesting eh?

At any rate, I can imagine hackers wanting to know who is looking up what database entries. It's likely that if a visitor is interested in a specific entry in the database then they're either vulnerable or compromised. Talk about fish in a barrel.

But they don't seem to be actually serving the site/database right now, so this could be just a temporary stopgap redirection, to serve the "Site/Page Not Available" message.

Apparently, at that time, they were using MS Server 2008 with IIS but they no longer are. Interesting eh?

At any rate, I can imagine hackers wanting to know who is looking up what database entries. It's likely that if a visitor is interested in a specific entry in the database then they're either vulnerable or compromised. Talk about fish in a barrel.

But they don't seem to be actually serving the site/database right now, so this could be just a temporary stopgap redirection, to serve the "Site/Page Not Available" message.

Well, that's what vulnerability-exploiting hacks do, isn't it? I mean, imagine there's a critter called the Totally Lethal Poisonous Genital-Biting Ant. Someone goes out into the savanna to collect data on them, and then what? You expect them to get shot up in a gangland drive-by? No! They get bitten in the genitals with a totally lethal poison from the Totally Lethal Poisonous Genital-Biting Ant! The National Vulnerability Database knew the risks when it signed on for the job is all I'm saying.

Am I seriously the only one that noticed that this was basically a madlibbed C&P from the Star Wars argument in the original Clerks? Those private contractors on the second Death Star knew what they were signing on for when they took the job.