Defencely USP for Major Finance Brokering Giants! Are you Ready!?

As part of our ongoing efforts to spread cyber security awareness, we’ve taken measures to go an extra mile & bring you rich blog posts about tales & adventures at Defencely Lab. We are going to explain & demonstrate how we chained up critical information to gain access to millions of customer accounts in order to safeguard our valued clientele pro-actively.

Majority of our clienttele are major finance brokering companies & we’d like to add that as the industry is grooming under leadership of real time markets, it’s critical to retain the value accordingly & an online heist would certainly impact as part of financial loss to the growing company.

We are intentionally excluding the names of the target to stick to confidentiality clause which we’ve signed up. At this point, our readers should be able to have an analogy of the steps which are taken & mentioned in this post to get the complete picture of what’s happening.

We have been assigned the same target several times for serious security threats, we have reported some SQL Injection’s and some more serious security threats but the vendor was still not satisfied. This was time to escalate this more and make it more serious.

We started enumerating the target. While the enumeration process was going on, we got hands on a HTTP Service running on a port `8080`.

This was not any white-box – Pentest, we were not having any test credentials to check out the application. We don’t want to miss anything out this time, so we checked if these login parameter’s were properly sanitized. I tried breaking the Query – No errors thrown.

We were sure that this is a Time based Blind SQL Injection. We made the application sleep(20) for 20 seconds. Not wasting much of our time thrown the same to SQLMap. Exploitation process was quite slow, even after increasing the threads.

The application was built under ASP.NET framework – most probably written in C# with DBMS used was MSSQL. If you have used SQLMap before, you already know there’s a flag used for gaining os-shell if requirements meets & depending on the DBMS detected.

We gave this a try – this flag in SQLMap checked if the xp_cmdshell is enabled on the target system and luckily our target was having that enabled. SQLMap promoted us with this screen:

We were happy that we gained a not-a-proper shell but at least have command execution in there this time ..

As this is a Windows System .. i executed the some commands to make sure everything is working fine .. but the problem was no standard output was thrown our side. So were not able verify if everything is working that side and the commands are actually getting executed.

To make sure if the commands are getting executed i started capturing the ICMP packets on my side and tried pinging from the target system.

 

Pinging our system from the target

Capturing the ICMP packets on our side:

We received several requests from a specific IP. Including an Web Address on the headers.

We opened up the website and it was of an ISP. Our target was at the TOP of their client list.

Now it was time to get a proper shell on the target. We were not sure if powershell was present there on the target. Simply typed powershell.exe on the os-shell prompt and it was a long delay and did a exit from the prompt. What we did is, created a file name ‘def.txt’ on our local and started the inbuilt Python HTTP Server and tried downloading the file on the target’s machine using powershell ..

We can see, it actually tried downloading the file from our created HTTP Server ..

Tried downloading netcat on the target machine to initiate a connection between both the target and my system. But there was some kind of firewall dropping my netcat connection every time i connect to the target ..

But a simple MSF reverse TCP did the work ..

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@defencely.com, Shritam Bhowmick, Red Team Lead @Defencely for any Security Operations Related queries or say “Hi” to us at hi@defencely.com 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.

 

How Chaining Of Attack Vectors Gave Defencely an Upper Hand in Pentests!?

Howdy,

Today as part of our ongoing efforts to spread cyber security awareness, we’ve taken measures to go an extra mile & bring you rich blog posts about tales & adventures at Defencely Lab. We are going to explain & demonstrate how we chained up critical information to gain access to millions of customer accounts in order to safeguard our valued clientele pro-actively.

We are intentionally excluding the names of the target to stick to confidentiality clause which we’ve signed up. At this point, our readers should be able to have an analogy of the steps which are taken & mentioned in this post to get the complete picture of what’s happening.

CONTENTS

  1. Understanding the workflow of the Application.
  2. Technical Understanding.
  3. Chaining up and Exploiting the vulnerability on the basis of Collected information.

WORKFLOW

Our target had an Android Application as well as a Web Application giving ourselves a wide scope to start enumerating and having a general idea of how their applications were working at the back-end, we look our own research time to be spend wisely before we actually started to hit the targets.

Working of the Web Application: This web application allows anyone to Sign Up for their services hosted on a particular sub-domain say example.target.com. And once you’re signed up as a normal user with the company you can upload your details and information related to you on the account to set it up according to the services offered.

Working of the Android Application: This Android Application is of their Partners Portal. The Android Application was more interesting as this Application doesn’t allows everyone to sign up as a Partner, You need to verify yourself as a legitimate person having skills on the works they offer & submitting documents related to the work they are offering. We reverse engineered the APK file & The only thing which were similar between the Web App & the Android App was both their APIs which were connecting to the same domain but having different endpoints.

So, this was going really interesting as we do not have access to any of their test credentials for the Partner’s Android App to test their API endpoints. We were only left with the reverse engineered files & codes on the desk. Now we have a basic idea about how things were working, let us jump into the technical understanding of the application and lets understand how we escalated this from having nothing to compromising millions of their accounts registered with the company.

TECHNICAL UNDERSTANDING 

If you want to register yourself as a Partner you need to call them on a given number on the website to their 24 * 7 available customer support and can provide details they needed to verify yourself as a legitimate partner.

So, what would you have done if you were at the same scenario we were? It’s obvious. We called them up & social engineered them to make them believe that we want to sign up as a partner and provided some legit looking details which were actually dummy details created at our end. The verification process was over, everything went fine. But they informed us that they will take couple of days to provide us the credentials to partner portal. We know we have deadlines, 2-3 days was a long time and we can’t afford wasting time on just registering a account on their partner’s portal.

If you remember we already have reversed engineered the APK file. So we went that way. We started looking into the huge source codes available.

We were looking through the directory structures and found some susceptible files where we can now at least concentrate into.

Above are the files we were specifically looking into. We started reading the codes of the ISignIn.java  file. And within a couple of minutes we found something really interesting which took our attention and made everything clear about the Login mechanisms they were using and how they were Saving passwords to the databases at the back-end.

Lets look at the code and understand the mechanism.

Vulnerable Code which could allow us to take over Partner Accounts: 

@FormUrlEncoded
@POST("/ppapp/savepassword")
void getSavePassword(@Field("mobile") String str, @Field("password") String str2, @Field("confirmPassword") String str3, Callback<OTPModel> callback);

This particular function took our attention which were sending some form-collected data into the POST parameters to the endpoint /ppapp/savepassword. I was pretty sure the developers were using this function to set new passwords for the users.

But here the question arises. How we are going to exploit this vulnerability? If we look into the function, we can see the function getSavePassword takes three functions parameters in.

getSavePassword(@Field("mobile") String str, @Field("password") String str2, @Field("confirmPassword")

  1. `mobile` parameter
  2. `password` parameter
  3. `confirmPassword` parameter

We need to full fill the need of supplying three parameters to the function to make the request happen. You might have noticed they are changing the password of users putting mobile phone number as their uniquely identified kind a`key`.

The first priority here is we need to have a mobile number already registered with the company. And to full fill the need we started enumerating other files which might throw us some more details regarding users already registered.

While enumerating other files, we found another endpoint which seems to be related with the customer profile details or vice versa.

We started searching where and how this endpoint @GET("/getprofilejson") is working by looking at the source codes left with us.

We found that the endpoint @GET("/getprofilejson") is working with two HTTP GET parameters.

  1. `uri`
  2. `consumerId`

Enumerating the source codes more and more gave us the values which were fitting into these two parameters. The `uri` parameter is taking a `location` which in my case was %2Feast%2Fassam%2Fbongaigaon%2F and `consumerId` was of 6 digit integer value, so i just passed a random 6 digit integer value ‘123456’ But nothing happened.

I wrote a python script to bruteforce the `consumerId`.

The API endpoint was throwing data’s at ‘391149’ which holds a token value for ‘example_profile_id’ and meant to be supplied as HTTP POST  parameter on the endpoint @GET("/getprofilejson") as "example_profile_id=82f088332d0611e484950e2f866a9102" to get hold on the registered customer profile details.

Our goals are achieved. Now we have a registered customer’s phone number. It’s time to code a exploit and make it happen. Lets jump into the last section of exploitation.

 

EXPLOITING THE VULNERABILITY

A coded up exploit to account take over.

Response:

We finally coded a mass account take over exploit where the script grabs user’s phone number bruteforcing the `consumerId` and passing the token value retrieved from the response to get phone numbers of the users and finally the invoking the  @POST("/ppapp/savepassword") endpoint to directly changing the password.

 

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@defencely.com, Shritam Bhowmick, Red Team Lead @Defencely for any Security Operations Related queries or say “Hi” to us at hi@defencely.com 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.

Defencely Clarifies Python Object Injection Exploitation

 

Readers,

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 & for Global Enterprises.

Today at Defencely Lab we are going to explain & demonstrate the Python Object Injection attack in minute details. The whole demonstration will be done with our coded intended vulnerable Application & Exploit which you can find at this Link –  Github – Python Object Injection

Contents – 

  • Introduction to Python Classes and Objects.
  • What is an Object Injection?
  • Detecting an Object Injection Attack.
  • Understanding the workflow of a Vulnerable Application.
  • Coding our own exploit against the intended Vulnerable Application.

Prerequisite – 

  • Basic Understanding on OOP Concepts.

Introduction to Python Classes and Objects.

 

What are Classes?

Class is basically a template where you store your variables & methods.

What are Objects?

Objects can be Anything, an instance of a class, a variable or a function in a class.

 

Lets go into the practical examples :-

Here you can see we have created an instance of the class named Test, and assigned the same to a variable named simpleapp passing the value of the variable rony to the Instance.

Output –

“ simpleapp = Test(rony) ”

When this particular code is executed python creates an object and then we are passing our value to the first parameter. Whenever python creates an object the __init__ function gets invoked. __init__ works like a constructor in python.

The random things which got printed with our output it’s because We are directly printing out the instance assigned variable to show how python is treating this as an object.

What is an Object Injection?

Object Injection is an Application Level Security Vulnerability that could allow an attacker to perform critical level attacks depending on the context.

Python specifically have its native module named as “Pickle” which is vulnerable to Object Injection on particular scenarios.

Python already lists pickle as risky module on their official documentation when user controlled data is passed.

We can compare the module “Pickle” with the serialize/unserialize() native functions in PHP which is also vulnerable to Object Injection when user inputs are supplied.

In Python we don’t need a magic methods as a condition to Inject into the Objects Unlike PHP.

Serializing and Deserializing in python is just Pickling and Unpickling of data.

Unpickling of data is NOT necessarily dangerous in Python until and unless user input data are passed to the process of Unpickling.

This is how Pickled and Unpickled data looks like in python –

 

Detecting an Object Injection Attack 

To achieve an Object injection, you have to do a white-box Pentest on a application. Because whenever you are pickling on complex Objects the serialized data in Python comes with the name of the class, variables & their values.

The Pickle module offers us four methods for easy and fast pickling/Unpickling.

  • dump()
  • dumps()
  • load()
  • loads()

You can find their respective functioning in Python’s Official Documentation.

As I already mentioned Unpickling of data is NOT necessarily dangerous, but If you are handling user inputs where in the backend you are pickling and unpickling the user inputted data that’s where the risk comes in. I quote – “Never Trust User Inputs”.

If the data supplied is user controlled it can obviously get tampered.

So, if you see pickled data is passing through any HTTP method, there might be a possibility of Object Injection.

 

Understanding the workflow of a Vulnerable Application

Filename: pickle.py

We will be studying the above code and tweak this accordingly to achieve an object injection.

Ignore everything else written on the code above let’s concentrate on the three things.

  • The user input which is the arg variable in this case.
  • The final_workout() method inside the class simpleApp which interestingly runs a python file.
  • The method which is called app.secureaApp() which is unpickling the inputted data.

Now lets dive deep and lets understand what role does these methods are playing.

The secureApp() method in the simpleApp() class

I am assuming that you probably have read the Python Official Documentation which i have already linked above & know the in’s and out’s of the methods used in this particular post by now.

Methods

  1. dump()
  2. dumps()
  3. load()
  4. loads()

What this secureApp() method is doing is taking a filename as an argument. Unpickling the data from the file using the load() method from the pickle module and assigning the value means the unpickled data to the variable workDone. Which is later on taken as an argument by the final_workout() method.

Let’s see what’s there on the final_workout() method.

The final_workout() method in the simpleApp() class –

This method creates a python file named code.py writes the unpickled data into the file and runs it. Simple right?

Let’s see how it looks like when we run our main vulnerable application pickle.py with the already generated serialized data.

As we can see it prints out the content from the serialized data and runs it successfully which prints out the string.

We will learn, crafting our own serialized data to do a successful object injection on the same application.

 

 

Coding our own Exploit

We now know that the pickle.py is working with the serialized data, so to serialize and making our own crafted payload we will be using the dumps() method to pickle our payloads.

And here is our final exploit to have our own serialized payload data which you can also found on the shared Github Link.

Filename:- exploit_pickle.py

 

We are going to serialize a piece of code which includes system commands with the exploit coded and test it if it works.

And we are now able to Successfully inject our own crafted codes.

I hope this will be a tremendous insight for such vulnerabilities which are well hidden in heap of crafted Enterprise Code & we are hoping to continue providing excellent security services for all kind of business houses & the enterprises in an absolute integrity.

This is Rony Das from Defencely Cloud Security Pvt. Ltd. & join you next week on Defencely Blog with more such highlights whereby our Defencely Lab exploitation goes beyond all measurements bypassing all kinds of security walls.

Thank you & have an excellent day ahead.

 

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:

api01.example.com/api/rest/v1/?customerId=89892381

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.

Exploitation

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@defencely.com, Shritam Bhowmick, Red Team Lead @Defencely for any Security Operations Related queries or say “Hi” to us at hi@defencely.com 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.