In this article he describes how an attacker could exploit Dropbox and gain access to unshared files. The concerns he raised do appear accurate however we must remember that security is an onion.
An onion, like security, has layers to protect its vital parts. The vital parts are more vulnerable when its security model only possess one layer. As we add layers to our security model, our system’s protection grows exponentially.
In the case of Dropbox, the username and password act as the first layer. Experts agree that a simple authentication layer will provide enough protection for nonsensitive data. However when attempting to protect sensitive data we must pair authorization with encryption.
Generally speaking file systems have maintained a sense of insecurity, which makes them useful. Not encrypting files on Dropbox is akin to not encrypting files on a shared PC. Sensitive data should always be encrypted regardless of its location or media. We should treat sensitive data-at-rest on Dropbox the same way we treat sensitive data on local, optical or flash disk. We should encrypt it!
o how does a user encrypt their Dropbox?
My strongly opinionated solution uses TrueCrypt to create an encrypted volume in the Dropbox directory. Simply treat the Dropbox like a normal directory, follow the TrueCrypt documentation to build a volume, and give Dropbox a chance to sync the data. When the sync completes, the TrueCrypt volume will be mountable on each of your Dropbox enabled computers.
I have to admit at first I was skeptical, but the software cooperates surprisingly well and after the initial sync proceeding syncs occur quickly! I prefer TrueCrypt because it is open source, cross platform, and free (both in freedom and cost). TrueCrypt also functions and performs better then any other solution including commercial products like GuardianEdge or PGP both recently acquired by Symantec.
An attacker could create a bogus form on his site – for example a search form. This form could have hidden inputs that contain malicious data. Now the form isn’t actually sent to the attacker’s site to perform the search; in reality, the form points to your site! Since your website will trust that the form is genuine, it goes through and executes the requested (and perhaps malicious) actions.
Imagine that a user is logged into your site, and is redirected to the attacker’s site for some reason (phishing, XSS, you name it). The attacker’s form could point to your account deletion form on your site. If the user performs a “search” on the attackers site, his account will then be deleted without him knowing!
There are numerous ways to prevent these sorts of attacks.
* Check the HTTP Referer header and see if it belongs to your site. The problem with this method is that not all browsers submit this header (I personally had this problem once with IE7); it could be forged anyway.
* Another method (the one we will use), is to include a random string (a “token”) on each form, and store that token on the user’s session. On each POST request, compare the submitted token to the one on store, and, if they differ, deny the request. Your site still needs to be protected against XSS though, because if it’s not, this method becomes useless.
Click here to read more.
This was exaggeration for effect—there aren’t many cases where a simple XSS injection could actually empty a bank account—but I wanted to make a point.
By some coincidence, I’ve found myself working with various open source projects recently that take a half-assed approach to HTML escaping. It’s something that tends to be implemented as an afterthought, which is unfortunate because it can be critical for the security of users of these projects. I won’t name any names in this post (pull requests are forthcoming), but I will explain some of the common problems I’ve seen, why they’re problems, and what can be done to fix them.
This post is not an introduction to HTML escaping. It assumes that you already know what HTML escaping is and why it’s necessary. This post also is not a comprehensive catalog of XSS vectors; the examples here are illustrative, but they certainly aren’t the only attacks you need to worry about. The intent of this post is to explain some dangers that you may not be aware of, and to encourage you to read more about them and write safer code.
Note that this post only discusses escaping, which is something entirely different (and far less complicated) than sanitizing. HTML sanitization is a topic for another time.
Escaping < and > isn’t enough
The worst HTML escaper I’ve seen in a major open source project only escapes the < and > characters. This may actually be worse than not escaping anything at all, since it gives the illusion of security, but is trivial to defeat.
For example, let’s say I have the following template, and I’m going to replace the placeholder values, indicated in [square brackets], with HTML-escaped user input:
The attacker enters foo” onmouseover=”alert(1) as their username. End result, even after escaping:
Because the ” character wasn’t escaped and the attacker’s input was used in an attribute value, the attacker was able to inject arbitrary attributes and therefore JavaScript (which, in a real XSS attack, would probably be something more harmful than an alert).
This is a classic example of making input safer in one context—in this case, as the content of an element—without considering the other contexts in which it’s likely to be used, such as inside an attribute value.
Click here to read more
istributed denial-of-service (DDoS) attacks have become the top vector for attacking websites, according to a report released today.
DDoS attacks jumped to the No. 1 attack vector, up 22 percent over the first half of 2010, according to Trustwave’s second-half 2010 Web Hacking Incident Report.
“Based on our report, website downtime is far from the traditional intended outcome of a [DDoS] attack, which is typically hacking for profit,” the report says. “As a result, most businesses were not equipped to handle such an attack because they had not tested, nor properly implemented, anti-automation defenses for their Web application architecture.
“Our study found that most businesses wrongly assume that network hardware will stop DDoS attacks, or believe their website will not be targeted by such attacks,” the report continues. “But the increase in this attack vector proves that businesses, both large and small, should test their website limitations to better understand how their applications will respond to such an attack.”
Click here to read more.
he average website has serious vulnerabilities more than nine months of the year, according to a new report issued yesterday.
According to a study issued by researchers at WhiteHat Security, the average site is exposed about 270 days of the year. “Information Leakage” has replaced cross-site scripting (XSS) as the most common website vulnerability, the report says.
The report examined data from more than 3,000 websites across 400 organizations that are continually tested for vulnerabilities by WhiteHat Security’s Sentinel service. The study offers a look at sites’ “Window of Exposure,” which measures not only the vulnerabilities found in sites, but the length of time it takes those vulnerabilities to be remediated.
“It’s inevitable that websites will contain some faulty code — especially in sites that are continually updated. Window of Exposure is a useful combination of the vulnerability prevalence, the time it takes to fix vulnerabilities, and the percentage of them that are remediated,” said Jeremiah Grossman, founder and CTO of WhiteHat Security. “Specifically for CIOs and security professionals, measuring window of exposure offers a look at the duration of risk their business and user data is exposed to by not having sufficient remediation processes in place.”
Click here to read more.
The assault against RSA, the security division of EMC Corp., began with two waves of spear phishing attacks using an attached Microsoft Excel file, which targeted an Adobe Flash zero-day flaw.
The phishing attacks took place over a two-day period and targeted two small groups of low-profile employees. Attackers were successful in getting at least one employee to retrieve it from their junk mail folder and open the Excel file titled “2011 Recruitment plan.xls.” Eventually, attackers gained access to critical systems. A NetWitness early detection system discovered the anomaly, alerting incident response teams while the attack was in progress, but not before attackers could make off with details about the company’s SecurID two-factor authentication products.
Uri Rivner, head of new technologies, identity protection and verification at RSA, shared the first details of the RSA SecurID attack since March 22, when the company warned that information related to its SecurID products was stolen.
Click here to read more.
RSA customers could be at risk after the company’s two-factor SecurID tokens fell victim to what it’s calling sophisticated cyber-attack.
Art Coviello, executive chairman of Bedford, Mass.-based RSA, the security arm of EMC, told customers in an open letter this week that RSA had recently identified an attack in progress against RSA and its investigation revealed that an Advanced Persistent Threat (APT) was carried out against the company and information specifically related to RSA’s SecurID two-factor authentication products was extracted.
Two-factor authentication is the process where users provide two independent identifying factors to obtain access to systems. In the case of SecurID, the two authentication factors would be a password and a physical token. RSA’s SecurID products are used on PCs, USB drives and other devices for an extra layer of security that goes beyond user names and passwords to grant access to systems.
Click here to read more
PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) system. Boasting an impressive feature set including a captive-portal for registration and remediation, centralized wired and wireless management, 802.1X support, layer-2 isolation of problematic devices, integration with the Snort IDS and the Nessus vulnerability scanner; PacketFence can be used to effectively secure networks – from small to very large heterogeneous networks. Among the different markets are:
* banks
* colleges and universities
* engineering companies
* manufacturing businesses
* school boards (K-12)
.. and many more!
Why do I need PacketFence?
If your network is a breeding ground for worms, PacketFence is for you. If you have no idea who connects to your network and who owns a particular computer, PacketFence is for you. If you have no way of mapping a network policy violation to a user, PacketFence is for you.
Click here to read more
Attack Surface Analyzer is developed by the Security Engineering group, building on the work of our Security Science team. It is the same tool used by Microsoft’s internal product groups to catalog changes made to operating system attack surface by the installation of new software.
Attack Surface Analyzer takes a snapshot of your system state before and after the installation of product(s) and displays the changes to a number of key elements of the Windows attack surface.
This allows:
-
- Developers to view changes in the attack surface resulting from the introduction of their code on to the Windows platform
- IT Professionals to assess the aggregate Attack Surface change by the installation of an organization’s line of business applications
- IT Security Auditors evaluate the risk of a particular piece of software installed on the Windows platform during threat risk reviews
- IT Security Incident Responders to gain a better understanding of the state of a systems security during investigations (if a baseline scan was taken of the system during the deployment phase)
click here to read more.
An iPhone can hurt an enterprise in many different ways. The device’s porous e-mail support is one big concern. Many enterprise employees are planning to use the device like an improved Blackberry, counting on it to provide e-mail capabilities that synchronize with their PC, Mac and Internet service-based contacts. But iPhone fails to incorporate basic security safeguards, like a firewall or data encryption. It also doesn’t support Microsoft Exchange or Lotus Notes, meaning that users must forward their e-mail to an Internet service provider, potentially exposing enterprise data to unsecured connections and servers.
The iPhone’s iffy security also extends to the road. Unlike the Blackberry and other enterprise-class telecom devices, the product doesn’t allow users to lock the unit or destroy stored data in the event it’s lost or stolen. That means an iPhone could disappear without a trace, placing sensitive e-mails and other data into the hands of strangers.
Managers also worry about iPhone’s capability to store prodigious amounts of data. The unit can function like an external storage device (and will be recognized as such by most networks), storing up to 4GB or 8GB of data, depending on the model. This means unscrupulous iPhone users can swipe large amounts of data from unsecured enterprise PCs.
The fact that iPhone will use an operating system and Web browser that have been available, in one form or another, for years will please users seeking reliability and familiarity. But to IT managers, this time tested, standardized approach means that hackers will have had a head start in finding entry points to exploit. Many managers also fret that all the media hype surrounding the iPhone will tempt ambitious hackers–those seeking notoriety–to target the product.
Meanwhile, the iPhone’s closed operating system will make it impossible for users or IT managers to install software from security companies on the device. David Maynor, a security researcher with Errata Security, recently stated that he’s already discovered a bug in the Apple Safari browser that will be used on the iPhone. Maynor claims that a backdoor can be exploited to hijack the iPhone with hidden software, just as hackers have used malware to herd millions of unwitting PCs into robots that send spam, attack Web sites and steal financial data.
Click here to read more.
