You are viewing boblord

Security, Crypto, and Random Topics
Recent Entries 
I'm a fan of Robert Vamosi's podcast on Cnet. Recently he had two shows that caught my attention.

First, he talked to Tom Murphy, chief strategy officer for Bit9 about whitelisting. Link

He also talked to Eva Chen, co-founder and CEO of Trend Micro about anti-virus protection. Link

Ms. Chen said that historically Trend Micro has seen the addition of 1,000 - 2,000 new virus strains in the wild each year. She also said that the numbers were exploding, and that they saw 5.5 million new unique virus samples in the wild in 2007. It's been clear for some time that blacklisting the "bad" apps was a losing battle. These new figures (new to me at least) really underscore that point. There are more illegitimate apps than legitimate apps.

Whitelisting, as Mr. Murphy describes it, allows you to define a set of applications or vendors and to mark them as trusted. Only specifically trusted apps, or apps from specific companies, can execute. Any app that is not on this white list is not able to run.

That technique will help in some cases to be sure, but what about the times when those apps themselves are tricked into performing malicious tasks for the attacker? The "trusted" app is running, but you've still been p0wned. Is there a cure for that problem?

Systems like SELinux attempt to solve this problem by not just whitelisting apps, but application behavior. (And it's built into Fedora and RHEL, naturally.)

Dan Walsh has some thought on how SELinux might be applied to something like Google's Chrome browser. He also includes some links to other posts on this same topic.

In one of those posts, Joshua Brindle writes:
Even if I have some sort of browser or plugin exploit going on it won’t matter, only data can be sent to the appropriate place (this is the beauty of mandatory access control, even a broken application can’t do anything bad).

This is a really important point: even "trusted" apps can be made to go bad, and you still need to find a way to be safe.  I'll be interested to see how systems like Firefox and Chrome adapt to these kinds of controls over application behavior.


Elinor Mills' CNET's post titled Google making SSL changes, other sites quiet is interesting not just because it's about session cookies at some sites being vulnerable to MITM attacks, but also because it brings up a topic I've been talking about for years: Using SSL for all connections, not just for login. (See here, and here, among others)

She quotes Mike Perry:
"Just about everyone but Google simply does not want to spend the money to invest in the security of their users, and will continue to ignore this issue, just as they have for the past year," Perry wrote in an e-mail.
Mike is being generous. Companies have been ignoring this class of issue for the past decade. In 2008 web sites that deal in money or personal information (like email) need to secure 100% of all connections, 100% of the time. It is not enough to secure just the login pages.

And as for cost? It's not really about buying new machines anymore. (See my posts, linked above) SSL has been more than fast enough for years. It's really just a matter of inertia.
Increasingly the law cannot keep up with specific technologies, and instead relies on phrases like "reasonable security measures". But what does that phrase mean?

Here's an example. The Newfoundland and Labrador Office of the Information and Privacy Commissioner issued a report (P-2008-002) on the theft of some laptops. It has some interesting analysis, such as:
The Commissioner noted that section 36 of the ATIPPA required public bodies to make “reasonable security arrangements against such risks as unauthorized access, collection, use, disclosure or disposal.” ESD failed to provide such reasonable security measures and this led to the unauthorized disclosure of personal information, contrary to section 39 of the ATIPPA.
Paragraph 34 contains this passage on how they worked to define "reasonable":
To determine whether ESD took “reasonable security measures” to protect personal information, I will consider the following factors:
1. The foreseeability of the privacy breach
2. The seriousness of potential harm (discussed above)
3. The cost of preventative measures
4. Relevant standards of practice
And paragraph 62 contains:
As a multi-layered approach to information security is the current industry standard, I am also of the opinion that this approach is necessary for compliance with section 36 of the ATIPPA. At the time of the breach, ESD was not using this approach. Some useful physical safeguards were in place, but administrative and technological safeguards were obviously lacking. While directives and policies alone would not have prevented this breach, they are nonetheless an important feature in safeguarding personal information. In another case, policies and directives may be the difference between a breach occurring or not. In this situation, however, appropriate technological measures may have prevented the breach. Use of network passwords alone to protect personal information does not constitute a “reasonable security measure” as mandated by section 36 of the ATIPPA. This lack of adequate technological safeguards led to unauthorized disclosure of personal information, contrary to section 39
(Emphasis added)

Some more analysis can be found here:
http://www.steptoe.com/publications-5479.html

It also contains some analysis of another incident in the UK. Steptoe writes:
While these specific actions are limited to government agencies, they reinforce the growing trend in the UK -- as well as the United States and around the world -- to regard encryption as a necessary component of data security.
17th-Aug-2008 06:49 pm - Thawte S/MIME cert enrollment broken?
A friend tried to get a Thawte S/MIME cert tonight, and was having trouble.  I decided to get a new cert to walk him through the process.  It turned out to be a change in the Thawte enrollment process, that I hope is a web site bug.

After the Thawte CA issues the cert, it takes you to a page with the "Fetch" button at the bottom.  When you click on that button, Firefox is supposed to import the certificate so you can use it.  Instead, tonight my friend and I got this confusing Save File dialog.



Eh?  SPC files are code signing certs, right?

I tried to alert Thawte, but that also proved to be a challenge.  Their vintage email submission code does not allow exotic symbols like equals, quotes, and parentheses.  Sadly, that means I cannot include actual URLs to their site since many of the good ones include an equals sign.

I really like the Thawte free S/MIME cert program and I hope they get this fixed before you read this entry. ;-)
14th-Aug-2008 10:13 am - Banks still act like phishers
A few years ago I started writing about how financial institutions, organizations that are really security companies at their core, have implemented web site designs that are so broken from a security perspective that they actually act like phishing sites.

Recently some University of Michigan researchers picked up the effort to document the problem in a more formal way. 

From their paper, they describe the flaws they chose to investigate:
1. Break in the chain of trust
2. Presenting secure login options on insecure pages
3. Contact Information/Security Advice on Insecure Pages
4. Inadequate policies for user ids and passwords
5. E-Mailing security sensitive information insecurely
I'm really glad to see more attention on this issue.  Perhaps the automated tools they devised can become well known as industry best practices.

It's hard to believe with all things Sarbanes-Oxley Act auditors make companies do that they don't require banks to have secure web site design. 

My old posts:
http://boblord.livejournal.com/tag/phishing
especially:
http://boblord.livejournal.com/1489.html
http://boblord.livejournal.com/1162.html

SOUPS (Symposium On Usable Privacy and Security)
http://cups.cs.cmu.edu/soups/2008/program.html

Paper:
http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf

Slides:
http://www.eecs.umich.edu/~aprakash/web-user-visible-security.pdf
12th-Aug-2008 07:37 pm - Finding text using Firefox 3
There is a lot to love in Firefox 3. But one of the things I still struggle with is the Find Text feature. It just doesn't work the way I do and I don't think it's gotten much attention in years.

First, the Next and Previous buttons are backwards. See this page for a visual. But let's ignore that for a bit.

Second, Firefox always scrolls long pages such that the search string, if it appears on the page, is positioned at the very bottom on the page. Aren't there some better algorithms than that? It's often the case that the first occurrence of a word is the first of many occurrences, but all the subsequent hits are hidden below the visible window region. At a minimum, FF should scroll so the string is in the middle of the page.

Third, I'd like Firefox to highlight all occurrences of the word. Maybe my usage pattern is very different from most people, but I'd like to see all occurrences highlighted, and the "Highlight all" button removed. Why would you not want to see all the results? Search engines don't return one result and wait for you to say "Next". Further, sometimes the string is hard to see on web sites with strange color choices. I'd like to see someone come up with a way to make them more visible (without blinking, of course).

Fourth, I'd like for the the text I'm searching for to remain highlighted across page transitions. If I'm looking for a term on a page, and then click on a link to another page on that site, I'm frequently looking for the same term on that page also. So I hit "Highlight all" again, click to another page, click "Highlight all", and so on.

The Google toolbar does some of what I want, but it seems to only do it when I've sent the query string to Google. What about pages on my home or work networks?

I spend time each day trying to find the right stuff on a page. I'd like to see some real innovation for Firefox 4!

Is there a plug-in that I should be using?
24th-May-2008 11:36 pm - S/MIME for GMail in Firefox 3
I've been beta testing the latest version of a Firefox add-on that adds S/MIME security to GMail. This version adds some features, including support for the latest builds of Firefox 3.

Here's the link to get it:
https://addons.mozilla.org/en-US/firefox/addon/592

Now I can send signed and encrypted email to people using Outlook, Thunderbird, and Apple Mail while using the native GMail web interface.

If you use S/MIME, Firefox 3, and GMail, you can finally use them together. My hats are off to the developers!
I started to use the Lightning plug-in today. (Lightning integrates a calendar into my Thunderbird mail client).  Despite the low version number (0.7), it works as expected. I subscribed to a number of public "shared" calendars and to my company's corporate calendar server. So now I can see my personal, work, and other public calendars in one place. I'm very impressed so far.

I wish I had done this before!
8th-Nov-2007 09:45 am - Gone Phishing
Silicon.com reports that a Salesforce employee was phished, which led to some of their customers being phished

Once the phishers had the contact list, they attempted to phish Salesforce.com customers. Harris wrote: "Unfortunately, a very small number of our customers who were contacted had end users that revealed their passwords to the phisher."

I don't think I've seen documentation of this sort of cascading phishing attack before.
12th-Oct-2007 10:37 am - SSL errors ain't what they used to be
Background
We've been making some changes to improve the security of SSL sessions. You'll start to see these changes starting in upcoming builds of Firefox 3. These changes will fall into two categories:
  1. UI improvements that include support for Extended Validation (EV) certificates
  2. UI to handle SSL errors
The first change is outside the scope of this blog entry (though they are important). If you want to get more information on those topics, you might start by reading Johnathan Nightingale's blog entries here.

This post describes the changes we're making to the error messages Firefox displays when you encounter an SSL problem. The most common problems we see are:
  1. Expired certificate: The certificate that the SSL server sent to Firefox was expired. Certificates that have expired are not valid in much the same way that credit cards are not valid once they have expired.
  2. Self-signed certificate: The certificate's issuer is itself. This type of certificate is most common in test servers, and on intranets. Banks, online stores, and other reputable businesses would never use a self-signed certificate.
  3. Incomplete certificate chain: The SSL certificate chains to a CA (intermediate or root) that Firefox either does not have, or does not trust. In either case, Firefox cannot connect the dots to be sure that the site is who it claims to be.
  4. Domain mismatch: The web address you are visiting says one thing, but the certificate was issued to a different address. A common scenario exhibiting this problem occurs when you visit http://example.com but the certificate was issued to www.example.com.
In previous versions of Firefox, we presented a dialog box that described the error and allowed users to continue anyway. The problem with this approach is that in general users don't know what the implications of such a decision are. We've seen many instances where people breeze by those warnings without a second thought. Software shouldn't ask users questions they cannot answer.

You can read more about the change to SSL errors on Johnathan's blog entry here.

Overriding errors: Exceptions
While in most cases the error page warns of a misconfigured server (or possibly an attack), there are some special circumstances when knowledgeable users will need to override these errors. For example, web site administrators might have an internal test or staging server. That server might use SSL, but with a self-signed certificate that Firefox would not be able to validate. In such cases, there is a way for knowledgeable users to override the error.

To override the error, you need to create an exception. The SSL exception dialog is located in the Preferences window, under Advanced/Encryption/View Certificates. Once there, click on the Servers tab, and then on "Add Exception...". The UI should be straightforward from there. You can add as many exceptions as you need for your testing purposes.

Sharing exceptions
There are also cases where administrators might wish to share their overrides between themselves. One admin might go through each of the internal sites that uses self-signed certificates. He can then share his override settings with other administrators. If you fall into one of these special cases, here is some information on how you can share override information.

The override definitions are stored in your Firefox 3 profile directory in a file called cert_override.txt. You can share the lines in that file that pertain to the web site in question.

For those of you who want to know more about the format of that file, here is the breakdown:
  1. hostname:portnumber (primary key). The override is bound to this combination of hostname and port number.
  2. OID of hash algorithm used to generate a certificate fingerprint. This is currently set to OID.2.16.840.1.101.3.4.2.1 which means SHA-256 and may change in the future.
  3. Certificate Fingerprint using the algorithm from the previous field
  4. One or more characters that define the time of override: M, U, and/or T:
    1. M : allow mismatches in the hostname
    2. U : allow untrusted certs (whether it's self signed cert or a missing or invalid issuer cert)
    3. T : allow errors in the validity time, like expired or not yet valid certs
  5. A special encoding of the allowed cert's serial number and the issuer name as a base64 encoded string (the database key obtained from NSS)
Note: when you update your cert_override.txt file, the browser must be shut down. Otherwise the file will be overwritten, destroying your changes.
This page was loaded Jul 11th 2014, 3:47 am GMT.