Category: Website Hacking

Posted on by

Beginners guide to Commix

Hello, aspiring ethical hackers. In one of our previous blogposts, you learnt what is command injection, types of command injection etc. In this blogpost, you will learn about Commix, a tool that is used to automatically exploit command injection vulnerability.

Commix, which is short for (comm) and (injection) e(x)ploiter is an open source pen testing tool written by Anastasior Stasinopolos that is useful in automatically detecting and exploiting command injection vulnerabilities. Written in Python, commix can be installed on any platform that supports Python.

On pen testing distros like Kali Linux, commix is installed by default. So, we will be using it for this tutorial. As target, we will be using mutillidae in Metasploitable 2. Mutillidae, is an intentionally vulnerable web application for practicing ethical hacking. See how to install Metasploitable 2 in virtualBox and set up a virtual hacking lab.

A webpage “dns-lookup.php” in mutillidae has a command injection vulnerability in the Hostname/IP field. These vulnerabilities can be detected using web vulnerability scanners like OWASP ZAP (aka zaproxy), Nikto, Burpsuite etc.

What this webpage does is when you provide an IP or hostname, it performs a DNS lookup of that IP or hostname (For example, we have used it on google.com).

This is its name functioning but when you join another command to the IP/hostname using ampersand as shown below, it also executes that command as shown below.

Commix allows us to exploit this vulnerability automatically. To do this, with commix, we need information about the parameter being sent while sending this query. This can be achieved by using OWASP ZAP as an intercepting proxy. See how to set OWASP ZAP as an intercepting proxy.

The target can be specified in commix using the “-u” option and POST data can be specified using “–data” option as shown below.

When you execute this command, commix will prompt you to set cookies. Cookies are not needed in this case.

Then, commix says the parameters we are testing is vulnerable to command injection and it will prompt you for a pseudo-terminal access.

Selecting ‘Yes” will give us access to the commix shell a shown below.

Apart from giving you a terminal on the target system, commix provides a lot of enumeration options. Let’s see some of them here.

–hostname

It retrieves the hostname of the target system.

–current-user

This command retrieves the current user on the target system.

–is-root

This command checks if the current user has root privileges.

–is-admin

This command checks if the current user has admin privileges.

–sys-info

As you might have guessed by now, this command retrieves the system information of the target.

–users

This command retrieves all the users on the target system.

–passwords

This command retrieves passwords of all the users on the system.

Here, of course we did not get any password hashes, as we do not have enough privileges to get those.

–privileges

This command retrieves the privileges of all the users on the target system.

–ps-version

This command retrieves the version of the PowerShell installed on the target system.

–all

Instead of enumerating each item separately, you can retrieve all the information from the target system using the “–all” option.

–os-cmd

This command is used to execute a single operating system command on the target system. For example, let’s execute “ls” command on the target system.

–os=

This command is used to force the backend operating system (For example, Windows or UNIX.

Posted on by

Beginners guide to XSSer

Hello, aspiring ethical hackers. In one of our previous blogposts, you learnt what XSS vulnerability is, what are the different types of XSS vulnerabilities and its impact on web security. Wouldn’t it be good if there was a tool that can automatically detect and exploit XSS vulnerabilities? In this blogpost, you will be learning about one such tool named XSSer which is an automatic framework to detect, exploit and report XSS vulnerabilities in web applications.

XSSer is a python script and can be installed on all Linux systems with python installed. It is installed by default in Kali Linux and we are going to use the same for this tutorial. See how to install kali Linux in virtual Box. We will be using Mutillidae in Metasploitable 2 as target to test with XSSer as it is easily available to download and this tutorial is easily reproducible. See how to install Metasploitable 2 in VirtualBox.

Mutillidae is a vulnerable web app that intentionally consists of all OWASP 10 vulnerabilities for practicing web application hacking. Also see how to create a virtual hacking lab in virtual Box. In the page shown below belonging to Mutillidae, the blog entry field consists of a XSS vulnerability. These vulnerable pages can be detected using web vulnerability scanners like OWASP ZAP aka Zaproxy, Nikto and Burpsuite etc.

XSSer can also be used to scan for XSS vulnerabilities using the “–all” option” as shown below.

However, here XSSer failed to find any XSS vulnerability. Let’s see how to find any XSS vulnerability in this specific section. For this, I start OWASP ZAP as intercepting proxy to capture web requests. Then, I change the setting in the browser to access the web through this proxy and visit the vulnerable page again on this browser.

I type “This is a new blogpost” in the blogpost entry and save the blogpost. Now, when we view the captured web request in OWASP ZAP as shown below, we can see the request being sent to the target.

Now, we copy the highlighted data above and use it in our XSSer tool. The only difference is to find out the XSS vulnerability, we add text “XSS” in the place of any vector that us vulnerable to XSS.

Note the method the query is using to pass this data. There are two methods by which data is sent and received: GET and POST. XSSer has an option to use both the methods: (-g) for GET method and (-p) for POST method. OWASP ZAP has shown us that this data is being passed using the POST method. So, we will be using the same with XSSer.

Now, you can see that vector “blog_entry” is vulnerable to cross site scripting using URL method. Here, we tried one vector. XSSer provides an option to inject a list of vectors provided by XSSer. To test all these vectors, we can use the “—auto” option. XSSer in total has 1291 injection vectors.

As you can see, XSSer found 1287 of 1291 injection vectors in the web app. XSSer also has the option of using payloads. Here the payload can be anything even the most popular <script> alert (“HC”)</script). Here is how we specify the payload in XSSer.

Here I have given the same above-mentioned script as payload.

Specify your own payload

Using the “-Fp” option, you can even specify your own payload for final injection.

Execute payload remotely

The “-Fr” option is used to execute the payload remotely.

Posted on by

Cross Site Scripting (XSS) for Beginners

Hello aspiring Ethical Hackers. In this blogpost, you will learn about Cross Site Scripting (XSS). Cross-Site Scripting (XSS) attacks are one of the most common web application security threats today. These attacks can allow attackers to steal sensitive data, gain unauthorized access to systems, and compromise entire networks. In this blog post, we will explore what XSS attacks are, their different types, and how to prevent them. In this article, we’ll discuss what Cross Site Scripting is, how it works, types of attacks, how to prevent and detect XSS.

What is Cross Site Scripting?

Cross-Site Scripting (XSS) is a type of security vulnerability that allows attackers to inject malicious code into web pages viewed by other users. The malicious code is typically written in client-side scripting languages like JavaScript, which is executed by the victim’s web browser when they view the infected page. The injected code can then be used to steal sensitive data, such as login credentials or credit card information, or to launch more advanced attacks, such as session hijacking or malware installation.

How XSS Works?

Cross Site Scripting

Types Of XSS

There are three primary types of XSS attacks: Stored (Persistent) XSS, Reflected (Non-persistent) XSS, and DOM-Based XSS. Let’s take a closer look at each type.

1. Stored (Persistent) XSS:

Stored XSS attacks are a type of XSS attack where the malicious code is injected into a website’s database, and then retrieved and executed by other users who view the infected page. This type of attack is particularly dangerous because the malicious code can be stored on the website for an extended period of time and can infect multiple users.

Cross Site Scripting

A typical example of a Stored XSS attack is when a user posts a message on a forum or blog containing malicious code. The code is then stored in the website’s database and is displayed to all subsequent visitors to the page, potentially compromising their systems.

2. Reflected (Non-persistent) XSS:

Reflected XSS attacks are a type of XSS attack where the malicious code is injected into a website’s search field, comment box, or other input field, and then reflected back to the user in the website’s response. This type of attack relies on the user clicking on a link containing the injected code, which then executes the malicious script in their browser.

A common example of Reflected XSS is when an attacker sends a phishing email with a link containing the injected code to a victim. When the victim clicks on the link, the code is reflected back to them through the website’s response and executed in their browser, potentially compromising their system.

3. DOM-Based XSS:

DOM-Based XSS is a type of XSS attack where the malicious code is injected into a website’s Document Object Model (DOM) rather than the server’s response. The injected code is then executed by the victim’s browser when the infected page is loaded.

Real World Examples Of XSS

Here are some of the SQL injection vulnerabilities and their exploitation cases in Real World.

1. British Airways:

In 2018, British Airways suffered a data breach due to cross site scripting. Magecart, a hacker group known for its card skimming scripture exploited a cross-site scripting vulnerability in Java script library known as feedify. This Java script library was modified to record customer data and send it to server controlled by Attackers using this, the attackers collected over 3,80,000 credit card details.

2. eBay:

eBay had a XSS vulnerability in its code for a short time at the end of 2015. EBay used an “URL” parameter to redirect users to the right page. However, the value submitted to this url parameter was not validated before it got inserted into the webpage. In the right attacker’s hand this could allow attacker to inject malicious code into the webpage. Luckily this didn’t happen.

Mitigation and Prevention

Preventing XSS attacks involves a range of technical measures and best practices. Some of the most effective strategies include:

1. Input Validation:

One of the most critical measures for preventing XSS attacks is input validation. This involves filtering and sanitizing user input to ensure that only safe and expected characters are allowed. This can be accomplished using a range of methods, including regular expressions, input masks, and whitelisting.

2. Output Encoding:

Another critical measure for preventing XSS attacks is output encoding. This involves encoding all output from the web application to prevent malicious code from being injected into the page. This can be accomplished using a range of methods, including HTML encoding, URL encoding, and JavaScript encoding.

3. Content Security Policy (CSP):

Content Security Policy (CSP) is a security standard that allows developers to define the sources of content that are allowed to be loaded by their web application. By defining a CSP, developers can prevent malicious scripts from executing on their web pages, thereby mitigating the risk of XSS attacks. CSP works by specifying a whitelist of trusted sources for content, such as scripts, stylesheets, and images. Any content that is not from a trusted source is blocked by the browser, preventing it from executing on the page.

4. Limiting the Use of Client-Side Scripting:

Another effective measure for preventing XSS attacks is to limit the use of client-side scripting languages like JavaScript. This can be accomplished by using server-side scripting languages like PHP or ASP.NET to generate dynamic content. By limiting the use of client-side scripting, developers can reduce the attack surface of their web application and minimize the risk of XSS attacks.

5. Using HTTP-only Cookies:

HTTP-only cookies are a type of cookie that prevents client-side scripting languages like JavaScript from accessing them. By using HTTP-only cookies, developers can protect sensitive information stored in cookies from being accessed by attackers through XSS attacks. This can help prevent session hijacking and other types of attacks that rely on stealing session cookies.

6. Keeping Software Up-to-Date:

Finally, it’s essential to keep all software used by the web application up-to-date, including web servers, frameworks, and third-party libraries. Developers should regularly check for security updates and patches and apply them promptly to reduce the risk of XSS attacks.

Posted on by

SQL Injection for beginners

Hello, aspiring Ethical Hackers. In this blogpost, you will learn about SQL injection. This vulnerability can result in unauthorized access to sensitive data, modification or deletion of data, and even complete control over the web application and underlying server. (Where is this data stored? In a database. Read what is a database). In this article, you will learn what SQL injection is, how it works, types of attacks, how to prevent and detect this vulnerability.

What is SQL Injection?

SQL (Structured Query Language) Injection is a type of security vulnerability that allows an attacker to manipulate a web application’s database through malicious SQL statements.

How does it work?

These attacks typically occur when a web application does not properly validate user input, such as form data or user-generated content. An attacker can exploit this vulnerability by injecting malicious SQL statements into the input field, which are then executed by the web application’s database.

Sql Injection for beginners

For example, suppose a web application has a login form that accepts a username and password. If the application does not properly validate the input, an attacker could enter a malicious SQL statement into the username field, such as:

Vbnet ‘ OR 1=1–

This statement would trick the web application into believing that the attacker has a valid username, bypassing the need for a password. The double dash at the end of the statement serves as a comment delimiter which ignores any subsequent characters in the query. As a result, the attacker gains unauthorized access to the application and potentially sensitive data.

SQL Injection attacks can also occur through other input fields, such as search boxes, comment forms and URLs. An attacker can use a variety of techniques to inject malicious SQL statements, such as union queries, stacked queries, and blind injection.

Types Of SQL Injection

There are several types of Injection attacks that an attacker can use to compromise a web application. These include:

1. Classic Injection:

This injection type is the most common type, where an attacker injects a malicious SQL statement into an input field to gain unauthorized access to the application and database.

SQL injection

2. Error Based Injection:

This type of Injection attack uses error messages returned by the database to extract sensitive information, such as usernames and passwords.

sql injection

3. Blind Injection:

In a blind Injection attack, an attacker injects a malicious SQL statement into an input field, but does not receive any error messages or output. This makes it difficult to detect the attack and extract sensitive information.

SQL injection
SQL injection

3. Out-Of-Band Injection:

This type of injection attack uses a separate channel, such as DNS or HTTP requests, to extract sensitive information from the database.

5. Time-Based Injection:

In a time-based injection attack, an attacker injects a malicious SQL statement into an input field that causes a delay in the database response time. This delay can be used to extract sensitive information from the database.

Methods Of SQL Injection

SQL Injection attackers use a variety of methods to exploit vulnerabilities in web applications. Some common methods include:

1. Union-Based Injection:

This method involves adding a UNION statement to a SQL query to combine data from multiple tables or queries. This can be used to extract sensitive information from the database.

2. Error-Based Injection:

This method involves triggering a SQL error and using the resulting error message to gain access to sensitive information.

3. Boolean-Based Injection:

This method involves using true or false statements to determine whether certain conditions are met, such as whether a username and password combination is valid.

4. Time-Based Injection:

This method involves using time delays in SQL queries to determine whether certain conditions are met, such as whether a username and password combination is valid.

Real World Examples Of SQL Injection

Here are some of the SQL injection vulnerabilities and their exploitation cases in Real World.

1. Freepik Data Breach:

In year 2022, hackers stole over 8.3million Freepik & Flaticon users by exploiting a SQL injection vulnerability in company Flaticon website.

2. Tesla Motors:

In 2014, a security researcher found a blind injection vulnerability in the Tesla Motors Design studio tool. This vulnerability if exploited could have given anyone access to Tesla backend database including call customer record.

3. Heartland Hack:

A team of hackers exploited an injection vulnerability in Heartland and other company’s website to gain access to their network and plant packet sniffing tools and other malware on their network.

Mitigation and Prevention

To detect and prevent SQL Injection attacks, web application developers and administrators can implement a variety of measures, including:

1. Input Validation:

This involves validating user input to ensure that it conforms to expected patterns or formats. Input validation can be implemented through client-side and server-side validation techniques.

2. Parameterized Queries:

This involves using parameterized queries instead of dynamically generated SQL queries. Parameterized queries use placeholders for user input, rather than incorporating user input directly into the SQL query.

3. Stored Procedures:

Stored procedures are a type of database object that can be called by an application to perform a specific task or set of tasks. They can also be used to prevent this injection attacks by creating parameterized queries that are executed by the stored procedure.

4. Database Hardening:

This involves configuring the database server to restrict user access and ensure that each user has only the necessary access to perform their job functions. It also involves implementing strong passwords and two-factor authentication.

5. Configuring Error Messages:

When a SQL error occurs, the database server may return an error message that includes sensitive information, such as the SQL query that caused the error or details about the database structure. An attacker can use this information to refine their attack and gain further access to the database. To prevent this, it’s important to configure error messages so that they do not reveal sensitive information.

6. Regular Updates:

This involves keeping web applications and database servers up-to-date with the latest security patches and updates.

7. Education and Training:

Regular education and training for developers, administrators, and users is critical to preventing SQL Injection attacks. This includes training on secure coding practices, data security, and password management.

Tools for Detecting SQL Injection

There are several tools available to help detect SQL Injection attacks. Some popular tools include:

1. SQLmap:

This is an open-source tool that automates the process of detecting and exploiting SQL Injection vulnerabilities.

2. Netsparker:

This is a web application security scanner that includes this injection detection and prevention features.

3. Acunetix:

This is another web application security scanner that includes this Injection detection and prevention features.

4. Burp Suite:

This is a web application security testing tool that includes a SQL injection Scanner.

5. OpenVAS:

This is an open-source vulnerability scanner that includes this injection detection and prevention features.

SQL Injection attacks continue to be a major threat to web application security, and the consequences of a successful attack can be devastating. By understanding the methods used by the attackers, and implementing best practices for prevention and detection, web application developers and administrators can effectively protect their applications against this type of attack.

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.