Saturday, 21 May 2011

Social-networking sites must protect privacy


How many times have you changed your privacy settings on a social-networking site?

If you've lost track, you're not alone.
  
Nor are you alone in your nagging fear that your private information, or that of your child, is lurking out there despite your best efforts - because it very well may be.
Social-networking sites routinely "update" their privacy settings, making it difficult for users to keep track of their own personal information. That's good business for them - their revenue depends on giving advertisers access to as much user information as possible - but it's bad for those of us who care about privacy.

No one should be confused about the security of their own personal information. It's a safety issue as well - if businesses have easy access to where you live and how to contact you, so do identity thieves and stalkers.

 
A bill in the Legislature, SB242 by state Sen. Ellen Corbett, D-San Leandro, would establish privacy guidelines for social-networking sites like Facebook, Twitter and Match.com. Sites would have to set defaults to private so that users themselves could choose which information to make public. It would also allow users to establish their privacy settings when they register to join sites, rather than after they have set up an account and profile.
Finally, it would require sites to remove personally identifying information within 48 hours of a user request - or a parent's request, if the user is under the age of 18.
Corbett says the bill is necessary because people want to preserve their privacy. "People are very, very concerned when they find out that their personal information can be disclosed to anyone at all on the Internet," Corbett said in an interview. "So many people believe that their personal information is theirs, and should not be shared with a third party unless that permission is specifically granted. And it's widely known that identity theft is a huge problem."
Companies that run the sites don't agree with her characterization. A coalition including Facebook, Skype, Yahoo, Twitter, Google and eHarmony sent Corbett a letter encouraging a "no" vote on her bill. The companies say that the bill is unnecessary because two-thirds of users already adjust their privacy settings and that it "would dramatically limit social-networking sites' growth potential in California by imposing additional operating costs and raising barriers to consumer participation in social-networking services, all while exposing those services to massive and unwarranted civil liability."
SB242 isn't perfect. Giving the sites only 48 hours to scrub individual users' data would certainly be burdensome, and it could be confusing for users to try to decide what their privacy settings should be before they've had a chance to use the service.
But the idea that it would prevent people from signing up for social networks, present a "serious threat to the viability of California's Internet commerce companies" and "interfere with the right to freedom of speech" - all of which is alleged in the coalition's letter - that idea is simply not serious.
As social networking pervades our lives, government officials are finally starting to get serious about privacy. Should SB242 pass, it would be the first such law in the nation but not the last. And in Washington, officials are paying attention too - this week, executives from Apple, Google and Facebook appeared before the Senate Commerce Committee to explain their reasons for collecting and storing customer information on mobile platforms. Once again, they claimed that privacy was important to them. Our leaders need to be skeptical.
As social-networking sites grow and develop in importance, their responsibilities grow as well. And if they don't provide users with the privacy that they need, then government officials must step in.



IPv6 connectivity: Innovations address IPv6 security concerns


Internet Protocol version 6 (IPv6) is coming soon to an enterprise near you, but few organizations have invested much time or effort into understanding how it works, never mind how to secure it. Yet enterprises could stand to learn something from the students and staff at Virginia Tech, which was recently lauded for an innovative new technology that secures IPv6 network communications.
A team from the Blacksburg, Va.-based university’s Information Technology Security Laboratory was recognized by the National Homeland Defense Foundation, which is a nonprofit forum for responding to terrorism tactics and natural disasters, for creating a security tool called Moving Target IPv6 Defense (MT6D).
MT6D solves one of a number of unique IPv6 security concerns that don’t exist in IPv4. In short, an IPv6 address consists of two parts: a 64-bit network prefix, and a 64-bit host address. The first part is determined by the network, but the host address by default is determined by the device’s MAC address.
According to Stephen Groat, a Ph. D. student in computer engineering at Virginia Tech, in this scenario, a machine’s IPv6 address would expose its MAC address, making a machine easy to track by a potential attacker.
“In IPv6, it takes centuries to scan a single subnet,” Groat said. “But once an attacker knows that MAC address, this lets an attacker pretty much do anything they want to a system.”
Groat said, with a little homework, attackers could use the IPv6 address to learn who the manufacturer of the system is, and also collect traffic over multiple sessions: Even when a device disconnects and reconnects, the MAC address portion of the IPv6 address remains unchanged.
There are mechanisms that exist today to obfuscate IPv6 client addresses to some degree, like IPv6 privacy extensions in Windows 7, but Groat said the Virginia Tech team wanted to protect both ends of a session; privacy extensions may protect clients, but servers can’t change their addresses without terminating a session.
That’s where MT6D comes in. It serves to create an algorithm that allows a pair of network hosts to change their addresses dynamically in a way that each host can predict the other’s next address, creating a network tunnel. The technology could be deployed as a stand-alone appliance on a network to secure a subnet or be built into specialized network devices like smart grid electric meters, but it’s likely to be made available to vendors for inclusion in commercial networking and security products.
While MT6D solves one IPv6 security problem, there are still a number of others. Few network security products today offer robust support for IPv6, Groat said, and those that claim to often haven’t been tested in a large-scale IPv6 environment like the Virginia Tech network, which has been in place since 2005 and features 30,000 nodes. Often, organizations have IPv6-enabled devices and don’t realize it, opening the door for malware to use IPv6 as an unmonitored back-channel. And that’s just for starters.
“We have someone here who also works for a hosting firm, and at the hosting firm they can’t turn on v6 support for their mail servers because they have v4-only blacklists,” Groat said. “So if they turn on v6, they’ll suddenly get all this spam. The other question is, ‘How do you create a blacklist for v6?’ Since hosts can change their addresses so frequently, do you block whole subnets? These are real problems people haven’t solved yet.”
Fortunately, with World IPv6 Day coming on June 8 – a one-day IPv6 connectivity awareness initiative where many global network and website operators like Google and Facebook will turn on IPv6, just to see what happens -- everyone will get a chance to see what an IPv6 Internet looks like. Though some believe the event will mostly be a PR stunt and simply raise awareness for the upcoming transition across the Internet, count the Virginia Tech team among those who believe it could be a disruptive event.
“I think a lot of websites will break,” said William Urbanski, a security analyst with the Virginia Tech IT security office. “I think end users are going to see misconfigurations on commerical ISPs.”
Still, World IPv6 day and the MT6D tool should serve to help enterprise security teams ponder how their security tactics must evolve as IPv6 takes hold. It’s a topic we’ll follow closely on SearchSecurity.com as the year moves on.
About the author:
Eric B. Parizo is senior site editor of TechTarget's Security Media Group. His rants can also be heard on SearchSecurity.com's Security Squad podcast.

99.7% of Android Devices Vulnerable to Data Leak


A weakness with an Android security feature called ClientLogin in older versions of Android OS leaves 99.7% of all Android devices vulnerable to leaking data on an unsecured WiFi network. Researchers from Ulm University found that it was possible, and even “quite easy” for the bad guys to launch an “impersonation attack” and hijack your Google digital credentials using this flaw, and then use those credentials to log on to your Google accounts (calendar, Gmail, and everything else).
“We wanted to know if it is really possible to launch an impersonation attack against Google services and started our own analysis,” researchers at the Institute of Media Informatics of Ulm University wrote in its report. “The short answer is: Yes, it is possible, and it is quite easy to do so. Further, the attack is not limited to Google Calendar and Contacts, but is theoretically feasible with all Google services using the ClientLogin authentication protocol for access to its data APIs.”
The Vulnerability
ClientLogin is a technology developed to make mobile services more secure. As explained by The Register, which first covered the research, ClientLogin allows users to log in to Google services once, creating a digital token that is then used for any additional access. This results in your login and password information being transmitted once (once is more secure than “lots,” or even “twice”), which is good.
The problem is that before Android 2.3.4, that token was transmitted in cleartext, which simply isn’t secure. On an unsecured network controlled by the bad guys, that token can then be hijacked and used by said bad guys to access everything on Google you might use. This is bad.
The vulnerability has been fixed in Android 2.3.4 and later (including Android 3.0), which puts us back in the good column, but it turns out that almost no one has bothered to update beyond Android 2.3.3, leaving us squarely back in the bad column again.
Visual Aids
Google has always had a problem getting users to update to the newest version of Android. In the Android ecosystem, some devices can’t be updated without being rooted (similar to jailbreaking in iOS terms), while others are merely difficult to update and require the user to know what they are doing. Google is working hard on this issue, and the company has reportedly been trying to corral its hardware partners into taking this issue more seriously.
For now, however, 99.7% of Android devices are running Android 2.3.3 or earlier, as of the two weeks leading up to May 2nd of this year (15 days ago). While Android 2.3.4 corrects the problem with Calendar Sync and Contacts Sync (leaving Picassa Sync vulnerable), that version of the OS doesn’t even register with Google’s distribution breakdown. Android 3.0 (Honeycomb) also fixes the problem, though the researchers weren’t sure about Picassa Sync in that version of the OS.
Let’s look at those numbers in a pie chart:
Breakdown of Android versions installed on Android devices
Data collected during two weeks ending on May 2, 2011
Android Distribution Graph
Chart by The Mac Observer from data provided by Google

That chart is kind of messy, so we broke the data down further into the percentage of users with Android 3.0 and everything else.
Breakdown of Android users affected by the vulnerability
Data collected during two weeks ending on May 2, 2011
Android Distribution Chart
Chart by The Mac Observer from data provided by Google

Google works to close security loophole in Android

Issue leaves millions of Smartphones, tablets vulnerable to personal data leaks.



LOS ANGELES — Google is in the process of updating its Android operating system to fix an issue that is believed to have left millions of smartphones and tablets vulnerable to personal data leaks.

"We recently started rolling out a fix which addresses a potential security flaw that could, under certain circumstances, allow a third party access to data available in calendar and contacts," a Google spokesman said in a statement. "This fix requires no action from users and will roll out globally over the next few days."

The fix is being issued for every version of Android released and began updating devices Wednesday, according to a person familiar with the software update who spoke on the condition of anonymity because of their relationship with Google.

The Mountain View tech giant hasn't found any instances of hackers taking advantage of the flaw to steal a user's personal data, the person said, adding that Google hadn't known of the potential for such an exploitation until Germany's University of Ulm issued a report on the security hole.

"The implications of this vulnerability reach from disclosure to loss of personal information for the Calendar data," Ulm researchers Bastian Konings, Jens Nickels and Florian Schaub wrote in their report.

"For Contact information, private information of others is also affected, potentially including phone numbers, home addresses and email addresses."

The vulnerability in Android was first pointed out by

Advertisement
Rice University professor Dan Wallach in February, and the University of Ulm probed it further.
"Beyond the mere stealing of such information, an adversary could perform subtle changes without the user noticing," the Ulm researchers said. "For example, an adversary could change the stored email address of the victim's boss or business partners hoping to receive sensitive or confidential material pertaining to their business."

The flaw affected 99.7 percent of all Android smartphones and was not limited to Google Calendar and contacts, "but is theoretically feasible with all Google services," the University of Ulm said.

Among the weaknesses mentioned in the report was ClientLogin, which is Android's system to authenticate apps.

"Basically, to use ClientLogin, an application needs to request an authentication token (authToken) from the Google service by passing an account name and password via a https connection," the report said. "The returned authToken can be used for any subsequent request to the service API and is valid for a maximum duration of two weeks."

However, if the authToken is not encrypted and sent over an unsecured wireless network, "an adversary can easily sniff the authToken" and then use it to access any personal data which is made available to installed apps.

"For instance, the adversary can gain full access to the calendar, contacts information or private Web albums of the respective Google user," Ulm researchers said. "This means that the adversary can view, modify or delete any contacts, calendar events or private pictures."

This is not limited to items currently being synced but affects all items of that user."

The tactic "is very similar to stealing session cookies of websites" or sidejacking, which is a popular attack among hackers breaking in to Facebook or Twitter accounts over unsecured wireless networks.

———

(c) 2011, Los Angeles Times.

Google Deodorizes Sniffable Android Security Flaw

A new round of patching has begun for Android phones, the vast majority of which were found to be vulnerable to hackers if the owner was using it on an open WiFi network. The flaw affected 99.7 percent of all Android smartphones running Android 2.3.3 and earlier versions because they don't use a secure HTTPS connection, according to researchers.

Google (Nasdaq: GOOG) has begun rolling out a patch to fix a security flaw in versions 2.3.3 and earlier of its Android mobile operating system.
That flaw affects all Google services using the ClientLogin authentication protocol.
It lets hackers access any personal data available through Android's application programming interfaces (APIs).
"The flaw is now fixed for all versions of Android worldwide," Google spokesperson Randall Sarafa told LinuxInsider.
The patch is being rolled out in stages over several days, Sarafa said.

The Hole in Android

The flaw gained media attention after it was publicized by theUniversity of Ulm.
Here's how it works: When an application wants to get access to Android's APIs, it requests an authentication token through ClientLogin by providing an account name and password.
The system then returns an authorization token, which is good for up to two weeks.
If the token is used in requests sent over unencrypted networks, such as WiFi networks, hackers can steal it. They can then use the token to access any personal data made available through the service API.
The hackers will gain full access to the victim's calendar, contacts information, or private Web-based photo albums. They'll be able to view, delete, or modify any calendar events, contacts, or private pictures, the Ulm University researchers said.
The flaw affected 99.7 percent of all Android smartphones running Android 2.3.3 and earlier versions because they don't use a secure HTTPS connection, the researchers said.
Google's patch forces an HTTPS connection for calendar and contacts sync on Android, Sarafa said.

More on the Flaw

Authentication tokens are widely used for online services such aseBay (Nasdaq: EBAY). They are also used by software and application vendors such as Microsoft (Nasdaq: MSFT) and Splunk, and in Apple's (Nasdaq: AAPL) iOS mobile operating system.
There was a problem with the authentication token on Android because Google's implementation was faulty, Paul Laudanski, director of ESET's cyber threat analysis center, told LinuxInsider.
"The entry point is having an unpatched or vulnerable Android system connecting to Google services using ClientAuth over an unencrypted public WiFi network," Laudanski explained. "The correct implementation is to transmit the authorization token in a secured manner."
Google services transmit the authorization token as an open text message, which can be easily stolen.
If the technology is implemented correctly and the authorization tokens are sent securely, then even if an unencrypted WiFi network is used, the user information would appear as garbage to snoopers, Laudanski pointed out.
Google's implementation of the technology may not have been faulty in and of itself, argues Mike Paquette, chief strategy officer at Top Layer Security.
"The problem appears to be the use of the ClientLogin protocol, allowing these sniffable authentication protocols, combined with a long expiry time," Paquette told LinuxInsider. "This makes exploits practical and even likely," he added.
Android smartphone owners should stay away from heavily used public WiFi hotspots, Paquette warned. "It's likely that attackers would target areas with large numbers of users of public WiFi in order to have the greatest return," he explained.

Old Problems Refreshed

The security flaw in Android was apparently first discovered by Dan Wallach of Princeton University, who blogged about it in February.
In an experiment during his undergraduate security class, he set up a sniffer with fellow students to listen in on his Android smartphone. They used Wireshark and Mallory.
Wireshark is a network protocol analyzer for Unix and Windows. Mallory is a transparent TCPand UDP proxy. It can be used to access network streams and assess mobile Web applications, among other things.
UDP, the User Datagram Protocol, is one of the core members of the Internet Protocol (IP) Suite. It lets applications directly send messages, or datagrams, to other hosts on an IP network.
The team found that Google doesn't encrypt traffic to Google Calendar, although it properly encrypts traffic to Gmail and Google Voice. Eavesdroppers could see victims' calendar transactions and likely impersonate them on Google Calendar, Wallach found.
The University of Ulm researchers built on Wallach's research.
Android smartphone users should apply the same security precautions to their devices as they would do with their laptops, Torsten George, vice president of marketing Reach More Customers with Live Chat - Free Whitepaper at Agiliance, told LinuxInsider.
"Smartphones are essentially taking on the role of a regular computer," George pointed out. "Thus, they are just as vulnerable to attack by cybercriminals as regular laptop or desktop computers."
Because they lack built-in security, smartphones "open up a bigger attack surface than traditional computer devices," George added. 


http://www.linuxinsider.com/story/Google-Deodorizes-Sniffable-Android-Security-Flaw-72494.html

Google is patching the Android security hole


In the wake of the revelation that there’s a huge security hole in Android’s Wi-Fi communications with Google applications, Google told me and other journalists on May 18th that, “Today we’re starting to roll out a fix which addresses a potential security flaw that could, under certain circumstances, allow a third party access to data available in calendar and contacts. This fix requires no action from users and will roll out globally over the next few days.” Fair enough, but how?
Specifically, I asked Google, “Is this a server-side fix? A client-side fix that will be rolled out as an automatically applied patch? A change in the client settings to force the use of a secure connection? Some combination of all these? Will this ‘fix’ be deployed to other apps that use ClientLogin [the routine that has the security problem]? Is it a ‘fix’ to ClientLogin? Any details on how the fix will be deployed? In the U.S. first? Via the various carriers? OEMs?”
And Google answered, well, actually they never did answer. Darn it!
So, here’s what I think Google is doing. I believe it must be a server-side fix since that’s the one way Google can roll it out quickly and without getting the phone carriers and OEMs involved. The easiest way to do that is to simply disallow ClientLogin from working over any open, non-secured Wi-Fi connection. It’s a kludge, but it should work.
If, as I suspect, Google is handling this on the server side, I believe the Android hole should be closed up within the week. I just wish I knew more about exactly how Google is going about this. Google? The ball is in your court now.