Jump to content
Exchange Prices

Monero

Sign in to follow this  
  • entries
    14
  • comments
    0
  • views
    114

About this blog

Graft blog test

Entries in this blog

Snider

Monero is a powerful tool that prioritizes privacy, security, decentralization, and fungibility. It includes several design components, including an accessible Proof of Work (PoW) algorithm and mandatory privacy to better meet these objectives. Monero is most often used for good. Thousands of transactions per day are used for speculation, securing the network, and for everyday purchases. Several nonprofits including UNICEF Australia, BailBloc, and Change.org allow users to mine Monero by simply visiting a website. The proceeds support various philanthropic causes. Other websites allow users to opt-in to mine instead of viewing advertising.

While the clear majority of users take advantage of these features for good, some attackers use Monero to earn money from machines without users' consent. They may run miners on webpages that activate without a user's consent. They may infect machines or hide it in other packages and run mining software. They may infect machines, encrypt the local files, and demand a ransom payment in Monero.

The Monero community condemns this malicious, non-consensual use of equipment to mine. Unfortunately, the Monero network itself benefits by having a wide set of stakeholders mine, since the network's security is afforded through a distributed set of users. While restricting mining to specialized equipment largely eliminates malicious mining, it doesn't eliminate ransomware, and it introduces security compromises that the Monero community is not comfortable with. Monero contributors build the best tool possible; they should not make it less secure even if it means the accessible system provides easier access to criminals too. However, the Monero community does not want to sit idly by as victims struggle to understand the impact of mining and ransomware. Most of these victims have no idea what mining and Monero are.

We created a set of resources that explain the basics of Monero and mining. We also have resources explaining and helping stop/remove unwanted in-browser mining, system mining, and ransomware. The website is purposefully approachable to absolute newcomers so that anyone can understand, though it offers actionable information that novices and experts alike can follow. It's our mission to resolve an unfortunate situation as well as possible.

The Monero Malware Workgroup is a self-organized set of volunteers that maintains these resources and provides live support. In the future, we will provide support from our website directly, but you can interact with our volunteers today at #monero-mrw, accessible on Freenode, Riot/Matrix, Mattermost, and Slack. If you would like to join our workgroup, hang out there and help us answer questions!

We will not be able to eliminate malicious mining, but we hope to provide necessary education for people to better understand Monero, what mining is, and how to remove malware.

mrw.getmonero.org


View the full article

Snider

This blog sets out the burning bug. The goal of this blog post is to provide a detailed explanation of aforementioned bug, how it could be used to cause harm to services, merchants, and exchanges, and how it was handled by the Monero (dev) community.

The bug basically entails the wallet not providing a warning when it receives a burnt output. Therefore, a determined attacker could burn the funds of an organization's wallet whilst merely losing network transaction fees. They, however, do not accrue direct monetary gains. Nonetheless, there are probably means to indirectly benefit. The notion of burning funds by sending multiple transactions to the same stealth address has been documented for quite some time already, as, for example, can be seen from this Monero SE Q&A. Unfortunately, however, the implications of an organization being involved had not been thoroughly thought through until a community member described a hypothetical attack on the Monero subreddit.

Now, a stealth address in Monero is described by the following formula:

P = Hs(rA||i)*G + B

Where

Hs is a hash to scalar function (note that the scalar output is reduced modulo l);

r is the private transaction key, which is randomly generated by the sender;

A is the public view key (which is part of the public address) of the recipient;

i is the output index (each output has its own index number (e.g. the first output has index 0));

G is the standard Ed25519 basepoint;

B is the public spend key (which is part of the public address) of the recipient;

Whereas a key image in Monero is described by the following formula:

I = xHp(P)

Where

x is a private key / scalar (created by adding the recipient's private spend key and the hash to scalar output of the ECDH shared secret);

Hp is a hash to point function;

P is the stealth address;

As can be seen from aforementioned functions, sending Monero to the same stealth address will result in multiple duplicate key images. Note that the network will reject a key image if it's already present in the blockchain, because it will be seen as an attempt to double spend. Thus, one will only be able to spend from this stealth address once (the wallet will automatically select the largest denomination though) and the remainder of the outputs will be unspendable / burnt. In addition, the transactions to the same stealth address will be linkable.

Practically speaking this bug is exploited as follows. An attacker first generates a random private transaction key. Thereafter, they modify the code to merely use this particular private transaction key, which ensures multiple transactions to the same public address (e.g. an exchange's hot wallet) are sent to the same stealth address. Subsequently, they send, say, a thousand transactions of 1 XMR to an exchange. Because the exchange's wallet does not warn for this particular abnormality (i.e. funds being received on the same stealth address), the exchange will, as usual, credit the attacker with 1000 XMR. The attacker then sells his XMR for BTC and lastly withdraws this BTC. The result of the hacker's action(s) is that the exchange is left with 999 unspendable / burnt outputs of 1 XMR.

The bug was discovered after a community member described a (hypothetical) attack on the Monero subreddit. A private patch was promptly created and later included in the code via this pull request. I (and others) privately notified as many exchanges, services, and merchants as possible with the (private) patch that had to be applied on top of the v0.12.3.0 release branch. To reiterate (from the previous post mortem blog), this is clearly not the preferred method, as it (i) invariably excludes organizations that I (and others) personally do not have contact with, but are an essential part of the Monero ecosystem and (ii) may invoke a view of preferential treatment. However, there had only been limited time to improve the vulnerability report process. Although, the bug being announced on the public mailing list can be perceived as an improvement. Lastly, I'd like to emphasize that, for any organization present in the Monero ecosystem, it's imperative to be subscribed to the public mailing list.

In sum, a bug in the wallet software allowed a determined attacker to cause significant damage to organizations present in the Monero ecosystem with minimal cost. Fortunately, the bug did not affect the protocol and thus the coin supply was not affected. However, we, as the Monero community, should seek means to get more eyes on the code and especially new pull requests. If you are familiar with C and/or C++, please, if time permits it, try to review pull requests (even a partly review is beneficial). Lastly, this event is again an effective reminder that cryptocurrency and the corresponding software are still in its infancy and thus quite prone to (critical) bugs.


View the full article

Snider

This blog sets out the multiple counting bug, of which two variants existed. The goal of this blog post is to provide a detailed explanation of aforementioned bug, how it was used to exploit services, merchants, and exchanges, and how it was handled by the Monero (dev) community.

The multiple counting bug, of which two variants existed, was introduced in conjunction with the subaddress feature, which required a different (code) structure of the transaction public key. The first variant of the bug is basically that the code didn't impose a check to guard against duplicate public keys. Therefore, an attacker could create a transaction in which the transaction public key was included multiple times, thereby duplicating the particular transaction public key. As a result, the receiving wallet would report that it had received x times (where x is an integer that represents the number of identical transaction public keys) the amount it had actually received. All commands that report incoming transactions (e.g. show_transfers (CLI), get_transfers (RPC)) were affected. The balance, however, was not affected, i.e., the wallet would still report the balance properly. Alas, most exchanges utilize the get_transfers or get_payments wallet RPC command, which would, in case of duplicate transaction public keys, return an erroneous amount.

Unfortunately, this variant of the bug was fairly trivial to exploit, i.e., an attacker simply had to append add_tx_pub_key_to_extra(tx, txkey_pub); in src/cryptonote_core/cryptonote_tx_utils.cpp and their transaction public key would, after recompiling the code, be duplicated. Practically speaking this works as follows. The attacker starts with appending src/cryptonote_core/cryptonote_tx_utils.cpp, say, thrice^1, thereby creating four identical public transactions keys for their transactions. Subsequently, they send a transaction of, say, 1 XMR to an exchange they seek to exploit. The exchange will, most likely, credit the attacker with 4 XMR. The hacker, thereafter, withdraws this 4 XMR, thereby basically robbing the exchange of 3 XMR. If the exchange does not regularly check the balance against the sum of incoming and outgoing transfers or checks the hotwallet for any abnormalities, the hacker can basically repeat aforementioned process until the Monero hot wallet is emptied or, worst case scenario, all Monero funds are depleted.

The second variant of the bug, of which a detailed report can be found on HackerOne, entails the code not imposing a check against dummy transaction public keys. Therefore, a hacker could utilize the alternative transaction public keys feature to trick the wallet into scanning the outputs in a transaction twice. As a result, the receiving wallet would report that it had received two times the amount it had actually received. Similar to the first variant of the bug, the balance was not affected.

The first variant was first reported in this issue on Github and was promptly fixed by moneromooo in this pull request. Unfortunately, however, the severity of the bug was underestimated until (i) an exchange got exploited via a fork of Monero and (ii) a security researcher (jagerman) on HackerOne provided an elaborate report on how to utilize this bug to steal funds from exchanges. The second variant was reported by phiren on HackerOne and quickly fixed in this pull request. Both patches got merged by fluffypony and were included in the v0.12.3.0 release.

After v0.12.3.0 was tagged, I (and others) privately notified as many exchanges, services, and merchants as possible. Obviously, this is not the preferred method, as it (i) invariably excludes organizations that I (and others) personally do not have contact with, but are an essential part of the Monero ecosystem and (ii) may invoke a view of preferential treatment. In addition, the bug should have been reported on the public mailing list, but, alas, wasn't. An oversight which should be learnt from. Furthermore, we, as the Monero community, should seek improvements that would streamline this vulnerability report process (i.e. reporting a critical vulnerability to exchanges, services, and merchants). A "private" mailing list to which only services, merchants, and exchange are able to subscribe may be in line with this notion. Some kind of verification of subscribers would be required though, which could be a tedious process. Although, it would probably be more secure than a public mailing list to which a clever attacker would undoubtedly subscribe.

In sum, a critical bug in the wallet software, of which the severity was initially significantly underestimated, allowed an attacker to steal funds from organizations present in the Monero ecosystem. Fortunately, the bug was confined to the accounting functionality of the wallet software, and thus the protocol and coin supply were not affected. It's imperative, however, that we learn from this event and seek improvements that would significantly mitigate the impact in case a similar bug is discovered in the future. Furthermore, this event is an effective reminder that cryptocurrency and the corresponding software are still in its infancy and thus quite prone to (critical) bugs. As such, it would be prudent for organizations to include as many sanity checks as possible (e.g. a check to verify the sum of transfers against the balance). In addition, the Monero dev community is investigating the feasibility of adding such a check to the RPC wallet.

Notes:

  1. As an example, a transaction with 50 identical transaction public keys (01ede13f013833f8aef14a9397b83fd5171833ab55bc480104dd6ba86ca8f13558) can be found here.

View the full article

Sign in to follow this  
×