This month’s Microsoft security bulletins got a lot of action with the “crypt.dll” ECC validation flaw (aka CurveBall aka ChainOfFools), but the Windows Remote Desktop Gateway (RD Gateway) ones – some remote code execution – warrant your immediate attention, specifically CVE-2020-0609 and CVE-2020-0610.
What follows is my thought process of how I investigate these kinds of vulnerabilities with a system like Censys.
Digging into Censys to find these hosts gets interesting. Briefly, because Censys records network observations, you have to figure out how the software presents itself on the network. For web-based software, Microsoft often has a specific header that expresses the product and version. But in this case, it doesn’t, so I have to rely on other signals to robustly identify candidates. My objective is to estimate the vulnerable population size, and maybe to support identifying assets in my network I need to patch or remediate.
Normally in this kind of scenario (no obvious marker like a distinctive web header), when I want to mine Censys for this data I begin with a free form text search with the product name, typically as a quoted string.
https://censys.io/ipv4?q=%22Remote+Desktop+Web+Access%22
In this case, it brings back under 100 hosts, suggesting to me this isn’t the right query. I found a support article from Microsoft’s forums that describe the default Web RDP path (/rdweb). This string made a really effective query term because it is so unique. It turns out we see nearly 38000 servers with “/rdweb” in their web pages:
https://censys.io/ipv4?q=rdweb
From there you can further refine to constrain it to your org by CIDR, domain name, or the like. In this case we don’t have any version numbers presented by the Web RDP banner, but some products do. If we did have some, we would use those to refine the result set based on the range of vulnerable products from the vendor advisory.
