About site: Security/Internet - Google Online Security Blog

About site: http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml

Title: Security/Internet - Google Online Security Blog News and insights from on security and safety on the Internet. [Atom]

Alexa statistic for http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml

Please visit: http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml

Related sites for http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml

CompuTALK Provides insights into purchasing and using Dragon NaturallySpeaking. Products, resources, help, and support.

Computer_Help_Education_&_Site_Support Provides speech recognition solutions including software, microphones and digital recorders. Resells Dragon, Sony, Philips, and Accustic Magic products. Technical support, and product and partner list

Fimex_Technologies Distributor of voice recognition software, imaging software, bibliography software and other professional and knowledge-based solutions in South Africa, Cape Town.

Focus_Medical_Software Sells Dragon NaturallySpeaking medical transcription software and provides related services in the San Francisco area.

Freedom_of_Speech Provides speech recognition software solutions. Specializes in NaturallySpeaking software. News, available solutions, and company overview.

Microtechusa Computer center specializing in Dragon NaturallySpeaking software.

This is best-2006.com cache of m/ as retrieved on 2009.01.08 best-2006.com's cache is the snapshot that we took of the page as we crawled the web. The page may have changed since that time.

tag:blogger.com,1999:blog-11769492575416861272009-01-08T22:33:04.419-08:00Google Online Security BlogThe latest news and insights from Google on security and safety on the Internet.Molly Grahamhttp://www.blogger.com/profile/14622034276288473028noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-1176949257541686127.post-38439381457016454972008-12-10T14:54:00.001-08:002008-12-10T14:54:45.966-08:002008-12-10T14:54:45.966-08:00Announcing "Browser Security Handbook"Posted by Michael Zalewski, Security Team. Many people view the task of writing secure web applications as a very complex challenge - in part because of the inherent shortcomings of technologies such as HTTP, HTML, or Javascript, and in part because of the subtle differences and unexpected interactions between various browser security mechanisms. Through the years, we found that having a full understanding of browser-specific quirks is critical to making sound security design decisions in modern Web 2.0 applications. For example, the same user-supplied link may appear to one browser as a harmless relative address, while another could interpret it as a potentially malicious Javascript payload. In another case, an application may rely on a particular HTTP request that is impossible to spoof from within the browser in order to defend the security of its users. However, an attacker might easily subvert the safeguard by crafting the same request from within commonly installed browser extensions. If not accounted for, these differences can lead to trouble. In hopes of helping to make the Web a safer place, we decided to release our <a title="Browser Security Handbook" href="http://code.google.com/p/browsersec/wiki/Main" id="rhcz">Browser Security Handbook</a> to the general public. This 60-page document provides a comprehensive comparison of a broad set of security features and characteristics in commonly used browsers, along with (hopefully) useful commentary and implementation tips for application developers who need to rely on these mechanisms, as well as engineering teams working on future browser-side security enhancements. Please note that given the sheer number of characteristics covered, we expect some kinks in the initial version of the handbook; feedback from browser vendors and security researchers is greatly appreciated.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=YOgP25VN"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=vThYIiKD"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=vThYIiKD" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/O4AU6_wiBy4" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com5http://googleonlinesecurity.blogspot.com/2008/12/announcing-browser-security-handbook.htmltag:blogger.com,1999:blog-1176949257541686127.post-63870790381581711672008-12-08T13:21:00.001-08:002008-12-08T13:22:11.809-08:002008-12-08T13:22:11.809-08:00Native Client: A Technology for Running Native Code on the WebPosted by Brad Chen, Native Client Team. Most native applications can access everything on your computer – including your files. This access means that you have to make decisions about which apps you trust enough to install, because a malicious or buggy application might harm your machine. Here at Google we believe you shouldn't have to choose between powerful applications and security. That's why we're working on <a href="http://code.google.com/p/nativeclient/?tbbrand=GZEZ&utm_campaign=en&utm_source=en-et-secblog&utm_medium=et" >Native Client</a>, a technology that seeks to give Web developers the opportunity to make safer and more dynamic applications that can run on any OS and any browser. Today, we're sharing our technology with the research and security communities for their feedback to help make this technology more useful and more secure. Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system. The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly. With reliable disassembly as a tool, it's then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself. To learn more and help test Native Client, check out our <a href="http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html">post on the Google Code blog</a> as well as our <a href="http://code.google.com/p/nativeclient/?tbbrand=GZEZ&utm_campaign=en&utm_source=en-et-secblog&utm_medium=et" >developer site</a>. Our developer site includes our research paper and of course the source for the project under the BSD license. We look forward to hearing what you think!<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=C9SoQAdJ"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=xHsaBQFL"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=xHsaBQFL" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/2QGrbq4tQuU" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com4http://googleonlinesecurity.blogspot.com/2008/12/native-client-technology-for-running.htmltag:blogger.com,1999:blog-1176949257541686127.post-12901419367889729142008-12-02T06:00:00.000-08:002008-12-02T06:00:00.991-08:002008-12-02T06:00:00.991-08:00User Experience in the Identity Community<div style="margin-top: 0px; margin-bottom: 0px; ">Eric Sachs & Ben Laurie, Google Security </div><div style="margin-top: 0px; margin-bottom: 0px; "> </div><div style="margin-top: 0px; margin-bottom: 0px; ">One of the major conferences on Internet identity standards is the <a href="http://iiw.idcommons.net/" id="xwok" title="Internet Identity Workshop" style="color: rgb(85, 26, 139); ">Internet Identity Workshop</a> (IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc. A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read a <a href="http://blog.plaxo.com/archives/2008/11/yahoo_ups_the_a.html" id="jh0r" title="summary" style="color: rgb(85, 26, 139); ">summary</a> from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the <a href="http://blogs.msdn.com/card/archive/2008/11/18/the-cardspace-geneva-selection-experience.aspx" id="pyzp" title="updated" style="color: rgb(85, 26, 139); ">updated</a> CardSpace selector from Microsoft.</div><div style="margin-top: 0px; margin-bottom: 0px; "> </div><div style="margin-top: 0px; margin-bottom: 0px; ">Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an <a href="http://sites.google.com/site/oauthgoog/UXFedLogin/strongauth" id="zq0m" title="article" style="color: rgb(85, 26, 139); ">article</a> summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of <a href="http://sites.google.com/site/oauthgoog/UXFedLogin/strongauthvideos" id="ln7n" title="videos" style="color: rgb(85, 26, 139); ">videos</a> showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.</div><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=g2twxZuB"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=9u931A56"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=9u931A56" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/KdUhqcr2y0c" height="1" width="1"/>Eric Sachshttp://www.blogger.com/profile/07249915321397925223noreply@blogger.com1http://googleonlinesecurity.blogspot.com/2008/12/user-experience-in-identity-community.htmltag:blogger.com,1999:blog-1176949257541686127.post-64441398379504706302008-11-25T13:22:00.001-08:002008-11-25T13:42:24.619-08:002008-11-25T13:42:24.619-08:00Gmail security and recent phishing activityPosted by Chris Evans We've seen some speculation recently about a purported security vulnerability in Gmail and the theft of several website owners' domains by unauthorized third parties. At Google we're committed to providing secure products, and we mounted an immediate investigation. Our results indicate no evidence of a Gmail vulnerability. With help from affected users, we determined that the cause was a phishing scheme, a common method used by malicious actors to trick people into sharing their sensitive information. Attackers sent customized e-mails encouraging web domain owners to visit fraudulent websites such as "google-hosts.com" that they set up purely to harvest usernames and passwords. These fake sites had no affiliation with Google, and the ones we've seen are now offline. Once attackers gained the user credentials, they were free to modify the affected accounts as they desired. In this case, the attacker set up mail filters specifically designed to forward messages from web domain providers. Several news stories referenced a <a title="domain theft from December 2007" href="http://www.davidairey.com/google-gmail-security-hijack/" id="d.kh">domain theft from December 2007</a> that was incorrectly linked to a Gmail CSRF vulnerability. We did have a Gmail CSRF bug reported to us in September 2007 that we fixed worldwide within 24 hours of private disclosure of the bug details. Neither this bug nor any other Gmail bug was involved in the December 2007 domain theft. We recognize how many people depend on Gmail, and we strive to make it as secure as possible. At this time, we'd like to thank the wider security community for working with us to achieve this goal. We're always looking at new ways to enhance Gmail security. For example, we recently gave users the option to <a href="http://gmailblog.blogspot.com/2008/07/making-security-easier.html" id="murn" title="always connect via https">always run their entire session using https</a>. To keep your Google account secure online, we recommend you only ever enter your Gmail sign-in credentials to web addresses starting with https://www.google.com/accounts, and never click-through any warnings your browser may raise about certificates. For more information on how to stay safe from phishing attacks, see our blog post <a href="http://googleblog.blogspot.com/2008/04/how-to-avoid-getting-hooked.html" id="o8q2" title="here">here</a>.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=5ziOaTxJ"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=UypYbMp4"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=UypYbMp4" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/jSxgatXB-tY" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com23http://googleonlinesecurity.blogspot.com/2008/11/gmail-security-and-recent-phishing.htmltag:blogger.com,1999:blog-1176949257541686127.post-34122985048697151832008-11-18T17:41:00.000-08:002008-11-19T10:28:25.651-08:002008-11-19T10:28:25.651-08:00OAuth for Secure MashupsPosted by Eric Sachs, Senior Product Manager, Google Security A year ago, a number of large and small websites announced a new open standard called <a href="http://oauth.net/" id="hz33" title="OAuth">OAuth</a>. This standard is designed to provide a secure and privacy-preserving technique for enabling specific private data on one site to be accessed by another site. One popular reason for that type of cross-site access is data portability in areas such as personal health records (such as Google Health or Microsoft Healthvault), as well as social networks (such as OpenSocial enabled sites). I originally became involved in this space in the summer of 2005, when Google started developing a feature called <a href="http://code.google.com/apis/accounts/docs/AuthSub.html" id="e3yh" title="AuthSub">AuthSub</a>, which was one of the pre-cursors of OAuth. That was a proprietary protocol, but one that has been used by hundreds of websites to provide add-on services to Google Account users by getting permission from users to access data in their Google Accounts. In fact, that was the key feature that a few of us used to start the Google Health portability effort back when it was only a prototype project with a few dedicated Googlers. <div id="zq.s" style="margin-top: 0px; margin-bottom: 0px;"> </div> <div id="zq.s1" style="margin-top: 0px; margin-bottom: 0px;"> However, with the development of a common Internet standard in OAuth, we see much greater potential for data portability and secure mash-ups. Today we <a href="http://igoogledeveloper.blogspot.com/2008/11/sign-in-to-myspace-aol-mail-and-google.html">announced</a> that the gadget platform now supports OAuth, and the interoperability of this standard was demonstrated by new iGoogle gadgets that AOL and MySpace both built to enable users to see their respective AOL or MySpace mailboxes (and other information) while on iGoogle. However, to ensure the user's privacy, this only works after the user has authorized AOL or MySpace to make their data available to the gadget running on iGoogle. We also previously <a href="http://googledataapis.blogspot.com/2008/10/whats-that-google-data-gadgets.html" id="w6.8" title="announced">announced</a> that third-party developers can build their own iGoogle gadgets that access the OAuth-enabled APIs for Google applications such as Calendar, Picasa, and Docs. In fact, since both the gadget platform and OAuth technology are open standards, we are working to help other companies who run services similar to iGoogle to enhance them with support for these standards. Once that is in place, these new OAuth-powered gadgets that are available on iGoogle will also work on those other sites, including many of the gadgets that Google offers for its own applications. This provides a platform for some interesting mash-ups. For example, a third-party developer could create a single gadget that uses OAuth to access both Google OAuth-enabled APIs (such as a Gmail user's <a href="http://code.google.com/apis/contacts/" id="v05v" title="address book">address book</a>) and <a href="http://developer.myspace.com/community/myspace/dataavailability.aspx" id="lewp" title="MySpace OAuth enabled APIs">MySpace OAuth-enabled APIs</a> (such as a user's friend list) and display a mashup of the combination. </div> <div id="d23k" style="margin-top: 0px; margin-bottom: 0px;"> </div> <div id="ivuk" style="margin-top: 0px; margin-bottom: 0px;"> While the combination of OAuth with gadgets is an exciting new use of the technology, most of the use of OAuth is between websites, such as to enable a user of Google Health to allow a clinical trial matching site to access his or her health profile. I previously mentioned that one privacy control provided by OAuth is that it defines a standard way for users to authorize one website to make their data accessible to another website. In addition, OAuth provides a way to do this without the first site needing to reveal the identity of the user -- it simply provides a different opaque security token to each additional website the user wants to share his or her data with. It would allow a mutual fund, for example, to provide an iGoogle gadget to their customers that would run on iGoogle and show the user the value of his or her mutual fund, but without giving Google any unique information about the user, such as a social security number or account number. In the future, maybe we will even see industries like banks use standards such as OAuth to allow their customers to authorize utility companies to perform direct debit from the user's bank account without that person having to actually share his or her bank account number with the utility vendor. </div> <div id="pvsw" style="margin-top: 0px; margin-bottom: 0px;"> </div> <div id="odub" style="margin-top: 0px; margin-bottom: 0px;"> The OAuth community is continuing to enhance this standard and is very interested in having more companies engaged with its development. The <a href="http://oauth.net/" id="q6e4" title="OAuth">OAuth.net</a> website has more details about the current standard, and I maintain a <a href="http://sites.google.com/site/oauthgoog/" id="uw8z" title="website">website</a> with advanced information about Google's use of OAuth, including work on integrating OAuth with desktop apps, and integrating with federation standards such as OpenID and SAML. If you're interested in engaging with the OAuth community, please get in touch with us. </div><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=RbYKY1QI"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=livMlZFo"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=livMlZFo" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/bEpTg1dntxU" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com1http://googleonlinesecurity.blogspot.com/2008/11/oauth-for-secure-mashups.htmltag:blogger.com,1999:blog-1176949257541686127.post-54999703540867655722008-10-24T14:25:00.000-07:002008-10-24T14:42:45.649-07:002008-10-24T14:42:45.649-07:00Malware? We don't need no stinking malware!Written by Oliver Fisher "This site may harm your computer" You may have seen those words in Google search results — but what do they mean? If you click the search result link you get another warning page instead of the website you were expecting. But if the web page was your grandmother's baking blog, you're still confused. Surely your grandmother hasn't been secretly honing her l33t computer hacking skills at night school. Google must have made a mistake and your grandmother's web page is just fine... <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_LMSk7hTEaIE/SQI_1LfaQYI/AAAAAAAAtcc/zI4emYNyj4g/s1600-h/example.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 125px;" src="http://3.bp.blogspot.com/_LMSk7hTEaIE/SQI_1LfaQYI/AAAAAAAAtcc/zI4emYNyj4g/s320/example.png" alt="" id="BLOGGER_PHOTO_ID_5260837497572311426" border="0" /></a> I work with the team that helps put the warning in Google's search results, so let me try to explain. The good news is that your grandmother is still kind and <a href="http://fitz.blogspot.com/2008/10/everybody-should-have-one.html">loves turtles</a>. She isn't trying to start a botnet or steal credit card numbers. The bad news is that her website or the server that it runs on probably has a security vulnerability, most likely from some out-of-date software. That vulnerability has been exploited and malicious code has been added to your grandmother's website. It's most likely an invisible script or iframe that pulls content from another website that tries to attack any computer that views the page. If the attack succeeds, then viruses, spyware, key loggers, botnets, and other nasty stuff will get installed. If you see the warning on a site in Google's search results, it's a good idea to pay attention to it. Google has automatic scanners that are constantly looking for these sorts of web pages. I help build the scanners and continue to be surprised by how accurate they are. There is almost certainly something wrong with the website even if it is run by someone you trust. The automatic scanners make unbiased decisions based on the malicious content of the pages, not the reputation of the webmaster. Servers are just like your home computer and need constant updating. There are lots of tools that make building a website easy, but each one adds some risk of being exploited. Even if you're diligent and keep all your website components updated, your web host may not be. They control your website's server and may not have installed the most recent OS patches. And it's not just innocent grandmothers that this happens to. There have been warnings on the websites of banks, sports teams, and corporate and government websites. Uh-oh... I need help! Now that we understand what the malware label means in search results, what do you do if you're a webmaster and Google's scanners have found malware on your site? There are some resources to help clean things up. The Google Webmaster Central blog has <a href="http://googlewebmastercentral.blogspot.com/2008/04/my-sites-been-hacked-now-what.html">some tips</a> and a <a href="http://googlewebmastercentral.blogspot.com/2007/09/quick-security-checklist-for-webmasters.html">quick security checklist for webmasters</a>. <a href="http://stopbadware.org/">Stopbadware.org</a> has great information, and their <a href="http://groups.google.com/group/stopbadware">forums</a> have a number of helpful and knowledgeable volunteers who may be able to help (sometimes I'm one of them). You can also use the Google SafeBrowsing diagnostics page for your site (http://www.google.com/safebrowsing/diagnostic?site=<site-name-here>) to see specific information about what Google's automatic scanners have found. If your site has been flagged, Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a> lists some of the URLs that were scanned and found to be infected. Once you've cleaned up your website, use Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a> to <a href="http://googlewebmastercentral.blogspot.com/2008/08/hey-google-i-no-longer-have-badware.html">request a malware review</a>. The automatic systems will rescan your website and the warning will be removed if the malware is gone. Advance warning I often hear webmasters asking Google for advance warning before a malware label is put on their website. When the label is applied, Google usually <a href="http://www.google.com/support/webmasters/bin/answer.py?answer=45432#2">emails the website owners</a> and then posts a warning in Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a>. But no warning is given ahead of time - before the label is applied - so a webmaster can't quickly clean up the site before a warning is applied. But, look at the situation from the user's point of view. As a user, I'd be pretty annoyed if Google sent me to a site it knew was dangerous. Even a short delay would expose some users to that risk, and it doesn't seem justified. I know it's frustrating for a webmaster to see a malware label on their website. But, ultimately, protecting users against malware makes the internet a safer place and everyone benefits, both webmasters and users. Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a> has started a test to provide <a href="http://googlewebmastercentral.blogspot.com/2008/10/message-center-warnings-for-hackable.html">warnings to webmasters</a> that their server software may be vulnerable. Responding to that warning and updating server software can prevent your website from being compromised with malware. The best way to avoid a malware label is to never have any malware on the site! Reviews You can request a review via Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a> and you can see the status of the review there. If you think the review is taking too long, make sure to check the status. Finding all the malware on a site is difficult and the automated scanners are far more accurate than humans. The scanners may have found something you've missed and the review may have failed. If your site has a malware label, Google's <a href="http://www.google.com/webmasters/tools/">Webmaster Tools</a> will also list some sample URLs that have problems. This is not a full list of all of the problem URLs (because that's often very, very long), but it should get you started. Finally, don't confuse a malware review with a <a href="http://googlewebmastercentral.blogspot.com/2008/07/requesting-reconsideration-using-google.html">request for reconsideration</a>. If Google's automated scanners find malware on your website, the site will usually not be removed from search results. There is also a different process that removes spammy websites from Google search results. If that's happened and you disagree with Google, you should submit a <a href="http://googlewebmastercentral.blogspot.com/2008/07/requesting-reconsideration-using-google.html">reconsideration request</a>. But if your site has a malware label, a reconsideration request won't do any good — for malware you need to file a malware review from the Overview page. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_LMSk7hTEaIE/SQJAJQN-pYI/AAAAAAAAtck/DOkV2_QwJdQ/s1600-h/example2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 320px; height: 202px;" src="http://4.bp.blogspot.com/_LMSk7hTEaIE/SQJAJQN-pYI/AAAAAAAAtck/DOkV2_QwJdQ/s320/example2.png" alt="" id="BLOGGER_PHOTO_ID_5260837842438759810" border="0" /></a> How long will a review take? Webmasters are eager to have a Google malware label removed from their site and often ask how long a review of the site will take. Both the original scanning and the review process are fully automated. The systems analyze large portions of the internet, which is big place, so the review may not happen immediately. Ideally, the label will be removed within a few hours. At its longest, the process should take a day or so.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=SIUWOyG4"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=62ZsGul3"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=62ZsGul3" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/FIyRCnLebV4" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com6http://googleonlinesecurity.blogspot.com/2008/10/malware-we-dont-need-no-stinking.htmltag:blogger.com,1999:blog-1176949257541686127.post-85898797256752158362008-08-12T14:01:00.000-07:002008-08-12T14:09:22.867-07:002008-08-12T14:09:22.867-07:00New spam and virus trends from EnterpriseWritten by Amanda Kleha, Google Apps Security & Compliance team The <a href="http://www.google.com/a/help/intl/en/security/index.html">Google Apps Security & Compliance</a> team, which provides email and web security for more than 40,000 companies, regularly tracks trends in spam, viruses, and other threats. Check out some of our latest findings over on the <a href="http://googleenterprise.blogspot.com/2008/08/security-spotlight-july-virus-attacks.html">Enterprise blog</a>. Also, on Friday, August 15, at 10:00 am PT, we'll be hosting a <a href="http://w.on24.com/r.htm?e=116483&s=1&k=E679E434ECD09EFE9AB299E6B4E16A3B&partnerref=blog_security">webinar</a> on keeping your business safe from web and email threats -- tune in if you'd like to learn more.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=EIfcy0RJ"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=WOfF3JAs"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=WOfF3JAs" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/1mq055TO3rM" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com4http://googleonlinesecurity.blogspot.com/2008/08/new-spam-and-virus-trends-from.htmltag:blogger.com,1999:blog-1176949257541686127.post-31845013849801085392008-08-11T11:06:00.001-07:002008-08-11T11:10:29.232-07:002008-08-11T11:10:29.232-07:00Keyczar: Safe and Simple CryptographyWritten by Steve Weis <img style="margin: 0pt 0pt 10px 10px; float: right;" src="http://2.bp.blogspot.com/_LMSk7hTEaIE/SKCABPuzeVI/AAAAAAAAhXc/nyKwkCyDdwQ/s200/keyczar_logo.jpg" alt="" id="BLOGGER_PHOTO_ID_5233323525895584082" border="0" />Cryptography is notoriously hard to get right and if improperly used, can create serious security holes. Common mistakes include using the wrong cipher modes or obsolete algorithms, composing primitives in an unsafe manner, hard-coding keys in source code, or failing to anticipate the need for future key rotation. With these risks in mind, we're pleased to announce the open-source release of <a href="http://www.keyczar.org/">Keyczar</a>. Keyczar is a cryptographic toolkit that supports encryption and authentication for both symmetric and public-key algorithms. It addresses some of the aforementioned issues by choosing safe defaults, tagging outputs with key version information, and providing a simple application programming interface. Keyczar's key versioning system makes it easy to rotate and revoke keys, without worrying about backward compatibility or making any changes to source code. We look forward to working with the open source community and continuing to make cryptography safer and easier to use. To download Keyczar or for more information, please visit our <a href="http://code.google.com/p/keyczar">Google Code project</a> and <a href="http://groups.google.com/group/keyczar-discuss">discussion group</a>.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=6ODRtEpO"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=agNjL0Me"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=agNjL0Me" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/iXt3UNU0ZIg" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com4http://googleonlinesecurity.blogspot.com/2008/08/keyczar-safe-and-simple-cryptography.htmltag:blogger.com,1999:blog-1176949257541686127.post-55237158907753606962008-07-16T13:24:00.000-07:002008-07-16T13:30:52.545-07:002008-07-16T13:30:52.545-07:00Are you using the latest web browser?Written by Thomas Duebendorfer In view of mass defacements of hundreds of thousand of web pages - with the intent to misuse them to launch drive-by download attacks - security researchers from ETH Zurich, Google, and IBM Internet Security Systems were interested in looking at the other side of the attack: the web browser. By analyzing the web browser versions seen in visits to Google websites, they have shown that more than 600 million Internet users don't use the latest version of their browser. Slow migration to latest browser version The researchers' paper, entitled <a href="http://www.techzoom.net/insecurity-iceberg">"Understanding the Web Browser Threat"</a>, shows that as of June 2008, only 59.1% percent of Internet users worldwide use the latest major version of their preferred web browser. Firefox users are the most attentive: 92.2% of them surfed with Firefox 2, the latest major version before the recently released 3.0. Only 52.5% of Microsoft Internet Explorer users have updated to version 7, which is the most secure according to multiple publicly-cited Microsoft experts (among them Sandi Hardmeier). The study revealed that 637 million Internet users worldwide who use web browsers are either not running the latest version of their preferred browser or have not installed the latest patches. These users are vulnerable to exploitation due to their web browser's "built-in" vulnerabilities and the lack of more recent security mechanisms such as improved phishing protection. Neglected security patches Over the past 18 months, the study also shows, a maximum of 83.3% of Firefox users were using the latest major version of the web browser and also had all current patches installed (i.e. latest minor version). Only 56.1% and 47.6% of Opera and Internet Explorer users, respectively, were similarly utilizing fully-patched web browsers. Apple users are no better: since the public release of Safari 3, only 65.3% of users operate the latest Safari version. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_LMSk7hTEaIE/SH5ZvdukCtI/AAAAAAAAd10/-yGf2De4l8I/s1600-h/share.png"><img style="cursor: pointer;" src="http://bp1.blogger.com/_LMSk7hTEaIE/SH5ZvdukCtI/AAAAAAAAd10/-yGf2De4l8I/s400/share.png" alt="" id="BLOGGER_PHOTO_ID_5223711289765006034" border="0" /></a> <div>Maximum measured share of users surfing the web with the most secure versions of Firefox, Safari, Opera and Internet Explorer in June 2008 as seen on Google websites.</div> Obsolete browser warning The study's most important finding is that technical measures now in place do not sufficiently guarantee browser security, and that users' security awareness must be further developed. The problem is that most users are unaware that they are not using their browser's latest version. It must be made clear to web browser users that outdated software is associated with significantly higher risk. The researchers therefore suggest that, as a critical component of web software, a visible warning be instituted that warns the user of missing security patches in a way analogous to the 'best before' date in the perishable food industry. Software updates must also be made easier to find. The resulting transparency would go far in contributing to end user awareness of software weaknesses, and allow users to better evaluate risks. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_LMSk7hTEaIE/SH5aAEVMy0I/AAAAAAAAd18/nXMAqQdWXno/s1600-h/expired.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_LMSk7hTEaIE/SH5aAEVMy0I/AAAAAAAAd18/nXMAqQdWXno/s400/expired.png" alt="" id="BLOGGER_PHOTO_ID_5223711575005514562" border="0" /></a> <div>Example "best before" implementation on a Web browser</div> As a side effect, having users migrate faster to the latest browser version would not only increase security but also make the lives of webmasters easier, as they would need to test and optimize websites for fewer older versions of web browsers.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=gDlcQ2b9"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=w8JeXKZ7"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=w8JeXKZ7" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/j4mV3PUWWWY" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com22http://googleonlinesecurity.blogspot.com/2008/07/are-you-using-latest-web-browser.htmltag:blogger.com,1999:blog-1176949257541686127.post-21936532393058938182008-07-01T16:49:00.000-07:002008-07-01T16:50:02.346-07:002008-07-01T16:50:02.346-07:00Meet ratproxy, our passive web security assessment toolPosted by Michal Zalewski We're happy to announce that we've just open-sourced <a href="http://code.google.com/p/ratproxy">ratproxy</a>, a passive web application security assessment tool that we've been using internally at Google. This utility, developed by our information security engineering team, is designed to transparently analyze legitimate, browser-driven interactions with a tested web property and automatically pinpoint, annotate, and prioritize potential flaws or areas of concern. The proxy analyzes problems such as cross-site script inclusion threats, insufficient cross-site request forgery defenses, caching issues, cross-site scripting candidates, potentially unsafe cross-domain code inclusion schemes and information leakage scenarios, and much more. (A more-detailed discussion of these features and information on securing vulnerable applications is provided <a href="http://code.google.com/p/ratproxy/wiki/RatproxyDoc">here</a>.) Compared with more-traditional active crawlers, or with fully manual request inspection and modification frameworks, this approach offers several significant advantages in terms of minimized overhead; marginalized risk of site disruptions; high coverage of complex, client-driven application states in web 2.0 solutions; and insight into dynamic cross-domain trust models. We decided to make this tool freely available as open source because we feel it will be a valuable contribution to the information security community, helping advance the community's understanding of security challenges associated with contemporary web technologies. We believe that responsible security research brings a net overall benefit to the safety of the Web as a whole, and have released this tool explicitly to support that kind of research. To download the proxy, please visit this <a href="http://ratproxy.googlecode.com/files/ratproxy-1.50.tar.gz">page</a>. Also, please keep in mind that the proxy is designed solely to highlight interesting patterns in web applications, and a further analysis by a security professional is often required to interpret the results and their significance for the tested platform.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=5AvS6vw2"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=sIWTM6AF"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=sIWTM6AF" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/matIm4t6Uks" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com7http://googleonlinesecurity.blogspot.com/2008/07/meet-ratproxy-our-passive-web-security.htmltag:blogger.com,1999:blog-1176949257541686127.post-6635303746495648162008-05-15T13:49:00.000-07:002008-05-15T13:53:16.113-07:002008-05-15T13:53:16.113-07:00Safe Browsing Diagnostic To The RescuePosted by Niels Provos We've been protecting Google users from malicious web pages since 2006 by showing warning labels in Google's search results and by publishing the data via the <a title="Safe Browsing API" href="http://code.google.com/apis/safebrowsing/" target="_blank">Safe Browsing API</a> to client programs such as Firefox and Google Desktop Search. To create our data, we've built a large-scale infrastructure to automatically determine if web pages pose a risk to users. This system has proven to be highly accurate, but we've noted that it can sometimes be difficult for webmasters and users to verify our results, as attackers often use sophisticated obfuscation techniques or inject malicious payloads only under certain conditions. With that in mind, we've developed a Safe Browsing diagnostic page that will provide detailed information about our automatic investigations and findings. The <a title="Safe Browsing Diagnostic page" href="http://www.google.com/safebrowsing/diagnostic?site=http://malware.testing.google.test/testing/malware/">Safe Browsing diagnostic page</a> of a site is structured into four different categories: <ol> <li>What is the current listing status for [the site in question]? We display the current listing status of a site and also information on how often a site or parts of it were listed in the past. </li> <li>What happened when Google visited this site? This section includes information on when we analyzed the page, when it was last malicious, what kind of malware we encountered and so fourth.   To help web masters clean up their site, we also provide information about the sites that were serving malicious software to users and which sites might have served as intermediaries. </li> <li>Has this site acted as an intermediary resulting in further distribution of malware? Here we provide information if this site has facilitated the distribution of malicious software in the past. This could be an advertising network or statistics site that accidentally participated in the distribution of malicious software.</li> <li>Has this site hosted malware? Here we provide information if the the site has hosted malicious software in the past. We also provide information on the victim sites that initiated the distribution of malicious software.</li> </ol> All information we show is historical over the last ninety days but does not go further into the past.   Initially, we are making the Safe Browsing diagnostic page available in two ways.  We are adding a link on the <a title="interstitial" href="http://www.google.com/interstitial?url=http://malware.testing.google.test/testing/malware/">interstitial</a> page a user sees after clicking on a search result with a warning label, and also via an "additional information" link in Firefox 3's warning page. Of course, for anyone who wants to know more about how our detection system works, we also provide a detailed <a title="tech report" href="http://research.google.com/archive/provos-2008a.pdf">tech report [pdf]</a> including an overview of the detection system and in-depth data analysis. <div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=XMKOvTbD"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=Yjj5lHjc"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=Yjj5lHjc" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/86T7u6nfNTo" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com46http://googleonlinesecurity.blogspot.com/2008/05/safe-browsing-diagnostic-to-rescue.htmltag:blogger.com,1999:blog-1176949257541686127.post-83515192942301539072008-05-05T11:38:00.001-07:002008-05-05T13:04:15.421-07:002008-05-05T13:04:15.421-07:00Contributing To Open Source Software SecurityWritten by Will Drewry From <a id="t82-" title="operating systems" href="http://www.linux.org/" target="_blank">operating systems</a> to <a id="zafu" title="web browsers" href="http://www.mozilla.org/" target="_blank">web browsers</a>, open source software plays a critical role in the operation of the Internet. The security of open source software is therefore quite important, as it often interacts with personal information -- ranging from credit card numbers to medical records -- that needs to be kept safe. There has been a long-lived discussion on whether open source software is inherently more secure than closed source software. While popular opinion has begun to tilt in favor of openness, there are still arguments for both sides. Instead of diving into those treacherous waters (or giving weight to the idea of "inherent security"), I'd like to focus on the fruits of this extensive discussion. In particular, David A. Wheeler laid out a "bottom line" in his <a id="ldw." href="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/open-source-security.html">Secure Programming for Linux and Unix HOWTO</a> which applies to both open and closed source software. It predicates real security in software on three actions: <ol> <li>people need to actually review the code</li> <li>developers/reviewers need to know how to write secure code </li> <li>once found, security problems need to be fixed quickly, and their fixes distributed quickly</li> </ol> While distilling anything down to three steps makes it seem easy, this isn't necessarily the case. Given how important open source software is to Google, we've attempted to contribute to this bottom line. As Chris <a title="post" href="http://googleonlinesecurity.blogspot.com/2007/10/auditing-open-source-software.html" id="u6ym">said before</a>, our engineers are encouraged to contribute both software and time to open source efforts. We <a id="m0o9" href="http://www.google.com/search?hl=en&q=%22Google+Security+Team%22+CVE&btnG=Search">regularly submit</a> the results of our automated and manual security analysis of open source software back to the community, including related software engineering time. In addition, our engineering teams frequently release software under open source licenses. This software was written either with security in mind, such as with <a id="abc0" href="http://code.google.com/p/bunny-the-fuzzer/">security testing tools</a>, or by engineers well-versed in the <a id="ouhv" href="http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications">security challenges</a> of their project. These efforts leave one area completely unaddressed -- getting security problems fixed quickly, and then getting those fixes distributed quickly. It has been unclear how to best resolve this issue. There is no centralized security authority for open source projects, and operating system distribution publishers are the best bet for getting updates to the highest number of users. Even if users can get updates in this manner, how should a security researcher contact a particular project's author? If there's a potential, security-related issue, who can help evaluate the risk for a project? What resources are there for projects that have been compromised, but have no operational security background? I'm proud to announce that Google has sponsored participation in oCERT, the <a title="open source computer emergency response team" href="http://ocert.org/" id="xji8">open source computer emergency response team</a>. oCERT is a volunteer workforce of security professionals from the open source community with the goal of providing security vulnerability mediation and incident response services to open source projects. It will strive to contact software authors with all security reports and aid in debugging and patching, especially in cases where the author, or the reporter, doesn't have a background in security. Reliable contacts for projects, publishers, and vendors will be maintained where possible and used for notification when issues arise and fixes are available for mediated issues. Additionally, oCERT will aid projects of any size with responses to security incidents, such as server compromises. It is my hope that this initiative will not only aid in remediating security issues in a timely fashion, but also provide a means for additional security contributions to the open source community.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=khctcBYr"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=xXwmGswO"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=xXwmGswO" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/-DwFl8sEKd0" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com8http://googleonlinesecurity.blogspot.com/2008/05/contributing-to-open-source-software.htmltag:blogger.com,1999:blog-1176949257541686127.post-84300443003683595012008-02-11T13:57:00.001-08:002008-02-11T14:22:17.952-08:002008-02-11T14:22:17.952-08:00All Your iFrame Are Point to UsWritten by Niels Provos, Anti-Malware Team It has been over a year and a half since we started to identify web pages that infect vulnerable hosts via drive-by downloads, i.e. web pages that attempt to exploit their visitors by installing and running malware automatically. During that time we have investigated billions of URLs and found more than three million unique URLs on over 180,000 web sites automatically installing malware. During the course of our research, we have investigated not only the prevalence of drive-by downloads but also how users are being exposed to malware and how it is being distributed. Our research paper is currently under peer review, but we are making a <a href="http://research.google.com/archive/provos-2008a.pdf">technical report [PDF]</a> available now. Although our technical report contains a lot more detail, we present some high-level findings here: Search Results Containing a URL Labeled as Harmful <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp3.blogger.com/_LMSk7hTEaIE/R7DFFTZgEGI/AAAAAAAAGk0/eNxgOyjY3x4/s1600-h/harmful_search_result_pages.png"><img style="cursor: pointer;" src="http://bp3.blogger.com/_LMSk7hTEaIE/R7DFFTZgEGI/AAAAAAAAGk0/eNxgOyjY3x4/s400/harmful_search_result_pages.png" alt="" id="BLOGGER_PHOTO_ID_5165845467491209314" border="0" /></a> The above graph shows the percentage of daily queries that contain at least one search result labeled as harmful. In the past few months, more than 1% of all search results contained at least one result that we believe to point to malicious content and the trend seems to be increasing. Browsing Habits Good computer hygiene, such as running automatic updates for the operating system and third-party applications, as well as installing anti-virus products goes a long way in protecting your home computer. However, we have been wondering if users' browsing habits impact the likelihood of encountering malicious web pages. To study this aspect, we took a sample of ~7 million URLs and mapped them to <a title="DMOZ" href="http://www.dmoz.org/">DMOZ</a> categories. Although we found that adult web pages may increase the risk of exploitation, each DMOZ category was affected. Malicious Content Injection To understand if malicious content on a web server is due to poor web server security, we analyzed the version numbers reported by web servers on which we found malicious pages. Specifically, we looked at the Apache and the PHP versions exported as part of a server's response. We found that over 38% of both Apache and PHP versions were outdated increasing the risk of remote content injection to these servers. Our "<a href="http://www.usenix.org/event/hotbots07/tech/full_papers/provos/provos.pdf">Ghost In the Browser [PDF]</a>" paper highlighted third-party content as one potential vector of malicious content. Today, a lot of third-party content is due to advertising. To assess the extent to which advertising contributes to drive-by downloads, we analyze the distribution chain of malware, i.e. all the intermediary URLs a browser downloads before reaching a malware payload. We inspected each distribution chain for membership in about 2,000 known advertising networks. If any URL in the distribution chain corresponds to a known advertising network, we count the whole page as being infectious due to Ads. In our analysis, we found that on average 2% of malicious web sites were delivering malware via advertising. The underlying problem is that advertising space is often syndicated to other parties who are not known to the web site owner. Although non-syndicated advertising networks such as Google Adwords are not affected, any advertising networks practicing syndication needs to carefully study this problem. Our <a href="http://research.google.com/archive/provos-2008a.pdf">technical report [PDF]</a> contains more detail including an analysis based on the popularity of web sites. Structural Properties of Malware Distribution Finally, we also investigated the structural properties of malware distribution sites. Some malware distribution sites had as many as 21,000 regular web sites pointing to them. We also found that the majority of malware was hosted on web servers located in China. Interestingly, Chinese malware distribution sites are mostly pointed to by Chinese web servers. We hope that an analysis such as this will help us to better understand the malware problem in the future and allow us to protect users all over the Internet from malicious web sites as best as we can. One thing is clear - we have a lot of work ahead of us.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=9pBVMnpr"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=NYx2ZFD9"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=NYx2ZFD9" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/8rBZJF8OzRo" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com21http://googleonlinesecurity.blogspot.com/2008/02/all-your-iframe-are-point-to-us.htmltag:blogger.com,1999:blog-1176949257541686127.post-88700358238609786212007-11-29T14:28:00.000-08:002007-11-29T14:30:54.234-08:002007-11-29T14:30:54.234-08:00Help us fill in the gaps!Posted by Ian Fette <div>We've been targeting malware <a title="for over a year and a half" href="http://googleblog.blogspot.com/2006/01/putting-stop-to-spyware.html" id="ugj2">for over a year and a half</a>, and these efforts are paying off. We are now able to display warnings in search results when a site is known to be malicious, which can help you avoid drive-by downloads and other computer compromises. We are already distributing this data through the <a title="Safe Browsing API" href="http://code.google.com/apis/safebrowsing/" id="fice">Safe Browsing API</a>, and we are working on bringing this protection to more users by integrating with more Google products. While these are great steps, we need your help going forward!</div><div> </div><div> Currently, we know of hundreds of thousands of websites that attempt to infect people's computers with malware. Unfortunately, we also know that there are more malware sites out there. This is where we need your help in filling in the gaps. If you come across a site that is hosting malware, we now have an easy way for you to let us know about it. If you come across a site that is hosting malware, please fill out <a title="this short form" href="http://www.google.com/safebrowsing/report_badware/" id="y8or">this short form</a>. Help us keep the internet safe, and report sites that distribute malware. </div><div> </div><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=ofFSTbFa"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=FWfCNov9"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=FWfCNov9" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/8UHj7YhL4wI" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com33http://googleonlinesecurity.blogspot.com/2007/11/help-us-fill-in-gaps.htmltag:blogger.com,1999:blog-1176949257541686127.post-73950844754490027222007-10-08T16:13:00.000-07:002007-10-08T17:40:48.552-07:002007-10-08T17:40:48.552-07:00Auditing open source softwareWritten by Chris Evans, Security Team Google encourages its employees to contribute back to the open source community, and there is no exception in Google's Security Team. Let's look at some interesting open source vulnerabilities that were located and fixed by members of Google's Security team. It is interesting to classify and aggregate the code flaws leading to the vulnerabilities, to see if any particular type of flaw is more prevalent. <ol><li>JDK. In May 2007, I <a title="released details" href="http://scary.beasts.org/security/CESA-2006-004.html" id="ro-g">released details</a> on an interesting bug in the ICC profile parser in Sun's JDK. The bug is particularly interesting because it could be exploited by an evil image. Most previous JDK bugs involve a user having to run a whole evil applet. The key parts of code which demonstrate the bug are as follows: <blockquote><code style="font-size: 120%"> TagOffset = SpGetUInt32 (&Ptr); if (ProfileSize &lt TagOffset)   return SpStatBadProfileDir; ... TagSize = SpGetUInt32 (&Ptr); if (ProfileSize &lt TagOffset + TagSize)   return SpStatBadProfileDir; ... Ptr = (KpInt32_t *) malloc ((unsigned int)numBytes+HEADER); </code></blockquote> Both TagSize and TagOffset are untrusted unsigned 32-bit values pulled out of images being parsed. They are added together, causing a classic integer overflow condition and the bypass of the size check. A subsequent additional integer overflow in the allocation of a buffer leads to a heap-based buffer overflow. </li> <li>gunzip. In September 2006, my colleague Tavis Ormandy <a title="reported some interesting vulnerabilities" href="http://www.scary.beasts.org/security/tavis_gzip.txt" id="qbd9">reported some interesting vulnerabilities</a> in the gunzip decompressor. They were triggered when an evil compressed archive is decompressed. A lot of programs will automatically pass compressed data through gunzip, making it an interesting attack. The key parts of the code which demonstrate one of the bugs are as follows: <blockquote><code style="font-size: 120%"> ush count[17], weight[17], start[18], *p; ... for (i = 0; i &lt (unsigned)nchar; i++) count[bitlen[i]]++; </code></blockquote> Here, the stack-based array "count" is indexed by values in the "bitlen" array. These values are under the control of data in the incoming untrusted compressed data, and were not checked for being within the bounds of the "count" array. This led to corruption of data on the stack.</li> <li>libtiff. In August 2006, Tavis <a title="reported a range of security vulnerabilities" href="http://www.scary.beasts.org/security/tavis_libtiff.txt" id="lkkz">reported a range of security vulnerabilities</a> in the libtiff image parsing library. A lot of image manipulation programs and services will be using libtiff if they handle TIFF format files. So, an evil TIFF file could compromise a lot of desktops or even servers. The key parts of the code which demonstrate one of the bugs are as follows: <blockquote><code style="font-size: 120%"> if (sp->cinfo.d.image_width != segment_width ||     sp->cinfo.d.image_height != segment_height) {   TIFFWarningExt(tif->tif_clientdata, module,     "Improper JPEG strip/tile size, expected %dx%d, got %dx%d", </code></blockquote> Here, a TIFF file containing a JPEG image is being processed. In this case, both the TIFF header and the embedded JPEG image contain their own copies of the width and height of the image in pixels. This check above notices when these values differ, issues a warning, and continues. The destination buffer for the pixels is allocated based on the TIFF header values, and it is filled based on the JPEG values. This leads to a buffer overflow if a malicious image file contains a JPEG with larger dimensions than those in the TIFF header. Presumably the intent here was to support broken files where the embedded JPEG had smaller dimensions than those in the TIFF header. However, the consequences of larger dimensions that those in the TIFF header had not been considered.</li></ol> We can draw some interesting conclusions from these bugs. The specific vulnerabilities are integer overflows, out-of-bounds array accesses and buffer overflows. However, the general theme is using an integer from an untrusted source without adequately sanity checking it. Integer abuse issues are still very common in code, particular code which is decoding untrusted binary data or protocols. We recommend being careful using any such code until it has been vetted for security (by extensive code auditing, fuzz testing, or preferably both). It is also important to watch for security updates for any decoding software you use, and keep patching up to date.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=AIMgd86f"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=oa3ZHDNZ"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=oa3ZHDNZ" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/i5ZqGf1D0A4" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com6http://googleonlinesecurity.blogspot.com/2007/10/auditing-open-source-software.htmltag:blogger.com,1999:blog-1176949257541686127.post-42573082915204819542007-09-17T09:32:00.000-07:002007-09-17T09:38:34.858-07:002007-09-17T09:38:34.858-07:00Information flow tracing and software testingPosted by Will Drewry, Security Team Security testing of applications is regularly performed using fuzz testing. As previously discussed on this blog, <a href="http://googleonlinesecurity.blogspot.com/2007/07/automating-web-application-security.html" id="jmad" title="Srinath's Lemon">Srinath's Lemon</a> uses a form of smart fuzzing. Lemon is aware of classes of web application threats and the input families which trigger them, but not all fuzz testing frameworks have to be this complicated. Fuzz testing <a href="http://pages.cs.wisc.edu/%7Ebart/fuzz/fuzz.html" target="_blank">originally</a> relied on purely random data, ignorant of specific threats and known dangerous input. Today, this approach is often overlooked in favor of more complicated techniques. Early sanity checks in applications looking for something as a simple as a version number may render testing with completely random input ineffective. However, the newer, more complicated fuzz testers require a considerable initial investment in the form of complete input format specifications or the selection of a large corpus of initial input samples. At <a href="http://www.usenix.org/events/woot07/tech" target="_blank">WOOT'07</a>,I presented a <a href="http://www.google.com/search?hl=en&lr=&q=%22Flayer%3A+Exposing+Application+Internals%22" target="_blank">paper</a> on <a href="http://code.google.com/p/flayer" target="_blank">Flayer</a>, a tool we developed internally to augment our security testing efforts. In particular, it allows for a fuzz testing technique that compromises between the original idea and the most complicated. Flayer makes it possible to remove input sanity checks at execution time. With the small investment of identifying these checks, Flayer allows for completely random testing to be performed with much higher efficacy. Already, we've uncovered multiple vulnerabilities in Internet-critical software using this approach. The way that Flayer allows for sanity checks to be identified is perhaps the more interesting point. Flayer uses a <a href="http://valgrind.org/" target="_blank">dynamic analysis framework</a> to analyze the target application at execution time. Flayer marks, or taints, input to the program and traces that data throughout its lifespan. Considerable research has been done in the past regarding information flow tracing using dynamic analysis. Primarily, this work has been aimed at malware and exploit detection and defense. However, none of the resulting software has been made publicly available. While Flayer is still in its early stages, it is available for <a href="http://code.google.com/p/flayer/downloads/list" target="_blank">download</a> under the GNU Public License. External <a href="http://code.google.com/p/flayer/issues/list" id="wkck" title="contributions">contributions</a> and <a href="http://groups.google.com/group/flayer" id="w7dc" title="comments">feedback</a> <a href="http://code.google.com/p/flayer/issues/list" id="wkck" title="contributions"></a>are encouraged!<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=1j43BTcX"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=8tXSyvKG"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=8tXSyvKG" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/7kYSZQOeJgE" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com4http://googleonlinesecurity.blogspot.com/2007/09/information-flow-tracing-and-software.htmltag:blogger.com,1999:blog-1176949257541686127.post-71226520287009465392007-07-16T11:40:00.000-07:002007-07-18T09:45:38.546-07:002007-07-18T09:45:38.546-07:00Automating web application security testingPosted by Srinath Anantharaju, Security Team Cross-site scripting (aka XSS) is the term used to describe a class of security vulnerabilities in web applications. An attacker can inject malicious scripts to perform unauthorized actions in the context of the victim's web session. Any web application that serves documents that include data from untrusted sources could be vulnerable to XSS if the untrusted data is not appropriately sanitized. A web application that is vulnerable to XSS can be exploited in two major ways:     Stored XSS - Commonly exploited in a web application where one user enters information that's viewed by another user. An attacker can inject malicious scripts that are executed in the context of the victim's session. The exploit is triggered when a victim visits the website at some point in the future, such as through improperly sanitized blog comments and guestbook entries, which facilitates stored XSS.     Reflected XSS - An application that echoes improperly sanitized user input received as query parameters is vulnerable to reflected XSS. With a vulnerable application, an attacker can craft a malicious URL and send it to the victim via email or any other mode of communication. When the victim visits the tampered link, the page is loaded along with the injected script that is executed in the context of the victim's session. The general principle behind preventing XSS is the proper sanitization (via, for instance, escaping or filtering) of all untrusted data that is output by a web application. If untrusted data is output within an HTML document, the appropriate sanitization depends on the specific context in which the data is inserted into the HTML document. The context could be in the regular HTML body, tag attributes, URL attributes, URL query string attributes, style attributes, inside JavaScript, HTTP response headers, etc. The following are some (by no means complete) examples of XSS vulnerabilities. Let's assume there is a web application that accepts user input as the 'q' parameter. Untrusted data coming from the attacker is marked in red. <ul> <li>Injection in regular HTML body - angled brackets not filtered or escaped Your query '<script>evil_script()</script>' returned xxx results </li> <li>Injection inside tag attributes - double quote not filtered or escaped <form ...   <input name="q" value="blah"><script>evil_script()</script>"> </form></li> <li>Injection inside URL attributes - non-http(s) URL <img src="http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml/<font" color="#ff0000">javascript:evil_script()">...</img></li> <li>In JavaScript context - single quote not filtered or escaped <script>   var msg = 'blah'; evil_script(); //';   // do something with msg variable </script></li></ul> In the cases where XSS arises from meta characters being inserted from untrusted sources into an HTML document, the issue can be avoided either by filtering/disallowing the meta characters, or by escaping them appropriately for the given HTML context. For example, the HTML meta characters <, >, &, " and ' must be replaced with their corresponding HTML entity references &lt;, &gt;, &amp;, &quot; and &#39 respectively. In a JavaScript-literal context, inserting a backslash in front of \, ', " and converting the carriage returns, line-feeds and tabs into \r, \n and \t respectively should avoid untrusted meta characters being interpreted as code. How about an automated tool for finding XSS problems in web applications? Our security team has been developing a black box fuzzing tool called Lemon (deriving from the commonly-recognized name for a defective product). Fuzz testing (also referred to as fault-injection testing) is an automated testing approach based on supplying inputs that are designed to trigger and expose flaws in the application. Our vulnerability testing tool enumerates a web application's URLs and corresponding input parameters. It then iteratively supplies fault strings designed to expose XSS and other vulnerabilities to each input, and analyzes the resulting responses for evidence of such vulnerabilities. Although it started out as an experimental tool, it has proved to be quite effective in finding XSS problems. Besides XSS, it finds other security problems such as response splitting attacks, cookie poisoning problems, stacktrace leaks, encoding issues and charset bugs. Since the tool is homegrown it is easy to integrate into our automated test environment and to extend based on specific needs. We are constantly in the process of adding new attack vectors to improve the tool against known security problems. Update: I wanted to respond to a few questions that seem to be common among readers. I've listed them below. Thanks for the feedback. Please keep the questions and comments coming. Q. Does Google plan to market it at some point? A. Lemon is highly customized for Google apps and we have no plans of releasing it in near future. Q. Did Google's security team check out any commercially available fuzzers? Is the ability to keep improving the fuzzer the main draw of a homegrown tool? A. We did evaluate commercially available fuzzers but felt that our specialized needs could be served best by developing our own tools.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=Pa8aZIiW"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=L65GyLjv"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=L65GyLjv" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/TfI6M87e-00" height="1" width="1"/>Panayiotis Mavrommatisnoreply@blogger.com21http://googleonlinesecurity.blogspot.com/2007/07/automating-web-application-security.htmltag:blogger.com,1999:blog-1176949257541686127.post-44736271034777407602007-07-09T11:54:00.000-07:002007-07-09T13:31:18.880-07:002007-07-09T13:31:18.880-07:00The reason behind the "We're sorry..." message<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_wLESxcF8BBY/RpKG2OwJMgI/AAAAAAAABZY/MUEcZfcOBgU/s1600-h/wearesorry.jpg"><img style="cursor:pointer; cursor:hand;" src="http://bp1.blogger.com/_wLESxcF8BBY/RpKG2OwJMgI/AAAAAAAABZY/MUEcZfcOBgU/s400/wearesorry.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5085275195485794818" /></a> Posted by Niels Provos, Anti-Malware Team Some of you might have seen this message while searching on Google, and wondered what the reason behind it might be. Instead of search results, Google displays the "We're sorry" message when we detect anomalous queries from your network. As a regular user, it is possible to answer a <a href="http://en.wikipedia.org/wiki/Captcha" title="captcha">CAPTCHA</a> - a reverse Turing test meant to establish that we are talking to a human user - and to continue searching. However, automated processes such as worms would have a much harder time solving the CAPTCHA. Several things can trigger the sorry message. Often it's due to infected computers or DSL routers that proxy search traffic through your network - this may be at home or even at a workplace where one or more computers might be infected. Overly aggressive SEO ranking tools may trigger this message, too. In other cases, we have seen self-propagating worms that use Google search to identify vulnerable web servers on the Internet and then exploit them. The exploited systems in turn then search Google for more vulnerable web servers and so on.  This can lead to a noticeable increase in search queries and sorry is one of our mechanisms to deal with this. At <a href="http://www.eecs.umich.edu/%7Efarnam/worm2006.html" title="ACM WORM 2006">ACM WORM 2006</a>, we published a paper on <a href="http://www.citi.umich.edu/u/provos/papers/search_worms.pdf" title="Search Worms">Search Worms [PDF]</a> that takes a much closer look at this phenomenon. <a href="http://en.wikipedia.org/wiki/Santy" title="Santy">Santy</a>, one of the search worms we analyzed, looks for remote-execution vulnerabilities in the popular phpBB2 web application. In addition to exhibiting worm like propagation patterns, Santy also installs a botnet client as a payload that connects the compromised web server to an IRC channel. Adversaries can then remotely control the compromised web servers and use them for DDoS attacks, spam or phishing. Over time, the adversaries have realized that even though a botnet consisting of web servers provides a lot of aggregate bandwidth, they can increase leverage by changing the content on the compromised web servers to infect visitors and in turn join the computers of compromised visitors into much larger botnets. This fundamental change from remote attack to client based download of malware formed the basis of the research presented in our <a href="http://googleonlinesecurity.blogspot.com/2007/05/introducing-googles-anti-malware.html" title="first blog post">first post</a>. In retrospect, it is interesting to see how two seemingly unrelated problems are tightly connected. <div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=6lpV88Pv"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=sJgLero5"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=sJgLero5" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/9u8XD-RwN54" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com50http://googleonlinesecurity.blogspot.com/2007/07/reason-behind-were-sorry-message.htmltag:blogger.com,1999:blog-1176949257541686127.post-57754080389800802542007-06-18T14:59:00.000-07:002007-06-18T15:04:05.168-07:002007-06-18T15:04:05.168-07:00Phishers and Malware authors beware!Posted by Brian Rakowski and Garrett Casto, Anti-Phishing and Anti-Malware Teams OK, so it might be a little early to declare victory, but we're excited about the <a href="http://code.google.com/apis/safebrowsing/overview.html" title="Safe Browsing API">Safe Browsing API</a> we launched today. It provides a simple mechanism for downloading Google's lists of suspected phishing and malware URLs, so now any developer can access the blacklists used in products such as Firefox and Google Desktop. The API is still experimental, but we hope it will be useful to ISPs, web-hosting companies, and anyone building a site or an application that publishes or transmits user-generated links. <a href="http://code.google.com/apis/safebrowsing/key_signup.html" title="Sign up for an API key">Sign up for a key</a> and let us know how we can make the API better. We fully expect to iterate on the design and improve the data behind the API, and we'll be paying close attention to your <a href="http://groups.google.com/group/google-safe-browsing-api" title="user feedback">feedback</a> as we do that. We look forward to hearing your thoughts. <div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=MnGtSkPd"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=zUrZ2tgv"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=zUrZ2tgv" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/9i5EnfT68pU" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com11http://googleonlinesecurity.blogspot.com/2007/06/phishers-and-malware-authors-beware.htmltag:blogger.com,1999:blog-1176949257541686127.post-52146408203450124382007-06-11T11:35:00.000-07:002007-06-11T12:01:34.239-07:002007-06-11T12:01:34.239-07:00Thwarting a large-scale phishing attackPosted by Colin Whittaker, Anti-Phishing Team In addition to targeting malware, we're interested in combating <a href="http://en.wikipedia.org/wiki/Phishing" title="Phishing">phishing,</a> a social engineering attack where criminals attempt to lure unsuspecting web surfers into logging into a fake website that looks like a real website, such as eBay, E-gold or an online bank. Following a successful attack, phishers can steal money out of the victims' accounts or take their identities. To protect our users against phishing, we publish a blacklist of known phishing sites. This blacklist is the basis for the anti-phishing features in the latest versions of Firefox and Google Desktop. Although blacklists are necessarily a step behind as phishers move their phishing pages around, blacklists have proved to be reasonably effective.Not all phishing attacks target sites with obvious financial value. Beginning in mid-March, we detected a five-fold increase in overall phishing page views. It turned out that the phishing pages generating 95% of the new phishing traffic targeted <a href="http://myspace.com/" title="MySpace">MySpace</a>, the popular social networking site. While a MySpace account does not have any intrinsic monetary value, phishers had come up with ways to monetize this attack. We observed hijacked accounts being used to spread bulletin board spam for some advertising revenue. According to <a href="http://ha.ckers.org/blog/20070508/phishing-social-networking-sites/" title="this interview with a phisher">this interview with a phisher</a>, phishers also logged in to the email accounts of the profile owners to harvest financial account information. In any case, phishing MySpace became profitable enough (more than phishing more traditional targets) that many of the active phishers began targeting it.Interestingly, the attack vector for this new attack appeared to be MySpace itself, rather than the usual email spam. To observe the phishers' actions, we fed them the login information for a dummy MySpace account. We saw that when phishers compromised a MySpace account, they added links to their phishing page on the stolen profile, which would in turn result in additional users getting compromised. Using a quirk of the CSS supported in MySpace profiles, the phishers injected these links invisibly as see-through images covering compromised profiles. Clicking anywhere on an infected profile, including on links that appeared normal, redirected the user to a phishing page. Here's a sample of some CSS code injected into the "About Me" section of an affected profile: <a style="text-decoration:none;position: absolute;top:1px;left:1px;" href="http://myspacev.net"><img style="border-width:0px;width:1200px; height:650px;" src="http://x.myspace.com/images/clear.gif"></a></style> In addition to contributing to the viral growth of the phishing attack, linking directly off of real MySpace content added to the appearance of legitimacy of these phishing pages. In fact, we received thousands of complaints from confused users along the lines of "Why won't it let any of my friends look at my pictures?" regarding our warnings on these phishing pages, suggesting that even an explicit warning was not enough to protect many users. The effectiveness of the attack and the increasing sophistication of the phishing pages, some of which were hosted on <a href="http://www.google.com/search?q=botnets" title="botnets">botnets</a> and were near perfect duplications of MySpace's login page, meant that we needed to switch tactics to combat this new threat. In late March, we reached out to MySpace to see what we could do to help. We provided lists of the top phishing sites and our anti-phishing blacklist to MySpace so that they could disable compromised accounts with links to those sites. Unfortunately, many of the blocked users did not remove the phishing links when they reactivated their accounts, so the attacks continued to spread. On April 19, MySpace updated their server software so that they could disable bad links in users' profiles without requiring any user action or altering any other profile content. Overnight, overall phishing traffic dropped by a factor of five back to the levels observed in early March. While MySpace phishing continues at much lower volumes, phishers are beginning to move on to new targets. Things you can do to help end phishing and Internet fraud <ul><li>Learn to recognize and avoid phishing. The Anti-Phishing Working Group has a good <a href="http://www.antiphishing.org/consumer_recs.html" title="list of recommendations">list of recommendations</a>. </li> <li>Update your software regularly and run an anti-virus program. If a cyber-criminal gains control of your computer through a virus or a software security flaw, he doesn't need to resort to phishing to steal your information. </li> <li>Use different passwords on different sites and change them periodically. Phishers routinely try to log in to high-value targets, like online banking sites, with the passwords they steal for lower-value sites, like webmail and social networking services.</li></ul><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=VnRAFITW"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=XJxTGYDk"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=XJxTGYDk" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/TAdiNY9kH6o" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com13http://googleonlinesecurity.blogspot.com/2007/06/thwarting-large-scale-phishing-attack.htmltag:blogger.com,1999:blog-1176949257541686127.post-28808624296220706902007-06-05T09:30:00.000-07:002007-06-05T10:00:07.110-07:002007-06-05T10:00:07.110-07:00Web Server Software and MalwarePosted by Nagendra Modadugu, Anti-Malware Team In this post, we investigate the distribution of web server software to provide insight into how server software is correlated to servers hosting malware binaries or engaging in drive-by-downloads. We determine server operating system by examining the 'Server:' HTTP header reported by most web servers. A survey of servers running roughly 80 million domain names reveals the web server software distribution shown below. Note that these figures may have some margin of error as it is not unusual to find hundreds of domains served by a single IP address. Web server software across the Internet. <div align="center"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_LMSk7hTEaIE/RmWVdyEWsCI/AAAAAAAAEqg/iXdunlloTHc/s1600-h/image1.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_LMSk7hTEaIE/RmWVdyEWsCI/AAAAAAAAEqg/iXdunlloTHc/s400/image1.png" alt="" id="BLOGGER_PHOTO_ID_5072624894191513634" border="0" /></a> Web server software distribution across the Internet. </div> Our numbers report a slightly larger fraction of Apache servers compared to the <a href="http://news.netcraft.com/archives/web_server_survey.html" title="Netcraft web server survey">Netcraft web server survey</a>. Our analysis is based on crawl information and only root URLs were examined, therefore hosts that did not present a root URL (e.g. /index.htm) were not included in the statistics. This may have contributed to the disparity with the Netcraft numbers. Amongst Apache servers, about 35% did not report any version information. Presumably the lack of version information is considered to be a defense against version specific attacks and worms. We observed a long tail of Apache server versions; the top three detected were 1.3.37 (15%), 1.3.33 (7.91%), and 2.0.54 (6.25%). Amongst Microsoft servers, IIS 6.0 is by far the most popular version, making up about 80% of all IIS servers. IIS 5.0 made up most of the remainder. Web server software across servers distributing malware. We examined about 70,000 domains that over the past month have been either distributing malware or have been responsible for hosting browser exploits leading to drive-by-downloads. The breakdown by server software is depicted below. It is important to note that while many servers serve malware as a result of a server compromise (by remote exploits, password theft via keyloggers, etc.), some servers are configured to serve up exploits by their administrators. <div align="center"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_LMSk7hTEaIE/RmWVoSEWsDI/AAAAAAAAEqo/EZmG71AhWHI/s1600-h/image2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_LMSk7hTEaIE/RmWVoSEWsDI/AAAAAAAAEqo/EZmG71AhWHI/s400/image2.png" alt="" id="BLOGGER_PHOTO_ID_5072625074580140082" border="0" /></a> Web server software distribution across malicious servers. </div> Compared to our sample of servers across the Internet, Microsoft IIS features twice as often (49% vs. 23%) as a malware distributing server. Amongst Microsoft IIS servers, the share of IIS 6.0 and IIS 5.0 remained the same at 80% and 20% respectively. The distribution of top featured Apache server versions was different this time: 1.3.37 (50%), 1.3.34 (12%) and 1.3.33 (5%). 21% of the Apache servers did not report any version information. Incidentally, version 1.3.37 is the latest Apache server release in the 1.3 series, and it is hence somewhat of a surprise that this version features so prominently. One other factor we observe is a vast collection of Apache modules in use. Distribution of web server software by country. <div style="padding: 1em 0pt; text-align: left;" align="center"> <table> <tbody><tr><td> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp1.blogger.com/_LMSk7hTEaIE/RmWV6CEWsEI/AAAAAAAAEqw/S9h_8dW_NtQ/s1600-h/image3.png"><img style="cursor: pointer;" src="http://bp1.blogger.com/_LMSk7hTEaIE/RmWV6CEWsEI/AAAAAAAAEqw/S9h_8dW_NtQ/s400/image3.png" alt="" id="BLOGGER_PHOTO_ID_5072625379522818114" border="0" /></a> Web server distribution by country</td><td> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_LMSk7hTEaIE/RmWWCyEWsFI/AAAAAAAAEq4/5kIjQoX1s4E/s1600-h/image4.png"><img style="cursor: pointer;" src="http://bp0.blogger.com/_LMSk7hTEaIE/RmWWCyEWsFI/AAAAAAAAEq4/5kIjQoX1s4E/s400/image4.png" alt="" id="BLOGGER_PHOTO_ID_5072625529846673490" border="0" /></a> Malicious web server distribution by country </td><td> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp2.blogger.com/_LMSk7hTEaIE/RmWWJSEWsGI/AAAAAAAAErA/y-xbrVReUXs/s1600-h/image5.png"><img style="cursor: pointer;" src="http://bp2.blogger.com/_LMSk7hTEaIE/RmWWJSEWsGI/AAAAAAAAErA/y-xbrVReUXs/s400/image5.png" alt="" id="BLOGGER_PHOTO_ID_5072625641515823202" border="0" /></a> </td></tr></tbody></table> <div style="padding: 1em 0pt;"> The figure on the left shows the distribution of all Apache, IIS, and nginx webservers by country. Apache has the largest share, even though there is noticeable variation between countries. The figure on the right shows the distribution, by country, of webserver software of servers either distributing malware or hosting browser exploits. It is very interesting to see that in China and South Korea, a malicious server is much more likely to be running IIS than Apache. We suspect that the causes for IIS featuring more prominently in these countries could be due to a combination of factors: first, automatic updates have not been enabled due to software piracy (piracy statistics from <a href="http://www.nationmaster.com/graph/cri_sof_pir_rat-crime-software-piracy-rate" title="Nationmaster">NationMaster</a>, and <a href="http://www.bsa.org/globalstudy/" title="BSA">BSA</a>), and second, some security patches are not available for pirated copies of Microsoft operating systems. For instance the patch for a commonly seen ADODB.Stream exploit is <a href="http://www.microsoft.com/downloads/details.aspx?FamilyID=4D056748-C538-46F6-B7C8-2FBFD0D237E3&DisplayLang=en" title="not available to pirated copies">not available to pirated copies</a> of Windows operating systems. Overall, we see a mix of results. In Germany, for instance, Apache is more likely to be serving malware than Microsoft IIS, compared to the overall distributions of these servers. In Asia, we see the reverse, which is part of the cause of Microsoft IIS having a disproportionately high representation at 49% of malware servers. In summary, our analysis demonstrates how important it is to keep web servers patched to the latest patch level. </div> </div><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=Yp6w47R5"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=BKQi63or"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=BKQi63or" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/meEMq7oHLCk" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com26http://googleonlinesecurity.blogspot.com/2007/06/web-server-software-and-malware.htmltag:blogger.com,1999:blog-1176949257541686127.post-73044775238817027342007-05-29T16:20:00.000-07:002007-05-29T16:26:03.133-07:002007-05-29T16:26:03.133-07:00On virtualisationPosted by Tavis Ormandy, Security Team Following <a title="Panayiotis' and Niels' post" href="http://googleonlinesecurity.blogspot.com/2007/05/introducing-googles-anti-malware.html">Panayiotis' and Niels' post</a> on malware, I'd like to discuss a somewhat related topic, virtualisation. Virtual machines are often used by security researchers to sandbox malware samples for analysis, or to protect a machine from a potentially hazardous activity. The theory is that any security threat or malicious behaviour will be restricted to the virtual environment which can be discarded and then restored to pristine condition after use. Virtual machines are sometimes thought of as impenetrable barriers between the guest and host, but in reality they're (usually) just another layer of software between you and the attacker. As with any complex application, it would be naive to think such a large codebase could be written without some serious bugs creeping in. If any of those bugs are exploitable, attackers restricted to the guest could potentially break out onto the host machine. I investigated this topic earlier this year, and presented a <a href="http://taviso.decsystem.org/virtsec.pdf">paper</a> at <a href="http://cansecwest.com/">CanSecWest</a> on a number of ways that an attacker could break out of a virtual machine. Most of the attacks identified were flaws, such as buffer overflows, in emulated hardware devices. One example of this is missing bounds checking in <a href="http://www.google.com/search?q=bitblt">bitblt routines</a>, which are used for moving rectangular blocks of data around the display. If exploited, by specifying pathological parameters for the operation, this could lead to an attacker compromising the virtual machine process. While you would typically require root (or equivalent) privileges in the guest to interact with a device at the low level required, device drivers will often offload the parameter checking required onto the hardware, so in theory an unprivileged attacker could be able to access flaws like this by simply interacting with the regular API or system call interface provided by the guest operating system. While researching this topic we worked with the vendors affected to make sure they were aware of our findings, and provided patches where possible. I've also suggested some precautions virtualization you can take to minimise the impact of any flaws like this discovered in future, such as: <h3> Reduce the attack surface </h3> By disabling emulated devices, features and services you don't need you reduce the amount of code exposed to an attacker, thus reducing the number of possible bugs that can be exploited. You should also aim to protect the integrity of the guest operating system, making it harder for an attacker to get lower level access to emulated hardware. By keeping software in the guest up to date, and hardening it by locking down the operating system and minimising what is run with root or admin privileges, you can reduce the risk of privilege escalation attacks. If an attacker cannot get low level access to the emulated hardware, it will be more difficult to exploit the bugs in them. Remember that some legacy operating systems make no attempt to restrict access to I/O ports and similar interfaces, these should be used with caution in a security sensitive context. <h3> Treat virtual machines as services that can be compromised </h3> Most administrators will take steps to limit the impact of a compromise of a network facing daemon, such as using chroot() or running the daemon as a low privileged user. These same tactics can be applied to your virtual machine. As always, try to minimise what has to run as root or administrator. <h3> Keep software up to date </h3> Keep your virtual machine software up to date, and look out for any security advisories from your vendor so that you can apply any patches promptly.<div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=3zcJ5JNU"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=0tiGJaFt"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=0tiGJaFt" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/rGHe6RqY0ec" height="1" width="1"/>Niels Provoshttp://www.blogger.com/profile/17807363822730767592noreply@blogger.com6http://googleonlinesecurity.blogspot.com/2007/05/on-virtualisation.htmltag:blogger.com,1999:blog-1176949257541686127.post-16286482251893310592007-05-21T09:43:00.000-07:002007-05-21T23:07:47.054-07:002007-05-21T23:07:47.054-07:00Introducing Google's online security effortsPosted by Panayiotis Mavrommatis and Niels Provos, Anti-Malware Team Online security is an important topic for Google, our users, and anyone who uses the Internet. The related issues are complex and dynamic and we've been looking for a way to foster discussion on the topic and keep users informed. Thus, we've started this blog where we hope to periodically provide updates on recent trends, interesting findings, and efforts related to online security. Among the issues we'll tackle is malware, which is the subject of our inaugural post. Malware -- surreptitious software capable of stealing sensitive information from your computer -- is increasingly spreading over the web. Visiting a compromised web server with a vulnerable browser or plugins can result in your system being infected with a whole variety of malware without any interaction on your part. Software installations that leverage exploits are termed "drive-by downloads". To protect Google's users from this threat, we started an anti-malware effort about a year ago. As a result, we can warn you in our <a href="http://www.google.com/support/bin/answer.py?answer=45449&query=badware&topic=&type=">search results</a> if we know of a site to be harmful and even prevent exploits from loading with <a href="http://desktop.google.com/support/bin/answer.py?answer=61640&amp;amp;amp;amp;amp;query=malware&topic=&type=">Google Desktop Search</a>. Unfortunately, the scope of the problem has recently been somewhat misreported to suggest that one in 10 websites are potentially malicious. To clarify, a sample-based analysis puts the fraction of malicious pages at roughly 0.1%. The analysis described in our <a href="http://www.usenix.org/events/hotbots07/tech/full_papers/provos/provos.pdf" title="The Ghost In The Browser: Analysis of Web-based Malware">paper</a> covers billions of URLs. Using targeted feature extraction and classification, we select a subset of URLs believed to be suspicious for in-depth investigation. So far, we have investigated about 12 million suspicious URLs and found about 1 million that engage in drive-by downloads. In most cases, the web sites that infect your system with malware are not intentionally doing so and are often unaware that their web servers have been compromised. To get a better understanding about the geographic distribution of sites engaging in drive-by downloads, we analyzed the location of compromised web sites and the location of malware distribution hosts. At the moment, the majority of malware activity seems to happen in China, the U.S., Germany and Russia (see below): <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_7ZYqYi4xigk/Rkygiz4PreI/AAAAAAAAAA0/oQiuMJFi3XM/s1600-h/2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_7ZYqYi4xigk/Rkygiz4PreI/AAAAAAAAAA0/oQiuMJFi3XM/s400/2.png" alt="" id="BLOGGER_PHOTO_ID_5065600200787078626" border="0" /></a>Location of compromised web sites. These are often sites that are benign in nature but have been compromised and have become dangerous for users to visit. <div style="padding: 1em 0pt; text-align: left;"> <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://bp0.blogger.com/_7ZYqYi4xigk/Rkyguz4PrfI/AAAAAAAAAA8/zQosxmqla_I/s1600-h/File.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp0.blogger.com/_7ZYqYi4xigk/Rkyguz4PrfI/AAAAAAAAAA8/zQosxmqla_I/s400/File.png" alt="" id="BLOGGER_PHOTO_ID_5065600406945508850" border="0" /></a>Location of malware distribution servers. These are servers that are used by malware authors to distribute their payload. Very often the compromised sites are modified to include content from these servers. The color coding works as follows: Green means that we did not find anything unsual in that country, yellow means low activity, orange medium activity and red high activity. <div style="padding: 1em 0pt; text-align: left;"> Guidelines on safe browsing First and foremost, enable automatic updates for your operating system as well your browsers, browser plugins and other applications you are using. Automatic updates ensure that your computer receives the latest security patches as they are published. We also recommend that you run an anti-virus engine that checks network traffic and files on your computer for known malware and abnormal behavior. If you want to be really sure that your system does not become permanently compromised, you might even want to run your browser in a virtual machine, which you can revert to a clean snapshot after every browsing session. Webmasters can learn more about cleaning, and most importantly, keeping their sites secure at <a href="http://www.stopbadware.org/home/security" target="_blank" title="StopBadware.org's Tips for Cleaning and Securing a Website">StopBadware.org's Tips for Cleaning and Securing a Website</a>. </div></div><div class="feedflare"> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=uIBuON5F"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?d=41" border="0"></img></a> <a href="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?a=5KrZnz09"><img src="http://feedproxy.google.com/~f/GoogleOnlineSecurityBlog?i=5KrZnz09" border="0"></img></a> </div><img src="http://feedproxy.google.com/~r/GoogleOnlineSecurityBlog/~4/HpXUlaY-ndY" height="1" width="1"/>A Googlernoreply@blogger.com47http://googleonlinesecurity.blogspot.com/2007/05/introducing-googles-anti-malware.html

News	and	insights	from
on	security	and	safety	on
the	Internet.	[Atom]

http://feeds.feedburner.com/GoogleOnlineSecurityBlog?format=xml

Google Online Security Blog 2009 January

dvd rental

dvd

News and insights from on security and safety on the Internet. [Atom]

Rules

Recommended Sites: 1. Arts - Business - Computers - Games - Health - Home - Kids and Teens - News - Recreation - Reference - Regional - Science - Shopping - Society - Sports - World Miss Gallery - Top Anime Hentai - DVD rental by mail - Bad Credit Mortgages - Credit Cards - Credit Cards - Free Ringtones - Ringtones Ksiazka - Klimatyzacja - Sp�ywy Kajakowe - Imprezy Dla Firm - W�osy

2009-01-08 23:52:52

Copyright 2006 by Rules

--BEGIN VALIDATION CODE--
C lXqKnJlR sU sMoCzNcP sOgSjM oIc MlGmMuRtC iXzA iJaR rZaQ iDpCbRqAcPrN iGd DlOrK gI jG tTx T yHkE dUtEkFsDoOxNcAz MlLnZ nGiCrWnQ eRmI bKrO e WuR cLzI cVaYeIiTkXj CjFzF qByI x MlPxAqYcH q J bWbEk EkWw BuHiN cSpDnW oJ