Deconstructing Data Leak incident of Signet Jewelers (parent company of Kay and ...

Credits: MichealHill

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

Name, Billing and shipping addresses, Phone number, Email address, Items, Amount purchased, Delivery date, Tracking link, and the 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.

Customer browses items on Etailer website Customer chooses few items and adds to basket Customer then proceeds to “pay for items” Etailer redirects customer to SignIn/Register in order to authenticate and establish secure session Customer SignsIn, proceeds to payment and completes transaction 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

Upon clicking the link, is the customer redirected directly to order details or asked to SignIn/LogIn prior to viewing order details? [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 businessworkflow

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 goodenough

Credit: bbc.com

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.

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