GHOST Vulnerability (CVE-2015-0235)
On 27 of January Qualys publisheda critical vulnerability dubbed “GHOST” as it can be triggered by the GetHOST functions ( gethostbyname*() ) of the glibc library shipping with the Linux kernel. Glibc is the main library of C language functionality and is present on most linux distributions. Those functions are used to get a corresponding structure out of a supplied hostname, while it also performs a DNS lookup if the hostname is a domain name and not an IP address. The vulnerable functions are obsolete however are still in use by many popular applications such as Apache, MySQL, Nginx and Node.js. Presently this vulnerability was proven to be remotely exploited for the Exim mail service only, while arbitrary code execution on any other system using those vulnerable functions is very context-dependent. Qualys mentioned through a security email list, the applications that were investigated but found to not contain the buffer overflow. Read more on the email list archive link below: http://seclists.org/oss-sec/2015/q1/283 Currently, F5 is not aware of any vulnerable web application, although PHP applications might be potentially vulnerable due to its “gethostbyname()” equivalent. UPDATE: WordPress content management system using xml-rpc ping back functionality was found to be vulnerable to the GHOST vulnerability. WordPress automatically notifies popular Update Services that you've updated your blog by sending aXML-RPCpingeach time you create or update a post. By sending a specially crafted hostname as paramter of xml-rpc ping back method the vulnerable Wordpress will return "500" HTTP response or no response at all after resulting in memory corruption. However, no exploitability was proven yet. Using ASM to Mitigate WordPress GHOST exploit As the crafted hostname should be around 1000 characters to trigger the vulnerability, limiting request size will mitigate the threat. Add the following user defined attack signature to detect and prevent potential exploitation of this specific vulnerability for WordPress systems. For version greater than 11.2.x: uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; re2:"/https?://(?:.*?)?[\d\.]{500}/i"; For versions below 11.2.x: uricontent:"xmlrpc.php"; objonly; nocase; content:"methodcall"; nocase; pcre:"/https?://(?:.*?)?[\d\.]{500}/i"; This signature will catch any request to the "xmlrpc.php" URL which contains IPv4 format hostname greater than 500 characters. iRule Mitigation for Exim GHOST exploit At this time, only Exim mail servers are known to be exploitable remotely if configured to verify hosts after EHLO/HELO command in an SMTP session. If you run the Exim mail server behind a BigIP, the following iRule will detect and mitigate exploitation attempts: when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { if { ( [string toupper [TCP::payload]] starts_with "HELO " or [string toupper [TCP::payload]] starts_with "EHLO " ) and ( [TCP::payload length] > 1000 ) } { log local0. "Detected GHOST exploitation attempt" TCP::close } TCP::release TCP::collect } This iRule will catch any HELO/EHLO command greater than 1000 bytes. Create a new iRule and attach it to your virtual server.Mitigating Remote Code Execution in "HTTP.sys" (CVE-2015-1635)
A critical Windows vulnerability in its HTTP stack ("HTTP.sys"), which was resolved in a recent Microsoft's Patch Tuesday release, could allow remote attackers to execute code on an IIS server with the privileges of the System account. A Proof-of-Concept code to check the existence of this vulnerability was soon to follow. Remote attackers could exploit the way "HTTP.sys" parses requests with a Range header including a very large byte range to crash the server or potentially run their shellcode. http://www.exploit-db.com/exploits/36773/ POC Information Bug details according to the POC More details on the available patch could be found in Microsoft’s security builletin MS15-034: https://technet.microsoft.com/library/security/MS15-034 Following user-defined signature will detect and mitigate attempts to exploit this vulnerability while using ASM. ASM versions including and above 11.2.x: headercontent: "range"; nocase; re2:"/bytes\s*=.*?[0-9]{10,}\b/Hi"; ASM versions including and below 11.1.x: headercontent: "range"; nocase; pcre:"/bytes\s*=.*?[0-9]{10,}\b/Hi";
Mitigating Ruby YAML.load Universal RCE Deserialization Gadget with BIG-IP ASM
Recently a new YAML deserialization gadget was published that may lead to arbitrary code execution when deserialized by supplying it to Ruby'sYAML.load function as input. Prior to this new gadget it was known that calling YAML.load on user supplied input is a bad idea, but this was only relevant to applications that are based on the Ruby on Rails web framework. In this case the published gadget is universal, meaning it will only depend on the existence of classes that are shipped with the default installation of Ruby, and thus it will be able to execute code in any Ruby application that deserializes YAML documents using the YAML.load function. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Ruby code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Ruby” System. Figure 1: Exploit blocked with attack signature 200004159 Additional Reading https://staaldraad.github.io/post/2019-03-02-universal-rce-ruby-yaml-load/Threat Analysis: perlb0t
This ancient bot, also known as the “Mambo” bot (due to an old vulnerability in the Mambo CMS it tried to exploit) has been around for a very long time, and many variations of it has been seen. However, from our observations, it is still being actively used in recent exploitations. After successfully exploiting an existing vulnerability on an unpatched webserver, a malicious Perl-based script is executed and turns the webserver into a member of a botnet. The names of the variables and functions in the code reveal that the bot author is likely a Portuguese speaker. Examples are words such as “servidor” (server), “conectar” (connect) and “pacotes” (packets). Like every “good” bot, perlb0t supports several functionality, such as port scanning, using Google search to find other vulnerable servers (also known as “Google Dorking”), running shell commands on the server and more. However, it seems that the main business model of this bot is a DDoS service. The bot supports HTTP and TCP floods, by sending “GET” requests or just opening (3-way handshake) and closing TCP connections respectively. But the most interesting DDoS functionality in this bot is the “UDP flood”, as its author calls it. At first glance it seems like the author is trying to create specific floods (ICMP, UDP, IGMP, TCP), however when further analyzing, this functionality is no more than just sending malformed packets of different protocols. Let’s look at this one… The C&C (Command&Control) instructs its bots to perform a “UDP flood” with 3 parameters: 1. Target (IP/Domain) 2. Packet size (in Kbytes) 3. Duration (in seconds) As we see from the source code, the bot uses raw sockets for the three types of packets, with different protocol numbers as the third argument, and one datagram socket for simple UDP. Using a raw socket enables the attacker to control more fields in the packet itself, however the bot writer needs to manually construct all the protocol headers. By looking at the table of supported IP protocols, we see that the bot creates raw packets of IGMP, ICMP and TCP protocols. Those packets are just being marked with those protocol numbers, however other fields and headers are not actually set. The packet is filled with “A” characters according to the size specified by the C&C command, making the packet a malformed one. However, even more interesting is the distinction the bot writer makes between the above protocols and other protocols the writer uses afterward. After sending malformed IGMP, UDP, ICMP and TCP packets, the bot will send 252 additional malformed packets of all other protocols (running from 3 to 255 protocol numbers, skipping previously sent protocols). The above screenshot displays a single loop in the attack, while each loop uses a different source port sequentially (running from 1 to 65000). Note the inaccuracy; the bot writer must have meant to run over all the 65k ports, which is 65,536. As we see from the bot’s traffic, a sequence of malformed packets is sent (the only well-formed is UDP), while the protocol number is sequentially incremented. (In the screenshot, this is shown as: 0xc, 0xd, 0xe, 0xf, 0x10…) It is important to note, that creating raw sockets needs administrative privileges, so if the infected webserver does not run as the root user, the attack will be a simple UDP flood. Note the destination port sequence. To sum up, a lot of attackers are lazy. They will do the minimum required to make their money suggesting DDoS services. As we learn from this example, an ancient bot first detected back around 2005 is still in the wild. Having the same basic structure, with edited nuances and sometimes functionality, it still spreads by exploiting recently discovered web vulnerabilities, making your web server part of a botnet.
