This blog is all about Cyber Security and IT

Showing posts with label bug hunting. Show all posts
Showing posts with label bug hunting. Show all posts

Thursday, April 14, 2022

How to get Entry Level Job in Cyber Security


 

This video is for all those students who want to get a Job in Cyber Security feild but don't know from where to start. So tried to explain the whole concept in a simple manner. If you don't know what to study and what are the things required to learn . You are at the right destination. Cyber Security is a booming career in India and is having lot of Opportunities. So here at davidertutorials you will get all the relevant stuff related to Cyber Security and IT


Friday, August 28, 2020

Bypassing Android SSL Pinning


Portswigger.net will give you detailed video for burp setup , But to hunt bugs on Android , Below are some important steps in order to unpin Apps for testing . To do so you need to install below apps

1. Dowload genymotion - This is Your Andoid Emulater

2. Download super su v2.46 or latest

3. Download xposed installer apk

4. download xposed sdk

5. Download ssl unpinning


first root your android fone

than download xposed apk in that fone

than install xposed sdk (Note sdk version must be same as your fone apk version)

than ssl unpinning

After all steps , Restart android phone. 


After Restarting the phone , Open SSL pinning App, Select the app you want to test and click on upin.

After that capture the requests on the Burp and have fun.







Tuesday, April 28, 2020

Open URL Redirection Vulnerability- Well Explained


Overview:

What are Redirects?

Redirect means allowing a website to forward the request for the resources to another URL/endpoint. Let’s assume that you make a request to davindertutorials.com and davindertutorials.com can redirect you to another website(new-davindertutorials.com), so you’ll end up at new-davindertutorials.com even though the original request was made for davindertutorials.com. This is called “redirection”. There are different types of redirects in HTTP, check em out below.
 

Now Lets understand this vulnerability:

Open redirect is basically what the name says, Openly allow Redirects to any website. 

URL redirection vulnerabilities found when user redirect to some other url , mainly the attacker url in unsafe way.

An attacker can construct a URL within the application that causes a redirection to an external domain. This behavior is well known for doing phishing attacks against users of the application.


Redirection Status Code - 3xx
    • 300 Multiple Choices
    • 301 Moved Permanently
    • 302 Found
    • 303 See Other
    • 304 Not Modified
    • 305 Use Proxy
    • 307 Temporary Redirect
    • 308 Permanent Redirect
      The redirection can happen on the server-side or the client side.

      Server-Side: Request to redirect is sent to the server, then the server notifies the browser to redirect to the url specified via the response.

      Client-Side: Browser is notified to redirect to the url specified directly without the intervention of the server.

      Why is this an issue?

      Think about it for a moment, what if davindertutorials.com, a TRUSTED website allows you to redirect to any other website. Then a malicious user can simply redirect davindertutorials.com to attacker.com, and people fall for it all the time believing that it’s trusted, but infact, it’s not. So allowing redirects to any website without a stop in the middle or without a proper notification for the user is Bad.

      Explanation

      Let’s say there’s a “well known” website - https://example.com/. And let’s assume that there’s a link like
      https://example.com/signup?redirectUrl=https://example.com/login
      This link is to a sigup page, once you signup, you get redirected to https://example.com/login which is specified in the HTTP GET Parameter redirectUrl.
      What happens if we change the example.com/login to attacker.com?
      https://example.com/signup?redirectUrl=https://attacker.com/
      By visiting this url, if we get redirected to attacker.com after the signup, this means we have an open redirect vulnerablility. This is a classic open redirect vulnerability.

      Why does this happen?

      This happens due to insufficient redirection checks in the back-end, which means the server is not properly checking if the redirect URL is in their whitelist or not. Here are some examples of vulnerable code

      PHP (Server-Side)

      <?php 
          $url_to_redirect = $_GET['redirect_url'];
          header('Location: ' . $url_to_redirect);
          die();
      Here, the php code blindly grabs the url from redirect_url parameter and redirects to that url using the Location HTTP header.

      Java (Server-Side)

       response.sendRedirect(request.getParameter("u"));
      Here, a jsp page takes the url from the parameter u and blindly redirects it to the specified url.

      Javascript (Client-Side)

      window.location.href = "https://attacker.com";
      We can assign the URL string to the location.href of window’s object. This will cause a redirect. If there are no checks inplace, then it’s a bug.

      HTML (Client-Side)

      <meta http-equiv="refresh" content="0;URL='http://attacker.com/'" />
      HTML Meta tags can refresh the site with the given url as it’s content and also you can specify the refresh delay time.

      How to find them?

      • Visit every endpoint of the target to find these “redirect” parameters.
      • View your proxy history, you might find something. Make sure to use filters.
      • Bruteforcing helps too.
      • You might uncover many endpoints by reading javascript code.
      • Google is your friend, example query: inurl:redirectUrl=http site:target.com
      • Understand and analyze where the redirection is needed in the target application like redirecting to dashboard after login or something like that.

      Some tricks to find this bugs

      • Test for basic modification of the url like target.com/?redirect_url=https://attacker.com.
      • Try with double forward slashes target.com//attacker.com.
      • Try target.com/@attacker.com. In this case the interpretation will be like, the target.com is the username and attacker.com will be the domain.
      • Test for javascript Protocol javascript:confirm(1).
      • Try target.com/?image_url=attacker.com/.jpg if there’s an image resource being loaded.
      • Try IP address instead of the domain name.
      • You can go further in terms of representing the IP in decimal, hex or octal.
      • You can also try target.com/?redirect_url=target.com.attacker.com to bypass weak regex implementations.
      • Chinese seperator 。 as the dot - https://attacker%E3%80%82com.
      • Test for String reverser unicode(“\u202e”) target.com@%E2%80%AE@attacker.com.
      • No slashes https:attacker.com.
      • Back slashes http:/\/\attacker.com or https:/\attacker.com.
      • Different domain redirect_url=.jp resulting in redirection of target.com.jp which is not the same as target.com.
      • Try some unicode(including emojis) madness t𝐀rget.com or 𝐀ttacker.com(‘𝐀’ is “\uD835\uDC00”).

      Exploitation

      Phishing

      Assume that the target is example.com. It has a password recovery page at example.com/forgot-password. You enter the email and you click on Forgot Password button, and it’ll send you an email with a password reset link, and this link might look like
      https://example.com/reset-password/some-random-token?redirect=https://example.com/login
      If we tamper with the redirect parameter and change it to
      https://example.com/reset-password/some-random-token?redirect=https://attacker.com/login
      This redirects the user to an evil login page instead if the original one and the user can be phished.

      Mitigation

      • Only use redirects if you really want em.
      • If you want to use them, make sure you properly check the whitelisted domains and allow the matched ones.