1-Nmap-Network Mapper is popular and free open source hacker's tool.It is mainly used for discovery and security auditing.It is used for network inventory,inspect open ports manage service upgrade, as well as to inspect host or service uptime.Its advantages is that the admin user can monitor whether the network and associated nodes require patching.
2-Haschat-It is the self-proclaimed world's fastest password recovery tool. It is designed to break even the most complex password. It is now released as free software for Linux, OS X, and windows.
3-Metasploit-It is an extremely famous hacking framework or pentesting. It is the collection of hacking tools used to execute different tasks. It is a computer severity framework which gives the necessary information about security vulnerabilities. It is widely used by cyber security experts and ethical hackers also.
4-Acutenix Web Vulnerability Scanner- It crawls your website and monitor your web application and detect dangerous SQL injections.This is used for protecting your business from hackers.
5-Aircrack-ng - This tool is categorized among WiFi hacking tool. It is recommended for beginners who are new to Wireless Specefic Program. This tool is very effective when used rightly.
6-Wireshark-It is a network analyzer which permit the the tester to captyre packets transffering through the network and to monitor it. If you would like to become a penetration tester or cyber security expert it is necessary to learn how to use wireshark. It examine networks and teoubleshoot for obstacle and intrusion.
7-Putty-Is it very beneficial tool for a hacker but it is not a hacking tool. It serves as a client for Ssh and Telnet, which can help to connect computer remotely. It is also used to carry SSH tunneling to byepass firewalls. So, this is also one of the best hacking tools for hackers.
8-THC Hydra- It is one of the best password cracker tools and it consist of operative and highly experienced development team. It is the fast and stable Network Login Hacking Tools that will use dictonary or bruteforce attack to try various combination of passwords against in a login page.This Tool is also very useful for facebook hacking , instagram hacking and other social media platform as well as computer folder password hacking.
9-Nessus-It is a proprietary vulnerability scanner developed by tennable Network Security. Nessus is the world's most popular vulnerability scanner according to the surveys taking first place in 2000,2003,2006 in security tools survey.
10-Ettercap- It is a network sniffing tool. Network sniffing is a computer tool that monitors,analyse and defend malicious attacks with packet sniffing enterprise can keep track of network flow.
11-John the Ripper-It is a free famous password cracking pen testing tool that is used to execute dictionary attacks. It is initially developed for Unix OS. The Ripper has been awarded for having a good name.This tools can also be used to carry out different modifications to dictionary attacks.
12-Burp Suite- It is a network vulnerability scanner,with some advance features.It is important tool if you are working on cyber security.
13-Owasp Zed Attack Proxy Project-ZAP and is abbreviated as Zed Attack Proxy is among popular OWASP project.It is use to find vulnerabilities in Web Applications.This hacking and penetesting tool is very easy to use as well as very efficient.OWASP community is superb resource for those people that work with Cyber Security.
14-Cain & Abel-It is a password recovery tool for Microsoft Operating System. It allow easy recovery of various kinds of passwords by sniffing the networks using dictonary attacks.
15-Maltego- It is a platform that was designed to deliver an overall cyber threat pictures to the enterprise or local environment in which an organisation operates. It is used for open source intelligence and forensics developed by Paterva.It is an interactive data mining tool.
These are the Best Hacking Tools and Application Which are very useful for penetration testing to gain unauthorized access for steal crucial data, wi-fi hacking , Website hacking ,Vulnerability Scanning and finding loopholes,Computer hacking, Malware Scanning etc.
This post is only for educational purpose to know about top hacking tools which are very crucial for a hacker to gain unauthorized access. We are not responsible for any type of crime.
Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.
This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.
Weaknesses of XML Encryption
Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.
Falsely implemented XML Encryption can be broken using:
an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key [4].
SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.
XML Encryption in SAML
To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.
The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements. SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element.
Encryption Attacker
Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.
Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.
As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.
The screenshot above shows the essential interface of the new encryption tab: At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message. In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.
The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.
Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.
Probing for Bleichenbacher Oracles
Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].
To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.
Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].
In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.
00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.
Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.
Probing for Oracles in CBC-Mode Decryption
Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption. Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].
In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key: In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.
An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.
Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].
Summary
The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.
In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:
Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.
Often while writing smart contracts we will want to call functions within other contracts either to leverage functionality within the other contract or for upgradability reasons. We can do this by leveraging libraries with Delegate Calls. There are various reasons to do this, including code re-use cost savings avoiding re-deploying large libraries. We will take a look at this while reviewing the technical details of the Parity Wallet hack at the end of this chapter. But first let's discuss some other aspects and nuances of the delegate call so we are comfortable with how they work and how we can use them in attacks.
We have seen multiple ways to interact with external contracts for example using the ABI of a contract with Web3 calls. We have also created interfaces to a contract when creating our malicious attacking contracts. Now we will expand on this using low level delegate calls to external contracts.
In this section we will show how to interact with other contracts using lower level functions such as, call and delegate call. We will show how the code can leverage the functionality of another contract using delegate calls within Solidity. Beware, that as usual whenever you use lower level functions within solidity, bad bad things can and will happen.
Firstly, let's just define some terms so that I don't confuse myself and I don't confuse the readers because this can get a bit confusing if we don't know which contract, we are discussing. So, I am going to label the following two terms upfront so we can distinguish which contact we are discussing and how they are interacting. If we don't do this, we are going to end up confused. This particular vulnerability and how it works took me a minute to wrap my head around. I actually had to deploy contracts and play with code interactions before it made sense. I hope to save you the trouble, since there were no good resources when I started learning this.
We will define two contracts as the following for the purposes of the code examples we are analyzing.
üCalling contract: The calling contract we are interacting with through our DApp
üLogic Contract: The library contract holding some kind of business logic we call with delegate call or call
With that out of the way let's get back to confusing myself along with you.
We often see delegate calls used when we don't have an ABI interface and as an upgradability pattern within solidity. In order to explain delegate call we are going to first talk about the differences between a regular call and a delegate call and what the results are with each of these call types.
Delegate calls are used to call the functionality of the logic contract but have the changes reflected in the context of the calling contract. It essentially behaves as if you imported the functionality of the logic contract into the calling contract and the changes are reflected in the context of the calling contract. This behaves much like importing libraries when you are coding large projects and using that functionality as if it were part of your project.
Vs
The regular call acts more like a remote API where we are making changes on the remote logic contract rather than our calling contract. When using a regular call, we are calling the logic contract but the effects of that are retained within the logic contract. Rather than in the context of the calling contract.
I know I know, I just confused you so let's look at a simple example and talk about the outcomes of each instance depending on if we are using call or delegate call:
The best way to start to understand delegate calls are to actually play with them. Deploy the above contract within Remix and play around with it for a few minutes before reading the code walkthrough.
Also note you can review the video walkthroughs to see this in action. But make sure that you have the contract open in Remix and you are following along, this is essential to your learning and retention of these concepts.
Note that the above code comprises of two contracts within one Solidity file, which will deploy without any issues in Remix and provide you with both the logic contract and the calling contract. The calling contract will have the functionality that you will be interacting with. So just paste it into Remix, compile and deploy it.
I have also supplied a bit of code that automatically grabs the Logic contract address via a call on line 14 since they are both in the same file. Automatically grabbing the second contracts address is useful when you're debugging so you don't have to deploy the first contract and manually add it every time you change the code and redeploy.
Things to try on your own before continuing:
üDeploy the above code as a single Solidity file in Remix and review the address of CallingContract.
üClick the print_my_delegate button and review the output in the logs section of the transaction.
üClick the print_my_call button and review the output in the logs section of the transaction.
Now that you have interacted with this code a bit within Remix, let's break it down piece by piece talk through some of the code, then do a walkthrough and explain the results.
6.function print_address() public returns(address){
7. returnedAddress = address(this);
8. emit contractAddress(returnedAddress);
9. }
10. }
The logic contract is pretty simple. We create an address variable named returnedAddress on line 3 which holds the value of the returned address from the print_address function. On line 7 we get the current address of the contract with the this keyword. This is kind of like self in python which says give me the variable value associated with the current instance of the object, in this case the address of the current contract based on context in which it has been called. In order to view this variable, we issue an Event on line 8 simply printing out the current value of the contract address.
In order to make use of the logic contract we have the CallingContract which is shown below:
First thing to notice on line 2 is the use of the exact same returnedAddress variable from the LogicContract. This is important when using delegate calls as the call will modify that variable locally on the calling contract from the Logic contracts remote functionality. If this variable does not exist it cannot be set, you should always have the same variables in each contract and have them in the correct order when using delegate call. We will talk more about variables and their behavior with delegate calls shortly when manipulating memory elements.
Next you will notice two functions, one function that is using a call on line 9 and one that is using a delegatecall on line 6.
We will see the differences with using each of these call types. Both of these functions are calling the same print_address function from the LogicContract using the logic_pointer address variable created on line 3. The logic_pointer variable is simply the address of the logic contract so our calls know where they are directed to. These two calls look very similar but that is where the similarities end as we will see in the following walkthrough.
Note: You will also notice some strange syntax wrapping our call to print_address using abi.encodeWithSignature. This is just simply an encoding mechanism before sending our data with our calls. Similar to encoding web calls with base64 except that delegate call only accepts a single un-padded bytes argument. It's nothing special, it's just the way we need to encode the data on these types of calls.
Deploying our Simple Example:
Actions to take:
üDeploy the contract in remix
üClick the print_my_call_address button
üClick the print_my_delegate_address button
The deployed contract should look similar to the following showing the contract address for CallingContract and the two functions available to us:
After you deploy the contract you will want to take note of the address of the CallingContract. In this example above the buttons you will see the calling contract address starts with the values 0x75A. Write the address of your contract down, as this contract address will be important when reviewing the output of the two functions print_my_call_address and print_my_delegate_address.
First let's review the output of using a regular call to the logic contract. When we click the print_my_call_address button you will see a new transaction post in the transaction window below the code.
Click the down arrow to view the transaction details and you should see output similar to the following under the logs section.
The output shows the event that emitted when the logic contract code was called with the returned address parameter coming from this. Notice that this is not the same address as our calling contract. This is the address of our LogicContract.
Next click the button for print_my_delegate_address. Again, check out the transaction window and click the down arrow to view the details. Within the logs section of the transaction you will see a similar event action: ___________________________________________________________________________________
This time note that the address returned is your CallingContract address that starts with 0x75. This is because with delegate call the code was run as if it was imported into the CallingContract using the context of the CallingContract for the returnedAddress variable posted to the event.
Now let's quickly go over how variables work within delegate calls and the importance of properly aligning these variables so they do not overwrite the wrong memory locations. In our example above we saw that we can execute code from the logic contract in the context of the caller. This is also true for the storage in the contract. Both the code and the storage are based on the context of the caller.
So, what does this mean? It means that when we change the value of a variable using our logic contract it will change the value of the variable within our calling contract if a delegatecall is used. This can be quite dangerous and lead to disastrous results as you will see in our Case Study of the Parity Wallet attack walkthrough at the end of this chapter.
For now, let's go over a simple example of what happens in memory when variables are incorrectly handled with delegatecall.
This example follows the same structure as the previous contract of having both the logic and calling contract in the same solidity file and retrieving the logic contracts address automatically for convenience.
Things to note:
üThere is only a single functionality between these contracts that sets the value of "a".
üThree variables are set in the calling contract "a", "b" and "logic_pointer"
üOne Variable is set in the logic contract "a"
üA delegate call is used in the calling contract to set the value of "a" using the set function from the logic contract.
Action Steps:
üTake note of the ordering of the variables between the two contracts.
üType out this code into remix and then deploy the CallingContract
üClick the b and a button and review their values
üNow click the setA button and review the values again
In the action steps above you would have noticed that when you set the value of "a" the value of "b" was the value that changed. Why is this?
So, we have to start thinking in which context we are using when calling the contract. The image below should help to clear this up. Take a look at that image for a minute and try to think about what happened.
So, in the calling contract we have "b", "a" and "Logic_Pointer". Then we have the variable "a" in the logic contract. When using a delegatecall we are executing the set function in the logic contract under the context of the calling contract which has those 3 variables with "b" being the first variable. You see where I am going with this? Essentially the logic contract only knows about the "a" variable and sets the first element in the memory to that value. However, we are in the context of the calling contract, and the calling contracts first memory slot is the variable "b".
So, what happens is when we initially deploy the contract, we have the following where both "a" and "b" equal 5.
Then we click the setA button to execute the delegatecall into the set function in the logic contract and this results in "a" remaining at the value of 5 but "b" is updated to the value placed in the setA function. In this case I used the value of 3.
The b value is overwritten because it is the first slot defined in the memory of the calling contract and the logic contract only knows about a single variable "a" in its own contract thus overwriting the value in the first slot of memory. Since we used delegate call we are not writing the memory in the logic contract but instead the calling contract.
Take a minute to let that all sink in. Review the picture from above with the memory slots. Think about the previous example of what context you are in when using delegate call. Then come back to this and check out the case study of this in action for a multi-million dollar theft in real life.
When it comes to attacks against misconfigured smart contracts with delegate calls the most famous of the attacks was the Parity Wallet hack which resulted in a multi-million-dollar losses. I will briefly but with detail discuss what one of the parity attacks entailed. This should bring together when you learned into a real-world example.
The vulnerable Parity contract we are referencing is located at the following address:
Essentially the parity wallet was a multi-signature wallet which was extremely lightweight and relied on functionality from a main library contract. Using libraries is a way of saving costs as wallets will be deployed multiple times on the blockchain and the fee to deploy contracts is based on the size of the instructions used in the contract. Less instructions on a smaller lightweight wallet equals less overall transaction payments. By deploying the main functionality within a callable library, the code only incurred a onetime fee for the larger codebase. Each additional deployed contract comes at a much smaller cost due to its reduced size of instructions. This is fantastic from both a cost savings and upgradeability perspective, depending how you deploy the functionality and how you handle access to libraries.
But the Parity wallet had a few shortcomings due to a combination of public initialization functions that lacked a usage state and authorization issues. Authorization issues allowed direct calls after initial contract deployment and delegate calls allowed attackers to interact with initialization functions in the context of the calling contract.
Parity Issues that allowed an Attack:
üAn attack Vector into the library via the wallet (DelegateCall in a Fallback function)
üInitialization functions that didn't check a wallets current initialization state
In this attack an attacker could gain control of the library via a public initialization function. Once the attacker gained control of the library via the initialization function, he was able to send two transactions. The first transaction was to take ownership of the contract found at the following link:
Browse to the above URL and click the "click to see more" link to review the live data from the output also showed and described in detail below. The transaction Input data shown made a call to the initWallet function. This call overwrote the owners of the contract with the attacker's address at [4] within the input data section.
Let's go into a little detail as to what the transaction values above are and how they were derived. This will help in understanding what is going on with this attack.
The data in the transaction can be broken down as the following
üA 4byte MethodID
üFive 32-byte values
The 4-byte MethodID which precedes the function parameters is the first 4 bytes of a sha3 hash of the initWallet method declaration. We can derive the sha3 value from the transaction by using the web3 utility functions and a substring of the sha3 output. You can try this out with the following commands.
The 5 parameters following the MethodID are defined as follows:
ü[0] Offset to the Owners Array length value: 60Hex or 96 bytes (3x32 = 96bytes to the Array length held at [3])
ü[1] How many owners are needed (Zero)
ü[2] Daily spending limit of the contract (A Large Number)
ü[3] Owners Array Length of 1 owner
ü[4] Attackers address value as the only address in the owner's array
A second transaction shown below, was then sent which transferred _value at [1] to the supplied _to address at [0] within the data section of the following transaction
Within the parity wallet there was a default payable function also known as a fallback function which used a delegate call into the wallet library. Fallback functions are called when a call is made to a contract and no function is specified while sending value to a contract. Using this functionality an attacker was able to access the fallback function and leverage the delegate call by calling the contract and NOT specifying a function but specifying msg.data with the target and values shown in the above exploit.
Fallback functions are often used as a catchall within contracts. I kind of think of them as the default from a switch statement or the else clause in a block of logic. You will see fallback functions aid us in many attacks for example tx.origin and reentrancy attacks. You also saw the usage of fallback functions in our chapter on reentrancy, when we used the functionality of a fallback function to loop through the contract calls and siphon value from the contract.
Taking a look at line 431 of the source code from the above link, this fallback function exposes all public functions of the wallet library to anyone with the fallback functions ability to send data into the wallet library via a delegatecall in the context of the calling contract on line 436. No worries, will explain context in a minute in our how delegate calls work section.
Notice that on line 435, the code logic states that if there is data within the transaction greater than 0 a delegate call is made which calls the wallet library in the context of the calling contract. We showed this above with the actual transaction data. But from a higher level the attacker used this logic to pass data to the wallet contract to perform the following to actions:
1.First calling the initWallet function as in the first transaction data we showed.
2.Followed by the execute function to both take ownership of a wallet via the wallet's fallback functionality and then transfer out the wallet's funds.
In order to perform this attack, all the attacker needs to do is:
üMake a transaction call to the wallet address
üNot specify a function in the in the wallet in order to invoke the fallback function
üSend msg.data with the values we saw in the attack transactions above
The fallback function will capture this transaction and forward it to the wallet library for us via a delegate call.
This attack resulted in millions of dollars of losses for users of the Parity wallet. I wanted to show an example of a real-world attack so you could see how it was constructed and know how serious this issue is. Millions of dollars can be lost with a relatively simple attack, in this case 31 million.
