Apple Online Store Security Flaw Exposed PINs of T-Mobile Customers

[Ethosik]

You don’t need to store millions of records at all. You are over thinking it. At its most pragmatic implementation level, you only have to restrict the number of tries for a given phone number. You can do this via Redis/Mongo/MySQL/etc. Hash their phone number, stored it in a volatile database, and associate a value. This value is the number of attempts. Set an expiration policy on the key. If key is accessed before expire time, increment corresponding value and update expiration. If key is hit > N times, then report error back.

This is completely disconnected from any API level integration.

If you think it costs significant resources, you are supporting the well known issue of Apple having internal management problems. For a company like Apple, it would not be an acceptable excuse. Now if you were a startup, you might have a point there.

And what happens when a million people miss type their pin three times? Millions of records. Like I said, it needs to support millions of records. What happens if they only plan for 10 people to have this issue at a time and there is an 11th person? Small example but you get the idea. They need to plan for large scale, or else there will be more problems.

This is like fixing a bug within a day vs a week to make sure it doesn't cause any more issues. Sure they can slap a poorly designed database table together, but it could cause issues if a lot of people suddenly start mistyping their pins several times.

This is how you handle large databases or a large customer base. Plan for a large data set. For example, we started using bigint instead of int for tables that constantly grow due to running into the limits of ints numerous times. You think it will never happen, but it does. And adjusting the code after the fact is very time consuming. Or a horrible approach is to reseed the index so that it utilizes the negative int values. So....you plan ahead. Oh and obviously our site was not even close to the same scale as Apple. NO WAY.

It doesn't matter how big or small a company is. It is still taking software development resources from other projects to implement this issue which should have been implemented at the API level in the first place.

What happens if there is a bug in Apple's implementation of these security checks?
What happens if like you said it will be a relatively small table but suddenly became larger than what they were planning and unforeseen bugs started to show up?

This is the problem with most software development these days. You think some of this stuff never happens, but it does.

 

[ipponrg]

And what happens when a million people miss type their pin three times? Millions of records. Like I said, it needs to support millions of records. What happens if they only plan for 10 people to have this issue at a time and there is an 11th person? Small example but you get the idea. They need to plan for large scale, or else there will be more problems.

DevOps scaling is fine. Redis/Mongo/Cassandra etc can be built to scale. This is nothing out of the ordinary for anyone with DevOps experience. If your intent is to develop a solution using persistent storage, then I'd say your architecture is flawed for this use case.

This is like fixing a bug within a day vs a week to make sure it doesn't cause any more issues. Sure they can slap a poorly designed database table together, but it could cause issues if a lot of people suddenly start mistyping their pins several times.

You keep referring to tables. There are other types of data stores that don't use tables. The schema for a preliminary gated check is fairly straight forward if you have dabbled with anything outside SQL.

This is how you handle large databases or a large customer base. Plan for a large data set. For example, we started using bigint instead of int for tables that constantly grow due to running into the limits of ints numerous times. You think it will never happen, but it does. And adjusting the code after the fact is very time consuming. Or a horrible approach is to reseed the index so that it utilizes the negative int values. So....you plan ahead. Oh and obviously our site was not even close to the same scale as Apple. NO WAY.

I think there is some confusion here. I am not talking about the back end architecture. I am only talking about the gate that would be sitting on the Apple side before it goes to the Tmobile APIs. Also, sounds like you're using a SQL database here. In other memory stores, your lookup parameters are using unique string keys and not numbers. Performance is done in-memory (e.g. volatile).

What happens if there is a bug in Apple's implementation of these security checks?
What happens if like you said it will be a relatively small table but suddenly became larger than what they were planning and unforeseen bugs started to show up?

What are you talking about? The worst case scenario here is Apple allows attackers to type PINS without restriction.

The initial size of the tables here don't really matter because it's assumed they will grow/shrink as necessary. Redis tables are the size of your memory. Now imagine if you had a cluster of Redis servers. You can grow that cluster via memory expansion for each instance dynamically with ease.

The worst case scenario here is you have 72M temporal records.

https://redis.io/topics/faq#what-is...ber-of-elements-in-a-hash-list-set-sorted-set

 

[boswald]

Not good. Not good at all. However, Apple always takes these issues seriously and will fix them promptly.

 

[Mascots]

Yeah, you're doing the exact same thing as zacharino. Cursory half-acknowledgement-half-excuse for Apple's involvement and the rest is "hey let's excoriate TMo for an issue where Apple was at fault. Apple accepted responsibility for it's actions and fixed the issue... on it's site, not TMo's. As I said earlier, TMo has issues... plenty of 'em. This issue is Apples.

Don't get me wrong Apple should have a form like this protected from brute force - but not because it allows unlimited guesses at a PIN - that should have never been a possibility from the carrier.

That responsibility lies with the entity handling the data and authentication, which is T-Mobile since they are the ones hosting that data. They should have their APIs for this kind of authentication locked at the very base point at which it accesses that information internally.

It's another failure of T-Mobile to handle, transit, and store sensitive information. If they're pushing that responsibility to those plugging into their system and seemingly not enforcing anything at all, that's the definition of unaccountability. "It's not my problem" isn't an answer I want to hear from those hosting my senesitive data.

Shame on Apple, but Tmo is hardly an innocent party.

 

[69Mustang]

Don't get me wrong Apple should have a form like this protected from brute force - but not because it allows unlimited guesses at a PIN - that should have never been a possibility from the carrier.

That responsibility lies with the entity handling the data and authentication, which is T-Mobile since they are the ones hosting that data. They should have their APIs for this kind of authentication locked at the very base point at which it accesses that information internally.

It's another failure of T-Mobile to handle, transit, and store sensitive information. If they're pushing that responsibility to those plugging into their system and seemingly not enforcing anything at all, that's the definition of unaccountability. "It's not my problem" isn't an answer I want to hear from those hosting my senesitive data.

Shame on Apple, but Tmo is hardly an innocent party.

Aaaaand there's the trifecta. The 3rd let's breeze by Apple and focus on TMo comment. No one claimed TMo to be an innocent party. But if the 3 comments I've replied to are any indication, one could almost believe the attack vector was TMo's website, not Apple's. Spread the blame. Good thing it's some of Apple fans and not Apple who feel the need to point at everybody else. Apple just slapped on big boy pants, fixed the issue, and said thanks for letting us know. Certain fans can't seem to abide Apple being at fault for anything. They have to make sure the bus wheels roll on everybody's neck. It's all good.

 

[Tech198]

There is no such thing as perfect security..... You only got perfection, until it breaks. I would also argue social engineering is making it too easy now-a-days, (*because*) of users plastering personal info on social sites...

The more info others know about us, the easy it will be to use it against us later, if they want.

 

[fairuz]

Yeah, you're doing the exact same thing as zacharino. Cursory half-acknowledgement-half-excuse for Apple's involvement and the rest is "hey let's excoriate TMo for an issue where Apple was at fault. Apple accepted responsibility for it's actions and fixed the issue... on it's site, not TMo's. As I said earlier, TMo has issues... plenty of 'em. This issue is Apples.

Yes, I am doing the same thing as zacharino. It's Tmo's API for the PINs, Tmo's fault if that can be abused. I hope Apple gets Tmo to fix their stuff instead of just sweeping it under the rug on their side. Anyone with experience in computer security or software design will agree.

 

[fairuz]

And what happens when a million people miss type their pin three times? Millions of records. Like I said, it needs to support millions of records. What happens if they only plan for 10 people to have this issue at a time and there is an 11th person? Small example but you get the idea. They need to plan for large scale, or else there will be more problems.

This is like fixing a bug within a day vs a week to make sure it doesn't cause any more issues. Sure they can slap a poorly designed database table together, but it could cause issues if a lot of people suddenly start mistyping their pins several times.

This is how you handle large databases or a large customer base. Plan for a large data set. For example, we started using bigint instead of int for tables that constantly grow due to running into the limits of ints numerous times. You think it will never happen, but it does. And adjusting the code after the fact is very time consuming. Or a horrible approach is to reseed the index so that it utilizes the negative int values. So....you plan ahead. Oh and obviously our site was not even close to the same scale as Apple. NO WAY.

It doesn't matter how big or small a company is. It is still taking software development resources from other projects to implement this issue which should have been implemented at the API level in the first place.

What happens if there is a bug in Apple's implementation of these security checks?
What happens if like you said it will be a relatively small table but suddenly became larger than what they were planning and unforeseen bugs started to show up?

This is the problem with most software development these days. You think some of this stuff never happens, but it does.

Postgres will handle millions of records straight out of the box (idk about MySQL cause I never use it), and Google's Spanner can scale much further if you can partition the data, but actually the other guy is right about in-memory data stores.

Anyway, they could have a prebuilt rate limiting service to plug into any web service without much effort. I don't blame Apple for this PIN issue but think they should do their own rate limiting anyway for other reasons.

 

[I7guy]

Aaaaand there's the trifecta. The 3rd let's breeze by Apple and focus on TMo comment. No one claimed TMo to be an innocent party. But if the 3 comments I've replied to are any indication, one could almost believe the attack vector was TMo's website, not Apple's. Spread the blame. Good thing it's some of Apple fans and not Apple who feel the need to point at everybody else. Apple just slapped on big boy pants, fixed the issue, and said thanks for letting us know. Certain fans can't seem to abide Apple being at fault for anything. They have to make sure the bus wheels roll on everybody's neck. It's all good.

It just couldn’t be T-MOBILE website shared in the blame, could it. The TMO web service couldn’t possibly be coded better, could it?

 

[Mascots]

Aaaaand there's the trifecta. The 3rd let's breeze by Apple and focus on TMo comment. No one claimed TMo to be an innocent party. But if the 3 comments I've replied to are any indication, one could almost believe the attack vector was TMo's website, not Apple's. Spread the blame. Good thing it's some of Apple fans and not Apple who feel the need to point at everybody else. Apple just slapped on big boy pants, fixed the issue, and said thanks for letting us know. Certain fans can't seem to abide Apple being at fault for anything. They have to make sure the bus wheels roll on everybody's neck. It's all good.

You literally said that T-Mobile have their issues, but this is just an Apple problem. I disagree that this is just an Apple problem. I never said this isn't an Apple problem. I think there are multiple levels of failure, but the biggest falls on the one supplying authentication, which is T-Mobile.

If you can't put ANY blame on T-Mobile for this issue because "it was on Applez site therefore it must be them!1!!", then you're just as bad as those who are only putting fault on T-Mobile.

Apple fixed their end, my concern is that T-Mobile isn't fixing theirs for other vendors with hooks into the unprotected service because of the emphasis on Apple and Asurion (in which I also find AT&T, the data owner, more at fault). Who will be the next entity with this vulnerability to point to when it's should be the data hosts for not doing their damn due diligence?