Hacking Your Way Into DefCon27 — An Insider’s Takeaways
DefCon27 just finished, and one more year it has been an amazing experience.
This is my fourth time over Las Vegas, and it was long overdue that I share what I saw and learned there with the rest of the planet.
If you are a blockchain enthusiast who couldn’t attend, this article will give you a good overview of the event.
Monero Village vs Blockchain Village
There were a lot of interesting blockchain discussions and presentations this year at Defcon27.
Coinbase run the ‘Blockchain Village’, and the community-driven Monero project run their own ‘Monero Village.’
Across both Villages one could notice a significant bias towards Monero: they had a strong developer and research representation.
Although they managed to avoid being directly salesy of Monero, panel discussions and presentations overall had the feel that they had been crafted to show Monero in a positive light.
Monero had lots of merchandise to give away including t-shirts, hoodies, stickers, electronic badge, poker chips, books on Monero and more.
They had a lead researcher and a lead developer there as well with whom I had the pleasure of connecting, and well as other people from several blockchain projects.
Coinbase Security Presentation
Coinbase had someone from their security team give an interesting presentation on their work profiling activity on the cryptocurrencies listed.
They monitor for a wide range of suspicious behaviour such as multiple blocks suddenly being made available to switch to a new chain. Coinbase Security will scan for any accounts impacted for any of the transactions in the newly revealed blocks.
Is there a double spend happening or something else?
What they’ve found is these kinds of attack happen in the same way:
There will typically be a short attack with just a couple of blocks released and with no accounts impacted by the transactions in the new blocks. This is the attackers testing that they can pull off the attack.
Days or weeks later a larger scale attack of the same kind happens with more blocks and one or more impacted accounts. This is the real attack.
What’s interesting is that this approach is generally followed in most attacks which shows that attackers have developed a process that includes design, testing and deployment.
But this allows Coinbase and others to expect an attack. Generally Coinbase monitors and suspends trading when they expect or see an attack unfolding.
Another challenge for Coinbase is confidential blockchains.
As an exchange they have to be able to see transactions to comply with regulations and to identify suspicious behaviour/attacks. With confidential blockchains they can’t do this which is why they can’t list confidential blockchains.
They presently have no solution to this.
Same goes for hybrid public/private blockchains: would it be sufficient for listing only non-confidential transactions or would the fact that other transactions are confidential preclude being listed by such compliant exchanges?
“You can have the best security around your node but are you sure your suppliers/partners have the same care around their nodes?”
False Security in Private Blockchains
There was a compelling argument put forward as to why private blockchains presently increase risk to businesses using them over centralised databases or even some public blockchains.
The argument centres around the idea that businesses believe that if they use a private blockchain then they don’t have to worry about people seeing the transactions recorded.
If I run nodes on approved machines then only they will see the transactions.
But as we know there are data breaches daily and so it must be assumed that the same breach risk applies to those nodes. If the only security is the firewalls around those nodes then the same threat exists for stealing data that exists for centralised databases.
Actually the risk is increased since while a centralised database might be a few servers linked together requiring an attacker to compromise a specific single location, a private blockchain network means an attacker now has multiple locations to attack and he only needs to succeed at one to expose the data.
You can have the best security around your node but are you sure your suppliers/partners have the same care around their nodes?
So for private networks you need to put in place all the same security and measures as you would a centralised database, applied to each node.
Alternatively, apply confidential transactions even on a private network with good key management so if someone compromises a node they won’t necessarily see all or even any of the transactions.
Also, be sure to think of security in the broadest terms, not only how transactions are stored.
The researcher in question was taking work he was involved in at 3 letter agencies to compromise CA’s and then use that man in the middle communications with email providers then password reset services which send the reset to the compromised email and then take control of the service.
Cloud services were a particularly interesting target since he was then able to retrieve the disk encryption keys for the targets home and company machines (MacOS and Windows etc) which were automatically backed up to the cloud.
They had found that not a single public CA was correctly configured to defend against the attacks and so the only mitigation is to configure a private CA.
Combine this with DNS attacks that were demonstrated and you can cause serious problems. The only public DNS that they found that supported all modern standards and so secure was Cloudflare.
So the overall lessons from those particular presentations were to not trust public CA’s, use encrypted DNS lookups but ensuring it’s using the latest standards and recommendations (Cloudflare or your own) and apply all the latest security standards with email providers including where a reset requires two forms of 2FA such as reset email to receive an email with a reset link and token that then requires a different 2FA as part of the reset.
Most email providers actually do it all via email so if you’re man in the middling the connection then you get everything you need to take over the email.
GDPR
As it was pointed out by Coinbase regulator team, GDPR was developed before blockchain was mainstream and so right now the regulators are having to go back and revisit GDPR within the world of blockchain.
The technology isn’t going anywhere and so how does GDPR work within this technology?
“Blockchain is Twitter for your bank account.”
I quite liked that term because while it is an oversimplification that doesn’t take into account the pseudo-anonymous nature of Bitcoin, it is one way to look at cryptocurrencies that aren’t confidential by design.
“Bitcoin is a mass surveillance system.”
Digital signatures are admissible in court. Also, it exposes you to easy surveillance from people you deal with. Pay the guy who does your lawn in BTC and he can then check where else you’ve been spending money.
Most wallets still don’t generated new addresses for each transaction. This was by someone else who is a huge Bitcoin advocate, so much so that it was bordering on madness.
He believes CDN’s will be replaced by BDN’s (Bitcoin Delivery Networks) and that Netflix will be replaced with movies stored on chain. For as little as $75 in transaction fees over 748 transactions he was able to store a 67MB movie.
Playback was painful in the demo, he had a movie player that he’d written which went through all those transactions to extract movie data, combine it back into the movie file and play it back.
So expensive and slow and as a node operator I’m not sure I want to store the whole Internet on my computer.
“Public blockchain is trustless, well, not really, it’s trusting the protocols and implementation”
VDF Alliance
VDF Alliance presented Verifiable Delay Functions (VDFs) are functions that take a certain amount of time to compute and can’t be accelerated by running the same function in parallel.
Within blockchain it’s a way to inject randomness in a way that shouldn’t be possible to jump ahead of, useful for random number generators that are deterministic whether used for random selection systems (randomly choose workers for the pool) or gaming systems etc.
I’m not going to go deep into the topic, but here’s more if you want to learn more.
This seems to be an important area of research for us. IPFS is also working on VDF’s as a way of proving that data exists on a device after a period of time.
Another use is unstoppable disclosure for things like time locked zero days.
So I find a zero day and set it to be disclosed after a period of time, say 3 months, with the VDF ensuring it isn’t disclosed early or late but giving certainty that it will be disclosed on a known time.
CryptoCurrency Security Standard (CCSS)
A presentation by the CryptoCurrency Security Standard, a group working on the development of a three tier set of standards that really focus on key management and process.
No one has accomplished level 3 since that would be for super paranoids but level 1 is sufficient for most businesses and level 2 being a stretch goal.
They are working with auditors on these standards so businesses can become certified level 1 for example to give customers confidence that there is a process in place for protecting keys and funds within an organisation.
Blockchain Honeypots
A researcher has built honeypots for Bitcoin nodes. Essentially a service that listens on a port and reacts like Bitcoin.
He ran a bot, it got scanned then afterwards someone performed a brute force attack and broke in.
But the service just gave expected results without working on the mainnet so the attacker thought they were stealing keys and funds but weren’t. The attacker stole funds, then would have checked on a blockchain explorer and seen the transaction Id wasn’t there.
The next day he came in and did more before creating a request with three actions but his API didn’t support more than one action so it gave an error and the attacker would have realised it was a honeypot at that point and didn’t come back.
He published his code and workings for constructing such honeypots.
Honeypots did get me thinking about whether we do something for our public network to detect attackers. Someone else there suggested perhaps giving some dust to the attacker so it could be traced through. The security side should have some consideration but we don’t have the bandwidth to do it much justice right now.
Testing
Some good looks at things like using Ganash on Ethereum to quickly spin up a private test blockchain to test against.
Run Gnash to spin up a forked copy of the blockchain then test your exploit there. For example, work on that vulnerable smart contract to craft your transaction before running it on the main network.
Run a node on the main network and monitor the mempool for a transaction for a vulnerable smart contract. Extract the signature and submit your own transaction with a slightly higher gas price so yours gets run first.
Three tools were released that combine to provide an automated attack system.
Scans smart contract contracts and performs static analysis to go through every route through the contract, identifying vulnerable paths and the series of calls required to exploit the contract.
Front runs by checking the mempool every second for transactions that use a vulnerable path.
When a transaction arrives, such as a transaction calling “ClaimOwnership”, take the signature and create a matching transaction with a different public address to take control of the contract and transfer funds to supplied address.
Another example would be on-chain exchanges, monitor buys so you can see what people are buying then make the trade first.
Fast bug detection using symbolic execution of EVM bytecode (Mythril)
Exploit automation (Scrooge McEtherface)
Exploiting those who use automation tools (Theo)
Still With Me? Here’s More Stuff
It was interesting to hear a discussion on Ethereum’s new PoS research.
The first question asked by the audience is what consideration they’d given to the environment and the response was that it’s a good question but they’d not considered it at all.
Their focus is security and the environment isn’t something they’ve thought about so far but perhaps in the future they would.
They weren’t all blockchain presentations of course, I did come up for air from time to time for other types of presentation.
Perhaps one of the more fun presentations was by a hacker who got caught speeding and so spent the next year reverse engineering speed guns (radar and laser) to understand how they work.
From there he found common standards and differences which enabled the creation of counter measures for both.
X band, K band and Ka band radar work on specific frequencies which can be countered by firing a signal back at a specific frequency using a calculation provided to give a desired speed (demonstrated with software and hardware specs provided for building a suitable device which also talks to Google Maps to find the correct speed for the location, adjusting the frequency accordingly to ensure you’re always at the correct speed).
For fun, respond at Microwave oven 2.4Ghz which gives a speed of -97,420,118 mph. Laser is different since it measures distance not speed and requires a flat reflective surface. So these speed guns are aimed at a vehicle and moved around looking for such a surface.
A simple counter measure is changing materials to avoid reflecting or have moving flat surfaces so a signal can’t be reached.
Another way is that these laser systems work by sending pulses that are very weak to begin and are very very weak when they bounce back. It will fire around 50 times per second and so a sensor detects the signals, the gap between the first and second pulse is sufficient for a device to identify the make and model of the gun and to then give a suitable pulse back at a higher power than received.
A laser fun requires dozens of responses to create an accurate speed so its easy to identify the gun within two pulses and overpower the response to give the correct speed, the device can be built for around $8.
Much more of course but those are some of the highlights. Happy to answer your questions about DefCon27 and debate.
Darren
Darren is the CEO at Atlas City, the company behind the development of Catalyst Network.
Check out our website for more information.
