CVE-2018-20319: Why you should always have two factor authentication on your VPN

The OpenConnect VPN client, on all supported platforms, suffered from a possible information leak that could result in an attacker with elevated local privileges obtaining plaintext credentials.  This VPN security vulnerability has now been patched and assigned CVE-2018-20319.

Affected Software

Vendor website: https://www.infradead.org/openconnect/

Affected versions: OpenConnect client – Windows, Linux, Mac OS X, Android, Solaris, BSD, GNU/Hurd – versions 7.08 and below.

Discovery

The closed source Cisco AnyConnect VPN client infamously suffered from an information leak, whereby credentials and session cookie information was stored insecurely in memory. An attacker with access to the endpoint could scan the memory and retrieve the credentials. An advisory was issued for this: https://www.kb.cert.org/vuls/id/192371/.

Nettitude has exploited this VPN security vulnerability on several occasions, scraping credentials from the Cisco AnyConnect client memory during red team engagements, and we always recommended that two factor authentication is used for any VPN.

At the end of 2018, I installed the open source OpenConnect client in order to connect to a VPN, and thought I would have a poke around in memory to see if this too suffered from a similar issue.

Lo and behold, plaintext credentials are visible in memory in the OpenConnect Windows client:

After discovering this, I performed a quick test on the Linux client. You need to have root privileges in order to scan the memory. I used the scanmem tool, the source code of which is available on https://github.com/scanmem/.

The Linux client also suffered from the same issue, which is not surprising because it’s using the same code base as the Windows version.

I contacted one of the developers in the OpenConnect IRC channel, and contrary to some of my experiences with closed source vendors, I was met with great enthusiasm. The bug was fixed exceptionally rapidly by David Woodhouse and is part of the version 8.00 release.

Advice for Software Developers

Secure programming guidelines are to clear memory of sensitive data immediately when it is no longer required. There is a MITRE documented software weakness entry for this issue at https://cwe.mitre.org/data/definitions/244.html.  When using C or C++, be especially careful as the compiler can optimise away a call to memset just before memory is released.

See the following CERT secure programming guidelines for more information:

Conclusion

You never know if some stealthy malware is scanning memory on your endpoints. Always use two factor authentication and patch software regularly to avoid falling foul of vulnerabilities like this one.

Timeline

  • 20 December 2018 – Discovery
  • 21 December 2018 – CVE issued
  • 22 December 2018 – Vendor contacted
  • 05 January 2019 – Vendor fixed issue
  • 19 June 2019 – Nettitude disclose details