EthCC 2: Pavlo Radchuk

hello everyone my name is Paul Laura Chuck and today I want to speak with you about deaf security and how we think it should be done I'm watching security lead at second I'm doing blockchain security stuff starting from smart contract auditing and watching protocol reviews finishing with the previews and in past I worked this application security engineer for web applications and that's why I'm talking about DEP security and the web aspects of depth security so what today we'll talk about its what is Deb how Deb's look like water depth owner abilities what is the difference between smart contract audit and Deb security review and making conclusion so Deb is decentralized application is just some applications that back-end code runs on some decentralized network they can be not only blockchain ones for example utorrent is still the biggest decentralized application but in this presentation I will limit only too easy Rome Deb's built on solidity smart contracts so how depth should look like and what will they look like in 1319 it will be decentralized front end where HTML and all the scripts are stored in this warm or ipfs and all the backend code is on smart contracts on the blockchain and all the logic is on the blockchain as well however we don't live in 1319 and if you don't believe me I've got some screenshots proving that so first example is rather relay if you try to access rather relay from Ukrainian IP address you'll get this one so rather relay is not available from your location smart contracts can define my location so there is definitely some not je server or some Apache server which is filtering IP addresses and not allowing me to access the application the next example is my cryptid hero's it's like one of the biggest games on the easy room and if you look on the top there is like a parameter what it means it means this parameter it's transferred to some server and processed by the server and its potential input for a hacker he can fast this parameter he can attack this and even if your smart contract is secure he can find some web vulnerability the next screenshot is our favorite cryptic kitties and there is like registration form it also process parameters in URL like UTM parameters which are responsible for marketing and when you register it for cryptic it is there is like email field what does it mean for classic devs like the apps in 1319 all the authorizations should be done we are easy reom wallet but here you need to have email address and this email address should be stored somewhere in database and it means that this application utilizes some database and there can be SQL injection so what we can see is that depth in 2019 looks like back-end on smart contracts on the blockchain front-end stored somewhere it doesn't really matter where and we've got middle and server typically not GS where they can be different software for example user support software marketing software continuous integration services some databases and a lot of ferrocene and its potential end points for hackers so when it comes to security most of people who develop depths think about this one but not thinking about Midland okay so smart contract audit is the process when you're auditing and smart contract and you're finding all the vulnerabilities in smart contract logic and the smart contract is the back end of the DEP and definitely smart contract audit should be performed it should be performing twice and as many times but as many times it's better and it's not protecting you from the attacks on users and web attacks ok what we think should be done for most of the devs is depth security review it's a project like security review which includes the smart contract audit for the smart contracts but also it models all those potential threats on web application and it includes user security and as a testing against web issues and the scope of the depth security review should be defined from the architecture for example if there there is any SQL there potentially can be SQL injection if there is no scales they can be SQL injection so what a typical vulnerabilities for depth what we research that there are two most common vulnerabilities for depth first of them is XSS exercises cross-site scripting it's the type of attack when malicious attacker can execute the script the JavaScript in your browser without your confirmation or any actions from your side and the second scene is server miss configuration it's like the class of security vulnerabilities related to unpatched software default passwords and all this stuff but actually as I said there can be all the vulnerabilities from classic web starting from SQL injection broken authentication XML external entity everything from elastic lists and best practices so I've prepared a small demo for XSS and here is the background as a back-end code of the smart contract it's pretty easy smart contact so any address can cause a set value function and apply for kyc and he will store some string for example company name in the blockchain and then some authority can get can call get value get a value function and receive that text from the blockchain and this contract is pretty secure so there is no potential threats from the smart contracts security side but when it comes to the app the implementation of the app for risky way C can have some vulnerabilities so I've got the video demo where XSS becomes critical and I'll describe what happens here okay so it's kyc registration Deb we've got one field where we can submit the company name for example second we write to blockchain execute transaction and if we check if admins check what is in this address we get hackin but for example if attacker pays the malicious JavaScript code here execute transaction and the admin won't see the name of the company it's builded HTML tag which cause web 3 function sent either and if admin of this ICM is clicks then he will send all his easer to the attacker and potential of all these vulnerabilities XSS K critical because you can try to call any function of any smart contract from from the admin address okay so that's why in classic web the XSS vulnerability is typically medium or high severity and we consider it is critical for blockchain depth ok the second most common vulnerability is a server miss configuration there are a lot of example of serving miss configuration and if you have a G not GS server they can be not updated software they can be default passwords for some SSH or some other software there can be open dot git folder and when attacker access doggit folder he receives the full access to your repositories there can be some other stuff for example if you have keys and repository or some additional information may also help attacker to execute some other vulnerabilities there can be diverse directory traversal is a kind of attack when attacker can go through server folders and try to find something some useful files and he can access any file of the server get access to all images for example get images for passports for kyc of other users there can be open s3 bucket if it's used and you can also with any Amazon account access this bucket and gulls get all the code from this bucket and use it for like reco incidents and gain more knowledge about the application and was a pretty common case when the app is not utilizing HTTP is like nonsense ok so the next example is an unpatched not GS its vulnerabilities it was discovered in not GS server and it was in discovered in June 2018 so it's pretty pretty fresh and if you are not updating your not GS server you potentially can be exploited via this vulnerability and what actually also seen on the slide meet so all versions are vulnerable to the spooner ability and severity is high the typhoon Ruby type of vulnerability is DOS its denial of service so it means that if attacker sends specially crafted request to your server your server goes down and any legitimate user cannot connect cannot send any request to the server what means that your DEP is down and it's much easier to put your nadjia server downs and the whole easy room network and even if your contracts are working your front end can be down and any user cannot use your d app and the impact of this vulnerability is high okay so when we were looking onto the lunar abilities we thought okay we can do a mask and for all the D apps and we parsed the list of the domains for all the apps from different sources like Deborah dar and they were like muslin two thousand of depths that we analyzed and we were looking to open that get folders and open s3 buckets we had no results for open dot git repository so it's pretty good and it's much better results than for classic web applications however when we did the mask and for open s3 buckets we found several applications with a big amount of users like top 20 of the apps in easy room that has open s3 bucket and we contacted all these teams we said that hello guys you have open s3 buckets so any guy can access to it and can read all the source code of your web application and the responses were different so some companies that okay it's not a problem our web application code is also open sourced and we don't care if you get access to our s3 bucket and if you prove that it has any potential security impact we will close it some other said that okay yes it's minor medium vulnerability and we will fix it so what I want to demonstrate with this presentation is that depths are not that depths they supposed to be so they also have centralized servers most of them they got marketing software's they got all the classic web stuff Deb's also are not thinking about web security usually and when they are doing security testing they are limiting for smart contract audit and the application with perfect smart contract can be also hacked for example like demo is XSS and what we recommend is to do security reviews instead of smart contract audits because it covers both web security and smart contract security so if you have any questions or any ideas about depth security let's talk about it you can reach me in Twitter you can reach me via email since everyone for attention and we have several minutes for questions [Applause] okay pulse thank you for your presentation tell me please what do you think the most difference between the classic web application and digitalized and web parts of a decentralized application in questions of web security what they think is are the most difference between them okay so the main difference is the architecture and where's the code actually executed if we have classic web application the code executed unlike some centralized server server it's like PHP code or Java Script code and there can be their own vulnerabilities so there are differences between Java Script a PHP as well and basically the main stuff when tasting the depth and if there is no server or a small part several just doing some proxy in tasks Zehra other can be XSS and accessibility is much higher than for web applications for classic ones because we always get access to meta masks and we can do everything and the second scene is server miss configuration for penetration testing the main classes of vulnerabilities are injections are xx E and the broken authentication a great talk so my question is about not necessarily about the dabs but you know all the interim notes also exposed a JSON RPC servers right so did you take a look at this you know endpoints and and it talks about that if it's like secure or okay so this is a different type of security reviews it's like blockchain platform security and we are doing this service for other block chains so we had like two requests for other block chains for phazon API for doing a network contesting but we are not actually doing this for zero because it's like hacking if you want to have some server we need to get approval from the company and if it's like a lot of time of our team it should be paid so we are doing it's like for other projects thank you very much for your great coat great talk are you thinking about working with I mean big framework companies like oh us to provide maybe a framework for a blockchain security analysis and yes yes of course so always framework there is like a Vasa ASVs its application security verification standard and there is seventeen sections that you should cover when you're doing pen test and when you be doing pen test we cover all of them but when we do a depth security there are two parts first part a smart contract audit and the second part is web application security and we define dependence on architecture what section from Ava's testing guide and of us by ASVs are applicable for this application and we cover them okay thanks everyone you can find me [Applause]