LAB Setup — ModSecurity || Apache as reverse Proxy || Generate& Install self signed SSL…

A: Configure Apache as reverse proxy and the application [demo.testfire.net] should be accessible via local host entry through configured Apache.

The Internet(Web clients) — -> Apache Reverse Proxy with Modsecurity Service — -> Web Server

A-1.1 — Installed and Configure Apache as reverse proxy

Reverse Proxy: A reverse proxy accepts a request from a client, forwards it to a server that can fulfill it, and returns the server’s response to the client.

A reverse proxy can hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them.

A-1.2 Installed and Configured Application — demo.testfire.net

Installation steps are below:

1. Download AltoroJ for application (demo.testfire.net)

Setup Github Link: https://github.com/HCL-TECH-SOFTWARE/AltoroJ

Prerequisites:

AltoroJ has been developed using Eclipse and designed to run on Tomcat 7, but since it’s a relatively simple J2EE app, it should be pretty easy to port it to a different J2EE IDE or another J2EE web application server. Here are out-of-the-box requirements:

• Eclipse 4.6 or newer recommended (requires Java 8)
• Tomcat 7.x — Tomcat provides a “pure Java” HTTP web server environment in which Java code can run.
• Gradle’s Buildship Eclipse plug-in to automatically download required 3rd party libraries and run AltoroJ inside Eclipse — Easiest way to install Buildship is from Eclipse Marketplace (inside Eclipse, go to Help -> Eclipse Marketplace)

Installation of Altotoj Application

1. Install Java JDK 8 — sudo apt-get install openjdk-8-jdk
2. Download and install Apache Tomcat 7
3. Eclipse IDE for Enterprise Java and Web Developers
4. The default JRE for my version of eclipse was 15 — in order to use it for AltoroJ we need to change it and point it to Open JDK 1.8 that we just installed.

5. Go to Window -> Preferences

6. On the right hand side click Add button > Select to add Standard VM

7. click Directory and point to usr directory where Open JDK 1.8 was previously installed. Eclipse should find automatically find the JVM and add the required JARs as shown below

8. check it usr to make it default as shown here

9. Configure Apache Tomcat 7

go to Window -> Preferences -> Server -> Runtime Environments

click Add > choose Apache Tomcat 7.0

10. Point to the installation directory (where we extracted the tar.gz for Tomcat )

11. Import AltoroJ project from GitHub

Go to File -> Import -> Git -> Projects from Git

Choose “Clone URI” and use the following URI on the next screen:

Proceed through the wizard without making any changes until you get to Wizard for Project import. At this point, choose to “Import existing Eclipse projects” and then continue through and finish the wizard

Run AltoroJ — application — demo.testfire.net

• Right-click on your AltoroJ project in Eclipse’s Project Explorer
• Choose Run As -> Run On Server

• Select your Apache Tomcat v7.0 Server instance and click Finish
• AltoroJ should now come up in a built-in web browser

• Confirm that AltoroJ is properly initialized by logging in using the following credentials: Username: jsmith Password: demo1234

B. Configure a local web page and point the Apache to show this page when the access request is done to [demo.testfire.net] through local host entry.

C. Configure self signed SSL certificates on Apache and make the application [demo.testfire.net] listen on https when accessed through local host entry.

1. Creating Self-Signed Certificates

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/bhavin.key -out /etc/ssl/certs/bhavin.crt

2. After running the commands above, It will prompt you to answer a few questions about the certificate you’re generating… answer them and complete the process.

Country Name (2 letter code) [AU]:IN

State or Province Name (full name) [Some-State]: STATE NAME

Locality Name (eg, city) []:CITYNAME

Organization Name (eg, company) [Internet Widgits Pty Ltd]:company

Organizational Unit Name (eg, section) []:IT

Common Name (e.g. server FQDN or YOUR name) []:demo.testfire.net

Email Address []:abc@email.com

3. Generated self signed SSL certificate — bhavin.crt

D. Install and configure Mod security service in apache and demonstrate a demo attack getting blocked by mod_security configured rule when locally accessing demo.testfire.net.

ModSecurity is an open-source web-based firewall application (or WAF) supported by different web servers: Apache, Nginx and IIS.

Protect web applications from various attacks. ModSecurity supports flexible rule engine to perform both simple and complex operations. It comes with a Core Rule Set (CRS).

https://owasp.org/www-project-modsecurity-core-rule-set/

When ModSecurity is enabled in the reverse proxy deployment, the following firewall architecture is enabled:

• Apache server becomes an HTTP router that is designed to stand between the Web/App server and its clients.
• Clients connect only to the Apache server.
• Apache forwards and gets the request from Tomcat for clients.
• Access to the Tomcat server for clients is disabled.

For Example setup like

1. Install and configure Mod security service in apache
2. Install ModSecurity

ubuntu-vm@ubuntuvm-virtual-machine:~$ sudo apt install libapache2-mod-security2

3. Apache service restarted

ubuntu-vm@ubuntuvm-virtual-machine:~$ sudo systemctl restart apache2

4. Check mod security version: ubuntu-vm@ubuntuvm-virtual-machine:~$ apt-cache show libapache2-mod-security2

Configure ModSecurity

1. ModSecurity is set to log events according to default rules. I have edited the configuration file to adjust the rules to detect and block traffic.
2. The default configuration file: /etc/modsecurity/modsecurity.conf-recommended.
3. Copy and rename the file: sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
4. ubuntu-vm@ubuntuvm-virtual-machine:~$ sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
5. Changed the ModSecurity detection mode. First, move into the /etc/modsecurity folder

root@ubuntuvm-virtual-machine:/home/ubuntu-vm# cd /etc/modsecurity/

root@ubuntuvm-virtual-machine:/etc/modsecurity# sudo nano modsecurity.conf

root@ubuntuvm-virtual-machine:/etc/modsecurity# cd

root@ubuntuvm-virtual-machine:~# systemctl restart apache2

Download Latest OWASP ModSecurity Rules

The latest Core Rule Set (CRS) for ModSecurity is maintained on GitHub. Install Git if it’s not already included on your system.

root@ubuntuvm-virtual-machine:~# sudo apt install git

root@ubuntuvm-virtual-machine:~# git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

Copy of the directory as a subdirectory of your current working location.

Open a new directory: cd owasp-modsecurity-crs and Move the crs-setup file

root@ubuntuvm-virtual-machine:~# cd owasp-modsecurity-crs

root@ubuntuvm-virtual-machine:~/owasp-modsecurity-crs# sudo mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf

root@ubuntuvm-virtual-machine:~/owasp-modsecurity-crs# sudo mv rules/ /etc/modsecurity

root@ubuntuvm-virtual-machine:~/owasp-modsecurity-crs# sudo nano /etc/apache2/mods-enabled/security2.conf

Apache service restarted

ubuntu-vm@ubuntuvm-virtual-machine:~$ sudo systemctl restart apache2

Now tested Apache Configuration by adding a detection rule into the default Apache configuration file.

Apache service restarted

ubuntu-vm@ubuntuvm-virtual-machine:~$ sudo systemctl restart apache2

\===================================

WAF Security test

Modsecurity rule test — https://demo.testfire.net/AltoroJ/

Modsecurity logs: tail -f /var/log/apache2/error.log

For LFI: https://github.com/xmendez/wfuzz/blob/master/wordlist/Injections/Traversal.txt

1. Checked robot.txt

Robots file sometimes expose juicy information.

The information in the file may therefore help an attacker to map out the site’s contents, especially if some of the locations identified are not linked from elsewhere in the site. If the application relies on robots.txt to protect access to these areas, and does not enforce proper access control over them, then this presents a serious vulnerability.

Logs: ModSecurity rules triggered

2. Cross Site Scripting:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

https://owasp.org/www-community/attacks/xss/

Payload:

Logs: ModSecurity rules triggered.

3. LFI Attack: Local File Include

Web servers control access to privileged files and resources through configuration settings. Privileged files include files that should only be accessible by system administrators. For example, the /etc/passwd file on UNIX-like platforms or the boot.ini file on Windows systems.

A LFI attack is an attempt to access privileged files using directory traversal attacks. LFI attacks include different styles including the dot-dot-slash attack (../), directory brute-forcing, directoryclimbing, or backtracking.

[Using Burp to Test for Path Traversal Vulnerabilities
Many types of functionality commonly found in web applications involve processing user-supplied input as a file or…portswigger.net](https://portswigger.net/support/using-burp-to-test-for-path-traversal-vulnerabilities "portswigger.net/support/using-burp-to-test-..")

Payload: https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/Injections/Traversal.txt

Logs: ModSecurity rules triggered

4. Execute malicious scripts on a browser

Logs: ModSecurity rules triggered.

SQL Injection:

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application’s content or behavior.

In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack.

Payload : ‘ and 1 in (select min(name) from sysobjects where xtype = ‘U’ and name > ‘.’) —

Logs: ModSecurity rules triggered.

SSRF: Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker’s choosing.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organization’s infrastructure.

Payload: ?forward=http://127.0.0.1

Web App Penetration Testing — Home LAB

Assessing Authentication Schemes // bugbounty

\=====================

Follow:

YouTube Subscription Link

Twitter

Instagram

Discord

🔈 🔈Infosec Writeups is organizing its first-ever virtual conference and networking event. If you’re into Infosec, this is the coolest place to be, with 16 incredible speakers and 10+ hours of power-packed discussion sessions. Check more details and register here.

[IWCon2022 - Infosec WriteUps Virtual Conference
Network With World's Best Infosec Professionals. Find How Cybersecurity Pros Achieved Success. Add New Skills to Your…iwcon.live](iwcon.live "iwcon.live")