October 28, 2004 is a day I’ll remember for the rest of my life.

I was coding away on the next version of a small product called GSuite that I was building for a tiny (and now nonexistent) software company called Imspire Software. It was a simple tool that provided some goodies for Gmail users, and had a few thousand users (it eventually died as a result of rapid API changes and new tools directly from Google). As I took a break to check my email, I saw something that shocked me:

[The full email is still posted over at osvdb, and I make a point to go and look at it and the details once a year or so - just to remind myself of what can happen.]

As I worked through the somewhat iffy English of the email I was in shock. I instantly understood the issue, I could see the code in my mind. It was written by another developer, and I could remember questioning its security - but I had other things I was supposed to be doing and didn’t worry about it. What a mistake that was.

I went back to Visual Studio and found the code that caused it all:

Shifting values is obfuscation and little more, it looks like security - it might even smell like security, but it isn’t. It’s a false sense of safety, it was a mistake to implement and even more of a mistake to actually use in a consumer product.

While this is only a local information disclosure, and not something far more serious like a remote arbitrary code execution issue - it was still enough to really shake me. I had always considered myself to be a good developer, and part of that is writing secure code. This was many things - but secure isn’t one of them.

Thankfully, Lostmon, the finder of the issue was courteous enough to give me a couple of days advance notice before making it public. Allowing me plenty of time to get a notice up on the web site, and get the next (fixed) version ready for release. I switched from a glorified Caesar cipher, to Rijndael - a significant step up I would say.

Was anybody harmed by this issue? I don’t believe so - it was a relativity minor issue given what was needed to get the password. Was anybody impacted? Most certainly.

• Users: They now wonder if they are secure - did somebody steal their information?

• Company: The brand is weakened, less trusted, and questioned more.

• Developers: Confidence is lost, self doubts start creeping in.

Because of this, every time I release an application I give much more thought to what I’m exposing and how it could be leveraged in an attack against my users. The only way I’ll agree to an application release is if I’m completely certain that I’m not risking a user’s security - if there are any unknowns, any doubts, then it’s not worth the risk. Just that simple.

I’ve released a new version of CCSRCH, the open-source PAN (a.k.a credit card number) search tool to help companies maintain PCI compliance. This is a fairly minor release, primarily focusing on reducing false positives. The scanner has been updated to exclude the following:

• Results made up of the same two digits repeating (i.e. 5454545454545454).

• Results that have seven or more of the same digits repeating (i.e. 5555555555554444).

I also fixed a bug that I introduced in v1.0.6 that prevented it from compiling on certain *nix systems; while I was in there I also fixed several instances of this building warning on newer Linux distros:

warning: call to __builtin___strncat_chk might overflow destination buffer
 [enabled by default]

I also took the time to write-up really simple build instructions for *nix users:

$ wget -O ccsrch.tar.gz https://github.com/adamcaudill/ccsrch/tarball/master
$ tar -xvzf ccsrch.tar.gz
$ cd adamcaudill-ccsrch-<rev>/
$ make all

This will probably be the last release for now unless a bug turns up; to improve results further I’m working on a new project (ccsrch-score), hopefully it’ll be released soon.

An Issuer Identification Number (IIN, more commonly called a BIN) is the first 6 digits of a credit or debit card, and it identifies the bank that issued it - and if you want to know if a number is a real credit card or just a bunch or random digits, it’s a huge help. While credit card numbers do use the Luhn algorithm (mod 10 check) to see if the number is valid, it still produces a huge false-positive rate.

For an application like ccsrch, having this data available would be very handy to reduce false positives when scanning a large file system (scanning a large server produces a huge number of possible hits), but for what I would call fairly misguided reasons, the official registrar of these numbers (the ABA) doesn’t make this data publicly available. As a result many people have pulled together what data they could find and made it freely available.

So I’ll add my name to that list.

I’ve pulled data from many public sources (sorry, I didn’t keep very good notes as to the sources) and cleaned it up to a reasonable point. All told, I’ve probably spent 40 hours or more cleaning this data up and getting it to a usable state. It contains over 60,000 entries, including major credit cards (Visa, MasterCard, Amex, Discover) as well as a few merchant entries.

Each record contains the following:

• IIN

• Type (Mastercard, Visa, Visa Credit, etc.)

• Name (Issuer name)

• Length

Data Quality

It’s not perfect. It’s from public sources so there may be errors, and there are some duplicates from cases where I wasn’t able to determine who the IIN actually belongs to. I’ve also updated for name changes and mergers where possible, but I’m sure I’ve missed a few and there are some where the assets where split, so I don’t know who the correct owner actually is (Washing Mutual being the leading example of this).

In general, I leaned to the side of caution - so if I didn’t know for sure, I left the duplicate in.

If you need absolutely correct data - contact the ABA, they are the only source that can give you the completely accurate listing. If you need to have a decent idea if a number is valid for most cases - I would say that this data is good enough.

Warranty

Just to make it really, really, really clear: There is no guarantee that this data is accurate, that it won’t cause to lose your job, cause your house to burn down, or cause Rebecca Black’s Friday to get stuck in your head (yup, you’re welcome ;)).

Copyright

Based on my understanding of US copyright law, it is my understanding that this data is not subject to copyright as it is a compilation of facts and doesn’t constitute an original expression. Thus, to the best of my knowledge, this data is in the public domain.

Download

Here (zipped CSV)

While checking on the latest updates in the start-up world from TechCrunch, I came across their article on Mykonos; the important part of their article (at least for me), is this:

Mykonos’s Web Security product uses deception to “detect, confuse, slow down and prevent attackers” in real-time in order to help companies protect their websites and Web apps from malicious hacker and proactively prevent fraud and theft.

A couple of minutes of reading, and my interest was piqued - to say the least. The thing that most interested me was the claim of no false positives, while they do talk about it - I really wanted to see it for myself. Assuming they used their own product to protect their site, I took a few minutes to see what I could find - and find I did.

The first thing I did was a view-source to see what I could learn about their site - mainly to see if there were any obvious signs of using one CMS or another. The first thing that jumps out at me is this from the HTML:

<!-- InstanceBegin template="/Templates/mykonos.dwt.php"
     codeOutsideHTMLIsLocked="false" -->

So, this tells us they are using Dreamweaver, and the name of the template. So, the next question is, does that /Templates/ directory exist on the server?

Yup.

So, not only does it exist, they have directory listings turned on - which to me was a real shock. Unfortunately for us though, these files are named with the .php extension and not the .dwt I was hoping for, so we can’t get much useful from them.

So, from looking at the source of the home page, we can see that the css files are stored in a /css/ directory - maybe that’ll be interesting.

It’s there, and like last time, we can see all of the files. While CSS files are of no real interest, the /_notes/ directory is, because it’ll contain a file called dwsync.xml - which can be quite interesting (since we knew they are using Dreamweaver, it’s not too surprising to see this). This file contains data about the last time the site was pushed from Dreamweaver, and will contain one entry per file, and looks like this:

<file name="style.css"
 server="ftp.belincreative.com/public_html/clients/mykonos/site/"
 local="129651858311162109"
 remote="129651936600000000"/>

The most interesting thing there is the server entry, as it tells us a little about the file-system; which if we were really trying to attack the site, knowing that would be handy. The other thing of interest is that when you see one /_notes/ directory, you’ll see lots more, as Dreamweaver likes to put them everywhere.

So, let’s see if there’s one in the root - that should be the most interesting one. Sure enough: /_notes/

This one has a few interesting entries, such as a PHP file that is named with an HTML extension - causing the code not to execute. Viewing the source of that file in the browser exposes the /inc/ directory; potentially interesting, but yields little information. The next file I tried (knowing it would be way too easy if it worked), was the .htaccess file:

<files "webadmin.pl">
    AuthUserFile /usr/local/www/public_html/.htpasswd
    AuthType Basic
    AuthName "Server Administration"
    require valid-user
</files>

Now, at first glance things look too good to be true - and that’s because they are. Look at the path in AuthUserFile and compare that to the entries from the dwsync.xml files. This .htaccess file is part of the trap, which is all but confirmed if you try to go to the .htpasswd file which shouldn’t work, since the path isn’t what we would expect.

Now, while mucking around looking at the aforementioned files, and others such as robots.txt, I would periodically see this, which I would assume is part of that “no false positive” promise:

I was hoping to run into the firewall (for lack of a better term) - looks like I got my wish; though since I wasn’t using anything automated and was just poking around by hand, it didn’t have any impact. Not terribly exciting, but it did provide some insight into what they are doing.

So far we’ve found a few interesting things, and bumped into their firewall, but that all pales in comparison to the last entry in the dwsync.xml file:

<file name="local-site.zip"
 server="ftp.belincreative.com/public_html/clients/mykonos/site/"
 local="129695851046591796"
 remote="129695888400000000"/>

When I saw the file name I was shocked - could it really be? But I was right. It’s a 59MB file containing everything on the site - all the PHP and everything else. Out of curiosity, I compared the .htaccess to that in the zip file, as expected it’s quite different and more believable:

Options +FollowSymlinks
RewriteEngine on
rewritecond %{http_host} ^mykonossoftware.com [nc]
rewriterule ^(.*)$ http://www.mykonossoftware.com/$1 [r=301,nc]

That confirms what I suspected, the file I saw earlier was just part of the trap.

So what have we learned?

1). Mykonos makes a really cool product, and had I not known what I was up against (and thus less skeptical about everything) it probably would have killed a lot of my time - just as intended.

2). No matter what you put in front or your site or application, human mistakes are still your greatest risk. A second set of eyes and a little paranoia go a long way in securing your systems, and stopping hackers.

3). Mykonos was either lucky or smart in that there was little on their site that shouldn’t be seen by the public. If they were using a CMS with a database back-end instead of simple (mostly-)static pages, this could have been worse. If they had source code or other valuable IP on the server, a mistake like this could be devastating.

4). Mykonos should take some of their new-found cash and hire somebody to finish the audit of their site that I started. ;)

Note: I notified Mykonos about that zip file before posting this (through a couple of channels), and I’m intentionally not linking to it. While I didn’t see anything in there that would be an issue to be publicly disclosed, I’m sure they don’t want it getting out. Hopefully by the time anybody reads this, they will have taken care of that file.

Update: As expect, they’ve cleaned up the files I mentioned - and a bit more. In a tweet from the company’s CEO, David Koretz, he mentioned that they had left a surprise for me. So I went to my starting point (the /Templates/ directory), and was greeted with this:

Yeah, cool product and cool people. I’m impressed.

While testing ccsrch I noticed a number that looked familiar - my debit card number. Now, being just a little paranoid, I don’t leave such information on my system unencrypted - so seeing it was a real surprise. But, here’s the real kicker: it was on my work PC, where it never should have been. But there it was, plain as day, in clear text. I spent a couple of minutes staring at the log trying to figure out why it would be there.

Once I saw the file name, a sinking feeling set in and the answer became clear:

%LocalAppData%\Google\Chrome\User Data\Default\Sync Data\SyncData.sqlite3

So it turns out that it’s Chrome’s sync feature that was saving my information, but why?

It turns out that auto-fill data is synced with your Google account (if you’re signed in and have the feature enable, of course), and all of the computers you’re signed into - and by default, without the benefit of encryption. This file may contain any number of things, from mine I was able to extract the following:

• Full name

• Wife’s full name

• Date of birth

• Wife’s date of birth

• Social Security Number

• Multiple credit card numbers

• Multiple CVVs

• Bank account & routing number

Not to mention quite a few websites I’ve been to, various addresses, employer’s name and other various useful tidbits. All would be quite useful for identity theft or highly targeted spear phishing.

Now am I saying that syncing auto-fill is bad? No, not at all. It’s a very useful time saver, but what takes it from a useful feature to security issue is the fact that by default, this data isn’t encrypted!

What are the risks?

There are three significant risks I see here:

1). Disclosure to less trusted systems:

In my case, I trust my laptop to be secure; between full-disk encryption (via TrueCrypt) and other precautions, I know that I don’t have too much to worry about. On the other hard, my Work PC is on a corporate domain, and at least a couple dozen people have permissions sufficient to access my personal files - thus I don’t trust anything too valuable on it.

Now because of the fact that this feature is insecure by default, that data is exposed to a less trusted system.

It can also go the other way: a number of auto-fill entries on my personal laptop were from forms on internal-only applications that only my Work PC would be able to access. So this means that anything sensitive could be leaked to home networks which are typically less secure than corporate environments. If you routinely handle PCI, HIPAA, or other restricted information - this type of leak could be a major issue.

2). Spear Phishing:

Let’s imagine a scenario:

You work for a defense contractor and I work for a foreign intelligence agency. Through some targeted attacks I manage to penetrate your home network, but have been unable to make it into your corporate network. I grab the sync database file from your home PC and extract one of your credit card numbers. I look up the IIN and find out what bank the card is from. Once I have this, I build a PDF with the latest 0day exploit, and send it with a convincing subject line:

“Important Information about your Bank of America credit card ending in 7850”

Normally you’d dismiss it as spam, but the last four digits are right - so you open it, just in case. The exploit kicks in. I’m in, you’re done.

This is just a simple and quite contrived example, but you get the idea.

3). Google Data Mining:

This is the most paranoid and least likely, but given Google’s issues in controlling their people - I’d say not impossible (see here, here, and here).

Just for a moment, think about the fact that Google has the following:

• Your account data (name, email, etc.)

• Your auto-fill history (see the list of items I found above)

• Tons of data from their other services

• At least parts of your browsing history, if not much of it

• Engineers that truly enjoy data mining

Most other companies I wouldn’t worry about; but knowing the people that Google hires, and the skill they have in manipulating data - you know that some engineer is using his 20% time to do this (or at least is wishing he could).

If nothing else, I know if I worked at Google - playing with this data would be tons of fun. ;)

Want to see your data?

To see what Chrome has saved about you, download SQLite Browser, and open the file I mentioned above. Go to the “Browse Data” tab, and select the “metas” table. What you’re looking for is in the “non_unique_name” column (among other places). You should see something like this:

The entries starting with “autofill_entry” are the ones you are interested in, but you’ll likely find some of the other records interesting as well. If you see the word “encrypted” then your data is already encrypted, and you don’t have to worry about this.

Is this a vulnerability in Chrome?

No, not at all - though it was a mistake. They should encrypt everything by default, and not provide an option to do otherwise. There’s no reason to expose users to a potential security risk when there’s a simple fix. Security isn’t something users should have to opt-in to; and unless there’s a very good reason, they shouldn’t have a way to opt-out.

Google should understand security and the value of the data they hold; they should be more responsible for the data (and faith) people give them.

How do I fix it?

Simple, from the “wrench” menu, select Options -> Personal Stuff -> Sign In -> Advanced… and then under “Encrypted data types” select “Encrypt all synced data” - and that’s it. After a couple of minutes the entries that were visible before will now just display the word “encrypted.”

You can also go a step further, and get rid of this data by disabling auto-fill to ensure that potentially sensitive information isn’t being persisted when it shouldn’t be.