XmrBazaar (beta)

For those of you curious to learn more about the exploit, here's a walk-through. I made the video before desktop_monitor's publication, so bear in mind that a few of the proposed changes will be adjusted accordingly. Link below:
https://odysee.com/@Memoro_Vault:a/MEMORO-VAULT-1.0.4-EXPLOIT:3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

As promised, here's my publication of all the issues I found in the current version of Memoro vault. Nothing I'm publishing here is new, as I already privately gave all the less important issues, and the author of Memoro vault already found the most important vulnerability himself independently.

Before I begin with implementation specific issues, I want to talk about some more structural mistakes.

A dynamically growing proof of work will never work in an offline context. It is always technically possible to load the vault in a virtual machine, take a snapshot of that virtual machine, take a guess, and then restore from backup for as long as the guess is incorrect. This way, the vault will not "be aware" of previous incorrect answers. A more practical attack in this case is to edit the formula which determines the difficulty of the proof of work. A dynamically growing proof may or may not be possible in a decentraliced context. I am not entirely sure.

Furthermore, while the concept of a multi-layered defence sounds great, in practice it only reduces security. Suppose we have 128 bits of entropy in the answers to our vault. This would be a rock solid defense. If we then split our defense into two layers, splitting our answers into two batches with 64 bits of entropy, it becomes about 2^(63) times easier to brute force. At that point, it would be very doable for a powerful entity to crack the vault. I am aware that Memoro Vault does not split the defense in half. But still, splitting the defense reduces security. The only upside I can think of is that it's now technically possible to make adversaries unaware of what the second half of the questions are, in case that's important. This could be beneficial if you ask a question like "In what city did I run my first marathon", which gives an attacker the knowledge that you run marathons. But, if this were the purpose, then having only two questions in the first layer is generally not enough.

Finally, the validity of various html files is checked during execution. These checks are an attempt to make attacks more difficult, but having an open source project is incompatible with DRM. It will always be possible to bypass these checks. In the current version (1.0.4 I believe), this can be done by simply patching these checks out. The Memoro Vault author suggested that, instead of verifying these files directly and throwing an error if they do not match, they should make it so that the hash of recover.html is included in the password derivation key. Again, an attacker can bypass that, this time by hardcoding the method that computes the hash of recover.html to always return the hash of the official recover.html file.

Now, I would like to talk about the implementation specific issues.

Most notably, the full list of questions that is decrypted after getting through the first layer unfortunately contains a SHA256 hash of the answer to each individual question. This allowed me to brute-force each question individually. After getting the answer to all but one question, I validated that that question was the red herring with an external script and then proceeded to decrypt the vault using the official interface.

During the creation of the vault, a nonce is mined which satisfies a special condition. In this case, the Sha256(baseInput + nonce) hash must start with a bunch of zeroes. This mining step is unnecessary, and in fact reduces security. A more appropiate approach would be to generate a random nonce (using a cryptographically safe random number generator) in the range of 0 to some maxNonce. This would make the nonce uniformally distributed across the interval, whereas it currently is not. A uniform distribution is more secure, as an attacker has no way to limit their brute force to only check the most likely nonce values for any particular fullConcat candidate.

A related issue is one that should occur when no small nonce exists that satisfies the special condition. Though I have not confirmed this issue. For any particular difficulty, there is an associated maxNonce value. The recover page will not check nonce values greater then this maxNonce value. If it happens to be the case that no nonce value is found in the range between 0 and maxNonce, then the recover page will not be able to decrypt the vault. The chance for this to happen varies wildly between different dfficulties, as the maxNonce values seem to be chosen rather arbitrarily. At difficulty 9 there should be a 1 in 38 chance, and at difficulty 5 a 1 in 13859 chance. These were the lowest chances I found. This issue will automatically be fixed when the author implements the suggestion I gave above, which they have confirmed they will.

Next, there is a small issue where multiple different answers can lead to the same fullConcat string. This leads to a very small amount of reduced entropy. For example, these answers:
- - question one, Red Herring: "foo"
- - question two: "foo"

will give the same fullConcat string as these answers:
- - question one: "foo"
- - question two, Red Herring:: "foo"

A way to fix this is to first convert the answers into a json-list string, and then append them to the rest of the fullConcat. The fullConcat would then look like:
'...' + '["", "foo"]' + '...'
or:
'...' + '["foo", ""]' + '...'

Finally, I would like to make a feature request. I think it'd be great if the project could ship only .html files. It would be a lot easier to win the trust of people this way. This should be possible by making a wrapper html file, which embeds the other pages and lets them communicate via the postMessage API. But I am not entirely sure if this is possible.

I would like to thank the Memoro vault author again for hosting the bug bounty.
-----BEGIN PGP SIGNATURE-----

iQITBAEBCgB9FiEEI5y8sbyzseru+L2mXSYBo1Pxa8gFAmhlHYRfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDIz
OUNCQ0IxQkNCM0IxRUFFRUY4QkRBNjVEMjYwMUEzNTNGMTZCQzgACgkQXSYBo1Px
a8hBhgv/SUsmLbzkpP6BjkcwhcTh3o5BAQMiwQdsBZgoNwIdSdLz1+QzR0o5ah8k
SZbAE71w546Yokqtl8YMRmKFEZq5rqBygXZVp7w9yiJ7/PX9QST8J79GYN3/lcK1
4T7RyLAa3Sa2uLHR6NKfL7ki3DxaXu6/7VCIxfiFTwfZSKUOEvW5iFIUHy5W6aw5
uGfh+vsGJz8O8PyRrRZ8dBYL0IU/ev6UmfJRfDYxlch2Fb93UqmQxG88HP7HJ3hd
Ak2vRm3yfTkYlNLmcAQDWBsgGjgFyyXrDMF7AYh5pfK0ZIUKLBES1/M4czkjU7wc
zTyxuW5DyVJ2JXxOa6S3z7dF1CTXEv9ddrMbG+hcnRWjhAYMZrjlV8gPHhGNXzPO
rvaRQBVZOlBFFjbY6581pkaeECMTURsiY2JChBqLdPKO29K7qgfALDJJ1cyWpAvC
fBg2GOvp+EOl4SdbXP/HwO9LRhACNpQytI5XX9YuRuNTJUZg2r7pfXG1zbb2r/D/
UCOrNpZc
=DHqH
-----END PGP SIGNATURE-----

Desktop_Monitor,

Thanks for taking the time to look under the hood of Memoro Vault. While I am disappointed in the mistakes I made, I am happy the bounty served its purpose: to find and fix the problems with Memoro Vault. With that said, it seems I have one of two choices:

1. Allow you to publish your findings and thereby be fully doxed.
2. Choose to remain private but discontinue the project.

While I don't wish to be doxed, Memoro Vault is still a viable project with great potential and use cases. Many users will benefit from this idea. Please publicly publish your findings 1 week from now. I have signed a message on github as requested. Congratulations on claiming the bounty!

-Kasmaristo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have claimed your bounty of 10 XMR for opening your memoro vault. I want to thank you for offering such a generously large bounty and for genuinely having the XMR in the wallet.

I dug into your source code and discovered multiple cryptographic mistakes. I have no reason to believe these mistakes were malicious/intentional. With one of these mistakes (or technically a combination of two of them), I was able to find the answers to the questions in your vault. I now have the answer to every question, except for the red herring. I do believe it's also possible to obtain this answer, though.

I would like to publish the mistakes I found, but in doing so I would make it trivial for anyone to extract the answers to the personal questions in your vault. Thus, I believe I should give you a choice.

Either you can choose that I should not publish my findings. This would make it harder for anyone to extract your personal details from your vault. However, fixing these mistakes is unfortunately not possible without publishing them. Therefore, if you choose for this option I'd like you to sign a message saying you'll discontinue the project.

Alternatively, I can publish my findings. It seems smart to wait a week or so before publishing, as to give potential memoro vault users a chance to move their monero if they deem that necessary.

Either way, I would like you to sign a message confirming I have claimed the bounty and that the current version of memoro vault is not safe.

Regarding the allegations on github: I have seen no evidence of malware. But then again, I did not look at the executables. I only looked at the html+js+css files.

Again, thanks a lot for hosting this bounty! I appreciate it.
-----BEGIN PGP SIGNATURE-----

iQITBAEBCgB9FiEEI5y8sbyzseru+L2mXSYBo1Pxa8gFAmhbzCVfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDIz
OUNCQ0IxQkNCM0IxRUFFRUY4QkRBNjVEMjYwMUEzNTNGMTZCQzgACgkQXSYBo1Px
a8jDjQwAgJQ7WD1Jy7a6Ea03F1yOa+Ctx2wmignevLOR344qlkGl1Z6YY2JMLad6
nili3mLTnaAJJOLq3h+cVXwwLmFYD3UPkHKYVIBgBBmIUQFjJ83dlmgEb+ICWavL
tO2vydvCogqVCHjeTK7bTmUU5xxGEbfB7/0fwjklhA0zzCOdZ8wMHbF2uTGwxtcF
sTJLUXYzIouY71Lv2XpiQ3vuVI4HbxwLpHw1J2es7qB5tXWCX85hoASEa7V1K5wh
2vNAL1hpcdY4UXtVuw40OT0QggwrKorpIUMnaroBOVvjhzsHo61gb81bxIse1pTH
3gY3IcIfxQrvOK0ofP39Jhjiqx8HotX0nuN+wMTO/sInBl2/ijtIRxrLyb161+5E
vjVSjpCsB7fvVuCVWmkadilmCt8joni2DPZYRA4bs5Dv6xDX26bl3f8+eB/WhPIX
6E31k03/871G896iTzAmkzVyZvT5rhbXMGI4tNEpYJyB8SkRyyGRIrt1tLWaMkFM
20jrBqyD
=0K7N
-----END PGP SIGNATURE-----

Also, I have received some feedback doubting the validity of the XMR stored within the bounty vault. I assure you, it's all there. However, in our space you shouldn't have to trust anyone. Don't trust, verify. With that in mind, does anyone have any ideas on how I can PROVE the status of the funds within the vault file? My only thought for now has been to screen record the entire process while blurring out the seed phrase. Any better ideas?

For anyone curious as to the status of the malware allegations, you can read about it here:
https://github.com/Kasmaristo-Delvakto/memoro-vault/issues/1

There is no malware and the code, while not perfect, will withstand scrutiny. All current allegations are unfounded.