Web Wallet and Desktop Wallet Vulnerability Exploitation and Analysis

With the rapid development of blockchain technology, encrypted assets have gradually become one of the investment methods for the public. The rapid growth of the scale of global encrypted assets makes the wallet an indispensable asset management tool for every encrypted asset owner. In the field of encryption, digital wallets are closely related to funds, and more and more people realize the importance of digital wallet security. The 28th DEF CON conference, known as the "Global Hacker's Carnival Party", has come to a successful conclusion recently. On August 9, 2020, Peiyu Wang and Minzhi He, security engineers of CertiK, delivered a speech at the DEF CON Blockchain Security Conference on the topic: Exploit Insecure Crypto Wallet (encrypted wallet vulnerability utilization and analysis) theme report. This article will take you back to review the insights of CertiK's security engineers on the security of encrypted wallets. A crypto wallet is a device, program or service that stores private and/or public keys. Because cryptocurrencies are virtual, encrypted wallets cannot be used to store real coins. But when we make a transaction, the encrypted wallet can use the user's private key to sign the transaction and broadcast it on the blockchain. There are different kinds of crypto wallets, such as software wallets and hardware wallets. This talk will focus on web wallets and desktop wallets. Speech Live Review: Encryption Wallet Introduction This is a typical web wallet interface, which is our CertiK Deepwallet wallet. Users can see the account balance and the option to send currency in this interface. Because this is a COSMOS-based wallet, it has a delegation function. When we talk about web application security, the top ten security vulnerabilities of the Open Web Application Security Project (OWASP) come to mind first. Here are some statistics on the top 10 security vulnerabilities of the "OWASP Top 10" among 27 web wallets surveyed by CertiK security engineers. CertiK security engineers found cross-site scripting attacks (XSS) in 3 wallets, and 2 cases are selected here for case study. Solana responded that the Ping Time was abnormal: it was caused by a webpage update, not a system performance problem: Jinse Finance reported that today Solana’s network status page showed an abnormal average Ping Time. Solana responded that the abnormality was caused by an offline update of the webpage, and was not related to the system The performance problem is not related and has no impact on network performance. The current average Ping Time indicators have returned to normal. [2022/11/20 22:07:40] We found a SqI injection vulnerability in a decentralized wallet. But its database only contains transaction data. Since the transaction data in the blockchain has been made public, it does not make sense to use Sql injection to steal data. Since there is no way to use SqI injection to achieve background code execution, in this case, this SqI injection attack has little practical impact. In addition, there is a loophole in the access authority of an API in this decentralized wallet. Unauthorized users can tamper with other people's 2FA settings, but there is no way to use this loophole to steal assets in other people's accounts. Many web wallets lack security headers, such as Content Security Policy (CSP) and "X-Frame-Options" headers, which can make the wallet vulnerable to clickjacking (Clickjacking) attacks. Some wallets still use outdated JavaScript libraries and Nginx/Apache servers with CVEs, and these vulnerabilities cannot be directly exploited. CertiK security engineers have not found any wallets that process data in XML format, nor have they found any wallets that have performed any deserialization operations, so no XXE and deserialization-related vulnerabilities have been found. Regarding logs and monitoring, there is no more information for the time being. Case 1: DOM XSS vulnerability of decentralized web wallet This is a case of DOM XSS vulnerability of decentralized web wallet. This wallet supports a single protocol and has all the basic functions of a web wallet. Vulnerable function This application will save the last access location: after the user unlocks the wallet with the password, it will jump back to the page before unlocking. The following figure is the code to realize this function. If you have experience testing web applications, you know that there is a high chance of DOM XSS vulnerabilities in this case, which is the case in this case. Opera browser and Yat have reached a cooperation to enable emoji-based web addresses: On February 14th, Opera announced that it has reached a cooperation with Yat, a platform that allows the creation of emoji-based URLs (URLs), and integrates all web addresses in Opera's browser. The operating system's emoji system allows Opera users to browse the web by entering a string of emoji in the URL bar. In addition, the two launched a campaign that will distribute 7 NFTs from the legendary NFT artist Fvckrender with a floor price of 2.89 ETH. Jorgen Arnesen, executive vice president of mobile at Opera, called Opera's "emoji-ification" a "new, easier and more fun" way to find and be directed to Yat pages. It is reported that rapper Lil Wayne's Yat page directs users to his record label website, and DJ Steve Aoki's Yat page directs users to his website. (Cointelegraph) [2022/2/15 9:51:20] DOM XSS DOM XSS requires Source and Sink. The Source is where the application receives untrusted data (user input), which it then passes on to the Sink. When a user visits this link, "window.location.search" will return  "?returnTo=/validators", and then "{returnTo}" will contain "/validators". Sink is where untrusted data from Source is processed, so Sink is here: "window.location.href", if the user enters "returnTo=/validators". The wallet returns to "/validators", i.e. goes to the validators page. If you enter "returnTo=javascript:alert(1)", an alert window will pop up in the browser. Report: ZB (ZB) ranked fourth in the world in Q3 2020 webpage visits: According to the 2020 Q3 Cryptocurrency Spot Exchange Industry Research Report recently released by TokenInsight, ZB ( ZB) ranked fourth in TokenInsight's 2020 Q3 global mainstream exchanges' monthly independent visits and browsing time list with an average monthly visit of more than 50,000 times and an average browsing time of about 3 minutes in the third quarter. [2020/11/10 12:09:43] Keystore and Password are decentralized web wallets. After a user creates an account or imports an account, both Keystore and Password are stored in local storage. Reading Local Storage Using JavaScript JavaScript can read information in local storage. In this case, the key-value data appears as "Hello World" stored in local storage. JavaScript can execute LocalStorage.getItem("Hello") to get "World". Using DOM XSS How to use the discovered DOM XSS vulnerability to steal Keystore and Password in local storage? In this URL below, it can read the content-ethexc of Keystore and Password and send it to the hacker's server. In the hacker's server log, you can directly see the Keystore content-ethexc and Password. Once in possession of this information, it is equivalent to controlling the user's account, can log in to their wallet and transfer money out. Announcement | ZB (ZB) launched the H5 mobile web version: According to the official announcement, ZB (ZB) has officially launched the mobile web version, and has now realized mobile terminal access and transactions. From 14:00 on November 28 to 14:00 on December 12, users log in to the ZB (ZB) mobile web version for transactions, and all transaction fees will be fully refunded on the premise of enabling the use of ZB to deduct fees. [2019/11/29] Repair method The repair method of the web wallet manufacturer is that whenever the user unlocks the wallet, the web wallet will always be redirected to the personal homepage, so as not to give the attacker any chance to insert malicious code. Case Two: Reflected XSS Vulnerability in a Hosted Web Wallet The second case study concerns a Reflected XSS vulnerability in a hosted web wallet. Hosted web wallets are servers that manage all private keys. To log into the wallet app, the user receives a one-time password via email. The wallet in this case supports 16 different currencies, has all the basic functions of the wallet, and an additional function called "twitter giving". API Operation The URL format of the API is similar to "/API/{endpoint}", for example, the API for obtaining user transaction information is "/apiUser/cloudTrans". If you access a non-existent API endpoint, such as "/api/test", the server will return a page with an error message, as shown in the figure below "Unable to parse the request". In addition, we found that the content-ethexc in the link appeared in the page returned by the server. This represents a signal: If there is no processing or encoding of user input in the background, it may be attacked by Reflected XSS. alert(document.domain) add the following content-ethexc after the API request of this wallet: <svg+onload=alert(document.domain)>”Dynamic | It is said that the web version and App are back online. Before that, the Bancor service was temporarily offline for 10 minutes. [2018/7/15] The application will pop up a window. This is a hosted web wallet, and the private key is managed by the server, so it cannot be used like the first A case like stealing user information directly. In this case, our plan is to try to exploit this vulnerability to hijack user accounts. Cookie After the user logs in, the session token is stored in the "PHPSESSID" cookie, and the special feature of this wallet is The reason is that this token does not have "HttpOnly". If the cookie is set to HttpOnly, the browser will prevent JavaScript from accessing the cookie. In other words, it can prevent attackers from stealing the session token in the cookie through cross-site scripting (XSS) .Get the session token Since there is no HttpOnly in the session token in this case, you can read the cookie content-ethexc and send it to your own server through cross-site scripting (XSS). After you get the session token, you can use it to log in Victim's account. Now that you have a session token, it's time to do a loot. The ultimate goal of hacking wallets is mostly to steal user funds, but there is a problem because 2FA is also required for currency transactions Verification. At this point, the hacker can neither reset 2FA nor disable 2FA, so the attacker needs to find a way to bypass 2FA verification. Bypassing 2FA verification As mentioned earlier, this wallet has a Twitter gift function: when the user When entering this function interface, it will ask the user what type of currency they want to give away, how much currency they want to give away, and how many people they want to give away. From this screenshot, you can see that the user can give up to 2 bitcoins. When the user sets up the gift activity, Others need to click to follow, Aite 3 friends and repost this gift tweet, as long as these steps are completed, you can go to receive the prize. But the problem is that this function does not require 2FA! Attackers can use reflective XSS, Steal the victim's session, log in to the victim's account, create a lot of gift activities, and then claim the rewards yourself. In this way, all the balance of the victim's account can be withdrawn. The repair method The manufacturer encodes the output in HTML, which solves the XSS vulnerability. At the same time, set "HttpOnly" for the "PHPSESSID" cookie containing the session token. In this way, even if the application is attacked by cross-site scripting, the attacker cannot directly steal the account's session token. The desktop wallet is a , running on Windows and Linux application. What framework do desktop wallets use? CertiK security engineers studied 18 desktop wallets, including QT (C++), Dot Net (C#), and Java, and the remaining 15 used the Electron framework. This part of the case study will explore the server remote code execution vulnerability of the Dot Net desktop wallet, and the client remote code execution vulnerability of the Electron wallet. Case 1: Server Remote Code Execution Vulnerability of Dot Net Desktop Wallet The following section analyzes a remote code execution vulnerability found in the desktop wallet. Let me introduce the background first: this wallet is a decentralized single-protocol wallet, written in C# language, using the Dot Net framework. It contains many common wallet functions, such as account management, transaction transfer and deploying/invoking smart contracts, etc. More interestingly, it also allows users to upload files to the server. This feature is not common in wallets, so we decided to investigate this feature further. As mentioned earlier, this wallet is based on Dot Net. If the code is not obfuscated, it is easy to obtain the source code through decompilation. This is exactly the case for this case wallet, so we were able to restore its source code for further analysis.

Tags：

Bitcoin Price USD