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

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 [email protected] 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.

Did something I wrote help you out?

That's great! I don't earn any money from this site - I run no ads, sell no products and participate in no affiliate programs. I do this solely because it's fun; I enjoy writing and sharing what I learn.

COVID-19 has taken the world by storm and left a lot of brokenness in its wake. A lot of people are suffering. If you feel so inclined, please make a donation to your local food bank or medical charity. Order take-out from your local Chinese restaurant. Help buy groceries for an unemployed friend. Help people make it through to the other side.

But if you found this article helpful and you really feel like donating to me specifically, you can do so below.

Read More

Securing Home Assistant Alexa Integration

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.

Securely Signing PHP Phar Files With OpenSSL

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.