This blog is all about Cyber Security and IT

Showing posts with label Bug Bounty. Show all posts
Showing posts with label Bug Bounty. Show all posts

Tuesday, April 19, 2022

What happens when we type HTTPS in browser - Interview Question


Usually whenever I take Interview for any candidate related to security background. I must ask one question.

What happens when we type https://example.com

Mostly security people know answer this question. With this answer i come to know how in-depth knowledge candidate have in this domain. 

Let's try to understand the concept in a little brief.

Websites are secured by https protocol. But most of us do not have clear concept about how it really works. Let me give you a high level overview of how https works.


Suppose we are trying to access https://abc.com. After typing the url in address bar of browser when we press enter first SSL handshaking happens. 

First When we type a domain and click enter 

  • Domain Name resolve to IP address by DNS server and request reaches to the server we want to communicate with.
  • Then the server immediately responds to the initial connection by offering a list of encryption methods the webserver supports.
  • The client selects a connection method. Then the client and server exchange certificates to authenticate their identities for this first server sends its public certificate to the browser. 
  • After receiving that public certificate browser performs some tasks. 
  • First it validates signature of the certificate. For this it takes the value of Issued by field and search in Trusted Root Certification Authorities certificate store to get the public key of that authority. If it finds that public certificate it uses that to validate the signature of the public certificate received from abc.com. Popular certificates providers are VeriSign, GoDaddy etc.
  • Next it tries to match value of Issued to field with domain name(here abc.com). 
  • Next it checks validity period of that certificate to check it expired or not. 
  • After that it calls to check the revocation list of that certificate authority in the web to check is that certificate blacklisted or not.
  • If everything goes fine the browser generates a random key and encrypt the key with that public key got from server and sends that encrypted value to the server(abc.com). Because it is encrypted by the public key of abc.com no one except abc.com can decrypt it. When server(abc.com) got this encrypted key it uses its private key to decrypt it. Then both server(abc.com) and browser uses that random key sent from browser to encrypt, decrypt, sign and verify signature of all data sent or received between them in that communication. Thus using symmetric encryption data remains secured in https communication. 

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


Saturday, August 29, 2020

Buffer Overflow - Simply Explained with real world Example


A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.

For better reference:


https://www.hackingtutorials.org/exploit-tutorials/buffer-overflow-explained-basics/

Lets say , we visit a signup page of a website and we entered email and password and click on signup . But before clicking sign up , I am capturing request in the Burp Suite . So when i captured the request , I changed email to some long string , like if email is "davinder@gmail.com" , i changed that to "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@gmail.com" or even more in size

If i am able to proceed further without any restriction and or boundation, that this vulnerability exists.

Another example of code

buffer overflow strcpy code



Steps to resolve:

Restrict size limit on input parameter.

Impact

Category:Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Access control (instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program’s implicit security policy.
Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

  • 1 attachment:

Friday, August 28, 2020

List of Top Wireless hacking Tools for bug hunting


http://www.aircrack-ng.org/

http://www.stumbler.net/

http://www.kismetwireless.net/

http://sourceforge.net/projects/airsnort/

http://www.oxid.it/cain.html

http://wepattack.sourceforge.net/

http://www.inssider.com/

http://sourceforge.net/projects/airjack/

http://sourceforge.net/projects/cowpatty/

https://www.cloudcracker.com/

http://www.wildpackets.com/products/distributed_network_analysis/omnipeek_network_analyzer

https://github.com/esc0rtd3w/wifi-hacker

https://github.com/philcryer/wpa2own

https://github.com/hash3liZer/WiFiBroot

https://github.com/kennyn510/wpa2-wordlists

https://github.com/chunkingz/linsetmv1-2

https://github.com/DominikStyp/WPA-Attack

https://github.com/wifiphisher/wifiphisher

https://github.com/krtzer/WPA2-Wireless-Network-LabVIEW-FPGA-Testing

https://github.com/soxrok2212/PSKracker

https://github.com/r-a-w/DriveShake

https://github.com/wi-fi-analyzer/eaphammer

https://github.com/Hackndo/krack-poc

https://github.com/jgamblin/hackAPie

https://github.com/derv82/wifite

Wednesday, August 5, 2020

No Restriction on Password length - Bug Bounty


About this Vulnerability 

This is something when we are able to sign up on any web application using a long 100000 characters password which may lead  website becoming unavailable or unresponsive.


When you supply a long password , Generally what happens applications are implementing password hashing algorithms , So when we supply long password than server will get busy doing that and website becomes unavailable or unresponsive . When a long password is sent, the password hashing process will result in CPU and memory exhaustion.

Prevention

Normally all sites have a password minimum to maximum length like 72 words limit or 48 limit to prevent Denial Of Service attack.

The password hashing implementation must be fixed to limit the maximum length of accepted passwords.


Example Password used during testing

123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 




Tuesday, July 7, 2020

No Rate Limit Bug on Forgot password



Overview of this BUG:

A rate limiting is used to check if the user session has to be limited based on the information in the session cache. If user make too many requests within a given time , HTTP-Servers has to respond with status code 

429: Too Many Requests.

Description:-

I have identified that when Forgetting Password for account , the request has no rate limit which then can be used to loop through one request. Which can be annoying to the root users sending mass password to one email.

Steps To Reproduce The Issue

Go to Forget Password page

Enter the mail where you want to receive the link

Capture that request in BURP.

Send this to Intruder and set  parameter at"Accept-Language: en-US,en;q=0.5

Now go to payload and select number from 1 to 100.

Click on start attack.


If you will receive 100 mails with this , than this is a bug which have to be reported.


Solution -

I Will Recommend to Add A ReCaptcha & Sort Of Something Which Requires Manual Human Interaction To Proceed Like You Can Add Captcha Like 2+2=___ so that it cannot be brute forced and you also can have a limit at the backend for particular number upto 5 times a day user can request Forget Password Email or Link something like that will prevent you from someone exploiting this vulnerability

Impact

If You Are Using Any Email Service Software API Or Some Tool Which Costs You For Your Email This Type Of Attack Can Result You In Financial Lose And It Can Also Slow Down Your Services It Can Take Bulk Of Storage In Sent Mail Although If Users Are Affected By This Vulnerability They Can Stop Using Your Services Which Can Lead To Business Risk

Sunday, July 5, 2020

Recon like a king for Bug Bounty


As we all know , If we want to hunt bugs , we have to get more and more information. With Recon we can:
  • Increase Target
  • Unpopular subdomains
1. Tool: SubBrute
https://github.com/TheRook/subbrute
usage: ./subbrute.py target.com > subdomain.txt



Now After having subdomains , I need to find further subdomains of subdomains

2. Tool: altdns
https://github.com/infosec-au/altdns
usage: .altdns.py -i subdomains.txt -o -w words.txt -s output.txt


Using above tool , you will get lot of subdomains

now we need to get all http status code for all subdomains

for that ;
go to https://httpstatus.io

now you have to check for all the domains that are redirecting , as all those domains are really important 


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.

      Friday, April 24, 2020

      Reflected XSS - Explained with a real world example


      OVERVIEW OF THE VULNERABILITY:

      Reflected cross-site scripting (or XSS) arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

      Suppose a website has a search function which receives the user-supplied search term in a URL parameter:

      https://davindertutorials.com/search?term=hello

      The application echoes the supplied search term in the response to this URL:

      <p>You searched for: hello</p>

      Assuming the application doesn't perform any other processing of the data, an attacker can construct an attack like this:

      https://davindertutorials.com/status?message=<script>/*+Bad+stuff+here...+*/</script>

      This URL results in the following response:

      <p>You searched for: <script>/* Bad stuff here... */</script></p>

      If another user of the application requests the attacker's URL, then the script supplied by the attacker will execute in the victim user's browser, in the context of their session with the application.

      AFFECT OF THE VULNERABILITY
       
      If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Among other things, the attacker can:
      • Perform any action within the application that the user can perform.
      • View any information that the user is able to view.
      • Modify any information that the user is able to modify.
      • Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.

      There are various means by which an attacker might induce a victim user to make a request that they control, to deliver a reflected XSS attack. These include placing links on a website controlled by the attacker, or on another website that allows content to be generated, or by sending a link in an email, tweet or other message.

      Because of the external delivery mechanism for the attack means that the impact of reflected XSS is generally less severe than stored XSS, where a self-contained attack can be delivered within the vulnerable application itself.


      REAL WORLD EXAMPLE OF THIS VULNNERABILITY:

      PUBG's main website https://www.pubg.com has an endpoint that is vulnerable to an injection vulnerability - namely a reflected injection of JavaScript, also known as Reflected Cross Site Scripting (XSS).

      Steps To Reproduce:

      How this can be done by attacker

      Prepare a JavaScript payload that it wants the victim to execute. In this case, for Proof of Concept purposes, our JavaScript code will prompt an alert showing the users' cookies.

      alert(document.cookie);
      

      Inject this Javascript code properly into the vulnerable parameter, creating thus a crafted future GET request that will inject the payload.

      GET /?p=iqz78'%3e%3cimg%20src%3da%20onerror%3dalert(document.cookie)%3d1%3echplq HTTP/1.1
      Host: www.pubg.com
      Accept-Encoding: gzip, deflate
      Accept: */*
      Accept-Language: en
      User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
      Connection: close
      Referer: https://www.pubg.com/es/feed/
      Cookie: _icl_current_language=en; _icl_visitor_lang_js=en-us; wpml_browser_redirect_test=0; __cfduid=de74423d435717d651b1c9e2c63f4acc21575460678
      
      As this injection happens in a GET parameter, the attacker simply needs to send the crafted Link that produces this GET request to the victim and have the victim click it.


      Thursday, April 23, 2020

      Cache Poisoned Denial of Service Simplified


      Suppose someone try to visit a website lets says "davindertutorials.com" than the request go to the server . But what if the website server is placed in US and I am surfing that website from India . Few minutes earlier my friend who is living near to me accessing that same website . So lets says davindertutorials.com server is in US but is taking services from cloudfare. So cloudfare DNS is holding copy of the page requested by me which is accessed by my friend few minutes earlier is saved in the cache of cloudfare.


      Whenever a cache receives a request for a resource, it needs to decide whether it has a copy of this exact resource already saved and can reply with that, or if it needs to forward the request to the application server.


      Simplified example of this attack :

      > GET /index.html HTTP/1.1 > GET /index.html HTTP/1.1
      > Host: example.com > Host: evil.com

      Identifying whether two requests are trying to load the same resource can be difficult so requiring that the requests match byte-for-byte is not actually possible so Caches tackle this problem using the concept of cache keys – a few specific components of a HTTP request that are taken to fully identify the resource being requested. In the request above, I've highlighted the values included in a typical cache key in orange.


      GET /blog/post.php?mobile=1 HTTP/1.1
      Host: example.com

      User-Agent: Mozilla/5.0 … Firefox/57.0
      Accept: */*; q=0.01
      Accept-Language: en-US,en;q=0.5
      Accept-Encoding: gzip, deflate
      Referer: https://google.com/
      Cookie: jessionid=xyz;
      Connection: close


      This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:

      GET /blog/post.php?mobile=1 HTTP/1.1
      Host: example.com

      User-Agent: Mozilla/5.0 … Firefox/57.0
      Cookie: language=pl;
      Connection: close

      GET /blog/post.php?mobile=1 HTTP/1.1
      Host: example.com

      User-Agent: Mozilla/5.0 … Firefox/57.0
      Cookie: language=en;
      Connection: close

      This means that caches think the following two requests are equivalent, and will happily respond to the second request with a response cached from the first:

      So now if you see, attacker have replaced the language in the cache .. so they can also make many other changes as well

      To verify that the cache has been poisoned, just load the homepage in a browser and observe the popup.







      Wednesday, April 22, 2020

      XSS found using host header injection


      This vulnerability arise when you give any input to the host parameter and it may reflect back .

       Impact

      An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user's browser in the context of that user's session with the application.

      Real World Example:

      Path : /billing-admin/profile/subscription/?l=de
      Payload : c5obc'+alert(1)+'p7yd5
      Steps to reproduce :
      Request Header :
      GET /billing-admin/profile/subscription/?l=de HTTP/1.1
      Host: www.semrush.com
      Accept: /
      Accept-Language: en
      User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
      Connection: close
      Referer: http://www.google.com/search?hl=en&q=c5obc'+alert(1)+'p7yd5
      Overview :
      The payload c5obc'+alert(1)+'p7yd5 was submitted in the Referer HTTP header. Payload is copied from a request and echoed into the application's immediate response in an unsafe way.


      In the above example the payload reflect back in the response causing the rise of the vulnerability.

      Password Reset link hijacking via Host Header Poisoning


      This vulnerability raised when a website uses the Host header when sending out password reset links. This allows an attacker to insert a malicious host header, leading to password reset link / token leakage.

      Developers often resort to the exceedingly untrustworthy HTTP Host header (_SERVER["HTTP_HOST"] in PHP or in another languages

      There are two main ways to exploit this trust in regular web applications. 

      The first approach is web-cache poisoning; manipulating caching systems into storing a page generated with a malicious Host and serving it to others.
      The second technique abuses alternative channels like password reset emails where the poisoned content is delivered directly to the target.

      Impact

      The victim will receive the malicious link in their email, and, when clicked, will leak the user's password reset link / token to the attacker, leading to full account takeover.

      Example for more understanding

      1.) Open up Firefox and Burp Suite.)
      2.) Visit the forgot password page (/index.php/login/concrete/forgot_password)
      3.) Enter the victim's email address and click Reset and Email Password
      4.) Intercept the HTTP request in Burp Suite & change the Host Header to your malicious site / server.
      5.) Forward the request and you'll be redirected to your server.
      The victim will then receive a password reset e-mail with your poisoned link.


      If the victim clicks the link, the reset token will be leaked and the attacker will be able to find the reset token in the server logs. The attacker can then browse to the reset page with the token and change the password of the victim account!

      
      

      Remediation

      Use $_SERVER['SERVER_NAME'] rather than $_SERVER['HTTP_HOST']

      HTTP Cache Poisoning via Host Header Injection



      Vulnerability:

      Rewriting of links and URLs in cached pages to arbitrary strings by unauthenticated HTTP clients.When the application reflects HTTP Header value back in it's response and it may be possible to poison the server cache. The X-Forwarded-Host is directly reflected as a hyperlink. Than Host Header Attack - Cache Poisoning vulnerability may be there like:

      Affected software: ANY site that does not validate HTTP Host: headers.

      It is common practice for web programmers and web frameworks to rely on the value of the HTTP Host header to write links. This is for convenience, so that the same software will run on localhost, various testing servers, subdomains, secondary domains, etc, without modification. For example:

      <a href="<?=$_SERVER['HTTP_HOST']?>/login">Login</a>

      This turns out to be a very, very bad idea in any language. The HTTP Host header is arbitrary text controlled by the client, but common practice treats it as though it were a safe environment variable.

      HTTP Request

      GET / HTTP/1.1
      Host: davindertutorials.com
      X-Forwarded-Host: test.com
      ...
      ....

      HTTP Response

      HTTP/1.1 200 OK
      ....
      ....
      ....
      <li class="SL_hide" title="Get New Relic on your iPad, iPhone, or Android phone"><a href="http://test.com/mobility">New Relic for iOS & Android</a></li>
      ....

      Now as you see we are able to see test.com in the response.

      Mitigation: DO NOT use the value of the Host header for anything. If you must, apply very strict filters to only allow valid FQDNs, and then whitelist the FQDNs you allow. Treat it as you would any arbitrary data coming from the outside. If your webserver is configured to output the value of the Host header (as in the example, and as by default in many webservers), disable that configuration.

      Sunday, April 12, 2020

      SPF Record Missing is an important Security Concern


      What Is SPF/TXT Records?
      An SPF record is a type of Domain Name Service (DNS) record that identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain.
      like : Suppose woodland company have email address as : customersupport@woodland.com , So if  I am able to send a mail using that address that means SPF records are not properly set .

      Checking Missing SPF:
      There Are Various Ways of Checking Missing SPF Records on a website But the Most Common and Popular way is kitterman.com
      Steps to Check SPF Records on a website:-
      Go to http://www.kitterman.com/spf/validate.html or mslookup
      Enter Target Website Ex: target.com (Do Not Add https/http or www)
      Hit Check SPF (IF ANY)
      If You see any SPF Record than Domain is Not Vulnerable But if you see Nothing Here then "HURRAY! You Found a Bug"
      POC:
      Once There is No SPF Records. An Attacker Can Spoof Email Via any Fake Mailer Like Emkei.cz. An Attacker Can Send Email From name "Support" and Email: "support@davindertutorials.com" .With Social Engineering Attack He Can TakeOver User Account Let Victim Knows the Phishing Attack but When He See The Email from the Authorized Domain. He Got tricked Easily.
      How to reproduce this
      1. fill all the details
        like
        Name - mycrypto
        email - support@mycrypto.com
        to - your email address
      Click on send email .It will directly send a mail from support@davindertutorials.com to you