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

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.

Bob,

I think Keith means the following situation: Enabled Standard HTTP Proxy Mode and no firewall rule which allows Internet access without proxy. I think this is the standard configuration in most (non-privat) networks.

In this case the malware will be able to resolve the domain name, but will not be able to access it over port 80. The killswitch will not work in this case.

Jas

Sophos did implement this these urls into the UTM via an update very early on. It's documented somewhere because I can remember reading it before we turned up for work last monday which meant we had nothing to do.

Jas got it. This is exactly the situation to which I was referring.

Although it's probably not the best way to control internet access on a private network, I have seen far too many networks (that I do not manage), setup this very way. Where a standard mode proxy requiring authentication is the only way to access the internet, and every single domain attached Windows instance has the OS level proxy settings completely disabled via Group Policy, so as to block the option of simply plugging your proxy login into Internet Options and giving everything running on that Windows instance internet access by default.

This combination results in any application to which you cannot directly enter proxy settings into, being blocked from accessing anything on the internet.

A simple way to fix the issue in that specific case, without changing the above network configuration, would be to setup a block page redirect, for anything sending HTTP / HTTPS requests through the gateway, to any domain, registered or not, and not going through the standard mode proxy. This would also give users on the local network a nice reminder of why their web requests are failing, rather than just ending up with a timeout error.

I have also seen this setup in virus / malware / etc. testing sandboxes, to make sure, say, a web browser can still access the internet, but nothing else can, to prevent further spreading of the samples being tested. This is almost definitely why this "switch" ended up in the malware in the first place, as a crude way of disabling itself if it thought it was running inside a sandbox. Not as a way for the creators to "turn it off", if they wanted to.

Ah I almost forgot...

I have also been reading posts by network admins, both home and "enterprise", who are using this very proxy setup, in order to block things like telemetry being sent back to Microsoft, especially for Windows 10 instances now, but also for older Windows versions as well. I've read a few cases where they also use this as a way to block outside WU updates on Home edition Windows instances, where they cannot do it via Group Policy...

Is it "correct" to manage these things this way? No. But, it is possible, and we know that's all it takes in most cases ;-p

And now we can all worry about this, anyways:
https://www.bleepingcomputer.com/news/security/new-smb-worm-uses-seven-nsa-hacking-tools-wannacry-used-just-two/

Will have to watch the UTM definition updates closely this summer...