Category: blog

It’s October bringing fall weather, pumpkin spiced lattes and a month dedicated to cybersecurity awareness.

Continue reading

This is the second installment of the Exploiting Unitrends series and will focus on several critical unauthenticated SQL Injection vulnerabilities leading to remote code execution.

Continue reading

Multiple vulnerabilities were discovered in the Unitrends Backup appliance and client software. An attacker with network access to the management interface or backup ports on the client or server could be exploited to compromise the machine. Both suffer from critical remote code execution vulnerabilities.

Continue reading

Plano, TX – November 16, 2021 — CyberOne, a trusted cybersecurity advisory and solutions leader, announced today its plans to spin off from the CRITICALSTART brand as an independent company.

Continue reading

Author: Quentin Rhoads-Herrera, Director of Professional Services

When it comes to security incidents involving malware, most of us rely on the information provided by the investigating firm to understand what the malware does, why it does it, and how to find it in our own environment. However, if you are interested in more in-depth details like us, you also want to know how to find that data for yourself.

With that in mind, Charles Dardaman, a Senior Adversarial Engineer of TEAMARES, and I have outlined the basic steps you can use to reverse engineer malware by showing you how it can be done on currently the biggest malware topic in the industry, the SolarWinds backdoor.

How It’s Done:

When looking at any form of malware, you first want to investigate its starting point, including what first landed on disk, memory, or in someone’s inbox that led to the rest of the compromise. In this case, that was the SolarWinds Orion DLL backdoor named SolarWinds.Orion.Core.BusinessLayer.DLL (b91ce2fa41029f6955bff20079468448), also called the SUNBURST Backdoor by many. For our sake, we used the excellent writeup provided by FireEye.

The first task a reverse engineer needs to do is to determine the type of binary or file they are working with. Luckily for us, the SUNBURST DLL is a .NET library so we can leverage several different tools to reverse out the contents of the .NET assembly to as close to the original source code as possible. The tool we used in this walkthrough is dotPeek from JetBrains.

When you initially load the SUNBURST DLL into the dotPeek application, it displays some basic information along with metadata, references, and classes as seen in the below screenshot.

With this now loaded, we can do a few different things; we can either export it to a Visual Studio project or just directly navigate the decompiled code through the dotPeek application.

If you wish to export for the simplicity of using grep or other command-line tools, either right-click the imported DLL or highlight it on the assembly explorer toolbar and select the icon with Visual Studio on it. This will export the whole DLL into a Visual Studio project folder and convert these different classes into .cs files.

Moving on to the backdoor discovered by FireEye and others working on the SolarWinds investigation. FireEye stated that the malware resided in the class SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer, which you should be able to find that class if you extend the SolarWinds.Orion.Core.BusinessLayer section in dotPeek.

Double-clicking the backdoor class will cause dotPeek to decompile the source as closely as possible to its original value. Keep in mind that it will not be a one-for-one translation, but you will still have enough data to continue your investigation.

If you are like us, you will want to comment in-line on any code that looks malicious, or suspicious, but dotPeek does not give you that ability, unfortunately. You can however copy all of the decompiled code and save it to a new file with the .cs extension.

With the decompiled code, it’s easy to begin to get a handle on what it is doing. To start with, we can see a large number of obfuscated strings that appear to be base64 encoded.

In order to know the value of these strings, you can jump down to the Unzip method shown below to look at the try-catch block.

As you can see, the Unzip function is converting from base64, decompressing (by deflating the data), and then encoding it into UTF-8. With this knowledge in hand, we can either write a quick script to deobfuscate this data or just throw it into CyberChef here.

The tool easily decodes the strings and you can now have a better idea of what the malicious code is attempting to do. By deobfuscating all the encoded strings inside the malware, you can already see the points called out by FireEye, including the domain that the malware phones home to.

With this extra data, you can now investigate the core functionality of the malware. In this case, we navigated to the Initialize() function which is used to start the malware by doing a number of checks and tricks in order to bypass sandboxes while not running on every machine.

To start, the malware will verify that its process name is “solarwinds.businesslayerhost” by hashing the lowercase name of the process and comparing it with the hardcoded hash. It will then only execute if the file write time was roughly two weeks prior. It does this because sandboxes have a significantly shorter runtime and the malicious code will not run inside of the sandbox. This can give people a false sense of security if they never dig any further.

The malware will then create a named pipe in order to ensure that it doesn’t run multiple instances.

After which, it will read the configuration file by the same name in the folder. As long as the number is either a 4 or 5 and not a 3, it will continue to run.

To see how that works, you can jump down to the ReadReportStatus() method and take note of which report status is being returned and how the Initiate() function is looking for the return value of Truncate or 3 in order to fail.

The malware then gets its domain name.

And creates a UserID based on the machine’s network interface, the domain name, and the GUID.

Now that we know the checks the malware will do before it runs, you can look for some other interesting functionalities. One thing that we like to look for is what kinds of jobs or commands the malware might be able to act upon.

In this sample, we can easily see what the malware is capable of by looking at the JobEngine.

From here, it’s easy to find the corresponding function and understand exactly how it works, such as jumping to ReadRegistryValue as shown below.

Understanding the malware’s capabilities is obviously very important, but we also want to discern how it communicates with the attacker’s Command and Control (C2). For this, you can look at the update function that is the main loop inside of the malware. This logic shows the malware creating a cryptoHelper object which it then uses to generate the DNS domains it reaches out to.

The UpdateNotification() below is called to validate that the malware has an Internet connection by checking if it can reach api.solarwinds.com.

While checking the Internet connection, it will call the TrackProcesses() function which contains a long list of AV/EDR tools to avoid. You can then dig further into it by brute-forcing the hashes that it compares with.

With these blocklists passed, the malware will reach out to the partially randomized domain and check-in with the C2 by starting a thread to handle the communication and job requests that the C2 responds with.

You can then follow this to the http.Initialize function that builds the JSON payload and acts on any job that might be received from the C2 server. Inside this function, we noticed a CreateUploadRequest that creates the actual JSON request sent to the server. Partway down the code where we commented, the json that it uses for the request is visible.

Even further down the http.Initalize function, you can see where the malware parses the response from the C2 server and acts on any jobs passed down to it.

While there is a lot more functionality to this malware, we hope this basic reverse engineering overview and examples can help you get started reversing the binaries. These techniques are not unique to this sample and can be used with other malware.

About the Author: 

Quentin Rhodes-Herrera, Cyber One’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. Follow him on Twitter at @paragonsec.

References and links:

• FireEye’s Discovery Release
• CyberChef Tool
• dotPeek by JetBrains

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