Vlads Blog

CodeBreaker 2018, Final Remarks

Sat, 12 Jan 2019 00:00:00 GMT

Codebreaker challenges are always fun and educational. This year’s it was especially good. It span multiple areas reverse engineering and blockchain. Thank you NSA for putting this up together. Looking forward to 2019 challenge.

CodeBreaker2018 walkthrough, Task 7 Refunds

Fri, 11 Jan 2019 00:00:00 GMT

Our final task is to take over an Escrow contract and refund the money back to the victims who paid.

After completing task 6, the solution of this task is pretty simple.

Let’s recap of what we have learned so far:

We understand the entire message flow of the ransomware
We can substitute ransom contracts with our ‘patched’ versions
We cannot change anything about the Escrow contract itself
Looks like the attackers have not withdrawn the money from the Escrow

So, what we need to do is:

Find a flaw in the ransomware blockchain
Exploit the flow to take the money from the Escrow
Refund it back to victims

Let’s take a look at the message diagram:

and this method

as well as this one

Looks like the attackers decided to be “Gentlemen” and provided refund option in case they fail to decrypt the encrypted file. Also it looks like the ransom contracts can re-register themselves as many times as they want given that they have been authenticated once by the Oracle.

So let’s modify our ransom contract again to do the following:

Register with the Escrow as zero ransom contract
Call payRansom on the escrow giving it 0 ether
When Escrow calls our requestKey method we will first give a corrupted version of the key to the Escrow and then re-register ourselves as a contract with Ransom amount of 300 ETH.
Oracle will fail to decrypt and will indicate failure to the Escrow by calling DecryptCallbackMethod with authResult = False
Escrow receives a failure notification and automatically refunds us. However, because we changed the refund amount at step 3, the Escrow is going to refund us with 300 ETH not zero which we initially paid
PROFIT

This is a blockchain equivalent of going to the store, changing the price sticker to 1 penny, buying the item, tampering with the receipt to make it look like we bought it for $3000, damaging the item, returning it back to the store for the refund of $3000.

Note that operations in step 3 have to be done exactly in this order. This is because registering new ransom contract creates a new contract record in the victimMap mapping. Which means the Escrow will consider this newly registered contract to be unauthenticated. It will therefore refuse the decryptKey request from the new contract. Doing these operations in the order listed in step 3 seems unreliable, but actually it’s not. We are guaranteed that our substitution of ransom amount is going to happen before the oracle gets the decrypt event by the atomic nature of the Ethereum transactions. All changes to the contracts and posting of the events are made public once the block is acknowledged by the miners.

Here is our test for this scenario [http://bit.ly/2Db5Eu4].

And of course it fails

It fails because we didn’t ‘patch’ our contract yet.

Again we are sticking to the principles of TDD. First we run the test to illustrate the problem. We run this test to make sure it fails, if it doesn’t fail it was not a valid test, we do whatever is needed to make the test pass.

The ‘patch’ for the Ransom contract is here

We run the test again.

And it passes this time.

Let’s check the account balances

Great, we managed to get 9 Ether out of the owner. Even better, because the transfer is done in the context of DecryptCallback, Oracle is paying for the gas.

Now let’s go and use this exploit on the real blockchain.

Note that we transferred only 9 ether except of 300 requested by the assignment. This is because of the default Ganache settings of 100 ether on each account. I have tried to make this walkthrough as simple as possible, but still educational. Changing default ganache settings would make this walkthrough more complex than it already is.

Go back to RemixIDE and upload our new EvilRansom contract to the workspace.
Deploy the new contract using the same technique we’ve used in task 6
Verify that the new contract has deployed by checking blockchain events using our notebook or just call the method getEscrowAddressForVictim of the Registry to verify that new contract has registered correctly
Once you’ve verified, that the new contract is there. Make a 0 either payment to the escrow and enjoy your 300 ETH refund back.
In order to get the credit for this task you have to actually send 100 ether to each of the victims who have paid the ransom. Can’t keep to yourself.
Once you send the ether to the victims, go ahead and submit your escrow contract address to the challenge

Sorry, there are no screenshots for the lasts steps. I am writing this more than a week after completing the challenge. Applying Task 7 exploit to the real blockchain permanently corrupts the Escrow contract so it is not possible to repeat this again.

If you followed me along, you have completed entire challenge. Congratulations!

CodeBreaker2018 walkthrough, Task 6 Loophole

Thu, 10 Jan 2019 00:00:00 GMT

In this task we are going to trick the attackers to reveal us the decryption key without paying any ransom.

Before we dive in, it will help to get familiar with Ethereum smart contracts and distributed applications. Here is some good reading material:

Mastering Ethereum by by Andreas M. Antonopoulos
Ethernaut - series of exercises, that show how to exploit various loopholes in Ethereum blockchain. Nicole Zhu prepared an excellent set of Walkthrough Solutions to these exercises. Try doing the exercises first before proceeding with the walkthrough. All of the Ethernaut exercises are very valuable for gaining insight into the inner workings of the blockchain. However, for the purpose of this challenge you need to only go through exercises 1 to 8.

Our approach is to build the model of the ransomware, and then experiment with the model to see how we can exploit it. Ethereum comes with some great tools to do it. We won’t be doing any reverse engineering here because attackers gave us their source code to the smart contracts to “prove” that we will get the funds. The only piece we are missing is the code to the Oracle daemon that watches blockchain and posts decryption keys when it detects that the ransom has been paid.

We will use the following tools

Truffle/Solidity suite a prime toolset for building Ethereum smart contracts using solidity language.
Ganache testing tool that lets you run the blockchain on your computer
Remix IDE web based IDE for developing and testing smart contracts
Metamask wallet Ethereum wallet for web Chrome and Firefox browsers.
NPM/Node environment Javascript development tools, needed to setup Truffle
For the editor you can use anything you want. I find that Visual Studio Code offers the best support for Solidity language. You’ll to install Solidity/Etherium plugin separately.

Let’s begin

Preparations

Install Node and NPM on your computer if you don’t have it installed yet. You’ll need a sufficiently modern version. I used Node version 10.7 and NPM 6.4.1. Best way to do it on OSX is to use the brew package manager.

Also, I like to use the desktop app version of the Ganache. It makes it more clear to see what’s going on with the dev-blockchain. To install it simply download it from their website and follow instructions.

To install Truffle framework use the following command:

npm install -g truffle

Start the project

Once you have everything installed, create a new directory and run the following command inside:

trfulle init

After the above command configures new project, copy the contracts provided by challenge to the ‘contracts’ directory.

Next, we are going to write some unit tests to understand the transaction flow between different contracts. There are two ways to write unit tests for Solidity smart contracts. The first one is to use solidity language itself and the second one is to use Javascript. We will be using the Javascript method because we’ll need to simulate complex actions between different contracts and off-the-chain entities like Victim and Oracle

We will be using a ‘solidity-coverage’ tool to see how much code we get to cover by our tests and to make sure we explore all the edge cases. Install the tool using the following command.

npm install solidity-coverage

Our initial setup is here

By default Ganache gives us 10 accounts with a 100 ETH balance on each. We will use them as follows:

Account 0 — ransomware OWNER, ultimate recipient of all the ransoms
Account 1 — ORACLE, an off-chain software daemon that will authorize ransom registration and release keys when ransom is paid
Account 2 — VICTIM, A person who got infected with ransomware

Note that there is a distinction between victim account, victim_id and ransom contract. First is an Ethereum address of the wallet that belongs to a real user. Second is just an ID number it has no meaning in the Ethereum universe, it is just a number, the last is the smart contract that holds victims encrypted key

Same distinction applies to owner and escrow. The first is the wallet address that belongs to a real person, second is the address of the smart contract that holds the funds deposited by the victim until withdrawn by the owner or refunded back to the victim.

Our initial test scenario is here. Let’s look at the interesting part.

We pick arbitrary number 0x5500 as our victim ID

29:   let victimId = 0x5500;   // Victim ID

And then create initial contracts

40:   // Deploy contracts
39:   registry = await Registry.new(oracle, {from: owner});
40:   escrow = await Escrow.new(registry.address, oracle, {from: owner});
41:   ransom = await Ransom.new(victimId, "Hello", victim, registry.address, 55);

So let’s measure our test coverage we have so far. We’ll use the following command:

./node_modules/.bin/solidity-coverage

This will compile contracts using a special version of solidity compiler that instruments the code, and will run them against a special version of ganache that records coverage events from instrumentation. When done it creates the following report

Not much. We just run the constructors of the contracts. And Ransom’s and Escrow constructors attempt to register with the Registry.

We can also use truffle development console to poke around the contracts.

or run tests against Ganache client

After running against local ganache, let’s look at the accounts’ status in the Ganache

Nothing much has changed. We see that the OWNER (account 0) was charged some small amount (0.08 ETH) for the contract deployment. It is actually a significant amount on the real Ethereum network, about $8 USD in Jan 2019. This is because test networks tend to have much higher gas prices. On a real Ethereum network the gas is much cheaper.

Now let’s write more tests to model the entire exchange. But before doing it let’s tweak the ransom contract a bit. We see that the Ransom contract expects to be payed 100 ether to release the encryption key.

However, the default Ganache setup gives only 100 ether to each account. Problem is that for each transaction in Ethereum we need to pay gas money. We don’t have enough Ether to run the simple scenario. What we can do is change the Ransom contract to lower the ransom price. Let’s set the ransom amount to 2 ether, that’s more reasonable. Here is the change.

Now let’s study the contracts and discern the protocol.

Here is the UML diagram.

And here is the protocol

At the start there are three personal accounts in the Ethereum. The First account is the owner of the block chain, shown as OWNER. The second account is the off-chain oracle daemon shown as ORACLE T third account is the infected Victim account,

Also, sometime earlier, the owner registered two smart contracts being REGISTRY and ESCROW. REGISTRY was created first and it knows all about the OWNER and ORACLE accounts. ESCROW was created after and knows about OWNER, ORACLE and REGISTRY. These two contracts are shared between all the infected victims All of the following transactions take place after infection. Transaction boundaries are shown as green squares. All the smart contract calls inside the square represent a single transaction and must be included in a single block. The transaction is recorded into the block chain if only if all the calls within the box are completed successfully. Note that the ORACLE daemon acts outside of the chain, so oracle sees the events after the transaction is completed and its result is recorded in the blockchain.

Once a victim is infected the owner creates a copy RANSOM contract. The following parameters are supplied to the RANSOM constructor victim_id, encrypted_key, victim address, registry address and one time password (otp). The RANSOM constructor sends a RegisterVictim message to the REGISTRY supplying victim_id and otp which in turn publishes AuthEvent event to the block chain. The AuthEvent contents include victim_id, registry address, otp and owner address. Once the event is posted transaction 1 is completed.
Once ORACLE sees AuthEvent on the blockchain it verifies OTP and starts a new transaction by posting an Authcallback message to the REGISTRY contract. The Authcallback message includes victim_id, ransom and escrow addresses and a Boolean value of True that indicates successful authentication. REGISTRY forwards an Authcallback message to both ESCROW and RANSOM contracts. When RANSOM receives the Authcallback message it posts the RegisterRansom message to the ESCROW. Parameters of RegisterRansom include ransom_amount, victim_id, and victim address Once ESCROW updates its tables with the information received in the RegisterRansom message, the transaction 2 is completed.
At some point VICTIM gathers funds and pays the ransom by sending a PayRansom message to ESCROW that includes victim_id and a copy of the encrypted file. Together with a PayRansom message the victim sends requested amount of ether. Once ESCROW receives a PayRansom message it looks up the victim’s RANSOM contract address and sends back a RequestKey message with no parameters. RANSOM receives the RequestKey message and in turn sends a DecryptKey message back to the ESCROW. DecryptKey has two parameters victim_id and encrypted key. Once ESCROW gets the DecryptKey message it posts DecryptEvent event to the blockchain. DecryptEvent contains the following parameters victim_id, encrypted_key, encryptedFile Once DecryptEvent is recorded by the blockchain the transaction 3 is completed.

When ORACLE sees DecryptEvent, it decrypts the encrypted key, then uses it to decrypt the encrypted file and sends a DecryptCallback message to the ESCROW. DecryptCallback message includes victim_id, decrypted_key and Boolean value of true that indicates that oracle decrypted the file successfully. Once ESCROW receives DecryptCallbackEvent with victim_id and decrypted key it stores the key on the blockchain and sends a FulfillContract message to the RANSOM. At this point transaction 4 completes.
After one or more contract have been fulfilled the OWNER can send a ‘Withdraw funds’ message to the ESCROW to request the collected ether to be transferred back to the OWNER account. A WithdrawFunds message includes the amount to be withdrawn and the owner account address. Once ESCROW receives a WithdrawFunds message it transfers the requested amount to the OWNER account at any point after. Transaction 5 is completed.
Victim can call RANSOM contract’s to getDecryptionKey method to request decryption key. When RANSOM gets getDecryptionKey call, it forwards it to the ESCROW which in turn returns back stored decryption key sent by the ORACLE. This is not shown on the diagram, because it is a ‘view’ only transaction that does not affect the state of the blockchain, therefore it is not even seen by miners.

Let’s implement the above scenario as a test.

And let’s measure the coverage again.

Much better this time. We have covered must of the code except for some minor edge cases and failures.

Running this scenario on the local Ganache a couple of times shows that victim funds have depleted by 4 ether and the owner account balance has increased by the same amount.

You seeing a decrease of 4 and not 2, because I ran the scenario twice before taking this screenshot. Note that 0.33 ETH went missing. Gas prices on local Ganache are very high.

So having completed the test, let’s see how can we exploit this

Nothing from standard bag of tricks seems to work. Maybe the solution lies in the interaction of different pieces.

Let’s look at the message flow chart again.

If we can slip in our own Ransom contract with the amount set to zero, we should be able to get the key with paying 0 ether in ransom. Which means not paying it at all, except for a small amount used for the gas.

We already saw that by modifying the Escrow contract we can set the ransom amount to 2 ether only. Let’s try setting it to something even lower, how about 0 wei. But first let’s try it in our simulation environment.

Let’s make a new contract and call it ZeroRansom, by making a copy of a standard Ransom contract, and then modify it to demand zero Wei for the ransom.

Here is the modification.

Let’s give it a try.

It works! We have got the key by paying 0 WEI.

Let’s look at the balances

Looks like everybody’s balance is still close to 100 ETH. Just some gas money was spent.

So, if we can deploy this ‘improved’ contract instead of the standard escrow contract, we can recover the key without paying any money.

Looks like Ransom contracts self-register on construction. It seems that all we need to do is just construct it with standard parameters.

To explore our progress on the real block chain we will use our exploratory notebook we have developed for Task 4.

Use this version to run it on your own computer. Or you can use this version to run it on Google Collaboratory platform without downloading or installing anything.

For that we need to set us up with Metamask wallet and Remix IDE. We’ll use the Web version of Remix IDE.

First follow instructions on the Challenge resources page to install Metmask client and connect it to the Challenge blockchain. Then click on this link to open Remix IDE.

You will see something like this:

Click on a button pointed by the arrow to upload the provided contracts to the IDE storage.

Upload all the contracts Ransom, Escrow, ZeroRansom and Registry. Then make sure that the version of solidity compiler used by IDE actually matches the versions that our contracts are written in.

Click on this button here.

And select correct version 0.4.24. You need to do this because Solidity is a very rapidly evolving platform, the language itself changes almost every month, to the point that it source code could quickly become unparsable by the current compilers.

Open all the four contracts you just have uploaded in the tabs by clicking on their filenames and then once all of them are opened press (ctrl-s / cmd-s) to compile.

If it worked correctly you should see something like this.

Now, let’s try to talk to the existing contacts. Switch to the run tub of the IDE by selecting ‘Run’ item in the top right menu.

We will not be deploying our contracts to the blockchain, rather we’ll attach newly compiled code to the already deployed contracts. For that we need contract addresses.
We can get Escrow and Ransom addresses from the ransom note left to us by the attackers. To attach to the Escrow, select it from the list of contracts and then enter the address next to the ‘At address’ button. Once done click on the green ‘At address’ button to make an attachment.

Do the same for the Ransom contract using the address given in the ransom note We are not given the address of the registry, but it can be easily found via our exploratory notebook.

If you did everything correctly, you should see something like this.

To verify that we have attached to the correct contracts try invoking some of the contract’s methods. To invoke a method, expand the contract by clicking a small triangle button on the left side. Then select the name of the method you want to invoke, if required enter parameter values, then click on the method name to invoke it.

Here is an example of a method invocation:

Note that the Escrow contract doesn’t have any executable methods open to the public except for the payRansom which requires payment.

Let’s try to deploy our ‘patched’ version of the ransom contract.

To deploy, it first select ZeroRansom contract from contract list, then expand the Deploy dialog, and then enter the parameters for the contract’s constructor.

Use the victim_id from the ransom note
For the encryption key use the one you got by solving task 2
victim_adrress comes from the ransom note as well
the registry address comes from the exploratory notebook shown above
Now the only parameter left is authToken. Let’s use the information given to us in task 3

You should get something like this:

Once you enter these parameters, press the green transact button Since contract deployment requires gas money, you get the metamask prompt asking for confirmation to spend $.20 for gas

Press confirm, and wait a little bit. In a few seconds you should see notification from the metamask that the transaction has been completed. Click on the metamask icon in your browser extension bar, to confirm that our contract was deployed.

You should also see a new ZeroRansom contract in the deployed contract list of Remix IDE. Now let’s try to interact with it.

There seems to be a problem. The contract doesn’t know its attached Escrow, it is not authenticated, and getDecryptionKey method just fails straight away. Calling ‘getRansomForVictim’ method of the registry contract gives the old contract address not the new one. This doesn’t seem right.

Let’s use the exploratory notebook to check the state of the blockchain. More specifically let’s see the AuthEvents.

Our AuthEvent was posted correctly.

And this is the callback event coming from Oracle.

The good news is that Oracle did respond to our attempt to register, the bad news is that it did not recognize it as valid registration.

This is because the OTP value is time sensitive, and only valid within a very short period after it was generated. We need to find a way to generate them ourselves.

Side note

Querying events on the block chain could involve scanning every single block stored on the chain. You could get an overwhelming number of results or more likely the client will just drop your request if number of blocks is too large.

In order to avoid this, we must limit the range of blocks we are scanning for the events. That’s what fromBlock and toBlock parameters are used for in the above examples. We always scan to the most recent block but we need to set the starting block to something mined not very long time ago.

Use the exploratory notebook to find out the most recent block number.

Then subtract a 1000 from this value and use the new value with the fromBlock parameter.

So back to our task.

Making oracle accept ‘fake’ contracts

We need Oracle to accept deployment of our fake contracts. Looks like we cannot reuse old OTPs, probably because they expire quickly. We need to reverse engineer genotp function of libclientcrypt.so, so that we can generate the OTP values ourselves.

I’ll skip the Radare part, it is very similar to what we did in Task 2.

Here is extracted code and test routines.

To test the code we need to know a valid OTP code and the exact time it was generated We can get this information from the victim_identification file given to us in Task 3.

One small obstacle, the gen_otp routine requires the timestamp value to be in epoch time format, not a human readable string. We’ll use the Epoch converter web app to convert it. Once we have it we can run out test to validate the model

Now we can try registering the the Ransom contract again. All we need is the current OTP.

To get it let’s head over to the Epoch converter site again and request a new timestamp for the time that is about 2-3 minutes from now. Since we don’t know at what time the OTP expires, lets use 35 for the seconds value to match the number that we saw in the victims_information file.

Then we change our test to use this new timestamp value and run the model again.

We got our new OTP.

Let’s try deploying this contract again, using the same arguments as before, but with the new OTP value.

After deployment is confirmed, let’s look at the blockchain events again

Great, this time it worked.

Now let’s poke at it with RemixIDE.

Much better, now the new contract is authenticated and attached to the Escrow.

All we need to do now is to call payRansom method of the escrow contract giving it 0 ether. Note that payRansom contract has two parameters vicitmId which we know and the encryptedFile which is given to us in this assignment. There is a small problem with encryptedFile. It’s a JSON string, and RemixIDE doesn’t work with them properly. It just passed them into the call verbatim, which results in an invalid JSON-RPC call. To make it work we need to first JSON stringify it.

We can use the browser console for that.

If you work in Chrome on Mac, press Cmd-Ctrl-I then follow example below.

Cut and paste output of the JSON.stringify to the REMIX IDE encrypted file parameter and press the green payRansom button.

Again you get a Metmask prompt asking whether it’s ok to spend a few cents on gas. Once the transaction is confirmed, let’s have a look at our ransom contract again.

All we need to do is press the getDecryptionKey button get the key and submit it as the answer.

And now on to the final Task 7

CodeBreaker2018 walkthrough, Task 5 Containment

Wed, 09 Jan 2019 00:00:00 GMT

In this task we are asked to find out which hosts were infected on our network given the victim IDs we have discovered in Task 4.

What do we know so far:

We have a list of all VictimIDs
We can the generate the correct VictimIDs the given IP address and OTP
We know the IP range for our network is 10.47.0.0/16 (2^16)
We know that OTPs are 6 digit numbers (roughly 2^20)

Given the above we are looking at the problem space with the size of 2^16 * 2^20. This is roughly 10^10 tries. In these days of cloud computing, multi-core CPUs seems pretty feasible to brute force. Looks like 100 something cores cluster will be able to to crack this in a few minutes.

Configure CI server

These days when faced with this type of tasks, I use continuous integration (CI) servers. My favorite one is Go.CD. Unfortunately, the particular feature that we’ll need to solve this task cheaply and efficiently is only available in the enterprise version. So, we will go with Jenkins.

To solve this task I have launched a brand new Jenkins server using standard configuration. After initial setup, we need to install the following plugins:

Amazon EC2
GitHub API
Job DSL
Chucknorris
Github
Matrix Project
Matrix Reloaded
Timestamper

The only Jenkins job that we will create by hand is the seed job, which will bring up the rest of the jobs.

To create the seed job first click the ‘New Item’ link on the main page of Jenkins.

Then select Freestyle Project as the project type. On the configuration screen select the checkbox Github Project and enter https://github.com/vladistan/codebreaker-2018-jenkins-seed/ for Github Project URL. Also, enter https://github.com/vladistan/codebreaker-2018-jenkins-seed.git as git repository URL. Make sure to pay attention to both URLs they look the same, but the last one ends with .git

In the build triggers configure it to Poll SCM and enter H/2 * * * * as the schedule. With this schedule string the Jenkins server will poll the GitHub seed-job repository every two minutes, and when it detects the changes it will apply them to existing jobs right away.

Scroll down to the Build section and click on the Add Build Step button. When pop-up appears, select Process Job DSLs

Configure DSL build step to look for the job definitions on the file system, and enter **/*.groovy as the DSL script filename pattern.

Finally save the job. Once you do it the Jenkins server will start polling GitHub and create jobs defined in the scripts placed in the repository.

After a few minutes, you should a see a new job called vlad-task-5 appearing on the Jenkins main screen. Running this job will give you solution to the Task-5, but for my personal set of input. Let’s examine this job in details and see how to customize it for different sets of inputs.

Brute force ID cracking job

We will use the following method to find the IP addresses by brute force

We will add a few routines to the model that will use the CID routine to generate series of CIDs for the given range of IP addresses and OTP values. Also, we will add functions to see if these newly generated CIDs match any of the known CIDs. Finally, we will add functions that generate individual IP addresses and OTP values given the range.
We will create a cracking program that given the IP subrange will try all possible addresses and OTP values in that subrange to see if any CIDs that are generated using these match CIDs known by us.
We will put this program into a Docker container
We will use the Jenkins server to the container against every possible subrange within the range of IP addresses given to us. We will use Matrix Project plugin for that.
Jenkins server will create a number of temporary EC2 instances necessary to run the cracking program. Jenkins will take care of spinning up the instances when there are jobs to run and will shut them down when they are no longer needed. For that we will use Amazon EC2 plugin.
That cracking program will be set up in such a way that it will indicate a failure when it finds matching CID. If it doesn’t find any matching CIDs in the given range it will finish successfully. Doing it this way makes it easier to spot the runs we are interested in.

Here is the modified model with all functions, tests, and an instance of cracking program

Since cracking program takes some time to run and go over all possible OTP values and networking addresses we need to divide our search space into smaller manageable chunks. From network_information.txt we see that we need to cover /16 size network. Which means that first two octets of the IP address always remain the same and two others vary between 0 to 255. We will break down our runs to probe a single value of 3rd octet and 16 possible values in the 4th octet. This way we’ll need to have about 4000 runs of our program or more precisely 16 * 256

Let’s test it using the IP address that we already know, being the one we found in Task 0 10.47.114.22. This address can be found in the search segment 114 1. First number is just a third octet of IP address (114) and second number is the second 16 address region of the fourth address. First region is 0-15, second is 16-31, etc.

Let’s give it a spin.

Great, we have found the IP address.

As mentioned above, the Jenkins server will be launching EC2 instances that run standard distribution of Amazon Linux without anything preinstalled. The cracking program cannot run on such instances as is, because they miss necessary pre-requisites such as CPPUtest and OpenSSL libraries. Instead of messing with configuration of these ephemeral instances to install all prerequisites and dealing with potential version conflicts, we will run our cracking program using Docker.

Docker lets us bundle everything that is needed to run the program into container. This container can be downloaded and run on any type of machine without installing anything except for the Docker engine.

Here is the Dockerfile that we will use to build our container. To build the container run the following command

docker build .

You should see something like this

We’ll use a two stage docker file. In the first stage we’ll download all the prerequisites necessary to build the cracking program. In the second stage we’ll copy the built cracking program and it’s runtime dependencies to a much smaller barebones container. This approach keeps the container sizes smaller. You need to keep your containers small to avoid long download and setting up times. This is especially true for the cloud environments like AWS where we are billed for every minute of running time.

Once build is complete, you will see something like this.

Pay attention to the last line, indicated by an arrow. The hex number there is the image ID, which you’ll need to run our image.

Detour. Creating dockerhub repository

To run the docker container of our cracking program EC2 instances created by Jenkins need to download it from somewhere. The easiest place to host public docker containers is Dockerhub

Follow the link above and sign up for the free account if you don’t already have one. Once you logged in to dockerhub with your account, create a new repository by clicking Create repository button.

Enter repository name and make sure it has public access.

Continue solving the problems

docker login

Tag the image we just built for uploading using the following command

docker tag IMAGE_ID DOCKER_ACCOUNT/REPO_NAME:VERSION

Substitute the IMAGE_ID with the ID you got at the end of the built, use your docker account name for DOCKER_ACCOUNT. For REPO_NAME use the name of the created repository. For version number use any number, if you ever need to upload a new version of the container make sure to increment this number.

For example, my command looks like this:

docker tag b13142962697 vladistan/cb2018t5:0.1

Once you have tagged your image use the following command to push the container image to the docker hub.

docker push DOCKER_ACCOUNT/REPO_NAME:VERSION

the output should look like this:

Now, that we pushed the image, let’s look at it on the Dockerhub.

Yes, it’s there

Now let’s repeat the test run using Docker

docker run vladistan/cb2018t5:0.1 /p/find_ips 114 1

Looks good.

Now, let’s have a massive run. Here is our test Jenkins job definition. And this is how it looks in Jenkins.

Each green bubble represents a single run of the job. Clicking on a bubble will take you to the details of the particular run represented by that bubble.

Now that we see everything is working we’ll need to bump things up a little bit. Cloud providers like AWS charge per compute hour. This means that it will cost us the same amount of money to run 100 cores for one hour, or one core for 100 hours. But it will take 100 times longer to do the later. What we need is a few really big machines.

36 cores looks like a nice option for the task.

Also, we don’t want to pay the full price if it’s possible. Let’s check the spot market.

Looks like the real price for that machine is $0.58/hr which is better than the full price of $1.53/hr.

So, let’s enter these parameters machine_type and spot_price into the Jenkins Ec2 plugin configuration. We’ll bid $0.63 cents so that we don’t get shutdown during the run. A spot price depends on how much and how many people are willing to pay and the number of available machines is limited. There is always a chance that someone will come in a middle of our run and will offer a higher price for the machine. When this happens our machine will get shut down and be given to the highest bidder.

We have a 36 core machine, which means we can run 36 independent containers at the same time. Our jobs are CPU bound, each container will always take 100% of the CPU core during the run. But we shouldn’t use entire the CPU, we need to leave some capacity to Jenkins and Docker so that they can orchestrate the runs, collect the logs and shuffle them to the master node, etc. Let’s allocate 32 out of 36 cores to our jobs and leave 4 cores to Jenkins and Docker.

Bill Gates said 640 is enough for everybody. We’ll settle for half of it.

Now let’s change the job to run over the entire space.

This is how it looks like in Jenkins

Now we press the run button, and we got close to 3000 jobs on the queue.

Jenkins spun up 7 instances and started to run the jobs. We got 224 cores chugging. (7*32)

After 14 minutes the jobs are done, and we see that some of them have failed.

Let’s click on the red balls to see why they have failed.

Great, we have found the victim IP address. Let’s look at the other jobs and collect the client IDs and IP addresses.

ea1e03022cc3a0378ef9056b5346befdf735f56d56509dcb3d1ea03191803815
FOUND: 10.47.4.142
472d7834f4dd0ab70b631f58a923af3c8db18913491e03a6679bbe4ff8e658eb
FOUND: 10.47.32.49
b784c8325a15d7b7d62d4ded79b86b08fd0cbc8ed0099fee200b55ef8791eae6
FOUND: 10.47.114.22

And then let’s submit those to the challenge.

We have brute-forced the whole thing under 20 minutes of running time, using 10 machines paying $0.63/hr for each one. The total cost to solve this problem is about $2.00. Not bad at all.

Note, my actual costs were a bit higher. I am still learning how to write programs that run correctly first time I run them. Because of this it took more than one attempt to solve the problem. My actual costs were about $10.00.

Additional reading material

We used the Jenkins server to help us orchestrate the efforts and organize the results. To read more about it, I suggest to have a look at Jenkins: The Definitive Guide by John Ferguson Smart
To configure jobs we have used Jenkins Job DSL language. It’s based on Groovy and to read more about Groovy consider this book Programming Groovy 2: Dynamic Productivity for the Java Developer by Venkat Subramaniam

Now on to Task 6 Loophole.

CodeBreaker2018 walkthrough, Task 4 Victims

Tue, 08 Jan 2019 00:00:00 GMT

Now we need to find out who the the other victims are. To solve this task, we need to have some understanding of how blockchain works.

Before starting this challenge, I had absolutely zero knowledge about the blockchain. It took me about two weeks to learn the tools and gain proficiency. It’s not that hard, but some basic understanding of cryptography is helpful.

The best resource that I found is Will Button’s course Learning Blockchain Application Development. This course is about 3.5 hours of video lectures and takes about a day to finish if you follow the course step by step and do all the projects together with him.

Another good resource is Jan-Erik Sandberg Blockchain Fundamentals on PluralSight.

Once you cover these introductory materials, read the following articles

Getting Deep Into Ethereum: How Data Is Stored In Ethereum? - it is very detailed and technical. You can just skim it, no need for complete grokking of the material. However, at least surface level understanding of the material is essential for solving this task.
How to read Ethereum contract storage - less technical than above.

I developed a Jupyter notebook that lets you poke around different pieces of the blockchain. You can download the notebook from above link and run it on your own computer. Or you can use this version to run it on Google Collaboratory platform without downloading or installing anything.

Let’s start solving the problem.

Open the exploratory notebook, and find in the Settings section find the cell that looks like this.

Replace the value of URL with the one given to you in the file called blockchain_information.txt.

Then execute next cell to verify that everything is configured properly and you can connect to the blockchain.

Keep executing the cells, until you get to the section called Constants

In this section, change the values of victim, escrow, ransom and victimid with the values given to you in the files `ransomnote.txtandblockchain_information.txt`

In the blockchain_information.txt you find the value for the address of your victim account. Put it into the accounts section

In the ransom_note.txt you will find the rest of the values

Do not touch the variables that are assigned value of None. We will get these values through the blockchain examination.

Now on to the solution.

If you have read all the material above, you’ll understand that all the storage variable of Ethereum smart contract are stored on the blockchain and are publicly available for reading by anyone. The private modified used by Solidity language is just a syntactic sugar.

Let’s take a look at some simple variables of the escrow.

Now, let’s take a look at the Ransom contracts that Escrow knows about

We have almost got a solution to the task. We know the ransom contract address for each victim, but the assignment asks for victim_id not the contract address. So let’s look them up in the ransom_map mapping.

Great, we have found all the victim ids. All that’s left is to identify which victims have already paid the ransom and which have not. Let’s look those up in vicToPayer map.

Now we have gathered all the answers.

Let’s submit the IDs victim of the victims who have paid and of the ones who have not.

And now on Task 5 Containment

CodeBreaker2018 walkthrough, Task 3 Connections

Mon, 07 Jan 2019 00:00:00 GMT

While solving Task 1, we didn’t reverse engineer the CID function. This time we will. Again, we” be using Radare.

Looks like it uses epochtime, and then calls unnamed function. Most likely that’s the OTP calculation.

Aha, looks like it is a SHA256 HMAC signature calculation. It uses the same secret key that we recovered in Task 2

cid = HMAC( 'IP_ADDR | OTP')

The full implementation of the function with the tests is here. Note that in our test cases we have used the IP address and the OTP values that we have recovered in Task 0 and Task 1.

All we need now is too look at the victim_information file to get the new values for IP address and OTP.

Then enter them as the input of the test case. Here is the example.

Let’s run the model again with the new values.

The test case is failing, but we do now have the new CID value for the other victim. We can submit it now.

Let’s got to Task 4

CodeBreaker2018 walkthrough, Task 1 It begins

Sat, 05 Jan 2019 00:00:00 GMT

In this task we are asked to examine the binary pieces left by ransomware and captured network traffic to extract the following information:

Victim Identifier
Encrypted Ransom Key
One-Time Passcode (OTP) used to authenticate the client to the ransomware LP
Escrow contract address

There are two ways to do this:

we can just extract this information from the dump using some guesswork and a bit of luck, or;
we can go the full reverse engineering route.

The second option is a fast one, but we will then run into problems during the following tasks, so we have to reverse engineer everything anyway.

Let’s do it the right way the first time.

We are given two binary shared libraries that are pieces of a larger program. The challenge states that the rest of the ransomware has been removed by the attackers after the infection.

We will solve the problem by building the model that incorporates the reverse engineered code from the libraries, the unit tests that exercise the code under different conditions and some mock up code to simulate the attackers’ infrastructure.

The mock-up code is very important for several reasons. Firstly, the ransomware is a client-server type of system for which we have only the client. We don’t have any control over the server part, nor should we communicate with the attackers while trying to develop countermeasures against them. Secondly, even if we had access to a ransomware server, we still would use the mocks because the distributed network development is very hard. It’s much easier to work on something that is self-contained within a single process that we have complete control over.

We will use a standard mock pattern by following these steps:

Prepare canned responses to the ransomware code
Reset the mock to initial state
Call ransomware function under tests
- Mocks check that they were called with the expected parameters and return the canned response back.
We’ll assert that mocks we called correct number of times in correct sequence with correct parameters
We’ll also assert that function under test returned expected result

You can read more about mocking here. We will use a cpputest library which includes both great unit testing and mocking package.

Let’s begin.

First we setup our initial model. This model is just a skeleton framework with some rudimentary tests, and then we will expand it later in the process.

Then we’ll use wireshark to dump the conversation between the ransomware and command post into the form of C arrays. This is very handy to use in our model code.

Open provided traffic capture with wireshark
Right click (on mac CMD-Click) the first packet and select “Follow TCP Stream”
Once you see the conversation dump, select show as C arrays and save the file into the model code.
Include saved file into the model

Now that we have test data, let’s take a crack at lib_comm.so. We will use a combination of Dissasembler.io and Radare. If you haven’t done Task 2 yet, I strongly recommend completing that task first, before doing this one.

We start by having a look at the code with Dissasembler.io.

Most functions in the library are just shims that glue dynamic libraries together. Except for the three at the bottom that seem to do something useful. Unfortunately, disassembler.io doesn’t do a very good job at resolving external references. This makes it quite hard to understand what is going on. Perhaps Radare will be more effective.

Yes, this looks much better. Now we do see the actual mentioning of external names. The function at 0xa30 is just a standard DLL shutdown / clean-up function, and can be ignored for now.

Let’s look at the one at 0xb30

Although disassembler.io was not that helpful with the external names, it is very effective when much better with analyzing the structure of the code.

Looks like a function that tries to send a fixed size buffer while handling the case of partial transmissions due to full buffers on the local host.

What else can we learn from it?

We confirm that our block size is 0x300
We also see that they are trying to be Object Oriented and pass around an object of 0x790 bytes long, that includes 0x300 size buffer.
Also we see that the buffer starts at position 0x320

Let’s copy these facts to our model. Here is our reverse engineered transmit function.

Now let’s take a look at at the next function.

Again the structure dump from disassembler.io comes in handy

as well as the analysis done by the Radare2.

An ugly set of parameters

However, it doesn’t look that bad

Mostly just a bunch of data shuffling back and forth

Let’s rewrite those back in C. We see lots of calls being made to libclient_crypt.so routines. For now, we’ll just hardcode their responses using the information we got from the wireshark dump.

But, we’ll make one exception with regard to the above. Let’s look at what the BCVH function might be doing. Looks like it just converts binary values to hex strings. We can just write one like this without resorting to reverse engineering tricks.

Here is the result of our efforts so far.

These are all the functions that seem interesting in the libclient_comm.so

Let’s look at the crypto library

First let’s take a look at the functions.

Some of those like base32 decode/encode we can just write ourselves, this is faster than digging through reverse engineering. The V_hh function looks like some kind of authentication function. Since we know that this is a successful exchange between ransomware and the server we’ll just stub it. It doesn’t look relevant to our task anyway.

We’ll use RFC-4648 for the spec of base32 encoding.

So here is what we got so far.

Now we’ve got all basic functions. Let’s see if we can compute the packet signatures that we have had hardcoded.

Let’s see what Radare shows.

Looks like c_hh is just straightforward HMAC setup using SHA256 follow with the call to BCVH for which we already have a source code. Let’s code it up and see if it works.

Here is the implementation of the real checksum function and the rest of the protocol.

Now we understand completely what the protocol is between client and the server. It looks like this

Here is our assumption of the meaning of each message:

HELLO - initial message to the server, include victim IP address, victim ID, OTP and Encrypted Ransom Key. The message is signed with Ransomware secret key using HMAC/SHA256 protocol
ACK - server responds with an ACK of some sort
PING - Ransomware again sends a message to the server, this time it’s just a signed victimip and victimid signed using the same method
PONG - server responds with an ACK of some sort
BYE - finally ransomware sends the final message which is just a signature of the last ACK received from the server

NOTE The names of these messages are made up by me. As typical in reverse engineering scenarios we don’t know the actual names of the variables and constants used by original programmers. This could be viewed as both a good and a bad thing. Having looked at a considerable amount of bad source code, sometimes bad source code is worse than not having a source code at all. The combination of modern optimizing compilers that clean up and remove redundancies, and streamline code and modern reverse engineering tools that show graphs of basic blogs like the ones shown above, give a lot of insight into the internal functioning of the software.

The protocol looks pretty naive and convoluted, probably the attackers are trying to guard against replay attacks and substituted malware code.

Now that we have a complete reverse engineered model of the ransomware code we can take a look at the code that prepares the HELLO packet.

the structure of client HELLO packet

and these unit tests

as well as the ransom note

and a dump of the hello packet

and we have all the information we need

Escrow contract address - has been given to us in the ransom note left by the attacker
Victim Identifier - has been given in the ransom note, we can also see it in the dump of the hello packet
One-Time Passcode (OTP) - in the dump of the hello packet, the 6 symbols that immediately follow the victim identifier
Encrypted Ransom Key - again in the dump of the hello packet. It’s the rest of the data after OTP

Note on the encoding. The encoding of the messages is little bit weird. Looks like they convert all binary values to their hex representation, except for the OTP which is converted to decimal. Not clear what the attackers trying to accomplish here. Perhaps the command server is written in the language that is not very friendly to binary encoding. (Javascript?)

Now that we have all the data, we can submit it to the challenge.

Additional reading materials

We have relied a lot on test driven development (TDD) techniques. It was not a pure TDD, because that we already had a code. But a lot of practices came from the TDD approach. Kent Becks’ Test Driven Development and Roy Osherove The Art of Unit Testing are great introductions to these techniques
To learn more about Mocks, read Martin Fowler’s article Mocks Arent’ Stubs
Most of the TDD material out there usually talks about projects written in languages like Java / Python / Ruby / Javascript. The James Grenning’s Test Driven Development for Embedded C describes a lot of techniques we have used to solve this task
The best way to learn TDD is to by practicing. And the best way to practice it is with the group of people. Checkout these meetups if in your neighborhood:
- New York
- Baltimore
- Austin
- Boston
- Washington,DC
- Global Day of Code Retreat — annual event happens around November.

Let’s continue to Task 3

CodeBreaker2018 walkthrough, Task 2 Secrets

Fri, 04 Jan 2019 00:00:00 GMT

Let’s look at Task 2 before doing Task 1. It is a much quicker and easier task, and it is a good warm-up practice in reverse engineering before we dive into the much more complicated Task 1.

In this task we are asked to extract a secret key from the binaries left over by the ransomware. To solve this we need to use some reverse engineering tools.

The organizers of recommend IDAPro or Binary Ninja. IDAPro is indeed an excellent tool, but unfortunately in order to get the full functionality you have to buy the complete version which is quite pricey. I have never used the Binary Ninja, looks like a good tool, but also expensive.

To keep this accessible to everyone I have opted for the free tools Dissasembler.io and Radare

The first one is a web application, you don’t need anything to install. The second one is an open source tool which is a package with many distributions. For example, on Mac you can use the excellent Homebrew package manager to install it.

brew install radare2

Radare will come in handy for Task 1. In this task we’ll stick with Dissasembler.io.

Let’s start.

Download libclient_crypt.so
Open Dissasembler.io in your browser
Click on the start disassembling button that looks like this.
Once the app loads, upload your libclient_crypt.so file.
After a short time your file will be disassembled and you’ll see the screen like this, with the symbols pane on the left and the code pane on the right.
Scroll all the way down on the symbols pane.
Most functions names are self-explanatory, except for the one that is called func_00001930, this looks suspicious. Click on it’s name to see the code.
These MOVB instructions look interesting. Seems like this function is writing a sequence of byte values to a memory location.
So, what’s can we say about these bytes? We see that these values range between 0x30 and 0x59, which covers digits 0 and uppercase letters.
Let’s refresh our memory about Base32 encoding here and here.
We see that the most common form of Base32 encoding uses uppercase letters A-Z and numbers 0-9.
Most likely this is what we want.
Let’s convert these hex values to their ASCII representation to get the string CAYPFE6MG2DJT4EB5RIZLIAYFJAUGL3L
Let’s submit it to the challenge
Voila!

Additional reading materials

If you want to find out more about the way we identified our suspect function so quickly, check out these reading materials.

Very comprehensive series of posts about linkers and shared libraries https://www.airs.com/blog/page/4?s=linkers
Linkers and loader by John R. Levin — very comprehensive overview of linkers, loaders and shared libraries. Somewhat dated, but things haven’t changed that much since 2000

Let’s move on to Task 1

CodeBreaker2018 walkthrough, Task 0 Warm up

Thu, 03 Jan 2019 00:00:00 GMT

This task is really simple, all you need to do is download the given capture file and analyze it with a tool such as tcpdump or WireShark

Let’s use tcpdump.

The provided PCAP file contains a dump of a single conversation between two hosts; first one with IP address 10.47.114.22 and the second one with IP address 172.17.39.217. We also see that host 10.47.114.22 sends out the first packet and it has a higher port number than host 172.17.39.217. So we can assume that this is a typical client server design where Ransomware reaches out to the control host first. We therefore assume that the address of command server is 172.17.39.217

Let’s try.

Yes, our assumption was correct.

Let’s continue to Task 2

CodeBreaker 2018, complete walkthrough

Wed, 02 Jan 2019 00:00:00 GMT

Every year publishes a challenge to reverse engineer and exploit something. Past challenges involved disarming simulation of IED (improvised explosive device), making sense of encrypted SSL traffic and so on.

This year the challenge was to analyze blockchain based ransomware, retrieve the decryption keys without paying and ultimately refund all the victims who already paid.

This year is the first time I managed to solve the entire thing with the other 19 finalists. Only 1.3% of the participants solved all 7 problems.

I will be posting a complete walkthrough on this blog, stay tuned.

Use the links below for the complete walkthrough of each task.

Welcome to the new home!

Tue, 01 Jan 2019 00:00:00 GMT

I haven’t been posting regularly here for a very long time. We’ll try to resume this blog. Let’s see how long it’s going to last this time.

Simple script to convert opml to markdown

Wed, 23 Apr 2014 00:00:00 GMT

I just put a quick transform script to convert outlines generated by OmniOutliner to MarkDown slide deck. The markdown is specific to Wiki2Beamer flavor.

Here the script code is here.

It is not the best of the XQuery code, but it does the job.

New version 0.5 of AWS4C has been released

Tue, 28 Jun 2011 00:00:00 GMT

Just released new version of AWS4C library.

The new release includes support for S3 delete operation. Check the API Reference and example code in s3_delete.c for details.

The library could be downloaded from here: https://github.com/vladistan/aws4c

Have any questions or suggestions write to me ‘tutorials@v-lad.org’ or post your comment here.

This release was made possible thanks to the anonymous contributors, who submitted these fixes.

Port of RXTX library to Android platform

Tue, 01 Mar 2011 00:00:00 GMT

Just ported the RXTX library to the Android platform.

Check out the picture below, it shows the Motorola Droid phone talking to the FreeNAS device over the serial port.

Reference-style:

Testing android with serial

More information and binaries are here http://v-lad.org/projects/gnu.io.android/. The source code of port is here https://github.com/vladistan/gnu.io.android/ .

If you have any questions, comments or support request post them below.

New version of AWS4C has been released

Sun, 03 Oct 2010 00:00:00 GMT

Just released new version of AWS4C library.

The new release includes support for Reduced Redundancy Storage and some bug fixes related to memory and socket leaks during extended operations.

The library could be downloaded from here: https://github.com/vladistan/aws4c

Have any questions or suggestions write to me ‘tutorials@v-lad.org’ or post your comment here.

This release was made possible thanks to the anonymous contributors, who submitted these fixes.

Compiling native programs for Android

Wed, 18 Aug 2010 00:00:00 GMT

There is an excellent tutorial by Nirnimesh on how to compile native programs for Android here http://android-tricks.blogspot.com/2009/02/hello-world-c-program-on-using-android.html

Unfortunately things have changed a bit since last year when this post was written. Andy’s agcc script doesn’t work with the most recent Google NDK release 4B.

I have changed the script a little bit to address new path changes. The new script is available here http://android-cruft.googlecode.com/files/agcc-0.2.tgz.

Make sure to add this to your path

$HOME/AndroidNDK/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/

Where AndroidNDK is your NDK installation directory.

Hope this works for you.

AWS4C has been updated

Wed, 18 Nov 2009 00:00:00 GMT

Thanks to Henry N. for sending patches to the AWS4C library. I applied and tested them, hence the new release of the library.

Here is the list of changes:

The code quality has been improved. Some memory leaks fixed. Also addressed some warnings given by GCC 4.1.2

Addressed a bug with having wrong file length after get
When debug is not set, don’t print verbose output to stdout
Fixed up EU and virtual host URLS
Now can set the mime-type for the items
Now can attach canned ACL to the items

The library is available at https://github.com/vladistan/aws4c

Have any questions or suggestions write to me ‘tutorials@v-lad.org’ or post your comment here.

AWS4C a C library that lets you work with AWS

Sat, 15 Aug 2009 00:00:00 GMT

Believe it or not some people need to write programs to access Amazon Web Services in C. This project grew out of the conversion of my old HPC project to run on the amazon EC2.

I needed a C library to access the code. Unfortunately I couldn’t find any, so I wrote my own.

The code quality sucks, I wrote the whole thing pretty much in one day. And I wouldn’t use it for anything more then a proof of concept projects unless it is heavily reworked to be more robust. But nevertheless it gets the job done.

The library includes bindings for SQS and S3.

It depends on libcurl for its network operations and openssl for the crypto.

There is also libAWS but it is heavily C++ dependent so it wouldn’t work for all types of C projects.

The library is available at https://github.com/vladistan/aws4c

Have any questions or suggestions write to me ‘tutorials@v-lad.org’ or post your comment here.

Hadoop tutorial for Windows and Eclipse

Fri, 20 Mar 2009 00:00:00 GMT

Hadoop tutorial for Windows and Eclipse.

Just posted a tutorial on how to configure Hadoop environment for Windows using CYGWIN.

The tutorial explains how to set-up a Hadoop cluster in the pseudo distributed mode and how to get it working with the Eclipse.

If you have any questions / comments / suggestions about this tutorial post them here.

The tutorial is located here.

NOTE

This tutorial is 10 years old, and probably nothing there applies to modern data processing. It’s here only for historical reasons