The parent firm of bling retailers Jared and Kay Jewelers has fixed a bug in the Web sites of both companies that exposed the order information for all of their online customers.
In mid-November 2018, KrebsOnSecurity heard from a Jared customer who found something curious after receiving a receipt via email for a pair of earrings he’d just purchased as a surprise gift for his girlfriend.
Dallas-based Web developer Brandon Sheehy discovered that slightly modifying the link in the confirmation email he received and pasting that into a Web browser revealed another customer’s order, including their name, billing address, shipping address, phone number, email address, items and total amount purchased, delivery date, tracking link, and the last four digits of the customer’s credit card number.
Sheehy said after discovering the weakness, his mind quickly turned to the various ways that crooks might exploit it.
“My first thought was they could track a package of jewelry to someone’s door and swipe it off their doorstep,” he said. “My second thought was that someone could call Jared’s customers and pretend to be Jared, reading the last four digits of the customer’s card and saying there’d been a problem with the order, and if they could get a different card for the customer they could run it right away and get the order out quickly. That would be a pretty convincing scam. Or just targeted phishing attacks.”
Concerned that his own information was similarly exposed, Sheehy contacted Jared parent company Signet Jewelers and asked them to fix the data exposure. When several weeks passed and Sheehy could still view his information and that of other Jared customers, he reached out to KrebsOnSecurity.
Scott Lancaster, chief information security officer at Signet, said the company did fix the problem for all future orders shortly after receiving a customer’s complaint. But Lancaster said Signet neglected to remedy the data exposure for all past orders until contacted by KrebsOnSecurity.
“When a customer first brought this matter to our attention in early November, we fixed it for all new orders going forward,” Lancaster said. “But we didn’t notice at the time that this applied to all past orders as well as future orders.”
Lancaster said the problem affected only orders made online through jared.com and kay.com, and that the weakness was not present on the sites of the company’s other jewelry brands, such as Zales and Piercing Pagoda.
Data exposures like these are some of the most common yet preventable for online retailers. In July, identity theft protection service LifeLock corrected an information disclosure flaw that exposed the email address of millions of subscribers. And in April 2018, PaneraBread.com remedied a weakness exposing millions of customer names, email and physical addresses, birthdays and partial credit card numbers.
Sheehy said he’s glad Signet has fully fixed the bug, but said he was annoyed that it seems like many companies fail to address or even acknowledge such failures unless and until they’re confronted by the news media.
“Being a Web developer, the only thing I can chalk this up to is complete incompetence, and being very lazy and indifferent to your customers’ data,” he said. “This isn’t novel stuff, it’s basic Web site security.”
Dec. 11, 10:37 a.m.: Corrected Sheehy’s title.
Thanks for everything you do to keep us informed and help protect us from the ignorant & negligent!
Thanks Brian…. now I have an excuse why I can’t get any jewelry for my wife 🙂
I would love to comment but I wish to do so anonymously . I was refused cleaning and service at one of the sterling stores even though I had all my paperwork from Leroy. They finally agreed to clean the jewelry but said I needed several hundred dollars worth of repairs. I declined. All the jewelry had life time guarantee that I purchased. I took my jewelry to another jewelry store not owned by sterling
They gladly cleaned and checked it and said they could tell my wife took good care of her jewelry… I purchased a new band from Reeds $1200 dollars and I will never shop a sterling owned store again. It seems like they are finding unnecessary repairs that my contract conveniently doesn’t cover.. investigate that
You are on the correct page for consumer investigations.
Good read !
This is such a lazy ass answer that they fixed it for new customers and forgot to fix it for existing ones. It’s done by the same script. How would it be different? Simply put an authentication on the link so no one who sees that email can access your purchase data. How lazy can a company be not to understand this basic security tenet. I bet they would do nothing if not for Krebs contacting them.
Actually since they sent links to customers that did not have hashes, they had to make those “weak” links continue to work otherwise past customers would no longer be able to access their order status.
Alternatively, they could have sent an email to all current orders with a new safe link, mentioning the other link would no longer work. But that would have meant telling customers they are incompetent so I’m pretty sure some manager quickly decided that it was not going to happen since the risk was low (who rewrites URLs, frankly ?).
Actually it is trivial to make the old “insecure” links work properly – just make a login required for the page (which it should be anyway) then match the users email with the order number in the database. If it doesn’t match, nothing is returned.
The transaction that triggered the realization they had a problem was, by definition, a past order. “Stopping the bleeding” is a great first step in these situations, but failing to realize that the fixing the future orders did not fix previous orders shows that application security was not the only failure here.
Mr. Lancaster has some explaining to do. Not only did his staff fail to recognize that PAST orders were affected, his previous position was CISO for Starwood Hotels and Resorts – the culprits in the 500-million-records breach just announced by Marriott.
Not a record to inspire confidence……
Although Lancaster left Starwood in 2011, and the breach only goes back 4 years.
Perhaps the breach scope was limited by a data retention policy of 4 years, and the problem was systemic for much longer. Or perhaps the new guy messed up.
And Lancaster has been at Signet for only a few months… not likely enough time to make changes. He may have inherited a mess.
First step when inheriting a mess, find out what’s in that mess. This should have been an immediate red flag to any security professional. And maybe even a security amateur.
It always gives me pause when I order something online and the link to my order status requires no login. Security by obscurity isn’t really a thing any more.
I always start with the benefit of doubt. A CISO is very high level, and it typically takes a while for specific problems to go up the flag pole.
There are probably 3, 4 or 5 managers, directors inline between the appsec team (who would be directly responsible) and the CISO.
It is very unlikely the CISO would be managing the remediation, or even aware of this problem.
Of course, if the CISO wasn’t aware even after several weeks, that would be a failing of how the department reports risk up to the CISO.
Basically, it is easy to assign blame in hindsight… but in reality, security is hard to do right all the time.
“A CISO is very high level, and it typically takes a while for specific problems to go up the flag pole.”
He should have made it a standing policy that he is immediately notified if a problem of that magnitude and importance is discovered.
Bad PR can do serious damage to the business.
“He should have made it a standing policy that he is immediately notified if a problem of that magnitude and importance is discovered.”
Yeah, maybe. But many times the disconnect, is that people below him may not be regarding this with the same magnitude and importance that we know in hindsight. And it takes time for everyone in a large organization to sync up with the intent on the new, incoming CISO.
There are obvious security gaps that exist, and this is often made worse during transition periods.
The Captain Goes Down With The Ship. No excuses.
A proven concept throughout human history, applicable to all endeavors. You loose that concept and things get out of control, as with IT security.
That is fair. Even if the captain is new, it is his/her responsibility that is accepted. So the buck should stop with Lancaster.
Yes, he may be putting out fires, but it sounds like he was on the job in November when the fix was made for future orders. Good catch on the Starwood connection.
New marketing slogans:
“He stole it at Jared!”
“Every klepto begins with K.”
I have stopped shopping at all Sterling brand stores after the whole, we are taking your good gems are replacing them with lesser quality gems scams they had going on. Who knows what you are getting with your purchase.
I just returned ALL of my purchased extended service plans. My husband and I were treated very badly and will Never go to a Kays.you have up to 5 years to return service plans. As for online with this company……Use Caution!!!
Good read. if all these large companies can’t protect their user’s data, your data held by a small business with no security program in place is already in the attacker’s hands.
Deliberately altering a URL to test for a flaw might be considered unauthorized system access.
Maybe warn off readers from playing security consultant, if they’re not backed by journalist protections or a good lawyer.
I’m glad things got fixed and this customer wasn’t hassled, but this could’ve turned out ugly.
Accidental duplicate comment.
I rephrased it below.
Tracking a package of jewelry to someone’s door and swiping it off their doorstep is certainly possible, and has precedent. The scarier scenario for me is that criminals scanned historical orders for the most valuable jewelry to harvest addresses of where to break in next. That sends a chill down my spine.
I guess everyone here was the A+ student thru high school and the top 1% of their college classes. Right. Everyone overlooks the obvious, to what extent. There is the part, of he didn’t think of that. Even the best and brightest, may dim from time in the socket. Now,he knows, his next involvement will show if he was a “programmer” or a tool.
How can Scott Lancaster not notice the issue affected past orders? The information presented to him came from a past order, therefore, he must know it affected past orders. His argument is indefensible.
Speaking as someone who works in the field and who’s encountered dozens of vendors with the identical issue – it’s easy to point fingers. As Jeff Sallee commented earlier, the problem is broader. One could easily see the calculus of a developer figuring the effort required to fix future orders is much shorter than fixing it historically, updating all the customers and dealing with their ensuing questions/confusion. Or how could a developer tell their security team that the issues have been resolved and tested when clearly the full scope of the problem wasn’t. In many of my similar examples, most recently with travel agent system a few months ago, there is superficial acknowledgement that this is even a problem and they usually take off just my order off-line. I appreciate Krebs bringing attention to this broader issue.
I’m glad it all worked out for Sheehy and the flaw was fixed.
But it could’ve transpired differently.
He accessed information he wasn’t authorized to have by manipulation of a URL. He wasn’t hired to find this flaw. In some circles, that’s not welcomed behavior.
People should report vulnerabilities through a journalist or a lawyer to avoid having the finger pointed at themselves.
Both great points, and I’ll add there’s not much gray area here – this is considered unauthorized access, specifically brute forcing random (order) numbers. When the Computer Fraud and Abuse Act was amended a few years ago, there was some debate about the inclusion of brute forcing but that’s another thread.
As and someone who didn’t have Krebs behind me, I can relate to this similar quickly situation going the other way.
You are correct! I took a legal risk with this activity. However, the great folks at the EFF agreed to take my case pro bono in the event of legal action.
Dell forced a password reset as well, did say hackers were detected trying to access customer accounts. But failed to say if they succeeded or not. Or possibly Dell wasn’t sure so a password reset was pushed out. I certainly of late have begun to examine how much web foot print I want out there anymore. I don’t know if these companies are to blame for security incompetence or that hackers are that good at their skills.
I’m in the process of designing a custom gift card system for a company. 2^80 possible combinations of card identifiers + 6 digit pins, and a back-end system with plenty of safety measures to complicate all sorts of enumeration attacks and / or direct intrusion. None of these items added materially to the project cost; it was mostly just putting a little bit of extra thought into the design phase.
Is there demonstration of Brandon Sheehy’s findings available?
Are you looking for screenshots? Or just a more in depth explanation?
Both would be helpful. For instance it appears you modified the link sent in the email from Kay. Can you show an example of the result of the existing link and then a modified one? It may be past that point since they fixed it so my second ask would be how it was resolved? Did they ensure authentication was passed before viewing the order? Any details on how they did that? I’m speaking from a very novice level but was just interested – maybe something that would apply to my own infrastructure.