Web Application Pentesting Methodology-Part 2 (Client-side vulnerabilities)

Ninad Mathpati — Tue, 08 Oct 2019 14:07:18 +0000

Hello Guys, took a bit long, but as I said here is the 2nd part of web application pen-testing methodology.

Before going for client-side vulnerabilities, I would like to describe how a browser works briefly!

So basically whats the definition of a web browser?

Something that helps in opening Facebook, youtube etc. is it just that? It’s an application which can be used to fetch or access information from the world wide web.

How does a browser work?

The browser has 3 main components

Browser user interface
browser engine
rendering engine

Browser user interface:

BUI is a method of connecting to an application by using the browser’s functionalities such as forward button, back button, proxy, URL bar,…etc.

Browser engine:

It acts as an intermediate to UI and rendering engine it collects all the inputs and data from the user interface and queries it to the rendering engine.

Rendering engine:

The rendering engine is something which processes the request web page according to the data. Here is the main process where everything works, this engine renders that HTML, XML..etc. Data to generate the display layout.

Browser Workflow

This was a short description of how a browser works, If you want to go more in detail you can go through the blog of Monica raghuwanshi.

Now moving on to the client-side vulnerabilities!

Client-side vulnerabilities are the major problems on the UI workflow, such as client-side data validation bypass, failed to add proper header leading to clickjacking…etc.

Some major client-side vulnerabilities are,

Testing for XSS
Testing for IDOR
Testing for CSRF
Testing for Javascript validation bypass
Testing for HTML Injection
Testing for Clickjacking
Testing for Cross-Origin Resource Sharing
Testing Client-Side Storage
Testing for Insecure URL redirects
…etc,

NOTE:- I would be not describing the definitions of this test cases in details; rather I would prefer providing you with a practical example on each of them.

Testing for XSS(Cross-Site Scripting)

As almost everyone knows there are 3 types of XSS

Reflected XSS
Stored XSS
Dom XSS

Now if we go for reflected XSS, We can describe it as,

let’s take an example, suppose an e-commerce website is there, and there is a search bar to search for the required things, suppose you enter a malicious payload instead of any product name, like

This will alert pop up with the domain name, in the same way, the attacker can steal user cookies, which may lead to account takeover.

This was a short description of the reflected XSS, now let’s move forward with stored XSS,

Here, in this case, suppose you have a signup form, and it is implemented so that when the user signups with the defined credentials. The username is getting reflected on the home page (after login). so here the attacker might make a username with a malicious payload such as

;

When the desired user logins through the application a pop up will appear in front of him showing the domain name. This type of scenarios is called stored XSS, where the entered field id is getting stored in the DB without validation. Thus leading to stored cross-site attacks.

Blind XSS is a variant of persistent/stored XSS vulnerability. They occur when the attacker input is saved by the web server and executed as a malicious script in another part of the application or another application. For example, Let’s suppose there’s a cryptocurrency trading related website, where it asks for identity verification before moving forward and creating/importing our wallet, while verification it asks for name, id no, and snap of id, we can use the blind XSS payload here in the mane field and try to get our malicious script executed by the admin. In contrast, he tries to verify our data. There are many other scenarios where we can find Blind Xss some of them are,

Contact/Feedback pages
Log viewers
Exception handlers
Chat applications / forums
Customer ticket applications
Web Application Firewalls
Any application that requires user moderation

If you want to test for Blind XSS here are the best tools as of me,

XSS Hunter (The Best tool for Blind XSS).
Xless (A best tool with slack notification)
bXSS (Has slack/SMS notification feature)
KNOXSS (has email feature)
Burp Collaborator
ezXSS (has 2FA, email reports, share reports feature)

Now the most difficult type of XSS is DOM-based XSS.

Here, suppose there’s a big application it has a lot of data stored in it. There will be a search bar to search for any information, so what we do is we enter a malicious payload like “/> instead of searching anything, but to the surprise what is see is as soon as I enter(only entered not clicked enter) this payload I m getting a pop-up, why this is happening?

It is because, in the backend, the query given by the user is being directly getting executed instantly, so the pop up appeared. This is what a dom based XSS is, it’s an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client-side script so that the client-side code runs in an “unexpected” manner.

These are just the simple example where there was no security implemented for XSS attack, but there are many instances where you need to bypass the validation or WAF some of the tricks to bypass the waf are given below,

Kona WAF (Akamai) Bypass:

 \');confirm(1);//

ModSecurity WAF Bypass:

Incapsula WAF Bypasses:

Wordfence XSS Bypasses:

>"
>>

Thanks to EdOverflow and other researchers who believe in Sharing the knowledge for the above details.

Here’s another reference for different types of WAF bypass.

Testing for Insecure Direct Object Reference (IDOR)

This is a type of vulnerability in which the attacker can fetch any user’s information, Suppose there is an HR management tool in your company and when you log in to it, the URL appears to be such as

https://www.xyzcompany.com/hrms/user_id=1234

Now if we change the user_id parameter value to something else, we get another employee’s information. Thus this shows that the given application is vulnerable to Insecure Direct Object Reference Attack.

Looks simple right this, but this might lead to a complete company’s data loss, theft, and manipulation.

Here is the example of it where I was able to delete company whole DB at once using IDOR,

https://ninadmathpati.com/how-critical-is-idor-vulnerability-can-it-take-down-a-whole-company/

Testing for Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is a type of attack in which the attacker can perform malicious activities in the user’s account without his knowledge. But to make this attack critical, the user’s interaction is needed, or we need a session id of the user. Only this attack is possible. For example, CSRF can suppose an email change option on my profile page, where there is no kind of verification done. In contrast, the email is changed, so the attacker can generate a CSRF request to change the account’s email. Thus after this, the only thing we need is user’s interaction, if the user clicks on the malicious link the email of the victim’s account is changed and then the attacker can go in a normal way to reset the password and request a password reset.

So here we can describe the impact as Business-critical as we can completely take over the account.

Another scenario can be like, suppose there’s an e-commerce website and we know that any security measures for CSRF attack are not implemented there. So suppose the victim has added something to the cart, what an attacker can do is generate a CSRF request to add the desired item to the victim’s cart, once it’s generated then and if the victims click on the link and proceed with the cart payment. Thus the attacker can order anything for him through anybody.

These were some attack scenarios of CSRF,

What’s the best way to check if CSRF security measure is implemented or not just give a check on the request part for CSRF token if it’s implemented then chances are there that the company has implemented CSRF security measure

Testing for Javascript validation bypass

Javascript validation bypass, we can call is as client-side validation bypass too, what happens here, in this case, suppose a developer has implemented a feature in my profile page that the user cannot change the user-id of the account, once it’s generated, so as shown in the below fig. the developer has implemented client-side security measure so the user cannot edit the email field, when we give a check at the inspect element there we can see that field is disabled to make changes,

Client-Side Bypass

If we change it to enabled or remove it and process the request to change the email-id and if email-id gets changed, we can say it as this is a javascript validation bypass, this was a basic scenario of this attack. There is a lot of another scenario where we can change the email id of the account or perform an XSS attack, such as, let us say there a username filed on my profile page where the developer has implemented client-side security measure that we cannot use any symbols like (><\/;'”..etc.) so here the attacker can type any name in the username field and process the request and intercept it with burp suite, there the attacker can go and change the username field and add any malicious script and forward the request, thus bypassing client-side validation here and performing an XSS attack.

Testing for HTML Injection

This attack is a lot similar to an XSS attack, but here the impact is different than that of XSS attack, In XSS attack the attacker aims to steal the session id whereas here the attacker tries to deface the website. In general, we can say in XSS we use script tags, whereas, in the HTML injection, we use HTML tags to exploit, of course, we can use any tags to exploit both the vulnerabilities.

Here the attack scenario can be like suppose there’s an internal application of a company product where on the home page it’s showing the details of the work done in a flow chart or any diagrammatic representation, there is a field where this data is stored and showed on the home page, Now suppose while entering the data what if the attacker succeeds to add iframe tag in that desired field. The result will be if the page is vulnerable to HTML injection, we will be able to see an iframe on the home page, thus leading to defacement of the website.

But my suggestion is if there’s HTML injection possible there are more chances that there might be an XSS attack also possible.

Testing for Clickjacking

Clickjacking is a type of vulnerability in which the attacker tries to impersonate a site and steal the user’s clicks on that website. This attack can lead to download malware, visit malicious web pages, provide credentials or sensitive information, transfer money, purchase products online..etc.

Here is the perfect example of an exploit which I found on Imperva

The attacker creates an attractive page which promises to give the user a free trip to Tahiti.
In the background the attacker checks if the user is logged into his banking site and loads the screen that enables the transfer of funds, using query parameters to insert the attacker’s bank details into the form.
The bank transfer page is displayed in an invisible iframe above the gift page. The “Confirm Transfer” button exactly aligned over the “Receive Gift” button visible to the user.
The user visits the page and clicks the “Book My Free Trip” button.
In reality, the user is clicking on the invisible iframe and has clicked the “Confirm Transfer” button. Funds are transferred to the attacker.
The user is redirected to a page with information about the gift (not knowing what happened in the background).

This was one scenario of bank transfer the attacker can steal user’s credentials too by this attack like we can carry out the same attack. Still, for social networking websites, we can post anything from the victim’s account. By this, I guess the impact of clickjacking must be clear if not then you can refer the below two links

Clickjacking in Google worth 14981.7$

Clickjacking on Google MyAccount Worth 7,500$

The easy way to check if the security measure for clickjacking is implemented or not is by looking for X-FRAME header or CSP header’s

Testing for Cross-Origin Resource Sharing

CORS is a vulnerability where the attacker can steal sensitive data of the user such as Payment info, messages, email id, contact no, depending on the application of any type of sensitive information.

I would like to share a bit more about this as this is one of the high-level vulnerabilities, so basically CORS is all about the resource sharing in between two sites, as we know

“It is very important that JavaScript that is running on one domain can only read data from that very domain”

If we want to fetch any information from other services, we will use Cross-origin Resource sharing.

So how do look for it?

Check the request part if any origin header is included then you can try to cors there. CORS is often implemented but not configured properly; the domains should be properly filtered.

How do we exploit it?

we can use Curl to exploit and check if you could succeed.

Curl command: curl https://www.edmodo.com -H “Origin: https://evil.com“

-H: Header

-I: Fetch the HTTP-header only

Testing Client-Side Storage

Testing for the client-side database is basically an information disclosure vulnerability. If you give a check through inspect element, in your browsers for Local storage you would find some information, this local storage works using the setItem and getItem functions. So if the attacker finds an XSS in the domain, then he can easily fetch the information stored in the local storage. The severity of the information might vary form-critical to a low level, but we know that we can find something in the local storage. So this testing is also essential while doing a penetration test for a web application.

Web-Sql

You can look here for more info about this topic here

Testing for Insecure URL redirects

A URL redirect is a vulnerability where the attacker able to redirect the victim to a malicious website hosted by the attacker. in this case, there are many ways where we can redirect the victim to the evil page the basic technique is suppose you have a vulnerable link such as

http://www.target.site?#redirect=www.target1.in

here the attacker can easily change the URL as http://www.target.site?#redirect=www.fake-target.site

and forward it to the victim and carry out an attack, but nowadays this URL redirects are very much secure, some ways to bypass this security measure are like using CRLF(%0d%0a) injection, template injection, parameter pollution..etc

All the injection part I will be discussing in the server-side testing blog.

So Alas, I hope this would be helpful to both professional and aspiring web application pen-testers. I hope you enjoyed reading this.

In the next blog, I will be covering the server-side vulnerabilities, feel free to reach out to me.

Hope you like it,

Till then, Happy Hacking

How I was able to earn 1000$ with just 10 minutes of bug bounty?
Ninad Mathpati — Fri, 16 Aug 2019 21:34:08 +0000

Hello, Guys, I m back with a new blog on bug bounty, I found this bug recently on independent bug bounty program, thought of sharing it.

So here I would like to share how I got 1000$ with just 10 minutes of bug hunting,

here you will get to know the importance of client-side vulnerabilities,

So here’s how it went on, earlier during my engineering 4th year, I had too much free time. This was the time I learnt a lot about this field, That time my daily schedule was like,

Eat-> Sleep -> Bug Hunting -> Repeat

A few months back, I thought to let’s give it a try so I just picked a random website lets to say asdf.com

Now, asdf.com is a cryptocurrency exchange website, and in a general way I tried to scan the website while doing the testing I came across the login page and got to know that we can create an account and so after creating the account I found out a place where we could request for password reset for our account. On the login page there was an option of reset password so just to give it a check I requested for my password reset through that reset option, The forgot password link was something like this,

www.asdf.com/resetpsswd/email=hacker2202@asdf.com&token=aknajdnskvbskfv34tr34nj3rrff33grjqw

Here if you notice, there’s and email change option. I tried changing the email address and checking the link and what a stroke of luck it was just 5 minutes of testing I got the bug, but after changing the email I was not able to change the password as the site has 2-factor authentication implemented.

As the 2-factor authentication was implemented I thought we cannot do anything of it now as altering the email doesn’t work, but suddenly I saw a mail-in my altered email inbox it was from the asdf.com it was like,

I got a new reset password link of that account to my altered email address.

So what was happening was

when we are requesting a password reset for our account we were getting a mail and that reset password link had token expiration vulnerability ( it was not expiring the token after one use)

2nd the problem was when I was altering the email and processing the link I was able to get a new reset link to my altered email address of the victim’s account (not exactly same but something like Http pollution attack)

So in this way, I was able to earn good, client-side attacks also pay very well if we show the attack scenario properly.

What might be the fix for this type of issues?

Token Verification & Expiration.
Avoiding unnecessary Parameters Like Email
Implementation of 2 Factor-Authentication.
Most importantly checking the workflow of that section

This was just an example for client-side attack I will be discussing in detail about client-side attacks in my further blogs (Will publish it soon)

“So Next time you see any parameter try to play with it who knows you might get lucky and get some bucks added to your account”

This blog I have only made for the specific findings only, Do Subscribe to my blog if you find it useful!!!

Hint for the next blog: Is it possible to hijack a browser through XSS?

Web Application PenTesting Part 1 (Methodology)
Ninad Mathpati — Sun, 30 Jun 2019 09:58:16 +0000

Hello Guys, Ninad here I hope you are doing good, so today’s topic is How to start with web application pen-testing. I would be dividing this Web Application Pentesting into 3 parts,

Part 1) Methodology.
Part 2) Client-side attacks.
Part 3) Server-side attacks.

In Part 1 Methodology, I would be Sharing my knowledge with you about How to start with Web Application pen-testing?
In Part 2 Client-side attacks, I would go in detail for client-side attacks like How to attack? How to mitigate? What are the client side attacks?
In Part 3 Server-side attacks, I would go in detail for Server-side attacks like How to attack? How to mitigate? What are the client side attacks? What is the attack scenario’s ..etc.

So Generally, What is Pen-testing?
As of me,

It’s a practice implemented to mitigate security threats in any domain

Here we are going to discuss Web Application Pen-testing, There’s one point which I would like to make it clear that web application pen-testing is totally different than bug bounties. So Don’t get confused with it.

How to Start Web Application Pen-testing?

There are some security testing standards In web application pen-testing which you would like to follow Such as
1) OWASP (Open Web Application Security Project)
2) SANS (Sysadmin, Audit, Network And Security )
3) OSSTMM ( Open source SecurityTesting Methodology Manual)
4) ISSAF ( Information Systems Security Assesment Framework)

If you would ask me How to?

I would start with basic’s, one should have basic knowledge of how a web application works, some programming knowledge like HTML, CSS Javascript, PHP, MYSQL..etc.
basically, if you have the above then you are good to start web application pen-testing. After this, you Should get know how a web application works its workflow, like what is HTTP? https? …etc.

How would you go for it? let divide the web application pen-testing into two parts
1) Client side pen-testing
2) Server-side pen-testing

Client-side pen testing:

Client-side attacks are quite different. These are attacks that target vulnerabilities in client applications that interact with a malicious server or process malicious data. Here, the client initiates the connection that could result in an attack. If a client does not interact with a server, it is not at risk, because it doesn’t process any potentially harmful data sent from the server. Client-side pen-testing may consist of vulnerabilities which often takes the form of unpatched software on a desktop or laptop. Depending on the nature of the vulnerable application, an attacker could exploit it via a specially-crafted email attachment or by convincing the user to visit a malicious Web site. Some targets include Web Browser’s, Adobe Acrobat, Macromedia Flash, QuickTime and Java Runtime Environment.

Some of the client side attacks might be like XSS, redirects, Phishing, Clickjacking, IDOR ..etc

Server-side Pen-Testing:

Server-side attacks seek to compromise and breach the data and applications that are present on a server.
Server-side attack target web server for downloading or viewing files like scripts, web shells, configuration files without proper authorization. Most of the time server-side attacks don’t require user interaction. These attacks can be used with web servers. We can also use them against a normal computer that people use every day. Some of the server side attacks are like RCE, Shell Uploading, RFI..etc.

In client-side attacks generally what happens is that an attacker can Mess up with the external part of the website mostly but in the server side the attacker is able to change the code or many internal files.

How to start with Web Application Pen-Testing?

—————————————————————————————————————————————————————-

Enumeration -> Enumeration -> Enumeration -> Scanning -> Manual testing

—————————————————————————————————————————————————————–

So how to go for Enumeration -> Enumeration -> Enumeration

My way for getting a description of the website is Virustotal
Looking for subdomain go for Amass
Looking for any OSNIT info go for Spiderfoot
Looking for how the application is made using Wappalyzer
Check for the Components with known vulnerabilities like check for the server name and version which the site is working on, there might be chances that the server might be vulnerable to some RCE, INJECTIONS …etc
Check for Low-level vulnerabilities like SPF, HTTP headers, NO rate limiting …etc

After that, once the basic enumeration part is done I would like to go for,
The medium level and high-level vulnerabilities like XSS, injections, Idor, chain attacks, Privilege escalation..etc.

So this was my methodology for Web Application pen-testing.

Furthermore, Testing You can go through the Methodology given within the web application hackers handbook.
1) Analyze the application
2) Test for the client side workflow
3)Test the authentication workflow
4)Test for session management
5)Test for Acces controls
6) Test for Input based Vulnerabilities
7)Tests for business login errors
8) Test for privilege escalation
9) Test for Injection attacks
10) Test for server level attacks

Now let’s take an example,

Suppose there’s a Login page now, On the basic login page, we will be having a User name and password field, submit button, Forgot password and Terms and services page link.

Now here the client side attack will be like,
There’s a forgot password section in the login page, if the attacker gets a forgot password link such as

https://xyz.com/email=ascd@xyz.com&token=aaaasdfgfdhs1232#@$

Now here if the attacker is able to alter the email address and able to reuse the token or if he is successful in carrying out an HTTP pollution attack here, and if he is able to take over the account by this method then this attack can be called as a client-side attack.

Now on the same page, you can see that there is a terms and services field also, can you check the link given there? can we carry try to carry out an RFI (Remote file inclusion) attack there

https://xyz.com/page=terms

Suppose if the attacker is able to alter the PAGE parameter and successfully carry out his RFI there then this kind of attack can be called as Server-side attacks

So this was all about the service side and client side attacks
This was all about the web application pen-testing methodology, Do let me know if you need any help in web application pen-testing

In the next part, I would be discussing in deep about the Client-side attacks, ways to carry out an attack, its mitigations..etc

Hope you like it,

Till then, Happy Hacking.

How critical is IDOR vulnerability? Can it take down a whole company?
Ninad Mathpati — Thu, 16 May 2019 09:10:21 +0000

Hello people, hope you are doing good and playing well with security!

Today I am here again with a topic known as Insecure Direct Object References (IDOR), I got this vulnerability while doing a VAPT(Vulnerability Assessment & Penetration Testing) for a client.

What is it?

According to wiki
“Insecure Direct Object References(IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files.”
In simple words, it’s like

“Getting sensitive information by just changing a few values in the parameter“

How an IDOR(Insecure Direct Object References) works?

IDOR Attack Structure

Here In the above Fig. you can see that an attacker is requesting the server to get his profile information with user id “101” in return, he gets his profile information from the server now he tries to manipulate the user id value to “103” and still he is getting a 200 ok response. It means the server is not doing a proper verification for the user’s requests. It’s just passing the response for any value. Thus this is IDOR.

Now coming to the topic, Is the IDOR just for that? Try going a bit deeper inside the application.

Suppose if we get the HTTP methods enabled with this IDOR What all a hacker can do here? Think about it!

Here is the sample request that shows IDOR vulnerability,

IDOR Vulnerability

Here if we change the user id to something else we are getting any other user’s profile information & there’s a lot of critical information here, Now after this, we can stop here and directly report it or well try to get a bit deep inside it. Can you see the HTTP methods enabled in the response field?

What are HTTP methods and what are they used for?

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. In simple words, we can say,

“It’s a way for connection between the server and the user”

There are total of 9 HTTP methods, they are

GET:- The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD:- The HEAD method asks for a response identical to that of a GET request, but without the response body.
POST:- The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
PUT:- The PUT method replaces all current representations of the target resource with the request payload.
DELETE:- The DELETE method deletes the specified resource.
CONNECT:- The CONNECT method establishes a tunnel to the server identified by the target resource.
OPTIONS:- The OPTIONS method is used to describe the communication options for the target resource.
TRACE:- The TRACE method performs a message loop-back test along the path to the target resource.
PATCH:- The PATCH method is used to apply partial modifications to a resource.

Now Coming to the topic, In the above request if we change the HTTP method from GET to DELETE, will it delete the user from the database?

DELETE method in IDOR

Yeah, it’s working, we are able to delete the customer just by changing the request method.

Now if we are able to fetch information by GET and erase the information by DELETE, then why not give a try to PUT method.

PUT method in ID0R

Here if we use the PUT method, we are able to edit/change the customer’s information, like first name, last name, dob…etc, or it can be anything, so how can it lead to full account takeover

There are two ways we can do that,
1) Using the PUT method change the password
2) Using the PUT method change the email and contact no

Once we change the email and contact no. We can request a new password from the reset password page and then just change the password.

Thus this leads us to a single account takeover. How can we take down the whole company then?

The answer is BRUTE-FORCE the user id field with the PUT method.

Account takeover by IDOR

Thus we need to do a brute force attack by adding the email field in the request and use intruder to brute force it. Within a few hours, the company will be down none of the user’s will be able to relogin.

Thus in this way, we could take down a whole company by
Insecure Direct Object References(IDOR).

What will be the mitigation for the IDOR?

1) Avoid Exposing Direct Object References :-

In this try to avoid exposing the direct object references like “www.xyz.com/user/23456” instead try configuring in this way “www.xyz.com/myprofile“ and use the information already present in the user’s session on the server to locate the resources to serve.

2) Check User Access at the Data-Object Level :-

Add proper Authorization while implementing the server-side access controls, it is relatively obvious to add authorization checks at the functionality or route level. A common issue that causes this vulnerability is missing access checks at the data or object level to protect against tampered IDs in URL parameters. You need to enforce the data layer access controls by verifying that the current user owns or is allowed to access the requested data.

Thus this was all about today’s topic, Hope you like it, Subscribe to my blog for further updates on security.

Hint for the next blog:- Bug bounty can be done in 2 ways hard work and smart work which one you prefer?
…. To be continued

Till then Happy hacking!

All about SSL pinning bypass!
Ninad Mathpati — Tue, 09 Apr 2019 10:27:24 +0000

Hello people, hope you are doing good and playing well with security!

Today I am here again with a topic known as SSL pinning
What is it?
According to google its something like
“Pinning is an optional mechanism that can be used to improve the security of service or site that relies on SSL Certificates. Pinning allows you to specify a cryptographic identity that should be accepted by users visiting your site. SSL/TLS uses digital certificates to provide authentication and encryption. To trust that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority (CA)”

SSL pinning is a security measure taken to reduce Man in the middle attacks it’s done for both Android and ios
applications, In general, Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.

Android part

Now to break it or bypass anything we need to know how its build (i prefer learning slowly but conceptually)
Here is a blog that I found on how SSL pinning is implemented in Android.

It’s not that if you don’t know how it’s built you will not be able to crack it, but it will be easy to crack, if you know how to build it.

In android SSL pinning bypass can be done in 4 ways:

Frida
Objection
Xposed Framework
Manually changing the code.

Let’s move on step by step

1. SSL pinning bypass using Frida

Frida is a dynamic code instrumentation toolkit. It lets you inject snippets of JavaScript or your own library into native apps on Windows, macOS, GNU/Linux, iOS, Android, and QNX.

In general terms,

It helps in Injecting JavaScript to explore native apps on Windows, Mac, Linux, iOS and Android.

How can we use Frida to bypass SSL pinning in android?
Firstly you should install Frida from here for mobile & for a laptop, you can just use the command line.

$ pip install frida-tools

Requirements :

Python 3
Linux/Windows/Mac
Rooted android device

Connect your device to adb command shell, once connected you can push the downloaded file to your data/local/imp folder.

$ adb root # required
$ adb push (path of the Frida file) /data/local/tmp(path to be saved)

Now open Cmd/ Terminal & follow these steps,

$ adb shell "chmod 755 /data/local/tmp/frida-server"
$ adb shell "/data/local/tmp/frida-server &"

If everything goes well we can make a quick check by running(this will show the processes running on device)

$ frida-ps -U

You will get something like,

Here you need to have the burpsuit certificate, for that open burpsuit & go to proxy settings and click on the export certificate button, and then select “Certificate in DER format” and download it.
Once its done rename it’s extension from “.der” to “.cer”. After that, you should push this file to your android device

$ adb push (path of certificate) /data/local/tmp

The last part of Frida is your Javascript, you can write your own or copy it from here. Save it as a js file & run the command.

$ frida -U -f it.app.mobile -l frida-android-repinning.js --no-pause

Where
-U stands for "USB device"
-f stands for "Filename"
-l stands for "location of js file"
--no-pause stands for "automatically start main thread after startup"

If everything goes well, you will get an output such as

SSL pinning bypass

& bypass the SSL pinning.

Now, you are good to go, you can successfully intercept the requests and work on dynamic analysis. Some errors in this will be sometimes you won’t be able to bypass in 1st attempt make it 4-5 times. While attempting once again you might get an error as
“Frida server service already running“
Here you need to kill that service using the adb kill command.

$ adb shell ps | Findstr Frida
$ adb kill ps(process id)

This was all about Frida SSL bypass
Now let’s move towards Objection

2. SSL pinning bypass using Objection

Objection is a runtime mobile exploration toolkit, powered by Frida. It was built with the aim of helping assess mobile applications and their security posture without the need for a jailbroken or rooted mobile device.
You can install it by running

pip3 install objection

Once done get your file name of the application by using Frida or adb.

$ Frida-ps -U
or
$ adb shell ps

then,

objection patchapk -s com.xyz.android.apk

This will create a new apk which is hooked
Push the apk file or install the application by

$ adb push
or
$ adb install (path to apk)

Now run,

objection -g (new apk file name) explore -q

Where,
-g stands for "Name of the Frida Gadget/Process to connect to"
explore stands for "objection exploration REPL"

thus if the file is successfully injected

run "android sslpinning disable"

Now, you are good to go and intercept the requests through burpsuit.

3. SSL pinning bypass using Xposed framework

Xposed is a framework that allows users to easily apply add-ons (called Modules) to the ROM. Rather than flashing a new ROM to get a specific feature, you can use Xposed to add individual features to whatever ROM you’re using, or even just the stock ROM.

Installation,
Download the app from here
Run it and find an application named SSL pinning bypass, install it
you get a screen like

Thus click on whichever application you want to apply the SSL bypass & you are ready to go and intercept through burp request.

4. SSL pinning bypass through manually changing the code

The reason why I gave a link to SSL pinning implementation above is for this one, if none of the above methods works, this should work but it’s not simple, here you need to have knowledge about the android app structure how it’s built and how it works, sometimes a developer would choose to provide their own SSL libraries instead of relying on the system libraries to handle the SSL certificate validation. So here we can decompile the apk using apktool or simply extract it. Convert the dex file to jar using the dex2jar and open that file using Java reversing tool (such as JD-GUI).
Here you need to find the code responsible for certificate validation, once you get it you can manually fix it or by using Frida you can hook the application.

Here is an awesome blog which shows a detailed way of bypassing SSL pinning using this method.

Thus, these were some methods to bypass SSL pinning in android.

iOS part

As I said we need to know the basics or atleast know how SSL pinning is implemented in iOS, here’s a link to the blog which will guide you in implementing SSL pinning in iOS.

Let’s come back to bypass part, there are 4 ways to do that:

Frida
Objection
External application (Cydia)
By modifying the IPA file

Let’s move on step by step

1. SSL pinning bypass using Frida for iOS

As you know already about Frida, basically it’s just used for hooking the application.
Here basically we need to modify the application in runtime so that’s what Frida is used for, we can use Frida Gadget dynamic library to modify the application during run time, so what we will do is extract the IPA file then modify the binary to load Frida gadget, if we are changing or modifying the IPA file we need to code sign it for the IPA to work, code signing can be done by creating a developer account.

Once code signing is done repack the IPA and install the application.
Looks complicated? right!
Don’t worry objection is here to help you,

2. SSL pinning bypass using objection for iOS

Here it is simple as of android you need to install objection
then use the command,

$ objection patchipa -s test.IPA -c 0[REDACTED]C
-s stands for the path to IPA file and
-c stands for code-signing certificate

Once done, install the modified application through ifunbox and run the objection here in the terminal.

3. Use of external application

There are some external application such as SSL killswitch, just install it and bypass the SSL. It is as simple as its name, here you need a jailbroken device and remember Xposed framework for android same like that we have Cydia for iOS.
So what is Cydia?
Cydia installer is a free third-party app installer which is developed for the iOS devices. Think of Apple’s official App Store, this is similar to the app store which means you can download apps, games from the Cydia downloader, but there are many other advanced options that have been included in the Cydia free store, which is more than the official store.
Thus, here you can find the “SSL killswitch“, install it and unpin the SSL for the application as you did it in android.

3. Modifying the IPA file

Most of the time the above methods should work. If not, this will definitely work, but here you need to know how the IPA application works, there is always an option to use disassemblers to be able to modify the IPA file to bypass any certificate validation. Some of the most common disassemblers are Hopper and IDA. Modifying the IPA will most likely break the signed application and it cannot be installed on an iOS device. Resigning the IPA file will allow you to install the mobile app.

That’s it for today. This was all about SSL pinning in android and iOS. Hope this helps you out, if not let me know in the comments section and if you liked it do subscribe for future blogs,

Hint for the next blog:- How critical is IDOR vulnerability ? Can it take down a whole company?
…. To be continued

Till then Happy hacking!

How I got a trip to amsterdam through bug bounty
Ninad Mathpati — Sun, 07 Apr 2019 01:33:04 +0000

Hello guys welcome to my blog, Let me tell this is my first blog and will be further writing more blogs on critical vulnerabilities that i found, I hope you would find it interesting.
So without wasting time lets move forward, Here I would like to share how I got a trip to Amsterdam with all expenses paid for 5 days.

At this moment a majority of them would have thought the Vulnerability would be a server-side issue, but Unfortunately, its a simple Vulnerability leading to full account takeover. The vulnerability was in the login portal, I guess some of you are familiar with this vulnerability.
First of all, let me tell you about this vulnerability which I like very much because it pays good enough & I have found it many times in different ways and the vulnerability is Full Account takeover, Account takeover can be through any method we just need to take over the account in any possible way, here the account takeover was done by Brute force on login portal. Now, what is it and how to find it?
For those who don’t know what Brute force attack is?

Brute force is a way of trying to bypass the login form or it might be any other form which needs a password to open that file or system. In simple words, we can say it’s just the process of guessing the password.

Here what I did was I created an account and was just checking for its requests and responses by intercepting the request through burpsuit, after some time checking for the minor vulnerabilities, I went to the forgot password page. Now the real problem was here when I was requesting a password for my account the server was by default setting a new password for my account and sending it to me via mail. When I received mail I saw the password was in a format such as
“Ab3CdF”

and it was a 6 digit password, to reconfirm the combination I requested the password for 100 times by this I got to know that there is no rate limiting implemented on the login page and forgot password page, Now we have the format of the password and nobody is gonna check us if we use it for brute forcing the account but it’s a 6 words password still we get a hell lot of passwords and its nearly (56,800,235,584) this much, now it’s really a lot of passwords for checking one account but we have the password format, So Here we can write a python script for generating the password or there are many other tools which will do the work for you. Thus once we generate the passwords we can use the burp-suit intruder (some thing like this)

to carry out the brute force attack. Thus this leads to Full account takeover.

Thus this was all about this Vulnerability. There are many other ways for full account takeover and I guess this is the easiest one to understand,
I will be writing blogs, one by one on various ways to take over the account and my other bug bounty experiences. so this is it for the day, thank you for reading the blog. Meet you soon with something more exciting things in bug bounty/ penetration testing.

Ninad Mathpati

Web Application Pentest Mindmap

How I was able to bypass the current password?