That Time I Became A 76-Year-Old New Yorker

A case of mistaken identity reveals a security flaw that exposes private health information.

Or, what happens when you send an email to the wrong place.

Note, for the time being, I have redacted the names of the company and doctor involved as I am attempting to follow through with a responsible disclosure process for this security issue.

I had something very strange happen to me today.

It all began with a random email to an address that I don’t use much anymore, but still have in Mail. It’s an email account I’ve had for over 13 years, so it still gets the occasional stray email. The subject read as follows:

Followed in quick succession by another one:

Wait, what?

I was confused looking at them. At first I thought they were spam, but they had my firstname and lastname in them and “looked” legit. A quick Google search for “<redacted>” shows it to be some cloud-based patient portal. The URLs in the email matched their site and the email was sent from “redacted-db19” mail server, so everything about this looked legitimate.

I figured one of my doctors had started using this online portal. The first one contained a username and the second one, send a minute later, contained a temporary password.

Well, that’s not very secure. But whatever, there are a lot of amateurs out there, so I better go sign in and change the password.

Imagine my surprise when I logged in with the username in the first email and the temporary password and was immediately prompted to change my password! No verification of the account ownership. Just immediately dropped to an old password, new password, enter new password again style password reset dialog.

Still operating under the assumption that this was sent to me, but making a mental note to talk with whichever of my doctors is using this product about its lack of security, I changed the password and hit submit.

What I saw next shocked me.

There, plain as day, was the full personal information for a “Robert Peck” who lives in New York City. Who was born in 1941. Who has an appointment in February. I saw his full name, address, both cell phone and home phone, even the last 4 of his social (the first 5 were X-ed out, but I’m guessing they have that too). History of visits with doctors.

Everything I would need to convincingly impersonate this person was handed to me with absolutely no verification that I was this person. Even a rudimentary “enter your birthdate” on the password reset dialog would have stopped me, because, obviously, I am not that person.

Then I looked over at the email more closely, and it was sent by <redacted> in care of some doctor in New York City. I should have caught that first, but I completely glossed over it.

So this company, <redacted>, is holding people’s personal identifying information and health information, and literally all you need to get it is a mistyped email address. They practice no good security policy when it comes to handling this type of information.

I thought about this for a little bit and asked my coworkers for advice. This whole thing was inadvertent, but I’ve heard of people getting in trouble for disclosing things like this this in the past. After thinking for awhile, I sent the following email to the doctor’s office in question:

I haven’t heard back yet.

I’m also attempting to contact the company in question, but they have no responsible disclosure email address on their site. So I sent an email to support@ with the following message:

I immediately received a response to this one! … a vacation notice telling me this person was out of the office until December 7th.

Doing Software Right Is Hard

Writing software is not for the faint of heart, especially on the web. I get that, because I’ve been doing it for nearly 20 years now. It’s tricky and there are a lot of things that can go wrong. There are a lot of bad actors out there looking to take advantage of any small misstep.

Some of the security vulnerabilities I’ve seen blow my mind. This one at Facebook comes to mind, where a person chained multiple tiny vulnerabilities together into a real exploit. These people, my hat is off to them, because that’s an impressive piece of work.

But some things are simple and have not changed in many, many years. Never trust a user. For accounts that are not created by a user, verify identity before you allow first time access. Never ever ever send a password, even a temporary one, in an email. These things have been known for many years and are considered standard industry practice at this point.

A good example of this is PNC Bank, who currently services my mortgage. When they bought my mortgage from Franklin American, they created an account for me in their online banking system. To get access to this account, I had to enter the birthdate and last 4 of my social security number, and then they physically mailed me a PIN that allowed me to complete the signup process.

Was it inconvenient? Absolutely. Is it the correct way to handle super sensitive financial information? Also absolutely.

At a certain point, when you have been entrusted with someone’s most intimate personal details, it’s time to stop behaving like a startup and more like a bank. Because that’s what you are: a bank of information. People are trusting you to hold their data and not play fast and loose with it. And that means following industry-standard security practices and doing the hard, unglamorous parts of software development.

And please have a responsible disclosure policy for when things go wrong. Preferably one not monitored by a single person who will go on vacation.

Comments (0)

Interested in why you can't leave comments on my blog? Read the article about why comments are uniquely terrible and need to die. If you are still interested in commenting on this article, feel free to reach out to me directly and/or share it on social media.

Contact Me
Share It
Home Assistant
One of the big missing pieces from my conversion to Home Assistant was Amazon Alexa integration. It wasn’t something we used a lot, but it was a nice to have. Especially for walking out a room and saying “Alexa, turn off the living room lights.” I had been putting it off a bit because the setup instructions are rather complex. But this weekend I found myself with a couple free hours and decided to work through it. It actually wasn’t as difficult as I expected it to be, but it is definitely not the type of thing a beginner or someone who does not have some programming and sysadmin background could accomplish. But in working through it, there was one thing that was an immediate red flag for me: the need to expose your Home Assistant installation to the Internet. It makes sense that you would need to do this - the Amazon mothership needs to send data to you to take an action after all. But exposing my entire home automation system to the Internet seems like a really, really bad idea. So in doing this, rather than expose port 443 on my router to the Internet and open my entire home to a Shodan attack, I decided to try something a bit different.
Read More
PHP
PHP’s PHAR archives (PHp ARchives, get it?) are a neat development. They’re a way to distribute an entire PHP application as a single archived file that can be executed directly by the PHP intepreter without unarchving them before execution. They’re broadly equivalent to Java’s JAR files and they’re super useful for writing small utilities in PHP.
Read More
Apache
I’ve been using Google Chrome as my primary browser for the last few months. Sorry, Firefox, but with all the stuff I need to work installed, you’re so slow as to be unusable. Up to and including having to force-quit at the end of the day. Chrome starts and stops quickly But that’s not the purpose of this entry. The purpose is how to live with self-signed SSL certificates and Google Chrome. Let’s say you have a server with a self-signed HTTP SSL certificate. Every time you hit a page, you get a nasty error message. You ignore it once and it’s fine for that browsing session. But when you restart, it’s back. Unlike Firefox, there’s no easy way to say “yes, I know what I’m doing, ignore this.” This is an oversight I wish Chromium would correct, but until they do, we have to hack our way around it. Caveat: these instructions are written for Mac OS X. PC instructions will be slightly different at PCs don’t have a keychain, and Google Chrome (unlike Firefox) uses the system keychain. So here’s how to get Google Chrome to play nicely with your self-signed SSL certificate: On your web server, copy the crt file (in my case, server.crt) over to your Macintosh. I scp'd it to my Desktop for ease of work. ** These directions has been updated. Thanks to Josh below for pointing out a slightly easier way.** In the address bar, click the little lock with the X. This will bring up a small information screen. Click the button that says “Certificate Information.” Click and drag the image to your desktop. It looks like a little certificate. Double-click it. This will bring up the Keychain Access utility. Enter your password to unlock it. Be sure you add the certificate to the System keychain, not the login keychain. Click “Always Trust,” even though this doesn’t seem to do anything. After it has been added, double-click it. You may have to authenticate again. Expand the “Trust” section. “When using this certificate,” set to “Always Trust” That’s it! Close Keychain Access and restart Chrome, and your self-signed certificate should be recognized now by the browser. This is one thing I hope Google/Chromium fixes soon as it should not be this difficult. Self-signed SSL certificates are used **a lot **in the business world, and there should be an easier way for someone who knows what they are doing to be able to ignore this error than copying certificates around and manually adding them to the system keychain.
Read More