WannaCry: What is next?
Posted on 2nd June 2017
The June 2017 security update release has seen Microsoft release patches for the all operating systems affected by the “ExplodingCan” exploit (CVE-2017-7269) under Microsoft security advisory 4025685. Also covered under the June 2017 update are patches for “EnglishmanDentist”(CVE-2017-8487) and “EsteemAudit” (CVE-2017-0176).
Quote from Microsoft:
Today, as part of our regular Update Tuesday schedule, we have taken action to provide additional critical security updates to address vulnerabilities that are at heightened risk of exploitation due to past nation-state activity and disclosures. Some of the releases today are new, and some are for older platforms under custom support agreements, that we are making publicly available today. Customers with automatic updates enabled are protected and there is no additional action required. For customers managing updates, or those on older platforms, we encourage them to apply these updates as soon as possible.
Full release details: https://blogs.technet.microsoft.com/msrc/2017/06/13/june-2017-security-update-release/
Almost everyone has heard of the “WannaCry” ransomware attack. It was infecting computers around the globe simultaneously while extorting money from victims. It has been so big that taxi drivers have been asking me how to protect themselves. When it passes from the information security community to the man driving you back from a night out then you know it has made an impact.
WannaCry was notable for several reasons including:
- It was the first truly global ransomware incident.
- By its nature ransomware is visible to victims and creates a sense of panic.
- It used a known exploit within Microsoft Windows which has been claimed to have come from the NSA.
- The exploit worked in versions of windows that Microsoft no longer supported where it could likely spread indefinitely; finally
- Many critical systems still run those unsupported versions of Windows for a variety of reasons. We are not about shaming people for needing these systems since there are many practical reasons that others have not been admitting too during the event.
As a provider of security services, we have lots of customers who rely on us for information on occasions like this. What they hear on the rolling news cycle is typically rushed at best, based on conjecture and wrong at worst. Things like that can add to the panic which is not what people intended.
How did we do? So far everything on both pages has remained true so we would call that a win. Our customers certainly seem to have appreciated the calmness of the coverage. The ones who contacted us have all asked one question: “What is next?”.
This post is about what we guess is next. Obviously we cannot predict the future with certainty. However, we started to think like attackers (not too hard as this is the day job of our offensive security consultants), and this is the story of what happened.
Change the Missile
WannaCry exploited a missing update in Microsoft Windows to get ransomware onto computers. In the real world, you can think of the missing patch as the “missile” while the ransomware is it’s “payload”. The missile does the moving to get the payload in place. But it is the payload which attacker designed to do the damage.
Our number one thought on what is next was: change the missile.
The payload will be caught by anti-virus vendors now who have generated signatures that can detect WannaCry. The truth is that signature based detection can be bypassed by altering the exact code used with relative ease. Everybody technical enough to have made the WannaCry ransomware knows how to tweak it to use basically the same payload again.
The thing that is difficult is building the missile. How to get the ransomware to run on the victim’s computer is the biggest problem for the attacker.
Psychology of our Attacker
What missile did they use? They picked something which Microsoft had already released updates for. This shows that our attacker is not sophisticated enough to sit down and find their own flaws in Windows.
The reason that WannaCry was such big news was because there has not been a remote exploit like it for Windows for many years. The impact of WannaCry would have been even greater if Microsoft had not already released patches to address the flaw two months prior to the attack. Supported versions of their operating systems were not included in the list of infected computers. Using it against legacy systems was effective but also a wonderful case of opportunism from the attacker.
If the missile was a “zero day” (a security issue which at the time of attack has no vendor patch available) then the impact would have been far worse. The immediate response to news breaking would have altered from “patch your server” to simply “turn your server off”.
The psychology of our attacker is basically:
- an opportunist.
- unabashed to use known flaws to their own ends.
- skilled enough to adapt someone’s proof of concept into a weapon; and
- determined enough to do so for money.
While incomplete we can start to use this along with their past behaviour to predict their next move.
Finding the next Missile
If the attacker did not make their own missile, where did they get this one? It was from a leak by “The Shadow Brokers” (https://en.wikipedia.org/wiki/The_Shadow_Brokers) who claimed to have stolen an entire arsenal of exploit tools from the NSA.
Given past behaviour we made an educated guess that the next missile may be sitting right next to the last one. After all this arsenal was created allegedly to allow a nation state to enter any network of their choosing with ease. It contained exploits for many common pieces of software which are being used to power businesses today.
If you have not updated software which is vulnerable to these tools, then the blunt truth is that you may be hit in the next wave.
In the longer-term attackers will simply use whatever new exploit code comes along in commonly Internet facing software. For now, the best bet would be the Shadow Brokers dump.
Looking at the available exploits we focused initially on “ExplodingCan” (all the exploits have memorable names). This is listed to exploit fully patched Windows 2003 servers offering IIS 6.0 under certain conditions. It seems right up our attacker’s street as it will target legacy systems.
To estimate how many targets were possibly vulnerable to ExplodingCan, we used a search engine called Shodan (https://www.shodan.io/). It indexes information about hosts on the Internet by continually scanning them.
Figure 1 shows 375k worldwide with around 10.5k specifically in the United Kingdom may be affected.
We must be clear that not all these computers will be vulnerable. Exploitation of this required a specific configuration to be enabled too. How likely the exploit was to succeed is hard to determine without scanning targets which is illegal without permission of each organisation. Worldwide we identified, telecommunications, banking, insurance, educational and governmental institutions who might be affected.
Having picked ourselves a weapon from the likely stockpile we decided to see this thing through. How much effort would it take to adapt and bolt on as our new missile?
Secarma researchers took the existing exploit code, determined how it worked, and got a good way into developing a functional tool in less than two days. While not quite ready to launch, they estimated that an attacker would probably require only one week or less to do the required work from the publicly existing exploit.
To us that seems like an attainable amount of effort for people to put into this kind of thing. If it is literally their business to do so then they will no doubt be even more effective.
Outreach to organisations potentially vulnerable to ExplodingCan
After estimating effort to make the next attack our consultant developed a script to check if a host is vulnerable to “ExplodingCan”. Rather than exploiting the flaw it simply detects whether the server is vulnerable in a safe way.
The logical next step would be to check the hosts listed on Shodan and then start to inform those who were vulnerable. This caused a dilemma because we are not legally authorised by those companies to do so. Even if it is to their benefit it is legally speaking not a good idea for us to act alone.
We needed help to do this so we reached out to the National Cyber Security Centre (https://www.ncsc.gov.uk/about-us). We handed full details of what we have done to this point along with a request for them to contact potentially vulnerable organisations to make them aware.
The ExplodingCan vulnerability works by exploiting a known weakness in IIS6 webservers with WebDAV enabled. WebDAV or Web Distributed Authoring and Versioning allows users to perform such functions as moving or copying files, documents or pages on a webserver or web share. It is therefore enabled frequently by directory.
The NSA’s ExplodingCan exploit employs a buffer overflow in the PROPFIND function of WebDAV. By sending a long request the condition is triggered and any given payload may then be executed.
We first noticed ExplodingCan while we were looking through the ShadowBroker’s exploit dump after reviewing the exploits used by the WannaCry malware. Next we noticed that a Metasploit module had appeared for ExplodingCan. This worried us as its inclusion in Metasploit meant not only had the barrier for entry just dropped significantly but that the basic ruby code was now freely and widely open and could easily adapted.
To begin with we setup a safe test system installed a Windows 2003 server, applied all updates and turned WebDAV on. Then we tested the Metasploit module.
As you can see success! We now have a shell on the server.
Next we looked at the most publicly available code of the exploit. https://www.exploit-db.com/exploits/41992/. Secarma researchers took the code and turned it into standalone python script which could then be adapted to have a different “payload” of our choosing on it. They not only managed this but improved on the exploit making it more reliable. In this case we decided to spawn the calc.exe process. Then we tried again, and again…
At this point we had a dilemma. In order for this to work effectively WebDAV must be enabled. However, given that it is enabled on some folders, in order to check every 2003 server in the UK we would not only have to check each of them but every folder they had. To do this we would need to know the names of the folders.
Doing this by using brute-force to guess folders would only be as good as the wordlist we had. It would also likely never check everything and, after some discussion over the implications of the Computer Misuse Act, was almost certainly illegal. The truth is it was never really an option but turned in to a valuable opportunity for our junior consultants to have practical insight in to the important implications of the law in our field. At this point we contacted the NCSC. We turned all the code we had over to them and they thanked us for the research.
Further analysis of the underlying cause of the vulnerability was completed by Secarma security researchers. A whitepaper will be made available within the coming weeks, providing a behind the scenes look at how our researchers disassembled the vulnerability, and review how attackers took advantage of a simple calculation error within Microsoft’s WebDev implementation.
Normally we would contact a vendor under such circumstances and go through the responsible disclosure route. However, these are unique circumstances for the following reasons:
- The exploit is publicly available (exploitdb and Metasploit)
- The exploit has already been used in the wild in a limited way
- Microsoft have stated their intention not to patch 2003 servers
Bottom line: the vendor already knew and had reacted already.
Advice and Tools
Due to the nature of this problem the only genuine advice to anyone potentially affected is to either upgrade your internal or external servers to a supported version of windows servers or turn WebDAV off completely. Given that the functionality may be necessary for business functions this may not be practical.
Also if we learned anything from WannaCry, it was people and large organisations often do not even know what they have running or what functions they have enabled. We have developed some code to allow people to check if they are affected.
This code takes a list of known folders and remotely checks if the issue exists. This should only be run against servers which you are authorised to access. From the back end of the server it is of course also possible to manually check to see if WebDAV is enabled.
The Code is available here: https://github.com/secarma/explodingcan-checker
Return on Investment
For a global problem estimated to have infected over 300,000 computers how much money did WannaCry make? According to a bot on Twitter https://twitter.com/actual_ransom at the time of writing the number was $120k which was around £93,000. For such a big news story this seems like a paltry return.
Clash that number against the estimate of effort (one week) and then you see that it was more than worth it. Our attacker has walked home tax free with the weekly salary of Chelsea and England International defender Gary Cahill.
We would call that worth it for most people.
Summary of our near future
The following bullet points are our predictions for the near future regarding WannaCry and its successors:
- Alterations will be made to the WannaCry ransomware component to make it resistant to analysis and harder to detect or remove.
- Attackers will increasingly use newly released publicly available exploit to serve as the missile to get their payload onto computers.
- Ransomware is here in a big way and it will only increase. Given the return on investment versus the estimate of effort this seems certain.
- We all need to talk about servers which are running unsupported