Deconstructing Data Leak incident of Signet Jewelers (parent company of Kay and Jared jewelers)

Protecting the Crown Jewels: Deconstructing Data Leakage in Exotic Environments (Inspiration from Signet — Kay/Jared Jewelers Breach)

Note : The following series of deconstruction/post-mortem is indicative of the security issues similar to the one found in Signet Jewelers infrastructure and first reported by KerbsOnSecurity (https://krebsonsecurity.com/2018/12/jared-kay-jewelers-parent-fixes-data-leak/).
While they follow similar patterns, they are in no way definitive of the exact same security incident that occurred in relation to Signet Jewelers. The incident is currently under investigation.

Earlier this month, Dallas-based Web designer Brandon Sheehy discovered a dead-simple vulnerability on the website for Jared jewelers in course of his purchase process. After his transaction was successfully completed, he received a purchase order confirmation email from the vendor. Brandon observed a link embedded in the email which reverted him back to the website with details of his purchase order encompassing

1. Name,
2. Billing and shipping addresses,
3. Phone number,
4. Email address,
5. Items,
6. Amount purchased,
7. Delivery date,
8. Tracking link, and the
9. Last four digits of the credit card used

By slightly altering this link and pasting it in his browser, Brandon was able to view orders fulfilled and associated with other customers. As a good citizen, Brandon reported the issue to Signet and thereafter Krebs.

“My first thought was they could track a package of jewelry to someone’s door and swipe it off their doorstep,” Brandon 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.”
 — from PR of KrebsOnSecurity

Scott Lancaster, chief information security officer at Signet has confirmed that the issue has been addressed after KrebsOnSecurity acted as a conduit to express severity of this exposure.

Let us speculatively deconstruct all events that led to this situation.

1. Customer browses items on Etailer website
2. Customer chooses few items and adds to basket
3. Customer then proceeds to “pay for items”
4. Etailer redirects customer to SignIn/Register in order to authenticate and establish secure session
5. Customer SignsIn , proceeds to payment and completes transaction
6. Customer receives email with details of transaction and in this email is a link that redirects to etailer’s website with order details

Let us expand on (6) and pretend the link embedded in this email looks like http://www.etailerxxx.com/vieworderstatus?orderId=123456

Misstep #1 — Exposing link content without authentication

1. Upon clicking the link, is the customer redirected directly to order details or asked to SignIn/LogIn prior to viewing order details ?
2. [or] Does the link directly lead customer to order details page without SignIn/Authentication?

Majority of etailers expose order details (via an embedded link) without authenticating the user and validating if the order belongs to the specific customer.

Misstep #2 — Predictable sequence

What does the orderId look like ? Is it a INTEGER, UUID, RandomString ?

The backend engineer decided that an INTEGER might be a conducive choice for the following reasons

Choosing orderid (PRIMARY KEY) as a INTEGER column in database renders it to auto increment, be sortable or ordered by sequence.

Misstep #3 — Exposing database sequence in business workflow

Furthermore, by directly using orderid (PRIMARY KEY) in the backend code which in turn embeds it in the email link , the business logic looks simple and easy to maintain

If an orderId is 12345678, it’s easy to guess that there are subsequent orderIds 12345677 and 1234569, and this makes for an attack vector (sequence prediction attack).

Misstep #4 — Randomness not good enough

The backend engineer realizes misstep #2 in design and decides to create random number (breaking sequence) to represent orderId in the database

Engineer creates a patch to depend on

and imports

and uses

randomNumeric(10) –> 1163361204

when creating orders to represent a customer transaction.

http://www.etailerxxx.com/vieworderstatus?orderId=1163361204

Now orderid in embedded link in not predictable (by virtue of sequence prediction). Think so?

“Predictable” is also a tricky word to use in the context of random number generators. Most “random number generators” are more properly described as “pseudo-random sequence generators” (PRNG), and claimed to be predictable in the sense that if you know the algorithm used to generate the sequence, and the internal state of the generator, you know everything you need to know in order to produce the same sequence.

“Entropy” is an interesting concept that is closely related to random number generators since it is generally held to be a measure of “randomness”. In information theory, “entropy” is a direct measurement of the amount of information in a signal — in other words, the minimum number of bits that can possibly be used to encode it.

RandomStringUtils uses as a default source of randomness the Java Random class, which uses a non-cryptographically secure PRNG called a Linear Congruential Generator.

If you skipped your math class, the general idea is that, given some terms of the output of an Linear Congruential Generator, we can determine its internal state. This means that we can (at the very least) predict what numbers it’s going to spit out next. In security terms, this has a lot of serious implications, because of the ways that people use random numbers.

So let’s put ourselves in the mind of the attacker.

We have a way of working out the internal structure of a particular class of random number generator given that the code of RandomStringUtils is open source. Depending on how much of the state of the Linear Congruential Generator, we have, and how much we know about it, we might even need just one number. Anyway, if we have (or can guess) the state of the generator for any “random” sequence generated in this way, we can work the generator forwards as far as we like in order to predict the next orderId.

Remember that a linear congruential generator can be simply described as “multiply by a constant, then add a constant, modulo some number”.

In order to reverse the sequence, then, we’ll need to “subtract a constant, then divide by a constant, modulo some number”. This, as it turns out, is relatively straightforward and gives the attacker access to past orderIds.

Too many missteps on road to remediation

Such applications are often developed quickly with little thought to security.

They are fraught with vulnerabilities, a fair number of which result from — complexity (vulnerabilities by association — use of OSS frameworks, libraries, APIs, etc) and
 — velocity (new feature requests to meet time to market needs)

Operating systems that support such applications deployed on physical hosts, VMs, containers no longer trust them and now defend themselves against existential vulnerabilities in them.

Sandboxing, micro-segementation, behavioral profiling partly fixes the symptom and not the problem.

We at ShiftLeft have devised a technique to analyze 3 essential security properties — input validity, state integrity and logic correctness , lacking which thereof results in manifestation of known and unknown vulnerabilities. Our technique converts source/byte code to a semantic graph consisting of high level information flows from API endpoints to one or more resources (filesystem, databases, other micro-services, etc).

In less then few minutes, our analysis engine identifies area of vulnerabilities with high precision.

Of course, not all vulnerabilities can be fixed by engineers as they are focussed on time-to-market. Armed with information of residual vulnerabilities, ShiftLeft provides an instrumented runtime micro-agent that observes in real time for any attacks applied on these vulnerable paths. If so, we detect , raise a #1 severity alert and also BLOCK this threat from manifesting.

This is done in a continuous loop without compromising DevOps velocity.

Using ShiftLeft platform, we will be able to precisely detect if

1. A specific API endpoint is lacking authentication or authorization (leading to access across tenants in a SaaS platform)
2. A database sequence is exposed to an API endpoint (leading to a sequence prediction attack, if the sequence can be predicted forward or backward)
3. Based on configured policy, verify if SecureRandom is used instead of RandomStringUtils randomNumeric.

If you are interested in evaluating ShiftLeft, please proceed to signup for a free trail at www.shiftleft.io

---

Deconstructing Data Leak incident of Signet Jewelers (parent company of Kay and Jared jewelers) was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/deconstructing-data-leak-incident-of-signet-jewelers-parent-company-of-kay-and-jared-jewelers-44a8d6b881fb?source=rss----86a4f941c7da---4