Blockchain Use in Software Code Signing & Malware C2

I’ve done some small research about blockchain recently, and just want to put my thoughts down on paperblog so I can stop thinking them. Most of this is rehashing information I’ve read, but the “signed code verification” piece towards the end is an idea of mine that I’ve not read about elsewhere.

Blockchain is a hot term these days. It’s a popular management buzzword, and as such it can get thrown about as a cure for just about all that ails you. All businesses need to store data, and blockchain is known as a data-store, so everyone wants to make sure you’ve considered their (probably expensive) blockchain solution for data storage…

Blockchain is good at solving a couple problems though.

  • It can provide a publicly-verifiable record of data’s existence at a point in time. At any point in the future, anybody with access to the blockchain can prove that a certain piece of data existed at the point it was stored on the blockchain. If you’ve got a document that has been digitally signed, you can store the hash of that document on the blockchain. Later blockchain links will all chain back to your document hash, and their presence will prove that your document predated their transactions. Because blockchain additions (is most implementations) occur on fixed schedules, it will be possible to reconstruct exactly when your document must have been added to the chain.
  • Publicly-verifiable records of data’s existence can prove transactions have occurred, or contracts have been signed. This is how a blockchain can act as a ledger. Transactions on the blockchain can represent physical-world transactions, if the participants assign them that meaning, enabling tracking of the transfer of real-world entities between blockchain participants. On a public blockchain these transfers are transparent to everyone involved at all points in the future. They cannot be reverted by any individual except by a future transaction.
  • Transparency means that no trusted third-party needs to exist. Transactions can occur more easily between non-trusting parties without an escrow.
  • Public blockchains get stored by many parties, each having an economic incentive to participate. That means any data stored on them is stored in many places, providing data replication and the potential for access from disparate parts of the world. To store a small amount of data, little economic incentive is required. To store larger amounts of data, much greater incentive is required.

These solutions are enabled by some prerequisites.

  • Blockchains require lots of computational power. Specifically, they require more than your adversaries. To prove data’s existence at a point in time, links must be added to the chain periodically. When adding links to the chain, the other participants in the blockchain must agree on their addition. If there are malicious participants in the blockchain, they may decide to disagree about a set of new links, and instead agree on a different set of links. If the malicious participants form a majority, other participants in the chain will be influenced to believe the new malicious links are legitimate and ignore the others. Participants make decisions based upon cryptographic data that’s passed around, and computing that cryptographic data requires computational power. Therefore, to prevent a malicious takeover of a blockchain, you must have more computational power than any malicious adversaries can muster. In a public blockchain, you get the benefit of all the disparate participants’ computational power. Your adversaries must then overpower the public, instead of just you.
  • Blockchains require a computer network connecting participants. When designing a blockchain for use in low-Internet access areas you really restrict your ability to use existing public blockchains. To add data to a blockchain you must submit your transaction to the other participants, and enough of them must get it for your data to have any chance of being added. If you stop using public blockchains, or use small ones, perhaps because you’re in a remote area, you open yourself up to attacks based on computational power.
  • Public blockchains require economic incentive. Computational power costs money – for hardware, network access, and electricity. Participants in a blockchain require computational power. Thus, participants need a monetary incentive to participate. You pay for data additions to Bitcoin’s blockchain by supplying a small amount of bitcoin that is automatically paid to the individual who adds your data to the blockchain. The amount of data added by each transaction is small, so larger chunks of data require multiple transactions and more bitcoin.

Lots of proposed uses for blockchain have limited applicability due to these requirements.

Potential Use Case: Malware Command and Control (C2)

Malware C2 is an interesting use for blockchain, though. Malware running on end-points often needs to reach out to its creators for further instruction. “Steal files”, “learn about the local network”, “propagate to a nearby computer”, “record keystrokes”, or “delete yourself” are all things malware might want to do, but only when commanded by a remote attacker. Often malware reaches out to one destination for these commands. This is the simplest C2 implementation, where one or a few hard-coded server name or IP address provide the C2 to the malware.

Network defenders can try to detect and block this behavior by redirecting those C2 servers to alternate locations, pretending to be those C2 servers, or by taking over the C2 servers with the permission of law enforcement or the server’s rightful owner.

Blockchain’s distributed nature makes this much more difficult. Given a good-enough implementation, it could be difficult or impossible for defenders to block access to a copy of the blockchain. Because there’s no central server it’s not possible for a defender to take over the blockchain, either. Once a C2 command is added to the blockchain, it is impractical to remove it, too.

We’ve seen a few uses of it this method already. Omer Zohar built and demonstrated this use-case in early 2018. He used Ethereum and its “smart contracts” system to implement encrypted C2 of a nearly unlimited number of malware endpoints. The result was a system that is extremely difficult to block or subvert. As Ethereum increases in popularity the system will be increasingly hard to block. His major limitation was operational cost. Each message to and from an endpoint cost a small amount of Ether, translating to (at the time) about $39 per year per malware instance.

Anonymity is a major benefit of such a system. Many consider blockchain participation to be completely anonymous, however participation often requires money, and that money must enter the system from some point. That money typically comes from a traceable source, however malware authors also steal or “mine” cryptocurrency. Such activity would provide a less-traceable source, and make the system nearly entirely anonymous.

Potential Use Case: Code Signing Transparency

Another potential use for blockchain is in software signature verification. Microsoft’s Windows and Apple’s OS X use software signatures to verify that software was produced by an entity (a company or individual). Software producers compile their code into binaries, then digitally sign them before sending those binaries out into the wild.

This provides end users the assurance that a specific company made the binary. An example is if someone emails you a version of Microsoft’s Notepad. Before executing it you would want to make sure it was actually from Microsoft, otherwise a malicious actor could have modified Notepad to include malicious software. If Microsoft has signed this copy of Notepad, you can verify that signature and prove that Microsoft created it. You would know then that the version of Notepad was safe to execute. Windows and OS X now make it more difficult to execute software that’s not digitally signed by some vendor.

Stuxnet is a piece of malware that abused software signatures. It included components that were signed by legitimate, trusted software vendors. This made those components more likely to be trusted and less likely to be detected. Other malware has abused software signatures, but none has been as high-profile as Stuxnet.

Blockchain’s distributed, transparent, nearly-immutable nature can help solve this problem.

Software signatures can currently be verified by a client who trusts a root certificate, and can the follow that root certificate trust through a set of other certificates to the software signature in question. One certificate signs the next, which signs the next… Good verification requires checking a revocation list too, so when invalid signatures are found in-the-wild they can be cancelled.

If an additional step for verification required signatures to be found in a public database of software signatures, all malicious code signers would have to publish their signatures to this public database too. Companies could check the database to determine if someone is signing code on their behalf.

In the event of Stuxnet, JMicron Technology and Realtek Semiconductor would have been able to check the public database regularly. They would have seen a software signature they did not issue, and they could have placed it on the revocation list immediately. They could have then taken action to prevent further signatures in their name.

A blockchain can act as this public database. The result would be widely distributed, and it would be practically impossible to modify or remove signature entries after they were added. As an added benefit, it would become more obvious to observers when a company holds compromised certificates that should no-longer be trusted, and that company’s security practices could become (rightly) suspect. Because blockchain provides an irrefutable timestamp when data is added, signature attack timelines will also become more transparent to security researchers.

Every valid software signature would incur a small cost to be added to the blockchain. Additionally, the signature verification process would become more complex and require Internet access. However, software and hardware vendors could implement API endpoints that handle the blockchain portion of verification, simplifying lookup code for the endpoints they sell. The result would still provide transparency for all signature creators and verifiers.

I haven’t seen this solution proposed elsewhere, however Kim, Kwon and Dumitras recommend that code signing tools log all transactions they complete [Kim, 2017]. Tools like “signtool.exe” in Windows would log “the hash value of program code and the certificates” to Microsoft, then third parties could “periodically audit the log and identify code signing abuse”. This is great, however it doesn’t require software to verify that signatures are present in that log during signature verification. Without that, any attacker that subverts the signature reporting process, by preventing reporting to Microsoft, gets their software signed without reporting it.


Some discussion of blockchain benefits and requirements:

Paper about blockchain potential in the military:

Doowon Kim, Bum Jun Kwon, and Tudor Dumitraş. 2017. Certified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (CCS ’17). ACM, New York, NY, USA, 1435-1448. DOI: URL:

Sir Sour

Time to make sourdough again! The starter has been going for a couple weeks, but during that time it never adopted the stinkiness I associated with the early starter stages last time. It does seem to grow after feeding, it produces some alcohol on top… It’s probably doing it’s thing enough to make some bread, so it’s time to try that out.

I was trying to diagnose the difference between the starter this time and last, and the best I can come up with is that the whole wheat flour is pretty old this time. It’s only a couple months away from it’s best-by date, so it has been sitting on the shelf for almost a year. I think in that time the natural yeasts and bacteria in the flour maybe mostly died. This, the harder time starting out. If this loaf is sour and good, perhaps this is really the better situation. Maybe the yeast just went into suspension, and the bacteria died, for instance, letting me skip the “stinky gym socks” state of starter. I don’t know.

Anyway, I started the fermentation last night and things smelled great (a little stinky a little yeasty) this morning, so it seems like the dough is on track. I did my cheater, adding 1 tsp regular yeast in with the other dough ingredients this morning.

The bulk rise finished around 1300 today, and the loaf is quite large. Bread is very forgiving! This will almost certainly be delicious awesome bread regardless of the specifics. Now – will it be the perfect tasting sourdough loaves I was making before? Who knows. It helps that I am pretty easy to please I guess.

Starting final rise

Looking good @1600! The cheater yeast really increases volume.

Final rise complete, about to go in the oven

It’s pretty good! Sour enough… I guess the starter works.

Smoking Salmon in Idaho

Well, we’re still unpacking things, but we’ve been here for a bit. One of the things I was most excited to have arrive is the smoker – not gonna lie, that was a top priority. I’ve been looking forward to having some smoked Salmon again, and Sarah has mentioned it a couple times too.

There’s a Sam’s Club more convenient these days, so I picked up some salmon there. They had Sockeye for about $12 a pound, and “Atlantic” for about $9. I went with the Atlantic to see how it’d go. This looks like the same fish I was buying back at Costco in MD. I’ve heard the Sockeye is amazing – maybe next time. At that price though, I’ll probably smoke some other fish to see how it goes. Trout? This time I picked up two fillets totaling about 5.5 lbs.

0800: The fish swam in the typical brine all night at the bottom of the fridge. I put it in the fridge to dry at this time. We haven’t found our typical wide flat glass brownie baking dishes, or cooling racks, so to get things drying I had to use a couple cake pans with a smoker rack sitting on top of each.

1230: Starting up the smoker – 120℉. I’m a little distracted by a project I’m working on. I should’ve started it up around 1130… Should be fine though, the fish just gets a little more time drying.

1310: Fish is on the smoker. Two hours at 120℉, one at 140℉, then 175℉ until the internal temp is over 135℉. Baste it with maple syrup every hour.

1710: it’s done and it’s fantastic as usual. No problem. The fish has the same quality as what I was buying in MD.

Pitching Success – CO-STAR

Idaho National Labs has a program right now called “CO-STAR”.  Their researchers do great work, but as with any research group they are constantly advocating for funding, and researchers are constantly advocating among themselves for time.

Everybody spends time advocating for something.  “Pitching” something.  You want your boss to consider a smarter way of working, one that you’ve come up with?  You pitch it to her.  You want someone to use an open-source project you’ve created? You pitch it to them.

Some folks are naturals at this.

Nerds (researchers, open-source software creators, me) are often not good at this.  At least this is my experience.

I don’t like to brag about my stuff.  I have a much easier time bragging about someone else’s work.  I think a lot of folks have this specific problem with pitching – but of course there are a number of other sticking points folks experience.

The CO-STAR system is a way to break out of that a bit, because it is a process for performing a pitch that one can simply follow.  Moxie and a persuasive style may help a pitch, and CO-STAR can’t help those, but it does set out the requirements your target will need to evaluate your pitch logically.  It’s a set of steps you can follow in a discussion – and it’s even ordered!  In an actual pitch a more-experienced speaker may choose to skip some of the steps that are already understood by all parties, but one could simply progress through the steps in order and have success. This link is a description of the system in short.

First, you need an idea you want to pitch and a target to pitch to.  Perhaps you want your boss to let you adopt a new way of washing the dishes, maybe you want your company’s training division to send you to a conference, maybe you want a separate company to use your widget. 

Next, use a couple sentences to describe and answer each of the following.  These are quotes with only small clarification on my part, and these come from that PDF linked above, which is copyright 2017 Enterprise Development Group, Inc.

Your Hook: Begin with a compelling question, fact, or statement that will generate (in the mind of your target) curiosity related to your idea.

Customer: Who is the customer for your idea?  What needs do they have that might be met by your idea?

Opportunity: What is the opportunity for them?

Solution: What is your solution to their problem?

Team: Who needs to be on your team to solve this?

Advantage: What is the competitive advantage your solution provides over other solutions?

Results: What results will you achieve?

The Ask: Conclude with a specific request regarding the next steps your target should take.

Don’t spend too much time on the solution.  Most people get too excited about the solution because, after all, the solution was their big idea!  But your pitch target probably cares more about the other things like opportunity, advantage, and most of all results.

Remember that when considering your advantage one “other solution” is for your target to keep doing whatever they are currently doing.  Even if that’s “nothing”.  Make sure you consider the advantages of your solution over “doing nothing”.

Regarding the ask and next steps maybe you want a meeting with the target where you can discuss a way-forward in more depth, or maybe you just want to ask for the time and money to do your idea (in the event of conference attendance, for example, that’s all you might need).

The CO-STAR system is pretty simple, and anyone who has pitched before has used parts of it.  One benefit is that it lays steps out that, when followed in-order, clearly explain the value proposition you want to make.  It systematizes and simplifies a pitch.

There are a number of non-traditional pitches I’ve made recently… Websites, emails about opportunities, persuasive papers… All benefit from answering the questions in the CO-STAR model.

Meet Differently

A recent episode of the Freakonomics podcast covered meetings. Two or more people gathering to accomplish the business of business, as they defined it. It gave me some things I hope I remember the next time I’m organizing a recurring staff meeting…

  1. Organize an agenda around questions-to-answer
  2. Hold smaller meetings
  3. Keep track and time

Meetings need agendas, just about every book I’ve read which touches on meetings agrees on this point. The agenda needs to be communicated to participants in advance, so folks can come ready to accomplish it. Folks need to know what to expect. Without an agenda meetings usually devolve into chaos, although sometimes it takes a couple aimless meetings in a row to hit this point. Staff meetings often don’t have a pre-published agenda, but they generally do have a set of topics they proceed through in a set order, and that becomes the known-agenda for the group.

Generally my agendas are lists of topics – that’s not the most effective way to manage a meeting though. In the podcast Steven Rogelberg says, “if you can’t come up with any questions, you shouldn’t have a meeting”. A meeting isn’t for distributing announcements – there are other, better, less time-intrusive means for that. A meeting is for collaboration on problems, which can be stated as questions.

Organize an agenda around questions-to-answer

This also makes it easy to shake out the folks that actually need to attend the meeting. Getting everyone to attend is a waste of their time. Getting just the folks who have inputs on question answers is the minimum group for attendance. If others have input they can attend too after seeing the meeting agenda.

One question I’ve needed to answer in the past is, “what work from my team am I going to present to my bosses this week?” I’ve often taken it on myself to answer this question, but it occurs to me that the transparency I’d provide by bring this question to the workers, getting their input, and providing my feedback, could be excellent.

Smaller meetings, like shorter meetings, make better use of my folks’ time. When nugging the group of attendees down based on inputs required, I’m building a smaller meeting. I can also build smaller meetings by holding more meetings but with targeted groups.

For instance, when I led tactics development I could have met with the team leads individually to gather their inputs for the week. What’s their status update, what are their blockers, what are their accomplishments… This would have given me personal time with each lead (valuable), time to track their updates, time for them to provide me feedback they might not in a larger group, and time for me to provide them more private feedback. Then, our larger group meeting might have asked the questions, “which of these accomplishments are most valuable to raise up”, “which blockers can be solved in the group”, and “which blockers are most valuable to raise up?”

I actually did that on occasion, thinking back. Not in such an organized way, but as a result of intuition. There were reasons at the time I didn’t fully embrace the method (partly because it wasn’t my job but I felt like I still had to do it) so I did it only about 90%. A mistake.


Hold smaller meetings

If a meeting has questions for the full group, and also some for only a subset, after the full group part is complete let the folks unconcerned for the rest leave. Open the door, take a 30 second break.

For small staff meetings, to improve group openness, risk-taking, and personal connection, consider taking 10 minutes at the beginning to do “a rose and a thorn.” Everyone tells what they see as the best part and worst part of their week/week-to-come.

Keep track and time

Start on time, end on time. Set the meeting for the amount of time the questions will take, not some arbitrary value like “an hour”. If there’s pre-reading required, consider scheduling-in time at the beginning for folks to complete it.

Take minutes, and if the group decides work needs to be done and follow-ups need to occur then assign those tasks to someone. Write that assignment down. Discuss when you’ll expect the result, then come back to it later. Put all that in the minutes and send that out to the participants.

Announce “last call” at the end of the meeting, or as we do in the Air Force ask for any “reattacks”. Maybe plan for the last ten minutes for this, and set an alarm that shouts “LAST CALL” or “REATTACKS!” at that time. That’d at least be fun.

Folks are going to complain about meetings. We all do – even when they’re useful. At the least I can try to make them a good use of my folks’ time.