Mozilla’s Non-Public Vulnerability Database Hacked: Poor Enterprise Security to Blame

Mozilla Firefox

Mozilla Firefox

On September 6th, Mozilla announced in a blog post that sensitive information was stolen from their private vulnerability database. This private vulnerability database was used in conjunction with Mozilla’s Bugzilla tracking system and contained non-public Firefox browser bugs. The attackers made off with detailed information about 185 vulnerabilities to be precise, of which 53 were listed as “severe vulnerabilities”.

The Attackers used this non-public vulnerability information to then launch attacks against the Firefox browser in efforts to compromise Firefox users private information. This domino effect of events was all started by one Mozilla employee carelessly re-using a password for another completely unrelated account. This is really all it takes to get the ball rolling in an enterprise-scale attack; one re-used account password.

So How Did it happen?

The Mozilla employee reused a privileged user account password (the password used to access the vulnerability database) for some unrelated account and this unrelated account was later hacked. The attackers then took this Mozilla employee’s compromised account credentials and tried them out on various accounts associated with the employee and guess what they discovered? The username/password combo worked to permit them access to a highly sensitive trove of non-public vulnerability data stored in Mozilla’s Bugzilla database.

Attackers Exploit the Stolen Vulnerabilities

Mozilla believes that at least one of these vulnerabilities has already been exploited and used against Firefox browser users. The attackers used a malicious advertisement that ran on a news site in Russia. The ad contained an exploit that worked by searching a users machine for sensitive files and then uploading them to a server in Ukraine.

While Mozilla has already released a patch to address the flaw mentioned above, the organization’s overall security posture has already suffered a tremendous blow. The takeaway here remains eerily clear: this could have and should have been prevented by following the most basic security measures.

  • Educate employees to never re-use passwords
  • Force users to change passwords regularly
  • Limit the number of users with privileged access accounts
  • Enforce policies restricting exactly what the privileged user can do

 

What is Your Enterprise Doing to Ensure it Doesn’t Happen to You?

The question every enterprise manager needs to ask themself is “What are we doing to ensure this doesn’t happen to our organization?” If you hesitate when answering this question, even for a split second, then you’re likely not doing enough.

Contact Mission Critical Global Technology Group today to learn ways to prevent this type of disaster from happening to your organization.

 

——————————————————————————–

Image: Doug Belshaw/Flickr, CC BY 2.0

Sources: Mozilla Bugzilla FAQ