Security

VeriSign, which runs the master database for such domains as .com and .net, says a significant Internet security vulnerability will be closed by 2011, after delays caused by technical aspects of the implementation.

The problem is that DNS, the Domain Name System that translates Internet addresses into numerical values, can be seeded with false values and used to misdirect users. VeriSign told ZDNet on Friday that it will put in place DNSSEC, a protocol that will guarantee the origin and integrity of DNS data for the .com and .net domains, by the first quarter of 2011.

Read more of "VeriSign: Major internet security update by 2011" at ZDNet UK.

An attack on the main domain name system registrar in Puerto Rico led to the local Web sites of Google, Microsoft, Yahoo, Coca-Cola, and other big companies being redirected for a few hours on Sunday to sites that were defaced, according to security firm Imperva.

Those sites and others including PayPal, Nike, Dell, and Nokia, were redirected to sites that were black except for messages in hacker lingo saying that the sites had been hacked. However, the sites themselves were not hacked, Amichai Shulman, chief technology officer at Imperva, said on Monday.

A group calling itself the "Peace Crew" claimed that they used a SQL injection attack to break into the Puerto Rico registrar's management system, he said. "We're seeing more and more of these DNS-related attacks and seeing them scale up," he added.

While the sites that visitors were redirected to were obviously not the legitimate sites, DNS redirects could be used to send unsuspecting Web surfers to phishing sites pretending to be banks where they would be prompted to provide sensitive information.

People should use the SSL (Secure Sockets Layer) protocol for encrypting communications with sensitive sites and use anti-phishing technology in the browser that colors part of the URL address bar green or red based on the safety level of the site being visited.

Calls to Gauss Research Lab, the organization that manages Puerto Rico's top-level domain, were not answered late on Monday.

This is the message the hackers left on sites affected by the DNS redirect attack, according to mirrors of the defacements captured by Zone-H.org.

(Credit: Zone-H.org)

In 2003, the federal government released a report titled "The National Strategy to Secure Cyberspace," offering numerous recommendations to improve overall security. One suggestion was to replace insecure Domain Name System (DNS) servers with DNS Security Extensions, or DNSSEC. Simply stated, standard DNS has a relatively open method for updating information, making it vulnerable to an attack. DNSSEC, on the other hand, marries DNS with a public key infrastructure (PKI) for authentication and digital signatures addressing this particular vulnerability.

Since the original call to arms in 2003, DNSSEC implementation remained on the backburner--that is until recently. Now federal officials are poised to implement DNSSEC across the .gov domain by the end of 2009.

Of course, I'm all for additional security and I'm a firm believer in PKI as a way to guarantee trust and reduce DNS threats. That said, I am a bit worried that the federal government may be in over its collective head here. In theory, DNSSEC is a big improvement, but I'm concerned about:

1. Implementation. From what I've learned, implementing DNSSEC is difficult to configure and deploy. Given the size of the federal network, this may be the biggest implementation of DNSSEC to date. Will DNSSEC scale? I'm sure it will but it may be a painful process requiring new software development and lots of trial-and-error on the taxpayers' dime.

2. PKI. The federal government is probably as good at PKI management as anyone, but PKI is notoriously difficult and DNSSEC is a different type of implementation. Will DNSSEC be integrated into the federal PKI architecture or remain separate? Will there be a master PKI implementation for DNSSEC and another independent PKI for an additional federal initiative to secure the Border Gateway Protocol (BGP)? My fear is a complex web of unconnected expensive federal PKI architectures throughout Washington.

3. Security. Implemented incorrectly, DNSSEC can expose DNS Zone data, which is normally kept confidential. And DNSSEC is not immune to its own vulnerabilities. Recently, the Internet System Consortium released a number of security patches specifically for DNSSEC. My point here is the DNSSEC is not a security panacea; it too can be configured incorrectly or be prone to software vulnerabilities.

No doubt, DNS is vulnerable, but the best way I've seen to address this is with dedicated DNS appliances built on a hardened operating system along with extremely good processes around emergency patching. DNSSEC does introduce additional safeguards but they seem overly costly and cumbersome to me. Ultimately, I am sure that the federal government will persevere and get DNSSEC right, but is this effort really worth it? My guess is that this project will cost tens of millions if not hundreds of millions of taxpayer dollars. Great for beltway bandits, but is this really necessary? Let me know what you think.

The prototype SSL crack in action: It's a supposedly secure Web site (note "https:" in the menu bar). But the SSL certificate is issued by MD5 Collisions Inc.

(Credit: Jonathan Stray)

By Jonathan Stray

Updated at 3:30 p.m. PST with Microsoft comment, at 1:50 p.m. PST with VeriSign comment, at 10 a.m. PST with comment from cryptography expert Paul Kocher, and at 9 a.m. PST to reflect that presentation has taken place and include comment from cryptography expert Bruce Schneier.

BERLIN--A key piece of Internet technology that banks, e-commerce sites, and financial institutions rely on to keep transactions safe suffers from a serious security vulnerability, an international team of researchers announced on Tuesday.

They demonstrated how to forge security certificates used by secure Web sites, a process that would allow a sufficiently sophisticated criminal to fool the built-in verification methods used by all modern Web browsers--without the user being alerted that anything was amiss.

The problem is unlikely to affect most Internet users in the near future because taking advantage of the vulnerability requires discovering some techniques that are not expected to be made public as well as overcoming engineering hurdles: performing the initial digital forgery consumed approximately two weeks of computing time on a cluster of 200 PlayStation 3 consoles. In addition, a criminal needs to find a way to reroute traffic from a legitimate Web site to his own, perhaps through techniques that have become well-known in the last few years.

Yet if one group can do it today, others eventually will. "We have a proof-of-concept that allows us to impersonate any supposedly secure Web site on the Internet," said David Molnar, a doctoral student in computer science at the University of California at Berkeley.

Molnar and six other researchers presented their findings during an afternoon session of the Chaos Computer Club's annual conference here on Tuesday. Other team members include Jacob Appelbaum and Alexander Sotirov.

Their work has focused on finding vulnerabilities in a technology known as Secure Sockets Layer, or SSL, which was designed to provide Internet users with two guarantees: first, that the Web site they're connecting to isn't being spoofed, and second, that the connection is encrypted and is proof against eavesdropping. SSL is used whenever a user navigates to an address beginning with "https://". SSL certificates essentially stand for the claim that, for instance, etrade.com actually belongs to E-Trade Inc., and is not being operated by a thief hoping to steal account passwords.

Most browsers indicate that SSL is active by displaying a small padlock icon. An attack using a forged authentication certificate--which is what the researchers say they have done--is insidious because the browser can't detect it and the padlock icon would still appear.

Talk announcement on the CCC schedule in Berlin.

(Credit: Jonathan Stray)

Unlike most security issues, this problem cannot be fixed with a simple software update. "The bug is not in anyone's software," Sotirov said. "It's not the browser that's at fault. The browser does exactly what it's supposed to do... The problem is that what it's supposed to do is wrong."

The attack exploits a mathematical vulnerability in the MD5 algorithm, one of the standard cryptographic functions used to check that SSL certificates (and thus the corresponding Web sites) are valid. This function has been publicly known to be weak since 2004, but until now no one had figured out how to turn this theoretical weakness into a practical attack.

An SSL certificate is a small file that ties a real-world corporate identity to a Web site address and a corresponding public encryption key. This is presented to a private certificate authority firm, which is supposed to verify the link between identity and domain name and then cryptographically "sign" the certificate to vouch for it.

The problem arises when someone else is able to forge the same signature.

VeriSign, which operates the largest certificate authority in the world, learned of the vulnerability early on Tuesday and acted quickly to close the hole in its certificates, according to Tim Callan, vice president of product marketing at the company.

"We went into our systems and removed the MD5 algorith and replaced it with SHA-1 (Secure Hashing Algorith)," he said. "You can not get an SSL certificate from VeriSign now that is subject to this attack." More information from VeriSign is available on Callan's SSL blog.

VeriSign was in the process of phasing out MD5 before the issue came up and is now on track to have it entirely out of commission in January, Callan said. "On balance, public key infrastructure works extraordinarily well," he said when asked if the vulnerability illustrated a need to change the trust model.

Microsoft, while noting that the issue wasn't a vulnerability with one of its products, tried to downplay the threat to users in a security advisory Monday.

"This new disclosure does not increase risk to customers significantly, as the researchers have not published the cryptographic background to the attack, and the attack is not repeatable without this information," the advisory said.

A 1991-era protocol, but modern problems
When MIT professor Ron Rivest developed MD5 in 1991, it was considered sufficiently secure. But starting in 1996, a series of increasingly serious flaws started calling the continued viability of MD5 into question.

As CNET News reported in 2004, flaws discovered at that time "could eventually make it easier for intruders to insert undetectable back doors into computer code or to forge an electronic signature--unless a different, more secure algorithm is used." Then, in 2007, Arjen Lenstra of Bell Laboratories Switzerland, with Marc Stevens and Benne de Weger of TU Eindhoven, demonstrated a technique to construct two new certificates with different content but the same fingerprint.

Although security researchers had been worrying, and recommending that other alternatives be considered, nobody had yet demonstrated how to exploit this theoretical flaw in a practical attack.

The researchers who attacked SSL authentication. Left to right: David Molnar, Alexander Sotirov, Marc Stevens, Arjen Lenstra, Jacob Appelbaum. Not pictured: Benne de Weger and Dag Arne Osvik.

(Credit: Jonathan Stray)

Molnar, Appelbaum, and Sotirov joined forces with the European MD5 research team in mid-2008, along with Swiss cryptographer Dag Arne Osvik. They realized that the co-construction technique could be used to simultaneously generate one normal SSL certificate and one forged certificate, which could be used to sign and vouch for any other. They purchased a signature for the legitimate certificate from an established company that was still using MD5 for signing, and then applied the legitimate signature to the forged certificate. Because the legitimate and forged certificates had the same MD5 value, the legitimate signature also marked the forged one as acceptable.

The process amounted to transferring a photograph from a real ID to a fake by carefully matching the holographic security markers.

The rogue certificate can then be used to sign any other certificate of the attacker's choosing--such as one which assures Web browsers that a malicious phishing site is actually the legitimate etrade.com or bankofamerica.com.

After three unsuccessful attempts, each of which required approximately three days of compute time on a cluster of 200 PlayStation 3s, the researchers obtained a forged certificate authority in early November, at which time they notified browser developers and certificate authorities, or CAs, about the security flaw. Molnar estimates that the same processing time could be purchased from Amazon for about $1,500.

The team decided to disclose the vulnerability at the Berlin conference in hopes that the news will encourage everyone involved to fix the problem quickly. "The main message here is to stop issuing MD5 certificates, now," said Molnar. He believes that MD5 is so weak it no longer should be used for any applications: "More secure, freely available alternatives exist." (In November 2005, the U.S. government announced plans to find successors to MD5 and SHA-1, an official federal standard with its own problems. The new federal standard will be called SHA-3.)

By itself, the MD5-certificate-forging vulnerability wouldn't be too worrisome. That's because it relies on criminals being able to capture Web traffic to display a fraudulent Web site. But setting up a fake wireless access point to lure unsuspecting neighbors or business travelers is trivial, and a program released earlier this year to attack the domain name system (DNS) provides another way to direct Internet traffic for malicious purposes.

While only a few CAs currently sign certificates with MD5, Appelbaum estimates that 30 percent to 35 percent of all SSL certificates currently in use have an MD5 signature somewhere in their authentication chain. "The CAs should contact every customer that currently uses an MD5-signed certificate and offer a free replacement."

In an interview on Tuesday morning, cryptography expert Bruce Schneier praised the research but downplayed the real-world consequences of the findings.

"SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem," he said.

"This is good work, great cryptography. I love the research, but this doesn't matter a whit," Schneier added. "There are half a dozen ways to forge certificates and nobody checks them anyway."

Paul Kocher, president of Cryptography Research and an architect of the SSL 3.0 protocol, said the exploit highlights the need for a new universal hash function "that everyone is comfortable with."

"The paper is not a surprise, but at the same time it's the crispest demonstration for why it's necessary to remove this broken algorithm everywhere it is being used," he said, before adding "there are bigger things to worry about, like browser bugs and operating security bugs."

The researchers have created a Web site signed with a forged certificate which can be viewed here. The forged certificate was backdated so that it could not be used maliciously even if stolen from researchers, so you have to reset your system clock to August 2004 to view it.

Even though their work may be controversial, the researchers view their efforts as fundamental to creating a more secure Internet. "I don't want to be hit by this type of attack either," Sotirov said. "I use the Internet too."

The author is a freelance contributor to CNET News and is not an employee of CBS Interactive. His Web site can be found at jonathanstray.com.

Customers of CheckFree.com, an online bill paying site, were quietly redirected to servers in Ukraine early Tuesday morning, according to several reports.

Representatives of CheckFree told WashingtonPost.com that customers were redirected to a blank log-in page that attempted to install malware on the visiting PC. The company said it regained control at 5 a.m. EST Tuesday, so only customers using the site overnight were likely affected.

Mike Haro, senior security analyst at Sophos told CNET News, "The fact that they used a blank page to download a Trojan (not exactly subtle) says to me one of two things: a) they fell into these credentials and chose the fastest way to get something done, expecting the breach to be quickly detected; or b) they got more than we're being led to believe."

The Post also said someone was able to steal the user name and password to make account changes at CheckFree's domain registrar. The Domain Name System (DNS) takes the common name CheckFree.com and converts it to an online address; the criminals were able to change that online address to a server hosting malicious content.

CheckFree allows users to pay their utility bills, insurance payments, mortgage and loan payments along with 330 other kinds of bills electronically. The company declined to say how many of its customers may have been affected, according to the Post story.

CheckFree...stressed that the attack occurred during off-peak hours when customer traffic to its Web site is typically low. Still, CheckFree has a huge customer base: The company claims that some 24.7 million consumers initiate payments through its services.

Haro said: "I guess I'm less surprised that someone got access credentials, and more surprised at what they did--or didn't do--with that level of access." For example, he hasn't seen evidence the criminals have tried to extract money directly from the exposed accounts.

As of Thursday afternoon, representatives from CheckFree had not responded to CNET News' request for further comment.

Arbor Networks found that DDoS attack size (in gigabits) nearly doubled in 2008 from the previous year.

(Credit: Arbor Networks)

Internet service providers now spend most of their IT security resources detecting and mitigating distributed denial-of-service attacks, concludes a report from Arbor Networks.

The fourth edition of the Worldwide Infrastructure Security Report, released Tuesday, was based on how 70 lead security engineers responded to 90 questions. As in the previous three reports, ISPs reported attacks where their networks were overloaded with packets, what's called a distributed denial-of-service (DDoS) attack. However, this year, the ISPs indicated the attacks were not only larger in size but that most of them were stretching the upper limits of their security resources in order to deal with such attacks.

Rob Malan, founder and chief technology officer of Arbor Networks, said the DDoS attacks seen this year broke the 40-gigabit barrier, nearly double the volume of last year's attacks. He warned that if next year's attacks again double in size, "most carriers will be unable to deal with those attacks."

In assessing the attacks, Arbor Networks found "brute force," a catch-all term, was the dominant method used. The security firm looked at traditional means of DDoS--syn flood, udp flood--as well as anything else that artificially created network congestion. Malan told CNET News that despite the massive size, the attacks themselves demonstrated "little sophistication" and were simply "trying to overwhelm network bandwidth."

One consequence of this method was that upstream providers of the targets were increasingly being affected. "If an attacker takes out capacity of (the upstream) routers you're (also) starving the target," he said. Malan said attackers were also using reflective attacks, which use different pieces of DNS structure to redirect traffic away from a target.

While flood-based attacks represented 42 percent of the attacks reported, followed by protocol exhaustion-based at 24 percent, Arbor Networks also saw a sharp increase this year in application-based attacks, which accounted for 17 percent of the attacks.

Malan explained that with application-based attacks, bot-infected computers worldwide make connections to a targeted site, then "use an application protocol to deliver a perfectly valid request, not a vulnerability, not something that an IDS or other type of firewall would necessarily flag." For example, a botnet might instruct its zombie computers worldwide to do a back-end query off a database. "By itself it's not bad, but if you have multiple such requests, then you tie up the application--in this case database--resources on the back end," he said.

The report does contain some good news. Arbor Networks found detection and mitigation of these attacks to be increasing as well. Fifteen percent of the respondents said, on average, they can mitigate an attack within 10 minutes of detection. However, 30 percent said mitigation still takes them over an hour.

But finding the criminals responsible for these attacks is not a high priority. Arbor Networks found that ISPs have little time to involve law enforcement. "It's hard on carriers," said Malan. "They get paid on traffic, not to do forensic analysis. So it's hard from their perspective to make the economics work."

(Credit: Arbor Networks)

Two researchers in Sweden have found multiple flaws in the TCP stack that could lead to massive denial-of-service attacks if exploited. At present there is no workaround and there are no patches available.

The TCP stack defines a set of rules by which a computer can communicate over any network. Robert E. Lee, chief security officer for Outpost24, told CNET News, "the vendors we are in talks with seem to be taking the threat seriously."

The discovery follows a test using a port scanner called UnicornScan, which Lee and senior security researcher Jack Louis created. The tool is used for vulnerability assessment and penetration testing at Outpost24. Lee told a Swedish podcast that when they couldn't get a port scan done soon enough, they decided to move the TCP stack into the program to make it more distributed. That's when Louis started noticing strange behavior.

"Jack found some anomalies in which machines would stop working in some very specific circumstances while being scanned," Lee told CNET News. One of the behaviors experienced was packet loss where the packets just kept trying, and trying, and trying, creating, more or less, a denial of service (DoS) on that machine.

There doesn't appear to be just one vulnerability, but several, according to Robert Hansen who first wrote about this Friday. Hansen says the potential for these vulnerabilities, as he understands it, if exploited, could result in great damage. And fixing it will require coordination with vendors of operating systems, firewalls, and Web-enabled devices.

To exploit the flaws, to see if the TCP vulnerabilities were real, Lee and Louis created a program called "sockstress" that intentionally did some wrong things with the TCP/IP handshake process. The sockstress program was very effective in producing DoS attacks. The pair have no plans to release sockstress.

Lee said he doesn't plan to have a big, public disclosure press conference like Dan Kaminsky did with the DNS flaw this past summer. "We plan to work with vendors to ensure they understand the issues fully and have adequate solutions in place before publicly sharing details on the issues. Since there are multiple issues, we may be able to share information on individual issues as they are individually addressed."

Asked whether someone else could figure this out before the patches are out, Lee said "even though I think Jack Louis is exceptionally brilliant, Outpost24 doesn't have a monopoly on bug-finding abilities. It is a matter of time before someone else independently figures it out."

With the release of Mac OS X 10.5.5 on Monday, the Cupertino, Calif., computer company provided patches for almost three dozen software flaws. Some of the fixes are specific to Apple features, such as image processing and Finder. Other fixes are updates to various open-source projects including Bind, ClamAV, OpenSSH, and Ruby.

Version 10.5.5 can be obtained from the Apple Software Downloads page.

ATS
This patch affects users of Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5 through v10.5.4, and Mac OS X Server v10.5 through v10.5.4. The update addresses the issue in CVE-2008-2305 in which viewing a document containing a maliciously crafted font may lead to arbitrary code execution. Apple credits Chris Ries of Carnegie Mellon University Computing Services for reporting this vulnerability.

BIND
This patch affects users of Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5 through v10.5.4, and Mac OS X Server v10.5 through v10.5.4. The update upgrades users to BIND version 9.4.2-P2, which addresses performance issues associated with BIND version 9.4.2-P1.

ClamAV
This patch affects users of Mac OS X Server v10.4.11 and Mac OS X Server v10.5 through v10.5.4. The update addresses the vulnerabilities detailed within CVE-2008-1100, CVE-2008-1387, CVE-2008-0314, CVE-2008-1833, CVE-2008-1835, CVE-2008-1836, CVE-2008-1837, CVE-2008-2713, and CVE-2008-3215 by updating Mac OS users to ClamAV version 0.93.3.

Directory Services
This patch affects users of Mac OS X v10.5 through v10.5.4 and Mac OS X Server v10.5 through v10.5.4. The update addresses the vulnerability detailed in CVE-2008-2329, in which a person with access to the log-in screen may be able to list user names. Apple says an information disclosure issue exists in Log-in Window when it is configured to authenticate users with Active Directory. "By supplying wildcard characters in the user name field, a list of user names from Active Directory may be displayed."

Directory Services II
This patch affects users of Mac OS X Server v10.4.11, Mac OS X Server v10.5 through v10.5.4. The update addresses the insecure file operation vulnerability within CVE-2008-2330, in which a local user may obtain the server password if an OpenLDAP system administrator runs slapconfig.

On Tuesday, Apple released iPod Touch version 2.1 to address several security issues. Among them are the DNS vulnerabilities first reported by Dan Kaminsky of IOActive in July. Other issues include vulnerabilities in Webkit, CoreGraphics, and the Application Sandbox.

Earlier on Tuesday, Apple released updates to its QuickTime media player.

Apple notes that this update is only available through iTunes as part of the iPod Touch updating process and will not appear in your computer's Software Update application, nor can it be found on the Apple Downloads site.

Application Sandbox
This patch affects users of iPod Touch v2.0 through v2.0.2. The update addresses the information disclosure vulnerability detailed within CVE-2008-3631. Apple says "the Application Sandbox does not properly enforce access restrictions between third-party applications. This may allow a third-party application to read files in another third-party application's sandbox and lead to the disclosure of sensitive information." Apple credits Nicolas Seriot of Sen:te and Bryce Cogswell for reporting the vulnerability. This issue does not affect iPod Touch versions prior to v2.0.

CoreGraphics
This patch affects users of iPod Touch v1.1 through v2.0.2. The update addresses the FreeType v2.3.5 vulnerabilities within CVE-2008-1806, CVE-2008-1807, CVE-2008-1808. Apple says the most serious of these vulnerabilities may lead to arbitrary code execution when accessing maliciously crafted font data.

mDNSResponder
This patch affects users of iPod Touch v1.1 through v2.0.2. The update addresses the cache poisoning vulnerability within CVE-2008-1447. Apple explains that mDNSResponder provides translation between host names and IP addresses for applications that use its unicast DNS resolution API. A weakness in the DNS protocol may allow a remote attacker to perform DNS cache poisoning attacks. As a result, applications that rely on mDNSResponder for DNS may receive forged information.

Networking
This patch affects users of CVE-2008-3612. The update addresses the memory corruption issue vulnerability details within CVE-2008-3626. Apple says the TCP initial sequence numbers are sequentially generated. Predictable initial sequence numbers may allow a remote attacker to create a spoofed TCP connection or insert data into an existing TCP connection.

WebKit
This patch affects users of iPod Touch v1.1 through v2.0.2. The update addresses a vulnerability detailed within CVE-2008-3632. Apple says that a use-after-free issue exists in WebKit's handling of CSS import statements. Visiting a maliciously crafted Web site may lead to an unexpected application termination or arbitrary code execution.