Ancient service updates, Google drops 0day, killing ANS quietly
Microsoft’s security team begins 2015 with a minimal set of Security Bulletins, MS15-001 through MS15-008. The set included one critical vulnerability in a service that probably shouldn’t be shipped any longer (telnet), and seven bulletins rated “Important” patches for elevation of privilege, DoS, and security bypass issues.
The critical Bulletin effects the telnet service. The telnet service is an ancient piece of software that provides shell access to a system, mostly available on router installations. Only it’s over unencrypted, plain text communications, and should not be used. It was also a bit of a bear to configure and make useful, but may have been useful in development and IT environments. Luckily, this service is not enabled by default on supported windows systems (but it is installed by default on Windows Server 2003). A quick search in shodan shows a pretty reduced set of users, and its presence in our Ksn data is very limited. And, on the public internet, the number of Windows telnet servers listening on port 23 and providing a related banner is only a couple hundred. So, this patch effects very few customers.
But, if someone didn’t install an alternative like OpenSSH, uses the PowerShell facility, WinSCP, RDP, or other facilities, and oddly installed this service, they may be running a server vulnerable to remote malformed packet delivery leading to remote code execution. Meaning it’s a severe issue that really “shouldn’t” effect many users. And it appears to not be exploited on our user base. When installed and enabled, Microsoft’s telnet server runs as “Tlntsess.exe” on all Windows systems since Windows Server 2003. And on a somewhat related note, Ksn shows infected Tlntsess.exe files on new customer systems running a first scan or enabling a scan after running infected code:
It’s always surprising to still see the viral stuff, but it’s certainly more prevalent than telnet service exploitation at this point.
The other Security Bulletins are rated “Important”, and the escalation of privilege issues are somewhat interesting and the kind of thing businesses should be aware of – they are frequently used as a part of target attack activity.
One of these EoP vulnerabilities was reported privately and exposed publicly by Google’s Project Zero two days prior to the scheduled and known patch release. The project maintains a database of exploitable vulnerabilities, each of which has a deadline of 90 days from reporting before the bug goes public: “Deadline exceeded – automatically derestricting“. This EoP was fixed and the fix released by Microsoft as MS015-003 on its scheduled “patch tuesday” release, two days after Google exposed their bug issue publicly. It’s strange that Google would do such a thing, it’s not as if Microsoft doesn’t commit to reasonable time frames for fixes and proper testing anymore. Microsoft responded with a lengthy writeup on responsible disclosure and cooperation within the industry, and mentioned Google’s approach in particular.
The flawed code has yet to be seen as abused in the wild, but it will likely happen. You can find a set of executive summaries for the Bulletins here.
And one last note, the Advanced Notification Service is coming to an end. Microsoft ended their practice of broadcasting advance notice of security updates to all customers, and offers it only to paying Premiere-level customers. For the most part, it seems that this works out just fine and possibly frustrates people less with security maintenance. However, I think that it would be useful for Microsoft to pre-release forecasted download file sizes and reboot requirements for the updates, along with their ratings of critical or not, etc. For example, knowing that I will have to download over 200mb of critical software updates requiring system reboots would be helpful. That information would be useful to their customers both large and small. Time will tell if they bring it back, but likely, they will not need to.