How do I get started with bug bounty hunting? How do I improve my skills?
These are some simple steps that every bug bounty hunter can use to get started and improve their skills:
Learn to make it; then break it! A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.
Read books. Lots of books. One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".
Join discussions and ask questions. As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.
Participate in open source projects; learn to code. Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.
Help others. If you can teach it, you have mastered it. Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.
Smile when you get feedback and use it to your advantage. The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.
Learn to approach a target. The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.
A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe." As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.
Brazil's biggest cosmetics company Natura accidentally left hundreds of gigabytes of its customers' personal and payment-related information publicly accessible online that could have been accessed by anyone without authentication. SafetyDetective researcher Anurag Sen last month discovered two unprotected Amazon-hosted servers—with 272GB and 1.3TB in size—belonging to Natura that consisted of
How does hacker use keylogger to hack social media account and steal important data for money extortion and many uses of keylogger ?
Types of keylogger?
===================
Keylogger is a tool that hacker use to monitor and record the keystroke you made on your keyboard. Keylogger is the action of recording the keys struck on a keyboard and it has capability to record every keystroke made on that system as well as monitor screen recording also. This is the oldest forms of malware.
Sometimes it is called a keystroke logger or system monitor is a type of surveillance technology used to monitor and record each keystroke type a specific computer's keyboard. It is also available for use on smartphones such as Apple,I-phone and Android devices.
A keylogger can record instant messages,email and capture any information you type at any time using your keyboard,including usernames password of your social media ac and personal identifying pin etc thats the reason some hacker use it to hack social media account for money extortion.
======================
Use of keylogger are as follows-
1-Employers to observe employee's computer activity.
2-Attacker / Hacker used for hacking some crucial data of any organisation for money extortion.
3-Parental Control is use to supervise their children's internet usage and check to control the browsing history of their child.
4-Criminals use keylogger to steal personal or financial information such as banking details credit card details etc and then which they will sell and earn a good profit.
5-Spouse/Gf tracking-if you are facing this issue that your Spouse or Gf is cheating on you then you can install a keylogger on her cell phone to monitor her activities over the internet whatever you want such as check Whats app, facebook and cell phone texts messages etc .
=====================
Basically there are two types of keylogger either the software or hardware but the most common types of keylogger across both these are as follows-
1-API based keylogger
2-Form Grabbing Based Keylogger
3-Kernal Based Keylogger
4-Acoustic Keylogger ETC .
====================
How to detect keylogger on a system?
An antikeylogger is a piece of software specially designed to detect it on a computer.
Sometype of keylogger are easily detected and removed by the best antivirus software.
You can view the task manager(list of current programs) on a windows PC by Ctrl+Alt+Del to detect it.
Use of any software to perform any illegal activity is a crime, Do at your own risk.
A step by step lab based mini course on analyzing your car network
I wanted to learn about hacking cars. As usual I searched around the internet and didn't find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn't attack your own Lambo, totally use your girlfriends Prius.
Below are the topics covered in this blogseries so you can decide if you want to read further:
Whats covered in this car hacking mini course:
Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware
The first thing we are going to do before we get into any car hacking specifics such as "WTF is CAN?", is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.
I also don't want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first.
Video Playlist:
Setting up your Lab:
First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away.
Install PreReq Libraries:
Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster:
Run the setup Script to get the vcan0 interface up:
root@kali:~/ICSim# ./setup_vcan.sh
root@kali:~/ICSim# ./icsim vcan0
On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0
Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator.
How to Use the Simulator:
The simulator has a speedometer with Right and Left turn signals, doors etc. Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator.
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors
Left Shift + X, A or be Close doors
Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic:
Awesome, thanks to OpenGarages you now you have your very own car to hack
Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0.
ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0 Link encap:UNSPECHWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.
With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic:
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0
Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it.
Capture and Replay CAN Actions:
One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.Or the door may not be connected to the network at all depending on your car and its age or how its configured.
Replaying dumps with CanPlayer:
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer.
Lab 1 Steps:
Run CanDump
Right Shift + X to open a door
Cancel CanDump (ctrl+c)
Left Shift + X to close the door
Run can player with the saved dump and it will replay the traffic and open the door
Recording the door opening:(-l for logging)
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0
Replaying the CanDump file:(use the file your can dump created)
Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.
Interacting with the Can Bus and Reversing Traffic:
So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic:
You will see 3 fields, Time, IDand Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.
The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in.
Determine which ID and Byte controls the throttle:
So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.This might take you a few minutes of paying attention to whats going on to see.
The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed.
The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed. The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.
Singling out Values with Filters:
If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.You will instead as shown below only have ID 244 in your output:
To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key. Now you should see all of the output as before.Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values.
Determine Blinker ID:
Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker.
This ID was not listed before as it was not in use within the data output until you pressed the blinker control.Lets single this value out by pressing -000000 followed by +188. Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values.
As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.
Time for YOU to do some Protocol Reversing:
This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.
Lab Work Suggestion:
Take out a piece of paper and a pencil
Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
Try unlocking each door and write down the BYTES needed for each door to open
Try locking each doors and what Bytes change and what are their values, write them down
Do the same thing for the blinkers left and right (Might be different then what I did above)
What ID is the speedometer using?What byte changes the speed?
Attacking Functionality Directly:
With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connectionor the center console units BLE connection which was connected to the CAN network in some way. After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile.
Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.Since we are remote to the target we can't just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend.
You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle.
My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph:
ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;done
Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right?
Monitor the CAN Bus and react to it:
Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.See below command and try this out.
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done
With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.
Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed.
So thats one way of monitoring the network and reacting to what you see in a very crude manner.Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in.
Conclusion and whats next:
I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong.
Welcome to my 4th new tutorial of the series of networking. In this blog you'll the content about network switches. You'll learn about how to make a communication successful and secure in the same network (LAN) by using STP. As Spanning tree protocol (STP) we used in multi-switched networks. Why we use this protocol in multi-switched network etc.
What is Switch?
A switch is an intelligent device used to connect multiple devices within the same network. The intelligence of is that it requires Media Access Control (MAC) address for communication and doesn't allow broadcast. Let's understand the whole thing by a little example, consider there is a network having 3 end devices name Device-A, Device-B,Device-C connected with each other respectively with the help of switch. When a Device-A sends data to Device-C so that data will only forwarded by switch to Device-C not to Device-B.
What is Media Access Control (MAC) address?
A Media Access Control (MAC) address is 48-bit unique physical address given to network interface controller (NIC) or network adapter, for communication within the same network which is given by its manufacturer. It is made up of hexadecimal numbers like a1:b1:cc:ac:2e:f1.
What is STP?
STP stands for Spanning tree protocol which is basically used in bridge and switches to prevent loops when you have a redundant links in the Ethernet networks. If the loop is present in the Ethernet network so the whole network will suffer because there will MAC instability in the MAC table, duplicate frames generation and so on. Let's move to the video for further detail.
In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them.
In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code?
Background
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,719,142 (2017/08/10).
Berkeley Open Infrastructure for Network Computing
To solve general scientific meaningful problems, Gridcoin draws on the well-known Berkeley Open Infrastructure for Network Computing (BOINC). It is a software platform for volunteer computing, initially released in 2002 and developed by the University of California, Berkeley. It is an open source software licensed under the GNU Lesser General Public License. The platform enables professionals in need for computation power to distribute their tasks to volunteers. Nowadays it is widely used by researchers with limited resources to solve scientific problems, for example, healing cancer, investigate global warming, finding extraterrestrial intelligence in radio signals and finding larger prime numbers. When launching a BOINC project, its maintainer is required to set up his own BOINC server. Project volunteers may then create accounts (by submitting a username, a password and an email address) and work on specific project tasks, called workunits. The volunteers can process the project tasks and transfer their solutions with a BOINC client.
BOINC architecture
BOINC uses a client-server architecture to achieve its rich feature set. The server component handles the client requests for workunits and the problem solutions uploaded by the clients. The solutions are validated and assimilated by the server component. All workunits are created by the server component and each workunit represents a chunk of a scientific problem which is encapsulated into an application. This application consists of one or multiple in-/output files, containing binary or ASCII encoded parameters.
BOINC terminology
iCPID
The BOINC project server creates the internal Cross Project Identifier (iCPID) as a 16 byte long random value during account creation. This value is stored by the client and server. From this time on, the iCPID is included in every request and response between client and server
eCPID
The external Cross Project Identifier (eCPID) serves the purpose of identifying a volunteer across different BOINC projects without revealing the corresponding email address. It is computed by applying the cryptographic hash function MD5 to (iCPID,email) and thus has a length of 16 byte [Source].
eCPID = MD5(iCPID||email)
Credits
BOINC credits are generated whenever a host submits a solution to an assigned task. They are measured in Cobblestone, whereas one Cobblestone is equivalent to 1/200 of CPU time on a reference machine with 1,000 mega floating point operation per seconds [Source]
Total Credit
Total number of Cubblestones a user invested with his machines for scientific computations
Recent Average Credit (RAC)
RAC is defined as the average number of Cobblestones per day generated recently [Source]. If an entire week passes, the value is divided by two. Thus old credits are weakly weighted. It is recalculated whenever a host generates credit [Source].
Gridcoin
As a fork of Litecoin, Gridcoin-Research is a blockchain based cryptocurrency and shares many concepts with Bitcoin. While Bitcoin's transaction data structure and concept is used in an unmodified version, Gridcoin-Research utilizes a slightly modified block structure. A Gridcoin-Research block encapsulates a header and body. The header contains needed meta information and the body encloses transactions. Due to the hashPrevBlockHeader field, which contains the hash of the previous block-header, the blocks are linked and form the distributed ledger, the blockchain. Blocks in the blockchain are created by so called minters. Each block stores a list of recent transactions in its body and further metadata in its header. To ensure that all transactions are confirmed in a decisive order, each block-header field contains a reference to the previous one. To regulate the rate in which new blocks are appended to the blockchain and to reward BOINC contribution, Gridcoin-Research implements another concept called Proof-of-Research. Proof-of-Research is a combination of a new overhauled Proof-of-BOINC concept, which was originally designed for Gridcoin-Classic and the improved Proof-of-Stake concept, inspired by alternative cryptocurrencies.
Fig. 1: Gridcoin block structure
Gridcoin terminology
In order to understand the attacks we need to introduce some Gridcoin specific terms.
eCPID
Identifier value from BOINC used in Gridcoin to identify the researcher.
CPIDv2
contains a checksum to prove that the minter is the owner of the used eCPID. We fully describe the content of this field in the last attack section.
GRCAddress
contains the payment address of the minter.
ResearchAge
is defined as the time span between the creation time of the last Proof-of-Research generated block with the user's eCPID and the time stamp of the last block in the chain measured in days.
RSAWeight
estimates the user's Gridcoin gain for the next two weeks, based on the BOINC contribution of the past two weeks.
Proof-of-Stake
Proof-of-Stake is a Proof-of-Work replacement, which was first utilized by the cryptocurrency Peercoin in 2012. This alternative concept was developed to showcase a working Bitcoin related currency with low power consumption. Therefore, the block generation process has been overhauled. To create a new valid block for the Gridcoin blockchain the following inequality have to be satisfied:
SHA256(SHA256(kernel)) < Target * UTXO Value + RSAWeight
The kernel value represents the concatenation of the parameters listed in Table 2. The referenced unspent transaction output (UTXO) must be at least 16 hours old. The so called RSAWeight is an input value to the kernel computation, it's indicates the average BOINC work, done by a Gridcoin minter. In direct comparison to Bitcoin's Proof-of-Work concept, it is notable that the hash of the previous block-header is not part of the kernel. Consequently, it is theoretically possible to create a block at any previous point in time in the past. To prevent this, Gridcoin-Research creates fixed interval checkpoint blocks. Once a checkpoint block is synchronized with the network, blocks with older time stamps became invalid. Considering the nature of the used kernel fields, a client with only one UTXO is able to perform a hash calculation each time nTime is updated. This occurs every second, as nTime is a UNIX time stamp. To be able to change the txPrev fields and thereby increase his hash rate, he needs to gain more UTXO by purchasing coins. Note that high UTXO and RSAWeight values mitigate the difficulty of the cryptographic puzzle, which increase the chance of finding a valid kernel. RSAWeight was explained above. Once a sufficient kernel has been found, the referenced UTXO is spent in a transaction to the creator of the block and included in the generated block. This consumes the old UTXO and generates a new one with the age of zero.
The Gridcoin-Research concept does not require much electrical power, because the maximum hash rate of an entity is limited by its owned amount of UTXOs with suitable age.
Proof-of-Research
Minters relying solely on the Proof-of-Stake rewards are called Investors. In addition to Proof-of-Stake, Gridcoin gives minters a possibility to increase their income with Proof-of-Research rewards. The Proof-of-Research concept implemented in Gridcoin-Research allows the minters to highly increase their block reward by utilizing their BOINC Credits. In this case the minter is called a Researcher. To reward BOINC contribution, relevant BOINC data needs to be stored in each minted block. Therefore, the software uses the BOINCHash data structure, which is encapsulated in the first transaction of each block. The structure encloses the fields listed in Table 6. The minting and verification process is shown in Figure 2 and works as follows:
A minter (Researcher) participates in a BOINC project A and performs computational work for it. In return the project server increases the users Total Credit value on the server. The server therefore stores the minter's email address, iCPID, eCPID and RAC.
Statistical websites contact project server and down-load the statistics for all users from the project server (A).
After the user earns credits, his RAC increases. Consequently, this eases the finding of a solution for the Proof-of-Stake cryptographic puzzle, and the user can create (mint) a block and broadcast it to the Gridcoin network.
Another minter (Investor or Researcher) will receive the block and validate it. Therefore, he extracts the values from the BOINCHash data structure inside the block.
The minter uses the eCPID from the BOINCHash to request the RAC and other needed values from a statistical website and compares them to the data extracted from the BOINCHash structure, in the event that they are equal and the block solves the cryptographic puzzle, the block is accepted.
Fig. 2: Gridcoin architecture and minting process
Reward calculation
The total reward for a solved block is called the Subsidy and is computed as the sum of the Proof-of-Research and the Proof-of-Stake reward.
If a minter operates as an Investor (without BOINC contribution), the eCPID is set to the string Investor and all other fields of the BOINCHash are zeroed. An Investor receives only a relatively small Proof-of-Stake reward. Because the Proof-of-Research reward is much higher than its Proof-of-Stake counterpart, contributing to BOINC projects is more worth the effort.
Statistic Website
At the beginning of the blog post, the core concept behind BOINC was described. One functionality is the creation of BOINC Credits for users, who perform computational work for the project server. This increases the competition between BOINC users and therefore has a positive effect on the amount of computational work users commit. Different websites 4 collect credit information of BOINC users from known project servers and present them online. The Gridcoin client compares the RAC and total credit values stored in a new minted block with the values stored on cpid.gridcoin.us:5000/get_user.php?cpid=eCPID where eCPID is the actual value of the researcher. If there are differences, the client declines the block. In short, statistical websites are used as control instance for Gridcoin. It is obvious that gridcoin.us administrators are able to modify values of any user. Thus, they are able to manipulate the amount of Gridcoins a minter gets for his computational work. This is crucial for the trust level and undermines the general decentralized structure of a cryptocurrency.
Project Servers
Gridcoin utilizes BOINC projects to outsource meaningful computation tasks from the currency. For many known meaningful problems there exist project servers 5 that validate solutions submitted by users, 6 and decide how many credits the users receive for their solutions. Therefore, the project servers can indirectly control the amount of Gridcoins a minter gets for his minted block via the total credit value. As a result, a Gridcoin user also needs to trust the project administrators. This is very critical since there is no transparency in the credit system of project server. If you want to know why decentralization is not yet an option, see our paper from WOOT'17.
Attacks
In addition to the trust a Gridcoin user needs to put into the project server and statistic website administrators, Gridcoin suffers from serious flaws which allows the revelation of minter identities or even stealing coins. Our attacks do not rely on the Gridcoin trust issues and the attacker does not need to be in possession of specific server administrative rights. We assume the following two simple attackers with limited capability sets. The first one, is the blockchain grabber which can download the Gridcoin blockchain from an Internet resource and runs a program on the downloaded data. The second one, the Gridcoin attacker, acts as a normal Gridcoin user, but uses a modified Gridcoin client version, in order to run our attacks.
Interestingly, the developer of Gridcoin tried to make the source code analysis somewhat harder, by obfuscating the source code of relevant functions.
Fig. 3: Obfuscated source code in Gridcoin [Source]
Grab Gridcoin user email addresses
In order to protect the email addresses of Gridcoin Researchers, neither BOINC project websites nor statistical websites directly include these privacy critical data. The statistical websites only include eCPID entries, which are used to reward Gridcoin Researchers. However, the email addresses are hidden inside the computation of the BOINCHash (cf. Table 1). A BOINCHash is created every time a Researcher mints a new block and includes a CPIDv2 value. The CPIDv2 value contains an obfuscated email address with iCPID and a hash over the previous blockchain block.
By collecting the blockchain data and reversing the obfuscation function (cf. Figure 4 and Figure 7), the attacker gets all email addresses and iCPIDs ever used by Gridcoin Researchers. See the reversed obfuscation function in Figure 4 and Figure 5.
Evaluation
We implemented a deobfuscation function (cf. Figure 7) and executed it on the blockchain. This way, we were able to retrieve all (2709) BOINC email addresses and iCPIDs used by Gridcoin Researchers. This is a serious privacy issue and we address it with our fix (cf. The Fix).
Steal Gridcoin users BOINC reward
The previous attack through deobfuscation allows us to retrieve iCPID values and email addresses. Thus, we have all values needed to create a new legitimate eCPID. This is required because the CPIDv2 contains the last block hash and requires a re-computation for every new block it should be used in. We use this fact in the following attack and show how to steal the computational work from another legitimate Gridcoin Researcher by mining a new Gridcoin block with forged BOINC information. Throughout this last part of the post, we assume the Gridcoin Minter attacker model where the attacker has a valid Gridcoin account and can create new blocks. However, the attacker does not perform any BOINC work.
Tab. 1: BOINCHash structure as stored and used in the Gridcoin blockchain.
As stated at the beginning of the blog post, the pre-image of the eCPID is stored obfuscated in every Gridcoin block, which contains a Proof-of-Research reward. We gathered one pre-image from the minted blocks of our victim and deobfuscated it. Thus, we know the values of the iCPID, and the email address of our victim. Subsequently, use the hash of the last block created by the network and use these three values to create a valid CPIDv2. Afterwards we constructed a new block. In the block we also store the current BOINC values of our victim, which we can gather from the statistics websites. The final block is afterwards sent into the Gridcoin network. In case all values are computed correctly by the attacker, the network will accept the block, and resulting in a higher reward for the attacker, consisting of Proof-of-Stake and Proof-of-Research reward.
Fig. 4: Obfuscation function
Fig. 5: Deobfuscation function
Evaluation
In order to verify our attacks practically, we created two virtual machines (R and A), both running Ubuntu 14.04.3 LTS. The virtual machine R contained a legitimate BOINC and Gridcoin instance. It represented the setup of a normal Gridcoin Researcher. The second machine A contained a modified Gridcoin-Research client 3.5.6.8 version, which tried to steal the Proof-of-Research reward of virtual machine R. Thus, we did not steal reward of other legitimate users. The victim BOINC client was attached to the SETI@home project 11 with the eCPID 9f502770e61fc03d23d8e51adf7c6291.
The victim and the attacker were in possession of Gridcoins, enabling them to stake currency and to create new blocks.
Fig. 6: CPIDv2 calculation deobfuscated
Initially both Gridcoin-Research clients retrieved the blockchain from other Gridcoin nodes in the Gridcoin network.
The Gridcoin attack client made it possible to specify the victim email address, iCPID and target project. All these values can be retrieved from the downloaded blockchain and our previous attack via the reverseCPIDv2 function as shown in Figure 7. The attack client read the iCPID and email address of the victim from a modified configuration file. All other values, for example, RAC or ResearchAge, were pulled from http://cpid.gridcoin.us:5000/get_user.php?cpid=. As soon as all values were received, the client attempted to create a new valid block.
Fig. 7: Reverse the CPIDv2 calculation to get iCPID and email address
Once a block had been created and confirmed, the attacker received the increased coin reward with zero BOINC contribution done. The attack could only be detected by its victims because an outside user did not know the legitimate Gridcoin addresses a Researcher uses.
All blocks created with our victim's eCPID are shown in Table 2. Illegitimate blocks are highlighted. We were able to mint multiple illegitimate blocks, and thus stealing Research Age from our victim machine R. All nine blocks created and send by our attacker to the Gridcoin network passed the Gridcoin block verification, were confirmed multiple times, and are part of the current Gridcoin blockchain. During our testing timespan of approximately three weeks, the attacker machine was wrongfully rewarded with 72.4 Proof-of-Research generated Gridcoins, without any BOINC work. The results show that the attack is not only theoretically possible, but also very practical, feasible and effective. The attack results can be reproduced with our Gridcoin-Research-Attack client.
Tab. 2:Blocks minted with the victim's eCPID
The Fix
In order to fix the security issue, we found one solution which does not require any changes to the BOINC source code nor the infrastructure. It is sufficient to change some parts of the already existing Gridcoin Beacon system. Thus, our solution is backwards compatible. The current Gridcoin client utilizes so called Beacons to register new eCPIDs and stores them as a transaction of 0.0001 Gridcoins in a Superblock which is created every 24 hours. A Beacon encloses the user's personal eCPIDs, a corresponding unused (but irreversible) CPIDv2, and the wallet's main Gridcoin payment address. Once the Superblock is created, the eCPIDs is bound to one Gridcoin payment address. During the block verification process this bond is unfortunately not checked. Furthermore, the existing Beacon system does not use any strong asymmetric cryptography to ensure authenticity and integrity of the broadcasted data. We propose to extend the Beacon system with public key cryptography. In detail, we suggest that a user binds his fresh public key PK_1 to a newly generated eCPID, and then storing them together in a Superblock. An initial Beacon would therefore contain a hashed (e.g. SHA-256) eCPID, the public key, a Nonce, and a cryptographic signature created with the corresponding secret key SK_1 of the public key. This allows only the owner of the secret key to create valid signatures over blocks created with his eCPID. Thus, an adversary first needs to forge a cryptographic signature before he can claim Proof-of-Research work of another Gridcoin user. Thus, he is not capable of stealing the reward of the user.
Beacon to create a eCPID, public/secret key pair bond
For verification purposes nodes fetch the corresponding latest public key from one of the Superblocks. Furthermore, this Beacon structure allows a user to replace his previous public key associated with his eCPID. This is realized by submitting a new Beacon with a new public key PK_2, signed with his old secret key.
Beacon to update a eCPID, public/secret key pair bond
All Beacons in the chain are verifiable and the latest public key is always authentic. The Nonce provide freshness for the signature input, and therefore prevent replay attacks against the Beacon system. Note that the eCPID needs to be completely unknown to the network, when sending the initial Beacon, for this concept to work as intended. The hash function ensures, that the Beacon does not reveal the fresh eCPID. As a result, an attacker is unable to mint with a eCPID even if he was able to intercept an initial Beacon and replaced the public key and signature with his own parameters, beforehand. This solution does not require any changes in the BOINC source code or the project servers.
Sign a block
In order to claim the Proof-of-Research reward for a newly created block, the Gridcoin minter computes a signature over the hash of the blockheader. Afterwards, he stores the resulting value at the end of the corresponding block in a new field. The private key used for the signature generation must correspond to the advertised public key by the user. It is important to note that the signature value is not part of the Merkle tree, and thus does not change the blockheader. In the end, the signature can then be verified by every other Gridcoin user via the advertised public key corresponding to the eCPID of the Gridcoin minter.
Responsible Disclosure
The attacks and the countermeasures were responsibly disclosed to the Gridcoin developer on the 14th of September, 2016. The developer used our proposed countermeasures and started to implement a new version. Since version 3.5.8.8, which is mandatory for all Gridcoin users, there exists an implementation, which contains countermeasures to our reward stealing attack. See our next blog post, why Gridcoin is still insecure and should not be used anymore.
Further Reading
A more detailed description of Gridcoin and the attacks will be presented at WOOT'17, the paper is available here.
Research: Dr. Web. Linux.Lady
More info