Mozilla Accidentally Dumps Info of 76,000 Developers to Public Web Server
Posted on August 3, 2014 by Kara Dunlap in Security
Mozilla Exposes Email Addresses of 76,000 Developers and 4,000 Password Hashes
Mozilla, the foundation behind the popular Firefox Web Browser, warned on Friday that it had mistakenly exposed information on almost 80,000 members of its Mozilla Developer Network (MDN) as a result of a botched data sanitization process.
The discovery was made around June 22 by one of Mozilla’s Web developers, Stormy Peter, Director of Developer Relations at Mozilla, said in a security advisory posted to the Mozilla Security Blog on Friday.
“Starting on about June 23, for a period of 30 days, a data sanitization process of the Mozilla Developer Network (MDN) site database had been failing, resulting in the accidental disclosure of MDN email addresses of about 76,000 users and encrypted passwords of about 4,000 users on a publicly accessible server,” Peter wrote.
While the data was exposed to the public, it doesn’t necessarily mean that anyone with malicious intentions had discovered it before being cleaned up, and according to Peter, Mozilla hasn’t seen any malicious activity the server, but noted they can’t rule it out.
According to Peter, the encrypted passwords were salted hashes and they by themselves cannot currently be used to authenticate with the MDN. However, Peter warned that MDN users may be at risk if they reused their original MDN passwords on other non-Mozilla websites or authentication systems. Peter further clarified in comments on the blog that the exposed passwords included salts that were unique to each user record.
Mozilla sent notices to those affected, and suggested that for those that had both email and password information exposed, change any similar passwords they may be using.
In typical breach disclosure fashion, Peter explained that Mozilla was examining how the “processes and principles that are in place” could be made better to reduce the likelihood that a similar incident could happen again.
Don’t Forget DNS Server Security
Posted on March 17, 2014 by Kara Dunlap in Security
Late last August, some visitors to the New York Times website received an unexpected surprise – the website was down.
The source of the interruption was not a power outage or even a denial-of-service attack. Instead, it was a battle against a DNS hijacking attempt believed to be connected to hacktivsts with the Syrian Electronic Army.
The attack was one of several in 2013 that focused on DNS (domain name system) infrastructure, and security experts don’t expect this year to be all that different – meaning organizations need to stay aware of DNS security threats.
Just last month, domain registrar and hosting provider Namecheap was hit with a distributed denial-of-service (DDoS) attack targeting its DNS platform that impacted roughly 300 sites. Beyond DDoS, attackers can also compromise a ame server and redirect DNS queries to a name server under their control.
“DNS providers are often targets of attack because they are a central point for disrupting all services, web, mail, chat, etc. for an organization,” said Michael Hamelin, lead X-Force security architect at IBM. “The DNS server is the roadmap for the Internet, and once disrupted, services that are the lifeblood of the organization such as web, mail, and chat become inaccessible. If a DNS provider goes down, it could mean that thousands of customers have their digital presence temporarily erased.”
In the case of the New York Times, the attack that affected their users occurred when someone accessed a reseller account on Melbourne IT’s systems and changed the DNS records for nytimes.com as well as other domain names such as twitter.co.uk. This kind of password theft can have far-reaching implications, said Hamelin, who recommended DNS providers use two-factor authentication and “enable a restricted IP block requiring all edits to be made internally on the network.”
“Organizations need to understand that just because they have outsourced their hosting and DNS, it doesn’t mean that they’re guaranteed that the vendor has taken adequate security precautions to provide a highly available and secure service,” he said. “The organization needs to anticipate their DNS may become a target of an attack, and implement countermeasures such using two different DNS systems and/or hosting providers.”
By its very nature, DNS is one of the weaker links in many infrastructures, said Vann Abernethy, senior product manager at NSFOCUS, adding that the company had seen an increase in both DDoS attacks on DNS infrastructure last year as well as the use of DNS to amplify traffic. Juxtaposed with the critical nature of its operation, its status as a weak link makes it an enticing target for attacks, he said.
“There are quite a few variants of DDoS attacks that can be executed against DNS servers, such as DNS Query Flood – a resource consumption attack aimed at a single infrastructure,” Abernethy said. “And there are new ones cropping up as well.”
Among those is a technique similar to a DNS amplification attack that relies on the attacker sending a query with fake subdomains that the victim DNS server cannot resolve, flooding the DNS authoritative servers it must contact, he said.
Fortunately, there are a number of actions organizations can take to improve DNS security. For starters, don’t run open resolvers, advised Mark Beckett, vice president of marketing for DNS security vendor Secure64.
“Open resolvers allow anyone on the internet to query a DNS resolver, and are widely used by botnets to inflict damage,” he said. “[Also] don’t allow spoofed IP addresses to exit your network. Organizations should set egress filters so that only packets with IP addresses within their network address space are allowed to exit their network. This eliminates the ability of the attack to spoof any IP address that it wishes from an infected machine.”
He also suggested organization use rate limiting capabilities within their DNS server if possible, and monitor the network to detect any sudden spikes in DNS packet rates or inbound or outbound DNS traffic volume.
“Early detection of an attack can allow an organization to take defensive measures (like blocking attack traffic upstream at the router or firewall) before the attack is severe enough to impact their users or their network,” he said.
DNS-related attacks will continue to be a theme of 2014, Hamelin said, noting there aren’t a lot of steps in place to protect organizations from a hijacked DNS server or its clients.
“Attackers are focused on ROI [return on investment] and attacking a DNS server could be a great way to have a large impact with little effort,” he said.