Another US Voter Database Leak
The database, a CouchDB instance, was located at IP address 22.214.171.124 on port 5984. It was configured for public access with no username, password, or other authentication required.
That address resolves to 126.96.36.199.bc.googleusercontent.com (which is the IP address in reverse followed by a google domain name). This indicates that the person or organization responsible for the leaky database was renting server space from Google’s Cloud services.
Each record contained an ID field following the scheme of “LAL”+[State Abbreviation]+[Record Number] (an example for Alaska would be LALAK176743). A little internet sleuthing showed that a data brokerage company named L2 (http://www.l2political.com) uses the same naming scheme for their records.
On Tuesday, June 21st, 2016, I sent an email to every L2 email address I could easily locate notifying them of the situation. In my email I put forth the theory that a client of theirs was hosting data purchased from L2 in an insecure manner and asked for L2’s assistance in getting it taken down. I also attached a screenshot as proof of my findings. It turns out that my hypothesis was correct and L2 was more than willing to help me track down the client at fault.
Shortly after my email went out I received a response from L2’s CEO, Bruce Willsie, asking me to give him a call and providing his cell phone number. We had a pleasant conversation and I provided him with additional details that would hopefully assist in identifying exactly which client was responsible.
The database was taken offline within three hours of our telephone conversation. That’s a pretty good turnaround time if you ask me. After noticing that the database had disappeared, I sent another email to Bruce asking if L2 would like to make any statement prior to me reporting on the situation. His response was:
Thank you for finding this and thank you for giving us the opportunity to respond. We very quickly identified the national client, informed them immediately and they took down the site as quickly as they could. The client told us that they were hacked, the firewall was taken down and then the probing began.
This was an old copy (from about a year ago) of the national file and it had only a very small number of our standard fields. Needless to say, the client is doing its own research now to determine the extent of the incursion. I’ve asked that they report back to us with their findings and their plan for hardening their system in the future. It’s unfortunate and, again, we greatly appreciate your discovery of the problem.
The “we were hacked” explanation comes out a lot in the kind of research that I do. One of the more noteworthy examples of this was when the Citizens’ Movement political party of Mexico made the same claim after I found an exposed copy of that country’s voter database. I have always believed that Citizens’ Movement was just lying to cover their own mistake.
That doesn’t necessarily mean that L2’s client is lying about being hacked, but I am taking it with a grain of salt.
The Serbian Connection:
While I was poking around this publicly exposed US voter profile database, I happened to query the server’s log file. The limited results are in the final screenshot above this post. Forgive me for not being more savvy with the CouchDB suite at the time (I’ve since learned of better ways to enumerate the log file).
You can see that a Serbian IP, 188.8.131.52, was interacting with this same database back on April 11th of this year. Why was a Serbian IP messing around with a US voter database? Even if this was just a proxy server it is still very troubling that this apparent incursion took place back on April 11th.
If you have any special insight as to which organization may be responsible for this leak, please leave a comment below or send me an email. I’ve included a fair bit of information in this post, and maybe someone with better sleuthing skills than myself can help crack the case. I don’t think L2 is going to tell us.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher, Chris Vickery.