This is a pretty pointless entry talking about the simple crossword challenge provided by the ITWeb Security Summit.

After Jacob outed the compromise at one of Comodo's resellers, I decided to see how I could best secure my browser when it comes to TLS. This is important given how fundamental TLS is to our daily online activities. The advice I currently recommend and have implemented myself in Firefox 4 consists of:

• Install HTTPS-Everywhere
• Reducing the number of trusted root CA certificates to the most frequently used
• Forcing OCSP revocation checks
• Monitoring for certificate changes

This is a brief how-to enable the same in your browser.

Come the turn of the year, many people draw up list of predictions for the next. This list is slightly different, instead of focusing on what new threats, vulnerabilities or attacks we'll see, this is a list of some things that, if not already handled should be in your security strategy for this year. Some organisations are further along than others, and this list is targeted at the average ZA organization based on my observations. (Full disclosure, some of the items relate to services my employer offers, that's just because I believe in them).

While sitting is a couple of talks at BlackHat Abu Dhabi, I got to thinking about how we can improve browser defenses. Much of the problems we have are due to the same problem that has plagued systems since Captain Crunch first blew his whistle at 2600 hertz; the data and control channel are the same. Your browser can't tell the difference between attacker injected script and legitimate scripts and happily responds to both. It's what allows XSS and CSRF attacks, and even SQLi. Framebusting is a great example of this, a site owner doesn't want his page to sit in a frame, but has to compete in the arms race against attackers who want the site to be framed. What we need is some way for a site-owner to specify a security policy, that exists outside of the application. The site-owner should be able to specify that the site shouldn't be framed, and the browser respect that, without an attacker able to inject an alternate set of instructions (or at least not trivially via the actual app). Right now, even if a site-owner is aware of the problem, with a smart security team, all they can do is compete in the arms race.

There's a corollary to the problem however, third-party content. The web is made of mashups. Even single-source content providers still include a raft of third-party content, from RSS feeds, to advertising or JQuery. This introduces a whole set of potential interconnected vulnerability that a site owner can't control. If an ad provider is hacked and used to distribute malware, then the site-owner's only choice (if detected) is to remove the ad.

We need something that can give a site owner control back of their application. Something that can be specified outside of the page content. A security policy that puts all the controls we have available to us with software (enforced security policy & ability to disable features not required) back in the hand of the right people. Once we get it, there's a whole separate discussion about how to get it widely supported and implemented, but we would need to agree on what that should be first.

I've been playing with ways of nuking evercookie-style identifier dropping (note: killing the evercookie specifically is silly, I'm aiming for unknown reimplementation too) and have worked some stuff out about LSOs. LSO are Local Storage Objects, they are ways Flash and Silverlight can store info on your machine rather than the remote server. The most common uses appear to be to drop an identifier, which behaves in exactly the same way as a cookie, or to store preferences (e.g. youtube volume settings).

The following information pertains to OSX, I'll get to other OS'es but I imagine their implementations won't vary greatly.

The ZaCon II CFP is nearing it's closure date (tomorrow!), and this is an overt reminder to all of you thinking about submitting to do it. ZaCon is a great place to either give your first infosec presentation or deliver a tech-heavy presentation to a receptive crowd. All you need do is submit a short abstract to abstracts@zacon.org.za and if your submission is accepted, prepare and deliver a presentation. You don't even need to write a paper. If that isn't lowering the barrier to entry enough, then you're just lazy :)

If my submission is accepted (heavy bribery underway), then I'm hoping to set up an infosec BP-style debate, and will be approaching some of you "I'm smart but never share that outside the office" types to get involved, and hopefully have some fun.

You can read more of my thoughts on ZaCon here. Also, at some indeterminate point in the future, some ramblings about ZaCon will appear in episode 18 of Let's Talk Geek.

BlackHat and the stuff surrounding it was an incredible experience this year.

This has been reposted from it's original at my new second blogging home at SensePost.

In my previous role working as a security manager for a large retailer, I developed some password tools for various purposes, primarily to help non-security people with some of the basics. I licensed them under the GPL, and I think it's about time they saw the light of day.

There are a couple of tools, which I will explain below. They're all written in JavaScript, primarily because it is cross-platform, but can be centrally hosted. They all work in Firefox and Internet Explorer, although the automatic copy to clipboard functionality of the service desk tool is IE only.

The intention is for the tools to be placed into your organisation's intranet somewhere. I found they came in much use, allowing me to reference a specific tool and setting rather than esoteric password theory in documents. For example, security standards documents would say "Service account passwords should either be generated by the password generator set to the service account setting, or be rated as "very strong" by the password strength checker", which is far more practical than quoting a list of password rules.

Being centrally hosted also allows updates to be made immediately in the case of a policy change, new common password addition, or bug. This also allowed web logs to provide an audit trail of who was using the tools. Particularly useful in the case of monitoring service desk activity e.g. If the service desk records 100 password resets, and the tool only saw 10 hits, you know something's up.

If you're a tactile learner, you can grab them here.

Verizon's Wade Baker (with assistance from Dave Kennedy, who I will refer interchangeably to as with Wade, Dave or Verizon) published a post claiming that vulnerability/security researchers are given too much leeway, and are closer to criminals than good guys. He suggests they should rather be called "narcissistic vulnerability pimps" (NVPs) in future. Dan Goodin got some clarification when writing his piece for The Register which expands on some of Verizon's motivations and justifications.

While I think I identify with part of his frustrations, he's wrong. Mostly due to an overconfidence in how vendors optimise for "shareholder value", but also because while scrabbling to paint vuln researchers as bad guys, he forgot about the actual bad guys.

Eugene Spafford has a warning for us in his latest entry that I thought worth remembering:

Generally, hackers who specialize in the latest attacks dismiss anyone not versed in their tools as ignorant, so I have heard this kind of criticism before. It is still the case that the "elite" hackers who specialize in the latest penetration tools think that they are the most informed about all things security. Sadly, some decision-makers believe this too, much to their later regret, usually because they depend on penetration analysis as their primary security mechanism.

In many ways, I worry that mechanisms like RSS & twitter and the associated behaviour help us to be up to date, but not knowledgeable, and that the implied arrogance of being up to date stops us from realising it.

I'm quite excited and honoured to host a guest entry from Yusuf Moosa Motara covering his talk at ZaCon (a video of which can be found here, and the slides here).

Update: Haroon's talk "Why ZaCon" at the con provides more of an overview. Including some aspects I didn't consider.

Our first South Africa fledgling unconference-like security conference, ZaCon, takes place this Saturday (21 Nov). Our intention was to have something which fits in the gap between corporate conferences like the ITWeb security summit and academic conferences like ISSA. The former is huge and can afford to bring over some of the big names, but also has plenty of "paid for" opinions and a sometimes less meaty content. The latter is peer-reviewed and requires more than a slide deck and a grin to present at, but also sometimes values theory over pragmatism and places a large burden on people already holding down a job.

As someone who uses a lot of web apps, I run into the problem of trying to remember multiple passwords. Most people resolve this by just using the same password across all the sites. However, as numerous, examples, have, demonstrated, that's not a good idea. The knee-jerk counter is to use a different password (or groups of passwords) across the sites, but that becomes difficult to remember. If you want the quick solution I'm proposing then check out SuperGenPass (or my customised version). The security geek details follow after the jump.

Boy do I have news for you security people out there; I have a 100% reliable way of breaking all encryption! I call it the "Evil Thug" attack. I provide this service for a small fee. The entry level service will get me or an employee for a hour, this is all it will take to break any encryption in the world (and no we don't need a prostitute, even for 2048bit RSA encryption).