Virtual Private Keylogging: Cisco Web VPNs Leveraged for Access and Persistence
October 7, 2015
Whether you are proactively monitoring your network or reactively undergoing an incident response, one of the last places you might examine for backdoors are your firewalls and VPN gateway appliances. As the industry is learning, firewalls, network devices, and anything else an attacker might be able to gain access to should be scrutinized just as much as any workstation or server within an organization. Having your own devices turned against you can make for a bad week. This represents yet another way attackers are taking credential theft and network persistence to the next level.
Cisco Clientless SSL VPN (Web VPN)
The Cisco Clientless SSL VPN (Web VPN) is a web-based portal that can be enabled on an organization’s Cisco Adaptive Security Appliance (ASA) devices. The Cisco Web VPN does not require a thick client and is accessed entirely through a web browser by end users. Once a user is authenticated to the Web VPN, based on the permissions the user has, they may be able to access internal web resources, browse internal file shares, and launch plug-ins that allow them to telnet, ssh, or VNC to internal resources. The average user would interface with their organization’s Cisco Web VPN via a screen similar to the one show in Figure 1 below.
This is certainly not a resource to which you want an attacker to gain access. Unfortunately, Volexity has found that several organizations are silently being victimized through this very login page. This begs the question: How are the attackers managing to pull this off? It turns out it’s possible through a couple different methods. The first method involves an exploit and the second requires good old fashion administrative access.
CVE-2014-3393: Security Appliance Turned Security Risk
Volexity has been able to track its earliest known abuse of Cisco Web VPN login pages back to November 2014. It appears to have started with CVE-2014-3393, a vulnerability in, you guessed it, the Cisco Clientless SSL VPN portal. This issue was initially reported by Alec Stuart-Muirk and was covered by Cisco Advisory ID: cisco-sa-20141008-asa on October 8, 2014. Cisco also released a notice about public exploitation of the vulnerability on February, 18, 2015. An excerpt from the original advisory describing the vulnerability is shown below.
A vulnerability in the Clientless SSL VPN portal customization framework could allow an unauthenticated, remote attacker to modify the content of the Clientless SSL VPN portal, which could lead to several attacks including the stealing of credentials, cross-site scripting (XSS), and other types of web attacks on the client using the affected system.
The vulnerability is due to a improper implementation of authentication checks in the Clientless SSL VPN portal customization framework. An attacker could exploit this vulnerability by modifying some of the customization objects in the RAMFS cache file system. An exploit could allow the attacker to bypass Clientless SSL VPN authentication and modify the portal content.
Later in the same month at Ruxcon 2014, Stuart-Murik further detailed the Cisco Clientless SSL VPN vulnerability in a presentation titled “Breaking Bricks and Plumbing Pipes: Cisco ASA a Super Mario Adventure“. Coinciding with his presentation, a Metasploit module was released that could be leveraged to exploit vulnerable servers.
Exploitation in the Wild
While not visible due to URL obfuscation, the file 1.js was hosted on the compromised website of a legitimate NGO. This website also leveraged a valid SSL certificate, which kept all communications encrypted. The file 1.js was a variant of an online script called “xss.js” that was designed to steal form data. Victim organizations effectively had their Cisco Web VPN devices turned into credential collectors for the attackers. This particular round of attacks appears to have compromised several organizations around the globe. Volexity observed this campaign successfully compromising the following verticals:
- Think Tank / NGO
- University and Academic Institutions
- Multi-national Electronics / Manufacturing
In several other cases involving breaches to the Cisco Web VPN, it is unclear if an exploit was leveraged or if the attackers actually already had sufficient credentials to directly modify the login page through administrative access. Volexity has worked on several past intrusions where attackers have thoroughly breached an organization and have been able to gain access to security devices, networking equipment, and other critical information technology resources. Attackers are typically able to gain “legitimate” access throughout a victim organization’s environment by installing keyloggers, dumping credentials from systems, exfiltrating documents (spreadsheets) that contain password lists, and identifying passwords that are commonly reused by administrators. Once armed with these credentials, an attacker with access to a victim’s network can typically perform the same functions as any administrator or highly-privileged individual within the company.
Volexity knows it is 100% possible and surmises it may be likely in some cases that the attackers leveraged credentialed administrative access to a Cisco ASA appliance in order to modify the login page. This can be done via the Cisco Adaptive Security Device Manager (ASDM), a Java administrative interface for Cisco firewalls that can be accessed via a web browser. Access to the devices ASDM should be restricted through access control lists (ACLs) as tightly as possible. At minimum, this is not an interface that should be open to the Internet. Attackers that are able to access this interface by having access to a victim’s environment or due to an ACL misconfiguration can easily modify code that is loaded via the Cisco Web VPN login page.
Organizations can also examine the settings for the Clientless SSL VPN from within the ASDM to verify that nothing is out of the ordinary. In order verify the Web VPN settings, you must first be logged into the ASDM. Then you can navigate to the following: Remote Access VPN -> Clientless SSL VPN Access -> Portal -> Customization. Once at this screen, you can load the various components of the Portal Page. Below is an example of the default view of the Title Panel settings for the Logon Page. This is the most commonly modified area of the Web VPN that’s been observed by Volexity thus far.
Japanese Government and High-Tech Industries Targeted
The code shown in Figures 6 and 7 are just a small excerpt of the Scanbox keylogger plugin. Other functions that facilitate building the URI associated with captured keystrokes are not shown. The Scanbox code on the Japanese Government and High-Tech Cisco Web VPNs were being used to record data on users accessing the services. This allowed the attackers to steal credentials in real-time and maintain persistent access to the networks of the victim organizations. Volexity worked with JP-CERT in June of this year to share relevant information on this threat.
Additional Hostnames and Domains
Digging into the attacker controlled domain mailsecure.cc turns up a few more interesting hosts.
Following the theme of accounts.nttdocomo.mailsecure.cc are hostnames of other popular Japanese companies and websites. Volexity did not observe this round of attacks associated with any of the organizations from the subdomain. It appears the attackers are using the names of legitimate Japanese companies and websites in an effort to make the traffic blend in with legitimate traffic. Digging into the e-mail address on the WHOIS registration for mailsecure.cc, email@example.com, leads to several other domains owned by the attackers.
Further research into these domains also yields interesting subdomains. A few of the themes appear to look similar to valid Google hosts and others, once again, have a Japanese oriented theme to them.
Interestingly, Novartis AG filed a complaint about the domain novartis-it.com with the World Intellectual Property Organization (WIPO). In a decision made on September 7, 2015, it was determined the domain should be transferred to Novartis. As a result, this domain may not be under attacker control for much longer.
The Malware Connection: PlugX
Until recently, Volexity did not have the above threat activity tied to specific malware or another known threat group. Several of the above hostnames were leveraging the IP address 255.255.0.0 when parked or not in use. Volexity tracks a threat group that also uses this IP when inactive, but this was not enough to definitively link the two. However, on July 31 and August 18 of this year, multiple hostnames from the aforementioned list and hostnames tied to PlugX malware overlapped on the IP addresses 220.127.116.11 and 18.104.22.168. The following hostnames, not previously confirmed as connected to the list above, were now on overlapping infrastructure:
In particular, a public report (TR-24) from the Computer Incident Response Center Luxembourg (CIRCL) describes a PlugX variant that communicates with microsoft.operaa.net and microsoftno.operaa.net. Also, previous but now defunct hostnames associated with this threat actor shows an affinity for Novartis. The following hostnames can be found online and in passive DNS:
The list below contains active non-parking IP resolutions and ASN information for this groups various hostnames:
|IP Address||ASN Information|
|22.214.171.124||133731 | 126.96.36.199/22 | TOINTER-AS | CN | – | Shanghai Fanyun software Co.LTD|
|188.8.131.52||20473 | 184.108.40.206/21 | AS-CHOOPA | US | vultr.com | Vultr Holdings LLC|
|220.127.116.11||7506 | 18.104.22.168/17 | INTERQ | JP | gmo.jp | GMO Internet Inc.|
Two-Factor Authentication (2FA)
- Session Cookie Theft: The malicious code could be modified to specifically steal session cookies after a user has established an authenticated session. In Volexity’s testing, it was possible to have two simultaneous Cisco Web VPN sessions using the same session cookies. This means an attacker could leverage the same session as an active legitimate user without either of them being disconnected.
- Token Theft and Reuse: Assuming a user’s 2FA leverages a numeric token (or similar), an attacker could potentially hijack the user’s initial authentication attempt and quickly reuse that token to access the victim infrastructure. This would prevent the user from initially logging into their own infrastructure. However, the attacker could then set a cookie to prevent subsequent authentication attempts from being hijacked. Preventing the user from ever authenticating would raise many flags, whereas only interfering with a single login attempt is less likely to result in discovery.
Leveraging 2FA on VPNs is a must for organizations. However, it should not be seen as bullet proof. Users are still susceptible to being phished or otherwise having their authentication attempts hijacked. The attackers are fairly ingenious and will likely find a way to gain access, if they are motivated enough.
Attackers are continuing to find new ways to use and abuse systems for long term persistent access to networks and systems of interest. This problem is not remotely unique to Cisco Web VPNs. Any other VPN, web server, or appliance that an attacker can gain administrative access to or otherwise customize/modify will potentially present similar risks. As recently made apparent through public disclosures of various backdooring methods, such as SYNful Knock, no device within a network is off-limits to motivated attackers. When proactively hunting for threat activity on your network and, in particular, when conducting an incident response to an active intrusion, be sure to leave no stone left unturned.