Recently, I became aware that a user had lost a significant amount in Monero via Twitter.
In specific, the tweet was from the afflicted user, lamenting the complete theft of their funds from the website 'xmrwallet.com'
Disclaimer: Do not visit this site unless you know what you're doing (i.e., know how to sandbox an environment properly to avoid instances of 'escape', which will inevitably be met with subsequent escalation of privilege shortly afterward)
Below is a screenshot of the tweet from the afflicted user: (https://mobile.twitter.com/singhsoro/status/1303001026849435649)
Corroborating This Story
Sadly, there are enough charades, 'pranks', and "trolls" in the crypto community that one would not be unreasonable to ask themselves
"How do we know for sure that this actually happened?"
Corroborating From My Own Observations
The website that the user mentioned in their tweet [xmrwallet(.)com], is one that I had marked down in my notes just a couple of weeks prior to this user's unfortunate experience with the website.
I stumbled upon it while looking for Monero ecosystem resources to study form & provide to other Librehash community members (as a service since we are a non-profit).
When I had initially stumbled upon the xmrwallet(.)com website, there were a few red flags that caught my attention initially, which were:
The outdated codebase (which we'll get into later on)
The erroneous claim that their wallet site could ensure that the entire process of creating a Monero wallet to transacting on the blockchain itself could be done offline. With Monero, this is especially difficult because part of the mechanisms that provide the "stealth" of the protocol are dependent upon information provided by the chain itself. This is one of the main reasons for why Monero's GUI wallet duos as a Monero node as well (hence the syncing process necessary for the wallet app).
The presence of "login" options on the site were erroneous in my opinion. How would one "sign up"? Wallet creation (on all blockchain protocols) is a stateless event, so there is no 'logging in' that occurs. And if one's wallet balance is being pulled after providing their mnemonic phrase / private key / etc., then, without doubt, it can be said that an external contact (to the blockchain via API in most cases), must be over the wire (not client side). This is not a problem - but the failure to divulge this is.
Independent Community Confirmation
The aforementioned oddities prompted me to see if there were any external, 3rd-party sources that had appraised the site (whether community members or an 'official' source such as the Monero community hub).
After searching for a brief while, I stumbled upon the following Reddit thread (link = https://www.reddit.com/r/Monero/comments/c03u56/any_selfhostable_monero_web_wallets/er220j5/):
The photo above shows a user inquiring about the viability of the wallet in question.
Notably, the first response that they received was from a user that apparently was also unaware of the nefarious nature of the site itself (or perhaps they were all too aware of its nature and were simply attempting to socially engineer the individual into trusting it with their funds).
Fortunately, however, it appears that others in the Monero community were able to provide adequate warning to the user (with reasonable points that are worthy of consideration).
Taking a Look at Some of the Excellent Responses That Were Given By Other Community Members
Unfortunately, it appears that this information was not widely available as I was unable to find another thread that gave users comparable information.
Sense of Personal Responsibility (Author's Note)
My biggest regret is that I did not publicize the existence of this website earlier.
Perhaps if I had done so before, then that would have spared the user at the beginning of our article from suffering a -$20,000 loss as they reported on Twitter.
Part Two: Examining the Site Itself
Disclaimer: We strongly recommend that users visiting this site take necessary precautions to ensure that their underlying devices are 'hardened' in some way against compromise ; at the very least, this site should not be accessed on the same machine that one uses regularly for general work purposes)
Below is a picture of the website (what you'll see when you arrive there):
As one can see the website is fairly mundane but there are a few things worthy note here already.
Specifically, the pop-up message that is given to users as they log in, which states:
"XMRWallet is an open-source, free monero wallet which allows you to send and receive Monero instantly on the blockchain. All while remainingr in control of your coins & your keys.
"When you generate a ne wallet, login, send or receive Monero, everything happens locally in your browser. Your seed is never transmitted, received or stored. That's why its imperative to write, print or save your seed somewhere safe. If you lose your seed, your account cannot be recovered."
Then there are instructions for apparent 'wallet generation', followed by two final messages, which state:
- "Import seed sync approx. 25 minutes."
- "New wallets can be used immediately."
If the wallet "allows you to send and receive Monero instantly on the blockchain", then there's no way that "everything happens locally in your browser" as we explained prior.
"Import seed sync" is not made clear. However, based on how Monero works, this seems to suggest that an entirely new Monero node would be spun up per user account (i.e., the 'sync' time is just for the Monero blockchain to sync with one's wallet up to the height that it was at, during the former transaction)
Also, that final statement:
"New wallets can be used immediately"
Makes zero sense.
Either a wallet has funds in it or not.If the wallet is new, then it has *no funds in it - thus, using it "immediately" is out of the quesiton in that case.
Seeing if We Can Match the Code Up With the Repo
According to the main site, the project is "open source" - with a link leading to its hosted code repos.
Specifically, we're going to enter into the 'website' repo.
Upon arrival, here is what we are met with:
Curiously, in the project's root view on GitHub we can see the last updates were made approximately two years ago - which is quite some time (especially when we're talking about apps with .js dependencies attached to them).
Typically, its smart to stay away from unmaintained projects as there could be a number of unmitigated vulnerabilities in the codebase that have not yet been accounted for.
This stands out as odd because:
A) This app claimed to be 'client side' (inaccurately - at that, but still)
B) This is supposedly a "wallet app" (site & app used interchangeably here)
Brief Look at the Wallet Generation Steps
From 'philipshen13' on Medium (whom does an excellent job at breaking down, step-by-step, exactly what is required for the generation of the Monero address / keys that are used in concert w one another to facilitate the privacy protocol's design):
Yes, that's a lot. Our apologies.
However, the fact that it is a lot, by itself, should give users the intuitive sense (at the very least), that there's a hell of a lot more that goes into the orchestration of Monero addresses than what is presented on the site (from a bird's eye level).
Not Blaming the User
To be clear, it would be preposterous to blame the end user for making the very understandable mistake of confusing the xmrwallet(.)com website with a legitimate Monero website.
The word 'obvious' (above) was used to refer to the simple observation (following the shelling out of the generation of a Monero address) that we should be expecting to see more than just an 'app.js' + 'monero.js' scripts to orchestrate with one another in order to produce a viable Monero address.
Major Red Flag in the Code Here
Specifically, found under 'select2.js' (included within the same family of .js files as what we saw in the directory that we were just in).
Let's check it out just one more time below:
What's the Issue Here With 'Select2.js'?
By itself? Nothing.
However, this should not be present in the context of wallet address generation.
This is a million times more true when considering the fact that the site boasts that the entire process takes place "client side".
Catchup: Low down on 'AJAX' Requests
Ever been to Google / YouTube and started typing in the search bar and suddenly, results start popping up?
As you continue to type - the results may even update themselves with refreshed results that provide suggestions based on what you have typed in at that point in the search box.
More Than Likely Every Single Soul Reading This Has Experienced Such a Phenomenon
That's AJAX (in a nutshell, for the most part).
Specifically, 'AJAX' requests refer to the idea of being able to respond / capture / extact / transform / manipulate user feedback (etc.), without having to refresh the page (i.e, have the user hit the 'submit' button after each and every single letter that they type into the box in order to obtain updated results on what's going on).
Why This is Bad For a 'Browser-Based' Wallet Address
Even if one were mkaing API requests to the blockchain - any and all calls of this nature should be coded in a very clear & transparent manner for the end user so that there are no 'surprises'.
However, this was not the case here.
Wallet generation is a STATELESS process in blockchain!
"What does that mean?"
That means that one shouldn't need to ever access the internet if ALL that one wants to do is generate a wallet address.
I can't think of any reason for why (or how) API would facilitate the process of key generation (because there are none and cryptography is a well-established field of professionals that have broken this shit down to a tee over the years).
One Last Look at AJAX Requests
I know that we're beating a dead horse here - but it is really imperative that users stay away from ANYTHING that claims to be a "client side" anything that has AJAX encoded in their webpage / app / platform.
These two concepts ('client-side' and 'AJAX' are not congruent with one another!)
Useful Place For Reference and More Reading / Study on the Topic For the Nerds: https://select2.org/data-sources/ajax (notably this source is from the documentation of the 'select2' js module that we saw in the 'xmrwallet' source code on GitHub).
As we continue forward with this review, we're going to see that the 'data sources' one can tap into using AJAX libraries will play a major role in the assessment of the xmrwallet(.)com code when we get back to our direct analysis of the site.
As we can see below, it takes little imagination to see how this could be used to exfiltrate user entries into various 'forms' + search bars:
Notice how this script specifically involves calls to remote APIs (or databases)
But there is no real use for including this in one's project unless there are clear cut plans to integrate it in some facet (and, indeed, as we move forward in this report - we're going to see that this code was called in some interesting spots)
Contrasting What We Saw Above With OpenMonero's Repo
OpenMonero is the open sourced backend of MyMonero.
It is a trusted and accepted resource for the Monero community (which means that it has been vetted by various community members that would out it for the 'trojan horse' it is, if that were the case).
Beyond that, one must build the code themselves to even use the project, which is considerably safer (versus even downloading and spinning up code based on instructions for execution, too).
"Why is that?"
Executing open source code is like throwing something you got from the store in the .
Sure, it should be good. Also, if there were something wrong with it, you would hope that there would be enough people to sound the alarm bells (after, unfortunately, falling ill - yet falling ill before you), to where you would be able to avoid that debacle altogether.
However, there is a strong non-zero chance that this happens at any given point.
Building the Code is like simply being handed a recipe and then being told to gather the ingredients and cook the meal yourself based on the instructions that were given.
Can you still be compromised that way?
Sure. But is it likely? Probably about as likely as you getting all the ingredients for a given recipe, cooking it yourself without realizing that you were actually concocting a massive dose of cyanide or some other lethal drug for yourself (so...unlikely).
Here's their repo btw: https://github.com/moneroexamples/openmonero
Notice the Open Explanation of Any and All API Calls That Must Be Made
As one can see below, there's really no reason to instantiate AJAX into a project / web page that does what the bogus Monero wallet (xmrwallet) purports to do.
Final Ingredient (asm.js)
The presence of the 'asm.js' script in the site's code is also a bit concerning as well.
Without going too far into what this is used for, just take a look at the excerpt below from a great netsec / malware info site that describes the dangers associated with illicit Web Assembly use in modern browsers:
As one can see in the highlighted section above, once there is compromise of this nature, it becomes very difficult to mitigate / escape it later (thus, general workflows should be advocated and [hopefully] adopted in the future moving forward so that these incidents do not continue to happen).
Back to the WebPage
To humor the process (and to discover a bit more since we're already this far down the rabbit-hole), I decided click no the "create wallet" option to see what interesting scripts / actions I could capture on the page from there
Random note - if you want to do something like this, then strongly consider getting a (non-headless) Selenium browser instance
Upon doing so, I was taken to the "create" page (despite there being a prompt that appears at the top of the page to reward me for successfully creating the wallet address already...)
Taking a Look at the Sources (with a special look at the WASM)
Here's a 'helicopter view' of the sources that are loaded up on the page that I visited (after clicking on 'create Monero wallet address')
Check it out below:
Important to Note!
The browser that's being used here is pretty secure by default (due to a number of tweaks + mitigations that were instantiated within it), thus there are numerous sources that were caught and prevented from loading.
We'll get to that later
Let's check out the 'WASM' for now:
Thanks to some of our mitigation practices, we managed to remain safe (shoutout to 'CORS').
Google Tab Manager Calls
One that I observed that was really weird with this XMR domain was the constant calling of Google Tag Services.
Take a look below:
This sent me on a quick Google search hunt to get an answer for the question of:
'What purpose would a malicious script have for calling up 'Google Tag Manager'?
Fortunately, I didn't have to look too far before findiong a sufficient answer (courtesy of 'Sucuri'; https://blog.sucuri.net/2018/04/malicious-activities-google-tag-manager.html)
Revisiting the Site Without Mitigations
To simulate a more realistic user experience, let's see what its like visiting the website without a ton of resources at our disposal to mitigate
Doing so led us to the discovery of a truncated response (more than likely holding the payload being sent back)
API calls nested right at the top of the payload (who knows what else is being called here; we'll have to go to a legitimate threat analysis site to ascertain information )
Which is exactly what we did.
Hybrid Analysis Report
One of the more reputable online sandbox providers out there, Hybrid Analysis has built its name off of providing extremely reputable findings about whatever file string / URL / URI that you feed into it.
'JIT' function detected (stands for 'Just in Time' cmputing) .
Some Research That Outlines How This Works (JIT)
Essentially, this is a means of compromise that involves grabbing a bit of the payload from various locations (after the page has already been loaded) with the 'end game' being sending the payload back to the user of the site (unbeknownst to them, of course). '
Hybrid Analysis Results (Among Some Additional Threat Scanners)
For the final part of our act, we're going to visit a great site, called:
Upon arrival, the instructions are pretty straightforward for what needs to be done, but there doesn't appear to be a culture of "innvoation", you could say.
Taking a Look at Our Configured Settings
Below, we have the initial settings that were used for this:
These are the other 'default' options:
But we're going to tweak a couple of them first before running this analysis:
Now, we just wait then get back to it in no time.
Check out how even despite the malware ont he site (which we'll see soon), there is a failure of several different AVs (all of them listed on this site) to pick into.
Never to Fear - A Closer Analysis of the Code Shows the Nefarious Origins and intentions
Let's take a look forward at the results genreted by 'Hybrid Analysis', specifically.
Presence of Mutex(s) Discovered
Not sure how to write that out in "plural", but check out the following that was also included in the Hybrid Analysis report too :
Cause For This Behavior
Typically, malware / viruses / payloads will undergo several mutations in order to avoid detection from modern AV engines.
Indeed, if we check out the results that we received back from Hybrid Analysis, it appears that each and every single one of the AVs that it ran the website through had rated it as positive
So - once again - for the poor fellow that did fall prey to this site, know that 80+ other anti-virus engines would've failed too. And many would argue that the latter failing is substantially less palatable (or deserving of empathy) than what occurred to the poor fellow that found themselves victimized by this fairly clever scheme.
Clean Files Were Dropped Here as well
'What does that mean?'
This means that files that the AV (anti-virus engines) had dubbed as 'clean' were "dropped" later by the site (for no reason).
"Process Launched With a Changed Environment"
This is yet another troublesome observation that was made by Hybrid Analysis.
Yes, it Gets Worse (Way Worse)
Finding the Actual Malware
Ta-da ; here it is:
As well as the 'contacted hosts' (so much for client-side, right?):
Also managed to find some "hits" between 'Hybrid Analysis' and 'OTXAlienVault' (the latter serves as a **really reliabel resource for anlayzing file hashes / URLs & other submitted information from various malware detectors / information aggregators).
Below is are the file hashes (respectively) for SHA1 & SHA256:
Below is the corresponding information provided by 'OTXAlienVault':
Based on what can be seen above, its plausible to suggest that the website in question may have simply been compromised.
However, when considering what we found in the Git Repo itself as well as the other inaccurate information on the site (coupled with the fact that the 'support' / 'contact us' section specifically states that the site has definitely been updated in 2020), it is really hard to not put this squarely upon the operator(s) of this site - but I would recommend for users (anywhere) to NEVER these folks