Some HTTP and HTTPS requests may trigger reverse DNS (RDNS) lookups in ProxySG, ASG, and CacheFlow. When these products are configured with policy rules that use hostnames from RDNS lookup results, such requests may bypass security controls such as blocking a request, requiring user authentication, and performing payload scanning. This Security Advisory has Medium severity, but should be carefully evaluated for its potential impact in each customer environment.
CVE |Affected Version(s)|Remediation
All CVEs | 6.6 (when deployed as forward proxy, reverse proxy, or web application firewall) | RDNS lookups are disabled by default in the CLI global settings in 6.6.5.1. Upgrading to 6.6.5.1 does not affect RDNS lookup settings that customers have configured in policy prior to the upgrade. However, upgrading to 6.6.5.1 disables RDNS lookups if they have not been configured in policy. See Workarounds section for more details.
CVE |Affected Version(s)|Remediation
All CVEs | 3.4 (when policy RDNS lookups are enabled via the CLI) | All versions of CacheFlow disable RDNS lookups by default. See the Workarounds section to ensure that RDNS lookups are disabled.
CVE |Affected Version(s)|Remediation
All CVEs | 6.6 (when deployed as forward proxy, reverse proxy, or web application firewall) | RDNS lookups are disabled by default in the CLI global settings in 6.6.5.1. Upgrading to 6.6.5.1 does not affect RDNS lookup settings that customers have configured in policy prior to the upgrade. However, upgrading to 6.6.5.1 disables RDNS lookups if they have not been configured in policy. See Workarounds section for more details.
6.5 (when deployed as forward proxy, reverse proxy, or web application firewall) | RDNS lookups are disabled by default in the CLI global settings in 6.5.9.10. Upgrading to 6.5.9.10 does not affect RDNS lookup settings that customers have configured in policy prior to the upgrade. However, upgrading to 6.5.9.10 disables RDNS lookups if they have not been configured in policy. See Workarounds section for more details.
Severity / CVSSv2 | Medium / 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N) References| SecurityFocus: BID 91404 / NVD: CVE-2016-6594 Impact | Security control bypass
The Blue Coat products listed in the Affected Products section support policy rules that match on URL hostnames and hostname categories of HTTP and HTTPS requests. The products perform categorization using category mappings from multiple sources - user-defined categories in policy, local category databases, Blue Coat Web Filter (BCWF), and third-party category databases. When the server hostname of an HTTP/HTTPS request is not available, the affected products may perform a reverse DNS (RDNS) lookup on the server IP address to obtain the server hostname. The server hostname is not available when one or more of the following conditions apply:
Using hostnames from RDNS lookups may, under certain circumstances, prevent the policy from enforcing security controls, such as blocking the request, requiring user authentication, or performing payload scanning. Only the following policy rule types that use hostnames from RDNS lookups are affected:
Policy rules that match against categories from BCWF and third-party category databases are not affected. ProxySG and ASG appliances that use affected policy rules are vulnerable when deployed as a forward proxy, reverse proxy, or web application firewall (WAF).
ProxySG and ASG administrator users with write access can remediate this vulnerability by disabling reverse DNS (RDNS) lookups. The following CPL syntax can be used in ASG 6.6, ProxySG 6.5, and ProxySG 6.6:
restrict rdns
all
end
Administrator users can also use the ProxySG 6.5 and 6.6 Visual Policy Manager (VPM) to disable reverse DNS lookups:
Customers who need to enable RDNS lookups should enable them only for IP addresses and subnets that they control. The following CPL syntax can be used in ASG 6.6, ProxySG 6.5, and ProxySG 6.6:
restrict rdns
except
<list of IP addresses or subnets>
end
ProxySG 6.5.9.10, ProxySG 6.6.5.1, and ASG 6.6.5.1 introduces the following CLI global setting to enable/disable RDNS lookups:
#(config) policy restrict-rdns {all|none}
After upgrading to ProxySG 6.5.9.10/ProxySG 6.6.5.1/ASG 6.6.5.1 or later, the CLI global setting will be set to disable RDNS lookups by default. Note that enabling or disabling RDNS lookups in policy, as described above, overrides the new CLI global setting. Upgrading does not affect RDNS lookup settings that customers have configured in policy prior to the upgrade:
By default, CacheFlow 3.4 does not enable policy RDNS lookups. Customers who leave RDNS lookups disabled prevent attacks against CacheFlow. CacheFlow 3.4 administrator user can use the following CLI commands to check and disable the RDNS lookup setting:
Compatibility note: changing the RDNS setting in any of the affected Blue Coat products may impact existing policy evaluation. For example, if the policy uses RDNS to resolve internal IP addresses, disabling RDNS lookups could impact how the content filtering or URL hostname matching policy is applied. Only policy rules that use hostnames from RDNS lookups are affected. See Advisory Details section for a list of affected policy rule types. Please consult with your reseller or Blue Coat contact if you have any questions about how disabling RDNS lookups might affect your organization.
Thanks to Mike Brookes and Nathan Fowler for reporting this vulnerability.
2016-12-16 Added CVE number
2016-11-03 ProxySG 6.6.5.1 and ASG 6.6.5.1 add a new CLI global setting that disables RDNS lookups by default if they have not been configured in policy. SA status moved to Final.
2016-09-01 Clarified that only some ProxySG policy rule types are affected by RDNS lookups. Added recommendation that customers should only enable RDNS lookups in ProxySG on IP addresses that they control. ProxySG 6.5.9.10 adds a new CLI global setting that disables RDNS lookups by default if they have not been configured in policy. No patches will be provided for CacheFlow - all versions of CacheFlow disable RDNS lookups by default.
2016-07-15 Fixed a typo in the Acknowledgements section.
2016-07-14 initial public release