This blog is all about Cyber Security and IT

Wednesday, November 2, 2022

Account Takeover Methods


Chaining Session Hijacking with XSS

1.I have added a session hijacking method in broken authentication and session management.
2.If you find that on target.
3.Try anyway to steal cookies on that target.
4.Here I am saying look for xss .
5.If you find xss you can steal the cookies of victim and using session hijacking you can takeover the account of victim.


No Rate Limit On Login With Weak Password Policy


Password Reset Poisioning Leads To Token Theft
1.Go to password reset funtion.
2.Enter email and intercept the request.
3.Change host header to some other host i.e,
    Host:target.com
    Host:attacker.com
  also try to add some headers without changing host like
    X-Forwarded-Host: evil.com
    Referrer: https://evil.com
4.Forward this if you find that in next request attacker.com means you managed to successfully steal the token. :)


Using Auth Bypass

Check out Auth Bypass method, there is a method for OTP bypass via response manipulation, this can leads to account takeovers.
1.Enter the wrong auth code / Password
2.Capture a auth request in burpsuite and send it to repeater
3.Check for the resoponse
4.Change the respone by manipulating the following parameters
  {“code”:”invalid_credentials”} -> {“code”:”valid_credentials”}
  {“verify”:”false”}             -> {“verify”:”true”}
 
 

Try For CSRF On

1.Change Password function.
2.Email change
3.Change Security Question
Token Leaks In Response
So there are multiple ways to do it but all are same.


Token Leaks in Response


Steps(For Registration):


  1. For registeration intercept the signup request that contains the data you have entered.
  2. Click on action -> do -> intercept the response to this request.
  3. Click forward.
  4. Check response if that contains any link, any token or OTP.


Steps (For password reset):

 1. Intercept the forget password option.
 2. Click on action -> do -> intercept the response to this request.
 3. Click forward.
 4. Check response if that contains any link,any token or OTP.

Tuesday, October 11, 2022

What is an SSRF?


SSRF stands for Server-Side Request Forgery. It's a vulnerability that allows a malicious user to cause the webserver to make an additional or edited HTTP request to the resource of the attacker's choosing.


Types of SSRF

There are two types of SSRF vulnerability; the first is a regular SSRF where data is returned to the attacker's screen. The second is a Blind SSRF vulnerability where an SSRF occurs, but no information is returned to the attacker's screen.

What's the impact?

A successful SSRF attack can result in any of the following: 

  • Access to unauthorised areas.
  • Access to customer/organisational data.
  • Ability to Scale to internal networks.
  • Reveal authentication tokens/credentials.

 

Potential SSRF vulnerabilities can be spotted in web applications in many different ways. Here is an example of four common places to look:

When a full URL is used in a parameter in the address bar:


A hidden field in a form:


A partial URL such as just the hostname:


Or perhaps only the path of the URL:


Some of these examples are easier to exploit than others, and this is where a lot of trial and error will be required to find a working payload.

If working with a blind SSRF where no output is reflected back to you, you'll need to use an external HTTP logging tool to monitor requests such as requestbin.com, your own HTTP server or Burp Suite's Collaborator client.

 

Thursday, October 6, 2022

Path Traversal Vulnerability?


Also known as Directory traversal, a web security vulnerability allows an attacker to read operating system resources, such as local files on the server running an application. The attacker exploits this vulnerability by manipulating and abusing the web application's URL to locate and access files or directories stored outside the application's root directory.

Path traversal vulnerabilities occur when the user's input is passed to a function such as file_get_contents in PHP. It's important to note that the function is not the main contributor to the vulnerability. Often poor input validation or filtering is the cause of the vulnerability
In PHP, you can use the file_get_contents to read the content of a file. You can find more information about the function here.


We can test out the URL parameter by adding payloads to see how the web application behaves. Path traversal attacks, also known as the dot-dot-slash attack, take advantage of moving the directory one step up using the double dots ../If the attacker finds the entry point, which in this case get.php?file=, then the attacker may send something as follows, http://webapp.thm/get.php?file=../../../../etc/passwd

Suppose there isn't input validation, and instead of accessing the PDF files at /var/www/app/CVs location, the web application retrieves files from other directories, which in this case /etc/passwd. Each .. entry moves one directory until it reaches the root directory /. Then it changes the directory to /etc, and from there, it read the passwd file.

As a result, the web application sends back the file's content to the user.


Similarly, if the web application runs on a Windows server, the attacker needs to provide Windows paths. For example, if the attacker wants to read the boot.ini file located in c:\boot.ini, then the attacker can try the following depending on the target OS version:

http://webapp.thm/get.php?file=../../../../boot.ini or

http://webapp.thm/get.php?file=../../../../windows/win.ini

The same concept applies here as with Linux operating systems, where we climb up directories until it reaches the root directory, which is usually c:\.

Sometimes, developers will add filters to limit access to only certain files or directories. Below are some common OS files you could use when testing. 



LocationDescription

/etc/issue

contains a message or system identification to be printed before the login prompt.

/etc/profile

controls system-wide default variables, such as Export variables, File creation mask (umask), Terminal types, Mail messages to indicate when new mail has arrived

/proc/version

specifies the version of the Linux kernel

/etc/passwd

has all registered user that has access to a system

/etc/shadow

contains information about the system's users' passwords

/root/.bash_history

contains the history commands for root user

/var/log/dmessage

contains global system messages, including the messages that are logged during system startup

/var/mail/root

all emails for root user

/root/.ssh/id_rsa

Private SSH keys for a root or any known valid user on the server

/var/log/apache2/access.log

the accessed requests for Apache  webserver

C:\boot.ini

contains the boot options for computers with BIOS firmware

Wednesday, October 5, 2022

What is an IDOR?


 

IDOR stands for Insecure Direct Object Reference and is a type of access control vulnerability.

This type of vulnerability can occur when a web server receives user-supplied input to retrieve objects (files, data, documents), too much trust has been placed on the input data, and it is not validated on the server-side to confirm the requested object belongs to the user requesting it.

 

Example:

Imagine you've just signed up for an online service, and you want to change your profile information. The link you click on goes to http://davindertutorials.com/profile?user_id=1105, and you can see your information.

Curiosity gets the better of you, and you try changing the user_id value to 1000 instead (http://davindertutorials.com/profile?user_id=1000), and to your surprise, you can now see another user's information. You've now discovered an IDOR vulnerability! Ideally, there should be a check on the website to confirm that the user information belongs to the user logged requesting it.

 

 

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. 

Monday, April 18, 2022

Top Github Dorks- 2022 Bug Bounty


Below are list of popular dorks bug hunters use for hunting bugs

api_key
“api keys”
authorization_bearer:
oauth
auth
authentication
client_secret
api_token:
“api token”
client_id
password
user_password
user_pass
passcode
client_secret
secret
password hash
OTP
user auth
#Some of the mine which I use generally
remove password
root
admin
log
trash
token
FTP_PORT
FTP_PASSWORD
DB_DATABASE=
DB_HOST=
DB_PORT=
DB_PASSWORD=
DB_PW=
DB_USER=
number

 

 Some other dorks

filename:sftp-config.json password

filename:.s3cfg
filename:config.php dbpasswd
filename:.bashrc password
filename:.esmtprc password
filename:.netrc password
filename:_netrc password
filename:.env MAIL_HOST=smtp.gmail.com
filename:prod.exs NOT prod.secret.exs
filename:.npmrc _auth
filename:WebServers.xml
filename:sftp-config.json
filename:.esmtprc password
filename:passwd path:etc
filename:prod.secret.exs
filename:sftp-config.json
filename:proftpdpasswd
filename:travis.yml
filename:vim_settings.xml
filename:sftp.json path:.vscode
filename:secrets.yml password
extension:sql mysql dump
extension:sql mysql dump
extension:sql mysql dump password
extension:pem private
extension:ppk private

Dynamic Programming Patterns