Dominic White - Security

Conficker Claims its First Human

nospam@example.com (Dominic White) — Wed, 01 Apr 2009 09:02:29 +0200

Conficker has claimed it's first victim, this time a live one. Conficker, a computer virus that security researchers have warned will do severe damage to computing systems from April 1st, has claimed millions of computer victims to date. However, Harry Hermulen's computer was luckier than he was.

Mr Hermulen, fearing a computerised Armageddon would occur on April 1st due to Conficker, barricaded himself in his log cabin outside the small town of Pofadder in South Africa last week. After missing the town's weekly "sokkie", a type of traditional Afrikaans dance, town members went to visit Harry. One witness described what they found as "horrifying". "We knocked on the door, but Harry didn't answer, a jean-pant were drying outside, but Harry only had one pair, so we knew he was inside." said Maggie van Schoonstad. "We opened the door and found yellow, red and blue devil's signs on all the walls," continued Maggie These were later confirmed as the logos of well known Anti-Virus vendors. "We found him dead in front of his computer, his face was all blue from the screen."

Later analysis confirmed Mr Hermulen had starved to death. Computer experts determined that while waiting for his Vista computer to boot, then clicking through the thousands of 'Allow' dialogs presented to him by the multiple Anti-Virus products installed, Mr Hermulen had not had time to eat. "His finger was full of blood and stuck to his mouse." said Frikkie Steyn a close hunting friend of Harry.

When asked for comment, Norton Symanteck, a spokesperson for Fckng-Secure Anti-Virus said, "What happened to Mr. Hermulen is a tragedy, BUT YOU'RE ALL GOING TO DIE UNLESS YOU BUY ANTI-VIRUS." Oh the humanity.

Happy April First.

Department of Home Affairs Snooping Tools

nospam@example.com (Dominic White) — Tue, 24 Mar 2009 16:37:09 +0200

Thanks to the Department of Home Affairs, it is now possibly to get a bit more creepy. If you know someone's ID number (not a hard task) you can now find out if they are dead/alive, in the process of obtaining a new ID book or married (and when).

While these would make a great addition to Maltego as new transforms, given how poorly protected our ID numbers are, I'm reluctant for the DHA to be making this info available. While this information certainly isn't a deep invasion of privacy, I am worried about them expanding the service. Additionally, the existence of these services implies that there is a DB full of juicy ID data connected to the internet, and I'm not sure they've secured it very well.

SA AV Vendor Recycling News for FUD Marketing

nospam@example.com (Dominic White) — Tue, 17 Mar 2009 13:04:26 +0200

ClassicFM just phoned me for comment on this story. I did some quick research and was rather dismayed to find that this appears to be an attempt to drum up some press references for marketing rather than a responsible informing of the public.

Update: ClassicFM has put up the story with a soundbite.

It was referencing X97M/TrojanDropper.Agent.NAI.trojan (the vendor in question isn't McAfee, they just had a good writeup) which exploited an unpatched vulnerability (CVE-2008-0081 to be specific) in early 2008, but was patched by Microsoft in October 2008. So, by now the patch is likely deployed to even your mother's machine in the cupboard, and AV vendors have got several copies of the signature deployed. In addition, the specific trojan was used in targeted attacks and it is highly likely that no person or company in SA will ever see a copy, even if they did, the generic advice of 'be suspicious of .xls files' is fairly useless.

To add insult to injury, the AV vendor seems to have received orders from their head office as their international office engaged in the same FUD last month.

This appears to be fairly blatant scaremongering in order to get their name in the papers, the sort that harm the whole industry and makes people unable to differentiate between real threats with real actions they can take. There may be a good explanation, and if the vendor in question wants to clear things up I'll publish it here, although having not mentioned their name I doubt they'll see it. In the meantime, I recommend journos blacklist them as a source.

Now, if anyone wants to write about the PDF tomfoolery that's been going on lately, that would be far more interesting. Although, even then only to IT and security types, not the general public yet.

Using Maltego to Data Mine Twitter

nospam@example.com (Dominic White) — Wed, 11 Mar 2009 10:31:02 +0200

I've previously, spoken about Paterva's awesome data mining tool Maltego in 2007. I've recently had cause to start playing with it again as part of the Privacy work I'm currently doing, and it's come a long way baby.

To demonstrate the cool sorts of data mining you can do, I decided to play with the new twitter transforms. I've produced some really nice graphs that demonstrate the power the views in Maltego can bring to your data analytics.

What I did was to start off with a phrase "@singe". I then transformed that to tweets. This showed all recent tweets to or about me. From there I transformed the tweets to twitter affiliation (i.e. a twitter user). Then for each of those users, I ran the 'tweets to' and 'tweets from' transforms. This gave me a nice first go at the networks surrounding me. Then for all tweeple who were referenced more than once, I ran the same 'tweets to/from' transforms. With the centrality data mining view, I could quickly see which tweeple were referenced several times and continued running the transforms against the most highly referenced people. I soon ran out of the 75 transforms allowed in the community edition.

From this data, I have a good idea of the twitter communication network that surrounds me. With the centrality view, you can immediately see there are two distinct networks, the South African twitter-sphere, and the Security twitter-sphere.

Centrality View - Showing 2 Distinct Networks

Centrality View - Showing Security Network

Centrality View - Showing South African Network

This is an interesting view. I know I operate within these two networks and the people in the one don't talk to the people in the other, but to have it represented so clearly is interesting.

Next, I switched to the edge-weighted view which looks at the number of incoming and outgoing connection of each entitiy. This provided some insight into how these networks are structured. It is easy to see that the South African twitter-sphere is far more connected, the people there share a common group of friends, it's also easy to pick up the central nodes of the network, stii features quite prominently. The security network on the other hand is far more distributed and far less connected, with the central players much less easier to spot.

Edge-weighted view - Showing network properties

Edge-weighted view - Showing SA Network

Edge-weighted view - Showing Security Network

The other piece of information this has provided are any people I should be following that feature prominently in either of the networks. For example, Tanya de Ville, Sheena Gates, Wogan May, Nick Jackson and Gabrielle Rosano are all people I don't currently follow but maybe should. Although, I tend to follow people I know personally in the South African network. On the other hand, I don't know most of the security tweeple personally and it tends to operate on more of a meritocracy, so this has given me some good ideas of other security tweeple I should follow; Andrew Hay, Marcus J. Carey, Thomas Nicholson and Rob Fuller.

I should add a disclaimer that I had Maltego set on max speed so it only returned 12 results, this means these graphs are very temporal based, tweple that were making more noise at the time I ran them featured more prominently. Also, I was using the community edition, and was limited to 75 transforms. Thus, don't take this as a personal slight if your name doesn't show up.

My intention is to show how Maltego's views can be used for quick visual analysis of interrelated data sets. With the inclusion of local transforms, I'm excited about the possibility of using this for all sorts of things, nessus/nmap output, firewall rules, customer info data sets etc. Nice work Paterva.

Cybersquatting and Prank Redirects - Malema and the DA

nospam@example.com (Dominic White) — Thu, 26 Feb 2009 16:00:49 +0200

Update: Verashni has since written a story on the matter.

Many non-technical people don't realise how easy it is to manipulate many of the core internet protocols. 2008 Was a particularly bad year for it with some key weaknesses being pointed out in critical protocols such as DNS, SSL and BGP (again) which have joined the ranks of SMTP, Ethernet and in-line SQL as broken. However, with all the technofeats, I forget how easy it is to do something simple that appears to be manipulation to the general public. A journo friend of mine, Verashni, noticed (amoung others) that visiting www.malema.co.za will take you to the DA's website. For any forein readers, this is funny as I'm sure Julius Malema has a dartboard with, opposing political party leader, Hellen Zille's face on it. I did a quick check of who had registered the domain and it was fairly obvious this was a prank:

2f. billingaccount : The ANC
2g. billingemail : neveranc@gmail.com
2i. invoiceaddress : Not 54 Sauer Street, Johannesburg, 2001
2j. registrantphone : +2774 115 9505
2k. registrantfax :
2l. registrantemail : neveranc@gmail.com

This isn't a technical feat, or particularly difficult to do. It likely cost the prankster R50 and 30 minutes of her time. For example back in 2007, I pointed out that thesource.ofallevil.com mirrored Microsoft's website (and still does), and a commentator pointed out that theroot.ofallevil.com did the same for Verisign (but not anymore).

However, the almost magical qualities attributed to technology by the general public have lead to some very amusing conspiracy theories. My favourite so far is: "The DA is trying to profit from Julius' popularity!" Unfortunately, there is no proof that the DA is behind this, and until we can rule out the rest of the planet as suspects, we'll just have to smirk and read Classic Malema.

This does have some domain squatting implications though. If Julius ever decides to take his "unique" brand on-line, he'll likely need to go through some legal procedure to get "Not the ANC" to relinquish it. You can read more about "Cybersquatting" on Wikipedia.

A Response to Bejtlich on DLP

nospam@example.com (Dominic White) — Wed, 04 Feb 2009 21:14:47 +0200

Richard Bejtlich just posted an entry entitle "Data Leakage Protection Thoughts." In it he argues that Data Leak Prevention products will just lead to a new barrage of alerts for someone to ignore (ala IPS/IDS), or blocking a too-small-set of data for which a significant amount of time would need to be invested to understand how to block. I'm paraphrasing, but I think it provides the gist.

Before I provide a response, I must preface it with the fact that we are currently working on and selling projects which use DLP tools.

That said, what I think Richard misses about DLP is the fingerprinting and discovery aspect. DLP solutions provide radically enhanced methods of fingerprinting and finding 'unstructured' data beyond comparing hashes or strings. Unstructured data, is data that doesn't follow some kind of programmatic pattern. For example, credit card numbers are structured data and need to conform to certain guidelines. It's fairly easy to find and detect that sort of data. Unstructured data on the other hand are things like spreadsheets, documents, presentations, podcasts, movies etc. However, even then those are just containers for the data, and it is possible for the same information to be copied from a word document to a spreadsheet (for e.g.). DLP provide a way of fingerprinting the underlying information, and then detecting it across the organisation.

For example, one could fingerprint the board minutes on a PA's laptop, then examine all mailboxes, databases and file servers to locate them. Or, one could do the same for customer records and work out which systems are storing customer personal information. Alternatively, one could work out which systems are in scope for PCI DSS compliance (or descoping) because they contain card-holder data. Then, much later, one could monitor communication channels, flash sticks and printers and block any instances of the classified information being distributed outside of designated groups.

The reason this sort of stuff is important, is that organisations aren't very good at knowing where their important data is. People who've done 'information classification' projects before, will tell you they took a long time because the business people knew what data was important, but not how or where it was stored, and the IT people knew which systems the business people thought were important, but not which parts of information in that system were important. Being able to do this sort of fingerprinting and discovery makes the task of mapping these to each other much easier. Additionally, being able to fingerprint a blob of data and assign the whole blob specific properties makes life easier. You don't have to classify each paragraph of the board meeting's minutes, you can fingerprint every one and assign a policy to all of them.

The second part of a DLP solution, the enforcement, is the bit Richard was talking about. If we look at previous information classification projects again, even if you did come up with a decent data/system/comms map and classification scheme, you couldn't do much more than write policies or put a bit more effort into securing the systems holding the important data. The DLP tools let security teams start putting controls around the actual data, not their format or system, and provides a method to enforce that policy. In implementing this part, it's easy to alert on everything and end up with an unmanageable and unwatched list of alerts. Initially, key policies should be expressed as a block rule, assuming you aren't an unrealistic rule-nazi this will allow you to define rules for very confidential information or high-risk leaks (e.g. 1million customer records and one set of minutes of a board meeting). However, once you've got that tweaked and usable, all the stuff in the middle may need a more nuanced approach in the form of logs and alerts. It's my personal belief that security analysts can't do that part, I've tried and it's just way too much work. The communication context is something the data owner needs to comment on, and takes too much time to work out. This is where I think the workflow component comes in as described in my other blog entry on the topic.

Then (almost) finally, I think DLP has potential to allow an organisation with an immature security posture, to fairly quickly put controls around high risk data, start working out where their high risk data is stored and where their biggest leaks are. Those last two will help them prioritise their security efforts better than the other risk assessments consultancies like mine are famous for overcharging for ;)

I do agree that DLP tools aren't going to provide a fool proof way of detecting all attempts at smuggling data out. I've tested a couple and while steganography works all the time, in some cases just bzip2'ing it worked too. I don't think only stupid people will get detected by the DLP tool (although given the number of "mistakes" you end up seeing, blocking stupid is useful) as they do go quite far in picking up things like copy pasting snippets of text into other documents or inserting some random text in between paragraphs etc. But in the end it won't kill that werewolf for you.

Opt-Out of Online Advertiser's Profiling

nospam@example.com (Dominic White) — Mon, 02 Feb 2009 21:59:21 +0200

I've been saying to anyone who would listen, that many advertisers (such as Google and DoubleClick - owned by Google) don't let you opt-out of their profiling. Essentially, many advertisers set a cookie and use it to track you across sites. This is useful to add state to stateless HTTP, but often lots of third-party cookies are set by advertisers which have no function other than to help profile you, i.e. it's possible to have a perfectly functional site without these cookies.

However, while trawling through Google's privacy policies, I found a gold-mine of opt-outingness, and it appears I was wrong. Not only can you opt-out of Google's and DoubleClick's profiling, you can opt-out of almost every other one! What this does it set a specific opt-out cookie, that will prevent the code running on the ad platforms from using or recording profile data to serve you ads. You will still see ads (unless you run Ad Block Plus), but they will not be based on inferences from your surfing history. As it uses cookies, this will only work as long as the cookie is there, so other browsers/computers won't have it, nor will they remain if you delete your cookies. I still recommend not accepting the cookies in the first place (Cookie Safe helps with that and is easier than managing it through browser prefs), but if you must (e.g. to use gmail) then there's very little reason to not opt-out.

While this is quite cool, and certainly makes me heap less derision on online advertisers, there is a caveat that you are trusting the advertiser that they have opted you out. For example, doubleclick.com still has an ASP session cookie set which could be used for profiling if they felt like it (several of the other ad partners also have opt-out cookies with what looks like unique identifiers present). I would still recommend blocking these third party cookies just to be safe, and you don't really loose anything by doing so. Additionlly, non-ad profiling such as your Google life-time (now 2 years) cookie or YouTube tracking cookie will still be present and used to profile you (unless someone can show me a cool way to opt-out of that?) so this certainly isn't a panacea.

The big problem is that anyone who indiscriminantly accepts third party cookies, is also not likely to know about/care about/find the opt-out page. Either-way, the Network Advertising Affiliates deserve some credit for this.

ARIAD - AutoRun.Inf Access Denied

nospam@example.com (Dominic White) — Sun, 25 Jan 2009 23:10:59 +0200

Viruses using the autorun.inf file of removable media such as flash sticks and iPods to automatically execute and install themselves whenever they are plugged into a machine can now be thwarted by Ariad. This is a big vector at the moment.

It's a file system filter (I didn't know about these, they're cool) that blocks access to autorun.inf and effectively stops windows from automatically installing viruses for you (aka a design flaw). Group Policy should allow you to do the same thing, but if you have either incompetent domain admins, some inheritance complexity of multiple policy applications have self-imploded, or a family member who uses their USB without protection, this can help fill the gap.

Courtesy DiderStevens - Ariad

Dider asked me to add that at the time of writing this is beta software, so test it first.

Why Patch Management will Remain Hard

nospam@example.com (Dominic White) — Sat, 17 Jan 2009 10:49:21 +0200

A discussion with haroon yesterday revived some of my interest in my MSc thesis topic. Then serendipity brought Eric Schultze commentary/apology on the MS09-001 patch to my attention.

First, some justification. Patch management is still a poorly practised discipline. I can't think of a single audit report either written or reviewed by me that didn't mention missing patches as a finding. This is also a non-trivial issue. Patches drives attacks (you can read my vulnerability life-cycle for more justification), missing security patches really do put your organisation at risk, no matter how jaded we are about them.

Arguably, Microsoft has done the most work in making their patches reliable and easy to install. However, it's still possible for a highly experienced patch management expert to get things wrong in understanding the impact (and hence appropriate prioritisation) of a patch.

However, the people within your organisation responsible for 'patch management' are usually fairly low level techies. It is often seen as a plumbing and maintenance issue. You certainly don't have your top sysadmins jumping to it every Tuesday to put together a regression testing schedule and work out which machines to prioritise the deployment to. In South Africa, things are a little worse, where there appears to be an increasing dearth of top sysadmins, as many of them move up into less technical managerial positions away from the care of the metal, thankful to leave plumbing issues like patching behind them.

This is where the disconnect comes in. Even with a comprehensive toolset to easily deploy patches. The technical and security experience required to properly understand the affects of a patch, coupled with the operational and organisational experience required to understand those applied to a specific organisation are quite large however this maintenance issue is usually given to a junior technician. Additionally, even though Microsoft's patches have improved their stability dramatically, people still err on the side of caution and tend towards non-deployment. This disconnect can be resolved via an organisation patch management policy that codifies much of that experience, but in the words of haroon "Management don't buy into who cleans the fridge or when the light bulbs are replaced." For the same reason low-level techies are sent to do the patching, management are unlikely to spend money and time getting patch management right. The right way to cut through that is with a risk-based argument, although not every organisation has a risk-management function motivated to do much about patching. Why? Because it's boring. Not only is it boring, it's repetitive; every month there's more. I personally find it very hard to care about patches these days.

However, these are the problem in the case of some of the best patches out there. But the software stack deployed on your average desktop, let alone across the organisation is far more complex, and most third-party vendors haven't gotten their patch process up to the same level as Microsoft. Even if they have, they often come with their own seperate infrastructure that many organisations are disincentivised to duplicate, and this isn't likely to get better any time soon. There are great tools out there to help with this, Lumension and Shavlik for example, however as per the previous paragraph this isn't the sexy sort of problem people want to spend lots of money on, and getting everyone to run Debian, while ideal, is impractical :)

So that's my litany of problems around patching. While quite different from several years ago, much of it remains the same or is just a subtle reformulation. I don't see patching getting better, and I don't see people willing to spend much time (outside of select vendors) to make it better. But the risk remains (and your IPS which you never check anyway won't save you).

Initial Ideas on How to Detect a Rogue CA Cert

nospam@example.com (Dominic White) — Wed, 31 Dec 2008 11:48:19 +0200

Based on Verisign's response here and here (in the comments), they have prevented future attacks, but seem to find the undermining of their PKI for the next several years an acceptable risk versus revoking thousands of certificates at great expense. However, Tim did mention that if they can find a unique characteristic of the bad certs, that would help, here's my attempt.

The Netscape Comment Block won't conform to the ASN.1 IA5String type. From the paper:

These two problems together ask for a place in the rogue CA certificate to hide 427 bytes of data in, some of which are random looking, and some of which have an interpretation that should not be shown in certificate viewers. The solution we adopted is to define a so called "Netscape Comment" block. This is a proprietary extension in which any data can be stored, which will be ignored by most certificate processing applications, including the major browsers. There is a small problem here in that formally the contents of this field must be of type IA5String, and our content is not of that form. An ASN.1 parser that strictly follows the standard will complain about this, as happens e.g. with Peter Gutmann's program "dumpasn1". But as most application software ignores the extension anyway, the certificate with this standard violating field in it will still be accepted in practice. It is conceivable that the 427 bytes could have been hidden in a different extension field (there is even an X.509 certificate with a movie hidden inside).
This won't work if an end-use cert, such as a website cert is generated instead of a CA cert, as in the former's case the 'tumour' can be hidden in the public key block.
The signing certificate of the rogue CA will be the wrong one for an intermediary CA, if the CA has set their PKI up properly:
My reasoning for this, is that if you have (for example) a three tier PKI. With an off-line root CA, and intermediary issuing CA, and end-point signing CAs; then any intermediary CA certs issued should be signed by the middle point in the tier and not the end-point. Once again, this won't work if the rogue cert is a an end-use cert instead of an intermediary CA cert, but this reduces the scope of the attack significantly, as a weekend of burning through 200 Playstation cores will only break one site, instead of allowing a transparent mitm.
The CA that signed a certificate uses the MD5 hashing algorithm:
By itself this does not indicate a problem, but combined with the other two factors above, if false, it would allow the cert to be excluded as untrusted.

If these and other factors can be discovered, certificate validation routines can be updated to proactive detect rogue certs based on the current attack (Firefox add-on anyone?). I'm not sure how modifications to the attack will affect these. For example, if MD5 collision attacks become advanced enough to generate collision blocks that are ASN.1 valid, it would be excluded, although it feels like a a significantly big hurdle for it to remain effective.

Using MD5 Collision to Create a Fake CA Certificate

nospam@example.com (Dominic White) — Tue, 30 Dec 2008 19:24:55 +0200

The presentation by Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik and Benne de Weger is done. ~~I am busy reading up on it and will post a summary and my thoughts here a bit later. Those are happening real-time on my twitter feed or on the right panel of my blog.~~

There's already a lot of coverage on this. I'm going to dig into laying blame, and potential geeky solutions for the end user.

The Attack

I need to cover this quick. The below paragraph from the white paper was the one which explained what was being done the best.

Our attack scenario basically is as follows. We request a legitimate website certificate from a commercial Certification Authority trusted by all common browsers. Since the request is legitimate, the CA signs our certificate and returns it to us. We have picked a CA that uses the MD5 hash function to generate the signature of the certificate, which is important because our certificate request has been crafted to result in an MD5 collision with a second certificate. This second certificate is not a website certificate, but an intermediary CA certificate that can be used to sign arbitrary other website certificates we want to issue. Since the MD5 hashes of both the legitimate and the rogue certificates are the same, the digital signature obtained from the commercial CA can simply be copied into our rogue CA certificate and it will remain valid.

For more detail, you can check these out:

Detailed explanation
Slides from the 25c3 presentation
Demo site (set your system date to August 2004 before clicking)

Blame

At first, the fault of this attack lies with the certificate authority vendors who have been using MD5 despite several warnings that it was broken. The fault is also partially with us security guys for not ranting harder about the fact that they were using a known broken protocol. However, this is not the first trouble with CAs, for example in the past it has been possible to get certain trusted and lax CAs to issue fraudulent certificates.

How is it then, that we have companies who's sole job is to make sure people are who they say they are and own what they say they do and represent that in the beauty of mathematical cryptographic certainty get one, or the other or both of these wrong?

We have standards and audit procedures for CA's, to name a few (courtesy of Mozilla's CA inclusion policy):

Annex B, "(Normative) Certification Authority Control Objectives", of ANSI X9.79-1:2001, Part 1: PKI Practices and Policy Framework;
Clause 7, "Requirements on CA practice", in ETSI TS 101 456 V1.2.1 (2002-04) or later version, Policy requirements for certification authorities issuing qualified certificates (as applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
Clause 7, "Requirements on CA practice", in ETSI TS 102 042 V1.1.1 (2002-04) or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to any of the "NCP", "NCP+", or "LCP" certificate policies);
"WebTrust Principles and Criteria for Certification Authorities" in AICPA/CICA WebTrust Program for Certification Authorities, Version 1.0; or
"WebTrust for Certification Authorities—Extended Validation Audit Criteria" in WebTrust for Certification Authorities—Extended Validation Audit Criteria (or, for CA requests received on or before June 30, 2008, the November 20, 2006 draft of these criteria) (in conjunction with "WebTrust Principles and Criteria for Certification Authorities").

Let's take Thawte as an example, since they were started by a South African and were fingered in the talk today as one of the vendors who are still using MD5 signing. They are audited annually against the WebTrust Program for Certification Authorities by KPMG. The report for 2007 can be found here, and the certificate here (RapidSSL's is here, both RapidSSL and Thawte are owned by Verisign). Both the reports come out clean. So either the auditors missed this, or the standard doesn't check things as basic as the hashing algorithm. A quick check of the standard makes no specific mention of the hashing algorithm, but generically refers to encryption algorithms as needing to meet the relevant criteria based on a "risk assessment and the business requirements of the CA." Given that no properly conducted risk assesment would highlight MD5 as acceptable, it can be assumed the risk assesment was not proper. So every year since MD5 has been highlighted as broken, the auditors have failed to notice this problem. This slips neatly through the accountability gaps it seems. In the end, here's my blame list in order of decreasing severity:

The CAs - it's their business and they need to proactivley secure it, especially when public warning of problems have been given.
The auditors - they're paid to validate what the CA is doing, and have specifically reviewed and signed off on the key management practises of most of the affected CAs.
WebTrust - a certificate standard needs to be more specific about something as fundamental as a hashing algorithm, and ideally proactivley highlight the risk of MD5 to the CAs and auditors.
Every security guy who has received an MD5 generated cert hash and never gone further than thinking "Isn't MD5 broken?" (I'm one of them.)

Solution

There are a bunch of hard, kak, solutions that the CA need to work with. Certificate Revocation Lists aren't implemented well, and at most will provide a reactive solution in cases where malicious activity is uncovered, much like anti-virus :) I'm not going to get into those.

For the rest of us, we need to trust CAs much less. Not just until the affected CAs move away from MD5, but until the root certs stored in your applications (like your web browser) expire and are changed. This is because the rouge intermediary CA certs will look legit as long as those are. Even then, I don't trust CA's much. I already suggest that in some cases previous to this bug, that certs should be treated like SSH keys. This require evaluating each certificate and trusting it specifically. An easy way to do that beyond having their fingerprints tatoo'ed on your arm is to use the Petnames's add-on for Firefox. The first time you visit a website using SSL that you need to be secure, examine the certificate, if if looks legit, assign it a petname by typing it into the petnames toolbar. Then make sure whenever you visit the site that the petname is displayed. If the petname stops being displayed, try and work out if the previous cert has expired or been legitimately replaced, if not, then it could be a man-in-the-middle attack. A few of the way I recommend checking whether a cert is valid are (in order of usefulness):

Check that the URL you're at is the right one. If you want to be a standardbank.co.za make sure there isn't anything else after the za.
Make sure all the usual requirements for validity are met. The easiest way to do this is to make sure your browser doesn't pop up any warnings (I'm talking about banks not this site :) ).
Check if a user on another computer, using a seperate internet link is presented with the same certificate (double click the lock icon and check the fingerprints).
The certificate has been the same for the past couple months/years (this is part of the ongoing observation, rather than the initial).
Check that the companies listed in the cert are what are expected, I put this last for a reason.

Apart from (4) this is a once off evaluation that can then be looked after by your petname. It's also something you can install for your non-techie mother and teach her to follow fairly easily: "If this is ever not green or not saying Standard Bank, then phone me."

That's all for now.

OpenVAS & Metasploit

nospam@example.com (Dominic White) — Mon, 29 Dec 2008 00:06:02 +0200

hdm just posted a graphic on his twitter feed of an OpenVAS client talking to a Metasploit server. This is pretty cool, and the possibility of integrating ~~Nessus~~ OpenVAS at the ~~NASL~~ NVT level (assuming that's what's happening) gives a good reason for greater adoption of the OpenVAS project.

DLP, Users and Workflows

nospam@example.com (Dominic White) — Wed, 10 Dec 2008 22:42:19 +0200

Jock (welcome to the blogging world) and Allen have responded to my last entry on Data Loss/Leak Prevention (DLP) vendors partnering with Digital Right Management (DRM) vendors. Jock had an interesting point about getting users involved via DRM, and Allen had some ideas around maturing DLP processes. I'm not sure I fully agree with Jock's ideas, although they do point to some important points that Allen and I agree on about workflows (but not that DLP is dead ;) ). Jock thinks that the integration of DRM will make the user more conscious of the need to protect data. By exposing the features in office, and integrating it into the usual 'how-to' training instead of separate security training, this could become a de-facto way of getting users to look after their own security.

Now, this is something we want. The big problems with implementing a DLP solution, as I see it are:

Understanding the context of a communication in order to make the correct security decision
Building a workflow that the data owners manage, not security

Communication Context

The first point is where getting the users involved helps. To provide a round-about illustration; while running a DLP PoC I cam across several points where I did not know whether the incident discovered was a breach or a problem. Should the sender have access to that information, should the receiver, and how sensitive is the information in the first place. For example, we noticed communications about a confidential strategic project going to a Gmail account of someone who did not work for the company and was not obviously affiliated with anyone who knew about the project. To resolve it we needed to follow up and investigate. It turned out the information was going to lawyers who's mail servers were bouncing the mail.

Another incident showed a massive amount of credit card numbers going from a DBA to HR people at a competitor. Upon investigation it appeared that the DBA was sending his CV to the competitor, but had inadvertently attached a DB dump he had been using for debugging purposes.

Both of these incidents required additional context and understanding, which takes time and a soft-touch approach (you can't storm the board demanding to know why information was sent to an unknown gmail account). This is not something a small security team (as they all are) can practically deal with. You also can't hire junior lackeys to do it for you, because they'll have even less of an understanding of the context.

Users can Help

This is where Jock's point comes in, getting the users involved and more aware via the DRM functionality could help them embed some of that context as security principles. For example, if a document should only be shared between the board, then the PA typing it up can embed that assertion. Or more simply, if a document is final and you don't want any surreptitious changes to be made, you can mark it as final without relying on the idea that people can't modify a PDF.

While I think DRM functionality is great, and I am glad to seem the DLP vendors integrating it. I don't think this is going to help us with the communication context. In the first example with the gmail account, the criticality of the information would be no more obvious, and the person it was being sent to would be no less anonymous. In the second incident, the DBA would not be less prone to mistakes, and it is unlikely that DRM will be embedded in the debugging DB dump.

Data Owner Workflow

This is where the second point comes in. It is my belief that it isn't the users that will be able to help with DLP, but the data owners. While this is a fairly obvious statement, the few DLP implementations I have seen which consider the data owners at all is slim, and the number which try and get them involved in the DLP processes are near zero (although this is coloured by DLP not being a currently wildly deployed process). However, when you speak to some vendors and ask for information on these sorts of processes, they usually don't have it.

Funnily enough, I just read Allen's entry on this topic and it seems we are about to say the same thing.

What you need is to get the data owners involved. They need to be empowered to have the tool understand their critical data, and provide workflows around making decisions on what is being done with it, in line with the relevant communication context. Allen call's this 'business context' but I think 'business' is an abused term as is.

For example, if the minutes for the last board meetings are being mailed to an unknown external person, then get the COO's PA to approve it, and if necessary escalate it to the COO. If the DBA is sending credit card details to the competition, get the customer transaction guy to approve it, block and alert or escalate to someone else. This needs to be done careful and intelligently to prevent hours of wasted time while user's click the approve button on 30 e-mail each morning. It also needs corresponding processes up front, ideally built into the process of data creation, to have the principles defined.

This is where the DRM integration helps. Security assertions in line with the data owners approved use can be defined once and checked in both the DRM and DLP environments, but without the workflow components, this just becomes another firewall - blindly blocking with little understanding of what is encapsulated in the content.

For these purposes, I like Allen's differentiation between Generation 1 and Generation 2/3 type solutions.

Security Teams Benefit

With the above in mind, I don't think that security teams should be blindly ignoring the DLP solution's alerts. There is an awesome amount of information about what people and what data is actually being used and how, that can help security teams better approach some of the harder security problems. I am not advocating a 'thought police' approach as often happens with these sorts of technologies - creepy security people reading your e-mail and surfing habits so that they can stop all this awful non-productive behaviour (is that an mp3 I see?!). I mean actually getting an understanding of reality, and implementing solutions that take reality into account. But the price tag doesn't justify this being it's only use.

DLP Vendors Partnering with DRM Vendors

nospam@example.com (Dominic White) — Thu, 04 Dec 2008 13:26:45 +0200

First RSA with Microsoft, then McAfee with Liquid Machines. It makes sense, especially for companies wanting to get proactive about preventing data loss. Although, what DRM (Digital Rights Management)/ERM (Enterprise Rights Management) doesn't have that DLP (Data Loss/Leak Prevention) does is the simplicity. It relies on user's pro-actively protecting their data, something we know we aren't good at. Sure, the DLP solution is there for when they don't, but then what's the point of the ERM solution? I'm playing devil's advocate a bit here, and am not committed to that position. It is interesting to note that there hasn't been much partnership between DLP vendors and other 'data focused' security products such as database activity monitoring (DAM) or data backup vendors and only limited partnership with encryption solutions. ERM seems to fit well from a marketing point of view, but I think there are some key integration points between the other solutions that can provide an easier security onion (aka defense in depth).

27 Dinner Tonight

nospam@example.com (Dominic White) — Mon, 24 Nov 2008 00:24:31 +0200

Tonight's 27 dinner was great. I haven't been in a while, but there was a good crowd and I had some really interesting conversation. My presentation went well it seems. I've attached a copy here if anyone is interested.

The talk was focused on cross-site request forgery attacks. As it was mostly a non-security crowd I tried to make it accessible. I demo'ed a CSRF against Vodacom4ME's online SMS functionality (which I rely on for vodasms). I also demo'ed a CSRF against muti, with code injected via a persistent cross site scripting (XSS) flaw in 27dinner.com. In effect, anyone logged into muti who viewed the Jozi 27dinner guest list also voted up this post on muti. I finished it off with a demo of BeEF proxy. For tips of defending against it in your app check out this entry.

I've removed all the demo code, as I can just image someone dubious sticking muti CSRF's all over the place to falsely inflate their posts ranking.

Anyway, thanks for the good conversations, and great feedback, in particular:

Also, thanks to the IRC geeks who helped with some of the ideas and finer points at funny hours in the morning last night: