Bitcoin is a Cult

The Bitcoin community has changed greatly over the years; from technophiles that could explain a Merkle tree in their sleep, to speculators driven by the desire for a quick profit & blockchain startups seeking billion dollar valuations led by people who don’t even know what a Merkle tree is. As the years have gone on, a zealotry has been building around Bitcoin and other cryptocurrencies driven by people who see them as something far grander than they actually are; people who believe that normal (or fiat) currencies are becoming a thing of the past, and the cryptocurrencies will fundamentally change the world’s economy.

Every year, their ranks grow, and their perception of cryptocurrencies becomes more grandiose, even as novel uses of the technology brings it to its knees. While I’m a firm believer that a well designed cryptocurrency could ease the flow of money across borders, and provide a stable option in areas of mass inflation, the reality is that we aren’t there yet. In fact, it’s the substantial instability in value that allows speculators to make money. Those that preach that the US Dollar and Euro are on their deathbed have utterly abandoned an objective view of reality.

A little background…

I read the Bitcoin white-paper the day it was released – an interesting use of Merkle trees to create a public ledger and a fairly reasonable consensus protocol – it got the attention of many in the cryptography sphere for its novel properties. In the years since that paper was released, Bitcoin has become rather valuable, attracted many that see it as an investment, and a loyal (and vocal) following of people who think it’ll change everything. This discussion is about the latter.

Yesterday, someone on Twitter posted the hash of a recent Bitcoin block, the thousands of Tweets and other conversations that followed have convinced me that Bitcoin has crossed the line into true cult territory.

It all started with this Tweet by Mark Wilcox:

The value posted is the hash of Bitcoin block #528249. The leading zeros are a result of the mining process; to mine a block you combine the contents of the block with a nonce (and other data), hash it, and it has to have at least a certain number of leading zeros to be considered valid. If it doesn’t have the correct number, you change the nonce and try again. Repeat this until the number of leading zeros is the right number, and you now have a valid block. The part that people got excited about is what follows, 21e800.

Some are claiming this is an intentional reference, that whoever mined this block actually went well beyond the current difficulty to not just bruteforce the leading zeros, but also the next 24 bits – which would require some serious computing power. If someone had the ability to bruteforce this, it could indicate something rather serious, such as a substantial breakthrough in computing or cryptography.

You must be asking yourself, what’s so important about 21e800 – a question you would surely regret. Some are claiming it’s a reference to E8 Theory (a widely criticized paper that presents a standard field theory), or to the 21,000,000 total Bitcoins that will eventually exist (despite the fact that 21 x 10^8 would be 2,100,000,000). There are others, they are just too crazy to write about. Another important fact is that a block is mined on average on once a year that has 21e8 following the leading zeros – those were never seen as anything important.

This leads to where things get fun: the theories that are circulating about how this happened.

  • A quantum computer, that is somehow able to hash at unbelievable speed. This is despite the fact that there’s no indication in theories around quantum computers that they’ll be able to do this; hashing is one thing that’s considered safe from quantum computers.
  • Time travel. Yes, people are actually saying that someone came back from the future to mine this block. I think this is crazy enough that I don’t need to get into why this is wrong.
  • Satoshi Nakamoto is back. Despite the fact that there has been no activity with his private keys, some theorize that he has returned, and is somehow able to do things that nobody can. These theories don’t explain how he could do it.

If all this sounds like numerology to you, you aren’t alone.

All this discussion around special meaning in block hashes also reignited the discussion around something that is, at least somewhat, interesting. The Bitcoin genesis block, the first bitcoin block, does have an unusual property: the early Bitcoin blocks required that the first 32 bits of the hash be zero; however the genesis block had 43 leading zero bits. As the code that produced the genesis block was never released, it’s not known how it was produced, nor is it known what type of hardware was used to produce it. Satoshi had an academic background, so may have had access to more substantial computing power than was common at the time via a university. At this point, the oddities of the genesis block are a historical curiosity, nothing more.

A brief digression on hashing

This hullabaloo started with the hash of a Bitcoin block; so it’s important to understand just what a hash is, and understand one very important property they have. A hash is a one-way cryptographic function that creates a pseudo-random output based on the data that it’s given.

What this means, for the purposes of this discussion, is that for each input you get a random output. Random numbers have a way of sometimes looking interesting, simply as a result of being random and the human brain’s affinity to find order in everything. When you start looking for order in random data, you find interesting things – that are yet meaningless, as it’s simply random. When people ascribe significant meaning to random data, it tells you far more about the mindset of those involved rather than the data itself.

Cult of the Coin

First, let us define a couple of terms:

  • Cult: a system of religious veneration and devotion directed toward a particular figure or object.
  • Religion: a pursuit or interest to which someone ascribes supreme importance.

The Cult of the Coin has many saints, perhaps none greater than Satoshi Nakamoto, the pseudonym used by the person(s) that created Bitcoin. Vigorously defended, ascribed with ability and understanding far above that of a normal researcher, seen as a visionary beyond compare that is leading the world to a new economic order. When combined with Satoshi’s secretive nature and unknown true identify, adherents to the Cult view Satoshi as a truly venerated figure.

That is, of course, with the exception of adherents that follow a different saint, who is unquestionably correct, and any criticism is seen as not only an attack on their saint, but on themselves as well. Those that follow EOS for example, may see Satoshi has a hack that developed a failed project, yet will react fiercely to the slightest criticism of EOS, a reaction so strong that it’s reserved only for an attack on one’s deity. Those that follow IOTA react with equal fierceness; and there are many others.

These adherents have abandoned objectivity and reasonable discourse, and allowed their zealotry to cloud their vision. Any discussion of these projects and the people behind them that doesn’t include glowing praise inevitably ends with a level of vitriolic speech that is beyond reason for a discussion of technology.

This is dangerous, for many reasons:

  • Developers & researchers are blinded to flaws. Due to the vast quantities of praise by adherents, those involved develop a grandiose view of their own abilities, and begin to view criticism as unjustified attacks – as they couldn’t possibly have been wrong.
  • Real problems are attacked. Instead of technical issues being seen as problems to be solved and opportunities to improve, they are seen as attacks from people who must be motivated to destroy the project.
  • One coin to rule them all. Adherents are often aligned to one, and only one, saint. Acknowledging the qualities of another project means acceptance of flaws or deficiencies in their own, which they will not do.
  • Preventing real progress. Evolution is brutal, it requires death, it requires projects to fail and that the reasons for those failures to be acknowledged. If lessons from failure are ignored, if things that should die aren’t allowed to, progress stalls.

Discussions around many of the cryptocurrencies and related blockchain projects are becoming more and more toxic, becoming impossible for well-intentioned people to have real technical discussions without being attacked. With discussions of real flaws, flaws that would doom a design in any other environment, being instantly treated as heretical without any analysis to determine the factual claims becoming routine, the cost for the well-intentioned to get involved has become extremely high. There are at least some that are aware of significant security flaws that have opted to remain silent due to the highly toxic environment.

What was once driven by curiosity, a desire to learn and improve, to determine the viability of ideas, is now driven by blind greed, religious zealotry, self-righteousness, and self-aggrandizement.

I have precious little hope for the future of projects that inspire this type of zealotry, and its continuous spread will likely harm real research in this area for many years to come. These are technical projects, some projects succeed, some fail – this is how technology evolves. Those designing these systems are human, just as flawed as the rest of us, and so too are the projects flawed. Some are well suited to certain use cases and not others, some aren’t suited to any use case, none yet are suited to all. The discussions about these projects should be focused on the technical aspects, and done so to evolve this field of research; adding a religious to these projects harms all.

[Note: There are many examples of this behavior that could be cited, however in the interest of protecting those that have been targeted for criticizing projects, I have opted to minimize such examples. I have seen too many people who I respect, too many that I consider friends, being viciously attacked – I have no desire to draw attention to those attacks, and risk restarting them.]

Exploiting the Jackson RCE: CVE-2017-7525

Earlier this year, a vulnerability was discovered in the Jackson data-binding library, a library for Java that allows developers to easily serialize Java objects to JSON and vice versa, that allowed an attacker to exploit deserialization to achieve Remote Code Execution on the server. This vulnerability didn’t seem to get much attention, and even less documentation. Given that this is an easily exploited Remote Code Execution vulnerability with little documentation, I’m sharing my notes on it.

What To Look For

There are a couple of ways to use Jackson, the simplest, and likely most common, is to perform a binding to a single object, pulling the values from the JSON and setting the properties on the associated Java object. This is simple, straightforward, and likely not exploitable. Here’s a sample of what that type of document looks like:

What we are interested in, is a bit different – in some cases1 you are create arbitrary objects, and you will see their class name in the JSON document. If you see this, it should raise an immediate red flag. Here’s a sample of what these look like:

To determine if this really is Jackson that you are seeing, one technique is (if detailed error messages are available) to provide invalid input and look for references to either of these:

  • com.fasterxml.jackson.databind
  • org.codehaus.jackson.map

Building An Exploit

The ability to create arbitrary objects though, does come with some limitations: the most important of which is that Jackson requires a default constructor (no arguments), so some things that seem like obvious choices (i.e. java.lang.ProcessBuilder) aren’t an option. There are some suggestions on techniques in the paper from Moritz Bechler, though the technique pushed in the paper is interesting (the focus is on loading remote objects from another server), it didn’t meet my needs. There are other, simple options available.

Helpfully, the project gave us a starting point to build an effective exploit in one of their unit tests:

This code leverages a well-known ‘gadget’ to create an object that will accept a compile Java object (via transletBytecodes) and execute it as soon as outputProperties is accessed. This creates a very simple, straightforward technique to exploit this vulnerability.

We can supply a payload to this to prove that we have execution, and we are done.

Building The Payload

In this case, the goal is to prove that we have execution, and the route I went is to have the server issue a GET request to Burp Collaborator. This can be done easily with the following sample code:

This code can be compiled with the javac compiler, and then the resulting .class file should be Base64 encoded, and provided to the transletBytecodes field in the JSON document. As soon as the document is processed, it will create the object, load the code, and execute it. You may still see errors from code failing after the code executes, such as from type-mismatches or the like.

Limiting Attack Surface

This is just one technique to exploit this flaw, there are many others available. To mitigate the issue, at least in part, Jackson has been modified with a blacklist of types known to be useful gadgets for this type of attack:

  • org.apache.commons.collections.functors.InvokerTransformer
  • org.apache.commons.collections.functors.InstantiateTransformer
  • org.apache.commons.collections4.functors.InvokerTransformer
  • org.apache.commons.collections4.functors.InstantiateTransformer
  • org.codehaus.groovy.runtime.ConvertedClosure
  • org.codehaus.groovy.runtime.MethodClosure
  • org.springframework.beans.factory.ObjectFactory
  • com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
  • org.apache.xalan.xsltc.trax.TemplatesImpl
  • com.sun.rowset.JdbcRowSetImpl
  • java.util.logging.FileHandler
  • java.rmi.server.UnicastRemoteObject
  • org.springframework.aop.support.AbstractBeanFactoryPointcutAdvisor
  • org.springframework.beans.factory.config.PropertyPathFactoryBean
  • com.mchange.v2.c3p0.JndiRefForwardingDataSource
  • com.mchange.v2.c3p0.WrapperConnectionPoolDataSource

There are likely others that can be used in similar ways to gain code execution that haven’t become well-known yet, so this doesn’t eliminate the problem, it just makes it less likely.

Required Reading & References

To fully understand this vulnerability, there are a few things that you should read:


  1. To exploit this issue, the user of the library must have enabled Default Typing (mapper.enableDefaultTyping), if this hasn’t been done, then the exploit here doesn’t work, as you aren’t able to create arbitrary objects. 

Breaking the NemucodAES Ransomware

The Nemucod ransomware has been around, in various incarnations, for some time. Recently a new variant started spreading via email claiming to be from UPS. This new version changed how files are encrypted, clearly in an attempt to fix its prior issue of being able to decrypt files without paying the ransom, and as this is a new version, no decryptor was available1. My friends at Savage Security contacted me to help save the data of one of their clients; I immediately began studying the cryptography related portions of the software, while the Savage Security team was busy looking at other portions.

The Code

The code that really matters is in a PHP file2, named after the Bitcoin address that the victim is to pay the ransom to, and stored under the user’s %TEMP% directory. Here’s the bit that matters to us:

There are some important things that we see immediately:

  • They generate a unique encryption key for each file.
  • They are using AES-128 in ECB mode.
  • They are using RSA to encrypt the AES-128 key and store it in a .db file (also named after the Bitcoin address).
  • They encrypt the first 2,048 bytes of the file, and then replace it with random data.
  • The .db file contains the path, encrypted AES-128 key, and the encrypted data removed from the file.

The Critical Mistake(s)

If you’ve been to any of my talks on cryptography, you should see an immediate issue with this code. If not, let me point this line out:

This line creates a 128 byte key to be used to encrypt the file (it seems the developers don’t know bits from bytes), using PHP’s mt_rand function. This function generates random numbers using the Mersenne Twister algorithm, which happens to use a small (32-bit) seed – this is where the fun begins.

Because of this small seed, if we can observe the initial output of mt_rand, we can brute-force the seed and then predict its future output. Thankfully, the developers of Nemucod made this easy for us. If you recall, the first 2,048 bytes of each file are replaced with random data from mt_rand, then the encryption key is generated immediately after. This means that they have given us everything we need.

Using the first few bytes (4 or 5), we can brute-force the seed that mt_rand used3, and by running mt_rand the appropriate number of times, we can create the exact output that the PHP script did when it encrypted the files, revealing the file encryption keys and allowing us to decrypt all of the files.

Cracking the Seed

To get the seed, we need to brute-force all 2^32 possible values, thankfully there’s a handy tool to do this – and do it within a matter of seconds. A few years ago the always impressive Solar Designer released just what we need. This is a simple command-line tool that takes output (in this case the first few bytes of the first file encrypted) and provides the seed that was used.

Using php_mt_seed, it takes only about a minute to test all of the possible seeds, and identify the correct one. Once we have that, decryption is simple, and we have all of the data back without paying a single cent to the extortionists.

Why Randomness Matters

When it comes to key generation (and many other aspects of cryptography), the use of a secure random number generator is critical. If you look at the documentation for mt_rand, you’ll see this very clear warning:

This function does not generate cryptographically secure values, and should not be used for cryptographic purposes. If you need a cryptographically secure value, consider using random_int(), random_bytes(), or openssl_random_pseudo_bytes() instead.

Had the developers heeded this warning, and used a more appropriate method for generating the file encryption keys, this method would not have worked. Had the developers not been so kind as to provide us with output from mt_rand in the files, this would not have worked. It is the developers of Nemucod that made recovering the data trivial, due to the lack of understanding of proper secure techniques4. While I don’t want to aid ransomware authors, this is a well known aspect of cryptography – if you write crypto code without a full understanding of what you are doing, and what you are using, this is what happens.


  1. In the hours before this post was published, Emsisoft released a decryption tool for those hit by this version of Nemucod. 
  2. This ransomware targets Windows users, though the core is written in PHP. The downloader, written in JavaScript, downloads the Windows version of PHP (version 5.6.3) and uses that to execute the PHP file. Yes, this is as crazy as it sounds. 
  3. If mt_rand is not seeded explicitly via mt_srand, PHP will select a random seed, and seed it automatically. In this case, the developers did not explicitly select a seed. 
  4. There may be additional methods here that could be used, but those are beyond the scope of this article. 

30 Days of Brave

Brave is a web browser available for multiple platforms that aims to provide additional security and privacy features – plus a novel monetization scheme for publishers. I gave it 30 days to see if it was worth using. I switched on all platforms I use to give it a fair shot, I normally use Chrome which made the switch less painful, though the results were very much mixed. There are some things I honestly liked about it, some things I really disliked, and at least one thing that just made me mad.

The Good

There are some truly good things about Brave, here are a few that are important to me.

Based on Blink (Chromium)

Brave is built on the Blink engine, the same engine that powers Chromium & Chrome – this gives Brave some of the better security properties of Chrome, and Brave actually uses the Chrome user-agent to pretend to be Chrome. This means that Brave has similar performance and rendering quality to the other Blink browsers, which gives it an edge over Firefox and keeps it on par with Chrome.

The use of Blink is a key to making the switch reasonable, there are no issues with sites breaking, as is so common when switching from one browser to another.

HTTPS Everywhere

Brave integrates HTTPS Everywhere to force connections to use TLS when possible, this is great, though the same can be achieved by using the HTTPS Everywhere plugin. During my time using Brave, it reports having performed over 15,000 TLS upgrades – just on my personal laptop.

Ad Blocking & Payments

Brave takes an interesting view of ads, it includes ad blocking, but also includes Brave Payments (disabled by default), which allows you to give something to the sites you visit most often. I put $5 into it, and let it run for a month – it tracks how much time you spend on each site, and splits up the money between them.

Of all the sites that Brave lists in my top sites, only two are setup to actually receive the payments – this site (which I setup during the testing process), and Archive.org. There are a number of sites that are included that really make little sense – for example, sites like RSA.com, PizzaHut.com, TeeSpring.com, Namecheap.com, Oracle.com, and Eventbrite.com all made the list to be paid. These aren’t content sites, but they all got a share of the money. You can selectively disable certain sites from being included, but that requires watching the list, and making sure that it’s maintained. You don’t have the opportunity to confirm who gets paid before the payment takes place, so make sure you check the list often.

When a payment is made, the money (Bitcoin actually), is transferred to accounts that Brave Software controls, and when (if) a site receives $100 in payments, one of two things happens:

  • If the site has already been setup for payments, the money is transferred to the site’s Bitcoin wallet.
  • If the site isn’t setup, they will attempt to contact them to set up the site so they can receive their money, if they don’t after a period of time, the money is distributed to other sites that are properly setup.

It’s an interesting setup, and somewhat cool to be honest – though does leave a decent amount of money in the control of Brave Software. Will this site ever get $100 in revenue from Brave users? I’m not holding my breath. That means that the money will stay in the control of Brave Software essentially forever.

The ad blocking itself works well, roughly the same you would get from uBlock Origin.

Performance

It’s hard to quantify just how much time is actually saved by using Brave; it’s not just general performance, but the integrated ad blocking that saves bandwidth and processing time. It claims to have saved me 18 minutes on my laptop and 5 minutes on my iPhone.

It does feel a bit faster, but the placebo effect may explain it.

The Bad

There are some things about Brave that just didn’t live up to my expectations, some of these are from a lack of polish – things that will likely be fixed as time goes on, others were more fundamental.

Private Browsing

Like pretty much every major browser today, Brave offers a private browsing feature, but it’s implemented in a way that I find troubling. Typically when you using Private Browsing, a new window is created, and everything in that window is held to a private scope. In Brave, a tab is private – so you mix the scopes, and can easily cross that boundary. When you right-click a link in a private tab, you can open the link in a new private tab, or in a new normal tab. This makes it extremely easy to cross the line, and expose activity that was meant to be isolated.

For me, I often use this feature to separate session scopes, logging into the same site in a normal window, and a different account (or no account) in a private window. This design makes it trivial to take an action under the wrong account. I think they were trying to make things easier, but what they did was make it easy to make mistakes.

Memory Leaks

Brave is leaky, like Titanic kind of leaky. I once left a Twitter tab open over a weekend, when I came back on Monday Brave had consumed every available byte of RAM. So much so, that even killing the process turned out to be impossible and I had to perform a hard reboot. Chrome is known for its high RAM usage, though Brave has pushed it too far.

PDF Handling

Built-in PDF handling is essentially a must these days, and Brave tries here – but ultimately fails. The integrated PDF viewer works well in most cases, unless the PDF is behind a login. In these cases, it fails and requires that the feature be disabled to be able to download them. As changing this setting requires restarting the application, so I eventually just left it off.

Rough Edges

Brave is a perfect setup for a death by a thousand cuts, from oddness with tab management, painful auto-complete in the search / address bar, the inability to search for anything with a period as Brave treats it as a URL, and many others. Much of this will improve as Brave matures, though for now the rough edges are a constant annoyance that make me want to switch back to Chrome. Some I’ve learned to work around, others are still painful every time I run into them.

The Mad

Brave recently published a highly misleading article that painted a very negative view of the standard QUIC protocol, trying to accuse Google of using QUIC as a way to circumvent ad blocking. The article was built on, at best, a significant misunderstand on the part of Brave. The article was later updated, though the update was entirely insufficient to set the record straight, leaving users with a misunderstanding of the technology, and how it applies to Chrome and other browsers.

Whether purely from a lack of understanding, or something else, the issue was poorly handled – they attacked a competitor (one which makes their product possible) without understanding the details they were talking about, mislead users of Chrome and Brave, and failed to accurately update their article to undo their misstatements. There are some people at Brave Software that I greatly respect, so this was shocking for me, and I lost a great deal of respect for the organization as a result.

Overall

Brave is an interesting experiment in how a browser can address privacy concerns, and provide an avenue for monetization; I hope that others in the market look at it and learn from what they do right. The application for iOS feels a lot more polished than the desktop version, and while I’m going to switch back to Chrome as my primary browser, I may keep the iOS version handy.

Confide, Screenshots, and Imaginary Threats

Recently Vice published a story about a lawsuit against the makers of the ‘secure’ messaging application Confide. This isn’t just a lawsuit, it’s a class-action lawsuit and brought by Edelson PC – an amazingly successful (and sometimes hated1) law firm – this isn’t a simple case. The complaint includes a very important point:

Specifically, Confide fails to deliver on two of the three requirements that it espouses as necessary for confidential communications: ephemerality and screenshot protection. […] Confide represents, in no uncertain terms, that its App blocks screenshots. But that isn’t true. Any Confide user accessing the platform through the Windows App can take screenshots of any and all received messages.

This article isn’t about the lawsuit though, it’s about threat modeling and screenshots.

Of Screenshots and Cameras

Preventing screenshots, or at least attempting to, has been around for some time, and was made popular thanks to Snapchat – their client would detect that a screenshot was captured, and using an API call, notify the server that this had happened (unsurprisingly, this API was rarely documented, as none of the third-party clients wanted it), so the sender could be alerted. When this feature was added, technical attacks were discussed by many that were following Snapchat’s attempts at living up to their word – from modifying the binary to not make the API call, to using a proxy server that would block the call to the server.

Yet for all of the technical solutions, there was an easier answer: grab another device with a camera and take a picture.

Many people that work in corporate or other environments that have strict security requirements often carry two mobile devices – if you know (or suspect) that a messaging application will block or report a screenshot, just take a picture of it with your other device. This completely bypasses the technical restriction on screenshots2. It’s simple, it works, and it’s undetectable. Then there are virtual machines – you could run an application in a virtual machine, and capture the screenshot from the host, instead of the guest operating system. Once again, this is effective and undetectable. Then there are numerous others.

Trust Violated

If you can’t trust the person you are talking to, don’t talk to them. If send a message to somebody that contains sensitive statements, and you can’t trust them to keep it private – the only way to ensure that it’s not shared is to simply not send it. There is no technical solution to ensure that a message displayed on a screen is actually ephemeral. This is why high security environments where sensitive (i.e. classified) information may be on display don’t allow cameras or devices with cameras at all.

If a user wants to capture information about a conversation, and there are numerous ways that they are able to do just that, they will get it. If they take a little care, nobody will know that they’ve done it. If they have technical ability (of know somebody that does), then it’ll be effortless and undetectable. Confide may, and should, make changes to address the technical issues with their screenshot protection feature to behave in a more effective way; that said, they will never be able to actually prevent all screenshots.

Screenshot protection is a vain effort; if it’s displayed on screen, it can be captured. People may think that they need it because it’s how they would capture a conversation, but it doesn’t actually provide any effective security. Features like this, and claims that applications implement them, are little more than snake-oil aimed at making consumers believe that an application provides a level of security that isn’t actually possible.


  1. Jay Edelson & team may be hated by some in Silicon Valley – but they have done a lot to protect consumers, and suing over security claims is an important avenue to ensure that companies live up to their promises. My research on Snapchat was cited by the FTC in their action against Snapchat, which I am still very proud of. Needless to say, I favor whatever action is necessary to ensure that companies live up to their promises, and consumers aren’t being sold snake-oil. 
  2. There are theoretical means to complicate this, by using a controlled “flicker” to make it more difficult to capture a useable photo. This comes with various downsides, not the least of which is the high likelihood of giving users a constant headache.