The OWASP Foundation has been chosen to be 1 of 50 Open Source Organizations to participate in the inaugural year of the Google Season of Docs program. The goal of Season of Docs is to provide a framework for technical writers and open source projects to work together towards the common goal of improving an open source project's documentation. For technical writers who are new to open source, the program provides an opportunity to gain experience in contributing to open source projects. For technical writers who're already working in open source, the program provides a potentially new way of working together. Season of Docs also gives open source projects an opportunity to engage more of the technical writing community. We would like to thank the OWASP members that donate their time and knowledge as administrators and mentors. It would not be possible if not for these individuals:
Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: "Avoid using open Wifi" or "Always use VPN while using open WiFi" or "Avoid sensitive websites (e.g. online banking) while using open WiFI", etc.
What I think about this? It is bullshit. But let's not jump to the conclusions. Let's analyze all risks and factors here.
During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don't care. They just want to browse the web, access Facebook, write e-mails, etc.
The risks
Let's discuss the different threats people face using public hotspots, compared to home/work internet usage:
1.Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:
HTTP sites
HTTPS sites but unsecured cookie
FTP without encryption
IMAP/SMTP/POP3 without SSL/TLS or STARTTLS
2.Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign
3.Attackers can use tools like SSLStrip to keep the user's traffic on clear text HTTP and steal password/session data/personal information
4.Attackers can monitor and track user activity
5.Attackers can directly attack the user's machine (e.g. SMB service)
WPA2-PSK security
So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!
In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11
If you want to see it in action, here is a nice tutorial for you
Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.
Let me link here one of my previous posts here with a great skiddie tool:
Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
Can monitor/track user activity
The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.
The real solutions
1.Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.
2.Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.
3.Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list
4.Don't click blindly on fake downloads (like fake Flash Player updates)
5.The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And "Average Joe" will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.
6.Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.
7.In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.
Asking the question "Are you using open WiFi?", or "Do you do online banking on open WiFi?" are the wrong questions. The good questions are:
Do you trust the operator(s) of the network you are using?
Are the clients separated?
If clients are not separated, is it possible that there are people with malicious intent on the network?
Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.
And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I'm using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).
Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.
PS: I know "Average Joe" won't find my blog post, won't start to read it, won't understand half I wrote. But even if they do, they won't patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That's life. Deal with it.
OctoSniff is a network research tool that allows you to determine information about all the other players you're playing with. It is compatible with PS, XBox 360 and XBox One. It has many other features that make it a great sniffing tool. Some people think it might be a tool like Wireshark or Cain n Abel. No, it's not a tool like that. It simply sniffs players that let you know who's really playing. Download OctoSniff 2.0.3 full version. It's only for educational purposes to use.
In this blog series we will analyze blockchain vulnerabilities and exploit them ourselves in various lab and development environments. If you would like to stay up to date on new posts follow and subscribe to the following: Twitter: @ficti0n
As of late I have been un-naturally obsessed with blockchains and crypto currency. With that obsession comes the normal curiosity of "How do I hack this and steal all the monies?"
However, as usual I could not find any actual walk thorough or solid examples of actually exploiting real code live. Just theory and half way explained examples.
That question with labs is exactly what we are going to cover in this series, starting with the topic title above of Re-Entrancy attacks which allow an attacker to siphon out all of the money held within a smart contract, far beyond that of their own contribution to the contract.
This will be a lab based series and I will show you how to use demo the code within various test environments and local environments in order to perform and re-create each attacks for yourself.
Note: As usual this is live ongoing research and info will be released as it is coded and exploited.
If you are bored of reading already and just want to watch videos for this info or are only here for the demos and labs check out the first set of videos in the series at the link below and skip to the relevant parts for you, otherwise lets get into it:
Background Info:
This is a bit of a harder topic to write about considering most of my audience are hackers not Ethereum developers or blockchain architects. So you may not know what a smart contract is nor how it is situated within the blockchain development model. So I am going to cover a little bit of context to help with understanding.I will cover the bare minimum needed as an attacker.
A Standard Application Model:
In client server we generally have the following:
Front End - what the user sees (HTML Etc)
Server Side - code that handles business logic
Back End - Your database for example MySQL
A Decentralized Application Model:
Now with a Decentralized applications (DAPP) on the blockchain you have similar front end server side technology however
Smart contracts are your access into the blockchain.
Your smart contract is kind of like an API
Essentially DAPPs are Ethereum enabled applications using smart contracts as an API to the blockchain data ledger
DAPPs can be banking applications, wallets, video games etc.
A blockchain is a trust-less peer to peer decentralized database or ledger
The back-end is distributed across thousands of nodes in its entirety on each node. Meaning every single node has a Full "database" of information called a ledger.The second difference is that this ledger is immutable, meaning once data goes in, data cannot be changed. This will come into play later in this discussion about smart contracts.
Consensus:
The blockchain of these decentralized ledgers is synchronized by a consensus mechanism you may be familiar with called "mining" or more accurately, proof of work or optionally Proof of stake.
Proof of stake is simply staking large sums of coins which are at risk of loss if one were to perform a malicious action while helping to perform consensus of data.
Much like proof of stake, proof of work(mining) validates hashing calculations to come to a consensus but instead of loss of coins there is a loss of energy, which costs money, without reward if malicious actions were to take place.
Each block contains transactions from the transaction pool combined with a nonce that meets the difficulty requirements.Once a block is found and accepted it places them on the blockchain in which more then half of the network must reach a consensus on.
The point is that no central authority controls the nodes or can shut them down. Instead there is consensus from all nodes using either proof of work or proof of stake. They are spread across the whole world leaving a single centralized jurisdiction as an impossibility.
Things to Note:
First Note: Immutability
So, the thing to note is that our smart contracts are located on the blockchain
And the blockchain is immutable
This means an Agile development model is not going to work once a contract is deployed.
This means that updates to contracts is next to impossible
All you can really do is createa kill-switch or fail safe functions to disable and execute some actions if something goes wrong before going permanently dormant.
If you don't include a kill switch the contract is open and available and you can't remove it
Second Note:Code Is Open Source
Smart Contracts are generally open source
Which means people like ourselves are manually bug hunting smart contracts and running static analysis tools against smart contract code looking for bugs.
When issues are found the only course of action is:
Kill the current contract which stays on the blockchain
Then deploy a whole new version.
If there is no killSwitch the contract will be available forever.
Now I know what you're thinking, these things are ripe for exploitation.
And you would be correct based on the 3rd note
Third Note: Security in the development process is lacking
Many contracts and projects do not even think about and SDLC.
They rarely add penetration testing and vulnerability testing in the development stages if at all
At best there is a bug bounty before the release of their main-nets
Which usually get hacked to hell and delayed because of it.
Things are getting better but they are still behind the curve, as the technology is new and blockchain mostly developers and marketers.Not hackers or security testers.
Forth Note:Potential Data Exposure via Future Broken Crypto
If sensitive data is placed on the blockchain it is there forever
Which means that if a cryptographic algorithm is broken anything which is encrypted with that algorithm is now accessible
We all know that algorithms are eventually broken!
So its always advisable to keep sensitive data hashed for integrity on the blockchain but not actually stored on the blockchain directly
Exploitation of Re-Entrancy Vulnerabilities:
With a bit of the background out of the way let's get into the first attack in this series.
Re-Entrancy attacks allow an attacker to create a re-cursive loop within a contract by having the contract call the target function rather than a single request from auser. Instead the request comes from the attackers contract which does not let the target contracts execution complete until the tasks intended by the attacker are complete. Usually this task will be draining the money out of the contract until all of the money for every user is in the attackers account.
Example Scenario:
Let's say that you are using a bank and you have deposited 100 dollars into your bank account.Now when you withdraw your money from your bank account the bank account first sends you 100 dollars before updating your account balance.
Well what if when you received your 100 dollars, it was sent to malicious code that called the withdraw function again not lettingthe initial target deduct your balance ?
With this scenario you could then request 100 dollars, then request 100 again and you now have 200 dollars sent to you from the bank. But 50% of that money is not yours. It's from the whole collection of money that the bank is tasked to maintain for its accounts.
Ok that's pretty cool, but what if that was in a re-cursive loop that did not BREAK until all accounts at the bank were empty?
That is Re-Entrancy in a nutshell.So let's look at some code.
Example Target Code:
function withdraw(uint withdrawAmount) public returns (uint) {
Line 1: Checks that you are only withdrawing the amount you have in your account or sends back an error.
Line 2: Sends your requested amount to the address the requested that withdrawal.
Line 3: Deducts the amount you withdrew from your account from your total balance.
Line 4. Simply returns your current balance.
Ok this all seems logical.. however the issue is in Line 2 - Line 3.The balance is being sent back to you before the balance is deducted. So if you were to call this from a piece of code which just accepts anything which is sent to it, but then re-calls the withdraw function you have a problem as it never gets to Line 3 which deducts the balance from your total. This means that Line 1 will always have enough money to keep withdrawing.
Let's take a look at how we would do that:
Example Attacking Code:
function attack() public payable {
1.bankAddress.withdraw(amount);
}
2.function () public payable {
3.if (address(bankAddress).balance >= amount) {
4.bankAddress.withdraw(amount);
}
}
Line 1: This function is calling the banks withdraw function with an amount less than the total in your account
Line 2: This second function is something called a fallback function. This function is used to accept payments that come into the contract when no function is specified. You will notice this function does not have a name but is set to payable.
Line 3:This line is checking that the target accounts balance is greater than the amount being withdrawn.
Line 4:Then again calling the withdraw function to continue the loop which will in turn be sent back to the fallback function and repeat lines over and over until the target contracts balance is less than the amount being requested.
Review the diagram above which shows the code paths between the target and attacking code. During this whole process the first code example from the withdraw function is only ever getting to lines 1-2 until the bank is drained of money. It never actually deducts your requested amount until the end when the full contract balance is lower then your withdraw amount. At this point it's too late and there is no money left in the contract.
Setting up a Lab Environment and coding your Attack:
Hopefully that all made sense. If you watch the videos associated with this blog you will see it all in action.We will now analyze code of a simple smart contract banking application. We will interface with this contract via our own smart contract we code manually and turn into an exploit to take advantage of the vulnerability.
Then lets open up an online ethereum development platform at the following link where we will begin analyzing and exploiting smart contracts in real time in the video below:
Coding your Exploit and Interfacing with a Contract Programmatically:
The rest of this blog will continue in the video below where we will manually code an interface to a full smart contract and write an exploit to take advantage of a Re-Entrency Vulnerability:
Conclusion:
In this smart contract exploit writing intro we showed a vulnerability that allowed for re entry to a contract in a recursive loop. We then manually created an exploit to take advantage of the vulnerability. This is just the beginning, as this series progresses you will see other types of vulnerabilities and have the ability to code and exploit them yourself. On this journey through the decentralized world you will learn how to code and craft exploits in solidity using various development environments and test nets.
Commands are just like an instructions given to a system to do something and display an output for that instruction. So if you don't know how to gave an order to a system to do a task then how it can do while you don't know how to deal with. So commands are really important for Linux users. If you don't have any idea about commands of Linux and definitely you also don't know about the Linux terminal. You cannot explore Linux deeply. Because terminal is the brain of the Linux and you can do everything by using Linux terminal in any Linux distribution. So, if you wanna work over the Linux distro then you should know about the commands as well. In this blog you will get a content about commands of Linux which are collectively related to the system. That means if you wanna know any kind of information about the system like operating system, kernel release information, reboot history, system host name, ip address of the host, current date and time and many more.
Note:
If you know about the command but you don't have any idea to use it. In this way you just type the command, then space and then type -h or --help or ? to get all the usage information about that particular command like "uname" this command is used for displaying the Linux system information. You don't know how to use it. Just type the command with help parameter like: uname -h or uname --help etc.
uname
The "uname" is a Linux terminal command responsible of displaying the information about Linux system. This command has different parameter to display a particular part of information like kernel release (uname -r) or all the information displayed by typing only one command (uname -a).
uptime
This command is used to show how long the system has been running and how much load on it at current state of the CPU. This command is very useful when you system slows down or hang etc and you can easily get the info about the load on the CPU with the help of this command.
hostname
The "hostname" is the the command in Linux having different parameters to display the information bout the current host which is running the kernel at that time. If you wanna know about the parameters of hostname command then you just type hostname --help or hostname -h to get all the info about the command and the usage of the command.
last reboot
The "last reboot" is the command in Linux operating system used to display the reboot history. You just have to type this command over the Linux terminal it will display the reboot history of that Linux system.
date
The "date" is the command used in Linux operating system to show the date of the day along with the current time of the day.
cal
The "cal" command in Linux used to display the calendar which has the current date highlighted with a square box along with a current month dates and days just like a real calendar.
w
The "w" is the command used in Linux distro for the sake of getting the information about current user. If you type this command it will display who is online at the time.
whoami
The "whoami" is the command in Linux operating system used to show the information that who you are logged in as. For example if you are logged in as a root then it'll display "root" etc.
finger user
The "finger user" is the command used in Linux distribution to display the information about user which is online currently over that Linux system.
🕬 OWASP Announcement:
Continue reading
