We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Tineola: Taking a Bite Out of Enterprise Blockchain

00:00

Formal Metadata

Title
Tineola: Taking a Bite Out of Enterprise Blockchain
Subtitle
Attacking HyperLedger Fabric
Title of Series
Number of Parts
322
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Blockchain adaptation has reached a fever pitch, andthe community is late to the game of securing these platforms against attack. With the open source community enamored with the success of Ethereum, the enterprise community has been quietly building the next generation of distributed trustless applications on permissioned blockchain technologies. As of early 2018, an estimated half of these blockchain projects relied on the Hyperledger Fabric platform. In this talk we will discuss tools and techniques attackers can use to target Fabric. To this end we are demoing and releasing a new attack suite, Tineola, capable of performing network reconnaissance of a Hyperledger deployment, adding evil network peers to this deployment, using existing trusted peers for lateral network movement with reverse shells, and fuzzing application code deployed on Fabric. As George Orwell said: "Who controls the past controls the future. Who controls the present controls the past." This talk will demonstrate how a sufficiently armed red team can modify the blockchain past to control our digital future.
Enterprise architectureDew pointInjektivitätMultiplication signEnterprise architectureMassComputer wormInheritance (object-oriented programming)Goodness of fitDrop (liquid)Mereology
Degree (graph theory)Gastropod shellTheoryProfil (magazine)RootMereologyComputing platformEnterprise architectureBoss CorporationCommitment schemeINTEGRALSoftwarePlastikkarteWordDesign by contract
Principal idealComputing platformEnterprise architectureLattice (order)Design by contractEnterprise architectureMultiplication signRight angleChainProduct (business)Rule of inferenceFlagBlock (periodic table)BlogComputing platformHand fanMereologyComputer programmingSoftware frameworkFormal languagePhysical systemVulnerability (computing)Information securityGroup actionCartesian coordinate systemOffice suiteInformation privacyGraphics tabletINTEGRALMathematicsSoftwareDifferent (Kate Ryan album)Computing platformDirection (geometry)Software bugGreen's functionInsertion lossPlastikkarteCryptographyAuthorizationField (computer science)Hacker (term)Data conversionGame controllerAuthenticationProgrammer (hardware)Power (physics)PhysicalismBit
Dew pointComputing platformChainPlastikkarteCartesian coordinate systemRight angleKey (cryptography)PasswordTwitterInternetworkingFile archiverReal numberNP-hard
MathematicsLattice (order)Computing platformEnterprise architectureBlock (periodic table)Computer iconPlastikkarteComputing platformDesign by contractRemote procedure callMultiplication signOrder (biology)CodeMobile WebVotingIntegrated development environmentPhysical systemException handlingSoftwareService (economics)Computing platformDefault (computer science)Complex (psychology)Virtual machineMereologyProduct (business)Cartesian coordinate systemResultantHypercubeDemoscene
Enterprise architectureBuildingMobile appComputer networkSoftware testingCuboidWeb applicationCartesian coordinate systemCASE <Informatik>Commitment schemeMultiplication signBlogMobile appHypercubeBuildingProgram flowchart
Mach's principleLattice (order)PlastikkarteComputing platformDifferent (Kate Ryan album)Design by contractMessage passingSystem callInterface (computing)ChainJava appletEnterprise architecturePlastikkarteElektronische WahlEncryptionKey (cryptography)Chain codeState of matterData storage deviceComputer programmingBytecodeProcess (computing)
Information securityBusiness modelAsynchronous Transfer ModeVirtual machineDuality (mathematics)Infinite conjugacy class propertyState of matterHierarchyDynamic random-access memorySineFault-tolerant systemValidity (statistics)Video gamePublic-key cryptographyPeer-to-peerType theoryOrder (biology)WritingSet (mathematics)Physical systemRule of inferenceChain codeDatabase transactionCategory of beingProcess (computing)Client (computing)LogicSingle-precision floating-point formatPoint (geometry)Default (computer science)SoftwareSign (mathematics)CodeRevision controlInformation securityGroup actionChainState of matterFunction (mathematics)Open setSelf-organizationLevel (video gaming)Block (periodic table)MathematicsBusiness modelBitMultiplicationDatabaseDifferent (Kate Ryan album)Computer networkChemical equationPower (physics)Computer configurationSound effectKey (cryptography)Broadcasting (networking)DiagramCheat <Computerspiel>outputConstraint (mathematics)Functional (mathematics)Multiplication signRight angleHypercubeTheoryWordPersonal area networkFigurate numberField (computer science)High availabilityDegree (graph theory)Real numberPerspective (visual)Program flowchart
Interface (computing)Demo (music)TheorySlide ruleComplete metric spaceFigurate numberSource codeSoftwareSoftware testingShared memoryDesign by contractInformation securityLink (knot theory)Scripting languageDemosceneHypermediaPoint (geometry)Business modelIntegrated development environmentChainCodeRight angleOpen sourceBlock (periodic table)Program flowchart
BlogDemo (music)VideoconferencingInternetworkingHacker (term)Medical imagingSlide ruleHand fanComputer animation
Product (business)Design by contractDebuggerMobile appPlanningWeb 2.0Front and back endsBoom (sailing)PasswordCodeComputer animationXML
Content (media)Linear subspaceFile viewerMotion blurServer (computing)Public key certificateLocal ringClient (computing)Ring (mathematics)Context awarenessIdentity managementElectric currentSession Initiation ProtocolServer (computing)Default (computer science)Attribute grammarRight angleClient (computing)Public key certificateCodeBlock (periodic table)System administratorPhysical systemAuthorizationMetadataAuthenticationHash functionCuboidInformationCartesian coordinate systemConnected space
Business modelChi-squared distributionIntrusion detection systemComputer wormInclusion mapService (economics)Web 2.0PasswordBlock (periodic table)User interfaceRight angleComputer fileException handlingInformation privacyLogicPerfect groupRelational databaseHash functionCASE <Informatik>Chain codeInformation securityData storage deviceArchitectureoutputMultiplication signPattern languageSource codeJSONComputer animation
CodeChainPeer-to-peerError messageLinear subspaceConnected spaceRule of inferenceSoftwareOrder (biology)Chain codeDefault (computer science)MathematicsMultiplication signWeb applicationChainLogin
Contrast (vision)Graphic designIntrusion detection systemExecution unitHill differential equationTerm (mathematics)Inclusion mapLinear subspaceSpectrum (functional analysis)Computer wormComputer iconInternet service providerFunction (mathematics)Parameter (computer programming)WindowDaylight saving timeForm (programming)Query languageChain codeComputer fileBlock (periodic table)Functional (mathematics)Process (computing)Query languageSystem callIntrusion detection systemRight angleParameter (computer programming)Error messageDependent and independent variablesSpacetimeCodeMiniDiscOrder (biology)Source codeJSON
Menu (computing)Limit (category theory)Link (knot theory)Dependent and independent variablesCAN busPasswordFunction (mathematics)Chi-squared distributionDemo (music)Error messageState of matterOrder (biology)Multiplication signWeb pageRight angleChainSource codeJSONXMLComputer animation
IntelPeer-to-peerComputer wormInclusion mapLinear subspaceCodeChainBlock (periodic table)Functional (mathematics)Peer-to-peerSystem callSelf-organizationProcess (computing)BitChainAuthorizationTerm (mathematics)Sampling (statistics)Front and back endsSoftwareCodeSoftware developerRight angleOpen setCartesian coordinate systemShared memoryQuicksortComputing platformRepresentational state transferMathematicsUser interfaceGame controllerVacuumEnterprise architectureChain codeBuildingConnectivity (graph theory)DebuggerSource codeJSON
StatisticsInjektivitätProxy serverChainRegular graphSystem callChain codeCartesian coordinate systemFunctional (mathematics)Port scannerDirection (geometry)Slide ruleSampling (statistics)Formal languageFocus (optics)NumberWritingRepository (publishing)Vulnerability (computing)Right angleFiber bundleError messageServer (computing)Dependent and independent variablesInjektivitätComputer animation
Error messageChainQuery languageLocal ringChain codeFuzzy logicResultantMessage passingBit error rateString (computer science)Right angleKey (cryptography)Port scannerVideoconferencingFunction (mathematics)CoroutineVirtual machineInjektivitätDoubling the cubeInternetworkingOpen setMoment (mathematics)Source code
InjektivitätInfinite conjugacy class propertyPivot elementCoroutineFuzzy logicChainEscape characterGastropod shellValidity (statistics)Cartesian coordinate systemPeer-to-peerWeb applicationCodeKey (cryptography)Pivot elementSoftwarePoint (geometry)Open sourceChain codeService (economics)Type theoryPoint cloudAuthorizationSelf-organizationVulnerability (computing)Mobile appCross-site scriptingComputer configurationSoftware maintenanceShared memoryRight angleDatabaseComputer animationProgram flowchart
Convex hullLinear subspaceGastropod shellIntelClient (computing)RankingInstallation artElectronic mailing listBuildingMIDILocal ringDatabaseGastropod shellPeer-to-peerInternetworkingSoftwareService (economics)RootComputer-assisted translationRight angleComputer networkBoom (sailing)Computer animation
Point cloudExecution unitService (economics)Local ringConnected spaceComputer fileClient (computing)MaizeSatelliteChinese remainder theoremMereologyClosed setStatisticsLinear subspaceLemma (mathematics)Dependent and independent variablesWitt algebraPivot elementOpen setOrder (biology)Greatest elementPeer-to-peerRight angleSingle-precision floating-point formatService (economics)SoftwareComputer networkBusiness modelCodeMultiplication signComputing platformSource codeJSONXML
AuthenticationConfiguration spaceCodeSheaf (mathematics)WordDefault (computer science)PasswordComputer animation
Physical lawReverse engineeringVirtual machineWeb applicationChain codeGastropod shellWeb 2.0User interfaceDrop (liquid)Utility softwareProxy serverMereologyPasswordDirectory serviceRight angleCASE <Informatik>Computer animationSource code
Default (computer science)Data managementDesign by contractTemplate (C++)Motion blurConvex hullType theoryDesign by contractPoint (geometry)PasswordSoftwarePeer-to-peerDefault (computer science)Revision controlCuboidWeb pageMachine visionFlagRight angleMultiplicationInstance (computer science)ChainComputer animation
Intrusion detection systemSpectrum (functional analysis)Linear subspaceChain codeMultiplication signWeb pageVideoconferencingComputer animationSource codeJSON
Value-added networkInclusion mapLinear subspaceDaylight saving timeDesign by contractHash functionOrder (biology)Data typePersonal identification numberBloch waveAreaTwin primeRight angleReading (process)Set (mathematics)Type theoryBlock (periodic table)Design by contractFlagPeer-to-peerKey (cryptography)ChainData storage deviceDatabaseSource codeJSON
Sound effectTrigonometric functionsComputing platformChain codeComputing platformBlock (periodic table)Perspective (visual)Software developerMobile appChainTrailInformation securityContext awarenessProgram flowchart
DecimalTrailBitMultiplication signComputer animation
Transcript: English(auto-generated)
So let's give them a big DEF CON welcome. Is this good? Can everyone hear me? Okay. Thank you. If I start speaking too quickly, please let me know. Throw something at me
because I do that. I have an accent so it's hard to understand me. So here we are at DEF CON. We are super excited. It's my first time at DEF CON. First time speaking at any conference. I mean it's super big. Everyone is hacking each other. There are so many
SQL injection payloads going around. Even Elon Musk dropped by to break up the unions. I'm so funny. So we have a great talk planned out for you. And you say, okay, what does this enterprise blockchain thing has anything to do with the theme of DEF CON which is surveillance. So everyone is collecting data about you. And this data will end up on the
enterprise blockchain sooner or later. So we might as well, you know, look at these things and see what these are. So we have a great talk planned out for you. The first part I'm going to talk theory. I know theory is boring but you will learn buzz words. After you go back home, you go to your LinkedIn profile, add those buzz words to it, talk to
your boss and ask for a raise. I mean it works. I mean my boss is there. The second part, my co‑presenter will show you our tool. We have created a tool to attack enterprise blockchain platforms. You will see things like defeating the blockchain to
commit insurance fraud and also root shells through smart contracts. Take that, Ethereum. So we all work at Synopsys, software integrity group. There's four of us. I'm
a tech fan. I love smart contracts. And my super power is ‑‑ they told me not to do this. My super power is getting selected at the airport every single time. You can see why. Any time spent with me is not harassing you. So you're welcome. And my
co‑presenter is this schmuck who doesn't even like Go. Hey, guys. My name is Stark. I work with this schmuck. Anyway, I came to Black Hat last year for like the sixth time but I finally got to hear about blockchains and smart
contracts and I got interested because it sounded really easy to break. And it turns out that it is. Our customer has been talking to us about enterprise blockchain which is apparently different and I wanted to kind of move the conversation in that direction. So Travis and Coon are there. They are our team members and they are amazing. I mean, they
speak like ten different languages between themselves. It's amazing. Okay. So we have our team together. The first thing we did, we started looking at the whole platform. So we have public blockchains and then we have private blockchains or enterprise one. Public blockchains are, you know, cryptocurrencies. There are a lot of
ICOs. All of them are scams. So there we go get banned from the crypto ‑‑ I'm sorry, crypto currency village. You should be careful not to say crypto as in cryptography because Matt Green will come and pummel you to that. And the enterprise part has been working very quietly. We have all been pointing and
laughing at the latest John McAfee scam, right? The bit five wallet, whatever it is. And the enterprise part, there are three major camps. It's been vulcanized. And I always wanted to say vulcanized. There's hyperledger, there is enterprise Ethereum alliance and there is R3. Now a lot of companies are invested into this. I mean, tech companies are already there. But they also change their JavaScript
frameworks every three weeks. So that's not surprising. But there are other companies, there are healthcare companies and there are financial companies. And financial companies are really hard to convince to do something new. That means the senior leadership of these companies has seen something in these platforms. So they're investing a lot of time and money into this. And as I said, before you
would get flagged at the airport if the immigration officer didn't like you. What's going to happen in two years is some small contract is going to flag you before you even land. And you get a free physical. Amazing, right? And they say your healthcare is shit. So the blockchain world is like this election
candidate. It says promises made and then promises kept, right? It says I'm immutable, which means I'm not hackable. Everything that gets on the ledger or the blockchain stays there and it cannot change it. So hackers cannot do
anything. It says I'm auditable, which means you think you know what has been put on the blockchain by whom and when. You have tunable trust. I will give you authorization controls and authentication controls. You can give access to different groups of people. And finally I will give you programmability through smart contracts. So we can codify the
rules of the world into smart contracts which get there on the blockchain and not be modified. So it will be an even playing field. What happens in the promises kept part is of course very familiar. None of them are kept. The ledger is immutable. Okay, we already knew that. But that means that if fraud happens, then you're SFIL. Sorry for your loss. Your Bitcoin wallet gets hacked.
Sorry for your loss. But your bank cannot say that the same. Say the same to you, right? Your account is empty. You go to the bank. The teller cannot laugh at you and say LOL. You're gonna sue them. Another problem is
they are not always mutable. There are bugs. And these bugs would make things different. You write something to the chain and you're like okay that's it. What happens in practice is there is some vulnerability out there and then something else is written in the chain and then you are SFIL. Privacy is
important. Before you put anything on the ledger, you should think really, really hard. Because when it goes there, it's there forever. It's like the internet, right? You can't go back and delete your old tweets because someone archived it. And then GDPR comes along and you have to change things. So if you commit usernames and password or credit cards or encryption keys to the
chain, then don't do that. You're SFIL. These platforms unfortunately as it is, don't have enough throughput for real world applications. So what you're gonna do is what they do is they sacrifice correctness for speed. Instead of running your smart contract on all nodes and comparing the results, you run
it on like one node and call it a day. If that node goes rogue, then SFIL. The execution environment is also important. I'm sorry I laugh a lot at my own jokes. I'm the funniest person I know. The execution environment is also important. Smart contracts are by default remote code execution as a
service. You're running someone else's code on your machine and you don't know what it is most of the time or don't know what it ends up doing. So you need to be understanding. You need to secure these things. And then finally these platforms are super complex. So every blockchain system is a distributed
network. Nodes join, leave. You need to, you know, make up for all of this. So great. So in order to progress more into these scene, we chose one platform. So we chose Hyperledger Fabric. It's part of the Hyperledger ecosystem,
which is owned by the Linux Foundation, with the exception that Linus is not yelling at you. It's great. It's written in Golang, which is great. Everyone should write in Go. And it counts for roughly 50% of the deployments out there. It's our observation. If you've heard about this
new mobile voting thing, application, it's based on Hyperledger Fabric. So whether you like it or not, your votes are gonna end up there. I know it's not important because we don't care about voting, but we should. So after that, we choose this guinea pig. And guinea pigs are important because we learn by breaking things. Unless it's OSCP, in which case you, you know,
pay someone. The application we have created is called the Build Blockchain Insurance App. And that's the name. If you Google for it, you can find it. It's your typical insurance application. It looks pretty slick and works most of the time. There's a web application in front.
As a customer, you go in, buy something, and then if something happens to it, which always will, you would say, I want to claim and submit a claim. The insurance people go in and look at your claim, and then if possible, they would pass it to the cops because they want to get out of it anyway. That's what insurance does. And then finally, everything goes to the repair shop.
The repair shop repairs it, or doesn't, and then gets paid. And that's what happens. So everything after this purple box is fabric. So looking at this application, we had some questions. So the first question is like, how do we hack this thing?
The front is web application. And in this day and age, it's not a solved problem. But we know how to tackle this web application testing. I mean, everyone does it, right? You just pass it to Burp, I guess. Sorry. But everything after that is opaque blob, which is hyper-leisure fabric.
So we created this tool that gives us insight into what's inside. We can do things. We will show you things. You can do shells. It's amazing. I mean, this thing is completely broken. And then the second question was like, okay, we have this insurance application. How do we hack it?
And they say follow the money. So the only person that gets paid is the repair shop. So we want to commit insurance fraud. And that's what we're gonna talk to you later. So we have our platform. We have our guinea pig first, and then we need to learn about the platform. And I'm sorry I'm boring you out, but the buzzwords are important.
So smart contracts and fabric are amazing. I love them because they're named chain code, and you can also write them in Golang. Go is great. You can also write them in Node.js or Java if you're an enterprise customer. And it interacts with the ledger in a very simple manner.
There's an interface called Shim, and the ledger is a key value store. You just call get state, pass a key, get the value. Just call put state, pass a key and value, and then you update it. It works. And the main difference between these smart contracts and the Ethereum smart contracts is that these are actual programs. So instead of just interacting with the ledger
through EVM bytecode, you can do other things like call HTTP APIs, spawn processes, do encryption, do decryption and all that thing. So it gives you great power, but with great power also we need to inhibit this power like these checks and balances thing that is supposedly there.
So you have what is called channels, and each channel has its own ledger. And on each channel we can have multiple chain code, one or more. Each chain code is only local to that channel. You can have copies of the same chain code on different channels, but they don't talk to each other. And each chain code has its own internal database which reflects the values of the ledger.
And then what you do is you run something, you update your values, and everything goes into some CouchDB, and then everything gets updated, gets minted as a new block on the chain, and everything comes back and updates yours. You cannot mess with other people's state DBs, which is great.
Now with that said, I'm out of buzzwords, so what I'm gonna do is I'm gonna pass the mantle to my friend who doesn't let go. Okay, so a little bit more theory, and then we'll hack something. So to really understand the security model
of Hyperledger Fabric, we need to discuss how things change on the network, right? So we have immutability guarantees, but we can program it to change over time. So the first step of one of these changes is we have a peer that's gonna submit a proposal, right? So a proposal just says invoke this chain code function, take some inputs, do something with it.
It's gonna send it to one or more endorsing peers. These are just members of the network who have the chain code itself. So step two, they're gonna actually execute the chain code, right? So they're gonna do something with the Golang code that's gonna generate some output. That output is called an endorsement. So an endorsement is a group of all the key values
that they read from and written to. It's called the read write set. It's gonna sign it with its private key, and then it's gonna submit it back to the peer. The peer collects all the endorsements from all the nodes that it sent it out to and forwards that along to a special peer called the orderer. So everything up until this point is really arbitrary, right?
So we could have sent garbage data in and the endorsing peers could have sent garbage data back to us. The orderer's job is to enforce some rules about this data. So at a high level, it performs three types of validation. So the first type of validation is ensuring that all of the endorsements match.
All the reads and write sets match each other so that the peers don't disagree on what's actually happening. The second step is to ensure that we meet some endorsement policy. So a policy can be set up to have maybe three out of five peers on the network agree to a transition, right? And then the third type of validation
is to ensure that we don't have conflicts with previous transactions. So the orderer does all this logic by itself, and at the end of the day, if it validates it, it creates a new block. It mints that block, puts its private key on it, says this is now a valid set of transactions, and broadcasts it to all the other peers on the network.
At this point, we consider the global state of the network to have changed. Every peer will now know the new values of every key in the data set, and we've completely updated everybody. So that's cool. We want to get there, and we want to bypass some of that logic that might be enforcing constraints. So there are a few suspects in just this diagram, right?
A few things that we can latch onto and talk about from a security perspective. First, on the far right, we have the endorsers. So we consider the endorsement policy to be a style of optional Byzantine fault tolerance. So for those of you who didn't get a master's degree, I think is the only place I learned about this in school
was we have to do networks with lots of different people. They're gonna disagree with each other. They're gonna lie. They're gonna cheat. We need to figure out a way to equalize the playing field, to figure out who's lying, who's cheating, and just ignore them. But if we have this style of endorsement policy
where we can choose what level of validation we do, then we've dropped our guarantee down to an optional level. So we lose that guarantee from open chains like Ethereum or Bitcoin, where all peers must be endorsing every transaction. And in fact, by default in Hyperledger Fabric, the endorsement policy is just one peer.
So if you don't set one up, anyone can say anything and the orderer will trust it. It's not great. So on the left, we have the orderer that's in orange. The orderer is ending up as a single point of failure for the whole system. So every transaction's gonna go through this orderer. Now, there might be multiple orderers, right? You might have high availability, but it's still a single set of,
it's a single organization within the network, so it's a single set of peers who are now party to every transaction on every channel. So that is completely non-fault tolerant by this definition. And in the middle, we have the client. So the client's got an interesting property where it can transmit requests to be endorsed
by endorsing peers without sending them for ordering. So it can cache and hold onto these things and maybe submit them later or choose not to submit them at all. And if our chain code has side effects, which it can, since it's just arbitrary Golang code, it can do anything, then this may have some very interesting properties in a real life system.
So if we're writing code or if we're auditing a system, we have to keep the side effects in mind for the effects of a peer that's not really performing what we expect on the network. So at this point, we're completely done with theory and I get to introduce our tool. So when we first got started with Fabric, we did a lot of getting started with it.
We set up dev environments, we built threat models, we built some quick scripts to hack it and kind of figure out what it's doing behind the scenes. And we decided to package all of this up and release it as open source code. So it's called Tinola and it's built by red teamers for red teamers. So if you're doing a penetration test or if you're doing a source code review in a live environment,
this tool's gonna let you see what's going on and try to interface with it more efficiently. It is on GitHub. I have a link at the end of the slides so you guys have to stick around. But we have our white paper up on there as well that talks about everything we're doing here if you wanna share it with your friends. Okay, so we're done with theory completely.
Let's talk about our demos or our techs. So from now on, my name is Tom. I work for the Repair Shop org. And we just signed up for this blockchain thing and I don't think it's as secure as all of the media headlines say and I wanna do insurance fraud. And I have access to my own peer because I'm a member of this network
as working for the Repair Shop. So I wanna see what my peer can do and maybe I can get some ideas on how to perform some fraud. My initial idea was okay, what if somebody bought an item, got some insurance contract and then they submitted it for repair but it's not actually broken, right? And then I get the contract to repair it
and then I repair it, right? And then they pay me to repair it. It's perfect. I just get cash. It's a great idea. So let's see how we could do this. So you may be asking about the slides. We sent this deck to our marketing department and asked them to spice it up and they came back with those stock images
that you see in the blog posts where the hacker in the black gloves is like picking locks and stuff. We weren't a fan. So we sent it back and they gave us this deck because they're like people on the internet like animals and these decks have animals. So you're welcome. Okay, let's do a video demo
because I didn't pray to the demo guys sufficiently. Okay, so to get started, we're just gonna watch Carol. Carol's gonna be our scapegoat because she's gonna buy an item and we're gonna do some fraud on that item. So she's buying a bike here. This is the insurance app that we're hacking, right? It's got a web front end. She's currently on the shop here
where you can buy items. You can see she's filling out her information and at the end of this, she's gonna get a contract. And like I said, my plan is to just fraudulently submit a repair claim on the contract. Should be pretty simple, right? But let's find out how we're supposed to do that. So we click through, we buy this very expensive bike
and then boom, we get a password in plain text. So we can tell this is following all the best practices. This is example code guys. People copy and paste this stuff. Anyway, so this is TyNola. It's a JavaScript application that runs on the command line and so it has some commands. So first I'm gonna connect up
to my certificate authority server and authenticate. I'm gonna use the default administrative credential which is admin admin pw. Again, it's in all of the examples. It's great. So I log in, I'm in, but I wanna know what's going on in here. So the first thing I do is I ask the certificate authority, what are all the users on this box?
And it goes, well, they've got the admin client, but that's it, right? So I'm the only person here and it's got some attributes that tell me what I can do on the system. It's pretty nifty. And the next step I might ask, okay, so let's connect to my peer, right? So I'm connecting out to the repair shop endpoint. I'm connected. I might say, give me some metadata about this peer.
So what channels are it connected to? We've only got one channel. It's the default channel. So I connect up to that. And then I might say, okay, give me some metadata about the channel. So I ask for channel info. And it gives me some hash values, but what's important here is the height, right? So that tells me how many blocks exist on this channel.
So that's great. So I know there's 11 blocks. I'm just gonna ask for the last five, right? So I do channel history five. I see the last five blocks that hit this channel. So right there in block 10, that's Carol, right? And there's her password right there in plain text. So that's pretty nifty. So I've got the password. I'll discuss this in a moment, but we're just gonna take that password back
to the web interface, throw it in. Yeah, this is me. Here I am. I'm gonna go over to the claim self service, throw in the password and file that claim. So why was that data there? Well, it turns out that the blockchain needs a bunch of data to do its thing, right? Business logic is complicated, needs inputs. And so although storing maybe plain text passwords
on the blockchain is not great, chain code often needs private data to operate. It's just we need to do business here, right? But if we think about it, that particular value, this password, it's gonna go on repeat, isn't it? That particular value wasn't needed by anybody
except for Carol and the insurance company. So that's a perfect case for like what? A relational database, right? We store hash passwords in MySQL all the time. Maybe we should be doing that. So we see storage of private data on blockchain as a major security risk and not using
in conjunction with relational databases is just an architectural anti‑pattern. Okay, so we've got through what we can see on the network. Now that we can see it, let's play with it, right? What can we do with it? Well, it turns out that I've made a mistake
and that if I go to my repair shop here, I don't have any repair orders. So what happened? And it occurs to me that the insurance company needs to approve this repair order. And I don't work for the insurance company. I don't have logins there. So let's see if we can just bypass the web app completely and just invoke stuff on the chain itself.
So I'm gonna connect back to that default channel just like I did before. I'm gonna connect to an order this time. So now I have the capability of making changes to the network. And I'm gonna just do a channel history command again because I don't know how to interact with this chain code yet. I'm gonna think about it for a while.
There we go. So here we are. And these are all the last blocks. So up in block seven is a claim process command. So it turns out this is the command that this chain code uses to approve a repair request. And it takes some UUIDs and down in block 11 was the most recent claim file command which was my fraudulent claim. So I could just like transplant the UUIDs
into that previous function call, right? That should work. So I'm gonna use TyNOLA's channel query cc command. I'll tell it to do a claim process function call. I'm gonna say I'm gonna use one argument and I'm just gonna paste in this JSON blob. I've already replaced the UUIDs here. I'm gonna hit enter. So this first one is a dry run. I just wanna make sure this actually works.
So I'm not gonna order it. I'm just gonna tell the endorsing peer, go make sure this works. So I get a blank response. Turns out this chain code doesn't actually do anything with the return code. It just returns blank. But I didn't get an error which means I'm running out of disk space. No. So anyway, I'm gonna do it again
with the dash dash invoke since it didn't error the first time. And this tells TyNOLA go order it. So again, no error. I think I might have changed the state of the blockchain. So I'm gonna refresh the page and we have modified the blockchain, folks. Okay, cool. So what does this actually look like, right? Like we can go ask TyNOLA
to show us what the chain history looks like. So again, I'm just gonna use the channel history command so we can see what happened. So in block 13, we see, excuse me, block 12 was our fraudulent claim process. That was me submitting. This is a function call that's only ever done by the insurance peer.
But we can see in column three, the creator column, it's the repair shop organization who invoked that function call. So the lesson learned, right? Enterprise blockchain, these Fabric and Quorum and these other platforms, they refer to themselves as permissioned blockchains
to differentiate themselves from open blockchains like Bitcoin or Ethereum where anybody can join. I don't like using that term because I feel like it's a big misnomer and it gives the wrong impression to chain code developers. The thing is that chain code itself isn't permissioned. You have to make it permissioned. Just access to the network is being blocked.
So what does that mean? It means that since we're building a network, ideally of mutually competing parties, that's the value of blockchain, bringing together people who don't trust each other to share things and data and code. Since we don't trust everybody else, I can make this go away, can't I? So we don't trust these other people,
we have to put authorization controls into our chain code. We have to do it explicitly. This code doesn't do it explicitly, right? So all the samples, none of them do authorization, that's great. There we go. So we're gonna take a bit of a detour
and we're gonna talk what we can do with just this invocation step, right? So the blockchain doesn't operate by itself. It's not in a vacuum. Blockchains almost always have some sort of front end component. May that be a REST API or SOAP API or web interface like in this example, it doesn't matter. There's some front end that's processing the data from the chain.
So we asked ourselves, can we attack that front end from the chain? Can we use the chain to attack that other front end application? It turns out, yeah, definitely. So we had an idea. So we built Tinola with an HTTP proxy in it. And so whenever you post to Tinola, Tinola will turn that into a chain code command and invoke it on the chain.
So on the right, I'm using Burp, it's just a regular application scanner. And I'm just gonna demonstrate that I can invoke this function call directly. Now before I show that, I'm gonna hop back over to my slides so we can see what's about to happen. So here, this is from the Fabric Samples Repository. It's an official repository that shows how to write chain code.
And we have a trivial JSON injection vulnerability due to string concatenation. This is really disappointing because the big thing with Go is that you can make JSON in the language. It supports it. So, whatever, you know, it's fine. But let's see, somebody's gonna read this data, right?
There's a reason we're formatting it as JSON because there's gonna be a server that takes this error message and puts it someplace, right? And we can see even the JSON response data for a regular response is the same way. It just happens to be secure because the data they're pulling out is always a number, but don't worry about that.
We'll focus on this one first. So let's see what this looks like. So first, I need to tell Burp to use local host because that's where my port is open. Don't worry, it doesn't open a port on your machine to the internet. It's just local host. We'll tell it chain code example 02. That's the name of the chain code that we're attacking.
We're using the query command. And then we're gonna fill in an account value that I happen to know exists. So on the right, we get HTTP 200 okay. It does exist. We get the chain code output as a result. So we can use HTTP to interact with the chain codes. It's pretty helpful. Let's try an account that doesn't exist, account 1234 does not exist.
We get the Sarah message. And we see it's concatenating the name right in there. So we can try playing with it by hand first, just to demonstrate for the video that it does concatenate. So I'm just gonna break out of the string with an escaped double quote. I'm just gonna add a second key just to show that it works.
Put in a spiffy emoji there. We hit go, okay. So we see that works, right? So we get HTTP 500 because it's throwing an error, but the error message itself has a JSON injection. But we can use any of the features of BERT through Tinola, right?
So we could use intruder or we could use scanner. So I'm just gonna demonstrate scanner. On the left in a moment, you're just gonna see it scroll by as the scanner tries all these insane permutations of fuzzing. So the nice thing is like, I didn't wanna write my own fuzzer because fuzzing is hard. So whatever fuzzing routines you guys are already using, oh geez, whatever fuzzing routines you're already using
will work with Tinola. You just, as long as it speaks HTTP, you can use Tinola. Again, this is not targeting chain code, right? We're not targeting this code itself. We're targeting whatever's ingesting the data from the chain, because there will be upstream applications that take this data and do something with it. So we might find cross-site scripting vulnerabilities
in a web app that displays data that's getting pulled from the chain. Why does this matter? Well, unlike databases, which you hold the keys to and there's a password on and only you can access it, the whole point of the chain code is to share the data, right? So you're sharing it with partners or with competitors, and they have access to modify the chain. So you can't trust the data coming in from the chain itself.
So we've gotta escape or validate or sanitize or whatever you're gonna do with the data you're bringing out of Fabric. Okay, so back to the insurance app. So I'm pretty comfortable with invoking stuff on the chain code. We figure out authorization doesn't exist. I can attack this chain code all day now.
This is lovely. But I've got bigger aspirations. So it turns out that my organization is using cloud hosting, blockchain as a service type deployment, and it's really hard for me to interact with the other peers, because I just have a single endpoint that I can hit that hits my peer. But I can't see the other peers.
I can't see their internal network. There might be network services hiding in there. So I wanna pivot through my peer, right? So how does this work, right? So chain code's running as a container, okay, Docker container. And it's arbitrary code. So I should be able to write some arbitrary code that runs in my container that gives me a shell or something, right?
So Tynola ships with Tynola CC, our proprietary chain code that's open source. Anyway, so Tynola CC has pivoting options for it. So let's see what that looks like. Here we are. So on the right, I'm gonna start just a netcat listener
on 3.1.337. And on the left, I'm gonna use the Tynola shell command, give it my IP and port, and do who am I? And boom, root. There we go, easy. But we're in a container, right? What can we do in the container? This is a Ubuntu container, so I can use apt to install things.
This is nice. If it doesn't have internet access, you can drop things using the Tynola HTTP dropper. That works. But either way, we're gonna get Nmap on here, and I wanna use that to scan the network, because I think there might be network services in here. I'm gonna scan the private network that I know that the peers are on, and I'm gonna give it the standard ports that Fabric uses.
So there's two gRPC ports that the peer uses, an HTTPS port that's for the order, and CouchDB. So this bottom one here is the order. It's got one port open. It's just a single gRPC port. And then we have four other peers who are listening on gRPC, HTTPS, and CouchDB.
So about this, right? So there's not a whole lot you can do to stop this, it turns out. Fabric was built to run arbitrary code. It's just what it does. So if your threat model includes peers being compromised, which it always should, because people get compromised all the time,
you have to account for this, right? You have to be aware that the network is not partitioned completely, and that a peer will always be able to communicate on whatever private networks it's located on. So even if you have a blockchain as a service platform, this is still something to think about. So for those of you who are familiar with CouchDB,
this attack may be obvious, but CouchDB doesn't use authentication by default. And yesterday I was trolling through the most up-to-date Fabric documentation, and their using CouchDB section doesn't even use the word password in it. This is very disappointing. They do have it in their configuration section,
like CouchDB configuration, how to customize it and everything, but who's customizing their deployments? They're just like copy and pasting code off GitHub. So what does this look like? What can we do with modifying CouchDB? Let's take a look. So I'm gonna pick a value in the web app
that cannot be changed. So this is theft insured column, and I've picked this not included thing. And it turns out there's simply no chain code that ever modifies this value. Once this value has been set, it's set forever. It's part of a JSON document, but there's no way to change it using chain code.
But I'm gonna use the Tynola SSH proxy command on the left. This does a reverse SSH proxy back to my machine, and opens up a port that points to, in this case, the insurance app's CouchDB port. And CouchDB comes with a beautiful web interface, and if there's no password on it, it just like drops you to a read write shell. So that's pretty sweet.
So on the right, I can see it's loading some JSON, and then I go to the slash underscore utils directory, and we have this beautiful web interface. This is all the channels, all the chain code that's installed in the machine. We can see everything. I'm gonna maximize it, because it's kind of hard to read this. Make it big.
Come on, there we go. And there's the contract type. So this is the value that we want to modify. There's theft insured, that's false. I'm just gonna change it to true and hit save, right? So at this point, the insurance peer, I'm not a member of the insurance company, I can't normally talk to this peer, has modified itself to say theft insured is present.
So we've modified this peer's vision of the network. We've not transacted anything, there's no evidence of this on the chain, just this one peer thinks that this value is true. To demonstrate this, we can hop over to the shop peer.
So the shop peer runs its own stack, and its own CouchDB instance, and its version of the network will be slightly different, because we haven't attacked this one yet. So I'm gonna just show you here. Here it is. It's the same contract, the theft insured box has not checked yet. So we have a, you know, we have conflict between multiple peers. So I've got an idea, right?
So I could attack the shop peer as well in the same way, but maybe they were clever, maybe they've got passwords there, right? But what if we could propagate it, right? So we're using the default endorsement policy, just one peer needs to be compromised to affect the rest of the network. So I'm just gonna disable and re-enable this contract. So that's all I'm doing here. I disabled it, now I'm gonna hit enable again.
Dune. Okay, I'm gonna refresh this page. And it turns out it read the JSON, modified the enabled flag, and then wrote it back with the tainted value. So it's still there. But this time, I'm gonna go over to the shop peer, I'm gonna refresh the page, and then go up, and look, it's checked.
So we've propagated a value, the chain code says can never be changed by messing with CouchDB due to a poor endorsement policy. So we'll go over to TyNOLA to see what happened. And this is, this is not even the right,
what's going on, this is not even the right video. So we'll go over to TyNOLA and say, hey, TyNOLA, what happened? Like, show me the channel history of what just happened. And these are the only two blocks that were written, okay? It's a contract type set active, and it's set at active false, and then active true. That's it. No trace of this theft insured flag changing,
but we can really dig into it, right? So I mentioned read‑write sets a while back. Let's take a look at what those look like. So here's the read‑write set. So in green, we see this contract type that we modified was read from the database, and then we see it was written back, and you see the whole JSON documents there. So that's how JSON documents work in a key value store.
You can't just modify a subvalue in CouchDB, you gotta write back the whole thing. And we can see, I'm gonna highlight it in a second, that the theft insured flag is tainted, right? There it is, theft insured true. So we've got an endorsed write set with our tainted data written back to the chain. Now all the peers trust it, and that's how we break it.
Sweet. Okay, so we've talked about a bunch of things, right? So to wrap up, we've got Fabric. It's a brand new platform. No one knows how it works from a security perspective,
but I think at least about $100 million, from what I understand, has been pumped into this thing, either the development of the platform itself or development of apps on top of it. It's huge, it's coming. Your data will be on the blockchain very soon. We need to know about these problems, because the developers of the platform, they're aware of these things,
but it's hard to fix a lot of them. They're architectural, or they're just, a lot of it is chain code needs to be better, right? And so until we get the platforms to be better, we need to write our chain code better. We need to make awareness of these problems bigger. There are so many cryptocurrency talks now, I can't keep track of them all, but I haven't heard anyone bring this up.
So we need to be talking about this more, and I'm just gonna start screaming about blockchains now, so I'm gonna stop. Okay, all, ooh, ooh, ooh. Okay, so everything you've seen is open source. Please go get it. We've got it on GitHub. It's fresh, I committed it like 20 minutes before I came out here. We've got a white paper on there. It explains everything we wanted to say here,
but we didn't have time. So I think we have a little bit of time. I lost track of my goon. So if there are any questions, I'm more than happy to take them now if we have time, or I'll be around. I've got five minutes, so I can take like two questions. There's a mic in the middle. Thank you, guys. This was awesome. Thank you.