August 4, 2020 · Security ·

It’s 2020, And I’m Still Getting Plain Text Credentials Via Email

Today, I noticed something concerning - I received an automated email invoice from my landscaping company (who I won’t name here, out of courtesy) which contained a plain-text version of my credentials for their payment portal.

While this had happened before, it previously contained an auto-generated set of credentials (so I elected to continue leaving those in place for a while so as to minimize the “blast radius” were their system to be compromised).

I had recently changed my username and password to something else (my email address and a randomized password generated using 1Password), however, thinking that changing it both would tell the system to use the new email address I provided for future correspondence and perhaps flag the system to tell it to stop sending my credentials via email.

Neither of those things happened. The latest email invoice I received went to the previous email address on file, and my new credentials were still sent to me in plain text.

An Investigation

The payment portal itself is suspiciously vague about what third-party companies are responsible for its maintenance and card processing, so I decided to investigate. You may notice I didn’t have a lot to go on:

A cursory once-over returns absolutely no information. The company running this portal is not named in the only valid link on the page (the Terms and Conditions). “Privacy” is not a link, and nor is “Web 2” (whatever that means).

A call to the phone number listed goes nowhere; it’s invalid. I mean, 555-1212? Come on, what is this, a cheesy hollywood movie?

The paragraph about “contact us by email by clicking here”? The linked email is “[email protected]”. That sure isn’t going anywhere, either.

Since the information provided on the page itself is completely bogus, I next turned to the domain name itself. The domain name for this payment portal is “manageandpaymyaccount.com”. A WHOIS lookup merely returns what I expected - the registration is private, masked by GoDaddy.

A dig command returns two A records - both for a CDN called “Incapsula”. Not a common CDN, so I looked a bit further. The site is HTTPS enabled (at least there’s that), so a quick search on Censys for “manageandpaymyaccount.com” returns this:

Nothing out of the ordinary so far (except that Incapsula apparently runs their CDN using IIS - really?). Next I dug into the first certificate in the chain:

Bingo! Now we’re getting somewhere. Some other interesting domains are listed here. As it turns out, “serviceautopilot.com” is the SaaS company my lawn care company uses to manage and run their business. A quick dig shows “backtell.net” doesn’t point anywhere but Google tells us Backtell, LLC is the registered parent company of Service Autopilot, both based out of Richardson, TX.

Some further searching turns up a couple of interesting things:

The Reddit comment is from two years ago. Service Autopilot has been sending credentials in plain text for their payment portal (which they apparently went to rather surprising lengths to hide that they run) for at least two years, possibly much longer.

So what’s next?

Before writing this post, I reached out via email to the owner of my lawn care company, recommending he change payment processors and pointing out that sending passwords in the clear is non-compliant with PCI-DSS standards.

I also reported the issue using Service Autopilot’s contact form.

Upon receiving notification of my report, my lawn care company responded as follows:

“Thanks for bringing this to my attention, we are going to make some changes moving forward with our current way of emailing usernames and passwords.  These emails containing the username and password will serve as a temporary username and password for first time clients and we will encourage our clients to change their password/username any time they receive this email.  We will not continue resending them monthly as we have been doing which should ensure a level of protection to our clients.”

This is a good start, as switching payment systems and business process flows is not an overnight process; they’re definitely limited by Service Autopilot’s technology though.

Service Autopilot responded with the following:

“Thank you for contacting us.  I am glad to assist you.  You are correct. SA is not PCI compliant, that is why we do not store credit card information. We store the token only.  We recommend that when you email the client portal login information to your customers you advise them to change the password after they login.

As for safety concerns, you can advise them there is no credit card information stored in the portal, only customer name, address and phone.  If someone were to access a customer's account there is no financial information stored on the site.”

This was very vague. Aside from the fact that PCI compliance also generally applies to the merchant, they seemed very cavalier about protecting their customers’ addresses and phone numbers. (Not to mention that the fact they can retrieve passwords in plain text means they’re not encrypted!) When pressed on protecting PII, and whether they would alter their portal to address this lax security practice, they stated:

“I have not heard of any upcoming changes. I will pass your feedback along for review. I have submitted product suggestion ticket (ticket #) on your behalf.”

Thanks for nothing!

Important Notes