Intro

In an era where misinformation and identity theft pose significant threats, the security of survey platforms is crucial, particularly during pivotal global election cycles. The Checkmarx research team recently identified two Cross-site scripting (XSS) vulnerabilities on Gallup’s website. XSS is a vulnerability that might enable attackers to bypass the same origin policy, impersonate users (and perform actions on their behalf), and access their data. This vulnerability can potentially allow attackers to gain full control over an application’s functionality and data, especially if the affected user has privileged access.

The types of XSS vulnerabilities found are:

• Reflected XSS – type of cross-site scripting that occurs when an application unsafely includes data from an HTTP request directly in its response.

• DOM-based XSS – this type of cross-site scripting occurs when client-side JavaScript unsafely processes data from an untrusted source, often writing it back to the DOM, as was the case in Gallup’s systems.

This blog examines these vulnerabilities, their potential impact, and the broader implications for digital security in the field of public opinion research.

Reflected Cross Scripting – gx.gallup.com

CVSS Score: 6.5 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /kiosk.gx endpoint did not properly sanitize or encode the query string ALIAS parameter value before including it on the page.

Figure 1: Exploiting the issue to display the document’s domain

Figure 1 shows the execution of JavaScript code included in the vulnerable parameter. This endpoint doesn’t require the victim to be authenticated.

If left unaddressed and exploited by malicious actors, these vulnerabilities could lead to the execution of arbitrary code in the victims’ navigation session context. This could result in unauthorized actions being performed on their behalf. It’s important to note that this endpoint is commonly used to access Gallup surveys, which may make users more susceptible to exploitation. This could lead to unauthorized access to personally identifiable information (PII), manipulation of user preferences, and other detrimental actions.

In this proof of concept (PoC) video, we show how this vulnerability could be exploited to manipulate the victim’s shopping cart. The victim innocently visits a specially crafted URL to participate in a “work-life balance” survey. Unbeknownst to them, the malicious URL triggers the browser to load a JavaScript file from a remote location controlled by the attacker. This script leverages a JSONP endpoint (https://buy.gallup.com/store/gallup/SessionToken) to retrieve and exfiltrate Digital River API access tokens to a server controlled by the attacker. With these tokens, the attacker gains access to the victim’s PII and can add a new product to the shopping cart, illustrating the potential risks of this vulnerability.

The JSONP endpoint plays an important role in this attack scenario. The gallup-session-token cookie is required to get the access tokens. Nevertheless, it is not accessible to JavaScript (httpOnly), and the browser refuses to include it in cross-site requests. SameSite attribute is set to None, and the server has Access-Control-Allow-Origin set to *.Exploit methodology

The following URL would pop a dialog box like the one shown in Figure 1:

https://gx.gallup[.]com/kiosk.gx?ALIAS=%22);alert(document.domain)//&TYPE=q12

DOM-Based Cross-Site Scripting – my.gallup.com

CVSS Score: 5.4 Medium CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Description

The /_Portal/ApplicationAsync endpoint did not properly sanitize nor encode query string searchTerm parameter value before including it into the page.

Figure 2: Exploiting the issue to display the document’s domain

Figure 2 shows the execution of JavaScript code included in the vulnerable parameter. The vulnerable endpoint requires authentication.

Malicious actors might exploit this issue to execute arbitrary code in the victims’ navigation session context and perform actions on their behalf.

In the above PoC video, this issue is exploited to take over a victim’s account (account takeover). The victim visits a specially crafted URL that includes a payload to pull a JavaScript file from a remote location controlled by the attacker. That script is responsible for 1) rendering my.gallup.com inside an iframe, 2) automating the required workflow to change the victim’s email, and 3) pinging the attacker’s remote server with the new email address associated with the victim’s account. From here, all the attacker needs to do is recover the account password, and set a new one.

Exploit methodology

The following URL, after logging in, will pop dialog box like the one shown in Figure 2:

https://my.gallup[.]com/_Portal/ApplicationAsync?gssClientId=dduOMXW7d71AS3U _2BFMiMY8EiRX0WxJVn_2FHNUkaHb4okdayR4Pz6_2BetryXCC5aLQ2&dashbo ardWidgetId=AQICAHgcAgLcqG_2BjL48JMeAx11Kd4K4khEMoYzbmIpOoa9wRw QHwBn_2B2jOYRmEThy2bBjhebAAAAeDB2BgkqhkiG9w0BBwagaTBnAgEAMGI GCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMwOTTYIEr2OY_2B8xLiAgEQ gDW9L_2B9lkGghNQqrG7K_2BQ36lyXdiSZZEDX3JBsqfhN3ST3LlZ_2FgMDzhuz_2BrcRxStCcFpuhu5Zw_3D_3D&eCode=LEARN#/search?searchTerm=%3Cimg%20src=x%20onerror=alert(document.domain)%3E

After validation to avoid these vulnerabilities, we recommended:

• Properly encode data according to the output context it will be included before appending it to the response markup (HTML) or page DOM – Document Object Model.
• Consider adding/adjusting the Content Security Policy (CSP) to restrict locations where the browser can fetch and execute scripts.

References

• CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site
• A03:2021 – Injection, OWASP Top 10 2021
• Cross Site Scripting Prevention Cheat Sheet, OWASP Cheat Sheet Series
• Testing for Reflected Cross Site Scripting, OWASP Web Security Testing Guide
• Content Security Policy (CSP), Mozilla Developer Network Scripting’)

Timeline

• 23-June-2024 Full findings reported to Gallup’s incident response team
• 25-June-2024 Gallup confirmed receiving the report
• 11-July-2024 vulnerabilities were reviewed and found to be fixed.
  
  

The attack, discovered accidently on March 29, 2024, by a developer named Andres Freund, during performance testing, was carried out over several years by the GitHub account Jia Tan (JiaT75), who gained the trust of the long-time maintainer of the xz project and eventually replaced them as the main point of contact.

The backdoor was added in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. This backdoor allows attackers unauthorized access on systems that have the compromised versions installed.

The impact of this backdoor is significant because of xz’s use in many systems around the world, including popular Linux distributions like Red Hat and Debian.

In this blog post, we will provide a timeline of the events, look at the key people involved, and discuss what this incident means for the open-source community and the importance of maintaining the security and integrity of widely-used software libraries.

Key Findings

• xz, a widely-used compression library, was compromised with a backdoor (CVE-2024-3094) that allows forunauthorized access on systems with compromised versions (5.6.0 and 5.6.1) installed.
• The attack was carried out over several years by a user named Jia Tan (JiaT75), who gradually gained maintainer status after continuous pressure from unknown accounts on the long-time maintainer, Lasse Collin, to add a new maintainer and approve Jia Tan’s patch.
• The widespread use of xz in Linux distributions makes the impact of the backdoor significant.
• The backdoor was accidentally discovered on March 29, 2024, by the developer Andres Freund.

Gaining Reputation Over Time

The xz compression library, a widely-used tool for compressing files, found across Linux distributions, community projects, and commercial products, was compromised by a malicious actor named Jia Tan (JiaT75) who gradually and patiently gained maintainer status in order to pull off the attack, ultimately introducing a backdoor identified as CVE-2024-3094.

The attack began in 2021 when Jia Tan created their GitHub account and began using it for various activities.

In April 2022, Jia Tan submitted a patch to the xz project via a mailing list. Soon after, unknown accounts, including one named Jigar Kumar and another named Dennis Ens , began pressuring the long-time maintainer of xz, Lasse Collin, to merge the patch and add a new maintainer to the project. Lasse Collin, who had limited availability to take care for the project, eventually agreed to add Jia Tan as a maintainer. A decision that is in fact not unusual in the open-source community, where maintainers often hand off projects to others due to various reasons.

Over the next two years, Jia Tan became a regular contributor to the xz project, gaining trust within the community.

By March 2023, Jia Tan had become the primary contact for xz in Google’s oss-fuzz, a platform for finding vulnerabilities in open-source software.

Most Sophisticated Supply Chain Attack We Know

The backdoor itself was introduced in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. The malicious code allows attackers unauthorized access by infecting the SSH on systems with the compromised versions installed, making it a significant threat to users of the library.

A Discovery

The backdoor was accidentally discovered on March 29, 2024, by Andres Freund during routine performance testing. Freund noticed unusual CPU usage in the sshd process, which led him to investigate further and uncover the malicious code. This accidental discovery, the backdoor could have gone unnoticed for a longer period, effecting a large part of the open source ecosystem.

Impact

The impact of the backdoor could have had particularly severe consequences due to the widespread use of xz in compressing critical software components, including popular Linux distributions like Red Hat and Debian. Many systems worldwide rely on xz for compressing and decompressing files, making the potential reach of the backdoor extensive.

Advanced Persistent Threat

The involvement of multiple identities. The complexity of the payload, and the high level of technical expertise required, along with the patience and persistence shown in gradually gaining trust within the xz community over several years before introducing the backdoor. All these are consistent with the capabilities of nation-state actors and are qualities of advanced persistent threats (APTs). 

This incident is part of a growing and alarming trend of advanced persistent threats (APTs) targeting critical open-source projects.

Conclusion

The xz compromise highlights the urgent need for the open-source community to improve its security practices and tools to prevent similar attacks in the future. Collaboration, transparency, and shared responsibility are essential to detecting and mitigating advanced persistent threats (APTs) targeting critical open-source projects. 

We, the community must develop more effective strategies, to strengthen the security of open-source software. By learning from this incident and taking proactive measures, the open-source community can build a more resilient and trustworthy ecosystem, ensuring the long-term success and integrity of open-source projects in the face of ever-evolving cybersecurity threats.

Working together to keep the opensource ecosystem safe.

The research team of Checkmarx simultaneously investigated a campaign of multiple malicious packages appear to be related to the same threat actors.

The threat actors target victims with Typosquatting attack technique using their CLI to install Python packages. 

This is a multi-stage attack and the malicious payload aimed to steal crypto wallets, sensitive data from browsers (cookies, extensions data, etc..) and various credentials.

In addition, the malicious payload employed a persistence mechanism to survive reboots.

PyPi Suspended User and Project Creation

A few hours ago, on Mar 28, 2024 – 02:16 UTC, The Python Package Index (PyPi) added a new website banner and released an official update: “We have temporarily suspended new project creation and new user registration to mitigate an ongoing malware upload campaign”

Evidence of Multiple Malicious Typosquatting Packages

Between March 27 and March 28, 2024, multiple malicious Python packages were uploaded on the Python Package Index (PyPI). These packages most likely created using automation 

The Malicious Payload

The malicious code is located within each package’s setup.py file, enabling automatic execution upon installation.

employed a technique where the setup.py file contained obfuscated code that was encrypted using the Fernet encryption module. When the package was installed, the obfuscated code was automatically executed, triggering the malicious payload.

Upon execution, the malicious code within the setup.py file attempted to retrieve an additional payload from a remote server. The URL for the payload was dynamically constructed by appending the package name as a query parameter. 

The retrieved payload was also encrypted using the Fernet module, Once decrypted, the payload revealed an extensive info-stealer designed to harvest sensitive information from the victim’s machine.

The malicious payload also employed a persistence mechanism to ensure it remained active on the compromised system even after the initial execution.

A small piece of the larger script

Summary

The discovery of these malicious Python packages on PyPI highlights the ongoing nature of cybersecurity threats within the software development ecosystem.

This incident is not an isolated case, and similar attacks targeting package repositories and software supply chains are likely to continue.

As this situation unfolds, we will provide updates on any new developments.

Working together to keep the open source ecosystem safe.

Package List

IOCs

• hxxps://funcaptcha[.]ru/paste2
• hxxps://funcaptcha].[ru/delivery
• hxxps://funcaptcha.ru/atomic/app.asar
• ABE19B0964DAF24CD82C6DB59212FD7A61C4C8335DD4A32B8E55C7C05C17220D      

0C1DDD33E630F4AC684880F0E673DFA84919272494C11DA0F1EC05FB4F919CE8

Key Points

1. An attacker distributed a malicious dependency hosted on a fake Python infrastructure by linking it to popular projects on GitHub and legitimate Python packages.
2. The malicious dependency, masquerading as the popular “colorama” package, contained hidden malware designed to steal sensitive data from infected systems.
3. The attacker hijacked GitHub accounts, including one belonging to a top.gg contributor, using it to make malicious commits and spread the malware to a community of over 170K members.
4. Employing a multi-stage execution process, the malware fetches and executes obfuscated code from multiple external sources, using techniques like encryption, encoding, compression, and misleading characters to evade detection.
5. Targeting a wide array of applications, such as web browsers, social media platforms, email services, and messaging apps, the malware harvests sensitive information, including login credentials, session tokens, and personal data.
6. Stolen data is exfiltrated to the attacker’s server, and persistence is established through Windows registry modifications.

Weird Message, Got Hacked

“I was using my laptop today, just the regular messing around with python and other stuff on my command line, until I seen a weird message on my command line saying that there’s something wrong with colorama on python, I didn’t care much cause I’m used to this stuff so I just skipped it, Few minutes later I got the same error message but in a different script I’m using. The moment I seen this I knew what’s going on, I got hacked.”

This chilling account comes from a recent blog post by Mohammed Dief, a Python developer who fell victim to a sophisticated malware attack while cloning the repository “maleduque/Valorant-Checker”.

Mohammed’s story is just one example of the far-reaching impact of this malware campaign. The attacker behind the campaign employed a devious strategy to spread the malware through malicious GitHub repositories.

Fake Python Mirror

The attack infrastructure included a website that appeared to be a Python package mirror and was registered under the domain “files[.]pypihosted[.]org”.

This domain selection is a clever typosquat of the official Python mirror “files.pythonhosted.org,” as the latter is where the official artifact files of PyPi packages are typically stored.

In the attacker’s footprints, we saw they utilized a feature in pip (package manager for Python) where you can specify a URL to grab your package dependency and use their fake Python mirror to download packages.

Requirement.txt file, Fake mirror URL vs legitimate URL

Fake Mirror Is Hosting a Poisoned “colorama”

The threat actors used Colorama,  and added malicious code inside, then hosted the poisoned Colorama package on their typosquatted domain; the attacker was able to use the exact same name as the popular “Colorama” package without raising immediate suspicion. This tactic makes it significantly harder for users to detect the malicious nature of the package, as it appears to be a legitimate dependency at first glance.

To further conceal their malicious intent, the attacker employed a strategic approach when committing changes to many of the malicious repositories. They would simultaneously commit multiple files, including the requirements file containing the malicious link, along with other legitimate files. This calculated move aimed to minimize the chances of detection, as the malicious link would blend in with the legitimate dependencies, reducing the likelihood of users spotting the anomaly during a cursory review of the committed changes.

Example of the attacker hiding Fake mirror URL within a commit of multiple files.

Hijacked GitHub Account

The attacker’s reach extended beyond creating malicious repositories through their own accounts. They managed to hijack the GitHub account of a user named “editor-syntax,” who is a member of the company top-gg and a contributor to one of their repositories. With control over this trusted account, the attacker carried out a series of malicious activities:

Starring Malicious Repositories: The compromised account was used to star multiple malicious GitHub repositories created by a user named LoffyNora. This activity aimed to increase the visibility and credibility of the malicious repositories.

Malicious Commit to top-gg Repository: The attacker made a malicious commit to a repository belonging to top-gg, exploiting the trust and privileges associated with the compromised account of “editor-syntax.”

Spreading the Malware: Through the compromised account, the attacker likely spread the malware to unsuspecting users who trusted the reputation of “editor-syntax” and the top-gg organization.

Account Takeover via Stolen Cookies

The GitHub account of “editor-syntax” was likely hijacked through stolen cookies. The attacker gained access to the account’s session cookies, allowing them to bypass authentication and perform malicious activities using the GitHub UI. This method of account takeover is particularly concerning, as it does not require the attacker to know the account’s password.

“Bro What”

The incident caused alarm within the top-gg community (which boasts over 170K members), as users alerted “editor-syntax” on discord about the suspicious activities originating from their account. “editor-syntax” was quite shocked, to say the least, as he realized what had occurred through his GitHub account. It became evident that the malware had compromised multiple individuals, highlighting the scale and impact of the attack.

Interestingly, the attacker’s Typosquatting technique was so convincing that even a user on GitHub fell victim to it without realizing they were under attack. When the malicious domain, piphosted[.]org”, went down, the user opened an issue on one of the malicious repositories, complaining about it, not realizing it had been a host for malicious payloads.

Deep Dive into the Malicious Python Package

In addition to spreading the malware through malicious GitHub repositories, the attacker also utilized a malicious Python package called “yocolor” to further distribute the “colorama” package containing the malware. They employed the same typosquatting technique, hosting the malicious package on the domain “files[.]pypihosted[.]org” and using an identical name to the legitimate “colorama” package.

By manipulating the package installation process and exploiting the trust users place in the Python package ecosystem, the attacker ensured that the malicious “colorama” package would be installed whenever the malicious dependency was specified in the project’s requirements. This tactic allowed the attacker to bypass suspicions and infiltrate the systems of unsuspecting developers who relied on the integrity of the Python packaging system.

Stage 1

The first stage is where the unsuspected user downloads the malicious repo or package which contians the malicious dependency – “colorama” from the typosquatted domain, “files[.]pypihosted.org”.

Example of how the malicious code looks like within the ycolor package

Stage 2

The malicious “colorama” package contains code that is identical to the legitimate package, with the exception of a short snippet of additional malicious code. Initially, this code was located within the file “colorama/tests/__init__.py”, but the attacker later moved it to “colorama/init.py”, likely to ensure that the malicious code is executed more reliably. This code sets the stage for the subsequent phases of the attack.

The attacker employed a clever technique to hide the malicious payload within the code. They used a significant amount of whitespace to push the malicious code off-screen, requiring someone inspecting the package to scroll horizontally for an extended period before discovering the hidden malicious content. This technique aimed to make the malicious code less noticeable during a quick review of the package’s source files.

This code fetches and executes another piece of Python code from “hxxps[:]//pypihosted[.]org/version,” which installs necessary libraries and decrypts hard-coded data using the “fernet” library. The decrypted code then searches for a valid Python interpreter and executes yet another obfuscated code snippet saved in a temporary file.

Stage 3

The malware progresses further, fetching additional obfuscated Python code from another external link: hxxp[:]//162[.]248[.]100[.]217/inj, and executes it using “exec”.

Stage 4

Upon analysis, it’s clear that the attacker has put thought into obfuscating their code. Techniques such as the use of Chinese and Japanese character strings, zlib compression, and misleading variable names are just a few of the techniques employed to complicate the code’s analysis and comprehension.

The simplified code checks the compromised host’s operating system and selects a random folder and file name to host the final malicious Python code, which is retrieved from “hxxp[:]//162[.]248[.]100.217[:]80/grb.”

A persistence mechanism is also employed by the malware by modifying the Windows registry to create a new run key, which ensures that the malicious Python code is executed every time the system is rebooted. This allows the malware to maintain its presence on the compromised system even after a restart.

Stage 5 – No One Is Left Behind

The final stage of the malware, retrieved from the remote server, reveals the true extent of its data-stealing capabilities. It targets a wide range of popular software applications and steals sensitive information, some of which include:

Browser Data: The malware targets a wide range of web browsers, including Opera, Chrome, Brave, Vivaldi, Yandex, and Edge. It searches for specific directories associated with each

browser and attempts to steal sensitive data such as cookies, autofill information, browsing history, bookmarks, credit cards, and login credentials.

Discord Data: The code specifically targets Discord by searching for Discord-related directories and files. It attempts to locate and decrypt Discord tokens, which can be used to gain unauthorized access to the victim’s Discord account.

Cryptocurrency Wallets: The malware includes a list of cryptocurrency wallets that it aims to steal from the victim’s system. It searches for specific directories associated with each wallet and attempts to steal wallet-related files. The stolen wallet data is then compressed into ZIP files and uploaded to the attacker’s server.

Telegram Sessions: The malware also attempts to steal Telegram session data. It searches for Telegram-related directories and files, aiming to capture the victim’s session information. With access to Telegram sessions, the attacker could potentially gain unauthorized access to the victim’s Telegram account and communications.

Computer Files: The malware includes a file stealer component that searches for files with specific keywords in their names or extensions. It targets directories such as Desktop, Downloads, Documents, and Recent Files.

Instagram data: The malware attempts to steal sensitive information from the victim’s Instagram profile by leveraging the Instagram session token. The malware sends requests to the Instagram API using the stolen session token to retrieve various account details.

Further analysis of the final payload reveals that the malware also includes a keylogging component. It captures the victim’s keystrokes and saves them to a file, which is then uploaded to the attacker’s server. This capability allows the attacker to monitor and record the victim’s typed input, potentially exposing sensitive information such as passwords, personal messages, and financial details.

The stolen data is exfiltrated to the attacker’s server using various techniques. The code includes functions to upload files to anonymous file-sharing services like GoFile and Anonfiles. It also sends the stolen information to the attacker’s server using HTTP requests, along with unique identifiers like hardware ID or IP address to track the victim.

Conclusion

This campaign is a prime example of the sophisticated tactics employed by malicious actors to distribute malware through trusted platforms like PyPI and GitHub.

This incident highlights the importance of vigilance when installing packages and repositories even from trusted sources. It is crucial to thoroughly vet dependencies, monitor for suspicious network activity, and maintain robust security practices to mitigate the risk of falling victim to such attacks.

As the cybersecurity community continues to uncover and analyze these threats, collaboration and information sharing remain essential in the ongoing battle against malicious actors in the software supply chain.

We reported the abused domains to Cloudflare, and they have since been taken down.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

Working together to keep the open source ecosystem safe.

Timeline

1. Nov 2022: Pypi User “felpes” added three packages to the Python Package Index (PyPI) that contained various forms of malicious code.
2. Feb 01, 2024: The domain pypihosted[.]org was registered by the attacker.
3. Mar 04, 2024: The GitHub account of a top.gg contributor was compromised, and the attacker used it to commit malicious code to the organization’s repository.
4. Mar 13, 2024: The attacker registered the domain pythanhosted.org, further expanding their typosquatting infrastructure.
5. Mar 05, 2024: The malicious package “yocolor” was published on PyPI, acting as a delivery mechanism for the malware.

List of Packages

IOC

• hxxps[:]//files[.]pythanhosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.5.tar.gz
• hxxps[:]//files[.]pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz
• hxxps://files[.]pypihosted[.]org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.3.tar.gz
• 162[.]248.101.215
• pypihosted.org/version
• 162[.]248.100.217
• 162.248.100.117
• 0C1873196DBD88280F4D5CF409B7B53674B3ED85F8A1A28ECE9CAF2F98A71207
• 35AC61C83B85F6DDCF8EC8747F44400399CE3A9986D355834B68630270E669FB
• C53B93BE72E700F7E0C8D5333ACD68F9DC5505FB5B71773CA9A8668B98A17BA8

Impact Summary

Successful exploitation of the discovered XSS vulnerability could have allowed attackers to hijack the sessions of admins and takeover the accounts of helpdesk agents. This would give the attackers the same privileges as admins and agents in terms of what they can execute, or the information they are exposed to. In certain cases, attackers would have been able to reset the helpdesk, wiping all system data.

Part 1: Administrator Session Hijacking

CVSS Score: 8.8 (High) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
This issue was found in Deskpro version 2020.2.9, running in a docker container using the official Deskpro docker image. Nevertheless, the underlying problem – a stored XSS vulnerability – also affects the cloud version.

Description

Malicious users can execute arbitrary code in the victim’s browser context to exfiltrate the session token. With this token at hand, malicious users would be able to hijack victims’ sessions and execute actions on their behalf.
The Deskpro solution tracks users’ activities, issuing requests like the one in Figure 1 to the /portal/api/auth/session endpoint: no authentication nor authorization is required.

Figure 1: User tracking request/response
As shown in Figure 1, the request payload includes several details about visited pages such as their URL (url), title (pageTitle), the page from where the user came from (referrer), etc.
This data is used to compute some statistics made available to administrators through the “Ticket Insights” built-in dashboard, as shown in Figure 2.

Figure 2: “Ticket Insights” built-in dashboard
Arbitrary code can be included in the request pageTitle property of the meta object. An example is shown below.

This data is stored in the Deskpro database and is loaded whenever the “Top KB Views” widget is rendered. In such a situation, the code is executed in the browser’s context, and a modal box is shown. Figure 3 illustrates this scenario for the administrator account.

Figure 3: Payload code execution in the admin’s browser context
Although Deskpro includes a Content Security Policy (CSP), it does not prevent inline scripts execution.
Attackers may take advantage of this issue to craft malicious requests, including source code, to exfiltrate the admin’s session token to a server controlled by them. Although the session cookie has the httpOnly flag, its value is also available via JavaScript, accessing the DESKPRO_SESSION_CODE global variable hardcoded in the DOM.
The script below does exactly what was described above, and it was used in our proof-of-concept.

With the admin’s session code, attackers would be able to place it in their own browser, getting access to the admin’s session. It would allow them to execute actions on the admin’s behalf. Note that admin accounts have access to the whole system, being able to access customers’ and other agents’ data (tickets, CRM, etc.) and the system configuration (e.g., SMTP server credentials). In some cases, attackers would be able to reset the helpdesk, wiping all system data.
The underlying stored XSS issue also affects Deskpro Cloud. Figure 4 shows the unauthenticated request to the /portal/api/auth/session endpoint on a trial Deskpro Cloud instance.

Figure 4: Deskpro Cloud request with the XSS payload
Figure 5 shows the XSS payload reflected on the admin’s built-in “Ticket Insights” dashboard.

Figure 5: XSS payload reflected on Deskpro Cloud admin’s dashboard

Part 2: Agent Account Takeover

CVSS Score: 8.1 (High) CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
This issue was found in Deskpro 2020.2.9, running in a docker container using the official Deskpro docker image. Nevertheless, the underlying problem – a stored XSS vulnerability – also affects the cloud version.

Description

Malicious users can execute arbitrary code in the victim’s browser context, allowing them to take over a victim’s account.
As described previously in the Administrator Session Hijacking section, the Deskpro solution tracks users’ activities, which can be displayed in built-in or custom dashboards such as the “Ticket Insights” built-in dashboard.
Agents can be granted access to dashboards, such as the “Ticket Insights” built-in one.
As for the administrators session hijacking attack, attackers may take advantage of the same vulnerability to include a specially crafted payload in the meta object’s pageTitle property.
The request payload above includes a script that is stored in the Deskpro database. When the agent opens a dashboard that includes the “Top KB views” widget (e.g., the build-in “Ticket Insights” dashboard), then the script is executed. The script is shown below for better readability.

Once executed, the malicious script adds a secondary email address to the agent’s (victim’s) account, behind the scenes and without notice. The required request token (_rt) can be gathered from the DP_REQUEST_TOKEN global variable hardcoded in the DOM. Figure 1 shows the account settings with the secondary email address added by the malicious script.

Figure 1: Account settings after malicious script execution
Then, to take over the agent’s account, the attacker goes to Deskpro agents Log In page (/agent/login?return=/agent/) to trigger the password recovery, providing his own email address included in the malicious payload (attacker@somehost.com).
The attacker would receive an email in his inbox with a link to reset the password. After doing that, the attacker would be able to access the agent’s account and execute actions on his behalf.
The attacker should remove the original agent email address to complete the account takeover, making his address the primary address. By doing this, the legitimate agent wouldn’t be able to recover control over the account.
Note that the underlying issue also affects Deskpro Cloud, as previously shown in Figures 4 and 5.

Recommendations

To avoid XSS issues, applications should perform proper data encoding / escaping according to the output context, e.g. before merging it with markup templates or appending it to the Document Object Model (DOM).
Although there was a CSP, which could have helped with mitigating the XSS, inline scripts were allowed. When using inline scripts can’t be avoided, cryptographic nonces should be used to create an allow-list of specific inline scripts.
Users should always be asked to re-authenticate when performing sensitive actions like, in this case, changing email addresses associated with an account. Moreover, the account owner should be notified about such changes, in real time, so that it can act in a timely fashion in case of suspicious activity.

References

• A7:2017-Cross-Site Scripting (XSS) – OWASP TOP Ten 2017
• C4: Encode and Escape Data – OWASP Top Ten Proactive Controls 2018
• Testing for Stored Cross-Site Scripting – OWASP Testing Guide
• Require Re-authentication for Sensitive Features – OWASP Authentication CheatSheet
• Content-Security-Policy – MDN Web Docs

Summary of Disclosure and Events

After discovering and validating the vulnerability, we notified Deskpro of our findings and worked with them throughout the remediation process until they informed us everything was appropriately patched. Deskpro’s responsiveness and professionalism throughout the process is worth noting and quite admirable.

Timeline of Disclosure

• October 31, 2020 – Checkmarx shared the full report with security@deskpro.com
• November 2, 2020 – Deskpro confirmed receipt of report and began fixing the issues
• November 9, 2020 – Deskpro confirmed the issues were fixed; requested 90-day wait for public disclosure
• February 11, 2021 – Public disclosure

Final Words

Despite being very old and well-documented, XSS vulnerabilities continue to be one of the most overlooked and serious issues. Application security testing solutions are key for detecting XSS vulnerabilities and are a critical component in enabling developers to build, deploy, and maintain secure software. To learn how to mitigate these types of issues, visit our CxCodebashing lesson here.
Vulnerabilities like the one discovered here are why the Checkmarx Security Research Team performs its investigations. This type of activity is part of our ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.

• prevent nodes with a duplicate hostname or –hostname-override value to join the cluster
• add a prefix/suffix to the etcd key name

Later, the Pull Request 81056 was created to address the vulnerability, following our first recommendation described above. The issue was fixed by rejecting a node joining the cluster if a node with the same name already exists #1711.
Discovering vulnerabilities like the one mentioned in this blog is why the Checkmarx Security Research team performs investigations. This type of research activity is part of our ongoing efforts to improve security for organizations worldwide.

At the time Solidity was proposed, it had significant differences to other languages also targeting the EVM (e.g., Serpent, LLL, Viper, and Mutan) such as mappings, structs, inheritance, and even a natural language specification NatSpec.
Like other programming languages targeting a Virtual Machine (VM), Solidity is compiled into bytecode using a compiler: solc.

Smart Contracts can be seen as a computer protocol intended to complete some task according to the contract rules. In the cryptocurrencies context, smart contracts enforce transactions’ traceability and irreversibility, avoiding the need of a third-party regulator like banks. This concept was suggested by Nick Szabo back in 1994.

This article is an introduction to Solidity from a security standpoint, created by the Checkmarx Security Research Team.
As more and more people/organizations look to blockchain as a promising technology, and being willing to build on top of it, it is mandatory to apply software development best practices such as code review, testing, and auditing while creating smart contracts. These practices become even more critical as smart contracts execution happens in public with source code generally available.

It is hard to ensure that software can’t be used in a way that was not anticipated, so it is essential to be aware of the most common issues as well as the exploitability of the environment where the smart contract runs on. An exploit may not target the smart contract itself, but the compiler or the virtual machine (e.g., EVM) instead.
We cover that in the next sections, providing a Proof-of-Concept that demonstrates the discussed topics.

Preamble

In the context of Ethereum (abbreviated Eth), Smart Contracts are scripts that can handle money. These contracts are enforced and certified by Miners (multiple computers) who are responsible for adding a transaction (execution of a Smart Contract or payment of cryptocurrency) to a public ledger (a block). Multiple blocks are called blockchain.
Miners spend “Gas” to do their work (e.g., publish a smart contract, run a smart contract function, or transfer money between accounts). This “Gas” is paid using Eth.

Common Issues

Privacy

In Solidity, private may be far from what you may expect, mainly if you’re used to Object-Oriented Programming using languages like Java.
A private variable doesn’t mean that someone can’t read its content, it just means that it can be accessed only from within the contract. You should remember that the blockchain is stored on many computers, making it possible for others to see what’s stored in such “private” variables.
Note that private functions are not inherited by other contracts. To enable private functions inheritance, Solidity offers the internal keyword.

pure/view functions

Preventing functions from reading the state at the level of the EVM is not possible, but it is possible to prevent them from writing to the state ( i.e., view can be enforced at the EVM level, while pure cannot).
The compiler started enforcing that pure is not reading the state in version 0.4.17.
Source

Reentrancy

Reentrancy is a well-known computing concept, and also the cause of a $70M hack back in June 2016 called the DAO (Decentralized Autonomous Organization) Attack. David Siegel authored “Understanding The DAO Hack for Journalists” a complete events timeline and comprehensive explanation of what happened.
“In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely be called again (“re-entered”) before its previous invocations complete execution.” (Wikipedia).
By using a common computing pattern, it was possible to exploit a Smart Contract. It is still possible. The call() function is the heart of this attack, and it is worth noting that it:

• is used to invoke a function in the same contract (or of another contract) to transfer data or Ethereum;
• does not throw, it just returns true/false;
• triggers the execution of code and spends all the available Gas for this purpose; there’s no Gas limit unless we specify one;

The following warning message was taken from Solidity’s documentation:
“Any interaction with another contract imposes a potential danger, especially if the source code of the contract is not known in advance. The current contract hands over control to the called contract and that may potentially do just about anything. Even if the called contract inherits from a known parent contract, the inheriting contract is only required to have a correct interface. The implementation of the contract, however, can be completely arbitrary and thus, pose a danger. In addition, be prepared in case it calls into other contracts of your system or even back into the calling contract before the first call returns. This means that the called contract can change state variables of the calling contract via its functions. Write your functions in a way that, for example, calls to external functions happen after any changes to state variables in your contract so your contract is not vulnerable to a reentrancy exploit.”
The highlighted part in bold text above is exactly how a Smart Contract can be exploited due to Reentrancy. In the Proof-of-Concept section below and in the accompanying video, there’s a ready to run example. To avoid this attack:

• “be prepared” – any function running external code is a threat;
• These functions:
  <address>.transfer(uint256 amount)/ <address>.send(uint256 amount) return (bool)
  are safe against Reentrancy as they currently have a limit of 2300 Gas;
• if you cannot avoid using call(), update the internal state before making an external call.

Overflow

Solidity data types are cumbersome because of the 256 bits Virtual Machine (EVM). The language does not offer a floating point representation and data types shorter than 32 bytes are packed together into the same 32 bytes slot. The literal 0 type-infers to byte, not an int as we might expect.
Being limited to 256 bits, overflow and underflow are something we may expect. It can happen with a uint8 whose max value is 255 (2ˆ8-1 or 11111111)

OverflowUint8.sol source code or with a uint256 whose max value is 1.157920892×10 (2ˆ256-1)

OverflowUint256.sol source code
Although uint256 is suggested to be (more) secure as it is unlikely to overflow, it has the same problem than any other data type. The batchOverflow bu (CVE-2018–10299) is a great example of a uint256 overflow.

Proof-of-Concept

Consider the following Bank Smart Contract which keeps tracking of balances for addresses that put ether on it.

A careful look at the withdraw() function reveals the reentrancy pattern highlighted in the above correspondent Common Issues > Reentrancy section external call before internal state update.
Now we need a malicious crafted Smart Contract to exploit the Bank one: Thief

Let’s rehearse the robbery using a Solidity development environment. To run it we’ll just need a docker enabled environment.
Clone the solidity-ddenv project and move inside the solidity-ddenv folder
$ git clone https://github.com/Checkmarx/solidity-ddenv && cd solidity-ddenv
Let’s start the development environment
$ ./ddenv
Creating network “solidityddenv_default” with the default driver
Creating ganache … done
Creating truffle … done
If ddenv started correctly you’re expected to be inside workspace folder (you can check it running pwd).
Let’s move into reentrancy directory where the Bank and Thief Smart Contracts are located
$ cd reentrancy
Now, it’s time to compile the source code
$ ddenv truffle compile
Starting ganache … done
Compiling ./contracts/Bank.sol…
Compiling ./contracts/Migrations.sol…
Compiling ./contracts/Thief.sol… Writing artifacts to ./build/contracts
and deploy the Smart Contracts to our development network:

We are now ready to perpetrate the attack. Let’s spawn a console to our development network so that we can issue a few commands
$ ddenv truffle console –network development
Starting ganache … done
truffle(development)>
truffle(development) > is the prompt. If you want to run the attack yourself, just copy the commands next to the prompt from the scripts below and paste them into the console prompt you have launched before.
Now, let’s


Discovering vulnerabilities like the one mentioned above is why the Checkmarx Security Research team performs investigations. This type of research activity is part of their ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.