Bright City: A Highly Insecure Police and Municipal Government App

Earlier this year I received a Nextdoor message from my County Police Department announcing a “Property LockBox App” they’d released (purchased) for citizens. There was no previous communication regarding this app that I could find, so I was interested in learning more about it.

As the app description states, Bright City is “[a] 2-way, dedicated mobile application for cities and law enforcement.” In addition to the “property lockbox” feature mentioned in the NextDoor announcement, the app supports receiving and submitting reports of suspicious activities, scheduling property watches to protect citizens’ homes when away, and reporting municipal maintenance issues. Bright City’s website describes some additional features, including payment processing of municipal fees for citizen citations, licenses, etc.:

The nature of the information involved in the app seemed highly sensitive, so I was interested in a closer look. I installed the app, created an account, and logged in. Here’s a look at the initial dashboard:

While proxying the requests on my device, I started moving through some of the options in the app to generate some API traffic. It didn’t take long to notice some very serious concerns — below is an example request the app makes while fetching the current user’s profile information:

Similar to another local municipal app I’ve written about recently, the request requires no authentication whatsoever. While this is alarming enough, it does get worse. Here’s a look at the API response to the above request:

Note that though I’ve removed it from the above output, the user’s password is returned in plain text. Clearly, this is as bad as it gets.

Next, I decided to decompile the app to see if I could find a more exhaustive list of its API endpoints (and whether any required authentication at all). Here’s a look at the main activity:

Since the app uses Android Cordova, almost none of the code was in Java. Instead, I moved over to the assets/www directory and found all of the HTML/JS that made the app run.

I opened up the editlockbox.js file and took a look at the JavaScript containing some of the API requests:

As you can see, all requests were made in a similar way — without any authentication or session-state mechanism whatsoever. Next, I wrote a quick script to search through all of the JavaScript files to produce a list of all endpoints:

Additionally, I setup a “lockbox” under my account and uploaded some images to test its functionality. I wasn’t surprised to find that directory listing was allowed, meaning all of the uploaded documents and images in the app were publicly accessible.

Risks

The risks to the public in using this app are numerous and severe. Not only is there sensitive information stored in the app itself for attackers to take freely, but actions and events within the system can be spoofed and submitted on the behalf of other users (or police agencies).

Without a fundamental authentication requirement, the integrity of any app information or action/event cannot be guaranteed to be legitimate. To be clear, there are user passwords (and other personal info), resident reports of suspicious persons, citizen electronic catalogs, and even payment information stored and used in this system — and none of it is safe.

It’s also important to note that the impact on users could be much further reaching than the Bright City system alone. Exposing user passwords in plain text can lead to compromises of other accounts (e.g. email, banking, social media) since it’s common for users to use the same passwords in multiple systems.

Disclosure

I’ve debated on how to address this particular disclosure in the most effective way possible. As in my other blog posts, I make every effort to work with vendors in reporting and patching identified vulnerabilities — but this is a little different.

I ended up reporting the above issues to the County and we had a brief call to discuss. While the vendor ended up taking the entire app offline to implement authentication, numerous other issues I reported remain unaddressed (including the directory listing issue).

2017-07-05 Initial report to County
2017-07-06 Call with County leadership to discuss
2017-07-07 Confirmed app taken offline
2017-07-17 I check status of the app, it’s back online. No further communication from vendor/County on other vulnerabilities.
Share this: Facebooktwittergoogle_pluslinkedin
  • Rex Knight

    Nice job/expose, Randy! It would be nice if you could have gotten a position from the County as a “trusted advisor” to be a fact checker and outside consultant to confirm all security needed has been added.