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.

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.