Topic: Mass hack -- over 1000 bitcoin addresses have been affected (Read 471 times)

Flipping a coin (or throwing a dice) enough times is a lot more compact.

You don't select words, you select bits. The easiest representation I've seen is Bitcoin Visual private key generator. This creates a private key instead of a seed phrase, but the principle behind it is more or less the same. Note that this visual generator is mostly for educational purposes, you shouldn't use it for actual funds unless you know what you're doing.

Nope, but you can use some simple math. BitBox has a nice lookup table here: https://bitbox.swiss/bitbox02/BitBox_Diceware_LookupTable.pdf.

ColdCard has a python script for you: https://coldcard.com/docs/rolls.py. ColdCard converts your input to SHA256 hashes before continuing with the word assignment.

Generally, if you have two different methods of generating randomness, and in your case two different bingo machines with different number of balls, you're bound to have certain values occurring more frequently than others.

not against using a six side die but how do I insure the picking pattern?

it is easy with 2 bingo machines

32 in one machine and 64 in the other. allows a 1 to 1 match for all 2048 words.

not sure how to assign the die rolls properly to the 2048 words.

is there a demo on youtube?

It's certainly a complicated topic. Rest assured that it is a topic that is heavily studied and there shouldn't be any concerns about using it so long as it is securely implemented.

There was an extensive discussion on this: https://bitcointalksearch.org/topic/measuring-the-randomness-of-a-seed-phrase-5460240.
Yeah, they are probably not random. The QC on these aren't as stringent as you think. Any difference in the size of the balls would result in certain results being more common as others. It really doesn't matter how unpredictable it is, any degree of randomness below that of your computer already means a weaker seed. I wouldn't trust a toy for my security. Besides, you have to consider the checksum for the final word, and BIP39 also only allows for 24 words at the maximum, anything beyond that is not within specs (even if it is in multiples of 3s).

The best practice isn't to use a bingo machine, but using an unbiased 6 sided casino dice, generating at least 50 rolls.

for the life of me I do not understand why any trusts a computer for a seed.

2048 words.

make a set of columns

32 by 64

 as 32 x 64 = 2048

next buy 2 bingo machines

https://www.amazon.com/gp/product/B088CHK7HY/ref=ox_sc_act_title_1?

put 64 balls in first 1-64

put 32 balls in the other 1-32


spin first get a 30

spin second get a  30

30 x 30 = 900

go to 900th word on the list

2 spins for one word

24 spins for 12 words

48 spins for 48 words.


are the 2 machines perfectly random not likely

but they are very likely random enough that no one will be able to understand the lack of perfect randomness for those 2 machines.

Even if they buy 2 of the same make and model.

Since they likely not perfectly identical even having 2 of the same units won't help much.

In fact if you have a lot of coin buy 4 separate bingo machines from 4 different companies.


https://www.amazon.com/s?k=bingo

Minor nitpick but it should be 'The randomness falls on the OS's ability to gather these AND USE THEM PROPERLY, not the CPU

There have been a few times when programmers screwed it up and took totally random, non duplicate entropy and gave bad randomness but to bad programming. We have to trust that they did it right, but have seen many times though the decades of computing that they did non.

https://www.wired.com/2017/02/russians-engineer-brilliant-slot-machine-cheat-casinos-no-fix/

-Dave

Depends. Those CSPRNG generally will still seed their randomness pool with the entropy from OS's CSPRNG and under normal circumstances, this wouldn't be compromised. From what I can tell, they are calling the correct functions. CPU is just one of the many inputs for the entropy pool and there are various other sources for entropy, hardware interrupts, noise, keyboard inputs, etc. The randomness falls on the OS's ability to gather these, not the CPU.

Sorry for your loss.  Just going through your post I have some comments and some suggestions.


I don't like mixing servers and wallets.  If I'm opening a node to the network, even just my local network, I wont ever use it to open a wallet.  Maybe overkill on the paranoid side, but just because I'm paranoid doesn't mean a hacker isn't trying to get at my coins.  


Unconventional key generation.  I didn't go through this code, but I couldn't help but notice that bitcore-mnemonic is a Java applet.  As far as I know web-browser and Java based seed generators won't provide the same entropy that a python or C++ seed generator can.  Again, to my admittedly limited knowledge this is due to whether the applet can access the CPU's ability to generate randomness, and I don't know if this particular Java app can do so.  If I'm wrong in this instance, this could be a non-issue.


I don't know if this had anything to do with your hack, but storing seeds digitally, especially on the same machine as the wallet isn't very secure regardless of whether the info is encrypted or not.  Loss of the machine could mean loss of your funds and all the backups.


Please correct me if I'm wrong, but this makes me think you were using a third party VPS provider to run your node and wallet.  That's a big security risk in my opinion.  

Possibly unrelated. Bitcore uses crypto.getrandomvalues which should request the browser to seed from urandom. There should be some checks on the bias of the data as well. JS is not great for CSPRNG but I wouldn't expect it to be that much of a security risk. Besides, OP seems to mention that Bitcoin Core generated those addresses.

Although what you said is more likely then what I posted about, keep in mind some of the server vulnerabilities I pointed out, and some others that are also out there allow for reading of memory outside of what should be your private VM.

If you got a dump of what was in the OPs machine you might not have gotten all the keys just the ones that were doing something at the time.

And without knowing more about the physical hosting setup, it's all a guess.

A lot of the time it's not the OS / software but the people involved. In theory I have no access to a lot of what my clients have stored on their machines.
In reality, it's amazing how much they just give to me when they are having an issue and need help with an issue.

-Dave

In light of recent events, I think we may have an idea as to what happened.

After libbitcoin explorer was found to have an extremely insecure seed generation command called bx seed, it must be concluded that the OP used bx seed to create the mnemonic. Particularly after following instructions from the Mastering Bitcoin book (which has instructions for using bx seed).

Personally, if I was a normal user, I would not had suspected anything wrong with using that.

The real scummy part was that in 2016 (probably after the book was publish since A.A. would have done his due diligence before publishing anything), the devs changed the secure random generator to a Mersenne Twister pseudorandom generator, which is no better than ordinary Python random numbers - and according to source code comments, they were considering even using rand(3) and srand(3), only backing out because the functions were not thread safe!

(hurr durr so cryptographic safety is not as important then. )

The OP's July 12 theft date coincides with what is shown on the MilkSad homepage. It must be concluded that the attacker was using libbitcoin command-line software in order to carry out the theft.

How they managed to use that software is incredulous, because building libbitcoin is an arse. But anyway, this must be what happened.

---

Note: OP says they used bitcore libraries to generate the mnemonic, but from this: https://milksad.info/disclosure.html it says the researchers confirmed that that mnemonic was somehow generated using bx seed or at least a pseudorandom generator (mt19937).

Bitcore also has insecure pseudorandom key generators, but I could not verify whether any of them are actually called when making the mnemonic.

If you generated keys online there is a chance some of them got leaked, but maybe you can tell us what did you use for generating entropy?
Being a little paranoid during this entropy generation is not a bad thing, and I am even starting to suspect in entropy generated by closed source hardware wallets like ledger.
I think you should always do this part offline, and I would never keep keys online or cloud, aka other people computers, even if it has additional encryption.
I am sure there is a way for exchange to use some kind of multisig setup to prevent hacks like this happening in future.

If you are interested how Seed Generation works in Hardware Wallets check out one of my topics:
https://bitcointalksearch.org/topic/seed-generation-in-hardware-wallets-5317199

Good points but it doesn't explain why only some part of funds were stolen. That's very weird. Frankly, I haven't heard of any other such case. As soon as the bad guys gain access to your wallet they normally empty it dry asap.

It doesn't matter whether you open your wallet regularly or not, as long as your private key is secure and not exposed you should be fine. If you are sure your case is similar to OP then you can provide more details. Saying that you might get hacked doesn't really help much. A lot of people got hacked and quickly blame their wallet app, even though it was their fault for storing keys on the cloud, downloading malware, etc.

1) Where are you hosting this locally or someplace else: https://www.bleepingcomputer.com/news/security/critical-ami-megarac-bugs-can-let-hackers-brick-vulnerable-servers/

2) If you are not hosting is on your own hardware keep in mind Meltdown and Spectre are still a thing https://meltdownattack.com/ if your provider did not apply patches which many have not even now 5 1/2 years later

3) Ubuntu 16.04 has been out of support for a while now and had known vulnerabilities

4) Since Ubuntu 16.04 is out of support there are probably other things on it that have not been updated:
https://thehackernews.com/2023/07/new-openssh-vulnerability-exposes-linux.html

5) The PC you connect FROM could have some compromise on it.

6) There is no such thing as a secure location if I know you are there and have the time to plan. MITM attacks and such are a real thing and can be targeted.

-Dave

Fair point, but I was eliminating various possibilities before coming to this conclusion. If you're talking about weak entropy, the only possible point of failure lies with BitPay, Bitcoin Core does have a pretty robust system when it comes to RNG by taking randomness from multiple sources. It would be hard to imagine that it would be a point of failure and besides the there are no address reuse (I presume) and it would eliminate the possibility signature nonce re-use (nonces are deterministic anyways).

Taking in mind that the possibility of Bitcoin Core being flawed is fairly low, the only two possible factors would be any vulnerabilities within your server or BitPay. Regardless, eliminating possibility based on the possible psychological thinking of the attacker wouldn't be effective in determining the actual cause. Perhaps they are only interested in those, perhaps they didn't want to draw attention to themselves, etc.

I understand that in the first place you can think about the vulnerability of the server, but besides bitcoin, there was still a lot of things that could be stolen, but nothing was stolen, moreover, not even all of the bitcoin was stolen, so this is anything but not a server vulnerability. Perhaps the problem is indeed in weak entropy, but what exactly in my case, I don’t understand.

This can't be the reason because I found Legacy and Segregated Witness (SegWit) Addresses (P2SH-P2WPKH) too in the senders list from the hast that OP shared so it doesn't make any sense that the hacker just stole a part of the money from wallets and more interestingly he left them unspent 3D2mKf28exn26v7BCVe9AXrrg4BY7qvYcv

But usually, they will try to convert them ASAP to cut the traces.

You mentioned the attacker only targeted Segwit UTXOs. So maybe the malware was using a block explorer that checks the balances of different types of addresses and displays them separately (i.e. not by private key), and that's what lead the hacker to go out and only steal from bech32 addresses.

Then again, I find the outgoing transactions suspicious too, because they are being sent to 100+ receipients.

Do you have the access logs to your Ubuntu Server? Are you certain that nothing has accessed it, not even via hypervisor or anything similar? Things like these tends to go unnoticed when doing cyber forensics for most. I have my doubts that the generation of your seeds is the problem, I don't see any vulnerabilities in recent times for those wallets that you've listed and they are fairly well vetted unless it is zero day.

I highly doubt that Bitcoin Core would be the issue, other than the fact that RPC functions could be the culprit. That leaves both your server and seed generation to be weak, I'm not aware of any concurrent vulnerability affecting it but it is not maintained at all. Is there any RPC connection visible in your debug.log?

Anyways, it's not over 1000 addresses, a quick look indicates that a good portion of the funds belongs to this: https://blockchair.com/bitcoin/address/bc1qxs3ugdgda5ljt20uuqegljzlq8rnjcxnjrjj6h. Weirdly enough, the amounts being sent to the wallets are regular and around the same size before the attack.