Posts

ADV200006 | Type 1 Font Parsing Remote Code Execution Vulnerability

Published: 2020-03-23
MITRE CVE-2020- (TBD)

Microsoft is warning about a vulnerability they have detected used in targeted attacks and that there is no patch for yet. No patch and detected in use, a place for the scary word “zero-day”, but this is not a tabloid.

“Two remote code execution vulnerabilities exist in Microsoft Windows when the Windows Adobe Type Manager Library improperly handles a specially-crafted multi-master font – Adobe Type 1 PostScript format.” This would not be so exciting if not document formats had the feature of including their own fonts in documents.

“There are multiple ways an attacker could exploit the vulnerability, such as convincing a user to open a specially crafted document or viewing it in the Windows Preview pane.”

This affects Windows 10 (but read on), and all Windows Server from 2008 until 2019. Windows 10 has some mitigating features. As always, read the advisory for full details.

There exist no official patch for this as of now. There are some mitigations possible, like “Disable the Preview Pane and Details Pane in Windows Explorer”, “Disable the WebClient service” (WebDAV) and “Rename ATMFD.DLL”. Basefarm has not tested these and recommend everyone to have a test environment that resembles their production environment and test the mitigations before applying them.

Consider the usage of your servers, are there documents viewed on them? Are the documents from an unknown, potentially untrusted source? Do you value the integrity of that server and all it in turn has access too? It might be worth to consider implementing the mitigations. For many servers this use case is not a match and it is potentially better to wait for an official and tested patch.

Basefarm follows this vulnerability internally as BF-VLN-2011507 and asking our dedicated customer teams to follow up these recommendations.

CVE-2020-0852 | Microsoft Word Remote Code Execution Vulnerability

Published: 2020-03-10
MITRE CVE-2020-0852

“A remote code execution vulnerability exists in Microsoft Word software when it fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could use a specially crafted file to perform actions in the security context of the current user. For example, the file could then take actions on behalf of the logged-on user with the same permissions as the current user.”

This vulnerability was overshadowed by the SMBv3 remote code execution vulnerability “announced” at the same time, as we have written about earlier. Basefarm evaluated this to be just as likely, if not more, to cause major infections in a corporate environment. It requires some user action to successfully exploit, but opening a document is not an action most users considers risky.

Basefarm recommends applying this patch as soon as possible, even though there is no known exploitation and no proof of concept published, because if a campaign starts up exploiting this on a Friday afternoon you will not have enough time to react.

This affects Microsoft Office (certain versions) AND Sharepoint Server 2019.
Basefarm is tracking this internally as BF-VLN-2004690.

CVE-2020-0796 | Server Message Block 3.0 (SMBv3) Remote Code Execution

Published: 2020-03-10
MITRE CVE-2020-0796

As of writing, Microsoft has not released any official information, but FortiGuard writes that there exists a “(…) Buffer Overflow Vulnerability in Microsoft SMB Servers. The vulnerability is due to an error when the vulnerable software handles a maliciously crafted compressed data packet. A remote, unauthenticated attacker can exploit this to execute arbitrary code within the context of the application.”

And as affected products FortiGuard mentions Windows 10, and Semi-Annual Channel (Windows Server 1903 and 1909). But as Microsoft has not released any official information this might be subject to change.

Basefarm does not recommend anyone to expose SMB and port 445 to an untrusted network. There also exists unofficial mitigation by adding a registry key to disable compression on the SMBv3 protocol. Basefarm is following the developments here, but as of writing there is no known proof of exploit or exploitation in the wild, there is also no official fix for this vulnerability.

Update 2020-03-11:

Microsoft has now released an advisory where they confirm previously known details and adds “to exploit the vulnerability against an SMB Client, an unauthenticated attacker would need to configure a malicious SMBv3 Server and convince a user to connect to it.”

So this vulnerability is more of a client-issue than a server issue. The known workaround to disable compression in SMBv3 prevents exploitation against an SMB Server, not an SMB Client.

Still no official fix, no known exploitation in the wild and no proof of concept available.

Basefarm is tracking this is a client issue in BF-VLN-2003557 and will most likely force all our clients to install this as soon as an official fix is available. We recommend others do too.

CVE-2020-0688 | Microsoft Exchange Validation Key Remote Code Execution Vulnerability

Published: 02/11/2020 | Last Updated : 02/11/2020
MITRE CVE-2020-0688

“A remote code execution vulnerability exists in Microsoft Exchange Server when the server fails to properly create unique keys at install time.

Knowledge of a the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM.

The security update addresses the vulnerability by correcting how Microsoft Exchange creates the keys during install.”

Zero Day Initiative recently published a write-up about this vulnerability, and some key points to know is “Instead of having randomly-generated keys on a per-installation basis, all installations of Microsoft Exchange Server have the same validationKey and decryptionKey values in web.config. These keys are used to provide security for ViewState.” and “Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. With the help of YSoSerial.net, an attacker can execute arbitrary .NET code on the server in the context of the Exchange Control Panel web application, which runs as SYSTEM.”

So this is bad. On the bright side it requires an authenticated user, but considering the amount of leaked credentials these days it could be better.

We agree with Zero Day Initiative when they say “if you’re an Exchange Server administrator, you should treat this as a Critical-rated patch and deploy it as soon as your testing is complete. Microsoft lists this with an Exploit Index of 1, which means they expect to see exploits within 30 days of the patch release. As demonstrated, that certainly seems likely.”

Update 2020-03-04: Exploit for this vulnerability is now a part of the metasploit framework and exploitation is very easy, just needs any domain user.

Internally Basefarm is tracking this as BF-VLN-1994667.

CVE-2020-1938 – Apache Tomcat AJP Request Injection and potential Remote Code Execution

Published by Apache: 2020-02-24
MITRE CVE-2020-3158

“When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising.”

There is not enough details available yet, but the vulnerability has at least a CVSS Base score of 8.1, High. This depends on how hard it is to exploit, etc.

There is proof of concept published, but as of writing no known public exploitation of this vulnerability.

Basefarm customers will be upgraded as part of normal patching routines.

CVE-2020-3158 – Cisco Smart Software Manager On-Prem Static Default Credential Vulnerability

Published by Cisco: 2020-02-19
MITRE CVE-2020-3158

“A vulnerability in the High Availability (HA) service of Cisco Smart Software Manager On-Prem could allow an unauthenticated, remote attacker to access a sensitive part of the system with a high-privileged account.”

The vulnerability has a CVSS Base score of 9.8, Critical.

Basefarm has triaged this vulnerability and found that we are not using the Cisco Smart Software Manager On-Prem software. Basefarm will not track this vulnerability further.

VMSA-2020-0003 vRealize Operations for Horizon Adapter updates address multiple security vulnerabilities (CVE-2020-3943, CVE-2020-3944, CVE-2020-3945)

Published by VMware: 2020-02-18
MITRE CVE-2020-3943

“vRealize Operations for Horizon Adapter uses a JMX RMI service which is not securely configured. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.0.”

“vRealize Operations for Horizon Adapter has an improper trust store configuration leading to authentication bypass. VMware has evaluated the severity of this issue to be in the Important severity range with a maximum CVSSv3 base score of 8.6.”

“vRealize Operations for Horizon Adapter contains an information disclosure vulnerability due to incorrect pairing implementation between the vRealize Operations for Horizon Adapter and Horizon View. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.3.”

The issue has been evaluated by our VMware technicians and Basefarm has concluded that we do not use Horizon Adapter and our systems are therefor not affected by these vulnerabilities.

ThemeREX Addons – Remote Code Execution (0day, Being Exploited)

Published by Wordfence: 2020-02-18
No known CVE

“This flaw allows attackers to remotely execute code on a site with the plugin installed, including the ability to execute code that can inject administrative user accounts.
This vulnerability has not yet been patched. We are only trying to get the word out so people can remove the plugin temporarily as the vulnerability is being actively exploited. ”

Basefarm considers this a Base CVSS Score: 9.8 (Critical) – there is no fix and it is currently being actively exploited.

Basefarm has done some initial investigations regarding the use of this WordPress Theme, but has not identified any customers or internal usage. Basefarm has decided not to track this vulnerability further internally, but want to make it visible by posting this vulnerability bulletin.

We wrote tests for our third-party security libraries, and you won’t believe what happened next! (CVE-2017-8028)

On the importance of thorough testing

Much of modern software development revolves around the concept of “quality”. As with all abstract concepts, “quality” is somewhat difficult to pin down, but for this article we can define it as “how well software conforms to its requirements”. Less formally, we can say that “high-quality software does what it’s supposed to”.

One way to ensure that you consistently deliver high-quality software is to have automated tests. I’m not a Test-Driven Development fundamentalist insisting on 100% test coverage; but if some part of your software is important to your users, there should be at least one automated test demonstrating that it works. This is obviously true for your software’s functional requirements, but it applies equally to its non-functional requirements such as auditing and performance.

So what non-functional requirements are important to the users of Basefarm’s internally-developed applications?
One thing that immediately springs to (at least my) mind is security. So we need some tests for that, right?

Think like a hacker

When developing secure applications, it is always useful to try to think like an attacker. If I were to try to get unauthorized access to this application, how would I go about it?

Obviously, you’d first need to log in. For Basefarm’s internal applications we use username/password logins authenticating against our internal LDAP server; this means that an attacker must obtain a set of working credentials somehow.

This suggests three tests:

  1. An existing user can log in with the correct password (this is what we call the happy-path test, which demonstrates that in fair weather conditions the software works as intended);
  2. A non-existent user is not allowed access;
  3. An existing user logging in with an incorrect password is not allowed access

As part of these tests, it is also useful to think about things like auditing and information leakage; login attempts — successful or not — should be logged, and the error message(s) presented on failure should not give an attacker information she does not already have. In particular, authentication failures should not say “no such user” or “incorrect password”; “Invalid credentials” is a safe, neutral way to put it.

So, in pseudo-code, we have the following tests:

authenticate("existinguser", "correctpassword") must succeed

authenticate("nonexistentuser", "anypassword") must fail

authenticate("existinguser", "wrongpassword") must fail

Don’t reinvent the wheel

The developers at Basefarm, as in most other places, don’t have the time (or, to be honest, the expertise) to write everything from scratch. It is hard enough to implement our specific functionality; implementing and maintaining code to talk to databases and LDAP, handle authentication and transactions and all the other things a large-scale (dare I say Enterprise?) application needs would be impossible. So like many other teams on the JVM platform we lean heavily on the Spring framework and its attendant ecosystem of libraries; in particular, we use Spring Security for authentication and authorization.

Setting the scene

Since our LDAP server (as all good LDAP servers should) requires authentication and encrypted communication using STARTTLS, our Spring Security configuration looks something like this (ignoring some details on how, exactly, things are wired together):

<bean id="tlsAuthStrategy" 
      class="org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy" />

<ldap:context-source 
  url="ldap://monkeymachine:389/dc=springframework,dc=org" 
  username="cn=Manager,dc=springframework,dc=org" password="secret" 
  authentication-strategy-ref="tlsAuthStrategy" />

<security:authentication-manager>
  <security:ldap-authentication-provider 
    user-search-base="ou=People,dc=springframework,dc=org" 
    user-search-filter="(uid={0})" />
</security:authentication-manager>   

The idea is that the security framework, authenticating with the manager credentials, searches for a user to really authenticate as.

We believe this to be a fairly typical LDAP-auth setup; in fact, the actual configuration is more or less copy-pasted from the Spring Security documentation.

We originally implemented this in 2011; and the configuration worked well, all the tests passed, and we were happy.

Let’s dance!

Fast-forward six years, to 2017. As part of our regular maintenance cycle, I went through all of our application’s dependencies and updated them to the latest version, to get the benefit of whatever new features and fixes are available.

This is usually a cushy job: Update some version numbers; recompile everything; drink coffee while the tests pass; and then ship it.

So I upgrade Spring Security to 4.2.1, and start the test run.

Imagine my surprise when I returned from my coffee binge to see

Tests failed: 1

Waltz Tango Foxtrot?

And the test that failed?

authenticate("existinguser", "wrongpassword") must fail

Whisky Tequila Fernet? In short, WTF???

Finding the problem

I’ll spare you the details of how we debugged the issue; it’s not really interesting, involving as it did copious amounts of coffee, creative swearing, scratching of heads, wailing and gnashing of teeth, and poring over code, logs and packet captures.

It turned out that the problem was not in Spring Security per se, but in Spring LDAP; a change in Spring Security’s use of that library exposed a weakness in DefaultTlsDirContextAuthenticationStrategy, which never actually performs an LDAP “bind” operation using the provided credentials.

The desired sequence of events when authenticating in our setup is something like this:

  1. Open a new LDAP connection
  2. Secure it using STARTTLS
  3. Bind with the search credentials (username/password from the context-source)
  4. Perform an LDAP search for the DN to bind as for the real authentication step
  5. Open another new LDAP connection
  6. Secure it using STARTTLS
  7. Bind using the DN from step 4 and the provided password

The logs from the LDAP server show what really happens (I’ve removed some entries from the log; the full log can be seen here):

-- step 1
59ceb606 conn=1000 fd=15 ACCEPT from IP=172.17.0.1:33378 (IP=0.0.0.0:389)
-- step 2
59ceb606 conn=1000 op=0 STARTTLS
-- step 3
59ceb606 conn=1000 op=1 BIND dn="cn=admin,dc=example,dc=org" mech=SIMPLE ssf=0
-- step 4
59ceb606 conn=1000 op=2 SRCH base="ou=People,dc=example,dc=org" scope=2 deref=3 filter="(cn=user)"
59ceb606 conn=1000 fd=15 closed
-- step 5
59ceb606 conn=1001 fd=15 ACCEPT from IP=172.17.0.1:33380 (IP=0.0.0.0:389)
-- step 6
59ceb606 conn=1001 op=0 STARTTLS
59ceb606 conn=1001 fd=15 closed (connection lost)

Step 7 never happens; as long as you have a username, all passwords are accepted.

Further investigation showed that this had been noticed as far back as 2013 by one mwebb and reported as a bug in November 2016, but not recognized as a security issue.

We had also noticed it before, earlier in 2017, but due to time pressures we did not properly investigate the issue at that time.

Houston, you may want to look at this

The Spring Framework is currently maintained by Pivotal Software, Inc., so we notified their security team of the problem. They, in turn, notified the maintainers of Spring LDAP, who initially concluded that this is not a bug because anonymous LDAP access was involved, as it was in the original example project exhibiting the bug.

However, a slight modification of the example project showed that the erroneous behaviour persists even when anonymous bind is not used; it is clear from the log that there is no bind attempt with the user credentials at all.

After a little back and forth, the Spring LDAP team released a fixed version of Spring LDAP on October 6, 2017, nearly a year after the initial bug report.

Timeline

2016-11-11 (approximately)
Tobias Schneider discovers the issue
2016-11-18
Schneider reports the bug to Spring LDAP, with a pull request
2017-01-11
We initially notice the issue, but due to time pressures do not investigate and roll back to an earlier version
2017-08-10
We attempt to upgrade again; again, we roll back to the earlier, working version, but this time (probably due to higher blood caffeine levels) a full investigation is scheduled
2017-09-26
We isolate the problem and discover the earlier bug report
2017-09-28
We notify Pivotal’s security team that we consider this a security vulnerability
2017-09-29
The Spring LDAP team determines that this is not a vulnerability
We demonstrate that the issue exists without involving anonymous search
2017-10-06
The Spring LDAP team commits a fix and releases a working version
2017-10-11
We request a CVE via Dell EMC and Pivotal
2017-10-16
Pivotal publishes CVE-2017-8028

The moral of the story (a.k.a TL;DR)

  • Security is an important part of your application; write tests for it
  • All non-trivial software has bugs, and some of these will be security-related
  • Report security issues to the security contact for the involved software

POODLE returns

The POODLE has returned, with a vengeance! This time it’s affecting vendors such as F5, even though SSLv3 is disabled. This means that TLSv1.0, TLSv1.1 and TLSv1.2 can be affected if the SSL termination is being done on a vulnerable server. Those with F5 are advised to update to the latest version as soon as possible, and you can check on SSLLabs if your site is affected by this (in which case it will automatically be graded F-).

More information:
https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html
http://blog.ivanristic.com/2014/12/poodle-bites-tls.html
https://www.imperialviolet.org/2014/12/08/poodleagain.html