Content
It has been often said that Open-source software (OSS)built the internet as many of the major components (eg. Unix/linux operating systems, Apache/Nginx web servers, MySQL/Maria Databases, etc.) used, are based on open-source platforms. While offering numerous benefits such as transparency, community-driven development, and cost-effectiveness, OSS is not immune to vulnerabilities, including those related to Distributed Denial of Service (DDoS) attacks.
Open source as a gateway for DDoS attacks
Several types of DDoS exposure exist within the realm of open-source software:
- Code Vulnerabilities: Open-source software relies on community contributions for its development and maintenance. While this fosters innovation and collaboration, it also means that the codebase is accessible to a wide range of individuals, including potential attackers. Code vulnerabilities, such as buffer overflows, injection flaws, or insecure authentication mechanisms, can be exploited by malicious actors to launch DDoS attacks against systems running open-source software.
- Dependency Risks: Many open-source projects depend on third-party libraries and components to function properly. However, these dependencies may themselves contain vulnerabilities that could be exploited to facilitate DDoS attacks. If a critical dependency is compromised, it could have cascading effects on the security and stability of the entire software ecosystem.
- Lack of Timely Updates: Open-source projects often rely on volunteer contributors to identify and patch security vulnerabilities. Consequently, there may be delays in releasing updates or patches to address newly discovered vulnerabilities. This lag time exposes systems running open-source software to potential DDoS attacks exploiting known weaknesses that have not yet been remediated.
- Limited Support and Documentation: While many open-source projects have vibrant communities that provide support and documentation, not all projects receive equal attention or resources. Some projects may lack comprehensive documentation or dedicated support channels, making it challenging for users to effectively secure and maintain their systems against DDoS attacks.
- Resource Constraints: Open-source projects may operate with limited resources, including funding, manpower, and infrastructure. As a result, developers and maintainers may prioritize features and bug fixes over security enhancements, leaving systems vulnerable to DDoS attacks that exploit weaknesses in the software’s architecture or implementation.
- Misconfigurations and Poor Practices: Improper configuration or deployment practices can inadvertently expose open-source software to DDoS attacks. For example, leaving default settings unchanged, failing to implement access controls, or neglecting to configure rate limiting and throttling mechanisms can make systems more susceptible to exploitation by DDoS attackers.
- Plugin Vulnerabilities: this is specific to Open-source Content Management System (CMS) platforms which often rely on plugins or extensions developed by third-party contributors to extend functionality. However, these plugins may contain vulnerabilities that attackers can exploit to launch DDoS attacks. Vulnerabilities such as insecure coding practices, input validation flaws, or lack of proper authentication mechanisms in plugins can be leveraged to compromise the CMS and disrupt website availability.
- Poor Configuration and Management Practices: Improper configuration or management of open-source CMS platforms can also expose them to DDoS risks. For example, failure to implement caching mechanisms, content delivery networks (CDNs), or rate limiting controls can make websites more susceptible to traffic spikes and DDoS attacks
A good example of point number 8 was observed with one of our customers recently who were operating an Open Source CMS based on the .NET framework on their origin web server. The customer had his site operating under Link11 but had disabled the cloud WAF mitigation capabilities and put the WAF into learning mode only. The customer failed to address a vulnerability that had been disclosed for a while, where a nefarious visitor could leverage an installer file to create a super user account and take control of the server. Additionally, the admins of this server failed to rename the default configuration and secure the directories with any type of access control, resulting in their system getting compromised.
We worked with the client to help identify how the compromise occurred. Using our logs we were able to show that a single user scanned their site, identified the default directory containing the installer file in question and then proceeded to use the installer file to root the server. A breakdown of the violations seen with our WAF in learning mode, and which would have been blocked if put in blocking mode, can be seen here:
28 violations were caught by WAF in learning mode. These were caused by:
<attacker IP redacted>
▪ /Portals/0/wi1.aspx
▪ • 1203: Directory Traversal Pattern: c:\\
▪ • 1500: Invalid File Extension
▪ • 10: Invalid hex encoding, null bytes
▪ /offline/wi1.aspx
▪ • 1203: Directory Traversal Pattern: c:\\
▪ • 10: Invalid hex encoding, null bytes
▪ /Install/InstallWizard.aspx/IsInstallerRunning
▪ • 16: Empty POST.
▪ /Install/InstallWizard.aspx/ValidateInput
▪ • 16: Empty POST.
▪ /Install/InstallWizard.aspx/ValidatePassword
▪ • 16: Empty POST.
▪ /Install/InstallWizard.aspx/VerifyDatabaseConnection
▪ • 16: Empty POST.
▪ /Host/Host-Settings/portalid/0
▪ • 1000: SQL Injection Pattern: select|union|update|delete|insert|table|from|ascii|hex|
unhex|drop
▪ • 1002: SQL Injection Pattern: 0x
▪ • 1005: SQL Injection Pattern: |
▪ /Install/InstallWizard.aspx/RunInstall
▪ • 16: Empty POST.
▪ /Login
▪ • 1000: SQL Injection Pattern: select|union|update|delete|insert|table|from|ascii|hex|
unhex|drop
▪ • 1002: SQL Injection Pattern: 0x
▪ • 1005: SQL Injection Pattern: |
▪ • 1013: SQL & XSS Injection Pattern: ‘
- 1016: SQL Injection Pattern: #
A visual representation of these violations caught by our WAF on a per URI basis is as follows (numbers cited in the middle of the graph are internal violation codes used in our WAF engine):
Had the customer kept the WAF in blocking mode, these incursions would have easily been thwarted.
To mitigate these DDoS exposure risks, organizations relying on open-source software should adopt robust security practices, including regular vulnerability assessments, timely updates and patches, secure configuration management, and active participation in the open-source community. Additionally, leveraging cloud DDoS protection solutions, such as Link11, can help organizations detect and mitigate potential threats before they impact their systems and operations, obfuscate the customer IT stack solution from nefarious actors looking for vulnerabilities on specific OSS platforms, and roll out zero day mitigation features faster than an organization IT department which may not have the requisite resources and/or are hampered by slow internal change control processes.
Protect yourself proactively
Our cyber security experts are always available if you would like to inquire about your current security setup without obligation. We will be happy to advise you on how your existing protection can be optimized and which steps would be worth taking to maximize the protection ratio.
Share this post
