Google has reportedly stopped censoring Chinese search results for its Google.cn property, in response to what it said earlier this week were targeted attacks against its corporate infrastructure aimed at Chinese dissident groups. But a security research firm claims the attack that hit Google was part of a larger, unusually sophisticated assault aimed at stealing source code from Google and at least 30 other Silicon Valley firms, banks and defense contractors.

Also, Google switches to “always on” encryption for all Gmail users. And some pundits see ulterior motives in Google’s Chinese hacking disclosure. More after the jump.

In a report released shortly after Google’s disclosure Tuesday evening, Sterling, Va. based iDefense cited two independent, anonymous sources in the defense contracting and intelligence consulting community as saying that Google traced the attack back to a “drop server” used as a repository for stolen files, where Google discovered its own data as well as proprietary data suggesting that at least 33 additional companies had been hit.

iDefense said the attack bears “significant resemblance” to a July 2009 attack in which assailants launched targeted e-mail campaigns against approximately 100 IT-focused companies. That attack employed a PDF file that exploited a then-undocumented vulnerability in Adobe Reader, and that a similar leveraging booby-trapped PDFs-as-attachments was used in the attack against Google, the report notes.

Kim Zetter at Wired.com’s Threat Level blog has a great deal more information in her thorough story on this.

Cynics see all kinds of ulterior motives in Google’s announcement that it got hacked and the subsequent arm-twisting with the Chinese government. Foreign Policy‘s Evgeny Morozov has penned a pair of incisive and trenchant opinion pieces speculating that Google’s move was little more than a calculated PR and business bid to gain market share vis-a-vis China’s dominant Baidu search engine. Krebsonsecurity.com reader and fellow security blogger Gunnar Peterson pointed my attention to a piece by Motley Fool‘s Tim Hanson that echoes those sentiments.

In apparently related news, Google has switched to “always on” encryption for all Gmail users, not just for those who have gone out of their way to select the “always use https://” option. By default, Google has always forced users to transmit their credentials over an encrypted (https://) connection when logging in, but after that Gmail users were popped back into an unencrypted connection unless they had changed the default option in the Gmail user settings to encrypt all Gmail communications.

The danger is that there are now free tools that help attackers steal the session cookie that most Webmail providers use to indicate users have already authenticated.  Armed with these tools, anyone recording the traffic on the local network would be able to access your Gmail inbox by simply loading that cookie on their machine. While these tools assume the attacker is on the same network as the target, most users do not sign out of Web mail services, and any session cookies that keep users logged in to their Webmail will most likely be transmitted periodically when roving users connect to a wireless network, for example.

Alas, Google has many properties that still do not enjoy this always-encrypted setting. In mid-2009, a Who’s Who of more than three dozen high-tech and security experts from industry and academia urged Google to encrypt all Google services by default, noting that tens of millions of consumers now rely on Google for a wide array of services that include sensitive data, such as Google Adsense, Adwords, Google Health. Still, this is a welcome step that hopefully will be emulated by the likes of Microsoft and Yahoo!, the other two major Webmail providers.

January promises to be a busy month for Web server and database administrators alike: A security research firm in Russia says it plans to release information about a slew of previously undocumented vulnerabilities in several widely-used commercial software products.

Evgeny Legerov, founder of Moscow based Intevydis, said he intends to publish the information between Jan 11 and Feb 1. The final list of vulnerabilities to be released is still in flux, Legerov said, but it is likely to include vulnerabilities (and in some cases working exploits) in:

-Web servers such as Zeus Web Server, Sun Web Server (pre-authentication buffer overflows);
-Databases, including Mysql (buffer overflows), IBM DB2 (local root vulnerability), Lotus Domino and Informix
-Directory servers, such as Novell eDirectory, Sun Directory and Tivoli Directory.

In an interview with krebsonsecurity.com, Legerov said his position on vulnerability disclosure has evolved over the years.

“After working with the vendors long enough, we’ve come to conclusion that, to put it simply, it is a waste of time. Now, we do not contact with vendors and do not support so-called ‘responsible disclosure’ policy,” Legerov said. For example, he said, “there will be published two years old Realplayer vulnerability soon, which we handled in a responsible way [and] contacted with a vendor.”

At issue is the pesky ethical and practical question of whether airing a software vendor’s dirty laundry (the unpatched security flaws that they know about but haven’t fixed yet) forces the affected vendor to fix the problem faster than it would have had the problem remained a relative secret. There are plenty of examples that show this so-called “full disclosure” approach does in fact prompt vendors to issue patches faster than when privately notified by the researcher and permitted to research and fix the problem on their own schedule. But in this case, Legerov said he has had no contact with the vendors, save for Zeus.com, which he said is likely to ship an update to fix the bug on the day he details the flaw.

Intevydis is among several vulnerability research firms that sell “exploit packs” — or snippets of code that exploit vulnerabilities in widely-used software (others include Gleg, Enable Security, and D2). The company’s exploit packs are designed for users of CANVAS, a commercial software penetration testing tool sold by Miami Beach, Fla. based Immunity, Inc.

While organizations that purchase CANVAS along with exploit packs from these companies may have better protection from newly-discovered security vulnerabilities while waiting for affected vendors to fix the flaws, Immunity does not report the vulnerabilities to the affected vendors (unless the vendors also are customers, in which case they would have access to the information at the same time as all other customers).

That approach stands apart from the likes of TippingPoint‘s Zero-Day Initiative and Verisign‘s iDefense Vulnerability Contributor Program, which pay researchers in exchange for the rights to their vulnerability research. Both ZDI and iDefense also manage the communication with the affected vendors, ship stopgap protection for the vulnerabilities to their customers, and otherwise keep mum on the flaws until the vendor ships an update to fix the bugs.

Legerov said he’s been an anonymous contributor to both programs over the years, and that it is not difficult for good researchers to make between $5,000 and $10,000 a month selling vulnerabilities and exploits to those companies. But he added that he prefers the full disclosure route because “it allows people to publish what they think without being moderated.”

Dmitri Alperovitch, vice president of threat research at McAfee, called Legerov’s planned disclosure “irresponsible,” given the sheer number of businesses that rely on the affected products. Alperovitch said the responsible way to disclose a vulnerability is to send information to the vendor and let them know you plan to release in a reasonable time (usually 60-90 days).

“If they ask for more time  — again, reasonably – not a year out — you try to accommodate. If the vendor doesn’t respond, you release and move on,” he said. “But to give them no advance notice just because some vendors don’t take security seriously is irresponsible.”

Charlie Miller, a former security researcher for the National Security Agency who now heads up the Baltimore based Independent Security Evaluators (and is co-founder of the No More Free Bugs meme) , also has earned tens of thousands of dollars from vulnerability management firms — most famously by competing in ZDI’s Pwn to Own contests, which carry a $10,000 First Prize.

“These programs are good because they allow researchers to get something for their effort, and you don’t have to deal with the back-and-forth with the vendor, which is not fun,” Miller said.

Still, Miller said he’s sympathetic to researchers who react to vendor apathy with full disclosure.

“The thing is, finding critical security bugs in widely used software should be rare if vendors are doing their job. But the sad part is, finding a serious bug in something like Adobe Reader is not a very rare event, and it seems to happen every month almost now,” Miller said. “The conclusion we can draw is that some vendors aren’t doing enough to make their software secure. It should be rare enough that vendors should be so surprised and concerned that they’re willing to do what they need to do to get it fixed.”

Setting the full disclosure debate aside for the moment, it has been fascinating to watch the development of the vulnerability management industry. I can recall a heated panel discussion back in 2006 at the CANSEC West conference in Vancouver, B.C. Canada, in which ZDI and several supporters of that effort took some heat for the program from a number of folks in the security industry.

These days, ZDI and iDefense are responsible for pushing software makers to fix an impressive number of software flaws.  Take Microsoft, for example: By my count, Microsoft fixed approximately 175 security vulnerabilities in its Windows operating systems and other software last year. Of those, the ZDI program is responsible for reporting 32, while iDefense’s program contributed 30 flaw reports. Put together, the two programs accounted for more than a third of all vulnerabilities Microsoft fixed in 2009.

Got strong feelings about this article, or about the issue of vendor responsibility or vulnerability disclosure? Please drop a note in the comments section below.