Category: blog

Vulnerability Management concepts are changing. The idea that vulnerability management is limited to scanning alone is being replaced with a wider and more comprehensive view. It’s now transforming to a concept called vulnerability identification, which is an umbrella for any type of service or activity centered around identifying vulnerabilities. This can include scanning and penetration testing, as well as breach and attack simulations.

Legacy ideas on vulnerability management tend to result in a lack of full understanding of the asset environment. Typical vulnerability management programs are not keeping track of everything that’s out there, especially externally facing components that may have dropped off the radar. There also tends to be shortcomings regarding the proper definition of scanning profiles, including what to scan for and what should be considered critical issues that need to be flagged with the highest priority.

What Today’s Vulnerability Management Should Look Like

One of the first steps in improving the performance of a vulnerability management program is that vulnerability scans should be performed quarterly while keeping a close watch on remediations to ensure standards are met. Too often, companies may have older, orphan systems that are not properly locked down or externally-facing servers that also lack proper security configurations. Every quarter (or even better, monthly), a business should scan to validate new assets, determine how those assets are being used, and link the teams that have taken ownership of the assets.

Another essential step is the creation of a risk register. This register should be the cornerstone of an effective vulnerability management program as it provides an assessment of vulnerabilities compared to the risk tolerance for a business. Risk tolerance is determined by variables such as potential liability that your organization could face, particularly in industries such as banking, insurance, or healthcare, and the likelihood of an attack from a variety of threats, such as criminal hackers or nation-states.

This type of risk evaluation can answer key questions such as:

• What is considered a critical area of protection?
• When a patch is released for a critical area, will the SLA be 60 or 90–days?
• Will logs be kept for a typical 14-day rotation or several months to trace back the source of an attack?
• Will logs be deleted or placed into cold storage?
• Will peak traffic be captured separately?

This risk register process should also include an evaluation of asset management. It must be determined if a list of all assets within a protected environment, and outside of it, is current and accurate. Keep in mind that an orphan system, that has fallen off an asset list, may have no endpoint protection monitoring or logs tracking activity, making it ripe for exploitation.

How to Improve Visibility Into Vulnerability Management

Most organizations will also need a good way of centralizing vulnerability management data. It’s common in some companies for the results of key security operations, such as penetration tests, to live on a PDF, while governance risk and compliance (GRC) lives in another location, and the massive files showing scan data may even be in another spot. Data from scanning, penetration tests and GRC all need to be moved to a single source to enable effective data orchestration to drive decision making. A company should be able to analyze all of this information so they can validate if the number of vulnerable assets is increasing or decreasing, and to determine the criticality of the vulnerabilities uncovered.

And this brings us to our next point. For vulnerability management to be truly effective, this centralized repository of data needs to be fed into what we call a vulnerability management orchestration platform. This type of platform can perform trend mapping to identify whether a security environment is heading in the right direction. It can show trends, and perform analytics on data such as severities, engagements, custom tags, and timeframes. It’s the type of insight that’s always useful when budgetary decisions need to be made to allocate resources.

Analysis in Action

To understand how this tool can be used, consider the example of a business that has an external asset list that grows continually, year-after-year. But the vulnerability tabulations are not going down. This probably indicates that a new approach to how this business handles their information security is needed. Similarly, if a company conducts penetration tests and comes back every year identifying that default password usage is commonplace, then a new password policy is probably needed. These examples are typical of the actionable visibility that can be provided by a vulnerability management orchestration platform.

What should you look for when evaluating the performance of this type of technology? A vulnerability management orchestration platform should support host-based remediation efforts by consolidating all findings for an asset, regardless of where the risk was identified. It should be able to import findings and automatically be able to populate information into standardized reports. The right solution will also have the ability to tag essential assets to enable rapid filtering for analytics to highlight problems that need the most attention.

With the right tools and processes in place, vulnerability management can expand far beyond its original definition. By truly taking on the role of identification, classification—and ultimately mitigation—of vulnerabilities, this new integrated and comprehensive concept can help you find and close all the hidden openings into your technology infrastructure.

TEAMARES helps organizations identify, classify, prioritize, assist in remediation, and mitigate software vulnerabilities. Talk to a TEAMARES expert to learn how to take action on your vulnerability data.

About the Author: 

Quentin Rhodes-Herrera, CyberOne’s director of professional services, leads the offensive and defensive teams known as TEAMARES. He is an experienced security professional with expertise in security analysis, physical security, risk assessment, and penetration testing. Quentin’s diverse background is built from a variety of staff and leadership positions in IT, with specific experience in threat and vulnerability management, penetration testing, network operations, process improvement, standards development, and interoperability testing.

Versions Tested:

• Aviatrix Cloud Controller UserConnect-5.3.1516
• Aviatrix VPN Client 2.8.2

Product: https://aviatrix.com/cloud-network-platform/

Security Advisories: https://docs.aviatrix.com/HowTos/security_bulletin_article.html

Summary:

CyberOne‘s TEAMARES recently discovered multiple vulnerabilities in the Aviatrix Cloud Controller appliance v5.3.1516 and Aviatrix VPN client v2.8.2 for Linux, macOS, and Windows. TEAMARES would like to thank the Aviatrix security team for partnering with us to get the issues resolved.

The Aviatrix security team provided the following upgrade instructions.

1. Upgrade – This is a software upgrade and does not fix previous versions. All security issues, bugs, and features are fixed in new releases. We recommend that the customer stay updated with the latest release to resolve security vulnerabilities. Software upgrades are typically released in a 4-6 week schedule. There is no software downtime to perform software upgrades. When a new software upgrade is available, Aviatrix Admin will receive an alert on the Controller console. When a particular release contains security patch, a field notice will be published. Field notices are emailed to Aviatrix Controller Administrator and it is also communicated in our documentation: https://docs.aviatrix.com/HowTos/field_notices.html.
2. Migration – This is an appliance upgrade. When performing a migration, the system is shutting down your previous controller, gateway instances, and launching a new image. The automated processes will grab the image from Aviatrix’s authorized service and check to make sure the latest backup is performed. Once the validation checks are completed, the system will automate a migration performed locally. Please note that the controller will control the Gateway migration.

To see your latest software upgrade, migration option, and Gateway version, login as admin to the Aviatrix Controller console > Settings > Maintenance > Upgrade. See the image below.

Product Overview:

Aviatrix cloud-native networking establishes an abstraction layer between the public cloud providers’ native networking and security constructs and the application to simplify networking in AWS, Azure, Google Cloud, and Oracle.

The Aviatrix Controller and Gateways are deployed as software in your VPCs and VNETs. The Aviatrix Controller provides programmatic control over the native constructs so you can easily take advantage of the cloud providers existing services. Additionally, the same Aviatrix Controller enables you to extend the native services by adding enterprise-class control for hybrid connectivity, data security, multi-cloud operations, monitoring, and troubleshooting.

Source: https://aviatrix.com/features/

Details:

This blog will focus on two critical unauthenticated vulnerabilities discovered in the Aviatrix Cloud Controller. The complete list of vulnerabilities are listed in the vulnerabilities table at the end of this blog. To manage the controller, an administrator must log in to the web console.

The controller also supports a set of APIs available to manage the appliance. The Aviatrix API Documentation states the “CID” parameter represents the session identifier, which the majority of API calls require.

Through dynamic and static code analysis, we discovered two sensitive API calls. The setup_network_options and edit_account_user APIs should require administrator-level access but did not validate the CID parameter. The setup_network_options API was leveraged to achieve unauthenticated remote code execution, and the edit_account_user API could be used to take control of the administrator account.

Pre-Auth Remote Code Execution

Reviewing the source code of the setup_network_options API function shows a call to the move_uploaded_file() PHP function. This function does what it sounds like and moves a file from one location to another after an HTTP POST request.

The setup_network_options API could be used to upload a new proxy certificate; however, the input filename and certificate content was not validated or sanitized. This allowed arbitrary files to be uploaded. The TMPDIR constant was set to the tmp directory inside of the webserver root. This path is used by several functions to stage uploaded files before processing. The location is protected by an Apache .htaccess file which by default denied all HTTP requests. This configuration effectively blocked the access/execution of any .php script files that could be uploaded.

Upon further investigation, the tmp directory was discovered with directory permissions set to be world-writable (777). This allowed the www-data user to create and update files under this directory, thus allowing the www-data account to also overwrite the .htaccess file.

The exploit was updated to first upload a new .htaccess file with an allow directive from our IP address.

The exploit now uploads a new .htaccess file, the PHP exploit (web shell), and then calls the PHP file resulting in a reverse shell running as root.

Root access was gained in a single step because the Sudo configuration allowed the www-data user to execute all commands as any user on the system.

Pre-Auth Account Takeover

The edit_account_user API did not verify the CID session value. This was leveraged to silently take over the admin account. When updating the email address of admin via the API, the current email address is not notified that a change was made to the account.

Now that the address for admin account had been updated, a “Forgot password” request may be initiated.

Within 60 seconds a one-time password (token) was sent to the updated admin email address under our control.

The token was submitted via the “Account Verification” page.

At this point a new password could be set for the admin account, concluding a successful account takeover attack.

The latest version of the Aviatrix Cloud Controller properly validates the CID value and adds additional hardening and authorization checks. Attempting to access the APIs from an unauthenticated view returns an error.

CVE NumberFix VersionFix TypeVulnerabilityAffected ProductRatingDescription2020-26553R6.0.2483 (8/4/2020)Upgrade + MigrationPre-auth Remote
Code ExecutionAviatrix Cloud Controller
UserConnect-5.3.1516
4.6CriticalAPI file doesn’t require valid session ID & allows arbitrary files to be uploaded to web tree2020-26552R5.4.1290 (8/5/2020)UpgradePre-auth Account
TakeoverAviatrix Cloud Controller
UserConnect-5.3.1516CriticalAPI file doesn’t require valid session & allows for account email address updates2020-26550R5.3.1551 (6/4/2020)Upgrade + MigrationInsufficiently Protected CredentialsAviatrix Cloud Controller
UserConnect-5.3.1516CriticalEncrypted file containing credentials to unrelated systems is protected by a weak key2020-26553R6.0.2483 (8/4/2020)UpgradePost-auth Remote Code ExecutionAviatrix Cloud Controller
UserConnect-5.3.1516HighSeveral APIs contain functions that allow arbitrary files to be uploaded to web tree2020-26551AMI Software Version 050120
(Aug 13, 2020)Upgrade + MigrationCleartext Storage of Cryptographic KeyAviatrix Cloud Controller
UserConnect-5.3.1516HighEncrypted key values are stored in cleartext in a readable file2020-134172.10.8 – May 14 2020UpgradeIncomplete Fix for CVE-2020-7224 Elevation of PrivilegeAviatrix VPN Client 2.8.2
macOS, Linux, WindowsHighVulnerability was previously reported & an incomplete patch was releasedPending2.10.8 – May 14 2020UpgradeArbitrary File WriteAviatrix VPN Client 2.8.2
macOS, LinuxHighVPN service writes logs to a location that is world writable and can be leveraged to gain write access to any file on the system2020-13413R5.4.1290 (8/5/2020)UpgradeObservable Response Discrepancy – User EnumerationAviatrix Cloud Controller
Aviatrix Cloud Controller
UserConnect-5.3.1516MediumAn API can be used to enumerate valid accounts2020-26548R5.4.1290 (8/5/2020)UpgradeInsecure sudo ruleAviatrix Cloud Controller
UserConnect-5.3.1516MediumUser account has permission to execute all commands as any user on the systemPendingR5.4.1290 (8/5/2020)UpgradeInsecure File PermissionsAviatrix Cloud Controller
UserConnect-5.3.1516MediumSeveral world writable files and directories were found2020-13414R5.4.1290 (8/5/2020)UpgradeHard-coded CredentialsAviatrix Cloud Controller
UserConnect-5.3.1516LowAviatrix Cloud Controller contains credentials unused by the software2020-26549R5.4.1290 (8/5/2020)UpgradeBypass htaccess security controlAviatrix Cloud Controller
UserConnect-5.3.1516LowThe htaccess control to prevent requests to directories can be bypassed for file downloading

Timeline:

04/13/2020 – Initiated contact with the vendor to determine a secure method to transmit the report.
04/20/2020 – Conference call with the vendor; report sent.
05/05/2020 – Conference call with the vendor.
06/30/2020 – Conference call with the vendor.
07/08/2020 – The vendor provided a test environment to verify the patches.
07/10/2020 – Verified critical vulnerabilities were mitigated.
07/21/2020 – Conference call with the vendor.
10/01/2020 – Conference call with the vendor.
10/19/2020 – Updated CVE list received along with customer upgrade instructions.

Summary:
VMware Fusion contains a local privilege escalation vulnerability that allows an attacker to inject a malicious path into the system-wide PATH environment variable.

Versions Tested:
VMware Fusion Professional v15.5.5

Product:
https://www.vmware.com/products/fusion.html

Security Advisories:
https://www.vmware.com/security/advisories/VMSA-2020-0020.html

CVE Number:
CVE-2020-3980

CVSS Score:
6.7

CWE:
CWE-269: Improper Privilege Management

Vulnerability Details

During a startup, VMware Fusion updates the “Public” path in /etc/paths.d/com.vmware.fusion.public using a leading path determined at runtime. A user with standard permissions can make a copy of the application, execute it from an untrusted location, and the value defined in com.vmware.fusion.public will be updated to this location. All interactive sessions, including the root user, will then have the untrusted location set in the system PATH environment variable. A trojan horse binary could be added that would be executed if it were not found in the standard directories. It is also possible to embed code into the path, which will be executed upon login by any user on the system.

The exploit is a two-stage process. The first stage creates an entire copy of the VMware Fusion application using hard links to save space.

The second stage is to execute VMware Fusion from the path where stage one copied it. This kicks off several processes in the background, waits five seconds, and then kills the application. When this stage completes, the com.vmware.fusion.public file in /etc/paths.d will contain a path set to a location we control.

Proof of Concept

The following proof of concept shows the exploit running as the test05 standard user.

When the exploit finishes, the system PATH environment variable is updated to include /Users/test05/.vmware.stager.Gagas/VMware Fusion.app/Contents/Public.

Now when any user logs in interactively, the system PATH environment variable will include the path that we control. Any application that does not specify the full path or reset the PATH variable could potentially be tricked into executing a malicious binary from this location. It is also possible to silently cause the user logging in to execute arbitrary commands.

Timeline:

06/03/2020 – Vulnerability reported to the vendor
07/08/2020 – Vendor confirms the vulnerability
07/29/2020 – Vendor requests extension due to issues
09/14/2020 – Vendor advisory and patch released. VMSA-2020-0020

Credit:

Vulnerability discovered by Rich Mirch, Senior Penetration Tester for TEAMARES

It is no secret that wildly different political views aside, the threat of foreign and even domestic interference in the 2020 U.S. presidential elections is dominating our politics in advance of November.

At its core, the subject of election security comes down to one key question: How secure is your vote?

The Current State of Electronic Voting

Election Security Must Change with Technology

As the nation increasingly moves toward electronic voting, increased electronic tabulation, and increased electronic transmission of results, we should be rethinking our strategy for ensuring the integrity, authentication, and non-repudiation of elections that rely so heavily on technology.

Who Oversees U.S. Election Security Threats?

Currently, the FBI, Department of Homeland Security (DHS), Cybersecurity and Infrastructure Security Agency (CISA), U.S. Cyber Command, and various other government agencies do their best to react to cybersecurity threats during elections.

While they do a good job of reacting to reports of fraud and cyberattacks and validating whether or not they occurred, this is all reactionary and does not amount to detection or prevention.

The Voting Machine Market Is Dominated by Only 3 Manufacturers

According to the Election Assistance Commission, there are only about ten approved electronic voting machine manufacturers and three of them account for almost 90% of the market.

When you go to the polling place, you will likely encounter one of those three companies’ machines.

Most likely it will be similar to a giant scantron where you either fill in the bubbles or punch out a chad and then feed your ballot into the machine.

No Paper Trail for Voters to Prove How They Voted

If you are provided with a confirmation that the machine counted your vote, it will either be a visual counter on the machine or a paper receipt confirming only that the machine has accepted your ballot.

You do not get anything that you can later use to prove how you voted in a contested election.

No Security Features Mandated for Voting Machines

What is most alarming is that there are no mandated security features for voting machines.

There is a set of Voluntary Voting System Guidelines (VVSG), which are a set of specifications and requirements for determining if voting systems meet required standards (including security recommendations), but they were last updated in 2015.

Current Voluntary Voting System Guidelines Are Inadequate

Tests run by third-party vendors in 2019 and 2020 found that none of these systems met the security protocols outlined in the 2015 standards.

Since then, additional security features have been recognized as needed by the National Institute of Standards and Technology (NIST) and Version 2 of the VVSG is in draft form which includes them.

But even then, there is no mandate, regulation, or law requiring that the voting machine meet these requirements.

Many machines in use today also predate even the 2015 standard and are using the 2010 guidelines, if they are using any at all.

Election Management Systems Also Lack a Security Protocol

Once the ballots are counted by the machines, they are transmitted electronically to higher-tiered election officials and eventually the Secretary of State (or equivalent) for that State.

Generally, these kinds of networks of election machines are known as election-management systems, and there are no security requirements for these systems either.

During this chain, there is a general lack of checking to ensure that the tallies were correct at each site or that the transmitted results were not tampered with.

Case Study: 2018 Georgia Mid-Term Elections

As an extreme example, during the 2018 midterm elections, Georgia was still using voting machines that had not had a security patch applied since before 2005.

To make matters worse, the FBI was contacted by a politician in Georgia around this time who had been called by someone who said they could hack the result to guarantee that candidate won the race for just $50,000.

In that case, the FBI successfully resolved the issue, but it relied on the fact that the politician was honest enough to report the offer, and the resolution did not make the process of voting any more secure.

Three Measures Necessary to Improve Electronic Voting Security

So how do we actually make the process more secure and ensure the integrity of legitimate ballots cast?

The three most crucial measures the U.S. can (and should) take are authentication, integrity, and non-repudiation. Let’s look at each of these measures in more detail.

Authentication

A process must be put in place that can be used to authenticate that:

1. the voter is who they say they are;
2. the voter is eligible to cast their ballot;
3. they have not voted elsewhere; and
4. if a vote for them is recorded elsewhere, they are allowed to clarify which is the correct vote.

This process must also allow for provisional voting that can be verified at a later date.

Integrity

The NIST recommendations and VVSG 2 should be ratified, and those standards should be made mandatory for a machine to be used.

Penetration and vulnerability testing of all machines should be required prior to their adoption.  Penalties should be assessed against vendors who claim their machines are secure but who fail this testing, including barring them from the marketplace.

Older machines that cannot pass security testing must either be patched by the vendor or replaced. If the machines cannot be replaced in a timely manner, paper voting must be implemented as a backup.

Both voting machines and election-management systems must be checked prior to and after elections to ensure that the code deployed on both are the same.

Non-Repudiation

When ballots are cast, the person voting should be given a paper receipt which shows them how the machine recorded their vote, including a two-way cipher that can be used to authenticate their results. In the event of a close or contested election where a recount occurs, the cipher can then be reversed.

Without a paper trail of each vote, no one can adequately check for discrepancies.

Failure to adopt these concrete solutions puts the integrity of the 2020 election and future elections at risk.

Not addressing these concerns doesn’t mean our elections will be hacked, but there is no question that it increases the likelihood of interference, fraud, and distrust.

When TEAMARES began research into the vulnerability identified in the F5 TMUI RCE vulnerability advisory released last month, we initially started by reading the advisory and mitigation steps, which contained minimal details but included key pieces of information needed to kick off our research. The advisory states that the vulnerability impacts a variety of capabilities when exploited, including the ability to execute arbitrary Java code, which stood out to us.

Reading the mitigation steps immediately points to directory traversal and potential command injection. The interesting character in the pattern is the semicolon.

The first step was to compare changes between the known vulnerable versions and the fixed versions, so we began by comparing system configurations between 15.1.0 against 15.1.0.4. We found that there were a plethora of differences, but the following changes to the Apache configuration piqued our interest in particular and led to us going down this rabbit hole.

The screenshots show the /hsqldb endpoint was removed from the reverse proxy configuration. The Tomcat application server listens on localhost:8009.

Running a basic unauthenticated GET request redirected to the login page, which is expected as authentication is required to access the management application.

With the vulnerability mitigation steps in mind, we appended a semicolon and the request was successfully sent to the application server. This must be the authentication bypass because this endpoint should not be reachable.

Now that we could reach /hsqldb, we set off on a journey to see what could be done with it. HyperSQL is an embedded relational database used by Java applications. Through reading documentation and looking for ways, this could be abused.

The first attempt used a User Defined Function (UDF); however, it was discovered that the feature is not available in v1.8. We found that we could call native Java functions or any method available to the server with the primary restriction being that it had to be a static method. After looking for static methods in the HSQLDB source code, we found the org.hsqldb.util.ScriptTool.main() method deserializes a Java objected represented as an ASCII hex string. This looked very promising, so we attempted to call this manually using sqltool and hit a “Serialization failure” error.

Thankfully, the error message informed us of how to resolve it. Setting the enableUnsafeSerialization property to true and executing the payload was successful. At this point, we proved that authenticated remote code execution was possible. Attempting to use /hsqldb; with a POST request resulted in a connection error, so we took another look at the mitigation regex “.*..;.*”  and noticed that the authentication bypass was “..;”. We then changed our exploit to work with that regex, allowing us direct access to HQSLDB.

Create a new user with the admin role via tmsh. This operation creates a root system account.

Versions Tested:

• F5 BIG-IP 15.1.0
• F5 BIG-IP 14.0.0

References:

• https://support.f5.com/csp/article/K52145254
• https://www.ptsecurity.com/ww-en/about/news/f5-fixes-critical-vulnerability-discovered-by-positive-technologies-in-big-ip-application-delivery-controller/

Credit:

Authentication bypass discovered by Mikhail Klyuchnikov of Positive Technologies

Proof of Concept research by Charles Dardaman, Senior Adversarial Engineer, and Rich Mirch, Senior Adversarial Engineer for at TEAMARES

Many organizations are shocked to learn their systems have been breached, with attackers having exposed vulnerabilities. However, you can defend your organization against these threats by taking some proactive measures.

Minimizing your security risk begins with risk management – ensuring proper asset management, implementing policies and procedures around protecting assets, and effective risk mitigation. Yet these fundamentals are frequently lacking in organizations, according to Quentin Rhoads-Herrera, Director of Professional Services for TEAMARES, during CRITICALSTART’s webinar, “Uncovering Your Security Blind Spots.”

“One of the most important things that I see quite often when we discuss risk management is asset management. This is a key fundamental to IT infrastructure and software risk management,” said Herrera. “If we don’t understand as a company what is out there in our infrastructure or what software we’re leveraging, then we’re not going to have insight into whether a company is following best practices for software development lifecycle.”

According to Herrera, here are some basics in which organizations can shore up their vulnerabilities:

• Ensure that asset management is elevated within your organization. For many, asset management is an afterthought, with processes and procedures developed later in the development of the company.
• Develop policies and procedures including implementing standards and detailed descriptions on how to comply with policies.
• Create a risk register and operationalize risk management. In some cases, the risk register has not been created because the company doesn’t understand their risk tolerance or what their threat actors may look like.
• Assess and manage vulnerabilities by implementing pentesting. An effective pen testing program helps you discover vulnerabilities while modeling the tactics of real-world threat actors.
• Conduct IR tabletop exercises to develop a high-level understanding of current cybersecurity processes.
• Increase efficiency through automation and technology, including leveraging of open-source tools.

It’s entirely possible to understand your security risk. The key is to identify and understand those risks. TEAMARES stands ready to help you improve your security posture. If you need assistance establishing an effective risk management program, contact us today.

Flexible, Open-Source Tool to Manage Post-Exploitation Issues – Without the Extra Spend

PLANO, TX – July 23, 2020  – TEAMARES, the offensive security and incident response arm of CyberOne, today announced the launch of DeimosC2, addressing the market need for a cross-compatible, open-source Command and Control (C2) tool for managing compromised machines that includes mobile support.

Offensive security teams often need access to a cost-effective, easy-to-use tool that can manage compromised machines after exploitation. However, many of the options currently available in the market can be difficult to use, expensive, or lack the flexibility to expand features. With this in mind, TEAMARES developed DeimosC2, a cross-platform and collaborative tool designed with robust functionality that can be extended in any language. Teams can conduct post-exploitation on any major operating system (OS), including Android devices, addressing the lack of defensive capabilities that are available on enterprise devices.

DeimosC2 features include:

• A UI that offers ease of use and supports multiple users for collaboration.
• Multiple listener and agent communication methods such as TCP, HTTPS, DNS over HTTPS (DoH), and QUIC.
• Pivot capabilities over TCP.
• Extendable functionality that can be written in multiple languages.
• API over WebSockets allowing for scriptable functionality.
• Written in Golang for cross-compatibility on all major operating systems.
• Archive and replay functionality post-testing so users can restore listeners, loot, and other critical information to the database.

“Red teams usually have to choose between expensive C2 tools in the market or training for their teams on the current tools,” said Quentin Rhoads-Herrera, director of professional services for TEAMARES and co-author of DeimosC2. “Deimos is an open-source, community-contributed tool that is designed for ease of use and cross-OS compatibility without a large spend of budget or time.”

Visit us at deimosc2.com to learn more.

Versions Tested:

• GlobalProtect App < 5.1.4 on Windows
• GlobalProtect App < 5.0.10 on Windows

Product:
https://www.paloaltonetworks.com/products/globalprotect

Security Advisories:
https://security.paloaltonetworks.com/CVE-2020-2032

CVE Numbers:
CVE-2020-2032

CVSS Score:
7.0

CWE:
CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition

NIST:
N/A

OWASP:
N/A

Summary:

A race condition vulnerability in the Palo Alto Networks GlobalProtect app on Windows allowed a local limited Windows user to execute programs with SYSTEM privileges. This issue can be exploited only while performing a GlobalProtect app upgrade.

Details:

­The Global Protect App Windows MSI installer executes as SYSTEM and uses a predictable path to create and execute a batch file from a location writable by all users. Prior to the update, a low privileged user could create a file named C:WindowsTemppostupdt.bat which is called by PanVcrediChecker.exe during the install/update.  The application overwrites the contents of the batch file. However, the ownership by the low privileged user was retained. A TOCTOU race condition exists, allowing a low privileged user to overwrite the file prior to the execution.

All users have permission to create new files in C:WindowsTemp and some applications store transient files here. The folder is like how /tmp is used on Linux systems, but the permissions are different. On Linux, file listing is allowed by low privileged users while, on Windows, a low privileged user cannot list the files.

Using a command shell, the low privilege user attempts to list the files under C:windowstemp and “File Not Found” is returned. This message is deceiving because files exist, but the user does not have the proper permission to list them.

Though a low privileged user cannot view the listing of files, it does have permission to create a new file. Using an administrator command shell and executing cacls to view the access control list shows that BUILTINusers have a few specific permissions. FILE_WRITE_DATA allows all users to create new files.

Windows has many file permissions and the names can be misleading. Fortunately, the permissions are documented on Microsoft.com. Included below are descriptions of the relevant permission descriptions for BUILTINUsers. Visit Standard Access Rights, and File Access Rights Constants for additional details.

Constant/ValueDescriptionSYNCHRONIZEThe right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right.FILE_WRITE_DATAFor a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (FILE_ADD_FILE).FILE_APPEND_DATAFor a file object, the right to append data to the file. For a directory object, the right to create a subdirectory (FILE_ADD_SUBDIRECTORY).FILE_EXECUTEFor a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.

With a basic understanding of how C:WindowsTemp is used, we can look for potential vulnerabilities. Some installers still use C:WindowsTemp for temporary files. My favorite utility for discovering file-based vulnerabilities is Sysinternals Process Monitor. Start the process monitor as an administrator and set the filter to the following. As an example, this filter will limit output to system users accessing files under C:WindowsTemp.

During the install/update, PanVcrediChecker.exe creates C:WindowsTemppostupdt.bat and then executes it. Note that some operations were excluded for brevity purposes.

An alternate view of the same data uses a process tree. This view can be accessed by using the Tools | Process Tree menu.

Drilling down on the event shows the following properties.

Armed with the knowledge learned through dynamic testing, a proof of concept can be developed. The goal is to create the postupdt.bat file, initiate the upgrade, and then continuously overwrite the file and attempt to win the race.

Steps to Reproduce:

Assumptions:

• All steps are executed as a low privileged user
• GlobalProtect client is a lower version than the VPN server
• The C:WindowsTemppostupdt.bat file does not exist which is should not if an update has not been run recently.

1.  Create C:WindowsTemppostupdt.bat with the following contents. The first line should be the arbitrary command to execute. The PanGPS.exe -benice is the command normally executed and is included to ensure the installation process does not fail.

whoami &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt; c:windowssystem32woot.txt&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/pre&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
“C:Program FilesPalo Alto NetworksGlobalProtectPanGPS.exe” -benice

2.  Create loop.cmd with the following contents and execute it. This will overwrite the target file using an infinite loop.

:loop&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/pre&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
@echo f | xcopy postupdt.bat c:WindowsTemppostupdt.bat /y /f

goto loop

3.  Connect to the Global Protect server with a higher-level version. This should automatically prompt to update the client. Click the “Yes” button. If there is no prompt, right-click the system tray application and click About.

4.  Click the “Check for Updates” button on the About window.

5.  Click the “Yes” button when the update message is displayed.

6.  After the update process has completed, c:windowssystem32woot.txt will exist with the contents set to “nt authoritysystem“.

A quick dive into static analysis. I originally found the vulnerability using Process Monitor, but I wanted to understand what was happening behind the scenes using IDA.

Build the path using GetTempPathA() which returns c:Windowstemp. Concatenate postupdt.bat and store it in the File variable.

Append PanGPS.exe -benice to the GlobalProtect App installation path.

Write the batch script contents, close the file, and execute it via ShellExecuteA() passing c:windowstemppostupdt.bat for the lpFile parameter.

Timeline:
04/22/2020  – Vulnerability reported
05/22/2020  – Vendor confirmed the vulnerability
06/10/2020  – Vendor advisory published

Credit:
Discovered by Rich Mirch, Senior Adversarial Engineer at TEAMARES

Missing HttpOnly flags on cookies are a common finding in Web Application penetration testing. Many times, there is confusion surrounding whether it is necessary to enable this flag though. However, cookies can contain session tokens and other values that can be useful to a malicious actor and should be protected. If the cookies do not need to interact with JavaScript or other scripting languages it is best to set this flag to “true”, so a malicious actor is not able to steal the values present in the cookie.

According to OWASP (Open Web Application Security Project ), “The HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) the ability to access the cookies via the DOM document.cookie object.”[1] Even though the HttpOnly cookie flag is not new, many times it is found to be absent during penetration tests.

A cookie is used by developers to hold data, one very important piece of data is a session cookie. Session cookies represent the user and need to be protected in order to assure that a malicious actor cannot use the cookie to impersonate the user. In this situation, the HttpOnly flag should be set. Some cookies do need to interact with JavaScript based on their function, setting the HttpOnly flag, in this case, would render the cookie useless to the application.

In order to demonstrate how the HttpOnly flag works two files were created. An HTML file, welcome.html consisting of a form and a PHP file, cookieWelcome.php that echoes user input from the form and contains two cookies.

The code for welcome.html can be found below:

<html>
<body>
<form action=”cookieWelcome.php” method=”post”>
Name: <input type=”text” name=”name” size=”50″ ><br>
E-mail: <input type=”text” name=”email” size=”50″ ><br>
<input type=”submit”>
</form>
</body>
</html>

Below is the code for cookieWelcome.php:

<html>
<body><?php
setcookie(“sessionId”,”261957163849573″, time() + (86400 * 30), “/”, null, null, true);
setcookie(“Missing_HttpOnly”,”482749185763514″, time() + (86400 * 30), “/”, null, null, false);
?>Welcome <?php echo $_POST[“name”]; ?><br>
Your email address is: <?php echo $_POST[“email”];?>
</body>
</html>

In PHP, a cookie is set with the following values:

setcookie($name, $value, $expirationTime, $path, $domain, $secure, $HttpOnly);

Cookie “sessionId” has the HttpOnly flag set.

setcookie(“sessionId”,”261957163849573″, time() + (86400 * 30), “/”, null, null, true);

XSS (Cross-Site Scripting) can be used to access cookie information. There are three types of XSS, reflected, stored and DOM-based. In this example, reflected XSS where the result is returned to the user and the payload is not stored is used to demonstrate the values returned with and without the HttpOnly flag. First, test if the application is vulnerable to XSS. We need the application to run our JavaScript code in order to access the cookies associated with the application.

Use the following values as input in the form:

Name:

<script>alert(“XSS Vulnerable”)</script>

The script was successfully run in the application.

Next, we will attempt to determine which cookies are available using JavaScript. Document.cookie is used to retrieve the value of cookies.

Use the following input:

Name: Daisy
Email:

<script>alert(document.cookie)</script>

An alert box exposing the value of Missing_HttpOnly is returned. An attacker could use this cookie to impersonate a user.

<$XSS_RISK>

XSS enables an attacker to steal sensitive information like cookie values. While this example uses reflected XSS if the XSS was stored any visitor to the application could potentially have cookies, session tokens, or other private information compromised.

The browser’s developer tools can also be used to examine cookies. A checkmark is present in the HttpOnly column for sessionId, validating the use of HttpOnly. Since HttpOnly was used sessionId was not returned by the JavaScript code.

In conclusion, HttpOnly is necessary when the values contained in a sensitive cookie need to remain confidential.

References:

[1] https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

Versions Tested:
VMware Fusion 11.5.3

Products:

• https://www.vmware.com/products/fusion.html
• https://docs.vmware.com/en/VMware-Remote-Console/index.html
• https://docs.vmware.com/en/VMware-Horizon-Client/index.html

Security Advisories:

• https://www.vmware.com/security/advisories/VMSA-2020-0011.html

CVE Number(s):
CVE-2020-3957

CVSS Score:
7.3

CWE:

• CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
• CWE-424: Improper Protection of Alternate Path

NIST:
N/A

OWASP:
N/A

Summary:

VMware Fusion, VMRC and Horizon Client contain a local privilege escalation vulnerability due to a Time-of-check Time-of-use (TOCTOU) issue in the service opener.

A second local privilege escalation was discovered that is not a race condition. The application blindly executes files from an untrusted location. Both vulnerabilities result in arbitrary code execution as root. The following disclosure provides details of the second vulnerability using dynamic testing. A proof of concept exploit will be provided for both vulnerabilities.

Details:

VMware introduced a signature check in an attempt to resolve CVE-2020-3950, a local privilege escalation vulnerability in VMware Fusion prior to version 11.5.2. Jeff Ball discovered the fix was incomplete and introduced a race condition with code signature verification logic.

To illustrate the behavior when the code signature check fails, I created a hard link to the Open VMware Fusion Services binary, setting the trailing path to Contents/Library/services to mimic the expected path. A hard link is necessary to preserve the setuid bit. However, executing the binary results in a code signing error. The check verifies the signature of VMware Fusion Services prior to execution. To bypass this restriction, I created another hard link to VMware Fusion Services and executed it again. There is no longer a code signing error. This created several other opportunities for code injection because no additional signature checks were performed.

For the remainder of this blog, assume that the TOCTOU vulnerability does not exist. The goal is to elevate privileges to root. When dynamically testing a privileged binary, start by analyzing file interactions. For macOS Mojave systems, use dtruss(1m) and the Monitor utility from FireEye. For newer versions of macOS, use Crescendo to determine how the application uses files and look for interesting behavior such as the locations of files being read, written, or executed.

To initiate a simple test, create a copy or hard link of a binary and execute it from a location under your control. A hard link is necessary to preserve the setuid/setgid bits if set. macOS uses a single file system, which makes this attack practical. Important to note is that Apple has not implemented kernel restrictions on symbolic and hard links like Linux did many years ago. Some applications implicitly trust parts of the path. When the application is privileged this scenario could lead to code execution.

To begin, I usually copy and run the entire application to a location I control, and review how it interacts with files, sockets, pipes, etc. Below is an example using the Monitor utility, root executed a file named services.sh under the home directory of the low privileged test99 user. We achieved this by copying the entire /Applications/VMware Fusion.app directory and then executing the VMware Fusion from that location via the command line.

With the leading path under the control of the test99 user, I injected a single line at the top of the script to create a file in /tmp. If the update is successful, /tmp/test.123 will exist and be owned by root.

After updating services.sh, I manually executed VMware Fusion from the command line and the file was created as expected.

In some instances, privileges could be dropped by the application or bash before accessing a file. When reviewing a list of files accessed in the Monitor application, I always verify the value of Euid field. Below is an example where further investigation was needed. At first glance it appears the low privileged test99 user is executing the vmware-id binary. If a file is created when only the Euid is set to zero, the file will be owned by the low privileged user unless the application explicitly sets the ownership.

For further details, select the record to display a window with additional properties about the process. It shows the vmware-id binary was executed as the test99, under a location the test99 user controls, and the EUID is set to zero, which is the root user. This could be an opportunity to escalate privileges to root.

By default, bash will automatically drop privileges if uid != euid (effective uid). This behavior can be disabled by enabling privileged mode using the -p option. VMware uses privileged mode with several bash scripts, which is not common.  It is possible to successfully exploit a vulnerability only to have bash drop the privileges. Not all shells have this feature. For example, the Korn shell (ksh) retains the euid value.

It is important to showcase the behavior using a setuid root bash shell. As root, make a copy of /bin/bash and change the permissions to 4755. The 4000 octal number adds the setuid bit. As a low privileged user, execute the setuid root copy of bash. Notice that even though the shell is setuid root, no root privileges are gained due to the default behavior. Executing the shell with the -p option overrides the security feature and root privileges are retained(euid=0).

At this point, code execution as root has been confirmed by creating the root owned file in /tmp. The next step is to spawn an interactive root shell. For a proof of concept, creating a setuid root shell or a local netcat reverse shell is usually sufficient. Netcat was chosen for this blog to show the parent processes.

The proof of concept can be download at CVE-2020-3957.sh. The PoC will create a copy of /Applications/VMware Fusion.app using hard links, inject a netcat command into services.sh, and directly execute the application.

A local reverse shell running as root is received.

It is important to show the process tree in reverse from the netcat shell. Each ps command below displays the parent process. This shows services.sh executing as root under the test99 users home directory which contains the netcat command.

On a final note I want to thank my colleague Charles Dardaman for testing and verifying the proof of concept.

Credit:
Discovered by Rich Mirch, Senior Adversarial Engineer at TEAMARES
Signature check bypass (TOCTOU) discovered by Jeff Ball