On 5th September, Monero released a report in which they announced a post mortem of the multiple counting bug that they faced recently. The report provided a detailed information about the bug and how it was used to exploit services, merchants and exchanges.
The multiple counting bug had two variants, which required a different structure of the transaction public key. It was introduced in conjunction with the subaddress feature.
In the first variant of the bug, the code did not impose an inspection to guard against duplicate public keys. This vulnerability resulted in attackers creating a transaction in which the transaction public key would be included multiple times. This resulted in the duplication of the particular transaction public key.
In the second variant of the bug, the code did not impose a check against dummy transaction public keys. Therefore, a hacker could trick the wallet into scanning the outputs in a transaction twice by utilizing the alternative transaction public key feature. As a result, the receiving wallet would report that it had received two times the amount that it had actually received.
The first variant of the bug was earlier reported on GitHub, and the severity of the bug was underestimated. This resulted in the exploitation of exchanges, and funds being stolen from organizations in the Monero ecosystem.
Moreover, a security researcher for HackerOne provided an elaborate report on how the bug was being utilized to steal funds from exchanges. The second variant of the bug was reported by Phiren on HackerOne.
After merging both the patches, Fluffypony, Monero’s Lead Maintainer released a new version V0.12.3.0. The severity of a critical bug in the wallet software was initially underestimated which allowed an attacker to steal funds from organizations in the Monero ecosystem.
Fortunately, the bug was confined to the accounting functions of the wallet software, and thus the protocol and coin supply were not affected. The Monero community also spoke about the adequate measures taken to solve the problem. DubsNC stated on Reddit:
“Yeah, the mailing list doesn’t sound like a good idea to me. It does sound like a high value target list for an adversary. How about just a signed update flag in the protocol that tells all full nodes to update at the sale time?”
Flenst, an enthusiastic Redditor stated:
“I am really glad to see that mistakes that have been done won’t be repeated and there will be better solutions in the future to disclose vulnerabilities like this to services in a more reliable way.”
Subscribe to AMBCrypto’s Newsletter
Is China’s Alibaba Group going to aquire Alibabacoin [ABBC]?
Ethereum [ETH] in the spotlight again; developers and the community talk updates
Litecoin [LTC/USD] Technical Analysis: The green zone turns red as the bear feasts on the wounded market
Cardano [ADA]’s Charles Hoskinson on EOS raising more capital than Cardano
Bitcoin Cash [BCH] is more viable than Bitcoin [BTC] says Co-Founder of Cyber Capital
Ripple partner Santander to adopt SWIFT GPI: What does it mean for XRP-powered xRapid?
Ripple partner Santander goes live with SWIFT’s Global Payments Innovation
Bitcoin [BTC] is not going to disappear, but Ethereum [ETH], XRP and others are “going bust”, says Roubini
Bitfinex pauses USD deposits after Bitcoin [BTC] drops: $2.3 billion at stake as insolvency rumors threaten USDT legitimacy
Tron [TRX/USD] Technical Analysis: The bulls have charged attack on the bear
XRP can now be used as collateral for $2 million instant loans
Tron [TRX] Foundation and Justin Sun announce a new partnership event
XRP, Ethereum [ETH] create ripples in cryptocurrency space; market wakes up to developments
Is Tron [TRX] planning to build its decentralized TronTube after the YouTube outage incident?