WannaCry Ransomware and MS17-010 Vulnerability

On Friday 12 May 2017 a large ransomware attack dubbed “WannaCry” was launched targeting more than 200,000 computers worldwide, including industries such as banks, hospitals and large telecom companies.

Figure 1: “WannaCry” ransom massage

Infection Methods

One of the main infection methods of this ransomware is by exploiting a recently patched Microsoft Windows SMB vulnerability (MS17-010). This vulnerability was publicly discovered as a result of the Shadow Brokers leaks that happened in April this year. Another possible method of infection is by phishing emails being sent to arbitrary recipients.

Either way, once this ransomware gets on a network it exploits the aforementioned windows vulnerability in order to spread further into the network and infect more computers.

Figure 2: Shodan search for Windows SMB service exposed directly to the internet

Mitigation using BIG-IP

BIG-IP is able to mitigate the Windows exploitation attempt and prevent the WannaCry ransomware infection by using the attached iApp which contains an iRule, the iRule detects a part of the kernel shellcode in the exploit and drops the packets containing it.

sys application template WannaCry_Blocker_v2 {
    actions {
        definition {
            html-help {
<h3>WannaCry Blocker</h3>
<p>This iApp installs the WannaCry Blocker iRule which will detect,
 block,* log, and count attempts to exploit CVE-2017-0144
 &ldquo;WannaCry.&rdquo;</p>
<p>Attach <i><b>both</b></i> the WannaCry Blocker
 iRule <i>and</i> the default Stream Profile /Common/stream to a TCP
 virtual server (the virtual server must not have an HTTP Profile).</p>
<p>The WannaCry Blocker iRule logs the source IP address and geolocation
 of each possible attack and counts attacks (per-virtual-server)
 using iStats.</p>
<p><b>*</b> The WannaCry iRule blocks WannaCry attacks.  It also has an
 option to log attacks then allow them to proceed, if you really want
 to do that.</p>
            }
            implementation {
package require iapp 1.1.1

iapp::template start

# Prepared by Mark Quevedo, f5 Networks

#------------------------------------------------------------

set ir_wcry {
# WannaCry Blocker iRule
#
# Attach this iRule along with the defaul Stream Profile
# /Common/stream to a TCP virtual server to detect, block,*
# log, and count CVE-2017-0144 "WannaCry" attacks.  (The
# virtual server must not have an HTTP Profile.)
#
# This iRule logs the source IP address and geolocation of each
# attack and counts attacks (per-virtual-server) using iStats.
#
# * Normally this iRule blocks WannaCry attacks.  If you really
# wish to allow such attacks to proceed (to a honeypot, maybe?)
# after they are logged, set the variable static::allow_wannacry
# to '1' in the RULE_INIT event.
#
# Written by Mark Quevedo, f5 Networks
#

when RULE_INIT {
 # if static::allow_wannacry is set to 1 (true) (see next line)
 # then WannaCry attacks are not blocked, just logged and counted
 set static::allow_wannacry @@@@@

 
 # Stream Profile target sequences here are TCL regular expressions.
 # TMOS maps payload octets as if they were ISO-8859-1 to Unicode chars
 set target_list {
  {\u00b9\u0082\u0000\u0000\u00c0\u000f\u0032\u0048\u00bb\u00f8\u000f\u00d0\u00ff{5}\u0089\u0053\u0004\u0089\u0003\u0048\u008d\u0005\u000a\u0000}
  {\u0010\u0000{4}\u00ff{4}\u0000{12}\u004a\u0000{3}\u004a\u0000\u0002\u0000\u0023\u0000{3}\u0007\u0000\u005c\u0050\u0049\u0050\u0045\u005c\u0000}
 }

 set static::wcry_targets ""
 append static::wcry_targets "/" [join $target_list "// /"] "//"
} ; #RULE_INIT

when CLIENT_ACCEPTED {
 STREAM::expression $static::wcry_targets
 STREAM::enable
} ; #CLIENT_ACCEPTED

when STREAM_MATCHED {
 if {$static::allow_wannacry} {
  STREAM::replace ; # no arg means don't replace, therefore allow
  set blocked ""
 } else {
  reject ; # block apparent WannaCry attack
  set blocked "blocked\x20"
 }

 set client_ip [IP::client_addr]
 set client_port [TCP::client_port]
 set local_ip [IP::local_addr]
 set local_port [TCP::local_port]
 set geo [whereis $client_ip continent country city isp latitude longitude]

 log local0.info "[virtual] ${blocked}apparent WannaCry attack from ${client_ip}_${client_port} to ${local_ip}_${local_port} (source IP geolocation: [join $geo "|"])"

 ISTATS::incr "ltm.virtual [virtual] c wannacry" 1
} ; #STREAM_MATCHED
} ; #ir_wcry

#------------------------------------------------------------

# create/update iRule
regsub -all {@@@@@} $ir_wcry [expr {!$::intro__block}] patched
iapp::conf "create ltm rule WannaCry-Blocker { ${patched} }"

iapp::template end
            }
            presentation {
section intro {
    message note1 "This iApp installs the WannaCry Blocker iRule which will detect, block,* log, and count attempts to exploit CVE-2017-0144 'WannaCry'."
    message note2 "Attach BOTH the WannaCry Blocker iRule AND the default Stream Profile /Common/stream OUTSIDE OF THIS iAPP to any TCP virtual server (the virtual server must not have an HTTP Profile)."
    message note3 "The WannaCry Blocker iRule logs the source IP address and geolocation of each possible attack, and counts attacks (per-virtual-server) using iStats."
    message note4 "* Normally the WannaCry Blocker iRule (WannaCry-Blocker) blocks WannaCry attacks in addition to logging and counting them.  If you really wish to allow such attacks to proceed (to a honeypot, perhaps?) after they are logged, you may configure the WannaCry Blocker iRule here to log WannaCry attacks then allow them to proceed."
    choice block display "xxlarge" {
     "Yes!  Block WannaCry attacks; also log and count them" => "1",
     "No.  Log and count WannaCry attacks but do NOT block them (INSECURE)" => "0"
    }
}

text {
    intro "Welcome to the WannaCry Blocker iApp template v2"
    intro.note1 "Description"
    intro.note2 ""
    intro.note3 ""
    intro.note4 ""
    intro.block "Do you want the WannaCry Blocker iRule to block WannaCry attacks?"
}
            }
            role-acl { admin }
            run-as none
        }
    }
    requires-bigip-version-max none
    requires-bigip-version-min 11.0.0
    requires-modules { ltm }
    description "WannaCry Blocker to detect/block/log/count CVE-2017-0144 'WannaCry' attacks"
}

Figure 3: iApp template for logging and blocking MS17-010 exploitation attempts

Figure 4: Exploit attempt against BIG-IP which has the iRule configured

It is important to emphasize that BIG-IP is not vulnerable to this Windows SMB vulnerability as it doesn’t run Windows OS.

Published May 16, 2017

Version 1.0

4 Comments

Tosin_Omojola
Altostratus
May 18, 2017
Thanks for this mitigation tool. I have installed the iapp. However, how does it protect all the virtual servers configured on my BIG-IP since it requires the target VS to not have the http profile?
M_Quevedo
Nimbostratus
May 18, 2017
SMB/CIFS cannot pass through a virtual server with an HTTP Profile on it, so you should be safe.

The caution against attaching the iRule to an HTTP virtual server simply reflects the fact that the Stream Profile filter it uses to efficiently scan the data stream for exploit sequences behaves differently when an HTTP Profile is present on the virtual server.
Tosin_Omojola
Altostratus
May 19, 2017
Okay then. That means one has to have an intermediary virtual server ( without HTTP profile ) to accept main requests to a resource, scan it for the ransomeware and then forward it to the actual virtual server ( with HTTP profile )for processing, right?

Thank you for the clarification.
M_Quevedo
Nimbostratus
May 19, 2017
WannaCry (in several variants) spreads two main ways: (1) through malicious downloads like web-page or email attachments; (2) from one computer to another by exploiting a flaw in SMB protocol handling in many versions of MS-Windows (SMB is a fileserver protocol, not a web-browser or email protocol). The second (SMB) method does not require any user interaction or Internet connectivity, but is mainly a way for the worm to spread in corporate/organizational intranets.

To prevent WannaCry from infecting MS-Windows computers via SMB, the WannaCry-Blocker iRule terminates an SMB connection (TCP to port 445 or 139, typically) when it detects the WannaCry attack (before the attack can succeed). The attack can be detected because it relies on sending specific byte sequences to the victim computer in SMB protocol packets.

The WannaCry-Blocker iRule should be used to prevent WannaCry from spreading across the organization's intranet, including site-to-site or branch-office VPN links. When using BIG-IP IP Forwarding virtual servers, you may wish to create some parallel Standard virtual servers to inspect port 445 and 139 traffic for SMB attacks.

SMB does not use HTTP. To prevent the initial download of the worm over HTTP (web) or email, a different approach is needed, because the exact byte sequences used in the SMB attack may not be present in a file download. Downloads are typically compressed, Base64-encoded, or contain malicious code which generates SMB attack sequences on the fly instead of including them literally.

To protect your organization against initial infections through web pages or email, you should use a web security tool like F5 Secure Web Gateway and a suitable email-attachment scanner.

Although it is probably not worth the trouble, you can alter the WannaCry-Blocker iRule and attach it to an HTTP virtual server to scan binary downloads over HTTP for the SMB attack signatures. That will still not detect malicious software which generates WannaCry SMB attacks dynamically. To scan HTTP binary download attachments add the following code to the iRule:

when HTTP_REQUEST { HTTP::header remove "Accept-Encoding" }