[00:03.960 --> 00:11.860]  Yep, cool. So, hello everyone. Welcome to our talk and thank you for the introduction.
[00:11.980 --> 00:17.540]  And in this talk, we'll be talking about how we're exploring secure cryptocurrency wallet
[00:17.540 --> 00:23.520]  applications. So, my name is Pei-Yu Wang. Here's what with my colleague Ming-Jie He.
[00:23.780 --> 00:29.000]  We're security engineers at CertiK. So, CertiK is a blockchain security company.
[00:29.000 --> 00:34.140]  We provide a variety of security services such as smart contract audit, chain audit,
[00:34.140 --> 00:39.300]  and penetration testing. I'm personally responsible for internal security review
[00:39.300 --> 00:44.620]  for our own product, as well as the external pen test, focus on wallet,
[00:45.320 --> 00:51.300]  Explorer, Exchange, and Dapp. So, outside of client work, we also do security research on
[00:51.300 --> 00:56.920]  different applications in the blockchain space. And that's how we come up with this talk.
[00:56.920 --> 01:04.660]  We also do bug bounty huntings over the weekend when we have time. This is the first time we speak
[01:04.660 --> 01:11.160]  at Defcon Blockchain Village. Thank you so much for having us here. So, what is crypto wallet?
[01:11.160 --> 01:16.640]  I'm sure most people here know what crypto wallet is, but in case someone don't. So,
[01:16.640 --> 01:23.580]  crypto wallet is a device, a program, or a service that stores the private key and the public key.
[01:24.320 --> 01:30.920]  So, crypto currency is virtual, like a wallet cannot physically hold the coins. And when you
[01:30.920 --> 01:36.280]  want to do the transactions, the wallet applications will use your private key to sign the transaction
[01:36.280 --> 01:42.400]  and broadcast that to the blockchains. There are different forms of crypto wallets. There's
[01:42.400 --> 01:47.680]  software wallets and hardware wallets. In this talk, we'll be focused on web wallet and desktop
[01:47.680 --> 01:54.680]  wallets. We believe there's two core functionalities for crypto wallets. One is account
[01:54.680 --> 02:00.800]  management. It allows users to create accounts, import accounts, and the other one is make
[02:00.800 --> 02:10.720]  transactions. It sends and receives coins. And for certain protocols, it will have additional
[02:10.720 --> 02:18.060]  features, such as for Cosmos-based wallets. They will provide the stacking features,
[02:18.060 --> 02:22.520]  allow users to delete coins to validators, and claim rewards.
[02:23.500 --> 02:28.860]  And looking at different wallets, we also find some, I don't know how to call them,
[02:28.860 --> 02:34.020]  maybe call them fancy features. For example, you can view newsletters in a desktop wallet.
[02:34.020 --> 02:39.860]  You can add third-party plugins in a desktop wallet. You can create a coin giveaway on Twitter
[02:39.860 --> 02:46.120]  in a web wallet. And there's one desktop wallet, the backend server allows users to upload any
[02:46.120 --> 02:52.100]  type of files to the backend server with the API. And then there's a desktop wallet that uses the
[02:52.100 --> 02:57.660]  WebView to implement a browser in it, which is mind-blowing. I don't know why people would want
[02:57.660 --> 03:05.440]  to use their desktop wallet to be as a browser. So we look at 45 different wallets, and we kind
[03:05.440 --> 03:12.680]  put them into two categories. One is host wallet. Host wallet is that the server manages your
[03:12.680 --> 03:18.960]  private keys. If you want to use the wallet, you need to authenticate, log into the application,
[03:18.960 --> 03:24.700]  authenticate with the server, and the server returns you session tokens or JWT tokens.
[03:26.660 --> 03:31.040]  Those secrets will either be stored in cookies or local session storage.
[03:31.040 --> 03:34.380]  And so most of what I will look at are decentralized wallets,
[03:34.380 --> 03:39.440]  which means the user manages the private key, the store, the key store, and their passwords.
[03:39.960 --> 03:44.080]  And after users create an account or import an account,
[03:44.080 --> 03:49.140]  those things will be stored in local or session storage or in the JavaScript variables.
[03:51.240 --> 03:58.420]  So in the 45 wallets, 27 of them are web wallets and 18 of them are desktop wallets.
[03:58.420 --> 04:03.960]  We think the logo for those projects are really cool. So we collect them and put it here.
[04:05.800 --> 04:12.300]  So let's start with the web wallet. This is a typical interface for a web wallet. This is our
[04:12.300 --> 04:20.060]  30-bit wallet for 30 chains. In this interface, you can check your balance. It has the UI for
[04:20.580 --> 04:26.720]  sending tokens. And this is because it's a cost-based chain. It has the staking feature as
[04:26.720 --> 04:32.940]  well. So when we talk about web applications security, the thing that comes to my mind is
[04:32.940 --> 04:40.020]  OAuth's top 10. Here's some statistics on OAuth's top 10 in the 27 wallets we look at.
[04:40.020 --> 04:46.720]  We find Crystalscripting in three wallets. We'll do a case study for two of them. We find one
[04:46.720 --> 04:54.060]  SQL ingestion in a decentralized wallet. So the database only contains those transaction
[04:54.510 --> 04:58.740]  data. And because the transaction data in blockchain is already public,
[04:58.740 --> 05:05.740]  and we don't have a way to escalate that SQL ingestion to, say, command code executions.
[05:05.740 --> 05:13.940]  So that SQL ingestion is kind of just useless in this case. We found one broken authorization.
[05:14.240 --> 05:22.320]  An unauthorized user can mess around with other people's 2FA settings. But we cannot use this
[05:22.320 --> 05:29.360]  vulnerability to compromise a user account. A lot of web wallets are missing security headers.
[05:29.360 --> 05:35.900]  For example, CSP, the content security policy, and expert option headers, and make the wallet
[05:35.900 --> 05:43.760]  vulnerable to clear-checking. We see a few wallets using outdated JavaScript libraries,
[05:43.760 --> 05:51.640]  or outdated Nginx, Apache hosting, but we are not able to directly export them.
[05:53.020 --> 06:00.320]  So we have not seen any wallets dealing with XML, or find them doing any type of
[06:00.320 --> 06:08.780]  DCR audations. For the login and monitoring, we just don't know. So jumping to the first case study.
[06:09.520 --> 06:17.600]  So this is a DOM SSS in a decentralized web wallet. The wallet supports single protocols.
[06:17.600 --> 06:24.260]  It has all the basic functionalities for a wallet. It doesn't really have any fancy things there.
[06:24.940 --> 06:31.340]  So the vulnerable feature is the application saves the last location, the user visit, and
[06:31.340 --> 06:36.500]  it redirects the user to that page after the user unlocks his wallet with his password.
[06:36.900 --> 06:44.400]  In this URL, it will redirect the user to the valid data page after the user unlocks his wallet.
[06:44.400 --> 06:52.480]  And here's the co-implementations. The object return to equal to the parsing result of the
[06:52.480 --> 07:00.740]  window.location.search, and the return to variable pass into the window.location.href.
[07:01.000 --> 07:06.880]  If you have some experience about web app testing and stuff, you might realize this
[07:06.880 --> 07:15.960]  might be vulnerable to DOM SSS. And that is the case. So DOM SSS requires source and sync.
[07:15.960 --> 07:22.500]  So source is the location where untrusted data, the user input, is taken by the application and
[07:22.500 --> 07:29.000]  passed to the sync. So when user visits this URL, the window.location.search will return
[07:29.000 --> 07:34.320]  question mark, return to equal to slash validators. And the return to object will later
[07:34.320 --> 07:42.740]  becomes, will contain the streams slash validators. And here's the sync. Sync is the place
[07:42.740 --> 07:50.000]  where untrusted data coming from the source is actually getting executed. So the sync here is
[07:50.000 --> 07:58.900]  the window.location.href, and it's taking the user input inside the return to. So when it returns to
[07:58.900 --> 08:04.600]  slash validators, it goes to slash validator page. But if it's JavaScript, JavaScript,
[08:04.600 --> 08:11.940]  colon alert one, it's going to pop alert in the browser. So we have the DOM SSS here,
[08:11.940 --> 08:21.620]  but how can we export this to causing bigger damage? So this is a decentralized web wallet.
[08:21.620 --> 08:28.860]  The key store and the passwords are stored in the local storage after user creating account
[08:28.860 --> 08:34.780]  or import his account. So if you're not familiar with local storage or JavaScript,
[08:35.660 --> 08:42.540]  so JavaScript is able to read the content inside the local storage. In this example,
[08:42.540 --> 08:48.080]  there's a key value pair, hello world store in local storage. JavaScript can just do local
[08:48.080 --> 08:56.960]  storage.get item, hello, and we just get the contents. So now the attack plan is to steal
[08:56.960 --> 09:02.140]  the key store and password in the local storage with the DOM SSS. And that's exactly what this
[09:02.140 --> 09:09.660]  payload does. It reads the content of the key store and password and sends it to my web server.
[09:09.700 --> 09:16.600]  And in my SS log, I can see the key store contents and the passwords. And after I have those
[09:17.280 --> 09:22.940]  contents, I basically just own the account. I can use those information, log into the wallet and
[09:22.940 --> 09:32.120]  transfer all the money out. So for the fix here, the fix here is after user unlock his wallet,
[09:32.120 --> 09:38.500]  I just always redirect to the portfolio page. It just doesn't give the chance for attacker
[09:38.500 --> 09:46.320]  to inject any payloads here. So the second case study is reflect SSS in a host web wallet.
[09:46.320 --> 09:53.420]  So it has host web wallet. The server manage all the your private key. And to log into the
[09:53.420 --> 09:59.380]  applications, you will use your email and the one time passcode you receive in the email.
[09:59.520 --> 10:05.020]  The wallet supports 16 different coins. It has all the basic functionalities and one additional
[10:05.020 --> 10:11.940]  feature called Twitter giveaway. This is the API handling. So the API format is like the
[10:11.940 --> 10:18.780]  slash API slash endpoint. And the one to get user transaction is slash API users.
[10:18.780 --> 10:27.540]  And if you visit the non-existing endpoint, for example, slash API slash test,
[10:27.540 --> 10:33.600]  it will return the error message like this one. Translate to English, it's failed to resolve the
[10:33.600 --> 10:41.420]  request test. So what we're seeing here is the content in the URL is reflect bad in the response.
[10:41.940 --> 10:49.360]  And this is kind of signal that indicating that this if the backend doesn't do any
[10:49.360 --> 10:54.480]  standardizations or encoding, that might have the reflect scripting vulnerabilities.
[10:54.880 --> 11:02.500]  And that's exactly the case. So by putting slash SVG unload equal to alert document domains,
[11:02.500 --> 11:08.660]  the application just very happily popped the alert for me. And as I mentioned, this is a host
[11:08.660 --> 11:15.160]  web wallet. The private key is owned by the server. You cannot just directly steal them
[11:16.380 --> 11:22.560]  like the one in the first case study. So the plan here is to use these vulnerabilities
[11:22.560 --> 11:29.940]  to compromise either take over user's account or take over his sessions. So by looking around,
[11:29.940 --> 11:40.140]  I found that this session token is stored in the PHP SCSSID cookies. And what's special here is
[11:40.140 --> 11:46.520]  it does not have the that token does not have the HTTP only flag. So if you are not a website guy
[11:46.520 --> 11:53.380]  or web developer, HTTP only flag, if that has that flag set, it will stop JavaScript from accessing
[11:53.380 --> 11:58.960]  that cookies. In other words, you say it is it prevents attacker from stealing the session tokens
[11:58.960 --> 12:06.240]  in the cookies with the cross-site scripting attack. But in this case, there's no HTTP only.
[12:06.240 --> 12:12.760]  So I can just craft a payload that read the content with the cookie content and send to my
[12:12.760 --> 12:19.980]  web servers. So after I get the session tokens, I can use the session token, log in to the victim's
[12:19.980 --> 12:25.660]  account. So, you know, when you're going to compromise the wallet, the end goal will always
[12:25.660 --> 12:31.140]  try to steal the money. So I take over the session. Now it's time to take all the money.
[12:31.140 --> 12:37.240]  But wait, I can't because for the money transactions actions in that wallet,
[12:37.240 --> 12:45.680]  it requires a 2FA. So I kept looking around to see what I can do. I was not able to reset the 2FA.
[12:45.680 --> 12:52.580]  I was not able to disable the 2FA. But I found a feature. There's a feature called giveaway.
[12:52.580 --> 12:59.240]  How it works is you go into the interface, it asks you what kind of coin you want to give away,
[12:59.240 --> 13:03.080]  and how many of them you want to give away, and how many people you want to give it to.
[13:03.420 --> 13:09.460]  In this case, here in the screenshot, you can give away up to two bitcoins. I think that's a lot.
[13:11.200 --> 13:15.840]  And after you create a giveaway, what people will need to do is they need to follow you,
[13:15.840 --> 13:21.660]  text your friends, retweet. Once you have done that, you can go to the URL and claim the reward.
[13:21.660 --> 13:26.780]  And what's special about this feature is this feature doesn't require 2FA.
[13:27.620 --> 13:34.480]  So I can use the reflect-quota-scripting to steal users session tokens and use these features to
[13:35.420 --> 13:40.320]  create a bunch of giveaways and claim those rewards myself. And this way,
[13:40.320 --> 13:44.060]  I can just transfer all the money coins out from the bitcoins account.
[13:45.200 --> 13:51.560]  So on May 28, I reported these issues to the company by email. They act on these issues.
[13:52.220 --> 13:59.340]  And it was silenced for almost two months. And last month, their response to the issue is fixed
[13:59.340 --> 14:07.760]  and reward me $20 worth of coins. They don't really have a formal bug bounty program,
[14:07.760 --> 14:16.140]  so I'm fine with the $20. So the fix is the HTML encode output, so no more cross-site scripting.
[14:16.140 --> 14:23.240]  And they said HTTP only flag for the cookies that contains the session tokens. In this way,
[14:23.240 --> 14:30.860]  if the application is vulnerable to cross-site scripting later, then the attacker would not be
[14:30.860 --> 14:37.620]  able to directly steal the session tokens. So that's all about the case study on WebWallet.
[14:37.620 --> 14:42.780]  Let's go move on to DesktopWallet. So DesktopWallet is the desktop application
[14:43.420 --> 14:50.760]  as it's a wallet that runs on Windows, macOS, and sometimes Linux. So what kind of text that
[14:50.760 --> 14:59.020]  people use to build a DesktopWallet? So we look at 18 DesktopWallets. So one is Qt, C++,
[14:59.020 --> 15:08.340]  one is .NET, C Sharp, and one Java, and 15 Electrons. In the DesktopWallet case study,
[15:08.340 --> 15:12.960]  we'll first talk about a server-side RCE in a .NET DesktopWallet,
[15:12.960 --> 15:18.960]  and the second one is a client-side RCE in an Electron wallet. Now I'm going to mute myself
[15:18.960 --> 15:26.800]  and let my colleague Mingzhi walk you guys through the server-side RCE in the .NET DesktopWallet.
[15:30.670 --> 15:36.650]  Thanks, Pei. So hi, everyone. I'm Mingzhi. So I'm going to talk about a remote code execution
[15:36.650 --> 15:42.010]  vulnerability found in a DesktopWallet. So first, I'll give some background about the wallet.
[15:42.030 --> 15:46.910]  The wallet is a decentralized single protocol wallet. It is written in C Sharp, and it uses
[15:46.910 --> 15:52.030]  .NET framework. It contains many common wallet functionalities like account management,
[15:52.030 --> 15:57.150]  making transactions, and deploying and interacting with smart contracts. What's interesting is that
[15:57.150 --> 16:02.770]  it allows users to upload files to a server. This is not quite common in a wallet, so we decided to
[16:02.770 --> 16:07.730]  look into this feature more. As mentioned previously, this application uses .NET,
[16:07.730 --> 16:12.210]  so for .NET application, it is very easy to retrieve the source code by decompiling the
[16:12.210 --> 16:19.110]  executables if code obfuscation is not deployed. So this is exactly the case of the wallet,
[16:19.110 --> 16:23.750]  so we're able to recover the source code for further analysis. So after decompiling the
[16:23.750 --> 16:28.750]  executables, we found the source code that implements the file upload, as shown in the
[16:28.750 --> 16:35.010]  snippet. The wallet sends a HTTP post request to the server, and it returns with the file upload
[16:35.010 --> 16:43.130]  URL. So we saw file upload.php is the file that handles the file upload on the server side.
[16:43.250 --> 16:48.450]  So as a pen tester, this is very fascinating, as now we know that the server probably uses PHP
[16:48.450 --> 16:54.650]  as the backend. So if we could upload a PHP WebGL to the server and open it in a browser,
[16:54.650 --> 16:57.270]  we might get remote code execution on the server.
[16:58.870 --> 17:04.770]  So that's exactly what we did. So we are able to successfully upload the file using the wallet
[17:04.770 --> 17:11.150]  and access the file in the browser. So after clicking on the upload shell, we are able to
[17:11.150 --> 17:16.150]  gain a web shell on the server. We also discovered that the web server runs under the administrator
[17:16.150 --> 17:21.570]  user, so we are able to execute commands with administrator privilege. So at this point,
[17:21.570 --> 17:26.110]  we are able to gain full control of the server, and we are able to manipulate files uploaded by
[17:26.110 --> 17:32.210]  other users. However, as mentioned previously, since it's a decentralized wallet, the server
[17:32.210 --> 17:38.050]  does not store any user private keys. So you are not you cannot directly compromise user account
[17:38.050 --> 17:44.210]  by exploiting this vulnerability. So the fix is actually pretty simple. The developer just
[17:44.210 --> 17:48.670]  removes the file upload functionality in their further application so that they do not have to
[17:48.670 --> 17:53.330]  deal with it. This is actually a good idea, as the critical wallet is supposed to keep as simple
[17:53.330 --> 17:58.530]  as possible to avoid security issues. So now I will hand over to Pei Yu to talk about security
[17:58.530 --> 18:09.140]  in Electron Wallet. Yeah, thanks, Minji. So right now, let's jump to Electron.
[18:10.700 --> 18:16.960]  What is Electron and why Electron? Electron is an open source framework that allows developers to
[18:16.960 --> 18:23.560]  build cross-platform desktop applications with HTML, CSS, and JavaScript. Electron combines the
[18:23.560 --> 18:28.560]  core and render engine Node.js into a single runtime. So the benefit of using Electron is
[18:28.560 --> 18:35.720]  developers can reuse web application codes to build desktop applications. They don't need to
[18:35.720 --> 18:41.660]  have a separate codebase. They don't need to learn new languages. And debugging the
[18:41.660 --> 18:47.760]  Electron application is pretty easy with the Chrome dev tools. And Electron applications run
[18:47.760 --> 18:54.440]  on major OS. And because it can access to the Node.js modules, it can build a more powerful
[18:54.960 --> 19:02.380]  app compared to the web app in the browsers. So Electron security. So for most vulnerabilities
[19:02.380 --> 19:07.800]  that exist in a web app, you can basically find them in the Electron app. And for Electron's
[19:07.800 --> 19:15.580]  specific security issues, the Electron official security guidance provides very detailed
[19:15.580 --> 19:22.100]  information about what mistakes that people make that will make the application vulnerable and how
[19:22.100 --> 19:29.760]  to not make those mistakes. And in BlackHat USA 2017, a talk called a study of Electron security
[19:30.330 --> 19:36.160]  talked about advanced technique that you bypass the building Electron security
[19:37.100 --> 19:43.880]  protections to achieve core executions. But in this talk, we will be simply talking about one
[19:43.880 --> 19:50.940]  configuration called Node integration. So the definition for Node integration is it refers
[19:50.940 --> 19:58.640]  to the ability of assessing Node.js resources in the applications. So why Electron application can,
[19:58.640 --> 20:02.620]  although it's using web technology, but can build more powerful app than
[20:03.320 --> 20:08.290]  application running in the browser because it can import so many Node.js modules.
[20:09.110 --> 20:15.710]  But it does come with a greater security risk. So aside from the Electron official security doc is
[20:15.710 --> 20:22.050]  disabling Node.js integration help prevent cross-scripting from escalating to a so-called
[20:22.050 --> 20:26.330]  remote core execution RCE attack. So what does it really mean?
[20:26.970 --> 20:34.110]  So this is the latest version of the MyCrypto desktop wallet. In the configuration, it has the
[20:34.110 --> 20:41.530]  Node integration set to false, which has the Node.js disabled. And if you type require in the
[20:41.530 --> 20:48.290]  dev console, it will just say require is not defined. This is the early version of the MyCrypto
[20:48.290 --> 20:56.750]  desktop wallet. It has the Node integration set to choose and Node.js enabled. In the dev console,
[20:56.750 --> 21:03.650]  if you type require, it will show the require functions. So by copy pasting some malicious
[21:03.650 --> 21:13.190]  code into the dev consoles, this behavior causes cross-scripting. And this is what you will see if
[21:13.190 --> 21:18.670]  you open the dev console when you're in the Electron, in the desktop core application.
[21:18.670 --> 21:24.770]  It says if someone told you to copy paste something here, you have 11 out of 10 chance being scanned
[21:24.770 --> 21:30.770]  and you shouldn't do that. So normally in a web application,
[21:30.770 --> 21:39.030]  if victim exported by the self-SSS, attacker can probably compromise his account
[21:39.030 --> 21:46.450]  or do some damage to his account within the application. However, for Electron wallet,
[21:46.930 --> 21:53.870]  it might get from self-SSS to calculator. So to open a dev console in Electron application
[21:53.870 --> 21:59.930]  on macOS, it's option plus command plus I. And if you copy paste the following code
[22:00.580 --> 22:10.630]  into the console, you can see calculators. So if you're not familiar what calculator means,
[22:11.670 --> 22:16.670]  it's the way to show the successful of co-executions.
[22:16.670 --> 22:23.250]  So you see, I paste that into the console and the calculator pop up.
[22:24.610 --> 22:31.650]  So what if the victim... so if you want to use way to export a victim, the victim,
[22:31.650 --> 22:37.550]  you will probably will construct some really long weird things and ask the victim to paste
[22:37.550 --> 22:43.430]  into dev console and the victim be like, hey, I'm not going to paste this weird thing into my dev
[22:43.430 --> 22:48.470]  console. So how about this one? I'll paste this, it will allow you to claim one BTC.
[22:48.710 --> 22:58.490]  Just paste window location to href equal to HTTPS BTC giveaway dot sign. So by the way,
[22:58.490 --> 23:07.330]  that domain is available. It only cost $0.99 on GoDaddy. Yeah, so the victim is like, oh sure,
[23:07.330 --> 23:14.990]  this short command, I'm just going to paste into console, what will happen? So what happens,
[23:14.990 --> 23:20.350]  you're going to see the calculators again, because what the line is doing is it will
[23:20.350 --> 23:25.550]  redirect you to another page. And if that page has the malicious code, it will just
[23:25.550 --> 23:33.390]  go to SQL in your desktop wallet in the electronic locations. So here's a statistic
[23:33.390 --> 23:42.030]  on electron wallet we look at. So we look at 15 electron wallet that's in active development.
[23:42.310 --> 23:50.010]  So 11 out of 15 has Node.js enabled. This can either cause by they, in the configuration file,
[23:50.010 --> 23:57.350]  they set the node integration to choose or they use the electron version less than 5.0.
[23:57.350 --> 24:04.390]  So the electron framework later than 5.0, it has Node.js disabled by default for security
[24:04.390 --> 24:14.070]  reasons. And 5 out of 15 has Node.js enabled and have the dev console enabled. So it might
[24:14.070 --> 24:20.030]  just escalate self cross-site scripting to client-side co-execution. So this is one example
[24:20.030 --> 24:29.010]  that the attacker can trigger the co-execution directly without using self cross-site scripting.
[24:29.150 --> 24:35.810]  And that brings us to our last case study on client-side RCE on a simple desktop wallet.
[24:35.810 --> 24:40.790]  So the simple desktop wallet is an open source decentralized single-coin wallet.
[24:40.790 --> 24:46.930]  It's the application from where it's built. It's electron. It has all the functionalities,
[24:46.930 --> 24:52.630]  basic wallet functionality, and as an addition, future code view news. They have
[24:52.630 --> 24:58.390]  bug bounty programs on HackerOne. That's how I discovered them and start hacking the wallet.
[24:59.430 --> 25:06.650]  So since it's open source, I start with the code view. This is their, the build.js is their
[25:07.470 --> 25:13.730]  electron configuration file. What the here does is the process the platform is storing.
[25:13.730 --> 25:19.650]  It starts the application with the create Mac functions. Otherwise, it creates the start
[25:19.650 --> 25:26.630]  application with the create Windows functions. So, and in the create Windows functions, I see
[25:26.630 --> 25:33.330]  that node integration is set to choose. That means if the application is running on Windows,
[25:33.330 --> 25:42.210]  the node.js is enabled. So how can we export this? So my goal will be to inject arbitrary
[25:42.210 --> 25:49.670]  JavaScript. Self-cursor scripting? No, bug bounty program does not pay for self-cursor scripting.
[25:49.670 --> 25:55.170]  How about legitimate cursor scripting? No, I was not able to find one. But how about node
[25:56.410 --> 26:02.430]  untrusted remote content into the application? So, all right, let's do some news. So in the
[26:02.430 --> 26:08.450]  simple desktop wallet, it provides the view news features. And when you click that link
[26:08.450 --> 26:18.850]  into in the news, it actually read the redirect out the wallet and go to another website.
[26:18.850 --> 26:24.150]  In this case, it just opened up GitHub on inside the desktop wallet.
[26:25.110 --> 26:32.750]  So the exportation plan is I will host the webpage with malicious JavaScript. I will place
[26:32.750 --> 26:37.990]  the URL then point to my malicious page on GitHub. It can be a GitHub issues on the repo.
[26:37.990 --> 26:45.850]  I can create a repo and put it in the README. Or I can put it on my GitHub profile and then
[26:46.530 --> 26:54.850]  visit that URL in the desktop applications. This is a very easy, simple proof-of-concept code. What
[26:54.850 --> 27:01.730]  it does is there's a button. And when the button is clicked, it triggers the RCE count functions.
[27:01.730 --> 27:07.770]  What a function does, it just pops the calculators. And here's a proof-of-concept video.
[27:09.570 --> 27:17.930]  So I opened up the desktop wallet. I unlock wallet with my password.
[27:23.350 --> 27:28.670]  And I go ahead and verify the version. It's a very early version.
[27:28.670 --> 27:38.810]  This is the version back in April, I think. And I click the link in the news. I'm now on GitHub.
[27:38.810 --> 27:46.230]  And in this case, you ask the victim to go to certain GitHub page with a phishing attack.
[27:46.230 --> 27:52.430]  But for the demonstration, I just go to my personal GitHub account. And I have the URL
[27:52.430 --> 27:59.430]  hosted on my profile. And I click that. I go to the page that contains my POC.
[27:59.490 --> 28:07.190]  And I click the close. Calculator just pop up. So in this example, the POC script requires
[28:07.190 --> 28:15.570]  user to click a button. But in reality, attacker can just execute those malicious code automatically.
[28:15.570 --> 28:21.030]  And of course, attacker can use JavaScript to steal the key stores, steal the passwords,
[28:21.030 --> 28:27.810]  or it can, you know, use have like creating a reversal and control the victim's computers.
[28:29.330 --> 28:35.530]  So timeline must submit these reports on HackerOne. They triage and give me 2,500 bounties.
[28:35.530 --> 28:41.610]  And they fix in the next release. The simple team and the name team are really nice. I really
[28:41.610 --> 28:48.530]  appreciate they allow me to talk about this being public. So and the fix was they set the no
[28:48.530 --> 28:56.450]  integration to false in the build.js file and update the build news feature. So right now,
[28:56.450 --> 29:03.710]  if you click the link in the news, it will open up in the external browser instead of inside the
[29:03.710 --> 29:11.690]  desktop wallet. So again, I want to thank the team and they really value the security they use.
[29:12.070 --> 29:19.150]  Yeah, really fixed. So the takeaway here is attacker can compromise the victim's
[29:19.730 --> 29:22.520]  wallet or even the computer.
[29:23.800 --> 29:46.680]  And have you had a security audit before you allow users to have an internal security team?
[29:46.680 --> 29:52.180]  Definitely ask the security team for a security review. And if you don't have the
[29:52.180 --> 29:56.800]  internal security team, you have to hire a security professional for a security review.
[29:58.920 --> 30:05.660]  If you have any questions, comments, you can post it on the text channel or email us after
[30:06.320 --> 30:12.480]  you're welcome to follow us on our Twitter. This slide will be posted on my Twitter account.
[30:13.780 --> 30:19.300]  And you can, if you're interested, you can check out our company blog post. There's a lot of
[30:19.300 --> 30:24.580]  interesting blog posts that we talk about some hacks that happened recently or some technical
[30:24.580 --> 30:37.640]  articles. Thanks. Yeah, if you have any questions, just drop in the channel.