Black Stealer v2.1 is an advanced keylogger that can steal even saved passwords from the browsers and sends through Email and FTP. It's really easy to the crypt. Keylogger is a computer program that is a type of surveillance technology used to monitor and record each keystroke typed on a specific computer's keyboard by the user, especially in order to gain unauthorized access to the passwords and other confidential information. It's also called a keystroke logger or system monitor. Download black stealer v2.1 full.
It's a 32bits elf binary of some version of vsftpd, where it have been added a backdoor, they don't specify is an authentication backdoor, a special command or other stuff.
I started looking for something weird on the authentication routines, but I didn't found anything significant in a brief period of time, so I decided to do a bindiff, that was the key for locating the backdoor quickly. I do a quick diff of the strings with the command "strings bin | sort -u" and "vimdiff" and noticed that the backdoored binary has the symbol "execl" which is weird because is a call for executing elfs, don't needed for a ftp service, and weird that the compiled binary doesn't has that symbol.
Looking the xrefs of "execl" on IDA I found that code that is a clear backdoor, it create a socket, bind a port and duplicate the stdin, stdout and stderr to the socket and use the execl:
There are one xrefs to this function, the function that decides when trigger that is that kind of systems equations decision:
The backdoor was not on the authentication, it was a special command to trigger the backdoor, which is obfuscated on that systems equation, it was no needed to use a z3 equation solver because is a simple one and I did it by hand.
The equation:
cmd[0] = 69
cmd[1] = 78
cmd[1] + cmd[2] = 154
cmd[2] + cmd[3] = 202
cmd[3] + cmd[4] = 241
cmd[4] + cmd[5] = 233
cmd[5] + cmd[6] = 217
cmd[6] + cmd[7] = 218
cmd[7] + cmd[8] = 228
cmd[8] + cmd[9] = 212
cmd[9] + cmd[10] = 195
cmd[10] + cmd[11] = 195
cmd[11] + cmd[12] = 201
cmd[12] + cmd[13] = 207
cmd[13] + cmd[14] = 203
cmd[14] + cmd[15] = 215
cmd[15] + cmd[16] = 235
cmd[16] + cmd[17] = 242
The solution:
cmd[0] = 69
cmd[1] = 75
cmd[2] = 79
cmd[3] = 123
cmd[4] = 118
cmd[5] = 115
cmd[6] = 102
cmd[7] = 116
cmd[8] = 112
cmd[9] = 100
cmd[10] = 95
cmd[11] = 100
cmd[12] = 101
cmd[13] = 106
cmd[14] = 97
cmd[15] = 118
cmd[16] = 117
cmd[17] = 125
The flag:
EKO{vsftpd_dejavu}
The binary: https://ctf.ekoparty.org/static/pre-ekoparty/backdoor
Top 15 Best Operating System Professional Hackers Use
Top 15 Best Operating System Professional Hackers Use
A hacker is someone who seeks and exploits the weaknesses of a computer system or network computing. Hackers may be motivated by a multitude of reasons, such as profit, protest, challenge, enjoyment or to assess these weaknesses to help in removing them.
The listed operating systems are based on the Linux kernel so it is all free operating systems.
1. Kali Linux
Kali Linux maintained and funded by Offensive Security Ltd. and it is first on our list. Kali Linux is a Debian-derived Linux distribution designed for digital forensics and penetration testing. It was developed by Mati Aharoni and Devon Kearns of Offensive Security through rewriting BackTrack, its previous forensics Linux distribution based on Ubuntu. Kali Linux has a specific project for the withdrawal of compatibility and portability of Android-specific devices, called Kali Linux NetHunter. It is the first open test platform penetration Source for Nexus Android devices, created as a joint effort between the member of the Kali "BinkyBear" Security and offensive community. It supports Wireless 802.11 frame injection, one-click configurations MANA Evil access point, keyboard HID (Teensy as attacks), as well as attacks MITM USB Mala.
2. Back Box
Back Box is an evaluation penetration testing Linux distribution and Ubuntu-based security aimed at providing an analysis of computer network systems and toolkit. Desktop environment back box includes a complete set of tools needed for ethical hacking and security testing.
3. Parrot Security OS
Parrot Security OS is a GNU / Linux distribution based on Debian. Fue built in order to perform penetration tests (safety information), vulnerability assessment and mitigation, Computer Forensics and Anonymous Surfing. Ha been developed by the team of Frozen box.
Parrot is based on the stable branch (Jessie) of Debian, a Linux 4.1 kernel hardened customized with a branch grsecurity patched available. The desktop environment is MATE fork of Gnome 2, and the default display manager is LightDM. The project is certified to run on machines with 265MB of RAM minimum follow and it is suitable for both 32-bit (i386) and 64-bit (amd64), with a special edition that works on 32-bit machines of age (486). Moreover, the project is available for Armel and armhf architectures. It even offers an edition (both 32 bit and 64 bit) developed for servers only for pen testing cloud.
4. Live Hacking OS
Live Hacking OS is a Linux distribution packed with tools and utilities for ethical hacking, penetration testing, and countermeasure verification. It includes embedded GUI GNOME user. There is a second variation available which has only the command line and requires much fewer hardware requirements.
5. DEFT Linux
DEFT stands for Digital Evidence and Forensic Toolkit and it is a distribution of Linux open source software built around the DART (Toolkit for Advanced Response Digital) and is based on the Ubuntu operating system. It has been designed from scratch to offer some of the best computer forensics open source and incident response tools that can be used by individuals, IT auditors, investigators, military, and police.
6. Samurai Web Testing Framework
The Samurai Web Testing Framework is a live Linux environment which has been pre-configured to function as a web pen-testing environment. The CD contains the best of open source and free tools that focus on testing and websites that attack. In the development of this environment, it is based on our selection of tools that we use in our practice of security. Hence, it includes the tools that were used in the four steps of a pen-test web.
7. Network Security Toolkit
The Network Security Toolkit (NST) is a Live CD based on Linux that provides a set of security tools computing and open source network to carry out routine security tasks and diagnostic networks and tracing. The distribution can be used as an analysis of network security, validation and monitoring tool for servers hosting virtual machines. NST has management capabilities similar to Fedora packages and maintains its own repository of additional packages.
8. Bugtraq
Bugtraq is a mailing list dedicated to safety issues in computers. On-topic issues new discussions about vulnerabilities, security-related notices providers, operating methods, and how to fix them. This is a mailing list of large volume, and almost all new vulnerabilities are there. Bugtraq computer freaks and experienced developers are discussed, is available in Debian, Ubuntu and openSUSE 32 and 64-bit architectures.
9. NodeZero
NodeZero is an open source system based on the operating core derived from the most popular Linux distribution in the world, Ubuntu, and designed to be used for penetration testing operations. The distribution can be downloaded as an ISO image live DVD, which will also take place on computers that support both 32-bit (x86) and 64-bit (x86_64) instruction set. Besides the fact that it allows you to start the live system, start menu contains several advanced features such as the ability to perform a diagnostic test of system memory, boot from local disk options, start the installer directly and to start in safe graphics mode, text mode or in debug mode.
Default graphical desktop environment NodeZero is powered by GNOME, which uses the classic GNOME interface. It has a design of two panels and uses the default software repositories of Ubuntu.
10. Pentoo
Pentoo is a Live CD and Live USB OS designed for penetration testing and security assessment. It is based on Gentoo Linux, Pentoo is offered both as 32-bit and 64-bit live cd which is installable. Pentoo is also available as a superposition of an existing Gentoo installation. It has conductors packet injection patched wifi, GPGPU cracking software, and plenty of tools for penetration testing and security assessment. The kernel includes Pentoo grsecurity and PAX hardening and additional patches with the binary compiled from a string of hardened with the latest nightly versions of some tools that are available.
#11 Live Hacking OS
Well, this Linux distro actually comes with some useful hacking tools which are often used in penetration testing or ethical hacking purpose. Live Hacking OS consists of the GNOME inbuilt. The operating system is really easy to operate and it can work on less RAM.
#12 Knoppix STD
This is another best Linux distro which focuses on tools for computer security. Knoppix STD brings some advanced tools for Password cracking, Firewalls, Network Utilities, Honeypots, Wireless Networking and more. This is one of the most used operating systems for Hackers.
#13 Cyborg Hawk
Cyborg Hawk is a new operating system which is based on Ubuntu Linux. Well, lots of hackers talk about Cyborg hawk and its one of the most powerful and cutting-edge penetration testing distribution that has ever been created. The operating system houses more than 700 tools for different purposes.
#14 Blackbuntu
Well, this is another operating system which is based on Linux and it was specially developed for penetration testing. Well, the operating system is very famous amongst hackers and it offers an awesome platform to learn Information security.
#15 Weakerth4n
Well, this is another best operating system which is used by professional hackers. WeakerTh4n actually comes with lots of hacking tools and it's actually a modern operating system for WiFi Hacking. Some of the wireless tools include SQL Hacking, Password Cracking, WiFi attacks, Cisco exploitation and more.
In this chapter we will take a look at bypassing incorrectly coded value transaction patterns within Ethereum smart contracts. These incorrectly coded patterns can lead to Reentrancy attacks that ultimately allow an attacker to liquidate the contract of all of its funds without much effort. The incorrect order of operations allows an attacker to avoid require statements which check if a user's balance is high enough to send a transaction. We can use this to bypass incorrect logic patterns and drain a contract of its funds.
Reentrancy attacks allow an attacker to create a loop between a target contract and a malicious attacker owned contract. Instead of a normal user making a request, the request comes from the attacker's contract which does not let the target contracts execution complete until the evil tasks intended by the attacker are complete. Usually this task will be draining the funds out of the contract bit by bit until all of the contracts funds are transferred to the attacker's contract.
The checks effects interactions pattern is a secure coding pattern within Solidity on Ethereum which prevents an attacker from re-entering a contract over and over. It does this by ensuring that balances are updated correctly before sending a transaction. It does this by:
üChecking that the requirements are met before continuing execution.
üUpdating balances and making changes before interacting with an external actor
üFinally, after the transaction is validated and the changes are made interactions are allowed with the external entity
The incorrectly coded pattern that usually creates a vulnerable smart contract is the common sense approach that first checks if a user's balance is large enough for the transaction, then sends the funds to the user. Once the transaction goes through, without error, the amount is subtracted from the user's balance.
The problem is that if a hacker's contract calls the target smart contract rather than a valid user calling the contract, the hacker's contract can run code in a loop. The hacker can call the same function in the target contract again without ever reaching the code that subtracts from the user's balance. This means that the initial balance check that passed the first time will pass again and again and again because it is at the same balance that passed the first time. You see where this is going right? The transaction will continue until the balance for the whole contract is empty, rather than just the users balance. Let's take a look at a simple example in order to understand how this works.
19.function getBalance() public view returns (uint){
20.return balances[msg.sender];
21. }
22.}
Simple Reentrancy Target Analysis Video:
There are three functions in the above contract, but the one we need to pay special attention to is the one that interacts with outside users. The withdraw function sends funds to the address of the user who called the withdraw function. This would be classified as an interaction and needs to follow our secure pattern.
The line breakdown of the withdraw function is as follows:
üLine 12: Checks that you are only withdrawing the amount you have in your account or sends back an error.
üLine 13: Sends your requested amount to the address the requested a withdrawal.
üLine 15: Deducts the amount withdrawn from the accounts total balance.
üLine 16. Simply returns your current balance.
Based on the above breakdown this function is following a:
Checks à Interaction à Effects
which violates the
Checks à Effects à Interactions
Because we interact with an external entity prior to updating the effects, the target contract is at risk for a call by a malicious contract that executes a loop with a malicious purpose.
Essentially what will happen is that the attacker will use his own malicious contract to call the withdraw function after adding a small value to his account. When the withdraw function is called the attackers contract will attempt to withdraw a smaller amount then the attacker has in his account which will pass the Checks portion of the pattern on line 12.
Next the target contract will attempt to interact with the attacker's contract by sending the valid withdrawn value from the contract. However, the attacker will have a fallback function that receives the sent value and calls the withdraw function again.
The second time calling the target contract will result in the exact same checks and interaction without ever updating the balance via the Effects portion. Over and Over and Over again.
The Effects portion will only be updated after the attacker's loop ends and the damage is done. Which means that the attacker has withdrawn funds many times over, but only subtracted that value a single time. Potentially draining all of the funds of the contract.
If we take a look at the following attacker's contract, we will see how the attacker creates this loop and we can analyze the order of operations that makes this possible.
The attacking code above is used by the attacker to siphon funds from a vulnerable contract. The main attack code in this contract is found on lines 22-24. This code creates a looping condition into the other contract by using a fallback function.
What is a fallback function?
A fallback function is a default function in a contract that is called when no other function is specified. So, in this instance when the contract receives funds and no other directions from the withdraw function, then the fallback function will execute on line 22. The fallback function will check that the target contract still contains a balance larger then what we are requesting which is defined on line 8 as "1 Ether".
If this check passes then our contract calls back into the withdraw function again at line 24. Which starts the whole process over and over again until the balance of the target contract is less than 1 ether. Let's take a look at a graphical representation of this to help understand what's going on.
The picture above shows the target contract and the attackers contract side by side. The attack function calls into the withdraw function initially. Then the fallback function is entered from the withdrawal transaction and returns right back to the beginning of the withdraw function from the fallback functions call back into the contract. This forms the loop between withdraw and fallback until the contract is below 1 ether.
That explains the main attack portion of the contract. The other parts of this attacking contract are just helping setup for the attack for example the interface code at line 1 simply creates an interface into the target contract via its function definitions. This interface is then set to the address of the target contract on line 7. With this interface you can now call the functions directly with the bankAddress interface using the function name as seen in the deposit function and attack function to call deposit and withdraw.
There is one other function we didn't mention which has nothing to do with the attack but helps us claim our funds after the contract is sent the ether from the attack. This function is on line 18 named retrieveStolenFunds. It simply takes the balance of "this" contract and transfers it to our personal address.
Let's try attacking the banking contract to see Reentrancy in action. Type out the code above for the target contract and understand what each piece of the contract does. Then type out the attacker's contract and try to piece together what each part of the attack does and what the sequence of execution will be.
Note: It's important that you type out this code and do not copy paste as it will help you in spotting issues in the future and your understanding of how things work.
Action Steps:
üWith account 1 deploy the target simpleReentrancy contract
üDeposit 20 Ether into the account by adjusting the Value field and selecting Ether
üCopy paste the address of the target contract and enter it into the target Interface variable in the attackers contract
üDeploy the attacker's contract simpleReentrancyAttack contract
üDeposit 2 ether into your account using the attackers contract deposit function
üThen execute the attack function with the attack button
üWhy did it pause?
üWhen attack completes execution note your second accounts balance and click retrieveStolenFunds
üNote your new balance
After running the attack, you should have noticed that your balance was updated by roughly 22 ether give or take fees. This would be the balance of the target contract initially and your own balance returned. You would have also noticed a pause when you clicked attack. This is because you are waiting for the contracts loop to complete its execution. It was calling the contract over and over again until 22 times.
Exploiting Reentrancy on the Target Smart Contract:
Reentrancy is a relatively easy vulnerability to fix, yet also a very easy mistake to make. It's easy to make a mistake because the vulnerable logic makes sense in real world logic. The vulnerable code should function correctly, if it were not interacting with a malicious contract. However, we do not expect an attacker's contract to be the receiver of the withdraw, thus throwing a wrench in real world logic. This is why we need to re-code this to function correctly using a secure pattern when dealing with DApps and web3.0.
Now let's correct the coding pattern by switching the order of operations to first decrease the accounts balance and then complete then initiate the withdraw transaction. The following image shows both the vulnerable and fixed code, where the original code is the on top and the fixed code is below:
Action Steps:
üImplement these changes in your contract.
üRedeploy both contracts making sure to update the address of the target contract in the attacker's contract
üTry this attack again, following the steps from above and observe how the results vary
With this simple change, our contracts balance is not decreased with each call to the withdraw function only the attackers balance is reduced until the attacker runs out of funds. If the attacker were to keep calling this function, the require check at the beginning of the function would fail as soon as the attacker ran out of funds. However, due to the usage of Call.Value and the lack of error handling, the funds may be incorrectly handled in the contract and error checking must be manually implemented. This is what we will look at next in regards to low level vs high level transfer functions.
Another relevant topic is that of the ways to transfer funds within Solidity. The "call" which was used in the withdraw function is a low-level function which can lead to issues and is largely replaced by the usage of Send or Transfer. Let's break these out and explain them:
Call.value()()
üReturns false on failure
üForwards available gas
üLow level function
Call.Value is dangerous because it forwards all of the available gas allowing for a reentrancy attack. It also does not return an error message and requires you to parse out the return Boolean value and perform an action based on this check. For example, if you were to make changes in the effects prior to the call.value, you may need to manually revert these changes as part of your error checking actions.
Send()
üReturns false on failure
üForwards a gas value of 2300
üLow level function
The send function limits the gas value to 2300 which helps prevent a reentrancy as there is a limit to how much the function can actually do before it fails. However, this is also a low-level function and you must be mindful of the lack of errors when this does fail exactly like the Call.value.
Transfer()
üActually, throws an error on failure
üForwards a gas value of 2300
üHigh level function
The transfer function provides a gas limit like the Send function but additionally provides an error and will revert changes made to the user's balance.
All of these functions are available for sending value out of the contract, however, only use low level functions with caution, and make sure to do error checking and make decisions on those errors. This will prevent hidden bugs in your code from error conditions. Also make sure to properly follow the checks, effects, interactions pattern in your code.
The DAO attack was the most famous blockchain attack ever performed. The DAO was a venture capital fund which pooled investors Ether for funding projects much like a crowdfunding application. The project initially raised 12.7 million Ether which at the time was equal to about 150 million dollars.
This Smart Contract contained a SplitDao function meant for removing funds into a child DAO when a user didn't like a majority decision of how to use funds. However, a Reentrancy vulnerability within the split function was found that ultimately allowed the attacker to remove 3.6 million Ether from the contract. This was a lot of money, but the bigger issue was the decision made by the Ethereum community to roll back the transaction, and give the users their funds back. As this violates the immutability of the blockchain. This should never happen again, but due to the immaturity of the network at the time, they felt it was needed.
This is the only time the Ethereum network violated the immutability of the blockchain and rolled back transactions on the Ethereum blockchain. The decision created a major idealistic split in the Ethereum community resulting in a hard fork of the network. Because of this split we now Ethereum classic and Ethereum. The network hard forked into two separate chains. One that contains the loss of funds on Ethereum Classic and one chain that does not contain the rollback, which is what we know as Ethereum.
Below we can see a snipped version of the original SplitDAO function which contained the issue:
If you take a look at lines 7-11 you will see a violation of our Checks à Effects à Interactions pattern.
On line 7-8 the contract is making withdrawal calls. However, following these withdrawals, the balances are updated on lines 10-11. If the attacker were to call back into the splitDao function when the interaction happened on line 8 then the attacker is able to drain the contract of millions of dollars. The balances are never updated until the attackers code is finished with its functionality.
In this chapter we took a look at secure coding patterns and high vs low level functions. We then interacted with vulnerable smart contracts that violated these secure coding principals. We exploited and fixed these issues ourselves in order to show how simple mistakes lead to huge losses in the case of attacks such as the famous DAO attack.
