Posts Tagged ‘Google’

Friday, August 29, 2014 @ 02:08 PM gHale

Thinking security while creating software is a must that more designers need to consider these days because not going that route is a recipe for disaster. Just ask Target.

That is why security researchers from Cigital, Google, Twitter, HP, McAfee, EMC, RSA, Harvard University, George Washington University, Athens University of Economics and Business, the Sandosky Foundation, and the University of Washington joined up with the IEEE Center for Secure Design and published a report looking at 10 of the most common software security design flaws.

RELATED STORIES
New Threats Emerging: Cisco Report
Social Network Security Risks Rampant
Faux Security Program is a RAT
Android RAT can Take Control

IEEE Computer Society Center for Secure Design Participants are, Iván Arce, Sadosky Foundation; Neil Daswani, Twitter; Jim DelGrosso, Cigital; Danny Dhillon, RSA; Christoph Kern, Google; Tadayoshi Kohno, University of Washington; Carl Landwehr, George Washington University; Gary McGraw, Cigital; Brook Schoenfield, McAfee, Part of Intel Security Group; Margo Seltzer, Harvard University; Diomidis Spinellis, Athens University of Economics and Business; Izar Tarandach, EMC, and Jacob West, HP.

The organizations came up with a top 10 list during a workshop session this spring, where each brought examples of design flaws it had experienced.

So far the security industry targets finding and eradicating security vulnerabilities. But design flaws, such as using encryption incorrectly or not validating data properly, can also end up exploited by attackers or lead to security bugs. As a matter of fact, these issues could be more difficult to eradicate as they built in. That is one reason why software designers need to think about security as they create the software.

Target’s data breach ended up being a design flaw leading to a hack.

The report recommends how to prevent each of the 10 most common software security design flaws:
1. Earn or give, but never assume, trust.
2. Use an authentication mechanism that cannot end up bypassed or tampered with.
3. Authorize after you authenticate.
4. Strictly separate data and control instructions, and never process control instructions received from untrusted sources.
5. Define an approach that ensures all data end up explicitly validated.
6. Use cryptography correctly.
7. Identify sensitive data and how you should handle it.
8. Always consider the users.
9. Understand how integrating external components changes your attack surface.
10. Be flexible when considering future changes to objects and actors.

Click here to view the full report.

Friday, August 15, 2014 @ 03:08 PM gHale

Google rolled out version 36 of the Chrome browser for Windows, Mac and Linux, including a set of security fixes, along with the latest revision of Flash Player.

Twelve vulnerabilities ended up fixed in this release, with some found by external security researchers, who earned cash for their efforts through Google’s bug bounty program.

RELATED STORIES
Security Updates for Firefox
IE Browser of Choice for Attacks
Flaw in Chrome Speech Recognition API
Chrome Update Includes 31 Security Fixes

For a use-after-free security flaw (CVE-2014-3165) in web sockets, Google paid $2,000 to researcher Collin Payne; additional information about this flaw is not available right now.

From another external researcher, the Google team received details about a security glitch that could lead to information disclosure in SPDY. Identified as CVE-2014-3166, the discovery goes to Antoine Delignat-Lavaud, second year PhD student in team Prosecco at Inria Paris.

In order to prevent the information leakage, Chrome developers decided to disable SPDY and QUIC session pooling in the latest revision of the web browser.

SPDY is a network protocol designed to increase page load speed and security, by manipulating HTTP traffic.

Disabling it translates to the user into slower page loads on websites using this protocol, but the latency is not as significant as to affect browsing at all.

Additional input came from the internal security team, who discovered an undisclosed number of glitches through internal audits or code fuzzing operations.

Build 36.0.1985.143 of the web browser also updates the Adobe Flash Player plug-in to the recently released version 14.0.0.177.

Adobe patched seven critical vulnerabilities, most of them referring to memory leaks that could end up taken advantage of for bypassing memory protection mechanisms (address randomization).

Thursday, June 19, 2014 @ 04:06 PM gHale

Mobile operating systems have their plusses and their minuses depending on needs and desires, but when it comes to using your own devices, well, it is a coin toss between Android and iOS.

A threat report around the BYOD (Bring Your Own Device) theme shows that in an enterprise environment, neither operating system “is inherently more secure than the other,” said researchers at security firm Marble Security.

RELATED STORIES
Breaches Continue Upward Trend
Attackers Exploit Privileged Accounts
Cloud Breach: Cost 3 Times Higher
How Attackers Bypass Security: Report

The report found despite Apple’s tight app distribution control, a non-jailbroken iOS device can still download software from enterprise app market places, through various testing apps and programs.

These allow installation of apps from websites with no more effort than a tap on the screen, thus allowing for more or less the same risks as in the case of Android devices.

Google Bouncer, the engine that checks the apps for malicious code before they end up listed in the store, is quite efficient, but, as Marble Security said, it “cannot protect users from installing apps from other marketplaces.”

A threat matrix comparing the two platforms shows the weak spots of the two platforms, both vulnerable to most of the attack types presented.

While iOS is not susceptible to sideloading apps and harvesting phone call and SMS logs, Android is resistant to hostile configuration profiles, which on iOS can occur while visiting a website.

But both of them are vulnerable to different types of phishing (regular phishing, spear-phishing, SMS-phishing and app-phishing), address book mining, jailbreaking and rooting, SSL weaknesses, unencrypted mail attachments, ransomware and backup jacking.

Ransomware threats are present on both platforms, as the latest reports of this type of incidents on iOS are no older then the month of May, this year; on Google’s mobile platform these events are even more recent, more frequent and can be more complex in nature.

“Both iOS and Android are complex operating systems, and will continue to grow in complexity over time. Major new features such as Siri for voice navigation have revealed serious security holes that may expose user contact data and phone address books. As the operating systems evolve, they will no doubt improve security, but as they add features, new security holes will emerge,” the report said.

Wednesday, June 4, 2014 @ 12:06 PM gHale

Iran-based hackers used fake personas on Facebook, Twitter, LinkedIn, Google+, YouTube and Blogger to fire up a cyber espionage campaign targeting U.S. and Israeli officials.

Security firm iSight Partners tracked the campaign to a group of Iranian hackers which it said gathered over 2,000 victims across the globe in an operation called “Newscaster.”

RELATED STORIES
Big Data a Cyber Protector
ARC: Securing Internet of Things
Home Automation Devices Open to Attack
Top 10 DDoS Attack Trends

“This campaign, working undetected since 2011, targets senior U.S. military and diplomatic personnel, congressional personnel, Washington DC area journalists, U.S. think tanks, defense contractors in the U.S. and Israel, as well as others who are vocal supporters of Israel to covertly obtain log-in credentials to the email systems of their victims,” read the report.

http://www.isightpartners.com/2014/05/newscaster-iranian-threat-inside-social-media/

The attacks targeted people with requests from fake online personas claiming to work in journalism, government and defense contracting.

“These credible personas connected, linked, followed and ‘friended’ target victims, giving them access to information on location, activities and relationships from updates and other common content,” iSight said in a blog post.

“Accounts were then targeted with ‘spear-phishing’ messages. Links which appeared to be legitimate asked recipients to log-in to false pages, thus capturing credential information.”

The security firm said it is currently unclear what data, if any,\ ended up stolen during the attacks.

“We are unable to say with complete visibility. However, it is reasonable to assume that a vast amount of social content was compromised in addition to some number of log-in credentials that can be used to access additional systems and information,” read the report.

“As users often maintain the same credentials for multiple sites, it is impossible to determine the scope, scale and duration of data loss,” the report said.

Tuesday, May 6, 2014 @ 07:05 AM gHale

Google fixed a cross-site scripting (XSS) vulnerability in its Google Search Appliance (GSA), a device that enables organizations to index and search through web content, databases, and content management systems.

The device is vulnerable to reflected XSS attacks when the dynamic navigation feature ends up enabled, according to an advisory published by the Computer Emergency Response Team’s Coordination Center (CERT/CC). The appliance combines Dell hardware with Google software.

RELATED STORIES
Security Flaw in OAuth 2.0, OpenID
Siri Allows iPhone Break-in
MyBB Release Fixes Security Holes
Video Site Hole Linked to DDoS Hit

Google fixed the vulnerability with the release of versions 7.2.0.G.114 and 7.0.14.G.216. Customers can download the updates from Google’s Enterprise Support Portal.

As a workaround, users can disable the dynamic navigation feature. Instructions on how to do so are available on the GSA support page.

Versions prior to 7.2.0.G.114 and 7.0.14.G.216 don’t properly sanitize user input reflected directly into a JavaScript “script” block when dynamic navigation is on. The vulnerability can end up exploited by an attacker to perform an XSS attack, i.e. execute arbitrary script in the context of the end-user’s browser session.

Will Dormann, a vulnerability analyst with the CERT/CC, reported the existence of the issue to Google on March 20.

Tuesday, May 6, 2014 @ 07:05 AM gHale

Authentication methods used by major web sites like Facebook, Google, and others could end up redirected by attackers, a researcher said.

A blog posted last week revealed the details of security flaws in OAuth 2.0 and OpenID, two technologies widely used by the Web’s most popular sites to more quickly and easily verify the identity of a user. Wang Jing, a PhD student in mathematics at Nanyang Technological University discovered the vulnerability.

RELATED STORIES
Siri Allows iPhone Break-in
MyBB Release Fixes Security Holes
Video Site Hole Linked to DDoS Hit
DDoS Attacks a Smokescreen for Data Theft

If you have ever allowed an application or website to verify your identity using your Facebook, Twitter, or Google account, then you have likely used OAuth or OpenID. OAuth is an open standard for authorization that gives client applications secure, delegated access to server resources on behalf of a resource owner.

OpenID an open standard that allows users to be authenticated by certain cooperating sites using a third party service, eliminating the need for webmasters to provide their own authentication systems and allowing users to consolidate their digital identities.

The vulnerability could allow an attacker to redirect the “token” used by OAuth 2.0 to access user information on a third-party site, making it possible to steal information such as the email address, age, or location of a user, the blog said. In OpenID, the vulnerability could enable attackers to collect user’s information directly.

The flaw is a “Covert Redirect” vulnerability, in which an application takes a parameter and redirects a user to the parameter value without sufficient validation. This differs from an Open Redirect, in which an application takes a parameter and redirects a user to the parameter value without any validation at all.

If a website ends up exposed to Open Redirect attack, it is often because the site’s operators failed to equip their own site with proper validation, the blog explains. But a Covert Redirect is trickier, because it is essentially a flaw in the handoff of validation between one site and another.

“The Covert Redirect vulnerability related to OAuth 2.0 and OpenID is, in the author’s view, a result of the provider’s overconfidence in its clients/partners,” the blog says. “The provider relies on the clients to provide a list of ‘trustworthy’ domains and assumes all would be safe. However, without sufficient verification of the redirected URLs, no safety could be guaranteed.”

It isn’t always clear who’s responsible for the vulnerability: The website requesting the authentication or the third-party provider that gives the validation, the blog observes.

“The vulnerability is usually due to the existing weakness in the third-party websites,” the blog said. “However, they may be unaware of the vulnerability. Or they do not bother to fix it. One concern is the cost. The other is that in their view, the host company is responsible for making the attacks appear more credible; therefore, it is not solely their problem. However, to the provider, the problem does not originate from its own website. Even if it is willing to take on the responsibility, it has to gain cooperation from all the clients, which is a daunting task.”

And because it isn’t clear who’s responsible for the vulnerability, it may be a difficult problem to fix, the blog notes.

“The patch of this vulnerability is easier said than done,” the blog says. “If all third-party applications strictly adhere to using a whitelist, then there would be no room for attacks. However, in the real world, a large number of third-party applications do not do this. This makes the systems based on OAuth 2.0 or OpenID highly vulnerable.” Providers need to develop a more thorough verification procedure, the blog suggests.

Monday, April 14, 2014 @ 06:04 PM gHale

A flaw in Google Chrome’s old speech recognition API could end up exploited to steal the transcript generated by the web browser when the feature ends up used.

The vulnerable API started up with the introduction of Chrome 11, said Israeli Researcher Guy Aharonovsky. Google released a newer API since, but Aharonovsky believes there are several websites still using the old one.

RELATED STORIES
Chrome Update Includes 31 Security Fixes
Security Fixes Highlight New Safari Release
Chrome Updated, 7 Holes Filled
Google Fixes Chrome Security Holes

To exploit the vulnerability an attacker can set up a website and place -x-webkit-speech feature on it. The speech widget is usually visible, but the attacker can make modifications to it.

For instance, the attacker can resize it so it activates regardless of where the user clicks. Furthermore, its opacity can end up positioned so it becomes invisible. The box which shows the user undergoing the recording process can end up moved outside the screen so the victim doesn’t see it.

All the attacker needs to do is lure the victim to his website and get them to click on the screen.

To demonstrate his findings, the expert set up a website that appears to be a game. As a part of the game, potential victims can plant tree seeds and as the trees grow they can make wishes, which they must say into the computer’s microphone.

What victims don’t know is everything they say while playing “the game” ends up collected by the attacker. That’s because the speech recognition feature activates each time they click on the screen.

Aharonovsky said Google is aware of the issue, but has not issued a release yet. Google said the issue is under investigation, but the search engine giant’s security team informed the researcher the bug is “low-severity” and they don’t view it as a top priority.

Thursday, April 10, 2014 @ 04:04 PM gHale

Google released stable versions of its Chrome browser with 31 security fixes, ChromeOS and other development versions of its products.

Google’s latest Chrome Web browser Version 34 is now rolling out, as well as a new ChromeOS Version 34 for all Chrome devices, as the company continues its regularly scheduled updates for its Chrome line of browsers and related applications.

RELATED STORIES
Security Fixes Highlight New Safari Release
Chrome Updated, 7 Holes Filled
Google Fixes Chrome Security Holes
Adobe Patches Shockwave

The latest stable channel update of the Chrome browser, Version 34 is now available for Windows, Mac, and Linux, said Daniel Xie of the Google Chrome team.

http://googlechromereleases.blogspot.com/2014/04/stable-channel-update.html

The new version includes bug fixes and improvements, such as easier importing of supervised users onto new computers, several new apps and extension APIs, a different look for the Windows 8 Metro mode and many changes to improve stability and performance, Xie said. Version 34 also has 31 security fixes, including at least nine that are high priority and three that are medium priority.

The latest Chrome 34 also now includes the ability to remember and fill password fields even when the autocomplete function is off, Xie said. This is to encourage the use of the Chrome password manager so users can have more complex passwords.

Also released is the latest Stable Version 34 of ChromeOS for all Chrome devices, said Matthew Yuan of the Google Chrome team.

The new version, known officially as Version 34.0.1847.118, includes bug fixes, security updates and feature enhancements, he said. Chrome devices will be receiving the update automatically. Among the fixes and features are a new “side dock,” which allows users to dock small windows and panels to screen edges, and a default “on” status for Google Drive offline backup after a user’s first log-in, Yuan said.

The new versions of Chrome and ChromeOS follow the March release of the previous Version 33 releases of each of those products.

Chrome for Android has also received an update to Version 34, giving Android devices the latest edition of their customized browser.

Chrome 34 for Android, officially Version 34.0.1847.114, distributes through Google Play and contains crash fixes and performance improvements, including battery usage optimizations, wrote Kersey.

Google is also rolling out an update for its Chromecast TV dongle devices.

The Build 16664 update includes bug fixes and stability improvements, as well as the new ability for the Chromecast audio volume level to end up retained across sessions. It also includes improved IPv6 support and improved Domain Name System (DNS) robustness.

Thursday, March 13, 2014 @ 07:03 PM gHale

Google updated the stable channel of its web browser to address seven security holes, which means Chrome 33.0.1750.149 is available for download.

Of the 7 vulnerabilities, three stand out. CVE-2014-1700 is a use-after-free issue in speech identified by Chamal de Silva. The researcher earned $4,000 for his findings.

RELATED STORIES
Google Fixes Chrome Security Holes
Adobe Patches Shockwave
IE Leads Patch Tuesday Fixes
Exploit for Patched Flash Bug

The second flaw, CVE-2014-1701, reported by aidanhs, is an UXSS vulnerability, which brought in $3,000.

Collin Payne earned $1,000 for finding a use-after-free in the web database (CVE-2014-1702).
All those vulnerabilities ended up labeled as being high risk.

Google’s internal security team has also contributed to making Chrome more secure. They’ve identified a potential sandbox escape caused by a use-after-free in web sockets (CVE-2014-1703), and various vulnerabilities in V8 (CVE-2014-1704).

Users should update their browser soon as possible to secure their computers against cyberattacks that might leverage these flaws. The latest version of Chrome contains a Flash Player update to version 12.0.0.77.

 
 
Archived Entries