CVE-2017-14706
📋 TL;DR
This vulnerability in DenyAll Web Application Firewall allows unauthenticated attackers to obtain authentication tokens by making a debug request to a specific endpoint. Successful exploitation could lead to remote code execution. Affected systems include DenyAll WAF versions before 6.4.1 and i-Suite versions 5.5.0 through 5.6.
💻 Affected Systems
- DenyAll i-Suite LTS
- DenyAll i-Suite
- DenyAll Web Application Firewall
📦 What is this software?
I Suite by Denyall
I Suite by Denyall
I Suite by Denyall
I Suite by Denyall
I Suite by Denyall
I Suite by Denyall
⚠️ Risk & Real-World Impact
Worst Case
Complete system compromise via remote code execution, allowing attackers to take full control of the WAF and potentially pivot to internal networks.
Likely Case
Authentication token theft leading to unauthorized access to the WAF management interface and potential configuration changes.
If Mitigated
Limited impact if proper network segmentation and access controls prevent external access to vulnerable endpoints.
🎯 Exploit Status
Metasploit module available. Exploitation requires only a single HTTP request to the vulnerable endpoint.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 6.4.1 or later
Vendor Advisory: https://www.denyall.com/blog/advisories/advisory-unauthenticated-remote-code-execution-denyall-web-application-firewall/
Restart Required: Yes
Instructions:
1. Download DenyAll WAF version 6.4.1 or later from vendor portal. 2. Backup current configuration. 3. Apply the update following vendor documentation. 4. Restart the WAF service. 5. Verify the fix by checking version and testing the vulnerable endpoint.
🔧 Temporary Workarounds
Block vulnerable endpoint
allAdd WAF rule to block access to /webservices/download/index.php with typeOf=debug parameter
Add custom rule: DENY if PATH contains '/webservices/download/index.php' AND PARAM 'typeOf' equals 'debug'
Restrict access to management interface
allLimit access to WAF management interface to trusted IP addresses only
Configure network ACLs to restrict access to WAF management IP/ports to authorized administrative networks
🧯 If You Can't Patch
- Immediately implement network segmentation to isolate the WAF from critical internal systems
- Enable detailed logging and monitoring for any access attempts to the vulnerable endpoint
🔍 How to Verify
Check if Vulnerable:
Send HTTP GET request to https://[WAF_IP]/webservices/download/index.php?typeOf=debug and check if response contains iToken fieldCheck Version:
Check WAF management interface or run: denyall-cli versionVerify Fix Applied:
After patching, repeat the vulnerable check - should return error or no iToken field📡 Detection & Monitoring
Log Indicators:
- HTTP requests to /webservices/download/index.php with typeOf=debug parameter
- Unusual authentication attempts following token extraction
Network Indicators:
- HTTP GET requests with typeOf=debug parameter to WAF management interface
- Subsequent connections using extracted authentication tokens
SIEM Query:
source="denyall_waf" AND (url="/webservices/download/index.php" AND params="typeOf=debug")🔗 References
- https://github.com/rapid7/metasploit-framework/pull/8980
- https://pentest.blog/advisory-denyall-web-application-firewall-unauthenticated-remote-code-execution/
- https://www.denyall.com/blog/advisories/advisory-unauthenticated-remote-code-execution-denyall-web-application-firewall/
- https://github.com/rapid7/metasploit-framework/pull/8980
- https://pentest.blog/advisory-denyall-web-application-firewall-unauthenticated-remote-code-execution/
- https://www.denyall.com/blog/advisories/advisory-unauthenticated-remote-code-execution-denyall-web-application-firewall/
