We found out that many TLS implementations are still vulnerable to different variations of a 19-year old Bleichenbacher's attack. Since Hanno argued to have an attack name, we called it ROBOT: https://robotattack.org
Given the new attack variants, we released a new version of TLS-Attacker 2.2, which covers our vulnerabilities.
Bleichenbacher's attack from 1998
In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 1.5 padding allow an adversary to execute an adaptive-chosen ciphertext attack. This attack also belongs to the category of padding oracle attacks. By performing the attack, the adversary exploits different responses returned by the server that decrypts the requests and validates the PKCS#1 1.5 padding. Given such a server, the attacker can use it as an oracle and decrypt ciphertexts.
We refer to one of our previous blog posts for more details.
OK, so what is new in our research?
In our research we performed scans of several well-known hosts and found out many of them are vulnerable to different forms of the attack. In the original paper, an oracle was constructed from a server that responded with different TLS alert messages. In 2014, further side-channels like timings were exploited. However, all the previous studies have considered mostly open source implementations. Only a few vulnerabilities have been found.
In our scans we could identify more than seven vulnerable products and open source software implementations, including F5, Radware, Cisco, Erlang, Bouncy Castle, or WolfSSL. We identified new side-channels triggered by incomplete protocol flows or TCP socket states.
For example, some F5 products would respond to a malformed ciphertext located in the ClientKeyExchange message with a TLS alert 40 (handshake failure) but allow connections to timeout if the decryption was successful. We could observe this behaviour only when sending incomplete TLS handshakes missing ChangeCipherSpec and Finished messages.
See our paper for more interesting results.
Release of TLS-Attacker 2.2
These new findings motivated us to implement the complete detection of Bleichenbacher attacks in our TLS-Attacker. Before our research, TLS-Attacker had implemented a basic Bleichenbacher attack evaluation with full TLS protocol flows. We extended this evaluation with shortened protocol flows with missing ChangeCipherSpec and Finished messages, and implemented an oracle detection based on TCP timeouts and duplicated TLS alerts. In addition, Robert (@ic0ns) added many fixes and merged features like replay attacks on 0-RTT in TLS 1.3.
In case the server responds with different error messages, it is most likely vulnerable. The following example provides an example of a vulnerable server detection output:
14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered vulnerable to this attack if it responds differently to the test vectors. 14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered secure if it always responds the same way. 14:12:49 [main] CONSOLE attacks.impl.Attacker - Found a difference in responses in the Complete TLS protocol flow with CCS and Finished messages. 14:12:49 [main] CONSOLE attacks.impl.Attacker - The server seems to respond with different record contents. 14:12:49 [main] INFO attacks.Main - Vulnerable:true
In this case TLS-Attacker identified that sending different PKCS#1 messages results in different server responses (the record contents are different).
A Chinese hacking group has been found leveraging a new exploit chain in iOS devices to install a spyware implant targeting the Uyghur Muslim minority in China's autonomous region of Xinjiang. The findings, published by digital forensics firm Volexity, reveal that the exploit — named "Insomnia" — works against iOS versions 12.3, 12.3.1, and 12.3.2 using a flaw in WebKit that was patched by
CoWPAtty is a wifi password cracking tool. Implementation of a dictionary attack against WPA/WPA2 networks using PSK-based authentication (e.g. WPA-Personal). Many enterprise networks deploy PSK-based authentication mechanisms for WPA/WPA2 since it is much easier than establishing the necessary RADIUS, supplicant and certificate authority architecture needed for WPA-Enterprise authentication. Cowpatty can implement an accelerated attack if a precomputed PMK file is available for the SSID that is being assessed. Download coWPAtty wifi password cracking tool.
It's a pre-built tool for Kali Linux which you can find in the /usr/local/bin directory. It's also available for the windows but it doesn't work as fine as it does in the Kali.
DOWNLOAD COWPATTY WIFI PASSWORD CRACKING TOOL
For windows, you can download it from here. As it becomes pre-built in Kali, you do not need to download it. You just have to follow the path /usr/local/bin directory to find it in your Kali Linux OS.
NTP amplification is a type of DistributedDenial of Service (DDoS) attack in which the attacker exploits publically-accessible Network Time Protocol (NTP) servers to overwhelm the targeted with User Datagram Protocol (UDP) traffic.
SYN
IP:PORT
A SYN flood (half-open attack) is a type of denial-of-service (DDoS) attack which aims to make a server unavailable to legitimate traffic by consuming all available server resources.
TCP
IP:PORT
What is a SYN flood attack. TCP SYN flood (a.k.a. SYN flood) is a type of Distributed Denial of Service (DDoS) attack that exploits part of the normal TCP three-way handshake to consume resources on the targeted server and render it unresponsive.
UDP
IP:PORT
A UDP flood is a type of denial-of-service attack in which a large number of User Datagram Protocol (UDP) packets are sent to a targeted server with the aim of overwhelming that device's ability to process and respond. The firewall protecting the targeted server can also become exhausted as a result of UDP flooding, resulting in a denial-of-service to legitimate traffic.
POD (Ping of Death)
IP
Ping of Death (a.k.a. PoD) is a type of Denial of Service (DoS) attack in which an attacker attempts to crash, destabilize, or freeze the targeted computer or service by sending malformed or oversized packets using a simple ping command.
HTTP
URL
HTTP Flood is a type of Distributed Denial of Service (DDoS) attack in which the attacker manipulates HTTP and POST unwanted requests in order to attack a web server or application. These attacks often use interconnected computers that have been taken over with the aid of malware such as Trojan Horses.
Slowloris
IP:PORT
Slowloris is a denial-of-service attack program which allows an attacker to overwhelm a targeted server by opening and maintaining many simultaneous HTTP connections between the attacker and the target.
Memcached
IP:PORT
A memcached distributed denial-of-service (DDoS) attack is a type of cyber attack in which an attacker attempts to overload a targeted victim with internet traffic. The attacker spoofs requests to a vulnerable UDP memcached* server, which then floods a targeted victim with internet traffic, potentially overwhelming the victim's resources. While the target's internet infrastructure is overloaded, new requests cannot be processed and regular traffic is unable to access the internet resource, resulting in denial-of-service.
In the past I had to do several DoS security audits, with múltiples types of tests and intensities. Sometimes several DDoS protections were present like Akamai for static content, and Arbor for absorb part of the bandwith.
One consideration for the DoS/DDoS tools is that probably it will loss the control of the attacker host, and the tool at least has to be able to stop automatically with a timeout, but can also implement remote response checks.
In order to size the minimum mbps needed to flood a service or to retard the response in a significant amount of time, the attacker hosts need a bandwith limiter, that increments in a logarithmic way up to a limit agreed with the customer/isp/cpd.
There are DoS tools that doesn't have this timeouts, and bandwith limit based on mbps, for that reason I have to implement a LD_PRELOAD based solution: bwcontrol
Although there are several good tools for stressing web servers and web aplications like apache ab, or other common tools used for pen-testing, but I also wrote a fast web flooder in c++ named wflood.
As expected the most effective for taking down the web server are the slow-loris, slow-read and derivatives, few host were needed to DoS an online banking.
Remote attacks to database and highly dynamic web content were discarded, that could be impacted for sure.
I did another tool in c++ for crafting massive tcp/udp/ip malformed packets, that impacted sometimes on load balancers and firewalls, it was vulcan, it freezed even the firewall client software.
The funny thing was that the common attacks against Akamai hosts, where ineffective, and so does the slow-loris family of attacks, because are common, and the Akamai nginx webservers are well tunned. But when tried vulcan, few intensity was enough to crash Akamai hosts.
Another attack vector for static sites was trying to locate the IP of the customer instead of Akamai, if the customer doesn't use the Akamai Shadow service, it's possible to perform a HTTP Host header scan, and direct the attack to that host bypassing Akamai.
And what about Arbor protection? is good for reducing the flood but there are other kind of attacks, and this protection use to be disabled by default and in local holidays can be a mess.
How to control Android phone From another phone Remotely
If you wish to remotely control Android phone from another phone, then you have come to the right place. It might sound surprising, but now you can easily control Android from Android by using the right kinds of applications. This can let you keep a strict eye on your kids, spouse, or anyone else remotely. In this informative post, we will make you familiar with different Android to Android remote control apps. Also, we will provide a stepwise solution to use an Android tracking app as well. Let's uncover them by taking one step at a time.
Control Android Phone from Another Phone Remotely
There could be numerous reasons to control Android from Android remotely. In most of the cases, it is used by professionals to access a device over the air. Also, parents like to use an Android to Android remote control at times to get a complete access to their kid's smartphones. Sometimes, it can help us transfer files from one device to another. You can also use it to access your partner's or employee's phone at the time of needs too. In the next section, we will let you know how to remotely control Android phone from another phone.
How to remotely control Android phone from another phone?
There are different readily available applications that can be used to remotely control Android phone from another phone. We have picked the 3 best tools here.
1. TeamViewer for Remote Control
TeamViewer is one of the most widely known solutions that can provide a remote access to computer and smartphone remotely. It has a dedicated solution for Android as well that can perform the same function without any trouble. You can try its free version and later buy the premium subscription if you wish to.
Smart screen sharing with a complete control of the device
Control Android from Android by bypassing a security access (a one-time code should be matched).
256 Bit AES session encoding and 2048 Bit RSA key exchange supported for advanced security
RemoDroid is another smart and lightweight Android to Android remote control that you can use. Besides controlling an Android phone, you can also use this tool to control a TV and other smart devices from your Android device as well.
Easy screen sharing provision
You can remotely control Android phone from another phone and other smart devices (like a TV)
It supports screen sharing between multiple users
Password protected and supports one-time authentication
Inkwire is a highly useful app that every Android user should have installed on their device. This freely available tool can let you share your screen with another user. After sharing the screen, you can provide assistance by marking the screen as well. It is particularly used by users to guide other how to use a certain feature on the device.
Once connected, you can easily draw on the screen and guide the other user on a real-time basis.
It is extensively used to provide customer support for Android apps.
Cybercrime is the use of computers & networks to perform illegal activities such as spreading viruses,online bullying,performing unauthorized electronic fund transfers etc. Most cyber crimes are committed through the internet. Some cyber crime also be carried out using mobile phones via Sms and online chatting applications.
TYPES OF CYBERCRIME
The following list presents the common types of cybercrimes-
1-Computer Fraud-Intential deception for personal gain via the use of computer system.
2-Privacy Violations-Exposing personal information such as email addresses,phone numbers,account details etc, on social media,websites,etc.
3-Identity theft-Stealing personal information from somebody and impersonating that person.
4-Sharing copyright files/information-This involves distributing copyright protected files such as eBooks and computer program etc.
5-Electronic funds transfer-This involves gaining an unauthorized access to bank computer networks and making illegal funds transferring.
6-Electronic money laundering-This involves the use of the computer to launder money.
7-Atm fraud-This involves intercepting ATM card details such as account numbers and PIN numbers.These details are then used to withdraw funds from the intercepted accounts.
8-Denial of service attack-This involves the use of computers in multiple locations to attack servers with a view of shutting them down.
9-Spam:sending unauthorized emails.
These emails usually contain advertisements.
CYBER LAW
Under The Information Technology Act,2000
CHAPTER XI-OFFENCES-66. Hacking with computer system.
1-whoever with the Intent to cause or knowing that he is likely to cause Wrongfull Loss or Damage to the public or any person Destroys or Deletes or Alter any Information Residing in computer Resource or diminishes its value or utility or affects it injuriously by any means, commits hack.
2-whoever commits hacking shell be punished with imprisonment up to three years, or with fine which may extend up to two lakh rupees,or with both.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
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.
