viernes, 22 de mayo de 2020

DSploit

DSploit

After playing with the applications installed on the Pwn Pad, I found that the most important application (at least for me) was missing from the pre-installed apps. Namely, DSploit. Although DSploit has tons of features, I really liked the multiprotocol password sniffing (same as dsniff) and the session hijacking functionality.

The DSploit APK in the Play Store was not working for me, but the latest nightly on http://dsploit.net worked like a charm.

Most features require that you and your target uses the same WiFi network, and that's it. It can be Open, WEP, WPA/WPA2 Personal. On all of these networks, DSploit will sniff the passwords - because of the active attacks. E.g. a lot of email clients still use IMAP with clear text passwords, or some webmails, etc. 

First, DSploit lists the AP and the known devices on the network. In this case, I chose one victim client.


In the following submenu, there are tons of options, but the best features are in the MITM section. 


Stealthiness warning: in some cases, I received the following popup on the victim Windows:


This is what we have under the MITM submenu:


Password sniffing

For example, let's start with the Password Sniffer. It is the same as EvilAP and DSniff in my previous post. With the same results for the popular Hungarian webmail with the default secure login checkbox turned off. Don't forget, this is not an Open WiFi network, but one with WPA2 protection!


Session hijack

Now let's assume that the victim is very security-aware and he checks the secure login checkbox. Another cause can be that the victim already logged in, long before we started to attack. The session hijacking function is similar to the Firesheep tool, but it works with every website where the session cookies are sent in clear text, and there is no need for any additional support.

In a session hijacking attack (also called "sidejacking"), after the victim browser sends the authentication cookies in clear text, DSploit copies these cookies into its own browser, and opens the website with the same cookies, which results in successful login most of the time. Let's see session hijacking in action!

Here, we can see that the session cookies have been sniffed from the air:


Let's select that session, and be amazed that we logged into the user's webmail session.




Redirect traffic

This feature can be used both for fun or profit. For fun, you can redirect all the victim traffic to http://www.kittenwar.com/. For-profit, you can redirect your victim to phishing pages.


Replace images, videos

I think this is just for fun here. Endless Rick Rolling possibilities.


Script injection

This is mostly for profit. client-side injection, drive-by-exploits, endless possibilities.

Custom filter

If you are familiar with ettercap, this has similar functionalities (but dumber), with string or regex replacements. E.g. you can replace the news, stock prices, which pizza the victim ordered, etc. If you know more fun stuff here, please leave a comment (only HTTP scenario - e.g. attacking Facebook won't work).

Additional fun (not in DSploit) - SSLStrip 

From the MITM section of DSploit, I really miss the SSLStrip functionality. Luckily, it is built into the Pwn Pad. With the help of SSLStrip, we can remove the references to HTTPS links in the clear text HTTP traffic, and replace those with HTTP. So even if the user checks the secure login checkbox at freemail.hu, the password will be sent in clear text - thus it can be sniffed with DSniff.

HTML source on the client-side without SSLstrip:


HTML source on the client-side with SSL strip:


With EvilAP, SSLStrip, and DSniff, the password can be stolen. No hacking skillz needed.

Lessons learned here

If you are a website operator where you allow your users to login, always:
  1. Use HTTPS with a trusted certificate, and redirect all unencrypted traffic to HTTPS ASAP
  2. Mark the session cookies with the secure flag
  3. Use HSTS to prevent SSLStrip attacks
If you are a user:
  1. Don't trust sites with your confidential data if the above points are not fixed. Choose a more secure alternative
  2. Use HTTPS everywhere plugin
  3. For improved security, use VPN
Because hacking has never been so easy before.
And last but not least, if you like the DSploit project, don't forget to donate them!
Related articles

jueves, 21 de mayo de 2020

How To Secure Your Home Against "Internet Of Things" And FUD

TL;DR, most of the security news about IoT is full of FUD. Always put the risks in context - who can exploit this and what can the attacker do with it. Most story only covers the latter.

Introduction

There is rarely a day without news that another "Internet of Things" got hacked. "Smart" safes, "smart" rifles, "smart" cars, "smart" fridges, "smart" TVs, "smart" alarm systems, "smart" meters, "smart" bulbs, NAS devices, routers. These devices are getting hacked every day. Because most of these devices were never designed with security as a goal, and some of them have been never tested by security professionals, it is no surprise that these things are full of vulnerabilities.





Independent security researchers find these vulnerabilities, write a cool blog post or give a presentation about the vulnerability and the exploit, and the media forgets the constraints just for the sake of more clicks. "We are all doomed" we can read in the news, but sometimes the risks are buried deeply in technical jargon. Please note I blame the news sites here, not the researchers.

http://www.slideshare.net/danielmiessler/iot-attack-surfaces-defcon-2015

There are huge differences between the following risks:

  • Attackers can directly communicate with the router (or camera) from the Internet without authentication and exploit the vulnerability. This is the worst-case scenario. For example, an automated ransomware attack against your NAS is pretty bad.
  • Attackers have to position themselves in the same WAN network (e.g. Sprint mobile network in the case of Jeep hacking) to exploit the vulnerability. This is still pretty bad.
  • The vulnerable code can not be triggered directly from the Internet, but tricks like CSRF can be used to exploit it (details later in this post). 
  • The vulnerable code can not be triggered directly from the Internet, and it uses a protocol/port which prevents Cross Protocol Scripting. Attackers have to access the local network before exploiting this vulnerability.
As it is the case with the worst scenario, one can find a lot of devices connected to the internet. You can always find funny stuff at http://explorer.shodanhq.com/#/explore , or use the nmap screenshot script to find your own stuff :)


Network exposure

Most devices are behind an IPv4 NAT device (e.g. home router), thus can not be reached from the Internet side by default. Except when the device configures the firewall via UPNP. Or the device has a persistence cloud connection, and the cloud can send commands to the device. Or the device uses IPv6 tunneling (e.g. Teredo), thus it is reachable from the Internet. But not every vulnerability on your home network is accessible directly from the Internet. As more and more devices and networks will support IPv6, this scenario might change, but I hope most home routers will come with a default deny configuration in their IPv6 firewall module. On the other hand, scanning for IPv6 devices blindly is not feasible due to the large number of IPv6 addresses, but some tricks might work

If attackers can not access the device directly, there is a way to hack it through the user's browser. Just convince the victim user to visit a website, and via CSRF (Cross Site Request Forgery) and brute-forcing the device IP, it is possible to hack some devices (mostly through HTTP - if the exploit can fit into simple GET or POST commands.

If attackers can not attack the device vulnerability through the Internet directly, or via CSRF, but have connected to the same network - the network exposure shrinks significantly. And when attackers are on the same network as you, I bet you have bigger problems than the security of the IoT devices ...

Recommendations for home users

Don't buy **** you don't need

Disconnect from the power cord the IoT devices you don't need to operate 7*24. 

Disable cloud connectivity if it is not necessary. For example, I have a NAS device that can be reached through the "cloud", but I have disabled it by not configuring any default gateway for the device. I prefer connecting to my network via VPN and reach all my stuff through that.

Prevent CSRF attacks. I use two tricks. Don't use the 192.168.0.x - 192.168.10.x network at-home - use an uncommon IP range instead (e.g. 192.168.156.x is better). The second trick is I configured my Adblock plugin in my primary browser to block access to my internal network. And I use another browser whenever I want to access my internal devices. Update: On Firefox you can use NoScript ABE to block access to internal resources.


Check your router configuration:

  • disable UPnP
  • check the firewall settings and disable unnecessary port forwards
  • check for IPv6 settings, and configure the firewall as default deny for incoming IPv6 TCP/UDP.

Change default passwords, especially for services connected to the Internet. Follow password best practices.

Run Nmap to locate new IoT in your home network :) 

Run a WiFi scan to locate new WiFi access points. Let me share a personal experience with you. I moved to a new house and brought my own WiFi router with me. I plugged it in, and forget about WiFi. Months later it turned out I had two other WiFi devices in my house - the cable modem had its own integrated WiFi with default passwords printed on the bottom, and the Set-top-box was the same - default WiFi passwords printed on the bottom. And don't forget to scan for ZigBee, Bluetooth, IrDA, FM, ...

Update your devices - in case you have a lot of free time in your hand.

Don't allow your guests to connect to your home network. Set up a separated AP for them. Imagine your nephew stealing your private photos or videos from your NAS or DNLA server.

With great power, comes great responsibility. The less device you own in your house, the less time you need to maintain those.

Read the manuals of your devices. Be aware of the different interfaces. Configure it in a secure way.

Disable Teredo protocol in case you don't need IPv6.

Stop being amazed by junk hacking.

Update: Disable WebRTC: https://www.browserleaks.com/webrtc , in Chrome you can use this extension: https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia

Update: Prevent against DNS rebind attacks via configuring a DNS server which can block internal IP addresses. OpenDNS can block internal IP, but this is not a default option, you have to configure it.

Recommendations for vendors

For vendors, I recommend at least the followings:

  • Implement security during Software Development LifeCycle
  • Continuous security testing and bug bounties
  • Seamless auto-update
  • Opt-in cloud connectivity

Recommendations for journalists

Stop FUD. Pretty please.

The questions to ask before losing your head

  • who can exploit the vulnerability?
  • what prerequisites do we have about the attack to successfully exploit the vulnerability? Is the attacker already in your home network? If yes, you have probably bigger problems.
  • what can the attacker do when the exploit is successful?

And last but not least, don't forget that in the case of IoT devices, sometimes users are the product, not the customer. IoT is about collecting data for marketing purposes.


Related news

One Reason Why InfoSec Sucked In The Past 20 Years - The "Security Tips" Myth

From time to time, I get disappointed how much effort and money is put into securing computers, networks, mobile phones, ... and yet in 2016 here we are, where not much has changed on the defensive side. There are many things I personally blame for this situation, and one of them is the security tips.

The goal of these security tips is that if the average user follows these easy to remember rules, their computer will be safe. Unfortunately, by the time people integrate these rules into their daily life, these rules either become outdated, or these rules were so oversimplified that it was never true in the first place. Some of these security tips might sound ridiculous to people in InfoSec nowadays, but this is exactly what people still remember because we told them so for years.

PDF is safe to open

This is an oldie. I think this started at the time of macro viruses. Still, people think opening a PDF from an untrusted source is safer than opening a Word file. For details why this is not true, check: https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/Adobe-Acrobat-Reader.html
On an unrelated note, people still believe PDF is integrity protected because the content cannot be changed (compared to a Word document).
Image stolen from Kaspersky

Java is secure

One of the best ones. Oracle started marketing Java as a safe language, where buffer overflows, format strings and pointer-based vulnerabilities are gone. Unfortunately, they forgot to tell the world that instead of "unsafe programs developed by others" they installed their unsafe program on 3 billion devices. 

Stay away from rogue websites and you will be safe

This is a very common belief I hear from average people. "I only visit some trusted news sites and social media, I never visit those shady sites." I have some bad news. At the time of malvertising and infected websites, you don't have to visit those shady sites anymore to get infected.

Don't use open WiFi

I have a very long explanation of why this makes no sense, see here. Actually, the whole recommendation makes no sense as people will connect to public WiFis, no matter what we (InfoSec) recommend.

The password policy nightmare

Actually, this topic has been covered by myself in two blog posts, see here and here. Long story short: use a password manager and 2-factor authentication wherever possible. Let the password manager choose the password for you. And last but not least, corporate password policy sux.

Sites with a padlock are safe

We tell people for years that the communication with HTTPS sites are safe, and you can be sure it is HTTPS by finding a randomly changing padlock icon somewhere next to the URL. What people hear is that sites with padlocks are safe. Whatever that means. The same goes for WiFi - a network with a padlock is safe.

Use Linux, it is free from malware

For years people told to Windows users that only if they would use Linux they won't have so much malware. Thanks to Android, now everyone in the world can enjoy malware on his/her Linux machine.

OSX is free from malware

It is true that there is significantly less malware on OSX than on Windows, but this is an "economical" question rather than a "security" one. The more people use OSX, the better target it will become. Some people even believe they are safe from phishing because they are using a Mac!

Updated AV + firewall makes me 100% safe

There is no such thing as 100% safe, and unfortunately, nowadays most malware is written for PROFIT, which means it can bypass these basic protections for days (or weeks, months, years). The more proactive protection is built into the product, the better!

How to backup data

Although this is one of the most important security tips which is not followed by people, my problem here is not the backup data advise, but how we as a community failed to provide easy to use ways to do that. Now that crypto-ransomware is a real threat to every Windows (and some OSX) users, even those people who have backups on their NAS can find their backups lost. The only hope is that at least OSX has Time Machine which is not targeted yet, and the only backup solution which really works.
The worst part is that we even created NAS devices which can be infected via worms ...

Disconnect your computer from the Internet when not used

There is no need to comment on this. Whoever recommends things like that, clearly has a problem.

Use (free) VPN to protect your anonimity

First of all. There is no such thing as free service. If it is free, you are the service. On another hand, a non-free VPN can introduce new vulnerablities, and they won't protect your anonymity. It replaces one ISP with another (your VPN provider). Even TOR cannot guarantee anonymity by itself, and VPNs are much worse.

The corporate "security tips" myth

"Luckily" these toxic security tips have infected the enterprise environment as well, not just the home users.

Use robots.txt to hide secret information on public websites

It is 2016 and somehow web developers still believe in this nonsense. And this is why this is usually the first to check on a website for penetration testers or attackers.

My password policy is safer than ever

As previously discussed, passwords are bad. Very bad. And they will stick with us for decades ...

Use WAF, IDS, IPS, Nextgen APT detection hibber-gibber and you will be safe

Companies should invest more in people and less into magic blinking devices.

Instead of shipping computers with bloatware, ship computers with exploit protection software
Teach people how to use a password safe
Teach people how to use 2FA
Teach people how to use common-sense

Conclusion

Computer security is complex, hard and the risks change every year. Is this our fault? Probably. But these kinds of security tips won't help us save the world. 

More information

miércoles, 20 de mayo de 2020

C++ Std::Condition_Variable Null Pointer Derreference


This story is about a bug generated by g++ and clang compilers (at least)
The condition_variables is a feature on the standard library of c++ (libstdc++), when its compiled statically a weird asm code is generated.


Any example on the link below will crash if its compiled statically:
 https://en.cppreference.com/w/cpp/thread/condition_variable



In this case the condition_variable.wait() crashed, but this happens with other methods, a simple way to trigger it:




If this program is compiled dynamically the crash doesn't occur:

Looking the dissasembly there is a surprise created by the compiler:


Compilers:
    g++  9.2.1+20200130-2
    clang++ v9

Both compilers are generating the "call 0x00"

If we check this call in a dynamic compiled:




The implementation of condition_variable in github:
https://github.com/gcc-mirror/gcc/blob/b7c9bd36eaacac42631b882dc67a6f0db94de21c/libstdc%2B%2B-v3/include/std/condition_variable


The compilers can't copile well this code in static,  and same happens on  other condition_variable methods.
I would say the _lock is being assembled improperly in static, is not exacly a null pointer derreference but the effects are the same, executing code at address 0x00 which on linux is a crash on most of cases.

Related news


  1. Hacking Quotes
  2. Que Es Growth Hacking
  3. Hacking With Swift
  4. Social Hacking
  5. Car Hacking
  6. Que Hace Un Hacker
  7. Hacking Wifi
  8. Servicio Hacker
  9. Significado Hacker

Hacking All The Cars - Part 2


Connecting Hardware to Your Real Car: 

 I realized the other day I posted Part 2 of this series to my youtube awhile ago but not blogger so this one will be quick and mostly via video walkthrough. I often post random followup videos which may never arrive on this blog. So if you're waiting on something specific I mentioned or the next part to a series its always a good idea to subscribe to the YouTube. This is almost always true if there is video associated with the post.  

In the last blog we went over using virtual CAN devices to interact with a virtual car simulators of a CAN network This was awesome because it allowed us to learn how to interact with he underlying CAN network without fear of hacking around on an expensive automobile. But now it's time to put on your big boy pants and create a real CAN interface with hardware and plug your hardware device into your ODB2 port. 

The video I created below will show you where to plug your device in, how to configure it and how to take the information you learned while hacking around on the virtual car from part1 and apply it directly to a real car.   

Video Walk Through Using Hardware on a Real Car




As a reference here are the two device options I used in the video and the needed cable: 

Hardware Used: 

Get OBD2 Cable:
https://amzn.to/2QSmtyL

Get CANtact:
https://amzn.to/2xCqhMt

Get USB2CAN:
https://shop.8devices.com/usb2can


Creating Network Interfaces: 

As a reference here are the commands from the video for creating a CAN network interface: 

USB2Can Setup: 
The following command will bring up your can interface and you should see the device light color change: 
sudo ip link set can0 up type can bitrate 125000

Contact Setup: 
Set your jumpers on 3,5 and 7 as seen in the picture in the video
Sudo slcand -o -s6 /dev/ttyACM can0 <— whatever device you see in your DMESG output
Ifconfig can0 up

Summary: 

That should get you started connecting to physical cars and hacking around. I was also doing a bit of python coding over these interfaces to perform actions and sniff traffic. I might post that if anyone is interested. Mostly I have been hacking around on blockchain stuff and creating full course content recently so keep a look out for that in the future. 

Related posts

Grok-backdoor - Backdoor With Ngrok Tunnel Support


Grok-backdoor is a simple python based backdoor, it uses Ngrok tunnel for the communication. Ngrok-backdoor can generate windows, linux and mac binaries using Pyinstaller.

Disclaimer:
All the code provided on this repository is for educational/research purposes only. Any actions and/or activities related to the material contained within this repository is solely your responsibility. The misuse of the code in this repository can result in criminal charges brought against the persons in question. Author will not be held responsible in the event any criminal charges be brought against any individuals misusing the code in this repository to break the law.

Dependencies:
  • Python 2.7
  • Pyinstaller 3.21
  • python-pip 9.0.1

Installation :
pip install -r requirements.txt

Usage:
You need to register an acccount in ngrok.com to use this backdoor, provide Ngrok authcode while configuring the grok-backdoor. You will see a new tcp tunnel created in Ngrok status panel after the grok-backdoor server execution in victim machine.
Create backdoor binary by running:
python grok-backdoor.py

Linux:


Windows :



You can find the output binary in grok-backdoor/dist/ directory:


Run grok-backdoor output binary in victim machine and login to Ngrok.com control panel to see the tunnel URL:


Telnet to tunnel URL to get the Bind shell: Enjoy shell :)


Features:
  • Multi platform support(windows,linux,Mac)
  • Autheticated bind shell
  • Ngrok tunnel for communication

Related news

martes, 19 de mayo de 2020

CEH: 10 Hacking Tools For Hackers


There are a lot of hacking tools available over the internet but mostly we need some of them. In this blog you'll learn about hacking tools which are typically used in the world of hacking by penetration testers.

SmartWhois

SmartWhois is an information-gathering program that allows you to find all available information about an IP address, hostname, or domain, including country, state or province, city, name of the network provider, administrator, and technical support contact information. SmartWhois is a graphical version of the basic Whois program.

SocksChain

SocksChain is a tool that gives a hacker the ability to attack through a chain of proxy servers. The main purpose of doing this is to hide the hacker's real IP address and therefore minimize the chance of detection. When a hacker works through several proxy servers in series, it's much harder to locate the hacker. Tracking the attacker's IP address through the logs of several proxy servers is complex and tedious work. If one of the proxy servers' log files is lost or incomplete, the chain is broken, and the hacker's IP address remains anonymous.

NeoTrace, VisualRoute, and VisualLookout

NeoTrace, VisualRoute, and VisualLookout are all packet-tracking tools with a GUI or visual interface. They plot the path the packets travel on a map and can visually identify the locations of routers and other internet working devices. These tools operate similarly to traceroute and perform the same information gathering; however, they provide a visual representation of the results.

Visualware's eMailTrackerPro

Visualware's eMailTrackerPro ( www.emailtrackerpro.com/ ) and MailTracking ( http://mailtracking.com/ ) are tools that allow an ethical hacker to track email messages. When you use these tools to send an email, forward an email, reply to an email, or modify an email, the resulting actions and tracks of the original email are logged. The sender is notified of all actions performed on the tracked email by an automatically generated email.

IPEye

IPEye is a TCP port scanner that can do SYN, FIN, Null, and XMAS scans. It's a command line tool.
IPEye probes the ports on a target system and responds with closed, reject, drop, or open. Closed means there is a computer on the other end, but it doesn't listen at the port. Reject means a firewall is rejecting the connection to the port (sending a reset back). Drop means a firewall is dropping everything to the port, or there is no computer on the other end. Open means some kind of service is listening at the port. These responses help a hacker identify what type of system is responding.

IPSecScan

IPSecScan is a tool that can scan either a single IP address or a range of addresses looking for systems that are IPSec enabled that means the system has IPSec enabled while disabled means that it either has IPSec disabled, the compatibility issue or the configuration issue that not reveal to you that it has IPSec enabled. Indeterminable means that the scanner isn't sure if IPSec is enabled or disabled.

Icmpenum

Icmpenum uses not only ICMP Echo packets to probe networks, but also ICMP Timestamp and ICMP Information packets. Furthermore, it supports spoofing and sniffing for reply packets. Icmpenum is great for scanning networks when the firewall blocks ICMP Echo packets but fails to block Timestamp or Information packets.

SNMP Scanner

SNMP Scanner allows you to scan a range or list of hosts performing ping, DNS, and Simple Network Management Protocol (SNMP) queries. This tool helps you to find out the current information about the device of SNMP nodes in the given network.

hping2 tool

The hping2 tool is notable because it contains a host of other features besides OS fingerprinting such as TCP, User Datagram Protocol (UDP), ICMP, and raw-IP ping protocols, traceroute mode, and the ability to send files between the source and target system.

THC-Scan, PhoneSweep, and TeleSweep

THC-Scan, PhoneSweep, and TeleSweep are tools that identify phone numbers and can dial a target to make a connection with a computer modem. These tools generally work by using a predetermined list of common usernames and passwords in an attempt to gain access to the system. Most remote-access dial-in connections aren't secured with a password or use very rudimentary security.

More information


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.

    Related articles