Even if you are careful, you may still fall victim to an attack. Here is a demonstration of how such an exploit works.

Step 1: initial contact

After a conversation on LinkedIn, an individual (the attacker) sent me this message:

The assignment looked fishy. I requested more information, but they refused to give any until I completed their task. At this point, I had no interest in working on this task but I knew I was going to find something cool in this repository.

Step 2: investigation

After cloning the repository in a virtual machine, I started looking at every single file carefully. My first assumption was that this project had been compromised by a malicious package (in the package.json or package-lock.json files). That would be an easy way to trigger an exploit while hiding the payload code. Here is the process:

• Publish a malware package on npm

• Add the malware package as a dependency to this project

• Trigger the malware when running the project

Unfortunately, I did not find any suspicious package. However, I did find an interesting hint.

The package.json has a dependency to the fs (filesystem) package, which is strange since fs is a built-in node module: there is no need to install it as a dependency. This was probably a mistake. But it got me thinking, the filesystem is the place to look for private keys or passwords.

A simple search for fs in the project revealed what I was looking for.

Step 3: the payload

It seems there is a require(“fs”) somewhere in this file…

I did not see it at first, but the first line is just that long. If we scroll a little bit more…

Finally! This appears to be the exploit payload. This could have been innocuous minified code, but only malicious actors would conceal their code this way. Let’s analyze what it does.

Step 4: analysis

As expected, the exploit code is obfuscated but we can still analyze it. Without executing it. To deobfuscate JS code, here are some simple steps we can take:

• Pretty print: use a tool such as prettier to clean up the code. A pretty printer will format the code to reintroduce spaces and indentation where needed, to increase readability.

• Find the main obfuscating primitives: in this case, strings are encoded with base64. It is a quite common method to hide variable names or IP adresses.

• Write a script to replace strings and rename variables: input_obfuscated → script → output_deobfuscated. This allows to perform changes efficiently on the whole payload. The less manual work, the better.

• Do manual edits in the obfuscated source, if necessary: For example, to rename variables manually, or to change the formatting. In that case, their obfuscator tends to put multiple statements on the same line (separated by commas). I did manual edits to make the code more readable.

After some time working on the code, it was easy to understand how the exploit works. It is triggered when the user runs the application (a Node web server) and their goal is to steal your private keys, wallets, passwords and more. Here are the original files for reference: Obfuscated payload, Unobfuscated payload

Luckily, the obfuscation here was rather simple. They could have employed stronger techniques such as Control-flow flattening or introducing dead code.

And some code snippets from the exploit.

This stage of the malware relies on Node to access the victim’s filesystem. Its success depends on whether or not the host gave enough permissions to Node to access restricted directories such as the home directory, and system files. Running this script with elevated privileges probably means game over.

Step 5: going deeper

At this point, I had seen enough to be convinced this was an exploit attempt. However there was more: this payload had a second stage that downloaded and ran Python based malware with more elaborate features to steal user credentials.

The second stage downloads a Python program (and even downloads Python if not available on the victim machine!). Below is the full code of the second stage:

Again, this is an obfuscated payload but its structure is much simpler. The base64 encoded exploit code is decoded, and then executed. Here’s the decoded version:

Reference: 2nd stage payload

This is a client for downloading two Python based malwares. They are quite long, and analyzing them is out of the scope of this research but here are some features of the malware:

• Keylogger

• Clipboard logger

• Shell into the target machine: a wildcard to control the target and possibly send even stronger malware

• Stealing passwords/credit cards

Reference: First, Second

Closing words

Working in the blockchain space requires extra caution to safeguard your assets.

This is especially true if you own or earn crypto. Do not run unverified Git repositories. If you must, use a virtual machine.

However, manually inspecting every file we download and run is impractical.

The community has to think about more automatic ways to detect exploits. Or make sure Node is sandboxed properly. That is also why I prefer Deno’s security model, but it is not always practical to use either.

By looking for a fingerprint of the payload on Github, we can see that multiple repositories are infected. Probably forks of a similar exploit attempt.

If you think you have been exploited by this or need more details, you can reach me @moru on Farcaster.

https://warpcast.com/moru

Hack safely!

• NFT art: Proof of Ownership of a digital image

• PFPs: similar to the above, except they focus on group memberships and social media persona (e.g. if you own a pfp, you are part of a club)

• Rare in-game items: cosmetic or gameplay items/characters

• Trading card games: Sorare, Gods Unchained, etc…

NFTs offer new ways to make (or lose) money: users hope to gain from flipping tokens on online marketplace venues. Developers use them as a way to raise money. Financial incentives are the main driver of non fungible tokens on public blockchains.

Selling digital items is not a novel idea: for instance, the Steam community market is popular and well-known compared to obscure NFT markets.

# NFT sales (28/07/2023 - http://opensea.io/category/gaming)

Rank Collection         Floor Price Volume (7d)
-----------------------------------------------
1.   HV-MTL             0.54 eth    105 eth
2.   Otherdeed Expanded 0.36 eth    84 eth
3.   Parallel Alpha     0.20 prime  70 eth
4.   Skyborne           0.02 eth    63 eth
5.   Otherside Koda     4.09 eth    56 eth

# Steam market sales (28/07/2023 - http://steamfolio.com/Popular)

Rank Name                     Price   Volume (7d)
-------------------------------------------------
1.   Dreams & Nightmares Case $ 1.44  $ 734 276
2.   Revolution Case          $ 1.32  $ 554 679
3.   Fracture Case            $ 0.65  $ 383 300
4.   Chroma 2 Case            $ 3.47  $ 276 333
5.   Recoil Case              $ 0.59  $ 265 461
...
7.   MOUZ (Holo) | Paris 2023 $ 16.95 $ 209 258

• NFTs trading volumes seem lower than Steam markets’. However NFTs are decentralized and can be traded on multiplie market places while Steam items are traded on a single centralized marketplace. A fair comparison would attempt to aggregate volumes from multiple trading venues.

• The main take away: the average price of a popular Steam item is lower than the floor price of a NFT gaming token.

So NFTs tend to be sold at a higher price, akin to luxury items. Most likely because they have a higher perceived value. This is of course not representative of their intrinsic value: most NFTs have close to zero utility and their value is extremely inflated. Hence the typical price direction of an NFT is to drop over time to pennies.

Reddit Collectible Avatars strategy (17M holders) is to sell cheap NFTs to maximize user adoption. While some unique pieces are expensive, they are following the pricing of a typical mobile game in-app purchase. Testing the technology on a large scale to familiarize users with crypto wallets is a clever strategy (→ Dune).

Closing thoughts:

• To aim towards mainstream adoption, most NFTs should be cheap. Luxury NFTs can be expensive, but if playing the game requires paying for an expensive token, it is not going to capture a ton of users.

• NFTs creators should aim towards creating useful items, and leverage the community aspect of their collection. How to value a decentralized proof of ownership?

  • Many creators design images and sell them as NFTs. What is the benefit for users compared to buying the image directly? Probably none, but no one would have bought the .jpg either. Some users just buy NFTs for fun and creators are tapping into that liquidity.

  • Holding a token can be used to give access to exclusive features such as in-game skins, access to a private community, shopping discounts, and more. It’s easier to value a NFT when there’s a service attached to it.

• Freedom of trading: the point of NFTs is to be able to trade them on public marketplaces with no third party. If NFTs are not tradable, then it would make more sense to implement them on a centralized server, unless it’s a feature, like tokens bound to a wallet.

Similar to the web, money took different forms throughout history, notably since the age of the internet. With digital money, customers pay online for goods and services. With the advent of blockchain technology, digital cash can now exist on public decentralized networks. Blockchain is also a less popular but viable alternative for private corporate applications, NFTs, tokenized stocks or central bank digital currencies (CBDCs).

Money had to reshape itself to evolve with technology but its usage stayed roughly the same. A (digital) cash transaction involves sending value to a third party and receive something in exchange. This transaction has to be processed by a large number of entities, whether it involves centralized currencies or cryptocurrencies.

This is a static use, reminiscent of the old web. But could we envision a future with dynamic, programmable money?

While money is not programmable by itself, most people are familiar with some forms of programmability, supported by web services and APIs. For instance, automatic cash transfers. Scheduling a transfer every month to a savings account is a form of programmable money. Or paying for a subscription service. In those two scenarios, a third party script has the permission to spend users’ money on their behalf.

Cryptocurrency is by and large used for trading, speculation and savings (hodling), but not really for payments. Nonetheless, Bitcoin is a thought provoking experiment that enabled many engineers to rethink about new forms money for the digital world.

In the physical world, paying with cash is second nature. In the digital world, payments require users to create accounts (or wallets), use login credentials securely and deal with KYC, 2FA authentication and more. A lot of important steps for good reasons, but quite cumbersome for low value transactions.

Programmable money is defined by two main elements: a transaction value and how it should be spent. For example, a digital bank note, signed, and issued by anybody holding a wallet. Attaching a script to money opens up many design possibilities.

• With such a system, reimbursing $10 to another party is simple: create a digital bank note that can be spent only by this person, copy and send it to them over a text message.

• Want to use a paywalled API? Without creating an account, send a digital cash note to a “subscribe” API REST end point to receive an API key.

• Monthly subscriptions could be pushed from a wallet instead of pulled from a bank account.

These theoretical use cases can be implemented with public blockchains and centralized finance as well, as long as an open standard for APIs and wallets exists. CBDCs (governments stablecoins) might be that new open standard for traditional finance. The multiplication of “light” banking apps in the last few years shows that this is a space with large growth potential and a need for innovation.