Analytics
1/27/2011
03:13 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

A Glaring Lesson In Shared Passwords

Vodafone's embarrassing breach should serve as a wake-up call for enterprises that also engage in the dangerous practice of credential-sharing

With dissolution of channel partner contracts and staff firings under way, as well as reactive executive orders snowballing from the corner offices, Australian wireless carrier Vodafone is feeling the full force of consequences stemming from the very common but unsafe practice of allowing shared passwords within enterprise accounts. Most enterprises turn a blind eye to shared account information, particularly among privileged accounts, experts say, and so plenty more IT staffers could face the same fate as their fired Vodafone cohorts should the shared passwords at their organizations be publicly exposed.

In the case of Vodafone, company officials were left red-faced earlier this month when they were informed by a journalist that she was able to log into their most sensitive customer database using legitimate credentials. What followed was a cascading torrent of bad news stemming from rampant password-sharing within the organization.

Earlier in the month, Australian Privacy Commissioner Timothy Pilgrim announced an investigation into the breach; Vodafone officials sent a letter to customers warning of the problem and also stated it fired a number of employees in connection to the potential breach. According to reports in The Sunday Age, Vodafone partners and employees frequently gave out shared passwords to those outside the circle of company trust as favors, and that the rampant account abuse could have put the names, home addresses, phone logs, driver's license numbers, and credit-card details of 4 million Vodafone customers at risk.

According to Vodafone executives, the company is acting quickly to shut down improper access. "Vodafone's customer details are not 'publicly available' on the Internet," a Vodafone spokesperson said in a statement last week. "Customer information is stored on Vodafone's internal systems and accessed through a secure Web portal, accessible to authorized employees and dealers via a secure login and password. Any unauthorized access to the portal will be taken very seriously and would constitute a breach of employment or dealer agreement and possibly a criminal offence."

More recently, Vodafone CEO Nigel Dews laid out the company's reaction to the breach in another statement to the press: "We've made swift progress. We've terminated the employment of a number of staff, we've undertaken a review of the security systems and processes, and we're implementing some of the initiatives straightaway."

Vodafone officials made good on the promises for changes late last week when it terminated its dealer agreement with Communications Direct, which, according to The Age, engaged in improper access of customer information in order to improve its commissions from Vodafone.

Dews also assured the public that the firm has already changed passwords across the board and implemented more stringent password policies, including more frequent changes. However, Dews denied that the damages are as sweeping to affect millions of customers and claims that the breach and password-sharing practices are a "one-off" event.

But account credential sharing is hardly a one-off problem in any enterprise, says Adam Bosnian, executive vice president of Americas and corporate development for Cyber-Ark. "Often in a retail environment, you do see it because in that retail environment the workforce is more transient," he says. "And if I don't have an easy way to create and delete accounts when people join or leave the organization, sometimes the 'efficient' approach is to just have a generic account. But that efficiency is creating an insecure environment and you're leaving yourself open for being exploited. A shared account of any kind is inherently risky."

Phil Lieberman, an identity management expert and CEO of Lieberman Software, agrees that password-sharing is a rampant problem, and can be particularly troublesome within databases accessed by Web applications such as the one that powers Internet access to Vodafone's customer database.

"What happens is that there are certain high-powered accounts that are used by applications and also by users -- call them generic accounts because they end up being shared," Lieberman explains. "So, for example, a root account or an administrator account might be used by a Web application or a super-user account used by a line of business application. One of the issues is that when you see these things in the log, you see all of these accesses being done but you don't know whether this is being done by the applications or this account is being used by a human user. The account shows up as 'root', 'root,' and 'root,' but you don't understand if anybody actually had access to the root account and for how long."

According to Gunnar Peterson of Securosis, this gray area within accounts shared by people and machines is tricky. "The question about what constitutes a user seems simple, and on one level it is. Most likely a user is an account in the corporate or customer directory, such as Active Directory or LDAP," he wrote recently. "But sometimes there are accounts for non-human system users, such as service accounts and machine accounts. In many systems service accounts, machine accounts, and other forms of automated batch processing can do just as much damage as any other account/function. After all, these features were programmed and configured by humans, and are subject to misuse like any other accounts, so likely are worth monitoring as well."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web