If consumers weren’t skittish enough, Home Depot recently joined the rapidly lengthening list of big box retailers experiencing sometimes prolonged data breaches: Albertson’s, Dairy Queen, The UPS Store, Sally Beauty, Target, Michael’s, Neiman Marcus, P.F. Chang’s and SuperValu.
More than a few Chief Information Security Officers (CISO) must be nervous. In fact, it may be forcing corporations who do not have a CISO to rethink that strategy. Often the CISO position is folded in with or serves under the Chief Information Officer (CIO) or even, if the CIO reports to the Chief Financial Officer (CFO), as is the case in some organizations, two layers under the seat of power. So, the person charged with security risk management may not have the authority to get things done.
With the recent spate of high profile data breaches, translating the message up the chain or even the perception that the CISO’s job is not important enough to be a direct report may not cut it anymore. Shareholders and customers want answers.
Consumers also are flocking to convenient online sites, where they have few other choices than to use a credit or debit card.
Data breaches, whether prolonged or short lived, especially those that compromise customer information, are black eyes that eventually will force consumers to keep their credit and debit cards at home. Having the man or woman in charge of mitigating IT risk fairly far down the food chain doesn’t look good, no matter whose ear he or she may have.
Michael Daniel, the current White House cybersecurity coordinator, recently admitted to lacking technical know-how; i.e. he can’t code and doesn’t feel the need to learn to do so. Those who have the technical expertise and think it’s important have lit up the Internet with their cries, making it clear that they do not approve.
Does it matter that Michael Daniel can’t code? Read More…
This is the second post in our Social Networking series. (Read the first one here.)
As Facebook’s application platform has become more popular, the composition of applications has evolved. While early applications seemed to focus on either social gaming or extending the capabilities of Facebook, now Facebook is being utilized as a platform by major companies to foster interaction with their customers in a variety forms such as sweepstakes, promotions, shopping, and more.
And why not? We’ve all heard the numbers: Facebook has 800 million active users, 50% of whom log on everyday. On average, more than 20 million Facebook applications are installed by users every day, while more than 7 million applications and websites remain integrated with Facebook. (1) Additionally, Facebook is seen as a treasure trove of valuable data accessible to anyone who can get enough “Likes” on their page or application.
As corporate investments in social applications have grown, Neohapsis Labs researchers have been requested to help clients assess these applications and help determine what type of risk exposure their release may pose. We took a sample of the applications we have assessed and pulled together some interesting trends. For context, most of these applications are very small in size (2-4 dynamic pages.) The functionality contained in these applications ranged from simple sweepstakes entry forms and contests with content submission (photos, essays, videos, etc.) to gaming and shopping applications.
From our sample, we found that on average the applications assessed had vulnerabilities in 2.5 vulnerability classes (e.g. Cross Site Scripting or SQL Injection,) and none of the applications were completely free of vulnerabilities. Given the attack surface of these applications is so small, this is a somewhat surprising statistic.
The most commonly identified findings in our sample group of applications included Cross-Site Scripting, Insufficient Transport Layer Protection, and Insecure File Upload vulnerabilities. Each of these vulnerabilities classes will be discussed below, along with how the social networking aspect of the applications affects their potential impact.
Facebook applications suffer the most from Cross-Site Scripting. This type of vulnerability was identified on 46% of the applications sampled. This is not surprising, since this age old problem still creeps up into many corporate and personal applications today. An application discovered to be vulnerable to XSS could be used to attempt browser based exploits or to steal session cookies (but only in the context of the application’s domain.)
When third-party developers enter the picture all this becomes even more of a concern, since two clients’ applications may be sharing the same domain and thus be in some ways reliant on the security of the other client’s application.
Once again, the impact of this finding really depends on the functionality of the application, but the wide variety of applications on Facebook does provide a interesting and varied landscape for the attacker to choose from. We only flagged this vulnerability under specific circumstance where either the application cookies were somehow important (for example being used to identify a logged in session) or the application included functionality where sensitive data (such as PII or credit card data) was transmitted.
The third most commonly identified finding was Insecure File Upload. To us, this was surprising, since it’s generally not considered to be one of the most commonly identified vulnerabilities across all web applications. Nevertheless 27% of our sample included this type of vulnerability. We attribute its identification rate to the prevalence of social applications that include some type of file upload functionality (to share an avatar, photo, document, movie, etc.)
Our assessment also identified a wide range of other types of vulnerabilities. For example, we found several of these applications to be utilizing publicly available admin interfaces with guessable credentials. Furthermore, at least one of the admin interfaces was riddled with stored XSS vulnerabilities. Sever configurations were also a frequent problem with unnecessary exposed services and insecure configuration being repeatedly identified.
Finally, we also found that many of these web applications had some interesting issues that are generally unlikely to affect a standard web application. For example, social applications with a contest component may need to worry about the integrity of the contest. If it is possible for a malicious user to game the contest (for example by cheating at a social game and placing a fake high score) this could reflect badly on the application, the contest, and the sponsoring brand.
Even though development of applications integrated with Facebook and other social network sites in increasing, we’ve found companies still tend to handle these outside of their normal security processes. It is important to realize that these applications can present a risk and should be thoroughly examined just like traditional stand alone web applications.