I recently acquired a new iMac at work to replace the 4yr old one I was using. The new iMac came with Lion on it, and since I had upgraded to Lion on my work machine, I went ahead and upgraded all of my home machines as well. My Macbook Air is my primary “workstation away from work”, and keeps client data. Because it does, I use FileVault on it. Under Snow Leopard, that only encrypted my home directory. Under Lion, FileVault now encrypts the entire drive, not just $HOME. However, if you upgrade, you have to explicitly convert your machine to use the new FileVault. And you need a lot of disk space to do it…

I have a 250 GB SSD drive – not exactly the biggest drive – and I have 11GB of that left. I wasn’t able to upgrade my machine to the new FileVault – until I moved the majority of my data to another computer and practically wiped my drive. I’m sure I’m not the only one in this situation – and generally, backups are not encrypted – Time Machine under Snow Leopard wasn’t, and most other backup options for home use are not either. So you have sensitive data backed up off an encrypted drive, just to “upgrade” to a different disk encryption technology. If I hadn’t upgraded, it wouldn’t have been a problem. If I was content to just leave $HOME encrypted, it wouldn’t have been a problem. But I wanted “bleeding edge”. Luckily, I have an iMac at work to off-load all of the files to – encrypted with Lion’s FileVault from the start.

A few years ago, a friend of mine served in Afghanistan. It was, as he described it, a long and mostly dull duty. When not busy with soldierly duties, he wrote on his blog and took pictures, often of the rather picturesque – to those who didn’t have to traverse it – scenery. At one point, however, he was informed that these landscape pictures were, in fact, an operational security violation. Not the ones taken in-camp, but the gorgeous panoramas of Afghani mountains and valleys. The theory was that, using those pictures, insurgents could find their position. My friend’s response was succinct: “I think they already know about the mountains, sir.”

In a previous job, I was charged with creating the security documentation for a particular government system, including the disaster recovery plan. That plan necessarily had to include the power requirements for the system. However, with a certain amount of digging, I discovered that by the standards to which I would be held, the simple fact that the servers used either 110V or 220V power was considered “secure unclassified information” and my report would require rather cumbersome treatment. Mind, what put it over the top was not that the servers required 110V, or that the servers required 220V, but simply that the servers might require one or the other. Or, in other words, that the servers required electricity in the same fashion as every other standard server. The bleedingly, patently, absurdly obvious. But that fact was somehow important for security.

There is a certain tendency, with respect to security, to classify, render confidential, or otherwise obscure every piece of information. I cannot count how many times I have heard “we can’t tell you what kind of encryption we use – that would make it insecure!” or some other variant. Indeed, there is a certain value to hiding some seemingly obvious pieces of information – the number of servers, the ports being used, the location of a datacenter in a building. These are not without purpose. There is no sense in making an intruder’s job any easier, and great value in making it as trudgingly difficult and annoying for them as possible.

But this must be tempered with a modicum of sense. In risk assessment terms, this means examining a piece of information and determining what level of risk it exposes. There is no sense in restricting the fact that servers run off of electricity; an intruder knows that – it’s not something that takes much knowledge to figure out. There’s no sense in hiding the fact that a base which is in contact with the local population can see the mountains – the insurgents know that. These are obvious things.

And there’s an important psychological component there. By trying to secure patently obvious things, security by obscurity (already a bad idea) becomes security of absurdity. The very concept of security becomes eroded. Yes, it’s easier to treat all information as secure, but the end users won’t view it that way. What they’ll see – correctly – is a security posture which has gone amok and which is not connected to the reality of their work. And they’ll start ignoring it because it’s ridiculous. And then they’ll be ignoring actually sensible security; they’ve lost confidence in the directives and the purpose behind them. And then you have a problem.

The point is to maintain a real connection with the people who have to implement security directives. As I’ve said before, their job is not to keep your infrastructure secure – their job is, well, their job. To keep people following secure processes, they have to be invested. They have to be able to understand why they’re doing these things. You have to acknowledge that they know the mountains are there, and work within that reality.

When it comes to giving advice about picking strong passwords, experts are quick to point out some of the good password generators and managers available, or recite best-practices for making up your own. And although we do so with the best of intentions, it’s still easy for people’s eyes to gloss over when presented with matter-of-fact information, especially if it comes in the form of a lecture or a wall of text.

For the people who are way more responsive to information communicated graphically, this short video from Mozilla explains some basic concepts of choosing easy-to-remember passwords that are still complex and robust:

Passwords look like they’ll be sticking around for a little while longer as a key component in single-factor authentication. The more we promote the practice of choosing sturdy passwords, the faster we will be able to turn one of their biggest weaknesses into a strength.

Security researcher Mario Heiderich (also creator of the HTML5 Security Cheatsheet and lead developer for PHPIDS) has been posting some interesting cross-site scripting challenges lately that highlight aspects of security on the client side. The most recent, called XSSMe², involved a page with a reflected XSS vulnerability that allowed one to insert arbitrary HTML – no filters applied by the server. The goal? Retrieve a particular bit of data, originally stored in document.cookie, without any user interaction. I say “originally,” because the page included JavaScript which attempted to lock down access to the data by removing it from document.cookie and hiding it unless retrieved by a user click. The code used evolved as bypasses were found, with several tricks employed along the way.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.

A lot of what we security professionals do includes protecting information from being compromised (especially personal information). The shift towards more profit-driven computer crime has happened swiftly over the last decade, so it should come as no surprise that there is a booming underground market centered almost entirely around compromised financial and personal data. And, on the other end of the spectrum, we have laws and regulations to help minimize the leakage of this data in the first place. Plenty of research and documentation exists for the many ways we try to protect information, but there isn’t much (public) info on the underground market populated by the attackers and their associates who trade in illegally-gotten information. So, how do someone’s bank account credentials grease the wheels of this unique ecosystem?

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

We’ve discussed the importance of properly implemented two-factor authentication before, but TFA is usually associated with computing fields or high-security facilities.  Earlier this year an InfoSec blogger wrote about his experience driving a new Ducati Diavel, in which he dealt with a dealer who did not provide a key for the bike he was test driving.  While the bike appeared to have been started before he left the dealership, apparently the dealer started it without a key, since new Ducatis can be started with an optional backup PIN in case you lose or forget your key fob.  To his surprise, the bike’s PIN was the last four digits of the bike’s VIN, although that was most likely an oversight from the dealer, not the factory setting, which is to have the feature disabled (Hint: You should never make your passcode for any authentication a number or phrase that is publicly available or related, like the VIN).

Now, while the bike ignition system incorporates both a physical key and a PIN, it’s clearly not two-factor authentication since you need only one of the two to start. Requiring only one OR the other obviously makes the system less secure for the sake of convenience.  Ducati could mitigate the possibility of randomly guessing the PIN by locking out PIN entry after five incorrect attempts, but it’s still inherently more vulnerable than just having a key and no PIN.  The same rules and guidelines apply here as in secure computing.

However, with just a slight change in the firmware, you could easily require both at startup, and voila, TFA.  It makes one wonder why bike manufacturers don’t implement this idea more often.  Or auto or boat manufacturers for that matter.  Yes, it’s normally straightforward for a skilled thief to hotwire the ignition and bypass a key altogether, but is it too difficult to implement an independent PIN input that is much harder to physically rip into?  Even if you could bypass it, surely TFA would deter a casual dishonest finder of lost keys.

We at Gemini are big fans of multi-factor authentication, and as more and more of everyday tools and applications utilize this feature, such as banks, Facebook, and Google, we can’t help but wonder why physical TFA is more often reserved for expensive high-tech facilities and safes than in the devices we use every day.   Certainly TFA is not indomitable, and it does not necessarily prevent phishing attacks, as one can tell from current news on ATM skimming, but it’s certainly a step in the right direction for anything worth securing.

I often talk about cross-site scripting (XSS), and that’s partly because I think it’s a pretty interesting type of vulnerability that many developers tend to overlook. It can be quite dangerous, but can also be quite misunderstood. For one thing, the name can be misleading: exploiting XSS does not always involve scripting, and the proliferation of web technologies has taken XSS issues beyond the browser.

One example of script-less cross-site scripting affected some high-profile MySpace users in 2007. Attackers were able to inject HTML into celebrity MySpace pages, but the service filtered out typical <script> payloads. Seemingly innocent <a> links were allowed, though, and adding a bit of CSS allowed one to create an invisible link that covered the entire page. In this case, clicking anywhere on an infected profile led to a malware download.

This attack could be one of the first prominent cases of clickjacking, though the term is usually applied to attacks that hijack clicks with malicious inline frames (iframes). Allowing <iframe> elements in user-controlled HTML opens up a range of issues more broadly known as UI redressing. For instance, an iframe that covers the entire page could render a fake login form that appears to be legitimate given the site’s address, leading to a powerful phishing attack. Frames and forms can also be used to bypass CSRF protections.

Of course, you can sometimes launch simple CSRF attacks using only images. By setting the “src” attribute of an <img> element to another page, the browser will still execute a GET request to that page when it tries to load the image. Without proper CSRF protections, such an attack may be possible without XSS to begin with. But images can also be a source of information leakage or tracking, since GET requests to a malicious server will also likely include a “Referer” header.

While most XSS payloads do capitalize on the power of JavaScript, keep in mind that a browser can load scripts from many places besides within script tags. Event attributes for other elements and certain CSS properties are just two examples of places a script could slip in. And don’t forget about the risks of browser plug-ins – Flash 0-day issues or malicious PDF files can also be sources of trouble.

Finally, an issue this week served to remind that XSS is no longer just a concern within the context of a web browser. As HTML and JavaScript become a greater part of developing apps built outside the browser, XSS may pop up on other platforms. On Monday, a security researcher with the handle superevr disclosed an XSS vulnerability in Skype for iOS. By inserting HTML into the “Full Name” of a user, one could send messages that when viewed would launch code capable of stealing the phone’s address book. And this wasn’t the first time XSS has been a problem for Skype – a vulnerability in desktop versions was found a few months ago, and XSS with shared content could lead to problems back in 2008.

Alternate labels, such as “HTML injection” or “web content injection,” have been proposed to describe cross-site scripting, but the established term is likely here to say. Still, remember that protecting against XSS does not simply mean blocking script tags, and keep in mind the power of XSS when integrating web technologies with other platforms.

Let me first start off with the disclaimer that I am a CISSP and (nominally) a member of (ISC)2.

I’ve been part of very few professional organizations throughout my career and college days. I even shied away from the women in engineering groups on campus, although I knew a lot of women in them. I tended towards the ad hoc, social groups instead. Blame it on the Cotillion club I was (forced to be) a part of when I was in high school, I just don’t like paying to be part of a “club”. I pay (ISC)2 only because I have to to keep my CISSP (and to other organizations for the same reason), I’m not a member because I believe in their mission or their goals. I think they’re overpriced and useless to me other than maintaining my credential (which is another can of worms…).

I’m more likely to be found at the local Linuxchix get together, or NoVAHackers because they are cool people who just happen to have the same interests I do. Yes, we’re “organized”, but I don’t have to pay to be part of the group (other than food and drinks, etc…). These folks I consider friends.

With the behemoth that is (ISC)2, I don’t even feel like part of the group. I’m assigned a number and then go on my merry way as long as I keep paying every year and submitting my CPEs. Which I’m perfectly happy to do.

I think the (ISC)2 has admirable goals, I’m just not motivated enough to care about them that much. I don’t participate in the elections (much), and I always pass up the proctor CPE opportunities and exam review opportunities. Could I help change the organization if I participated more – probably. And Wim Remes is trying to do just that by running for the board.

I don’t know what percentage of other CISSP holders feel like I do, but I’m sure I’m not the only one. And I’m not even sure that there’s anything (ISC)2 can do to change that – it’s not their “fault” we don’t care.

Any ideas or suggestions? Or arguments on why I should care more about the organization?

In light of all the discussions about maintaining a secure posture on trusted certificates, we oftentimes forget about the little guys. In this case, I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately, it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting, here’s how you can do it.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK
Read the rest of this entry »

In the past few years, we’ve seen point-of-service payment card hardware and software capabilities extend from an enterprise level (proprietary systems) to a small business level (financial instutution-backed merchant accounts) and finally to an individual level (web and mobile payments). And it makes sense; despite the growing popularity of e-currency, most people with a bank account have access to a credit/debit card and aren’t afraid to use it. And with each step of maturity, the technology surrounding payment cards gets more and more diverse and open to innovation.

Jumio’s Netswipe is a new twist on entering payment card data online. Instead of swiping or typing, you essentially stream an encrypted video capture of yourself holding up your card. I’m assuming some OCR and heuristics on the other end translates those video frames into the actual card number. The resulting experience has the benefit of being keyless (immune to keystroke loggers), unsniffable (due to the encrypted stream), and easier than typing it out. The security benefits are complemented by the claim that the whole service is compliant with the PCI-DSS.

Yet, despite these kudos-worthy achievements, what new avenues are being slowly opened for exploitation by taking the tech in this direction? For example, when making purchases, I know what to look for to tell if I’m on a secure site (https and valid server certificate). But how do I quickly verify that my encrypted video stream isn’t being tampered with? If photo/video-enabled authentication becomes the standard, will phishing be just as lucrative on these new platforms? What about trojan’d hardware (webcams in this case)?

Innovation, especially in technology, can develop and mature despite a generally shady understanding of future implications. Sometimes, potential concerns are simply noted in passing, as if to say “we’ll cross that bridge when we get to it.” Other times, they are met with vehement resistance as issues of ethics and morality get debated. But I suspect the most interesting issues, the type that manifest themselves long after a technology has been adopted by society, are ones that were never even considered in the first place.