Bitcoin Forum
December 09, 2021, 08:23:07 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 »  All
  Print  
Author Topic: Wasabi Vulnerablilities - Drama or real.  (Read 454 times)
Royse777
Legendary
*
Offline Offline

Activity: 1596
Merit: 2027


Powerful promotion strategy https://bit.ly/3cRVjFi


View Profile WWW
August 20, 2020, 12:46:23 PM
Merited by hugeblack (1)
 #1

https://cryptonews.com/news/alleged-wasabi-wallet-vulnerabilities-denied-by-developer-7483.htm

I am not a technical guy, so I do not understand some terms that talked in the article from OXT Research.

Quote
“vulnerabilities break a core assumption of mixing, with each remix effectively cancelling out the privacy gains of the previous mix,” and OXT Research believes that they “have been present in the Wasabi Wallet code base for a long time, thus it is likely someone less than ethical has already discovered [them] and is exploiting” them.

However, zkSNACKs is denying the claim and from their statement it seems this is some business interest.  
Quote
“They claimed Wasabi is broken because of the lack of randomness in coin selection for CoinJoins. More specifically, they tried to show that if an adversary knows all the UTXOs in a wallet, then it can tell which coin will be mixed next time. This is pointless as the only entity who knows the UTXOs in a wallet is the user itself,” said Ficsor. “Then they moved onto building more and more on this false premise, repeating their conclusion over and over again, and that's the rest of the technical part of the letter.”

I use Wasabi coinJoin sometimes. Now not sure what to take from this article. Anyway with good technical knowledge can enlighten a bit?

Thanks in advance.

Cheers,

.
.Duelbits.
            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
.
        ▄ ▄▄▀▀▀▀▄▄
        ▄▀▀▄      █
        █   ▀▄     █
      ▄█▄     ▀▄   █
     ▄▀ ▀▄      ▀█▀
   ▄▀     ▀█▄▄▄▀▀ ▀
 ▄▀  ▄▀  ▄▀
▀▄    ▄▀▀
Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█
█  █    █    █  █  █ █
Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █
█     ▀▄▀     █   ▀▀  █
Blackjack
.
▄▄▀█████▀▄▄
▄▀▀   █████ ▄▄▀▀▄
███▄  ▄█████▄▀▀▄███
██████▀▀     ▀▀██████
█ ▀▀██▀ ▀▄   ▄▀ ▀██▀▀ █
█    █    ███    █    █
█ ▄▄██▄ ▄▀   ▀▄ ▄██▄▄ █
██████▄▄     ▄▄██████
Roulette
.
█▀▀▀▄             ▄▀▀▀█
█ ▀▄ ▀▄         ▄▀ ▄▀ █
▀▄ ▀▄ ▀▄     ▄▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄  ▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄ ▀ ▄▀
▄ ▀▄ ▀▄ ▀▄  ▄
█ ▀▄ ▀▄ ▀  ▄▀ █
▄▀▄ ▀▄ ▀ ▄▀ ▄▀▄
Dice Duels
1639038187
Hero Member
*
Offline Offline

Posts: 1639038187

View Profile Personal Message (Offline)

Ignore
1639038187
Reply with quote  #2

1639038187
Report to moderator
1639038187
Hero Member
*
Offline Offline

Posts: 1639038187

View Profile Personal Message (Offline)

Ignore
1639038187
Reply with quote  #2

1639038187
Report to moderator
1639038187
Hero Member
*
Offline Offline

Posts: 1639038187

View Profile Personal Message (Offline)

Ignore
1639038187
Reply with quote  #2

1639038187
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1639038187
Hero Member
*
Offline Offline

Posts: 1639038187

View Profile Personal Message (Offline)

Ignore
1639038187
Reply with quote  #2

1639038187
Report to moderator
bob123
Legendary
*
Offline Offline

Activity: 1610
Merit: 2428



View Profile WWW
August 20, 2020, 04:36:33 PM
 #2

Ok, so i read the article and the statement from samourai.

The two reasons why the vulnerability is critical (according to samourai) are:

When a mixed output is remixed, these vulnerabilities break the ZeroLink guarantee for the previous mix, cancelling its benefits.
and
These vulnerabilities break a core assumption of mixing, with each remix effectively canceling out the privacy gains of the previous mix.

If this is based on the assumption that the attacker has to know every UTXO in the wallet, there is no privacy to begin with.
Further, they only reference on multiple mixing events. So the coinjoin itself is not "vulnerable", they claim that multiple coinjoins have the same effect than one coinjoin.

To me, this seems just like the regular war between samourai and wasabi.
The privacy is not broken, the coinjoins are not useless.

Assuming that every UTXO of a user is known before coinjoining and also assuming that all UTXO's are enqued into a coinjoin is a pretty strong assumption to say at least.
And even then, it is not like there is a vulnerability which de-anonymizes people.

o_e_l_e_o
Legendary
*
Offline Offline

Activity: 1498
Merit: 7986


Wear a mask, slow the spread


View Profile
August 20, 2020, 06:40:05 PM
 #3

It's impossible to tell until the full details of the alleged vulnerability are released publicly. According to the medium post linked above, that will in no more than 48 hours from when that post was made, which was around 12 hours ago from now. So check back in the next day or two and we should know for sure.

dkbit98
Legendary
*
Offline Offline

Activity: 1344
Merit: 2881


Powerful promotion strategy https://bit.ly/3cRVjFi


View Profile WWW
August 20, 2020, 10:33:54 PM
 #4

This seems like Samourai vs Wasabi war indeed, and I don't take anyone side here, even if I prefer Samourai and I think it is a bit superior.
Interesting news, and I will follow what happens in next few days.
This is what they tweeted few hours ago:
https://twitter.com/SamouraiWallet/status/1296480000963641346
Salty :/

LeGaulois
Copper Member
Legendary
*
Offline Offline

Activity: 2002
Merit: 2537

Bitcoin Ninja Unregulated Banker Unbanking Folks


View Profile
August 20, 2020, 11:06:43 PM
 #5

I believe they aren't the first to find these supposed vulnerabilities. Guess who's first and already working on it Roll Eyes

Europol-Wasabi-Wallet-Report.pdf

By the way this is only related to privacy but this isn't the first time OXT claims to deanonymize Wasabi without disclosure. Let's see now if they have the testicles big enough

hulla
Hero Member
*****
Offline Offline

Activity: 1806
Merit: 565



View Profile
August 20, 2020, 11:27:25 PM
 #6

Firstly, the OXT researcher was right when they said if the UTXO in a wallet knows it will be easy to know the next transaction that will be mix because UTXO is reliable for the start and end of each transaction but since the Wasabi wallet vulnerabilities were said by a competitor it hard to believe if this was actually the truth or a drama. However, using wasabi or samourai wallet alone as anonymity is concern was never an advisable idea from the first place but wasabi wallet was too strong for Chainanalysis and Europol why OXT?


.
.Duelbits.
            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀
 ▀▄    ▄▀▀
Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█
█  █    █    █  █  █ █
Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █
█     ▀▄▀     █   ▀▀  █
Blackjack
.
▄▄▀█████▀▄▄
▄▀▀   █████ ▄▄▀▀▄
███▄  ▄█████▄▀▀▄███
██████▀▀     ▀▀██████
█ ▀▀██▀ ▀▄   ▄▀ ▀██▀▀ █
█    █    ███    █    █
█ ▄▄██▄ ▄▀   ▀▄ ▄██▄▄ █
██████▄▄     ▄▄██████
Roulette
.
█▀▀▀▄             ▄▀▀▀█
█ ▀▄ ▀▄         ▄▀ ▄▀ █
▀▄ ▀▄ ▀▄     ▄▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄  ▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄ ▀ ▄▀
▄ ▀▄ ▀▄ ▀▄  ▄
█ ▀▄ ▀▄ ▀  ▄▀ █
▄▀▄ ▀▄ ▀ ▄▀ ▄▀▄
Dice Duels
posi
Hero Member
*****
Offline Offline

Activity: 1624
Merit: 554

God will make a way ↕️


View Profile
August 21, 2020, 03:44:43 AM
 #7

According to the research I did about the OXT research, I'm afraid they seem to be telling the truth about Wasabi's wallet vulnerabilities because they were able to track down the year 2015 hacker that stole 455BTC despite the hackers used Joinmarker mixer.


For adequate information, guys visit the UTO site and download the PDF file of their investigation report.

Last of the V8s
Legendary
*
Offline Offline

Activity: 1652
Merit: 4390


Be a bank


View Profile
August 21, 2020, 07:09:52 AM
Last edit: August 21, 2020, 12:07:02 PM by Last of the V8s
Merited by bob123 (3), ETFbitcoin (2), hugeblack (2), malevolent (1)
 #8

Trust Samourai and their childish shills to blow this out of proportion.

Here's the vuln https://pastebin.com/4tDh3ueW

Code:
Summary
-------
 
This report is intended as a disclosure of 2 vulnerabilities found in Wasabi Wallet. We suspect that these vulnerabilites have existed for a long time (since the inception of Wasabi?) and we think they're serious enough to deserve a proper responsible disclosure.
 
 
Context of these findings
-------------------------
 
In late July, we were working on an analysis of bitcoin flows related to the Twitter hack. This study was done in the context of our work for OXT Research.
 
As it was reported by multiple articles, a part of these funds has entered the Wasabi mixer. That led us to work on an analysis of mixes related to these funds.
 
Our first action was to gather a set of information by analyzing the main peel chain of toxic changes generated by these mixes. Nothing new here.
 
After that, we decided to check if we could identify idiosyncrasies of Wasabi Wallet allowing us to weaken the anonsets of some mixed outputs potentially controlled by the hacker. The approach used here is similar to the one used for the Toxic Recall Attack previously described for Joinmarket as it leverages additional information based on the coinjoin algorithm.
 
So, we've started to review the code of the client and of the coordinator, looking for such idiosyncrasies. This is how we have identified the first vulnerability.
 
 
Vulnerability 1
---------------
 
Review of the code led us to the conclusion that there is no randomness introduced by the client or by the coordinator during the selection of TXOs that will participate in a given mix.
 
Client side, the unique random factor that we were able to find is related to the switch between "lazy mode"/"non lazy mode" (https://github.com/zkSNACKs/WalletWasabi/blob/07b0a5cf6245724c68a86dfc9a9535b0164ca864/WalletWasabi/CoinJoin/Client/Rounds/ClientState.cs#L238) but this mechanism provides a weak protection considering that it will only occur if the selection of a single TXO or of a low number of TXOs has previously failed.
 
This lack of strong randomness consistently introduced by the client and/or the coordinator means that the system is acting as a deterministic automaton.
For instance, the client can be modeled as an automaton composed of:
- a Table of Instructions that is the set of coin selection rules mainly defined in ClientState.GetRegistrableCoinsNoLock(),
- a State Register storing the set of TXOs controlled by the wallet,
- a Tape composed of cells storing events related to the mixing process ("input registration of round N starts", "input registration of round N ends", "confirmation of tx associated to round N", etc).  
 
The main consequence of this lack of strong endogenous randomness is that an observer having knowledge of events related to the mixing process and of the composition of the targeted wallet at a given step N, is able to predict which TXOs of the wallet will be selected for each round of mixing after step N, hence cancelling the benefits of the previous mixes.
 
Specifically, this means that:
 
- We are able to use the coin selection algorithm to isolate remixed UTXOs based on the coin selection rules. As a result, the anonset of the previous mix(es) does not contribute to the actual anonset. For instance, if round N generates a 0.1 mixed output A that is itself remixed by round N+1 into TXO B, then anonset(B) is equal to anonset(round_N+1) and not to anonset(A) - 1 + anonset(round_N+1) as it's expected by the user.
 
- Anonsets of TXOs that weren't selected for a given round may also be decreased thanks to this attack.
  For instance, if we know that:
    - a mixed output A controlled by the target wallet and created by round M wasn't selected for round N,
    - a TXO B also created by round M and with the same denomination as A, was selected as an input of round N
  then we can infer that B isn't controlled by the target wallet. This inference allows for a decrease of the anonset of A.
 
In summary, the lack of consistent randomnness introduced in the coin selection process negates the privacy gained by previous mixes, reducing the actual privacy to that of the most recent mix.
 
 
The role of exogeneous randomness
---------------------------------
 
So far, we've excluded the case of exogeneous randomness that may decrease the reliability of results provided by an attack based on this first vulnerability.
 
Here, it's important to note that exogeneous randomness may have different sources. Thus, we're going to use the following typology that will allow us to define a typology of attackers in the next section:
 
- Type A: Randomness introduced by the user and for which the attacker has no prior knowledge (e.g.: new funds unknown to the attacker are enqueued, user temporarily stops her client and resumes the mixing later, custom target anonset value set by the user, etc)
 
- Type B: Randomness introduced by events independent from the user (e.g: unconfirmed TXOs are rejected by the coordinator, connection failure, etc)
 
 
Typology of attackers
---------------------
 
Here we propose the following typology of attackers:
 
- Type A: Attacker having the same knowledge as the coordinator (i.e. attackers with knowledge of the technical logs of the coordinator)
 
- Type B: Attacker with no access to coordinator's technical logs but able to eavesdrop the Wasabi and Bitcoin network and, optionally, to participate in each round in order to gather additional information about the mixes.
 
Type A attackers are subject to Type A exogeneous randomness but aren't concerned by Type B (knowledge of coordinator logs).
 
Type B attackers are potentially subject to both types of exogenous randomness but they should be able to deal with some occurences of Type B randomness. For instance, the analysis of mix transactions stored on the blockchain should allow such an attacker to detect if the rejection of unconfirmed TXOs has been activated by the coordinator.
 
 
Vulnerability 2
---------------
 
In order to mitigate the effects of exogenous randomness, both types of attackers can leverage a second vulnerability that is based on the existence of peel chains composed of toxic change outputs propagating across the mixes.
 
Here, the idea is that these toxic change outputs can be viewed as:
- "beacons of certainty" because it's possible to identify which mixes have spent the toxic changes.
- "expected checkpoints" that can be predicted to occur at a given round in absence of any exogenous randomness.
 
Thus, when an expected checkpoint doesn't match with the mixes generated by Wasabi, an attacker knows that there was an occurence of exogenous randomness and he can start to investigate concurrent hypotheses of exogeneous randomness that may lead to the observed results.
 
On our side, we were able to confirm this approach during some of our tests. In one case, we were expecting the mix of a toxic change output after the first two rounds of mixing, but it didn't happen after a few hours. After further analysis, it appeared that this TXO was repeatedly rejected by the coordinator because it was unconfirmed (like others TXOs controlled by the wallet). Mixing resumed as expected after the transactions associated to the first two rounds were confirmed a few hours later.
 
This second vulnerability can be used by both types of attackers but we suspect that it's especially effective when used by Type A Attackers in order to mitigate the effect of Type A randomness (the main reason being that users are humans and humans suck at generating strong randomness).
 
 
Test of the attack in the wild
------------------------------
 
* Summmary
 
In early August, we completed a series of tests. These tests have allowed us to confirm that the coin selection algorithm implemented by the client is indeed deterministic and selected the inputs as predicted.
 
From our observations, the main source of exogenous randomness during these tests seemed related to temporary scalability issues encountered by the coordinator and leading to TXOs failing to participate to mix rounds (see PRs 4133, 4134, 4135, 4136, 4137).
 
While technical issues like these ones make the interpretation of results more challenging for Type B attackers, they don't affect Type A attackers (a failure during a registration phase or during the signing phase is part of information available to the Coordinator). Moreover, we can expect that issues like these ones get fixed, decreasing de facto the randomness experienced by Type B Attackers.
 
 
* Principle of the test
 
Test simulated 2 actors:
 
- Alice:
  - Alice simulates the Wasabi user targeted by the attack.
  - She runs a vanilla Wasabi client.
  - She sends ~0.4BTC (single UTXO) to her Wasabi wallet and enqueues this UTXO for mixing with a 120 anonset target.
 
- Eve:
  - Eve simulates an attacker tracking the funds controlled by Alice and leading to Wasabi mixes.
  - She acts as a "low-level" Type B attacker.
  - She eavesdrops the Wasabi coordinator but doesn't participate to mixes.
  - For this, she runs a slightly modified Wasabi client that logs the details of mix rounds and if rounds failed or succeeded (modifications made in ClientState.UpdateRoundsByStates()) .
 
 
* Sample test illustrating the attack
 
The spreadsheet "analysis.ods" provides a sample of a test illustrating how this attack can be used to decreases the anonset provided by multiple rounds of mixing.
 
- First sheet lists the first mixes and TXOs related to Alice's activity during the test (plus the related bitcoin addresses and private keys) .
 
- Second sheet is a timeline of events built by Eve thanks to data gathered thanks to her Wasabi client.
 
- Third sheet is the different stages of the State Register (Alice's wallet) as predicted by Eve when running a deterministic automaton simulating Alice's Wallet.
  For the sake of clarity and simplicity, the first spreadsheet is organized as follows:
  - Bold green cells identify elements modified by each step.
  - In the context of this specific test, the deterministic coins selection algo can be reduced to the following heuristic: "Select the first available TXO covering the required funds with TXOs sorted by confirmation status, increasing anonset and decreasing amount" (this order corresponds to the order defined for the selection of a single TXO).
  - Comments in the last column try to make explicit the details of the heuristic for each step.
 
 
As predicted by our model of the attack, we can observe that:
 
- remix of [9e01:81] by [79bc] leads to a first weakening of anonsets:
  - [9e01:81]: Ajusted anonset is 4 instead of expected anonset of 10,
  - [79bc:33]: Ajusted anonset is 4 instead of expected anonset of 13,
  - [79bc:46]: Ajusted anonset is 81 instead of expected anonset of 90,
 
- remix of [79bc:46] by [3de0] leads to a second weakening of anonsets:
  - [79bc:33]: Ajusted anonset is 2 instead of expected anonset of 13 (2 TXOs with same amount as [79bc:33] are inputs of [3de0]),
  - [79bc:46]: Ajusted anonset is 2 instead of expected anonset of 90,
  - [3de0:45]: Ajusted anonset is 53 instead of expected anonset of 142.
 
 
Severity
--------
In our opinion, these vulnerabilities should be considered as High/Critical for the following reasons:
 
- in the case of a mixed output being remixed, these vulnerabilities break the Zerolink guarantee for the previous mix and cancel the benefits provided by the previous mix.
 
- these vulnerabilities break the global guarantees provided to users by the mixer. Indeed, an effective attack against the user of a mixer doesn't require the deanonymization of all user's postmix TXOs. Deanonymizing a single TXO is often enough. Thus, the last mix a user participates in is their effective anonset. For users participating in a final low liquidity mix (e.g. 105d84ad09a11e91b406cbde6ae220ad8dc74d718427080721b0048f18a4f55c or 9035306130415c91b7144e977097a7abe150aaf554046390ec48a8e61d051c9c), their desired/expected and actual privacy can be off by an order of magnitude.
 
- Considering that these vulnerabilities have existed for a long time, it's our belief that if we were able to detect them, it's more than likely that they were already detected by someone else and perhaps already exploited in the wild.
 
 
Potential mitigations / fixes
-----------------------------
 
As it was shown in previous sections, the unique protection currently available to users against these two vulnerabilities is the occurrence of exogenous randomness. Obviously, this can't be considered as a satisfying solution, because:
- protection should be consistent and verifiable and shouldn't rely on external factors which aren't under the control of users or operators of the mixer.
- it offers a weak protection against Type A attackers.
 
In our opinion, the best fix against these two vulnerabilities is the introduction of consistent randomness in client code (i.e. in ClientState.GetRegistrableCoinsNoLock()).
 
We understand that prioritizing the selection of some TXOs over others TXOs might be an important factor for Wasabi operations and we believe that it's still possible to do that while introducing randomness only known by the client.The principle of such a solution would be to replace the current selection process based on a strong ordering of TXOs, by a random selection of a Coingroup, with an unequal probability of being selected depending on the factors currently used for the ordering.
 
For instance, the stong ordering of TXOs by anonset and amount (https://github.com/zkSNACKs/WalletWasabi/blob/07b0a5cf6245724c68a86dfc9a9535b0164ca864/WalletWasabi/CoinJoin/Client/Rounds/ClientState.cs#L242) may be replaced by:
- the computation for each CoinGroup of a metric f(anonset(CG1), amount(CG1)).
- the computation for each CoinGroup of a probability of being selected: P(CG1) = metric(CG1) / sum_over_CGn(metric_CGn).
 
 
 
Schedule for a public disclosure
--------------------------------
 
Considering the severity of these vulnerabilities and the likelyhood this is already being exploited by less ethical parties but also keeping in mind the time that may be required for implementing and testing a fix, a tradeoff has to be found. Thus, we are offering the following approach:
 
- Within 48 Hours of the delivery of this disclosure Wasabi Wallet / Zk Snacks Ltd should release a statement on their public channels (twitter, reddit, website, etc...) alerting and warning users to the fact that a vulnerability has been reported and a solution is being worked on.
 
- Within 15 Days of the delivery of this disclosure Wasabi Wallet / Zk Snacks Ltd should release a tested patch to the public that mitigates the concerns in this disclosure.
 
Provided these two conditions are met, we will not disclose this publicly until after the 15 days have elapsed and a fix can be implemented by your team.
 
If Wasabi Wallet / Zk Snacks Ltd fails to release a statement within 48 hours we will be forced to conclude that the team does not consider this a serious issue and we will begin the process of a responsible public disclosure immediately.
 
 

The only (cmiiw) way the attackers can get enough wallet state info is if someone puts a large amount of BTC in as one UTXO and then queues all of it for remix. Stick with small sizes, should be fine.

mk4
Legendary
*
Offline Offline

Activity: 1876
Merit: 2442


🔐 NotYourKeys.org 🔑


View Profile WWW
August 21, 2020, 08:15:16 AM
 #9

If I remember correctly, I read on Twitter that Samourai will only disclose the "vulnerabilities" if only Wasabi promises to close their service or something like that. Correct me if I'm wrong as I haven't dug deep if this is true or not, but it looks like the Samourai devs or whoever is concerned with their talks are being petty again as per usual.

Royse777
Legendary
*
Offline Offline

Activity: 1596
Merit: 2027


Powerful promotion strategy https://bit.ly/3cRVjFi


View Profile WWW
August 21, 2020, 08:34:03 AM
Merited by mk4 (1)
 #10

If I remember correctly, I read on Twitter that Samourai will only disclose the "vulnerabilities" if only Wasabi promises to close their service or something like that. Correct me if I'm wrong as I haven't dug deep if this is true or not, but it looks like the Samourai devs or whoever is concerned with their talks are being petty again as per usual.
It was here: https://www.reddit.com/r/Bitcoin/comments/id6iub/a_vulnerability_in_wasabi_coin_join_has_been/g27srsm/?utm_source=reddit&utm_medium=web2x&context=3



I am not much Reddit guy so could not find the exact link.

And the below came from SamouraiWallet:


https://www.reddit.com/r/Bitcoin/comments/id6iub/a_vulnerability_in_wasabi_coin_join_has_been/g282wur/?utm_source=reddit&utm_medium=web2x&context=3

This seems political to me but still not making any conclusion yet.

.
.Duelbits.
            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
▄▀▄
█   █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█ █ █
█▀▀▀▀▀█
▀█▀█▀
█▄█
█▄█
.
        ▄ ▄▄▀▀▀▀▄▄
        ▄▀▀▄      █
        █   ▀▄     █
      ▄█▄     ▀▄   █
     ▄▀ ▀▄      ▀█▀
   ▄▀     ▀█▄▄▄▀▀ ▀
 ▄▀  ▄▀  ▄▀
▀▄    ▄▀▀
Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█
█  █    █    █  █  █ █
Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █
█     ▀▄▀     █   ▀▀  █
Blackjack
.
▄▄▀█████▀▄▄
▄▀▀   █████ ▄▄▀▀▄
███▄  ▄█████▄▀▀▄███
██████▀▀     ▀▀██████
█ ▀▀██▀ ▀▄   ▄▀ ▀██▀▀ █
█    █    ███    █    █
█ ▄▄██▄ ▄▀   ▀▄ ▄██▄▄ █
██████▄▄     ▄▄██████
Roulette
.
█▀▀▀▄             ▄▀▀▀█
█ ▀▄ ▀▄         ▄▀ ▄▀ █
▀▄ ▀▄ ▀▄     ▄▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄  ▀ ▄▀ ▄▀
▀▄ ▀▄ ▀▄ ▀ ▄▀
▄ ▀▄ ▀▄ ▀▄  ▄
█ ▀▄ ▀▄ ▀  ▄▀ █
▄▀▄ ▀▄ ▀ ▄▀ ▄▀▄
Dice Duels
mk4
Legendary
*
Offline Offline

Activity: 1876
Merit: 2442


🔐 NotYourKeys.org 🔑


View Profile WWW
August 21, 2020, 08:50:50 AM
 #11


Thanks. What an outrageous move from Samourai. I get it, they're competitors. But what they're asking for in return is just something else; and their petty namecalling on Twitter ain't helping either. Sure they might have a good privacy-focused wallet in their hands, but the person who handles their comms seems like a huge child.

NotATether
Hero Member
*****
Online Online

Activity: 728
Merit: 2393


Cryptographic Crawler


View Profile WWW
August 21, 2020, 10:25:26 AM
 #12

~

Thanks for pasting the vulnerability here it makes it easier to read without clicking on a bunch of links. If you have to modify the Wasabi client code to make the exploit work, wouldn't you have to patch it frequently each time there is an update for Wasabi? So I think this is out of reach for lone wolves and that it takes a group of hackers to designate people to make a patched client and others to listen to the coordinator.

ETFbitcoin
Legendary
*
Offline Offline

Activity: 2072
Merit: 3399


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
August 21, 2020, 11:50:26 AM
 #13

The competition between Wasabi and Samourai getting more unhealthy, but since there aren't many information of toxic waste attack which is similar with this Wasabi Vulnerabilities, i can't make any conclusion.

bob123
Legendary
*
Offline Offline

Activity: 1610
Merit: 2428



View Profile WWW
August 21, 2020, 12:34:22 PM
Merited by ETFbitcoin (3), hugeblack (2), o_e_l_e_o (2), DaveF (1), mk4 (1), Last of the V8s (1)
 #14

After reading the published vulnerability, i'd still stay that this is by far not as severe as outlined by samourai.

Assuming that an attacker knows every UTXO in your wallet:
  • Choosing the UTXOs to mix yourself, does circumvent everything mentioned by them.
  • Not mixing multiple BTC's automatically at once does circumvent this.

Assuming that an attacker does not know every UTXO in your wallet, the "vulnerability" isn't exploitable at all.


The recommendation from samourai to "stop using coinjoin" is exaggerated. Especially for a wallet which calls "ricochet" a privacy extending mechanism.
For everyone wondering what that is: It simply adds hops between your address and the destination. Basically it makes 3-4 transactions out of 1: Source -> hop1 -> hop2 -> hop3 -> destination
And these transactions are always broadcasted after the previous one has 1 confirmation. That's quite easy to detect and not sophisticated at all.

Calling that privacy extending while also assuming an attacker knows every UTXO in a competitors wallet to find vulnerabilities is kind of insincere.

o_e_l_e_o
Legendary
*
Offline Offline

Activity: 1498
Merit: 7986


Wear a mask, slow the spread


View Profile
August 22, 2020, 11:35:40 AM
Merited by DaveF (2), ETFbitcoin (1)
 #15

Here is a response on reddit from "nopara73", who is one the developers of Wasabi Wallet (His GitHub: https://github.com/nopara73): https://old.reddit.com/r/WasabiWallet/comments/icvu58/any_statement_to_this_is_this_true/g2bixj8/

He is essentially saying what bob123 has said above - this "vulnerability" is dependent on the attacker knowing every UTXO in your wallet. If you are trying to protect your privacy, and an attacker has managed to discover every UTXO in your wallet without you handing out your master public key, then you have much bigger things to worry about, such as the security of your entire computer or how you are so careless as to leak so much information unintentionally.

DaveF
Legendary
*
Offline Offline

Activity: 2590
Merit: 2667


I DO NOT TRADE on Telegram or Skype or Discord.


View Profile WWW
August 22, 2020, 11:58:06 AM
Merited by Last of the V8s (1)
 #16

Here is a response on reddit from "nopara73", who is one the developers of Wasabi Wallet (His GitHub: https://github.com/nopara73): https://old.reddit.com/r/WasabiWallet/comments/icvu58/any_statement_to_this_is_this_true/g2bixj8/

He is essentially saying what bob123 has said above - this "vulnerability" is dependent on the attacker knowing every UTXO in your wallet. If you are trying to protect your privacy, and an attacker has managed to discover every UTXO in your wallet without you handing out your master public key, then you have much bigger things to worry about, such as the security of your entire computer or how you are so careless as to leak so much information unintentionally.

The only things I could kind of come up with, and both are a stretch; one is if someone knew that it was a new wallet with only 1 or 2 UTXOs that could be known. The other is even more of a stretch but possible is that they could find your UTXOs but knowing your habits. i.e. I am in a sig campaign, if I always used a new wallet not just a new address for getting paid then you would know what is happening.

Both would not happen under normal circumstances. But other then that, I have no other way of thinking of a way that people could get that info without having access to the device running it.

-Dave

Last of the V8s
Legendary
*
Offline Offline

Activity: 1652
Merit: 4390


Be a bank


View Profile
August 22, 2020, 06:49:13 PM
Last edit: August 23, 2020, 08:14:59 PM by Last of the V8s
 #17

Here's the whole enchilada:

https://research.oxt.me/alerts/2020/08/21/Wasabi-Wallet/full

nothing new beyond what bob123, daveF et al. have said here, just puff and er snark

Quote
“... I think it’s silly...” Adam Ficsor (nopara73), Wasabi Wallet Founder

I agree lol

edit: more discussion in the latest Block Digest podcast https://youtu.be/dpbvvv8S-NA saying largely the same, perhaps more heatedly

Captain-Cryptory
Hero Member
*****
Offline Offline

Activity: 1260
Merit: 852


👿 lurks in the details.


View Profile
August 28, 2020, 10:37:49 AM
 #18

According to the research I did about the OXT research, I'm afraid they seem to be telling the truth about Wasabi's wallet vulnerabilities because they were able to track down the year 2015 hacker that stole 455BTC despite the hackers used Joinmarker

Looks like Wasabi is  straggling to improve their  mixing protocol  to make such tracking hard in the future. But their attempts are still in the testing phase so no one knows what the outcome is, betterment or step backward.
posi
Hero Member
*****
Offline Offline

Activity: 1624
Merit: 554

God will make a way ↕️


View Profile
August 28, 2020, 11:50:23 AM
 #19

According to the research I did about the OXT research, I'm afraid they seem to be telling the truth about Wasabi's wallet vulnerabilities because they were able to track down the year 2015 hacker that stole 455BTC despite the hackers used Joinmarker

Looks like Wasabi is  straggling to improve their  mixing protocol  to make such tracking hard in the future. But their attempts are still in the testing phase so no one knows what the outcome is, betterment or step backward.
Straggling to improve their mixing protocol was not the issue because their wallet anonmymity are done through coinjoin right from the get go and no vunerability was detect until now but they definitely need to add an advance privacy features.
According to @Last of the V8s message, the attackers cannot get the sender's wallet information if the BTC is not large amount.








bob123
Legendary
*
Offline Offline

Activity: 1610
Merit: 2428



View Profile WWW
August 28, 2020, 04:22:45 PM
 #20

Looks like Wasabi is  straggling to improve their  mixing protocol  to make such tracking hard in the future.

You didn't understand the "vulnerability" posted by samourai and also didn't understand the article you have linked.

There is no vulnerability in the coinjoin. Neither is there something to "fix" inside of the protocol. According to the article you have linked, they are going to further improve it to make it more appealing and easier to use.
However, this is not related to any privacy issues or similar.

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!