Mitigating OWASP Web Application Security Top 10 – 2021 risks using F5 Distributed Cloud Platform
Overview: In the early 90’s, applications were in dormant phase and JavaScript & XML were dominating this technology. But in 1999, the first web application was introduced after the release of the Java language in 1995. Later with the adoption of new languages like Ajax, HTML, Node, Angular, SQL, Go, Python, etc. and availability of web application frameworks have boosted application development, deployment, and release to production. With the evolving software technologies, modern web applications are becoming more and more innovative, providing users with a grand new experience and ridiculously ease of interface. With these leading-edge technologies, novel exploit surfaces are also exposed which made them a primary target for intruders/hackers. Application safeguarding against all these common exploits is a necessary step in protecting backend application data. Open Worldwide Application Security Project (OWASP) is one of those security practices which protects application with above issues. This article is the first part of the series and covers OWASP evolution, its importance and overview of top 10 categories. Before diving into OWASP Web Application Security Top 10, let’s time travel to era of 1990’s and try to identify challenges the application customers, developers and users were facing. Below are some of them: Rapid and diversified cyber-attacks has become a major concern and monitoring/categorizing them was difficult Product owners are concerned about application security & availability and are in desperate need of a checklist/report to understand their application security posture Developers are looking for recommendations to securely develop code before running into security flaws in production No consolidated repo to manage, document and provide research insights for every security vulnerability After running into the above concerns, people across the globe have come together in 2001 and formed an international open-source community OWASP. It’s a non-profit foundation which has people from different backgrounds like developers, evangelist, security experts, etc. The main agenda for this community is to solve application related issues by providing: Regularly updating “OWASP TOP 10” report which provides insights of latest top 10 security issues in web applications Report also provides security recommendations to protect them from these issues Consolidated monitoring and tracking of application vulnerabilities Conducting events, trainings and conferences around the world to discuss, solve and provide preventive recommendations for latest security issues OWASP also provides security tools, research papers, libraries, cheat sheets, books, presentations and videos covering application security testing, secure development, and secure code review OWASP WEB SECURITY TOP 10 2021: With the rapid increase of cyber-attacks and because of dynamic report updates, OWASP gained immense popularity and is considered as one of the top security aspects which application companies are following to protect their modern applications against known security issues. Periodically they release their Top 10 vulnerabilities report and below are the latest Top 10 - 2021 categories with their summary: A01:2021-Broken Access Control Access controls enforce policy such that users cannot act outside of their intended permissions. Also called authorization, it allows or denies access to your application's features and resources. Misuse of access control enables unauthorized access to sensitive information, privilege escalation and illegal file executions. Check this article on protection against broken access vulnerabilities A02:2021-Cryptographic Failures In 2017 OWASP top 10 report, this attack was known as Sensitive Data Exposure, which focuses on failures related to cryptography leading to exposure of sensitive data. Check this article on cryptographic failures A03:2021-Injection An application is vulnerable to injection if user data and schema is not validated by the application. Some of the common injections are XSS, SQL, NoSQL, OS command, Object Relational Mapping (ORM), etc., causing data breaches and loss of revenue. Check this article on safeguarding against injection exploits A04:2021-Insecure Design During the development cycle, some phases might be reduced in scope which leads to some of the vulnerabilities. Insecure Design represents the weaknesses i.e., lack of security controls which are not tracked in other categories throughout the development cycle. Check this article on design flaws and mitigation A05:2021-Security Misconfiguration This occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. XML External Entities (XXE), which was previously a Top 10 category, is now a part of security misconfiguration. Check this article on protection against misconfiguration vulnerabilities A06:2021-Vulnerable and Outdated Components Applications used in enterprises are prone to threats such as code injection, buffer overflow, command injection and cross-site scripting from unsupported, out of date open-source components and known exploited vulnerabilities. Utilizing components with security issues makes the application itself vulnerable. Intruders will take use of this defects and exploit the deprecated packages thereby gaining access to backend applications. Check this article on finding outdated components A07:2021-Identification and Authentication Failures Confirmation of the user's identity, authentication, authorization and session management is critical to protect applications against authentication-related attacks. Apps without valid authorization, use of default credentials and unable to detect bot traffic are some of the scenarios in this category. Check this article on identifying and protection against bots A08:2021-Software and Data Integrity Failures Software and data integrity failures occurs when updates are pushed to the deployment pipeline without verifying its integrity. Insecure Deserialization, which was a separate category in OWASP 2017, has now become a part of this larger category set. Check this article on software failures protection A09:2021-Security Logging and Monitoring Failures As a best recommendation, we shall always log all incoming request details and monitor application for fraudulent transactions, invalid logins, etc. to identify if there are any attacks or breaches. Applications without logging capabilities provide opportunities to the attackers to exploit the application and may lead to many security concerns. Without logging and monitoring we won’t be able to validate the application traffic and can’t identify the source of the breach. Check this article for identifying logging issues A10:2021-Server-Side Request Forgery Server-Side Request Forgery (SSRF) attack is a technique which allows intruders to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. Attacker exploits this flaw by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information. Check this article which focusses on SSRF mitigation NOTE: This is an overview article of this OWASP series, check the below links to prevent these vulnerabilities using F5 Distributed Cloud Platform. OWASP Web Application Security Series: Broken access mitigation Cryptographic failures Injection mitigation Insecure design mitigation Security misconfiguration prevention Vulnerable and outdated components Identification failures prevention Software failures mitigation Security logging issues prevention SSRF MitigationMitigating OWASP Web Application Risk: Security Logging & Monitoring Failures using F5 XC Platform
Overview: The overview articlecovered a brief introduction about OWASP Top 10 Vulnerabilities related to Web Application. This article is continuation of the series and shows importance of Security Logging and Monitoring and how F5 Distributed Cloud (F5 XC) can contribute to mitigate the threats. It occupies position #10 in 2017 as Insufficient Logging and Monitoring and it has moved to position #9 in 2021. Introduction to Security Logging and Monitoring Failures: Security logging and monitoring failures is integrated as one process to log request such as logins, transactions during runtime and other operations which could cause harm to the application via attacks, breach attempts and suspicious behavior from user operations etc. and these activities must be monitored, and the decision must be taken at the earliest. An attack or breach attempt maynot be identifiable due to lack of logging and monitoring failures. Ignoring malicious activities could provide opportunities to the attackers to exploit the application and may lead to disallow valid users from accessing the application, loss of data, revenue, and reputation as well. Reports find that the mean time to identify the attack is around 200 days due to applications susceptible to modern day attacks and many other reasons as well. Generic use case demonstration: From the above logs it is tedious to categorise requests based on type and their severity and hence it is difficult to identify the attacks or anomalies from it. There is no point in logging the requests and not presenting them in easily understandable GUI format which helps security teams to detect and respond to the security events, if any. Professional and comprehensive Solution: A Web application should always have capability of logging events such as, User logins Warning and error messages Appropriate alerting threshold Attack Detection F5 XC stores log requests as mentioned above along with its detailed information. F5 XC categorizes the logs based on different dimensions of its characteristics and displays them in GUI template according to Customer needs which helps them to understand better about their behaviour. This elaborativeway of logging and displaying logs makes it easier for forensic analysis and investigation. Security Monitoring Dashboard gives an integrated view of overall primary essence of attack details for a given time stamp. Below is the information that can be extracted from the above dashboard picture. Displays security events by their type and top attacked sites from respective source IP’s along with geographical location as well. Top attack types by their signatures ID give detailed view on attacker’s approach to violate the application behaviour. Traffic is processed by aggregatingfor better understanding on categories such as Malicious Users, Security Events, DDoS tabs etc, as mentioned above. This provides critical intelligence of application security at your fingertips. Filtering enables the security team to easy debug and identify the issues. It helps in narrowing down to identify the abnormal behaviour based on multiple parameters like country, URL, region etc. F5 XC enhances the alerts with additional information for the customers to make decisions faster. Along with above dashboard, performance monitoring dashboard gives information on performance and latency of each request which makes F5 XC logging more comprehensive. From the above dashboard we can observe request rate, throughput rate, top URL accessed which tells us about the performance of the application. Following tabs such as Metrics, Requests etc, give a detailed view on Traffic rate and Individual traffic requests parameters reaching the application. Conclusion: F5 XC comes with modern UI templatesand graphical representation especially when it comes to Logging and Monitoring Failures for better analysis. With the modern-day attacks growing drastically these eases application developers’ worry about prioritizing the attacks and malicious activities. This level of intelligence in Logging and Monitoring helps to bring down the mean time to identify the attack to almost immediate. This makes F5 XC more professional and comprehensive. Related Links: OWASP Top 10: 2021 Vulnerability List Overview Owasp.org/Security_Logging_and_Monitoring_FailuresMitigating OWASP Web Application Risk: SSRF Attack using F5 XC Platform
Introduction to SSRF attack: In recent OWASP Web Application Top 10 report, SSRF is observed as one of the widely happening web application attack. Please refer to OWASP WebApp Top10 article for more details on Top 10 vulnerabilities. This article demonstrates the SSRF attack and its mitigation technique using F5 Distributed Cloud platform. Server-Side Request Forgery (SSRF) attack is a technique which allows an attacker to manipulate the server-side application vulnerability and make a malicious request to the internal-only resources. These internal resources are not intended to be exposed to the outside world, instead they are used by the web application to fetch configurations such as Metadata, connect to internal databases and read the data, communicate with the peer web applications. Attacker exploits the web application by modifying/crafting a URL which forces the server to retrieve and disclose sensitive information from the internal servers which are not accessible from outside world. Demonstration: In this demonstration, we will see how to generate a simple SSRF attack and mitigate it using F5 Distributed Cloud (F5 XC) platform. We are using: AWS instance with Docker DVWA vulnerable application installed as container to act as a target for the SSRF attack F5 Distributed Cloud (F5 XC) Platform for mitigation Brief on SSRF attack scenario in AWS: The AWS instance uses an internal web service to obtain its metadata i.e., instance specific information and this metadata service can be accessed only from the AWS instance. When EC2 instance requires any kind of metadata, it initiates a request to this service and the information gets served according to the request made. AWS uses 169.254.169.254 address to fetch the Instance metadata. As shown in the above architecture, a vulnerable application is deployed in an AWS instance. Attackers can access the application and try to exploit this vulnerable application. This can be done by modifying orproviding a URL that will initiate a request from the AWS instance to the internal web service and retrieve the sensitive metadata. Step by Step process: Launch an EC2 instance. Deploy DVWA application in the instance and make sure the application is up and running. Configure HTTP load balancer in F5 XC without enabling WAF policy. Please follow below provided steps on how to configure F5 XC HTTP load balance. Access the backend vulnerable application using configured load balancer domain. Wait for the application to load and login to the application. Navigate to “File Inclusion” page in the application. In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/ Observe that application page displays sensitive metadata of the EC2 instance. The retrieved metadata will be displayed on the vulnerable application as below. Configuration of HTTP Load balancer for mitigation of attack: Step 1: Creation of Origin Pool From your desired namespace, navigate to Manage > Load Balancers > Origin pools. Click on "Add Origin Pool" and provide a name for Origin pool. Configure Origin server details with valid Port details. Step 2: Configuration of Load Balancer with WAF enabled Navigate to Manage -> Load Balancers -> HTTP Load Balancers Click on "Add HTTP load balancer" and provide a name for the Load Balancer Provide valid domain name and choose appropriate load balancer type under Basic Configuration Associate the above created Origin Pool in the load balancer. Enable “Web Application Firewall”and create a WAF configuration with Blocking mode Click on Continue and observe that above created WAF configuration is being used. Click on “Save and Exit”. Step 3: Access the vulnerable application and repeat the attack scenario. In browser, access the backend application using configured load balancer domain. Wait for the application to load and login to the application. Navigate to “File Inclusion” page in the application. In the URL, modify the value of query parameter ‘page’ to http://169.254.169.254/latest/meta-data/ Observe that page cannot read metadata of the server and request gets blocked due to WAF policy. Step 4: Validate logs and blocked request details Navigate to Virtual Hosts -> HTTP Load Balancers -> choose appropriate load balancer -> Security Monitoring -> Security events Observe that malicious request gets blocked due to applied WAF policy Expand the request and observe details about blocked request Conclusion: As you can see from the above demonstration, SSRF attacks can be mitigated by configuring a WAF policy in F5 Load balancer which automatically detects attack signature and block them. Reference Links: F5 Distributed Cloud Services F5 Distributed Cloud WAFMitigating OWASP Web Application Risk: Injection exploits using F5 Distributed Cloud Platform
This article is in continuation of the owasp web application security series and is intended to give insights into injection attack category.Checkherefor overview article. Introduction to Injection vulnerability: An application is vulnerable to attack when: Provided data is not validated by the application. User requested schema is not being analyzed before processing. Data is used within search parameters to extract additional and sensitive records. SQL commandsare used in dynamic queries and commands. If user tries to use Cross-site Scripting to get some unauthorized data. Some of the common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), Etc. Step by step process: Version: Cloud Console at the time of article: crt-20220510-1579 Step1: Login to distributed cloud console and navigate to Load balancers menu, then expand “Security” section and then click on “App Firewall” Step2: Click “Add App Firewall” button and provide some name. Keep default options and save new firewall. Step3: Navigate to Manage section and select “HTTP Load Balancers” in load balancers drop-down option. Step4: Select 3 dots available in Action column besides your application load balancer and select “Manage Configuration”. Step5: In top right corner click on “Edit Configuration” button and navigate to “Security Configuration” section available on left menu. Step6: Disable service policies, Bot-Defense and Rate-Limiting features. In WAF config section enable App Firewall and select your firewall created in Step2. “Save and Exit” the load balancer dialog. Step7: Copy the load balancer domain, open a browser and open the copied domain. Validate you can access your application. Step8: Next in browser URL, click on Sign-in button, add SQLinjection attack script “or '1'='1” in email field, some random password and click on “Confirm” button. Validate your application is still accessible and request is not blocked with message of invalid email address. Step9: In cloud console page navigate to “Virtual Hosts” section and then select HTTP Load Balancers. Select “Security Monitoring” link for your application load balancer. In Dashboard validate new security events are generated with your IP and location. Navigate to the Security Events section and check the latest log request details. Solution: To mitigate these injection attacks, navigate to Firewall section and in “App Firewall” configuration change “Enforcement Mode” to Blocking, keep default options in other fields and save firewall. Next in browser try to pass above same SQL injection attack in username field of Sign-in page, validate your request is blocked and support-id is displayed in response as below: In Distributed Cloud Console navigate to security events section, expand the latest requests, filter logs with your request-ID and validate you can see the request log as below: Conclusion: As shown above, OWASP Top 10: Injection attacks can be mitigated by configuring WAF firewall in Blocking mode thereby preventing data breaches and even application downtime. Stay tuned for more exciting details on how F5 Distributed Cloud can protect your web applications against other OWASP top ten vulnerabilities. For further information click the links below: OWASP Top 10 - 2021 Configuring load balancer in cloud console Security features in cloud console Steps to delegate domain in cloud consoleMitigating OWASP Web Application Risk: Broken Access attacks using F5 Distributed Cloud Platform
This article is in continuation of the owasp series and will cover broken access control.Check here for overview article. Introduction to Broken Access Control attack: Access controls enforces policy such that users cannot act outside of their intended permissions. Also called authorization, allows or denies access to your application's features and resources. Misuse of access control enables: Unauthorized access to sensitive information. Privilege escalation. Illegal file executions. There are many ways to infiltrate application servers using broken access controls and we are going to focus on the 2 scenarios below and how to mitigate them. Scenario 1: Broken access + SQL injection attack Instead of logging with valid credentials,attacker uses SQL injection attacks to login as another standard or higher privileged user, like admin.We can also say this is broken authentication, because an attacker authenticated to a system using injection attack without providing valid credentials. For this demo I am using OWASP Juice shop (reference links at bottom for more info). Step1: Please follow steps suggested in Article1 to configure HTTP load balancer and WAF in cloud console. Make sure WAF is configured in Monitoring mode to generate the attack. Step2: Open a browser and navigate to the login page of the application load balancer. In the Email field provide “' OR true --” and any password as below: Step3: Validate you can login to application as administrator as below: Scenario2: File upload vulnerability Any file which has the capability to harm the server is a malicious file.For example, a php file which has some dangerous php functions like exec () can be considered as a malicious file as these functions can execute OS command and can remotely provide us the control of the application server. Suppose there is a file upload functionality in the web application and only jpeg extension file is allowed to be uploaded. Failing to properly enforce access restrictions on file properties can lead to broken access control attacks providing attackers a way to upload potentially dangerous files with different extensions.For this demo I am using DVWA as the vulnerable testing application (reference links at bottom for more info). Step by step process: Step1: Open a notepad editor and paste below contents and save to desktop as malicious.php Step2: Open a browser and navigate to the application load balancer URL. Login to DVWA application using admin/password as the credentials. Click on “File Upload” option in left side of the menu section. Step3: This page is used to upload images with extensions .jpeg, .png, .gif etc. But this demo application doesn’t have file restrictions enabled making attackers to upload any file extensions. Click on “Choose File” button and upload above created .php file. Step4: Note the location displayed in the message, open the URL in the browser and validate we can see all the users available as below. Solution: To mitigatethese attacks, navigate to Firewall section and in “App Firewall” configuration make sure “Enforcement Mode” is set to “Blocking” as below: Next in browser try to generate above scenarios and validate your request is blocked as below. Login Mitigation: Illegal File Upload mitigation: Illegal File Execution mitigations: In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why request was blocked. Conclusion: As shown above, OWASP Top 10: Broken access control attacks can be mitigated by configuring WAF firewall in “Blocking” mode. For further information click the links below: OWASP - Broken access control File Upload Vulnerability OWASP Juice Shop DVWAMitigating OWASP Web Application Risk: Cryptographic Failures using F5 Distributed Cloud Platform
Introduction to OWASP: Introduction article covered details of OWASP and 3 more articles in sequence covered Injection, broken access and authentication failures (check reference links for more details). This 4th article is in continuation of the series and will cover Cryptographic Failures. Introduction to Cryptographic Failures: In 2017 this attack is known as Sensitive Data Exposure, which focuses on failures related to cryptography which often lead to exposure of sensitive data. For this demo we are using OWASP Juice Shop as a vulnerable application which is exposing some files in ftp server location as below. This website has file type limitations kept in place to restrict users from downloading only .md/,pdf files. For example, let’s say we have a file with the name eastere.gg file which has some sensitive details and when we try to download directly, we get 403 error as below: Step by step testing process: Step1: Please follow the suggested steps here to configure HTTP load balancer and WAF in cloud console. Make sure WAF is configured in Monitoring mode only to analyze the attack. Step2: Hackers can find a way to bypass this file cryptographic restriction. For example, as shown below we can intercept the outgoing request using burp suite and just by adding null byte to the filename we are able to download the file (%2500.md is a null byte which is equal to empty space in cryptography). Prevention: Below are some of the best practices suggested to prevent this attack: Identify which data is sensitive according to regulatory requirements, or business needs. Don't store sensitive data unnecessarily. Make sure to encrypt all sensitive data at rest. Disable caching for responses that contain sensitive data. Apply required security controls as per the data classification. Do not use legacy protocols such as FTP and SMTP for transporting sensitive data. Store passwords using strong hashing algorithms. Always use authenticated encryption instead of just encryption. Avoid deprecated cryptographic functions and schemes, such as MD5, SHA1, etc. Mitigation using F5 Distributed Cloud Services: To mitigate these attacks, navigate to Firewall section and in “App Firewall” configuration make sure “Enforcement Mode” is set to “Blocking” as below: Next in browser try to generate above scenarios and validate your request is blocked as below. In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why request was blocked. Conclusion: As shown above, these types of cryptographic failures can be mitigated by configuring WAF on load balancer thereby preventing sensitive data exposure. For further information click the links below: OWASP - Cryptographic Failures Mitigation OWASP - Authentication Failures using F5 XC Mitigating OWASP Top 10 2021: A01 Broken Access attacksMitigating OWASP Web Application Risk: Identification and Authentication Failures using F5 XC
Introduction to OWASP: Introduction article covered details of OWASP 2nd article covered broken access attacks This 3rd article is in continuation of the series which will cover Identification and Authentication Failures. Introduction to Identification and Authentication Failures: In our daily activities confirmation of the user's identity, authentication, authorization and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application: Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords. Permits brute force or other automated attacks. Permits default, weak, or well-known passwords, such as "password", “default” or "admin". Uses plain text, encrypted, or weakly hashed passwords data store. Introduction to credential stuffing: This is the common attack attackers typically use with lists of known passwords with automation tools like Selenium, Postman, etc. and get authenticated. Suppose an application does not implement automated threat or credential stuffing protection, attacker can exploit the login page using this credential stuffing attack. Step by step process: Step1: Please follow steps as per link to configure HTTP load balancer. Do not configure any security policies or bot-defense on this load balancer. Step2: Develop a selenium script to automate UI login page which uses credentials from creds.csv file as below: from selenium import webdriver import random import string import os import csv import sys import argparse import time driver = webdriver.Chrome("chromedriver.exe") parser = argparse.ArgumentParser() parser.add_argument("--backend", help="Use the unprotected backend airline app", action="store_true") args = parser.parse_args() if args.backend: target = 'https://jbair.f5-hyd-demo.com/user/signin' else: target = 'https://jbair.f5-hyd-demo.com/user/signin' def loginuser(name, password): driver.get(target) driver.find_element_by_xpath('/html/body/div[2]/div/form/div[1]/input').send_keys(name) driver.find_element_by_xpath('/html/body/div[2]/div/form/div[2]/input').send_keys(password) driver.find_element_by_xpath('/html/body/div[2]/div/form/button').click() f = open('creds.csv') csv = csv.reader(f) for row in csv: print (row[0]) print (row[1]) if loginuser(row[0], row[1]) is True: break time.sleep(1) driver.close() Step3: Execute the above script to generate credential stuffing attack and to identify if anyone of the provided credentials is working. In above steps we have seen how hackers were able to find valid credentials from large combinations of leaked passwords using simple automation scripts. Prevention: Below are some of the best practices suggested to prevent this credential stuffing attack: Multi Factor Authentication Secondary passwords Captcha solving Rate limiting requests Auditing failed logins Mitigation using F5 distributed cloud: Please follow steps as per link to configure bot defense on load balancer. Make sure configurations are correct and mitigation action is set to Block as below: Rerun the above script again and validate your request is blocked as below. In Security monitoring Section, Navigate to Bot defense section to check the overview of bot defense. As shown below dashboard shows selenium bot type detected as threat intelligence. It also gave details about endpoints, Humans & Bot request counts and IP where bot requests were generated. Navigate to Requests and Bot traffic overview tabs to understand the reason why requests were blocked as below: Conclusion: As shown above, brute force attacks can be mitigated by configuring Bot-Defense on load balancer thereby preventing forceful browsing and credential stuffing. For further information click the links below: OWASP - Authentication Failures F5 XC Bot-Defense Introduction Credential Stuffing mitigationMitigating OWASP Web Application Risk: Software and Data Integrity Failures using F5 XC Platform
Overview: This article is a continuation of the series of articles on mitigation of OWASP Web Application vulnerabilitiesusing F5 Distributed Cloud platform (F5 XC). Introduction to OWASPSoftware and Data Integrity Failures: Automating the software release process using CI/CD pipelines has helped organizations to significantly speed up their product delivery, reduce cost, apply updates/fixes in a short span of time etc. But at times to match up with frequent releases/updates security best practices are overlooked allowing attackers to infiltrate into the deployment pipeline and inject their malicious code eventually exposing end users to risk. Software and data integrity failures is one of the newest categories added as part of OWASP Web App Top 10 list. This vulnerability occurs when updates are pushed to the deployment pipeline without verifying its integrity. Insecure Deserialization, which was a separate category in OWASP 2017, has now become a part of this larger category set. The above image depicts a possible attack scenario where the attacker comes up with an open-source repository embedding malicious code in it. As a part of an update, the compromised package is imported into the repository and is deployed in the production environment resulting a wide distribution of malicious code allowing attackers to sneak into the end user’s network. Insecure Deserialization: Before understanding insecure deserialization, we should first be aware of serialization and deserialization ‘Serialization’ is a process of converting objects or data structures into a convenient format to make its storage or transmission easier, it is used to preserve the current state of an object. On the other hand, ‘Deserialization’ is a process of reverting back the serialized output (byte stream) into its original form (object). Now as we know about Serialization & Deserialization, we can start discussing insecure deserialization and how this vulnerability can pose a security concern. Insecure Deserialization occurs when user inputs are deserialized by a website in an unsafe manner and attackers can take advantage of it by modifying serialized object content to misuse application logic for their benefit. It is also known as object injection vulnerability. Now, it's time to have a look at the demonstration attack scenario and find out how F5 XC platform can help to mitigate this security event. Demonstration: For the purpose of this demonstration, we have already hosted a vulnerable application (XVWA) in an instance and are using F5 XC HTTP Load Balancer (LB) to route client requests to our vulnerable application server. To find out the configuration steps for the HTTP LB in F5 XC console follow this document. Note: XVWA (Xtreme Vulnerable Web Application) is a buggy application written in PHP/MySQL for learning application security. For more information refer to the repository. Attack Scenario: As you can see from the above screenshot, serialized data is added as a query parameter in the URL as soon as the button is clicked which hints the possibility of insecure deserialization vulnerability. The below code snippet shows the web application’s implementation, as you can see in the code “unserialize()” method is used for unserializing user input parameter ‘r’ from the request, when unserialize method is called, “__wakeup()” method will automatically get triggered, “__wakeup()” method will check whether inject variable is set or not and performs an eval operation on inject value if “isset()” returns true. Now, as we know the flow of execution, we can manipulate user request by crafting a serialized input to perform command injection attack In the below code snippet, we have created same class, as we are aware that inject variable’s value will get executed as a PHP code, we have used system() method to execute OS commands on host operating system, at the end created an object of the class and printed serialized object value. Serialized data explanation: [“O:18:"PHPObjectInjection":1:{s:6:"inject";s:17:"system('ps -ef'); ";}”] ‘O’ - Stands for Object, ‘18’ - Length of class name, ‘PHPObjectInjection’ - Class name, ‘1’ – Number of variables inside the class, ‘s’ – String, ‘6’ - Length of variable name, ‘inject’ – Variable name, ‘s’ – String, ‘17’ – Length of command, ‘system('ps -ef'); ";}’ - Command Now, as we have custom serialized data, we can use it to perform command injection attack. Below screenshot displays successful exploitation of vulnerability, as we got the list of running processes inside the server. Prevention: Step1: Login to F5 XC console and open the configuration page of your HTTP LB Step2: Enable Web Application Firewall (WAF), create/configure WAF policy as per your need and add it to your LB. For this demonstration we did the configuration as below: Step3: Repeat the attack scenario As you can see from the above screenshot, the F5 XC WAF engine has successfully identified and mitigated the attack which could otherwise have impacted adversely. At the end, monitor F5 XC Security Event Logs to get the details about the blocked attack Conclusion: With the ever-evolving threat landscape it has become critically important to securely manage your deployments. F5 XC security solution suite can help to achieve the same in a super simplified manner, as we have seen in the demonstration it only requiresadding adefault WAF policy in blocking mode to defeat the demo attack scenario. References: PHP methods used: isset(): It determines if a variable is declared and is different than null. For more information refer to the documentation eval(): It evaluates string as PHP code. For more information refer to the documentation system(): It can be used to execute OS commands and display the output. For more information refer to the documentation serialize(): It generates a storable representation of value. For more information refer to the documentation unserialize(): It creates a php value from stored representation. For more information refer to the documentation Magic Methods: They are the special methods which will override PHP's default action when certain actions are performed on an object (__wakeup() is one of the magic methods which will be called automatically when object is unserialized). For more information refer to the documentation For more details, follow below links: OWASP Top 10 - 2021 F5 Distributed Cloud WAAP Overview of OWASP Web Application Top 10 2021Mitigating OWASP Web Application Risk: Security Misconfiguration using F5 XC Platform
Overview: This article is a continuation of the series of articles on mitigation of OWASP Web App Top 10 vulnerabilities using F5Distributed Cloud platform (F5 XC). Introduction to OWASP Security Misconfiguration: Security Misconfiguration is a vulnerability that occurs when security best practices are overlooked allowing attackers to get into the system utilizing the loopholes. The severity of this risk can be identified by the fact that it moved one step up from 6th position in the previous edition of OWASP top 10 (2017) to 5th position in the current edition (2021). A4:2017-XML External Entities (XXE), which was previously a separate category of risk, is now a part of security misconfiguration. Below are a few sample scenarios which highlight that the application might be vulnerable to security misconfiguration: Unnecessary features like ports, pages, privileges or services are enabled or installed. Default accounts and their passwords remain unchanged. Over sharing information while doing error handling. Forget to apply security patches. Vulnerable to XXE attacks. Demonstration: In this demonstration we will see how we can exploit the XXE vulnerability in ‘Mutillidae’ application and later steps to prevent it by using F5 Distributed Cloud Web App and API Protection (WAAP). Note: Mutillidae is a free and opensource web application that is deliberately designed to be vulnerable and is used for web security training. For more details you can refer OWASP Mutillidae II documentation. Introduction to XXE (XML eXternal Entity): XXE attack targets an application that parses XML input. This attack occurs when a weakly configured XML parser processes XML input containing a reference to an external entity. Step by step process: In the below steps we will first set the enforcement mode as ‘Monitoring’ in the app firewall policy, perform the attack and observe security event logs. This will give us an idea about the application vulnerability and WAF engine efficiency in detecting the threat, andat a later stage we will set the enforcement mode as ‘Blocking’,to let the WAF engine block any such malicious request in future. Step1: Create a Load Balancer (LB) in F5 Distributed Cloudconsole and add the application server as an origin pool member. Refer to F5 Distributed Cloud docs for configuration steps. Step2: Create a WAF policy with enforcement mode as ‘Monitoring’ and add it to your LB Select WAAP service from DistributedCloud console homepage. Navigate to Manage->App Firewall, click ‘Add App Firewall’. Enter a name, select ‘Enforcement Mode’ as ‘Monitoring’, click ‘Save & Exit’. Navigate to Manage->Load Balancers->HTTP Load Balancer. On the right side of your LB click on three dots (ellipsis) and select ‘Manage Configuration’ as an action, click on ‘Edit Configuration’. Scroll down, in ‘Security Configuration’, ‘Enable’ WAF (Web Application Firewall) and select the app firewall created. Click ‘Save & Exit’. Step3: Identify and exploit the XXE vulnerability of the application and monitor the security events logs in Distributed Cloudconsole. Note: Among various types of XXE attacks, we have chosen one to retrieve the contents of a file (/etc/passwd) containing information related to the users on the system like username, user id etc. from the server’s file system. on the vulnerable application as the enforcement is set to ‘Monitoring’ mode in the app firewall policy. Step4: Modify the enforcement mode of the firewall policy to ‘Blocking’ Step5: Repeat Step3. Conclusion: As you can see from the demonstration, the F5 Distributed Cloud WAFengine was able to successfully detect and restrict the attempt to exploit the XXE vulnerability. Reference Link: Overview of OWASP Web Application Top 10 2021Mitigating OWASP Web Application Risk: Vulnerable & Outdated Components using F5 XC Platform
Introduction to OWASP TOP 10 2021: The Overview article on mitigation of OWASP Top 10 Application Security risk categories usingF5 Distributed Cloud Web App and API Protection (WAAP) covered details about OWASP & mitigation strategy for Injection attacks followed by 3 more articles in sequence covering Broken Access, Authentication and Cryptographic Failures, Security Misconfiguration (check reference links at the end of this article for more details). This article is in continuation of the series and will cover A06:2021 – Vulnerable and Outdated Components. Introduction to Vulnerable and Outdated Components: Vulnerable and Outdated Components was in 2017 OWASP Top 10 list with a name of “Components with Know Vulnerabilities” and has secured a better position now from #9 to #6 in 2021 OWASP Top 10 list. Applications used in enterprises often contain open-source components such as libraries and frameworks (e.g., Junit, Log4J, SonarQube, Open SSL). Such applications are prone to threats such as code injection, buffer overflow, command injection and cross-site scripting from unsupported, out of date open-source components and known exploited vulnerabilities. Since numerous computer program components run with the same privileges as the application itself, any vulnerabilities or imperfections within such components can result in a danger to the software/application. Utilizing components which are prone to vulnerabilities makes the application vulnerable to attacks that target any portion of the application stack which makes the security of the application unstable causing threat to the organization’s security. Using F5 Distributed Cloud Web Application Firewall (F5 XC WAF) we can identify these vulnerabilities and prevent the impact by configuring the WAF. Demonstration: In this demonstration we will exploit one of the vulnerabilities of PHP server, admin console page (phpMyAdmin.php) which has sensitive info related to the backend server like homepage location, user info and relative credentials etc. For the demo, we are using ‘Mutillidae’ vulnerable application as the backend server (check reference links for more details). We will also see the detailed prevention steps using Distributed Cloud WAAP. Steps: In this process, we will configure the enforcement mode as ‘Monitoring’ in the application firewall policy, exploit the vulnerability and will observe the security event log so that we will come to know how the WAF engine is efficiently identifying the threats. Create a Load Balancer (LB) in Distributed Cloud console and add the Mutillidae application as an origin pool member, Refer F5 Distributed Cloud Tech Docs for configuration steps. Create a firewall policy with enforcement mode as ‘Monitoring’ and add it to your LB Select WAAP service from Distributed Cloud console homepage. Navigate to Manage->App Firewall, click ‘Add App Firewall’ Enter a name, select ‘Enforcement Mode’ as ‘Monitoring’, click ‘Save & Exit’ Navigate to Manage->Load Balancers->HTTP Load Balancer. On the right side of your LB click on three dots (ellipsis) and select ‘Manage Configuration’ as an action, click on ‘Edit Configuration’ Scroll down, in ‘Security Configuration’, ‘Enable’ WAF (Web Application Firewall) and select the firewall created. Click ‘Save & Exit’ Access the above-mentioned vulnerable PHP server admin page (phpmyadmin.php) and monitor the security event logs. The above screenshot will show you the admin page that provides sensitive information related to database server which should not be exposed to the outside world. Security Event Logs: To verify the logs, Select Web application & API Protection (WAAP) service from Distributed Cloud console homepage. Navigate to Overview --> Dashboard, click on ‘Security Events’ Since the WAF is in monitoring mode the WAF engine has detected and allowed the PHP admin vulnerability as shown below. The above screenshot shows the PHP vulnerability signature details with matching info of the security event. Modify the enforcement mode of the firewall policy created to ‘Blocking’ as below Repeat Step3. In the above screenshot you can see how the Distributed Cloud WAF engine has successfully detected and blocked the known vulnerability. Security Event Logs: Refer step-3 to navigate to dashboard Since the WAF is in blocking mode the WAF engine has detected and blocked the PHP admin vulnerability as shown below. In the above screenshot you can see the php admin page attack has been successfully identified and blocked by Distributed Cloud WAF engine. Conclusion: As you can see from the demonstration, the F5 Distributed Cloud WAF was successfully able to detect and restrict the attempt to exploit the known vulnerability of php admin page, a part of vulnerable and outdated components category. For further information click the links below: OWASP Vulnerable and Outdated Component OWASP Mutillidae II documentation F5 Distributed Cloud WAAP
