The Remote Exploit Development Team has just announced BackTrack 4 Beta. BackTrack is a Linux based LiveCD intended for security testing and we've been watching the project since the very early days. They say this new beta is both stable and usable. They've moved towards behaving like an actual distribution: it's based on Debian core, they use Ubuntu software, and they're running their own BackTrack repositories for future updates. There are a lot of new features, but the one we're most interested in is the built in Pico card support. You can use the FPGAs to generate rainbow tables and do lookups for things like WPA, GSM, and Bluetooth cracking. BackTrack ISO and VMWare images are available here.
Mentor classes are special, 10 week-format SANS classroom sessions that give the students time to absorb and master the same material with the guidance of a trained security professional.
Students receive all the same course materials used at SANS conferences and study at a more leisurely pace, so students will have:
Hardcopy set of SANS course books
Mentor Program study materials
Weekly Mentor led sessions
Prior to the weekly Mentor-led classroom sessions, students study SANS course material at their own pace. Each week, students meet with other professionals in their hometown area and the SANS mentor, who leads topical discussions pointing out the most salient features of the weekly material studied, provides hands-on demonstrations, and answer questions. The Mentor's goal is to help student's grasp the more difficult material, master the exercises, demonstrate the tools and prepare for GIAC certification.
On SANS SEC575, we will learn about mobile device infrastructures, policies and management, we will see the security models of the different platforms, like the data storage and file system architecture. We will also see how to unlock, root and jailbreak mobile devices in order to prepare them for data extraction and further testing. In the second half of the course, we will learn how to perform static and dynamic mobile application analysis, the usage of automated application analysis tools and how to manipulate application behavior. Last but not least, we will see how to perform mobile penetration testing that includes fingerprinting mobile devices, wireless network probing and scanning, attacking wireless infrastructures, using network manipulation attacks and attacks against mobile applications and back-end applications.
In this article we are going to go through File Inclusion Vulnerability. Wikipedia defines File Inclusion Vulnerability as: "A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application." There are two types of File Inclusion Vulnerabilities, LFI (Local File Inclusion) and RFI (Remote File Inclusion). Offensive Security's Metasploit Unleashed guide describes LFI and RFI as: "LFI vulnerabilities allow an attacker to read (and sometimes execute) files on the victim machine. This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information. If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands. RFI vulnerabilities are easier to exploit but less common. Instead of accessing a file on the local machine, the attacker is able to execute code hosted on their own machine." In simpler terms LFI allows us to use the web application's execution engine (say php) to execute local files on the web server and RFI allows us to execute remote files, within the context of the target web server, which can be hosted anywhere remotely (given they can be accessed from the network on which web server is running). To follow along, click on the File Inclusion navigation link of DVWA, you should see a page like this:
Lets start by doing an LFI attack on the web application. Looking at the URL of the web application we can see a parameter named page which is used to load different php pages on the website.
Since it is loading different pages we can guess that it is loading local pages from the server and executing them. Lets try to get the famous /etc/passwd file found on every linux, to do that we have to find a way to access it via our LFI. We will start with this:
../etc/passwd
entering the above payload in the page parameter of the URL:
we get nothing back which means the page does not exist. Lets try to understand what we are trying to accomplish. We are asking for a file named passwd in a directory named etc which is one directory up from our current working directory. The etc directory lies at the root (/) of a linux file system. We tried to guess that we are in a directory (say www) which also lies at the root of the file system, that's why we tried to go up by one directory and then move to the etc directory which contains the passwd file. Our next guess will be that maybe we are two directories deeper, so we modify our payload to be like this:
../../etc/passwd
we get nothing back. We continue to modify our payload thinking we are one more directory deeper.
../../../etc/passwd
no luck again, lets try one more:
../../../../etc/passwd
nop nothing, we keep on going one directory deeper until we get seven directories deep and our payload becomes:
../../../../../../../etc/passwd
which returns the contents of passwd file as seen below:
This just means that we are currently working in a directory which is seven levels deep inside the root (/) directory. It also proves that our LFI is a success. We can also use php filters to get more and more information from the server. For example if we want to get the source code of the web server we can use php wrapper filter for that like this:
We will get a base64 encoded string. Lets copy that base64 encoded string in a file and save it as index.php.b64 (name can be anything) and then decode it like this:
cat index.php.b64 | base64 -d > index.php
We will now be able to read the web application's source code. But you maybe thinking why didn't we simply try to get index.php file without using php filter. The reason is because if we try to get a php file with LFI, the php file will be executed by the php interpreter rather than displayed as a text file. As a workaround we first encode it as base64 which the interpreter won't interpret since it is not php and thus will display the text. Next we will try to get a shell. Before php version 5.2, allow_url_include setting was enabled by default however after version 5.2 it was disabled by default. Since the version of php on which our dvwa app is running on is 5.2+ we cannot use the older methods like input wrapper or RFI to get shell on dvwa unless we change the default settings (which I won't). We will use the file upload functionality to get shell. We will upload a reverse shell using the file upload functionality and then access that uploaded reverse shell via LFI. Lets upload our reverse shell via File Upload functionality and then set up our netcat listener to listen for a connection coming from the server.
nc -lvnp 9999
Then using our LFI we will execute the uploaded reverse shell by accessing it using this url:
To learn more about File Upload Vulnerability and the reverse shell we have used here read Learning Web Pentesting With DVWA Part 5: Using File Upload to Get Shell. Attackers usually chain multiple vulnerabilities to get as much access as they can. This is a simple example of how multiple vulnerabilities (Unrestricted File Upload + LFI) can be used to scale up attacks. If you are interested in learning more about php wrappers then LFI CheetSheet is a good read and if you want to perform these attacks on the dvwa, then you'll have to enable allow_url_include setting by logging in to the dvwa server. That's it for today have fun. Leave your questions and queries in the comments below.
In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.
Integer Attack Explanation:
An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.
If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.
In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.
Normally in your math class the following would be true:
99 + 1 = 100 00 - 1 = -1
In solidity with unsigned numbers the following is true: 99 + 1 = 00 00 - 1 = 99
So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.
That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.
Simple Example:
Lets say we have the following Require check as an example: require(balance - withdraw_amount > 0) ;
Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?
This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?
Let's do some math. 5 - 6 = 99
Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.
Because the following math returns true: require(99 > 0)
Withdraw Function Vulnerable to an UnderFlow:
The below example snippet of code illustrates a withdraw function with an underflow vulnerability:
In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.
require(balances[msg.sender] - _amount > 0);
It will then send the value of the _amount variable to the recipient without any further checks:
msg.sender.transfer(_amount);
Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:
balances[msg.sender] -= _amount;
Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.
Transfer Function Vulnerable to a Batch Overflow:
Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?
You have 10,000 tokens in your account You are sending 200 users 499 tokens each Your total sent is 200*499 or 99,800
The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.
You have 10,000 tokens in your account You are sending 200 users 500 tokens each Your total sent is 200*500 or 100,000 New total is actually 0
This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.
Lets take our new numbers and plug them into the below code and see what happens:
1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.
2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.
3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.
4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.
In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.
Lab Follow Along Time:
We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.
For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently. https://remix.ethereum.org/
Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:
This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:
Conclusion:
We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.
