Verizon Hum Leaking Credentials

or, Christmas Infosec Insanity…

A friend mentioned Hum by Verizon, a product that I hadn’t heard of but quickly caught my attention – both from a “here’s a privacy nightmare” perspective, and “I might actually use that” perspective. While looking at the site, I decided to take a look at the source code for the shopping page – what I saw was rather unexpected.

Near the top is a large block of JSON assigned to an otherwise unused variable named phpvars – included was some validation code, a number of URLs, some HTML, and the like. After seeing the first element, isDeveloperMode, I was sure this was worth a closer look.

A few lines in, I ran across something that I would have never expected from a company like Verizon:

Username, password. Embedded in JavaScript. Seriously.

In the JSON, there are several API endpoints listed, from a variety of domains (only one of which is publicly resolvable):

  • osb-bss-vv.vtitel.net
  • atlspare05xd.hughestelematics.net:8011
  • shopping.hum.com

If any of these endpoints would allow an outside attacker to gather private data, I couldn’t say.


There are a few things about this that really surprise me:

  • How did Verizon allow this to go live?
  • Why aren’t they doing any type of post-deployment testing?
  • Weblogic12 – Seriously? Is that really an acceptable password?

The use of stolen and/or misused credentials (user name/passwords) continues to be the No. 1 way to gain access to information. Two out of three breaches exploit weak or stolen passwords, making a case for strong two-factor authentication. – Verizon Data Breach Investigations Report

I’ve reached out to Verizon via Twitter to ensure that they are aware that this information is being leaked. I attempted to email both security@verizon.com and security@hum.com – neither of which are valid addresses (another surprise from a company that should have a clue).