Verizon Glitch Allowed Easy Viewing of Texting Data From Any Number

[roseofbattle]

Verizon Glitch Allowed Easy Viewing of Texting Data From Any Number

Thanks to a URL mistake, texting data for Verizon customers could have been viewed by anyone.

Nothing is completely private anymore, but when we use a service or device that has pervaded our daily lives, we expect there will be certain safeguards to keep our information from getting out. A URL exploit may have exposed texting data for Verizon customers, security researcher Prvsec reported. Prvsec reported the problem to Verizon, who fixed the problem in over a month and did not disclose the the issue for another month.

When downloading a file of the time, date, and recipient of texts on Verizon's "download to spreadsheet" function, a person could easily find data on others by simply changing the phone number in the URL. The spreadsheet would contain the numbers of people the user had texted, potentially exposing the phone numbers of many other people.

A Verizon representative said the company "takes customer privacy seriously" and "no customer information was impacted."

The Prvsec researcher reports having a difficult time even contacting Verizon to inform the security team of the glitch. A lengthy process stood in the way of contact, and Verizon did not update the status of the bug for months. "They need to make it easier to reach out," Prvsec said. Prvsec was only able to get Verizon's attention through LinkedIn. Verizon now has an email contact for security issues.

Source: The Verge [http://prvsec.com//verizon-wireless-message-detail-disclosure.html]

Permalink

 

[Tortilla the Hun]

Well shit... How's the NSA supposed to get their data now?

Not to worry, there is still Google and Facebook.

On topic, that is really quite the oversight. You'd think something like this would be very hard to miss, unless they didn't do much testing for the feature in the first place. I know you can't account for all variables, but this seems like a pretty big one.

 

[CriticalMiss]

Well shit... How's the NSA supposed to get their data now?

Probably by threatening to lock up and execute Verizon employees for being terrorists, only a terrorist would want to keep something from the NSA!

A Verizon representative said the company "takes customer privacy seriously" and "no customer information was impacted."

Obviously they don't take privacy seriously or this wouldn't have happened or would at least have been fixed sooner. And how do they know that "no customer information was impacted"?

 

[DiamanteGeeza]

Obviously they don't take privacy seriously or this wouldn't have happened or would at least have been fixed sooner. And how do they know that "no customer information was impacted"?

The article said it was fixed "within a month", which sounds about right - you can't just hack in a 'quick fix' when you're talking about a database and network the size of Verizon's. Maybe they took that feature offline? That would seem like the best thing to do while it's being fixed, unless, of course, that then has knock-on consequences too. These massive databases with URL requests are insanely complex behind the hood (I know, I had the misfortune to be involved with one a few years back), and even the tiniest change needs to be tested inside out across the entire system, because you never know what relies on what has just been changed - one person simply cannot hold all of the infrastructure in their heads. It sounds crazy, I know, and I felt the same way as you before I got involved with one, and my brain then exploded!

As for how do they know, my guess is that it's a reasonably low-traffic feature (hence nobody discovering this before), and they simply looked at the logs for how many calls to this API were made and from what IP addresses. If the same IP kept requesting data from different numbers, then they have a problem. If that pattern didn't exist, then there's probably very little threat. It's impossible to know for certain, I'm afraid. That's the nature of the beast.

 

[Zombie_Moogle]

Obviously they don't take privacy seriously or this wouldn't have happened or would at least have been fixed sooner. And how do they know that "no customer information was impacted"?

The article said it was fixed "within a month", which sounds about right - you can't just hack in a 'quick fix' when you're talking about a database and network the size of Verizon's. Maybe they took that feature offline? That would seem like the best thing to do while it's being fixed, unless, of course, that then has knock-on consequences too. These massive databases with URL requests are insanely complex behind the hood (I know, I had the misfortune to be involved with one a few years back), and even the tiniest change needs to be tested inside out across the entire system, because you never know what relies on what has just been changed - one person simply cannot hold all of the infrastructure in their heads. It sounds crazy, I know, and I felt the same way as you before I got involved with one, and my brain then exploded!

As for how do they know, my guess is that it's a reasonably low-traffic feature (hence nobody discovering this before), and they simply looked at the logs for how many calls to this API were made and from what IP addresses. If the same IP kept requesting data from different numbers, then they have a problem. If that pattern didn't exist, then there's probably very little threat. It's impossible to know for certain, I'm afraid. That's the nature of the beast.

True points all, except for one thing: this should have come out in exactly that kind of testing if it was so large a glitch as to work with any account. You're absolutely right about massive databases needing incredible amounts of testing, but clearly Verizon wasn't bothering with bug testing in the first place

So who knows?

 

[DiamanteGeeza]

True points all, except for one thing: this should have come out in exactly that kind of testing if it was so large a glitch as to work with any account. You're absolutely right about massive databases needing incredible amounts of testing, but clearly Verizon wasn't bothering with bug testing in the first place

I know that's how life should work, but with a system that incredibly massive, it's really easy to overlook the odd thing here and there or, it might have been secure at one point, but a change elsewhere (and unrelated) by one of the army of engineers had an unintended consequence that nobody foresaw.

I promise you Verizon will have tested the crap out of their API - their business depends on it. Although this shouldn't have happened, to blame Verizon for "not bothering with bug testing" is unfair, and shows a lack of understand regarding how database back-ends work, and the staggering magnitude of what is being dealt with.

Like I said, a few years ago I shared your view entirely - it's only when you get involved that you realize how truly hard it is to get 100% right every single time. You have to remember that their API behind the scenes will be updated on a regular basis to add/modify/remove features and fix bugs, but massive lengths are gone to to ensure that you, the end user, never knows about it. One of these updates, I'm almost certain, will have accidentally been the cause of this security flaw and, for whatever reason, it wasn't caught by QA before release. Probably because, if this feature is low traffic, it might not have featured on their pre-release QA sweep list. You can bet your ass it's included now!

(And just for the record, when we finally went live, you wouldn't believe all the stupid why-didn't-someone-catch-that bug issues that popped up! It was a huge learning experience for me, and I've been a programmer for many decades!)

 

[CriticalMiss]

Obviously they don't take privacy seriously or this wouldn't have happened or would at least have been fixed sooner. And how do they know that "no customer information was impacted"?

The article said it was fixed "within a month", which sounds about right - you can't just hack in a 'quick fix' when you're talking about a database and network the size of Verizon's. Maybe they took that feature offline? That would seem like the best thing to do while it's being fixed, unless, of course, that then has knock-on consequences too. These massive databases with URL requests are insanely complex behind the hood (I know, I had the misfortune to be involved with one a few years back), and even the tiniest change needs to be tested inside out across the entire system, because you never know what relies on what has just been changed - one person simply cannot hold all of the infrastructure in their heads. It sounds crazy, I know, and I felt the same way as you before I got involved with one, and my brain then exploded!

Given how much people freak out about personal information being leaked, I'd have said that taking it offline for a month would be the better option than people trying to sue you for leaving their info out in the open. I would also have expected them to test such things before hand so that it never occured in the first place. Good to hear you glued your brain back together though

As for how do they know, my guess is that it's a reasonably low-traffic feature (hence nobody discovering this before), and they simply looked at the logs for how many calls to this API were made and from what IP addresses. If the same IP kept requesting data from different numbers, then they have a problem. If that pattern didn't exist, then there's probably very little threat. It's impossible to know for certain, I'm afraid. That's the nature of the beast.

That's true, although if someone used a proxy or something surely they could hide themselves to some extent? Data thieves are probably clued in enough to know how to cover their tracks.

 

[RandV80]

Obviously they don't take privacy seriously or this wouldn't have happened or would at least have been fixed sooner. And how do they know that "no customer information was impacted"?

The article said it was fixed "within a month", which sounds about right - you can't just hack in a 'quick fix' when you're talking about a database and network the size of Verizon's. Maybe they took that feature offline? That would seem like the best thing to do while it's being fixed, unless, of course, that then has knock-on consequences too. These massive databases with URL requests are insanely complex behind the hood (I know, I had the misfortune to be involved with one a few years back), and even the tiniest change needs to be tested inside out across the entire system, because you never know what relies on what has just been changed - one person simply cannot hold all of the infrastructure in their heads. It sounds crazy, I know, and I felt the same way as you before I got involved with one, and my brain then exploded!

As for how do they know, my guess is that it's a reasonably low-traffic feature (hence nobody discovering this before), and they simply looked at the logs for how many calls to this API were made and from what IP addresses. If the same IP kept requesting data from different numbers, then they have a problem. If that pattern didn't exist, then there's probably very little threat. It's impossible to know for certain, I'm afraid. That's the nature of the beast.

This is the first I've heard of it, but if a user could download anyone's text logs by typing a different number to the url then it sounds like a basic web scripting 101 mistake of using the GET method instead of POST. If that was the case then this was not a 'bug' nor was accessing the data a 'hack', it was just a plain old **** up on Verizon's part.

 

[DiamanteGeeza]

This is the first I've heard of it, but if a user could download anyone's text logs by typing a different number to the url then it sounds like a basic web scripting 101 mistake of using the GET method instead of POST. If that was the case then this was not a 'bug' nor was accessing the data a 'hack', it was just a plain old **** up on Verizon's part.

Unless that API call was supposed to have your session pre-authenticated and never be used as an end-point? For whatever reason, an update somewhere changed that? Then you have a low priority and traffic feature, accidentally made insecure, said feature no longer on the QA sweep (for whatever reason), and you get a big ol' *&^*-up!

I don't know. I'm wildly speculating now, but I have a really hard time believing that Verizon would, upon launch of this feature, have it as insecure as that. Maybe I'm wrong, but I hope not!

 

[DiamanteGeeza]

Given how much people freak out about personal information being leaked, I'd have said that taking it offline for a month would be the better option than people trying to sue you for leaving their info out in the open.

I agree completely, but there may have been a valid reason they were unable to do this. I'm sure if they could have shut down a security loophole immediately, they would have...?

I would also have expected them to test such things before hand so that it never occured in the first place.

And I'm sure they did. Verizon's engineers aren't stupid - my best guess to explain this is that it was secure when the feature launched, but an update changed something that had an unintended consequence that then made this API call insecure. If the feature wasn't used much, it's possible it fell off a QA sweep list over time and so the update was pushed live without anybody noticing what had happened.

Like I said, I'm not condoning what happened, just putting forth an argument to counter the 'Verizon iz dumb' reasoning. They're not dumb, far from it, but mistakes happen - we're all only human. I make plenty!

 

[thisbymaster]

Well, that would make someone else see them.

 

[Jadak]

]

This is the first I've heard of it, but if a user could download anyone's text logs by typing a different number to the url then it sounds like a basic web scripting 101 mistake of using the GET method instead of POST. If that was the case then this was not a 'bug' nor was accessing the data a 'hack', it was just a plain old **** up on Verizon's part.

Using GET instead of POST is not necessarily a mistake, and certainly not the one at issue here. POST values could be manipulated to exploit the same flaw. ( albeit slightly less easily ).

Still, this is indeed a rookie web programming mistake, but the error is in the lack of server side input validation, not the request method used.

 

[Zombie_Moogle]

True points all, except for one thing: this should have come out in exactly that kind of testing if it was so large a glitch as to work with any account. You're absolutely right about massive databases needing incredible amounts of testing, but clearly Verizon wasn't bothering with bug testing in the first place

I know that's how life should work, but with a system that incredibly massive, it's really easy to overlook the odd thing here and there or, it might have been secure at one point, but a change elsewhere (and unrelated) by one of the army of engineers had an unintended consequence that nobody foresaw.

I promise you Verizon will have tested the crap out of their API - their business depends on it. Although this shouldn't have happened, to blame Verizon for "not bothering with bug testing" is unfair, and shows a lack of understand regarding how database back-ends work, and the staggering magnitude of what is being dealt with.

Like I said, a few years ago I shared your view entirely - it's only when you get involved that you realize how truly hard it is to get 100% right every single time. You have to remember that their API behind the scenes will be updated on a regular basis to add/modify/remove features and fix bugs, but massive lengths are gone to to ensure that you, the end user, never knows about it. One of these updates, I'm almost certain, will have accidentally been the cause of this security flaw and, for whatever reason, it wasn't caught by QA before release. Probably because, if this feature is low traffic, it might not have featured on their pre-release QA sweep list. You can bet your ass it's included now!

(And just for the record, when we finally went live, you wouldn't believe all the stupid why-didn't-someone-catch-that bug issues that popped up! It was a huge learning experience for me, and I've been a programmer for many decades!)

I know you're right; it's just fun to bust balls when a billion-dollar company screws up this hard

Not sure "their business depends on it" though, seeing as telecoms (at least here in the US) have a pretty tight monopoly, but that's another conversation entirely

 

[lacktheknack]

True points all, except for one thing: this should have come out in exactly that kind of testing if it was so large a glitch as to work with any account. You're absolutely right about massive databases needing incredible amounts of testing, but clearly Verizon wasn't bothering with bug testing in the first place

So who knows?

This is really insulting to anyone who's worked on a database.

Just because one issue did not get caught right away doesn't mean they didn't try. To claim it does only reveals the magnitude of how much you don't understand databases.