UTM Advanced Threat Protection blocks kill switch URL for WannaCry (also referenced as WCry, WannaCrypt, and WanaCrypt0r)

This might be fixed.  I used the DNS Test tool in UTM WebAdmin and it returned a valid list of addresses.

Yes, I can confirm that's fixed now. The URL is not longer blocked.

Well, it seems that with proxy it doesn't matter [:(]

WannaCry Killswitch Check Is Not Proxy Aware

found: https://blog.didierstevens.com/2017/05/13/quickpost-wcry-killswitch-check-is-not-proxy-aware/

So maybe, opening Firewall towards the known address would be an option.

Best 

Alex

Yes, but the UTM employs a transparent proxy so I'm wondering if this negates this?

In transparent mode, the host doesn't know whether its being proxied or not. It simply tries to get to the internet and the UTM will intercept http/s traffic.

Anybody offer any info on this?

Louis-M said:

Yes, but the UTM employs a transparent proxy so I'm wondering if this negates this?

...

Anybody offer any info on this?

Ok, I was assuming proxy in standard mode, as UTM provides it too. It's correct in transparent mode this should be no difference to no proxy at all.

Alex

create an ad integrated dns zone with this name and inside a www a entry pointing to an internal web server. that will do the trick without any proxy involved.

Alex, in Didier Stevens' blog, he said jut an hour ago that the "kill switch" works as long as the client can resolve public DNS.  He said earlier in comments on his post that it does work in Standard (explicit proxy) mode.

Cheers - Bob

Hi Bob, I can not see this on his blog, where did he said that, do you have a link?

Maybe I'm misunderstanding...

When one uses the Transparent Proxy, it's the client that requests name resolution.

According to the code in the snippet in Didier's post, Wannacry, like Dropbox and many other apps, doesn't check to see if it should go via a Proxy.  In this case, even if the client is configured to use a proxy for web browsing, Wannacry requests name resolution.

In both cases, Wannacry stops because the DNS request for that FQDN returns a real, public IP.

What am I missing?

Cheers - Bob

Hi again Bob,

The missing element, is that the malware doesn't do just a DNS lookup. It does a full HTTP request out to the root URL of the domain.

I think the following image breaks the code down well. From https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html, this: https://www.malwaretech.com/wp-content/uploads/2017/05/IDA.jpg

So, whatever IP the domain resolves to, must also accept HTTP connections. If not, the malware continues execution as normal.

This is where proxy configuration starts to matter. Some client / proxy configurations will block the HTTP connection, because the malware doesn't end up using the proxy, as it doesn't bother to check for one. In other configurations, like transparent proxy mode for example, the HTTP request will be successful.

"So, whatever IP the domain resolves to, must also accept HTTP connections. If not, the malware continues execution as normal."

So, in which case does the malware not see the HTTP connection?  If the HTTP Proxy is in Standard mode, the malware won't use it and the connection will bypass the Proxy and go to the site.  If the Proxy is in Transparent mode, the malware will not know the difference and will go to the site.

I still don't understand what I'm not seeing.

Cheers - Bob

This is an incredibly important discussion, and it is a lesson to me for the next crisis.   On first reading, I thought it only needed to perform a DNS lookup on that name, so as long as I was not blocking DNS, I was benefiting from the kill switch.   

Bob, a well configured proxy should be configured for BOTH standard mode and transparent mode.   Standard mode provides the best protection and the best user attribution.   Transparent mode provides some protection and (thorugh log review) helps identify the devices that are not configured for Standard proxy.

Country blocking applies globally, so if the kill-switch address is intercepted by country blocking, then it could be deactivated.

If you have a copy of Microsoft's portqry.exe utility, this is a successful test

C:\PortQryV2>portqry -n www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com -e 80

Querying target system called:

www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Attempting to resolve name to IP address...

Name resolved to 104.17.40.137

querying...

TCP port 80 (http service): LISTENING

C:\PortQryV2>

Then, I ran the same test using UTM...  Web Filtering... Policy Helpdesk.   Even though we have a lot of country blocking enabled it reported the site as allowed   So I think Sophos has implemented the appropriate flags to ensure that the kill switch will work for all users.   But testing your own environment is wise.

Going forward to the next crisis, I will be careful to pursue as much detail as possible about how proxies might interact with the problem code.

This is an incredibly important discussion, and it is a lesson to me for the next crisis.   On first reading, I thought it only needed to perform a DNS lookup on that name, so as long as I was not blocking DNS, I was benefiting from the kill switch.   

Bob, a well configured proxy should be configured for BOTH standard mode and transparent mode.   Standard mode provides the best protection and the best user attribution.   Transparent mode provides some protection and (thorugh log review) helps identify the devices that are not configured for Standard proxy.

Country blocking applies globally, so if the kill-switch address is intercepted by country blocking, then it could be deactivated.

If you have a copy of Microsoft's portqry.exe utility, this is a successful test

C:\PortQryV2>portqry -n www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com -e 80

Querying target system called:

www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Attempting to resolve name to IP address...

Name resolved to 104.17.40.137

querying...

TCP port 80 (http service): LISTENING

C:\PortQryV2>

Then, I ran the same test using UTM...  Web Filtering... Policy Helpdesk.   Even though we have a lot of country blocking enabled it reported the site as allowed   So I think Sophos has implemented the appropriate flags to ensure that the kill switch will work for all users.   But testing your own environment is wise.

Going forward to the next crisis, I will be careful to pursue as much detail as possible about how proxies might interact with the problem code.

I never recommend using "All" in Country Blocking, "From" is all I would do.  You're right about Standard vs. Transparent, Doug - I recommend having the Default Profile in Transparent with tighter restrictions than a more-desirable Profile in Standard.  You might be interested in a document I maintain that I make available to members of the UTM Community, "Configure HTTP Proxy for a Network of Guests."  If you would like me to send you this document, PM me your email address.

Keith and Jas, I see now what you mean.  I guess I am so accustomed to the way I do things, it didn't occur to me that some organizations would block some traffic instead of managing it with a Transparent-mode Profile. 

Cheers - Bob

For me it's a normal design in non-privat LANs to block Internet access until a user logged in, which is allowed to use the proxy. For special requirements the firewall allows direct access to sites and/or services based on the clients IP address. But all other machines and users are blocked.

I'm interessted what are the benefits of allowing basic Internet access for everyone in your opinion (in case that there's not a ransomware with a web based killswitch :-) ).

There are three elements of proxy strategy:   (1) organizational policy (Management does not want employees going to gaming, pornography, or software piracy sites).   (2) Malware protection, and (3) Business and Technical necessity.    User identification seems only necessary for item 1.

Necessity:  Most computers require some internet access for basic technical functions like software updates or web-based resources such as online help.   Many modern applications require internet access to perform some of their functions.   Most staff require internet access for some aspect of their job.   These are the best reasons for a default policy that allows some access.

Policy:   User identification is important for policy enforcement based on job requirements, and for user accountability if appropriate use policy is violated.   Standard mode proxy seems to be the only method that provides sufficient accountability for employee discipline purposes.

Security:   These protections are uniform for all employees.  Accountability is useful but not required, because blocking threats is more important than knowing whom to blame.

Then the practical issue is knowing everything that will be required by your organization.   Incremental rollout seems to be the only practical way to learn that information.   Standard proxy can be deployed incrementally using group policy, and transparent mode proxy can protect the other essential connections while you learn what else needs standard proxy configured manually.

Great explanation, Doug.  Those are the main reasons I use a more-restrictive Default Profile in Transparent mode along with a Web Filtering Profile in Standard mode.  If anyone wants to do anything for which there is a company policy, they have to use the Standard mode Profile.

I developed this approach before it was possible to do AD-SSO with a Transparent mode Profile, so I haven't thought about using that until now.  If a client didn't want to use an explicit proxy (Standard), I think I could achieve practically the same thing in Transparent mode by allowing un-authenticated access and then using Policies with more-open Filter Actions for identified browsers and a more locked-down one for unidentified browsers.

Cheers - Bob