I took some time today and wrote up a script that can be run to eliminate autocomplete=off in Firefox. It basically does the same thing as is described here, but it automates it.

The script can be run with one of five arguments:

• You can choose to use find (--find) or locate (--locate) to find the files that need to be changed on your system;
• You can dictate the location of the file if you want to modify a specific one or know exactly where it's located (--dictate);
• You can choose to use the Ubuntu default location (--default); or
• You can print the help information (--help)

Once the program is run, it will make a back up, and modify it the original versions of the file. Once that's complete, all you have to do is restart Firefox.

It has been pointed out to me by some security folks that removing autocomplete's functionality from the browser might not be the best thing, since it will allow you to save your passwords in the browser. There's some truth to that: Anything that's on your computer can be hacked. So, if you're going to use this script, use it wisely.

Here's the code. I've attached it to this message as well. Any bugs or comments are greatly appreciated.

#!/bin/bash
# a simple script to destroy autocomplete in linux installations. 
 
 
##############
# We begin with our functions, it's not efficient, but it works
##############
 
# a function to print the help message.
function printHelp {
cat <<EOF
NAME
    autocompleteDestroyer.sh
 
SYNOPSIS
    autocompleteDestroyer.sh [ --find | --default | --help | --locate | --dictate ] 
 
OPTIONS
    This program will find the nsLoginManager.js file on your computer, and will fix it so that autocomplete is disabled in your installation of Firefox. Since this program will be altering your installation of Firefox, it will require your root password. 
 
    --help     Print this help file
 
    --default  Attempt to use the default location of the files (/usr/lib/xulrunner*/components/nsLoginManager.js)
 
    --locate   Use the locate database, if installed, to find the files. This will only find the files that were added before the last time the locate database was updated (which is typically once a day). It is faster than the --find option, but might not find all versions.
 
    --find     Use the find command to locate the nsLoginManager.js files. This will search in /usr/lib by default. Edit the script if you would like to change this. This is the slowest, but most thorough option.
 
    --dictate  Allows input of a known location.
 
EXIT STATUS
    autocompleteDestroyer.sh exists with a status of 0 if it encounters no problems. An exit status of 1 means incorrect usage. An exit status of 2 indicates it was unable to find your files. An exit status of 3 indicates the user terminated the program. An exit status of 4 means it encountered problems editing your file.
 
BUGS
    If any bugs are encountered, please see michaeljaylissner.com/contact
 
AUTHOR AND COPYRIGHT
    This script was authored by Michael Lissner and is released under GNU GPLv3.
 
EOF
}
 
# takes an argument, and creates an array containing the files to be modified.
function identifyEvilFiles {
    if [ $1 == "find" ]
    then
        files=$(find /usr/lib -name nsLoginManager.js 2> /dev/null)
        if [[ ! $files ]]
        then
            # Test if files has been set.
            echo "autocompleteDestroyer.sh: No files found. Try loosening the find parameter in the script, per the help file."
            exit 2
        fi
    elif [ $1 == "default" ]
    then
        # We assume the default location of nsLoginManager.js
        files=$(ls /usr/lib/xulrunner*/components/nsLoginManager.js 2> /dev/null)
        if [[ ! $files ]]
        then
            # We didn't have any hits. Exit.
            echo "autocompleteDestroyer.sh: We didn't find anything at the default locations. Perhaps try the --locate or --find arguments."
            exit 2
        fi
    elif [ $1 == "locate" ]
    then
        # We run the locate command, see if we have any hits.
        files=$(locate -b '\nsLoginManager.js' 2> /dev/null)
        if [[ ! $files ]]
        then
            # No hits. Exit.
            echo "autocompleteDestroyer.sh: We didn't find anything using the locate command. Perhaps try the --find argument."
            exit 2
        fi
    elif [ $1 == "dictate" ]
    then
        # "Why don't you just tell me what movie you'd like to see?" --Kramer.
        read -p "Where is the file nsLoginManager.js located on your machine: " files
        if [ -f $files ]
        then
            # Good. The file exists. We press on.
            echo "Thank you. That file exists, and we will modify it."
        else
            echo "autocomplete.sh: That file doesn't seem to exist. Please try again."
            exit 2
        fi
     fi
}
 
 
 
function modifyFiles {
    echo  "The following files will be modified: 
$files "
    echo 
    read -p "Shall we proceed (y/n): " proceed
 
    if [ $proceed == "y" -o $proceed == "Y" ]
    then
        # Here we go!
        while read -r line
        do
            echo Now processing $line
            #find the function in the file, label it with FILLERWORD, then replace the first line, and delete the rest. A messy approach, but functional
            sed -i.bak '/[[:space:]]*_isAutocompleteDisabled[[:space:]]*:[[:space:]]*function.*{[[:space:]]*$/,/^[[:space:]]*},[[:space:]]*$/s/^/FILLERWORD/' $line
            sed -r -i 's/FILLERWORD.*_isAutocomplete.*/    _isAutocompleteDisabled :  function (element) { return false; },/' $line
            sed -i '/FILLERWORD/d' $line
 
            # test if it worked
            grep -i -q 'isautocompletedisabled.*return false' $line
            if [ $? != 0 ]
            then
                # something failed...probably. Tell the user
                echo "Unable to successfully edit the file. Exiting"
                exit 4
            fi
        done <<< "$files"
        echo "All the files have been processed properly. Please restart Firefox, and thanks for using this script."
        exit 0
    else
        # It appears they'd like to abort. Let's exit.
        echo "OK. You know what to do if you change your mind."
        exit 3
    fi
 
}
 
 
#initiation sequence
if [ $# -eq 0 -o $# -gt 1 ]
then 
    # We need to give them help using the program. 
    echo "autocompleteDestroyer.sh:  Invalid number of arguments."
    echo "Usage: autocompleteDestroyer.sh [ --help | --default | --locate | --find | --dictate ] "
    exit 1
elif [[ $EUID -ne 0 ]]; 
then
    echo "autoCompleteDestroyer.sh: This script must be run as root" 1>&2
    exit 1
else
    case $1 in
        --help) printHelp;;
        --find) identifyEvilFiles find; modifyFiles;;
        --default) identifyEvilFiles default; modifyFiles;;
        --locate) identifyEvilFiles locate; modifyFiles;;
        --dictate)identifyEvilFiles dictate; modifyFiles;;
        *) echo "autocompleteDestroyer.sh: Invalid argument. Try the --help argument."
           exit 1;
    esac
fi

Two more security papers today.

In the first, Breaking ReCAPTCHA I discuss a few methods that ReCAPTCHAs can be hacked, and talk a bit about the ways that they were attacked by the Anonymous hacker group. I should mention at the outset that none of the approaches here are particularly useful though, and that ultimately, the hacker group beat ReCAPTCHA by simply out numbering it.

The second paper is a brief discussion of some approaches an organization might take when beginning a project in which security is a high concern. Essentially, it takes a chronological approach, from the start to the end of the project.

Enjoy.

For my Privacy, Security and Cryptography class, we studied a set of 13 principles for secure systems:

1. Security is Economics
2. Least Privilege
3. Use Fail-Safe Defaults
4. Separation of Responsibility
5. Defense in Depth
6. Psychological Acceptability
7. Usability
8. Ensure Complete Mediation
9. Least Common Mechanism
10. Detect if You Cannot Prevent
11. Orthogonal Security
12. Don’t Rely on Security Through Obscurity
13. Design Security in, From the Start

For our midterm, we were asked to analyze how Facebook exemplifies or does not follow these principles. It was an interesting assignment, which finally forced me to think more thoroughly about Facebook's security policies, and I'm happy to attach my findings here.

For some people these may be rather run of the mill notes. For others, you may be surprised at poor security of the world's biggest photo and social networking site.

Enjoy.

A few months ago, Twitter was hacked by means of a clever, yet somewhat obvious approach. Today, I saw the following alert on my Gmail account, ensuring that this security vulnerability is fixed. I'm often impressed by Gmail, but this is great to see:

Hey, this is important: If you ever lose access to your account, you can send password reset info to [myemailaddress@michaeljaylissner.com]. This address is correct | Update this address

What happened in the case of Twitter was that a hacker did the following:

• Figured out the Gmail address of a Twitter employee
• Went to Gmail's password reminder, and requested a reminder
• This informed him that an email reminder was sent to a specific Hotmail address
• That Hotmail address had been automatically closed due to disuse
• He set up that email account, since it was now available
• He then requested another password reminder, which summarily sent an email to his new Hotmail account
• This gave him complete access to the Twitter employee's gmail account (and thus a lot of other stuff)

The new alert that Gmail is now popping up should serve the function of updating this, and, if done correctly, should fix this problem permanently. Well done Gmail.

Prior to becoming a student at the School of Information, I worked doing systems support for a government database that held hundreds of thousands of records, consisting of social security numbers, addresses, names, DOBs, etc. My job was to help users with any kinds of bugs they found in the system, and to work with the vendor to report and resolve those bugs. Over the years at this job, I spent a good amount of time doing security testing of the system. I found a number of vulnerabilities which I reported to the vendor, and which were quickly fixed. One of them however had been plaguing me from the time I found it, around 2007, until now. This post is the tale of that vulnerability, which I'm proud to say was fixed earlier this week.

The problem that I discovered is a simple one, and is one that is widespread on the web. Simply put, the web-based system did not use encryption on the log on page, resulting in user names and passwords being sent over the Internet in plain text rather than ciphertext.

Now, without going into too much detail, this is not necessarily the end of the world. When you use the Internet, the information that transfers between you and websites is split up into packets, and these packets are sent down whatever wire appears to have the least load and the greatest speed. As a result, there is no guarantee all of your information will ever be sent through the same computer, and it's challenging for a hacker to place a computer between you and the website you're using.

Unfortunately though, there are some bottlenecks, and sometimes — not always — all of your information will pass through the same point between you and the server. Bottlenecks can occur in a number of places, such as:

• The web host's computers and wires — Unless a custom DNS server is being used, all the information going to or from the server has to go through some host's computer system. If they are logging the information, and if the login information is sent in plaintext, they will immediately have it.
• The fastest route — Somewhere between you and the server, there may be one route that is fastest. It's possible that some computer in the middle will in fact be relaying all of the information to and from you and the server. They will, in effect, have all of the needed information to steal your login credentials.
• Your network — If you're on a home or corporate network, more than likely, there is one or more bottlenecks between you and the Internet. This is a point where your information could be gathered.
• The network provider's computers — Finally, your information will be passing through the hands of the network providers, so they have a wide scope of opportunities to inspect and analyze your information.

Thus, you might say that it's OK to have an unencrypted login page, if you don't mind having vulnerabilities at both endpoints and all along the middle of the connection.

But I digress and should proceed with the tale. Around 2007, I found this vulnerability and used Wireshark to demonstrate it to my managers and to the vendor. At that time, it seemed like it would be quickly fixed, and that we could go on with our lives.

Then some time passed, and nothing happened. I reminded a few people, but still nothing. The problem persisted, and I handed off my job to somebody else so that I could go back to school. But even once I was back in school, occasionally something would remind me of the problem, and I'd check to see if it was fixed. But it wasn't. So I reminded my old co-workers that they had a problem (which wasn't my favorite thing to do), and I assumed it would be taken care of. Except it still wasn't.

At this point, I had to decide how much of a moral duty I had to get this fixed, since I was unaffiliated with the organization for about a year by that time. Proceeding to bring up this issue meant that I would probably annoy a number of people, and that I would likely damage relationships I had spent years building, but to not bring it up meant that thousands of people's records would continue to be insecure.

With this balance in mind, I decided to contact the vendor about it some more, and to continue contacting him every so often until it was fixed. Ultimately, after an additional three or four months and about five long phone calls it's finally fixed.

The questions now are, what took so damned long, and what can be done to avoid this in the future? Well, a number of things factored in:

1. Staff transitions — Part-way through this time, I left my job and transitioned to school. While I did mention this problem to my replacement, I also mentioned about 500 other things. Sadly, this one may not have caught his attention, or I did not emphasize it enough.
2. Lack of security personnel — Nowhere in either organizations was there a person that was designated to discover and push security problems.
3. Vagueness of the problem — I was able to demonstrate the problem to my superiors and to the vendor, and to explain how it could be a problem, but it wasn't a smoking gun. There had been no security failure, nor was there any obvious thing that an average user could exploit.
4. Competing projects — At the time I discovered the problem, there were many other competing projects that were on the table. To push them aside to fix a vague and unexploited problem did not seem like a good use of resources.
5. Relationship maintenance and imbalances — In 2007, when I reported this, I was not a part of the senior management, and did not have a strong relationship with the vendor. Conversely, my bosses did have a relationship with the vendor, but they might not have wanted to jeopardize it by pressuring the vendor to fix a security problem.
6. Vague economic incentives — With this vulnerability, it was unclear if anybody would ever know if a hacker had been logging into the system and collecting information. If one had, it's vague where the burden of the problem would fall. It's not certain whether it would fall on my organization or the vendor. And anyway, because HIPAA is so massive, and because there are many other laws that come into play (such as the data breach laws of CA), it's unclear what exactly they would have to to as a result.

Some things did not factor in that one might expect to be relevant:

• Everybody wanted to fix it. Nobody thought it shouldn't be fixed or that it shouldn't be prioritized.
• Nobody dropped the ball and didn't get it done.
• There were no structural impediments to getting it reported to the proper people.
• It wasn't a complicated or difficult thing to fix.
• It wasn't a trivial problem, nor one that was difficult to exploit.

In sum therefore, it appears that it was economic, social and personnel challenges that caused this to take so long to be fixed. So what can we do to fix these types of problems? A number of things come to mind:

1. Full-time security personnel — The most important thing for one of the organizations to do is to hire somebody to complete regular security audits. This person needs to be hired full time so that they understand the complexity of the problems, and so they can be there to push the solutions forward until things are fixed.
2. Clarity of economic burden — With so much information being stored in the system, it should be made explicit to both parties what the plan is in case of a data loss, and where the burden lies in that event.
3. Shared bug reporting — Currently, there are about fifteen organizations that use this vendor for their information management, however there is no shared system of bug tracking or reporting. As a result, when security problems are found, organizations have no organized way to share information with each other. Because each organization has a relationship to maintain with the vendor, none of them want to make the product look bad or vulnerable. This isolates the information, reducing the pressure on the vendor to fix such problems.
4. Prioritization of security fixes — Finally, it's vital that such problems be prioritized so that they do not fall by the wayside, and so that they can all be fixed before they are exploited.

Laptops get stolen. It sucks, but we know it happens from time to time. Recently, I've been checking out programs that can help to catch the thieves (and dabbling in writing my own).

One program that I found, called Prey, helps to do just this. Once installed, every few minutes it will check a website to see if a page exists. If that page exists, it will collect a bunch of information about the computer, and send that (using SMTP of your choice) to an email address of your choice.

So, for example, if I set up a web page at http://michaeljaylissner.com/laptop-stolen, in a few minutes, Prey will see that page, and will collect the following information:

• The IP address where my computer is connected (this is almost as good as the thief's physical address)
• The name of the wireless network my computer is connected to, and a list of the others in the area
• The MAC address of the wireless router my computer is connected to
• How long my computer has been on (uptime)
• Any files that have been modified in the last X minutes
• Any programs that are currently running
• Any open connections to websites or online services
• A picture of the thief, if you have a webcam enabled
• And best of all, a screenshot at the time of the report

Once I get the email with all this information, it's just a matter of taking it to the police, and convincing them to take action on it.

Of course, all of this could be useless if the thief decides to immediately wipe the data on the computer, but it's a good safeguard that can weed out the dumb thieves at least.

EDIT: Forgot to mention the webcam on the first version.

I've mentioned secret questions on my site before, but I never quite realized how much of a problem they are until today, when I discovered uspublicrecords.com.

It's a simple site. You put in a name, and if it has that person in its database, it gives you their age, middle name, and family members. So far, I haven't found any names it doesn't have.

Using this information, I went and checked a friend's gmail secret question, which was, "What is your father's middle name?" I just happened to have that information from uspublicrecords.com, so I put it in, and changed their email password.*

It's pretty creepy how easy this is, and fixing this problem could take days as you check all your secret questions one by one. This might make a good mashup: a system for checking all your secret questions.

Anyway, now might be a good time to go change your secret questions, cause if it has anything to do with middle names, that site will hand them right out.

* With their OK, of course.

We all agree that security is necessary for our data, but we all fall down when it comes to implementation. An example that I keep returning to is the need for encryption. I posted a few days ago about how Yahoo! doesn't encrypt their email, allowing a sophisticated hacker to intercept any message to or from your account.

Today, I encountered my password in plain text in a configuration file that is easily accessible to anybody that gains physical access to my computer. The guilty program is the Pidgin IM client (bug filed here), which stores login and password information in an XML file in your home directory. I've seen files of this sort a number of times, and for some reason programmers keep using this technique.

Most people believe that if they have confidential information in their computers, and if they use a password on their computer, they'll be OK. Nobody will be able to get past the password. While that isn't entirely true (most passwords are easily broken), the thing to remember is that once a hard drive is removed from a computer, any of the data on it can be accessed — without the password. So, so long as programmers keep using this technique, sensitive data will still be out there.

The easiest solution to this problem is to encrypt your entire hard disk at all times. That way, even if your hard disk is removed from your computer, all the data is jumbled anyway. Ubuntu released this feature back in April, and Microsoft released this feature with the release of Vista. Unfortunately though, to receive encryption on your Vista installation, you have to buy Vista Ultimate, which costs $120 more than the Home version (at a cool $320!).

As we trust more and more data on our computers, is this irresponsible product engineering? Absolutely. It costs Microsoft no more money to put encryption on all versions. Unfortunately though, they make more money by charging for it.

I had the occasion to go through airport security over the weekend, and I realized an interesting thing. If you want to get through security with a large knife, all you have to do is try to slip one through in your bag a few times over the course of a few days or weeks.

Each time you fail, you act like an idiot ("oops!"), and give them the knife, proceeding without it to your airplane. Eventually, the guy watching the x-ray screen will miss the knife, you will proceed, and you will finally be able to cut your airplane steak.

I learned this lesson by accident when I nearly missed my plane. I had planned on checking my small bag with the knife in it, but when I arrived at the airport late (my fault), I could either miss my plane, or try to sneak the knife through.

Since I didn't want to miss my flight, I tried and succeeded to get the pictured knife through. Pretty amazing that a three inch blade can pass right by, eh?

I wonder if terrorists are patient...

Well, there is an interesting development in the theft of my credit card number. Today I received supplements in the mail for my prostate. Supplements that were bought with my credit card. For those wondering, no, I do not need this medicine. No, I did not order this medicine.

I'm intrigued and a bit amused that this is what my identity thief decided to do with my money, but I'm going to have to decline their offer of prostate supplements. This purchase raises so many questions, I don't know exactly where to begin.