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.

We all have passwords.  Most of us hate writing a new one for every new account we open.  The traditional thinking always said that for a password to be secure, it was necessarily unwieldy to memorize.  So who wants to memorize vRg5BoTA for your new Spotify account when you just solidified a mnemonic in your head for your Gmail password?  Many older account systems limited your passwords to be between 6 and 12 characters, so increasing complexity through a larger alphabet and using non-dictionary words was crucial to give yourself a chance against password guessing attacks.  If you’re still using 6 character passwords, I have bad news for you: you’re so laughably vulnerable, you don’t even register as roadkill for a dedicated cracking system — more like a mosquito trying to escape the pull of a fighter jet turbofan.  A case-sensitive alphanumeric 6 character password has just 57 billion permutations.  If you include all 95 printable ASCII character possibilities, that’s still just 690 billion permutations.  Even setting aside obvious and potent optimizations such as dictionary word checking and 1337 substitutions, professional cracking systems can brute force 30 billion passwords per second!

More likely our readers already know that short passwords are practically useless and have adopted longer passwords of 12-20 characters or more.  Perhaps you’ve read the recent xkcd comic demonstrating that several case-insensitive common words strung together are collectively more secure than conventionally complex 10-12 character passwords.  In a general sense, yes, increasing length increases difficulty so much more quickly than making your password unwieldy.  Some of us at Gemini prefer to use whole sentences as passwords (as long as 30-50 characters) where possible.  Even if case-insensitive, a length of 30+ is so non-trivial that brute force attacks are eons beyond impractical.  However, not all account services permit you to use passwords that long, so to remain secure, you have to rely on high complexity (and maximum length).  If you have many of these types of accounts, it may be easier to use a password manager for those accounts such as LastPass, a tool that saves and encrypts passwords for your use, after prompting for a master password (this can be long and complex and also further bolstered by multi-factor authentication).

Sometimes it can also be difficult to manually devise a truly random complex password for these accounts, and for that there are many password generators, but I personally prefer using Wolfram Alpha because it gives a very thorough summary.  Just enter “password of n characters”, where ‘n‘ is the length you require, and it produces a lengthy report.  One interesting application is that it also spits out a phonetic form of your password in call signs, which can help you memorize the one they gave you or be used as a very long password itself.  Wolfram Alpha also displays the password entropy and total permutations of passwords that length for varying alphanumeric sets, which is rather interesting to see, and you can change password input rules, too.  For instance, if I want to write out an all-lower-case sentence of 30 characters for my password, WA tells me that there are about 10^42 permutations and 185 bits of complexity – far too difficult to brute force.  In case you’ve never seen or done these calculations before, this is a terrific way to gauge how secure your passwords ought to be.  It also gives nice examples of each for you to write down (the text isn’t selectable).  This tool is quite handy and was also recently featured on Lifehacker.

SSL certificates have been in the news lately (again), and there’s a huge uproar. Is SSL still OK? Is PKI dead?

While most people understand the technical side of PKI, I’ve found that the “soft”, or what I call the “political” side, is not as well understood.

Anyone can set up the technical infrastructure to become a CA – but what makes the Root CAs found in your browser special? And as a corollary, how do you get into that select list? Each company officially has their own method of determining what CAs are in their list of Trusted Roots. Mozilla clearly outlines their requirements on their wiki, and Microsoft has a program for inclusion. In general, there are a few technical requirements, and “the audit” – usually a WebTrust audit. I’ve audited CAs (not a WebTrust audit), and what you look for is compliance with the stated policies. However, the stated policies might not be the best option for a Root CA. WebTrust just requires that

“Subscriber information was properly authenticated (for the registration activities performed by ABC-CA).
The integrity of keys and certificates it manages is established and protected throughout their life cycles.” (http://www.webtrust.org/item27804.pdf)

So, what is “protected”, what’s “properly authenticated?” That’s left up to the CA to decide. As long as the CP and CPS cover what the CA is doing, how they’re doing it, and the auditor thinks it’s “protected” or “properly authenticated”, it’ll pass the audit. Generally, once the audit is passed, it’s almost trivial to get into the operating systems and browsers – just a paperwork exercise.

In the case of Diginotar, we can assume they’ve had a recent audit (not necessarily WebTrust) because they’re in Windows and Firefox (NSS), and the auditor felt that they were “secure” enough. Something went wrong though in the subscriber identity proofing process (if it even happened). The CA is just a tool, it can enforce some policies, but not all – it has no clue that the people requesting the certificate for *.google.com are not really Google – the RA function checks that then instructs the CA to issue the certificate(s). If the RA function was bypassed (intrusion into the CA), then the CA will do as it’s told and issue the certificates.

Ideally, CAs have an off-line root CA – no network connection, generally turned off, and only able to be turned on by the folks who have control of the CA. This is the Root CA that is in the operating systems and browsers. Then, that Root can revoke its sub-CA certificates, and life moves on (except for folks who now have to get a new certificate), and most people won’t even know. When an on-line root is compromised, it’s a bigger deal for everyone involved to revoke that CA – patches are issued, instructions go out on how to delete it or distrust it, etc.

Most people blindly trust the Root CAs in their browser/operating system – have you looked at the list in your OS/browser of choice? Do you know anything about these CAs or are you trusting the folks at Mozilla, Apple, and Microsoft to tell you if they’re to be trusted?