Defencely Red Team were able to Compromise Half Million Indian E-commerce Data!? How?

Welcome to Defencely Blog, This is Rony, part of the Red Teaming Operations Associate at Defencely Cloud Security Pvt. Ltd. & we are extremely delighted to present scenarios of exploitation of a recently conducted security operations for prestigious organizations in India & Abroad. This will be the same scenario which we faced while doing a security inspection on an extremely high profile target & is likely to repeat for most other organizations.

We are excluding the names of the actual target and will be demonstrating the same on a demo application which is intentionally coded for achieving the exact same scenario in order to reflect most grave mistakes developers have been making. It’s our part & parcel to make the Indian E-Commerce aware of the risks which it comes surrounded with & how compliance’s could not be met due to these potential risk factors which if immediately not resolved – would be liable & answerable to investor deck.

You can find the demo application which will be used for the demonstration on this Github Repository.

Let’s get started,

Contents – 

  • WorkFlow
  • Technical Understanding
  • Exploiting

WorkFlow – 

Basically our target had an Android Application which at this point is very susceptible to most insecure API Security Practices. Most of the Android Applications which deals with huge customer data uses APIs (Application Programming Interfaces) to make their tasks easy. And this makes it much easier to tamper things out when your API calls are done without any authentication services or let’s put as it is even with an authenticated services, there are other risks in the authentication mechanism itself. That’s where our Ops Team started enumerating.

An attacker has to be well versed & very well aware of having dealt with programming languages to build any GUI Desktop app, iOS app or any Android app to considerably know  the in’s & out’s of Event Listeners and Handlers. What this does is, detects your touch and clicks to collect data according to the invoked functions and then sends it via APIs and receive the output in the same way.

In our special scenario, there was a List of menu which were used for different tasks, our ops team started clicking on all the menus at the moment & ended with a menu named “Profile”. While intercepting the requests our testers came across an URL which was requested by the Application & that’s exactly where the target started getting interesting.

In order for our readers to understand this better, lets jump into the Technical Details.

Technical Details

NoteFurther explanation and demonstration will done using the coded example application. These details are for minute level of understanding which is very needed.

The URL looked similar to as below at the time when the application were tested for security violations:

Defencely Red Team ops hit open the URL on our customized browser look at the rendered output which we’re surprised to have a look into:

The URL was throwing the results as JSON parsed format and the same fetched out credentials which one could see in the screenshot as well above.  Please remember, this is a sample coded application & not the real details or any of it. The rendered output were every customers profile details which are extremely sensitive in nature such as their Email, Phone Number, First Name & Last Name. These details could be later used for social engineering attacks & more targeted attacks on a particular customer if it needed to be.

The most basic flaw was the API was taking inputs directly without any validations in place or a mechanism put forward for any such authorization which should had been needed in the first place. Our Red Team Ops concluded that their could be an instance of “Unauthorized API Service Calls” which would really look like an Insecure Direct Object References on OWASP Top 10 Chart.

What if an attacker can enumerate all the customer id’s & then frame a very particular script to obtain all those records given that the parameter was vulnerable to insecure direct object references given that this time an API Service calls were in place!? We replaced the integer values to determine if such changes are rendered as per our hope & voila!

At this point our Red Team Associates & security professionals were clear there were no authorization service in place due to the lack of which validation failed to check if such a service request calls should be allowed in an insecure way to gain an insecure direct object reference attack.

This meant the API were identifying their users using a Uniquely identified key, in this case it’s “customer_Id”. That’s a very real problem with the Enterprises. There were no mapping which had authorization in place for such an API call. We’re sure, many large scale enterprises are equally open to such attacks & their reputation clings on a tolls way after an investigation from compliance team given that the compliance team is enough aggressively capable of checking routinely on rampage a single unclosed vulnerability might cost.

Defencely was able to code a script to know exact numbers of registered users, this script can be found at Simple Python Script to guess the range.

Now let’s simplify the exploitation process.


Defencely created another Python Script for the Proof of Concept showing to the company & to simplify the attack as well in order to demonstrate the grave concern to senior managers & the management team which quickly later reacted to it’s closure of the threat uncovered by the Red Team Operations.


Taking out users credentials, remember these same credentials could be harvested & mounted to their social account profiles as most of the time, credentials will always be the same for a victim:


That’s all we have for now. Let’s look forward to more amazement at Defencely Red Team Operations Labs next week for absolutely yet another amazing uncover story of how we’re adding value to our customerbase with insider threat program as well as routine sound-ful & an offensive Vulnerability Assessment followed by a Penetration Test for critical applications both at the staging level & production bases. Our manual security assessments methods have proved the best value. Feel free to touchbase at, Shritam Bhowmick, Red Team Lead @Defencely for any Security Operations Related queries or say “Hi” to us at for inquiries.

We should see you again next week with another operational tale of the broad security premises where 0days are always a possibility & at proximity of a security compliance issue which always will be a sooner or later decision by the Indian E-Commerce Management & stakeholders.

Let’s act pro-actively.

Achieving Code Injection on Trendy –

Hello Readers,

Welcome to Defencely, I’m Rony, part of the red teaming operations at Defencely Cloud Security Pvt. Ltd. & we conduct security operations for prestigious organizations in India & Abroad. We would like to throw security concerns related to a trending application named ‘Sarahah’ & I hope my viewers would love this detailed security inspection of the application & learn from developers mistakes.

We have kept the content very specific & simple to understand for your viewers as we understand our efforts to achieve a continuous conscious security are necessary to help developers fix their security loopholes timely. Defencely has already reported the Code Injection concern to the developers with a proper timeline & as per it’s policy of a full disclosure.

We’re yet awaiting for a fix which has expired since then. In order to help users, we’re attempting at a full disclosure.

Contents – 

  • Application Overview.
  • The Workflow.
  • Exploiting the Trend.

Application Overview –

What is Sarahah?

Sarahah is an application, which let you help get feedbacks anonymously from your friends and coworkers. Atleast that’s what Sarahah says & plans to extend the features.

How it works?

First of all, Sarahah would let you register to their website, and once done Sarahah offers you a personal dashboard with a link with your name which you can share in Social networks and you will receive anonymous feedbacks.

As a Penetration Tester, Before attempting any exploitation into the target one needs to enumerate very well in order for a quality assessment. So here comes a Technical Understanding of the Application.

The WorkFlow –

Everything starts after we sign up for Let’s understand the WorkFlow from the point of view of a Penetration Tester. 

As a Penetration Tester, one needs to know Users inputs can take you from zero to a successful security audit real quick.

That’s where we started fuzzing around the user inputs, which is basically in this case are your friends and co-workers who will be sending you anonymous feedbacks & this nature isn’t possible if the application was not allowing taking inputs from the audience.

  1. You are creating a account.
  2. Your friends are sending you feedbacks through a form publicly available.
  3. The feedbacks are getting displayed in your dashboard.
  4. Which means the Feedbacks are getting saved to the database and later on echo’ed off to your dashboard.

What if Sarahah is not sanitizing the user inputs? Can we initiate code injections

Exploit the Trend –

We sent a simple and classic snippet of JavaScript code to my own dashboard.

Payload:  <script>alert("Hello, Vulnerable!");</script>


This Javascript code should pop-up a ‘Alert Box’ into the user’s dashboard. Let’s check if we got a Popup?
Sarahah 2

Nope, we didn’t got any pop-up right? The code we tried injecting to the application, just echos off back to dashboard rather than getting injected right?

So what we did is, We enumerated around the application & noted an AJAX request going into the server and calling the next contents in JSON format and parses them back to the dashboard which means we have got our second attack surface.

One can look at our payload in the JSON Request:
JSON req

But there’s a twist. The event gets called every time when you scroll down,  then an AJAX request is made through the URL,″

and then the Contents from JSON result gets parsed and echos off them back to the dashboard.

Sarahah Developers messed up when they are parsing contents from the JSON result, and that is the point they are not filtrating the special characters anymore.

So how we are going to trigger the XSS?

  1. The first thing you need to keep in mind that, you need to make the user scroll down so that AJAX request is made.
  2. Send the payload to user.
  3. And then flood the users dashboard with some random messages(Approximately around 20-30). This is how you will make the user scroll down to see the messages where your payload is included too.
  4. Once the user scrolls down, the AJAX request is made, all the contents of the next page gets parsed(which includes your XSS payload) and Sarahah echos them back to the dashboard.


Your XSS gets immediately triggered –

This pop-up “Hello, You got hacked” will keep poping into the user’s dashboard until and unless the user deletes that particular feedback.

Here an attacker can easily irritate the users just by changing their payload to something  –




alert(“You are getting hacked!”)



This is a continuous loop, because 1 is always true. Hence the pop-up will be continuous. We recommend Sarahah Developer to fix this nature & have already attempted sending them the cure for the itch.