As an Ethereum solo staker, I want my Linux staking box to be as secure as feasible. It applies to physical security too. If the attacker gains access to the validator key stored on disk, it will allow him/her to do malicious things such as intentionally exposing the validator to the slashing penalties.

My machine isn’t placed in a data center guarded 24/7, therefore to protect it from the physical attacker I used cryptography.

Encryption inconvenience

I decided to use LUKS disk encryption which can be enabled easily during the Linux installation. I set a long passphrase and I rest assured my data is well protected.

I need to provide the passphrase each time I turn the machine on. This way the volume key used to unlock the disk, can be derived from the text I enter. It requires a keyboard and physical presence during startup, therefore it may be inconvenient for headless systems.

There are many methods to make it easier. Though I use one of them, I find them either complex, costly, unreliable, or compromising security. I don’t want to discuss them here, because this topic deserves a separate post.

The important thing is, once started, the node should stay online. And with UPS protection, turning it off doesn’t happen almost at all.

Maintenance

To ensure there are no security bugs I perform regular software updates. Modern Linux distributions make it really easy to automate.

However, kernel updates are not that simple. To use a new kernel, the system needs to be rebooted. It’s just a short downtime which is often acceptable.

But when using disk encryption, the disk needs to be unlocked. How to achieve that when using ssh connection from a remote location? Given the fact kernel updates can be frequent, it becomes an issue.

One way to approach it is to try to avoid reboots.

Live patching…

…is a technique to apply changes to the running kernel, without a reboot. There are many proprietary implementations provided as services. Preparing a binary patch ready to be applied to a running kernel seems to me a complex task that requires a lot of testing. Probably that’s why most suppliers charge for this service. In the case of Ubuntu Livepatch, before the patch is pushed to the customers, it is tested on the production systems of non-paying users. That’s the cost of using it for free!

But still, when your kernel gets a live patch it is recommended to reboot in the nearest maintenance window.

I like to use open-source solutions instead of proprietary ones. Therefore I needed something else.

No rebooting at all?

In some environments and threat models, most vulnerabilities in the kernel are not a big deal. If you trust your local users, expose one or a few regularly updated services, and firewall the rest of the ports, then it’s just unlikely for the attacker to succeed. He/she will need a remote exploit in the tried and tested TCP/IP stack. I believe those types of bugs are extremely rare.

In the above scenario, one may choose to keep running with the same kernel, avoiding reboots. For the record: I don’t recommend this approach.

That said, if the only reason for ignoring established good security practices is to prevent reboots because disk encryption makes it inconvenient, then I think we should do better.

We should make reboots convenient.

How I wish it would work

I would like to reboot to the new kernel without entering the passphrase again. It was entered once: can’t it be reused for a new kernel?

Well, we have kexec. It will be 18 this year, but it is not popular amongst people. If you haven’t heard about it, it allows you to replace the currently running kernel with a new one. And it does it without involving hardware reset and executing the boot loader:

$ sudo kexec -l new_kernel.img   # load kernel into memory
$ sudo kexec -e                  # boot the loaded kernel

While being cool, it’s not the same as live patching. The new kernel has to boot the entire system, filesystems need to be mounted and services have to start. The disk has to be unlocked, so the passphrase is required again.

What if it was possible to preserve the volume encryption key?

Linux keeps the keys for disk encryption in the kernel keyring. It is a special, secure place in memory. Even the root can’t retrieve volume encryption keys from there!1

$ sudo dmsetup table
dm_crypt-0: 0 36284416 crypt aes-xts-plain64 :64:logon:cryptsetup:edd435cc-b51a-4530-aef3-5010caeee165-d0 0 252:3 32768

As you can see above, only key reference is provided. The actual key is kept securely in kernel memory.

If the user could tell kexec to keep the given key intact, then the new kernel could reuse it. The newly booted system could unlock the disk without asking for a passphrase. I imagine kexec adds a new option allowing to specify a key to preserve:

$ sudo kexec -l new_kernel.img --keep-key=my-key-reference

We are not there yet

Most of the work related to the volume key preservation feature would need to be done on the kernel side, but kexec and cryptsetup would also need to implement support. From my limited perspective, it seems doable, but I cannot estimate the amount of work required.

In the meantime, let’s try to resolve this issue using the tools we already have.

Initramfs

Kexec allows to pass 2 things to the new kernel:

• kernel command line containing various options for kernel and userspace,

• initramfs which is run by a new kernel to initialize various things, including disk encryption.

We could include a volume key in the kernel command line and later use it to set up disk encryption. It would work, but the kernel command line is visible to the users, which disqualifies this concept.

So we are left with initramfs. This is a file located typically in an unencrypted /boot partition. We definitely don’t want to store the volume key on an unencrypted disk, because it defeats the purpose of encryption.

But we don’t need to modify the original initramfs file permanently. It’s enough to modify it temporarily and pass it to kexec.

Introducing cryptreboot

This led me to create a tool that:

1. Asks the user for a passphrase to derive the volume key.

2. Copies original initramfs into memory and patches it to include the volume key.

3. Uses kexec to load patched initramfs and kernel into memory.

4. Initiates standard system shutdown to stop services and unmount filesystems.

5. On shutdown completion, a kernel with patched initramfs is executed. This step is done by systemd.

Here is what it looks like compared to the standard reboot. If you prefer, you can check the identical YouTube version.

As you can see, the user is still asked for a passphrase, but it’s done before reboot, not after. This way the user could execute a reboot remotely. Physical presence during startup is not required anymore.

From a security standpoint, it should be almost as secure as the standard setup:

• secrets are not persisted anywhere, everything is done in memory,

• volume key touches userspace for just a brief moment; the rest of the time it stays safely in the kernel keyring.

If you have a different perspective, please leave a comment below.

Leave a comment

Cryptreboot is an easy-to-use, drop-in solution written in Ruby and released under the MIT license. You can find it on GitHub.

What’s next

Here are the features I plan to implement:

• boot loader configuration parsing; currently, cryptreboot relies on symlinks or the user to pick the kernel and initramfs,

• optionally persist the volume key on an encrypted disk in a file accessible to root only; this way user accepting a slight security trade-off won’t be prompted for the passphrase at all,

• integration with systemd, to make cryptreboot the default reboot handler,

• deb package to make installation easier,

• support for non-Debian Linux distributions.

If you use disk encryption in Linux, please give cryptreboot a try and share your feedback!

Thank you for reading this post. If you want to stay in the loop, subscribe and star the project on Github, so you won’t miss new cryptreboot releases.

Subscribe now

3 months ago I received an email that got my attention. I subsequently wrote a blog post about it. To make a long story short I suspected the disposable email address I used exclusively for Ledger Card leaked somehow because I got a suspicious email on that address. Later on, I found out the source of the problem lay in Baanx, Ledger's business partner.

Baanx informed the email I got had been sent by a legitimate project, which is a partner of Baanx. I neglected to check the project carefully — that’s on me!

However, it’s only one part of the issue.

The email message came unsolicited to the address which shouldn’t be used for this type of communication. There is no doubt Baanx failed to handle my email address properly. While Baanx might see it differently, I believe this specific mailing campaign reached others as well. However…

The breach probably did not happen

We exchanged a few messages and had video calls with Baanx. I learned a lot of details, which I won’t provide here. The common part of our conclusions is that there was a human error during the handling of marketing email campaigns.

Most importantly, Baanx said they investigated the case, fixed a software bug, and cleaned up internal processes. Here is part of the email I got from Baanx:

There definitely were some "human error" learnings here on our internal processes that were cleaned up, so I thank you for reporting the issue. No other customers or waiting list participants contacted us, so it appears to be a single edge case - at least from reports.

While I think they could do a bit better, I believe them.

The end of this story is positive. Something that looked like a data breach turned out to be a relatively harmless human error. That’s a relief!

A special thanks to Scott Carlson from Baanx for his diligent management of the situation.

2023-07-05 update

I got an official response from CL Card support on Reddit. I also spoke to a person from Baanx. It seems that Anrk is Baanx’s partner. They're conducting an internal investigation. They say there was no data breach. I'm still not 100% clear why I got this email message. I will update this post when more data becomes available.

Here comes the original text

Do you remember how 1 million records leaked from Ledger?

Today I received this funny-looking email message:

Seems similar to Ankr. But if you check it closely you will notice a typo.

Recipient address

“Oh, just another scam attempt” - I thought1. However, when I checked the recipient address of this message, I found this address looks similar to the one, I use exclusively for my Ledger CL card.

By exclusively I mean, I don’t provide this address in any other place. Every time I register somewhere, I use a different, unique email address. This is my method of localizing sources of data leaks (if it was my data that leaked).

However, in this particular case, I used the same email address twice. I used it to contact CL Card support regarding the issues with my card. After closer inspection, I found that I made a typo in my email address when contacting CL Card support. To sum things up, I used:

• address #1 as a login for the CL Card system,

• address #2 for contacting CL Card support2.

The scam message was delivered to email address #2.

Source of the leak

So it seems, my address leaked from the support department and not the CL card system itself. That’s a big relief!

But still, the data we have now leads to many questions. Here are some of them:

• When the leak happened?

• How many other addresses leaked?

• Apart from email addresses, what other data leaked?

• Was it a corrupt or careless employee?

• Was it a CRM database leak?

• Is CRM self-hosted by Ledger or outsourced? Maybe they outsource support entirely?

• Was CRM data transferred into another system (for example for marketing purposes), and the leak happened there?

I can answer the first question. I sent the first message using address #2 on 8th December 2022. So it seems the leak happened between 2022-12-08 and 2023-07-04.

Also, I know Have I Been Pwned doesn’t report my email as leaked. I checked the same day I wrote this post.

I don’t know other answers. But I wonder how many people noticed this too. If you were affected, please leave a comment below.

Leave a comment

My data leaked - what now?

Unfortunately, if your data leaks, you can’t leak it back. It helps if you provide disposable addresses, but your main address will leak someday too. As always you need to be careful with incoming mail.

That’s it

Thank you for reading this short post.

For interested parties, I pasted the headers of the message and the first part of the text below. I obfuscated my email address and some other data which may potentially lead to revealing private information.

Delivered-To: address-2@obfuscated.com
Received: by 2002:ab3:1c15:0:b0:238:9402:e3c6 with SMTP id u21csp4866874lth;
        Tue, 4 Jul 2023 03:00:09 -0700 (PDT)
X-Google-Smtp-Source: APBJJlGIpdLNd8AIX7qcHMNUTlkl5SwX0AIeWFPH3NbG0NmWonNOfJbO6NP308UQD2NXNBzLQOO5
X-Received: by 2002:a17:902:d501:b0:1b8:3936:7b64 with SMTP id b1-20020a170902d50100b001b839367b64mr20459348plg.1.1688464809144;
        Tue, 04 Jul 2023 03:00:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1688464809; cv=none;
        d=google.com; s=arc-20160816;
        b=vppot55BTC0Nh7GIdbYXbKkW+isDHpv7D0N4QQeYwg6qUShM6SncDiiDxRpZGylRNB
         vYll7SyfV7nMe1RkojIwcsGocbl6o8FGgQVgj/sMqZ7bIJNWu0wx+mkQRYOZ5VD/j5pC
         eHPFaD4AadeMlQTtWBrqeZx6lRovpHPBrXJnFQ7BriNOfbINnuxgQgHuAnt9vP8As/Rm
         oij0SvOVoOsXW0wRWOFiWebZ+jmGRUMNWRmkLSsAGnSSAcC7x3+VStBjpg9KMDH37iLr
         WL5MJ7IvbnzmooomKMDeVwrUEKUFVEULpELb7LCF9lM6qAas9bz4XNn8rtgQ0doIfuxh
         mH8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=feedback-id:from:list-unsubscribe:subject:reply-to:mime-version
         :date:message-id:to:dkim-signature;
        bh=8yLsdori4r6GtMEEET+tAfTrVGhEDhyYgbLw94d8CEQ=;
        fh=tDNHxWpIqxviIVEMkK8CTTH5nJteJnWyRzljgxDe6kw=;
        b=Oh3dOJKFdCq5hF0TPRn4pTSwnLdpqhkQbu8ePsrpsa2942ygYm8oqKn8vo1FTIHAqC
         OGWcB6odmBIZxTnE2UktQ13Cxhn7sIWvoxJh4OpGDiF2VmQrvYXvyjrJvAb/xQnVNxYj
         b8YZIK4Q9JTKIhLllhAA2P0Tvo9jY9maEBpz4bs/oq1lFenOrDcuVFwKsJM0AFVtNsBC
         7zjsqMzyPEnVwAeTG1XDr7SgQeq84TESIG/M5j5icR2s40qktBUGIjYnkpCnH5XtW84C
         68W4+/h6Ph2g3gD+t2ze/Fbeg7jdVJfyczvXSUR4/P5YvB4dxeJPvvbq/vZsqPYFnYx6
         qKeg==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@anrkprotocol.com header.s=scph0623 header.b=qQ7u47oI;
       spf=pass (google.com: domain of msprvs1=1954918sqetfe=bounces-280172@sparkpostmail.com designates 192.174.87.92 as permitted sender) smtp.mailfrom="msprvs1=1954918SQEtfE=bounces-280172@sparkpostmail.com"
Return-Path: <msprvs1=1954918SQEtfE=bounces-280172@sparkpostmail.com>
Received: from mta-174-87-92.smtp-out.sparkpostmail.com (mta-174-87-92.smtp-out.sparkpostmail.com. [192.174.87.92])
        by mx.google.com with ESMTPS id kb14-20020a170903338e00b001b6ae9f8bb1si12371885plb.75.2023.07.04.03.00.08
        for <address-2@obfuscated.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 04 Jul 2023 03:00:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of msprvs1=1954918sqetfe=bounces-280172@sparkpostmail.com designates 192.174.87.92 as permitted sender) client-ip=192.174.87.92;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@anrkprotocol.com header.s=scph0623 header.b=qQ7u47oI;
       spf=pass (google.com: domain of msprvs1=1954918sqetfe=bounces-280172@sparkpostmail.com designates 192.174.87.92 as permitted sender) smtp.mailfrom="msprvs1=1954918SQEtfE=bounces-280172@sparkpostmail.com"
X-MSFBL: OWV7igvEEXPJb+7ZJrrlYsThoPLaO1ot/hRxyPVy+gU=|eyJtZXNzYWdlX2lkIjo iNjQ5Y2E1ZWRhMzY0YTExMDVjOWQiLCJzdWJhY2NvdW50X2lkIjoiMCIsImN1c3R vbWVyX2lkIjoiMjgwMTcyIiwidGVuYW50X2lkIjoic3BjIiwiciI6ImNsLWNhcmR zLmNvbS4xMi4xMi4yMDIxLnN5c3RlbUBjcnlwdG9uaXgub3JnIn0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anrkprotocol.com; s=scph0623; t=1688464805; i=@anrkprotocol.com; bh=8yLsdori4r6GtMEEET+tAfTrVGhEDhyYgbLw94d8CEQ=; h=To:Message-ID:Date:Content-Type:Subject:List-Unsubscribe:From:
	 From:To:Cc:Subject; b=obfuscated
To: address-2@obfuscated.com
Message-ID: <obfuscated@jp.mta1vrest.cc.prd.sparkpost>
Date: Tue, 04 Jul 2023 10:00:05 +0000
Content-Type: multipart/alternative; boundary="_----MvvyzH+M+eka7ub4N8/3Kw===_61/D9-38980-5ADE3A46"
MIME-Version: 1.0
Reply-To: anrk@anrkprotocol.com
Subject: On-chain card spending, self-custody and beyond! 🚀
X-Campaign-ID: 7184983
List-Unsubscribe: <https://links.iterable.com/e/encryptedUnsubscribe?obfuscated>,<mailto:unsubscribe+obfuscated@unsubscribe.iterable.com>
From: anrkprotocol <anrk@anrkprotocol.com>
X-Message-ID: obfuscated
X-Feedback-ID: obfuscated:iterable
Feedback-ID: obfuscated:iterable

--_----MvvyzH+M+eka7ub4N8/3Kw===_61/D9-38980-5ADE3A46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Connect to your Web3 wallet to an open source wallet network



 <https://anrkprotocol.com/on-chain-transactions/>=E2=80=8A

Connect Your Metamask, Ledger, Phamtom or Web3 Wallet To The X Card And Spe=
nd=20
On-Chain!


We are building anrkprotocol - an open-source wallet network that allows yo=
u=20
to connect your Web3 wallet to our Mastercard, enabling on-chain spending a=
nd=20
giving you complete custody over your assets. With anrkprotocol you keep=20
control of your funds at all times and you eliminate the need for trust in=
=20
custodians or financial institutions. Join Waitlist!=20
<https://anrkprotocol.com/on-chain-transactions/>=20

I came across an article whose author described the process of creating a smart contract and deploying it to the Ethereum mainnet. He also published the source code.

I didn’t have experience with smart contract development and blockchain analysis, but after reading the article I began to wonder:

Is it possible to use this public information in order to find Ethereum address of this person?

It would be fun to see how much money he holds ;-)

TL;DR

Given the smart contract’s source code it is possible to find it using blockchain analysis. I’ve used Google Big Query to search for specific function signatures. In the end, I give some hints on how to avoid deanonymization.

Disclaimer

I don’t want to disclose the personal details of the smart contract’s author. Let’s just call him John. I contacted John and he approved this article before publication.

Don’t use the knowledge you got here (or anywhere else) to hurt others.

Challenge

I can define a challenge as entering unknown territory with a clear goal in mind. In the area of computer security and privacy, this feeling boosts my creativity in problem-solving, forces me to learn new things fast, perform reverse engineering and try to get into the state of mind of a given system creator.

It gives me the satisfaction of a deep understanding of the system and a thrill, both at the same time. With that motivation, I started researching the problem.

Examine the code

My first attempt was to check for any hardcoded Ethereum addresses in John’s code. The common practice is to set contract owner address dynamically during deployment instead of hardcoding it, and it was also the case here. But it costs nothing to check.

constructor() {
  owner = msg.sender; // set owner to address of caller
}

Compare bytecode

Every smart contract’s bytecode is available publicly on the blockchain. Therefore my second attempt was to compile John’s code and then use some tool to compare it with every smart contract on Ethereum.

I started by finding a way to query the blockchain for the information I wanted. It appears you can’t search by bytecode in popular blockchain explorers such as Etherscan or Etherchain. Googling bytecode is not a good idea, because Google doesn’t allow such large queries.

BigQuery

However, I’ve found Google created a BigQuery public dataset for Ethereum and updates it daily. From the user’s perspective BigQuery is just a large SQL database similar to Postgresql or Mysql used routinely by developers. Its usage is free (within limits) and there is a web-based query tool called BigQuery Console.

I found it perfect for the job. Looking at schema, there is a contracts table and it contains a bytecode column. To see bytecode related to each one of random 10 transactions made on the last day, I could execute the following SQL statement:

SELECT bytecode
FROM
  bigquery-public-data.crypto_ethereum.contracts
WHERE
  block_timestamp >
  CAST(DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) AS TIMESTAMP)
LIMIT 10

Timestamp constrain is optional but recommended. This table is huge. Restricting time interval prevents Google from processing a lot of non-relevant data. I skipped this constrain on my first trials which quickly ate all of my quota.

Knowing the exact bytecode and blog post’s publication date I could find the contract address by executing the following statement:

SELECT address
FROM
  bigquery-public-data.crypto_ethereum.contracts
WHERE
  block_timestamp > {month before post publication date}
AND
  bytecode = {compiled bytecode of smart contract}
LIMIT 10

address is a column containing contract address.

Now I only needed the bytecode of this smart contract.

Compilation

I decided to use a free web-based IDE called Remix because it doesn’t require setting up the development environment.

I’ve created a .sol file in Remix and pasted the code of the contract. Then I opened Solidity compiler tab and set Solidity version to match the version specified in the code. Each file has the following line at the top:

pragma solidity SPEC

In place of SPEC there is a version specification.

Using the same compiler is important because every version may produce different bytecode and I was trying to generate an exact copy of the bytecode deployed by John.

The code was compiled successfully, and I was able to get bytecode.

Blockchain search

To my surprise, SQL query mentioned above didn’t return any values. I modified WHERE statement to use SQL LIKE, which allows finding partial matches:

bytecode LIKE '%{part of compiled bytecode}%'

Then I experimented with passing different parts of bytecode. However, there were no meaningful results neither.

Optimization

Then it hit me. Solidity compiler optimizes code, to reduce code size (contract deployment is cheaper) and execution cost (users have to pay less for gas).

Optimization level is controller by a parameter specified during compilation.

This parameter is a number from 0 to 4294967295. I suspect each number produces a slightly different bytecode.

I didn’t know what optimization parameter had been used. I didn’t want to compile the code and execute SQL queries against the blockchain 4294967296 times. After trying to guess common values few times, I gave up. There has to be another way.

Function signatures

I dug into Ethereum dataset. One of the columns in SQL schema got my attention: function_sighashes.

After some research, I found that, in order for the smart contract’s functions to be called by users or other smart contracts, there needs to be some kind of mapping between the function name and an address in bytecode where the function logic resides.

But what if someone likes to use veryLongFunctionNames? Does it mean the name of the function has to be embedded in smart contract bytecode, increasing blockchain size and eating precious gas?

This may be one of the reasons Ethereum uses the concept called function signature. The function signature is created by hashing the prototype string and discarding anything after the first 4 bytes. The hash algorithm used is Keccak256 which you may know from SHA-3. However SHA-3 uses a version with slightly different parameters, therefore the output is different.

For example, to get function signature for a function myFunction which receives 1 argument of type uint256:

1. Prepare function prototype, let’s say myFunction(uint256).

2. Find an online Keccak256 generator (for example this one) and paste the function prototype there.

3. You will get 50628c969c386d878aac8a993492e42110c19ba346d377fec055d2d56124b695.

4. Remove anything after the first 4 bytes and add 0x prefix to make it clear we are dealing with a hexadecimal number.

5. The result is 0x50628c96.

Those four bytes along with the mapping method will show you where the function resides in a compiled contract (it is a simplification to make you grasp the general idea, check limitations below).

Back to BigQuery

I’ve calculated function signatures for every function of John’s smart contract. Now I was armed with the information needed to find the address of this contract:

SELECT address
FROM
  bigquery-public-data.crypto_ethereum.contracts
WHERE
  '0xf68deb93' IN UNNEST(function_sighashes)
AND
  block_timestamp > {month before post publication date}
LIMIT 10

This simplified example contains only one function signature (0xf68deb93). To find John’s contract I had to add more of them to the WHERE condition.

Yay! The query gave exactly one result. Is it the contract address I was looking for?

Verification

I used Etherscan to get more information about this address. Etherscan confirmed this is a contract address and allowed me to decompile it using a build-in online tool. The resulting code looked similar to the original code published by John. I found it!

Limitations

Function signatures are extracted from contract bytecode using heuristics. In case the contract’s bytecode doesn’t follow conventions, it may be hard or even impossible to obtain function signatures. Therefore some function signatures may not be available in the BigQuery dataset.

For more details, check out how the Ethereum dataset was built and how those heuristics work.

This is how I understand why some function signatures are not available in the dataset. If you have a more accurate explanation, please share it below.

Leave a comment

Extracting information

Let’s see what information I can get knowing the contract address.

The most important data is the Ethereum account address which interacted with the contract. I was able to found it easily in the list of the contract’s transactions on Etherscan. There was only one, therefore I could safely assume it was the address of John.

The rest is simple: when you have someone’s address you can get his entire transactions history and balance. It’s like a bank statement, but public.

Now I could contact John and tell him the exact amount of Ether he holds. His reaction was worth the time I’ve put into this task :)

If you like this story then I can send you my future articles right after publication. This is a privacy-oriented blog - there will be no spam and you can unsubscribe anytime.

Subscribe now

How to avoid being doxxed on Ethereum?

Ethereum transactions are pseudonymous, which means the user performing them is private as long as his address (pseudonym) can’t be linked to his real identity. John runs a blog, therefore his identity is public. Smart contract source code is also public and linked to the blog. Therefore anyone who is able to perform the steps I described above, could deanonymize him.

If you want to deploy a contract which source code is public and associated with you, here are some ideas to make connecting your real identity with your main Ethereum address harder:

• obfuscate source code before deployment (example obfuscator) - this makes finding the smart contract more difficult,

• separate contract deployment from contract usage: deploy contract from address specially generated for this purpose and don’t use it for anything else - others could see who created the contract, but won’t be able to easily connect this information with your transactions (which in most cases reveal your financial situation), especially if you follow next advice,

• if the contract is meant to be used by other people - don’t be first to use it, wait for others to transact - hide in a crowd; break up a transaction into many smaller ones and execute them at irregular intervals from many different, unrelated accounts, preferable with different transaction history; this method is similar to techniques employed by anonymity mixers such as Tornado.cash,

• make sure all addresses you use (for deployment and transactions) are anonymously funded and not linked to your main account.

  I plan to write dedicated article about maintaining anonymity on Ethereum blockchain. I will link it here. Subscribe to get it right after publication.

  Subscribe now

Final word

Thank you for reading this little deanonymization story, I hope you enjoyed it :)

In case you would like to add something, have a question, or found an error, please comment down below.

Privacy is important. If you think this article will be useful to others, please spread the word.

Share

2011-01-18 update

I received information that the vulnerability had already been known earlier, in July 2008. The issue was discovered by Józef and described in this forum thread.

2011-01-12 update

On January 12, 2011, Freeconet's management issued an official statement regarding the vulnerability described in this article.

Freeconet statement

64.3KB ∙ PDF file

Download

Download

The platform owners reacted immediately—on the day the article was published, the “Add external operator” feature was disabled.

Introduction

Freeconet is a VoIP platform that offers a range of internet telephony services to its users.
At the end of September 2010, I discovered a vulnerability that allows an attacker to intercept calls from Freeconet users to numbers chosen by the attacker.
The attacker has full control over the calls: they can terminate, record, join, and manipulate them in any way.
To demonstrate some of the possible attacks, I created the VOIPROX tool (see below).

Immediately after discovering the vulnerability, I passed detailed information to the platform’s owner.
Unfortunately, despite assurances from Freeconet, the vulnerability was not removed.
That’s why I’ve decided to publish full details about the issue.
I believe in the magic of Full Disclosure—the vulnerability will be eliminated, and Freeconet users will soon be safe.

However, after the fix, the platform’s owner should be urged to investigate whether such abuse has already occurred.
If so, the affected individuals—as well as law enforcement agencies, if necessary—should be notified.
To ensure the credibility of such an investigation, it should be conducted by an external, trusted body, e.g., the Urząd Komunikacji Elektronicznej.

This matter is also important to me personally, as I use this otherwise innovative and probably the most technologically advanced VoIP platform in Poland.

The vulnerability

The platform allows you to assign additional phone numbers to a VoIP account—numbers from external, non-Freeconet operators.
The idea is to increase user convenience while reducing call costs.

Let’s assume users A and B are registered on Freeconet.
User A also has a number from a traditional operator and can associate it with their account.
If user B dials that number, the platform sets up an internal network connection, so the call is free.
If the number wasn’t registered, the platform would use traditional telephony, which would result in charges for user B.

Note: It’s user A’s VoIP terminal that rings, not the phone connected to the traditional landline.
This issue is typically solved by using a hybrid gateway or a VoIP phone that can handle both IP and traditional line connections.
That way, a single device handles both types of calls.

The external operator definition feature is available in the Freeconet control panel under Configuration » Operators » External.
Clicking “Add external operator” opens a form where the number and area code are entered in separate fields.
Clicking “Add” links the number to the account—provided the number format is correct and it’s not already linked to another account.

There might be other validation checks, but it’s clear a crucial one is missing: verifying the user’s right to the entered number.
An attacker can enter any number—not owned by them.
From then on, all calls to that number are no longer routed to the actual owner—they go directly to the attacker!

Scope of the threat

Freeconet has between several thousand and several hundred thousand subscribers, depending on the source.

I believe the vulnerability has existed since Freeconet launched in September 2006.
So, for over four years, users have been vulnerable to attacks like those described below.

Attack scenarios

Denial of Service (DoS)

The simplest attack type.
The attacker doesn’t answer calls, hangs up, or simulates a busy line.
This effectively blocks access to the targeted number.

Eavesdropping

As a call is initiated, the attacker starts a parallel call to the same number using traditional telephony (via or outside of Freeconet).
Once the recipient answers, the attacker connects the audio streams of both calls and records them.

The attack is harder to detect if the attacker hides their number or (more difficultly) spoofs the caller’s number.
This way, the callee won’t notice that the call came from a different number.

The attacker can then use fragments of the recorded call to construct misleading or self-serving statements—for example, to carry out the next attack.

Call modification

This builds upon the eavesdropping attack.
The attacker can manipulate the call in real-time—altering pitch, adding echo, or even injecting their own speech.
More advanced versions may target interactive phone systems (IVRs), such as banking lines.

For example, after the victim passes authentication via phone, the attacker disconnects them and continues the call impersonating the user.

How to protect yourself?

Until the vulnerability is fixed, users can protect themselves by changing call routing rules to avoid internal Freeconet calls.
This will increase call costs for calls to other Freeconet users but ensures your calls aren't intercepted.

To do this, go to Configuration » Calling » Routing and set external routing rules for all calls.

VOIPROX tool

To demonstrate the vulnerability, I created a tool called VOIPROX (from VoIP proxy—or, for fun, VoIP rocks!).

The tool logs into two SIP accounts—an input and an output one. It works similarly to a proxy. Incoming calls to the number(s) assigned to the input account (hereafter referred to as intercepted numbers) are received and forwarded to the real recipient via the output account. The incoming call is only answered once the person being called picks up. This prevents a suspicious pause that could alert the caller.

Each intercepted call is automatically saved to a separate WAV file. While the call is ongoing, the user can interact with it in real time via a simple console.

VOIPROX was written in Python. I chose this language because the VoIP library I selected is only available for C and Python.

VOIPROX was written and tested on Linux. However, I see no reason it wouldn't work on other operating systems supported by Python and PJSIP.

To test the tool conveniently, you'll need a separate VoIP terminal, gateway, or softphone (e.g., the web softphone provided by Freeconet). Note: the softphone must run on a different machine than VOIPROX. VOIPROX requires access to a sound card (even if it doesn’t use it) and cannot share it with other software.

Dependencies

Install all dependencies needed to compile PJSIP. You can find detailed instructions here. Pay special attention to the ALSA libraries. If they are not detected, VOIPROX will not support local audio.

Download the PJSIP library (I tested version 1.8.10):

$ wget http://www.pjsip.org/release/1.8.10/pjproject-1.8.10.tar.bz2

Unpack the archive and compile the library without installing it:

$ tar jxf pjproject-1.8.10.tar.bz2
$ cd pjproject-1.8.10
$ ./configure
$ make dep
$ make

Install Python and the necessary packages to compile extensions. You can find all the required information here.

Compile and install the PJSIP extension for Python:

$ cd pjsip-apps/src/python
$ sudo make

Check installation:

$ python -c 'import pjsua' && echo 'OK'

VoIP accounts

You will need three SIP accounts:

• Input account: Receives calls to one or more intercepted numbers.

• Output account: Used by VOIPROX to make calls to actual recipients.

• Test account: Used for testing. If you already have a Freeconet account, you can skip creating this one.

Although in theory, the output account can be registered with any VoIP provider, VOIPROX currently supports only Freeconet accounts. You can create all accounts using the Freeconet registration form.

Assign a phone number, provide your details, email, and login for each account. You can use the same email for all. To distinguish accounts, include the type in the login (e.g., -in, -out, -test).

Account configuration

Log in using the credentials sent to your email and configure:

• Output account:

  • Top up your balance: Payments » Top Up.

  • Deactivate Freeconet internal calls (see "How to Protect Yourself").

  • Optionally, hide caller ID: Configuration » Users » Your user » Presentation » Hide.

• Input account:

  • Configuration » Operators » External » Add external operator.

  • Enter the number to intercept and click Add. For mobile numbers, provide the first three digits (area code) without the leading zero in the first field and the rest in the second.

  • Note: The number must not be from Freeconet.

  • Do not use popular numbers (e.g., company hotlines), as intercepting random calls can have legal consequences. Use your own landline or mobile number.

• Test account:

  • If you already have a Freeconet VoIP phone, use it for testing and skip ahead.

  • Otherwise, after logging in, use the web client under "Call from Website". Try dialing 901 (for free account status info) or Freeconet’s support at 801 009 500.

  • If calls don’t work, try another SIP client. Configuration info is in the email from Freeconet.

  • Do not make test calls from the same machine running VOIPROX. Use a separate VoIP device or run a softphone on another computer.

Launching the program

Download VOIPROX:

$ git clone https://github.com/pepawel/voiprox.git
$ cd voiprox

Start VOIPROX with SIP credentials:

$ ./voiprox input_login:password1 output_login:password2

A short sound confirms correct sound card communication.

If issues occur, run with -v for verbose mode.

First test

Make a call from the test account (on a different device) to the intercepted number set in the input account. The test call is free for the test account but will charge the output account.

After the call, a .wav file will appear in the VOIPROX directory. Congrats—you’ve just intercepted your first phone call. ;-)

Further capabilities

VOIPROX has an interactive console. Type help for commands:

>> help
Possible commands:
  list, show       - show all active connections
  disconnect [[caller|callee] [from]] connection
    - disconnect caller or calee from connection given by
      connection id; if caller/callee not given entire
      connection is terminated
  attach [mic|speaker] [to] connection
    - attach local microphone or speaker to given connection;
      if mic/speaker keyword not given both will be attached
  detach [mic|speaker] [from] connection - analogical to attach
  play file.wav [to] connection
                   - play wav file (no spaces allowed in file name)
  help             - show this help
  quit, exit or ^D - terminate all active connections and quit

Call and don’t hang up. Use the list command to see active calls:

>> list
1: 123456789 > 0987654321

Attach mic/speaker:

>> attach to 1

Detach mic to listen only:

>> detach mic from 1

Disconnect the caller to impersonate:

>> attach mic to 1
>> disconnect caller from 1

Play a WAV file:

>> play test.wav to 1

Enjoy—and play nice!

Disclaimer

VOIPROX is a proof-of-concept tool. It may contain bugs. I’ve tested intercepting two calls simultaneously, but not more. Tested on Ubuntu 9.10.

All calls during development were initiated by me and used only for testing.

Use VOIPROX at your own risk. Do not break the law. Freeconet logs all connections—logs may be used as evidence in court.

I hope bad actors won’t use this tool. Public release should pressure Freeconet to patch the flaw quickly, denying criminals time to abuse it. Anyone already secretly exploiting it will lose that opportunity.

Summary

TP Internet DSL, based on ADSL technology, is a service from Telekomunikacja Polska (TP) mainly targeted at businesses. The DSL modem management system contains a serious security flaw. In this post, I will explain how I discovered the flaw, what risks it involves, and propose countermeasures.

Background

It all started when my DSL modem broke. I had been using TP’s DSL Internet Access service for a while and was mostly satisfied. The connection was provided by a Siemens Speedstream 5660 ADSL modem. The modem worked well, though it occasionally suffered from stability issues1. However, one thing always annoyed me: TP didn’t allow users to configure the modem themselves—it was password-protected, and neither the customer nor even the technician knew the password.

TP claimed this restriction was for security reasons2. Ironically, it actually compromised security.

Since the modem broke on a weekend, I knew I’d be waiting a while for a replacement. A friend lent me a Planet ADSL modem, and I tried configuring it manually. The DSL link connected fine, but I couldn’t get past the PPP login—I didn’t have the username or password, and TP didn’t provide this information to customers. After some persistence, a helpful technician gave me the PPP credentials, which I greatly appreciated.

During that call, I learned something interesting: by entering a special service login and password, a script would automatically configure the modem. Unfortunately, this only worked with Speedstream modems, so I had to configure everything manually.

How it works

The service login and password are a clever trick for installers. The installer resets the modem to factory settings, connects it to the DSL line, and enters the login konfiguracja@konfiguracja with the password konfiguracja. A script then completes the configuration remotely.

This setup prevents rogue installers from keeping access to modems or sharing it with customers. TP controls a centralized database of logins and passwords, allowing them to enforce strong password policies.

But as I realized, this special pair of login and password shouldn't be public—because it can be exploited. And anyone can learn them—all it takes is carefully watching the technician’s hands during modem configuration.

The experiment begins

I began to wonder whether this automation could be used to gain access to the modem.

I downloaded the modem manual from the manufacturer’s website. After studying it, I concluded that the modem is most likely configured remotely via Telnet, since it has a built-in Telnet server. If I could intercept the Telnet session, I might be able to extract some interesting information. But how? The transmission takes place over the DSL line. A DSL sniffer? It was beyond my reach.

Eventually, I came up with an idea. An attacker equipped with two DSL modems and some additional hardware can build a network like the one shown below:

The attacker configures the Planet modem to forward (NAPT) traffic coming from the Internet on administrative ports (Telnet, WWW, SNMP, FTP) to an internal host—the Speedstream modem. The Speedstream is reset to factory settings—this enables Telnet access to its configuration. The last step is to set the default route on the Speedstream so that it goes through the Planet modem.

I entered the service login and password into the Planet modem's PPP configuration, then started a sniffer on my PC...

First success

After a moment, the Planet modem establishes a connection. It receives an address from the pool of service addresses. After a short while, the attacker notices activity on the Ethernet network. The traffic comes from a provisioning server that initiates a Telnet connection to the Planet modem, which forwards it to the Speedstream modem, allowing interception of the session. After recording and analyzing the transmission, I learned, among other things, confidential information about the modem!

Type "?" at the command prompt for a list of commands.
Type "help" at the command prompt for general help.
For detailed help on a specific command, type command name
followed by a "?",  for instance, "show ?".

Command-> show

--- General Router Information
 System Mode          - Router
 System Type          - SpeedStream 5660-R:ENI
 System HW Version    - 0
 System Up Time       - 0 Days 0 Hours 22 Minutes 36 Seconds
 Software Version     - 2.3.0(8) Jan 13 2003 09:29:38
 Factory MAC Address  - 00:11:22:33:44:55
 DSL Phy Description  - Motorola 850 SAR Alcatel/RT Adapter
 DSL Phy Version      - 
 DSL Interface State  - Down
 Host Name            - SpeedStream
 Domain Name          - domain.invalid
 IP Gateway           - 10.0.0.2
 Ethernet Interface   - 10.0.0.1/255.0.0.0
 DSL Interface        - /
 RIP Mode             - Disabled
 DNS Server           - Enabled
 DHCP Server          - Enabled
 NAPT Mode            - Enabled
 IP Filter Mode       - Disabled

Command-> set pppauth xxxxxxxx@internetdsl xxxxxxxx
Command-> set napt disable
Command-> set ethip x.x.x.x x.x.x.x

Implement IP changes now? default: n [y,n] n

Changes will not take effect until modem is rebooted!

Command-> set snmpcfg xxxxxxxx a a a 10.10.10.10 10.10.10.10
Command-> set password
Setting user password:

New password : ********
New password : ********

Password updated
Command-> reboot

Are you sure? default: n [y,n] y

System rebooting as requested!!!!

The provisioning script connects, displays the modem’s data (using the show command), and sets configuration parameters, passwords, and the IP address. Finally, it reboots the modem so the new configuration can be loaded. As a side effect of the reboot, even if the attacker had initiated an administrative session (via Telnet or serial console using the factory password) before the script started configuring the modem, that session would be terminated by the reboot. If the reboot didn’t occur, the attacker would remain connected and could retrieve the newly set passwords.3

For a moment, I wondered why the script ran the show command, but the answer quickly became clear: this is how the script identifies the modem to assign it the correct configuration. The only piece of data likely to differ between modems is the MAC address…

The masquerade

I wrote and ran a simple Perl script. The script, when hooked up to inetd on port 23, emulates the behavior of the modem’s Telnet server after a factory reset. I set up a network similar to the previous one, but without the Speedstream modem, since it’s no longer needed.

To check whether it’s possible to obtain passwords for any modem, I configured the script to display the MAC address of another existing device.

Indeed, the provisioning script connected to my script and handed over the configuration data of a different modem!

I could repeat this experiment successfully using the MAC address of a modem from another city. To obtain confidential configuration data for any modem in Poland, all you need is its MAC address!

Packet filter

I gained Telnet access to modems to which I had physical access. However, an attempt to log in to a modem in another city failed. Connections to the Telnet port were hanging—there was no response from the remote modem. Meanwhile, TCP connections to other ports were actively rejected (the modem sent a TCP packet with the RST flag set). This was a clear sign of packet filtering.

Using the tcptraceroute tool, I determined where the packets were being filtered. It turned out the filtering was done by the DSLAM located just before the remote modem. A DSLAM (DSL Access Multiplexer) is a central hub to which many DSL modems are connected. It provides connectivity between the modems and the external network. In the case of TP, these are most likely Lucent’s Stinger devices.

The packet filters and “firewalls” in the operating systems of such devices usually have little in common with professional solutions (like Cisco PIX, GNU/Linux, or *BSD systems). Instead, they function more like add-ons that “sort of work.”

Based on this assumption, one can try to bypass the DSLAM’s blocking rules. Simple packet filters may, by default, allow all fragmented packets through. I needed to structure the connection attempt to the modem so that at least the initial connection packet is fragmented. For this, I used the fragroute tool. It turns out a small patch was necessary because the program doesn’t fragment packets with the SYN flag set, which are precisely the packets that need to be fragmented.

Filter bypassed!

The filter allowed the fragmented packets through, and the attacker gained remote access to the modem.

Another method of bypassing the filter is IP spoofing. For the attack to succeed, one would need to find an inactive IP address that’s on the DSLAM’s list of “trusted” addresses. These IPs should be searched for “near” the IP address of the server running the modem configuration script.

If such a trusted, inactive IP were found, the attack—despite the obvious challenge of performing it without feedback—would be relatively simple because, according to Nmap, the modem’s ISN (Initial Sequence Number) generator is predictable:

Starting nmap x ( http://www.insecure.org/nmap/ ) at xxxx-xx-xx xx:xx CEST
Host x (x.x.x.x) appears to be up ... good.
Initiating SYN Stealth Scan against x (x.x.x.x) at xx:xx
Adding open port 1723/tcp
Adding open port 21/tcp
Adding open port 80/tcp
Adding open port 23/tcp
The SYN Stealth Scan took 6 seconds to scan 1659 ports.
For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled
Interesting ports on x (x.x.x.x):
(The 1655 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
21/tcp   open  ftp
23/tcp   open  telnet
80/tcp   open  http
1723/tcp open  pptp
Device type: firewall|switch|WAP
Running: SonicWall embedded, Enterasys embedded, Cisco embedded
OS details: SonicWall SOHO firewall, Enterasys Matrix E1, or Accelerated Networks VoDSL, or Cisco 360 Access Point
TCP Sequence Prediction: Class=64K rule
                         Difficulty=1 (Trivial joke)
IPID Sequence Generation: Incremental

Nmap run completed -- 1 IP address (1 host up) scanned in 12.380 seconds

What’s next?

Full access to the modem gives a malicious actor significant capabilities.

In the simplest case, the attacker could disconnect the subscriber from the Internet by disabling the LAN interface; they could change the modem’s access password, preventing TP technicians from reaching the device; or they could attempt to break into the subscriber’s internal network, which until now was protected by the modem’s NAT.

There is an officially undocumented SET PRIV command that provides full access to the operating system (VxWorks). Full system access gives the attacker virtually unlimited possibilities—they could upload and run any program on the modem. Such a program could turn the modem into a so-called “zombie” used in DDoS attacks; it could allow the attacker to eavesdrop on traffic and perform man-in-the-middle (MitM) attacks. Finally, the program could reprogram the modem’s FLASH memory to the point that it stops functioning entirely and would require service reprogramming.

The described threats become more serious when one considers the number of modems in use in Poland.4

The problem of obtaining MAC addresses

To gain control over a modem, one must know its MAC address. It wasn’t possible to obtain this address based on the IP of the Speedstream 5660 modem.

After analyzing a transmission dump between the script and the modem using p0f, it turned out that the server running the configuration script most likely operates under Solaris 8.

p0f - passive os fingerprinting utility, version 2.0.2
(C) M. Zalewski <lcamtuf@coredump.cx>, W. Stearns <wstearns@pobox.com>
p0f: listening (SYN) on 'filtered.dump', 193 sigs (9 generic), rule: 'all'.
80.50.248.71:14396 - Solaris 8 (1) (NAT!) 
  -> 10.0.0.1:23 (distance 8, link: unknown-1472)
[+] End of input file.

If an attacker were able to gain control of this server, they would also have access to the MAC address database (and most likely passwords and other confidential data as well).

The server is protected by a firewall that likely performs packet defragmentation, so the previous trick with packet fragmentation wouldn’t work here. I did not attempt direct intrusion, but I tested the provisioning script by feeding it incorrect input. It proved to be resistant—at least to the inputs it was tested with.

While testing the buffer capacity of the remote side, it became clear what kind of firewall was in use. When my program sent a large amount of data, the script on the other side disconnected and closed the connection. The firewall interpreted this as a terminated connection, while my program kept sending data. As a result, the packets sent by the program were reset—but in a very specific way. The RST packets weren’t empty—they contained a payload that was a copy of the packet being reset. This is a known bug in Cisco PIX.

With other methods blocked, brute-forcing MAC addresses was the remaining option. Of course, it’s not necessary to scan the entire MAC address space. While there are 2⁴⁸ possible MAC addresses, which might sound discouraging, the first three bytes are identical for all the modems. Additionally, the first half of the fourth byte is often the same. That narrows it down to 2²⁸ = 268,435,456 possibilities.

It’s reasonable to assume that TP purchased modems in batches. Devices from the same batch have almost identical MAC addresses. If the attacker “hits” one valid MAC address, finding others from the same batch becomes easy.

During testing, I observed that TP’s script has timeouts for modem configuration. If the modem doesn’t respond within a certain time, the script disconnects and reconnects—this cycle can repeat multiple times. This behavior can be exploited to speed up password collection.

With enough time, it would be possible to create a password-harvesting program that intelligently scans MAC addresses and extracts passwords from the database at a rate of one every few seconds—provided it “hits” a valid series. The wait time could be longer if the MAC address is a miss, but likely no more than 2–3 minutes.

New modems

After identifying and initially describing the vulnerability, it turned out that, in addition to the Speedstream 5660 modems, TP was also providing subscribers with newer modems—devices from the same manufacturer, but marked with the model number 5100.

Like the 5660, the Speedstream 5100 also features a web interface for managing and monitoring the modem. However, unlike the 5660, which protects the entire interface with a password, the 5100 allows users to monitor the modem's status without authentication. This allows subscribers to diagnose connection issues without needing full access.

The main page of the web interface also includes basic information about the device. From an attacker’s perspective, the key piece of information is… the MAC address.

The problem of obtaining MAC addresses—solved

This is a major convenience for an attacker. Knowing the IP address of a remote modem is enough to connect to the modem’s homepage (again using fragmented packets) and retrieve its MAC address.

An attacker, using a tool to scan all IP ranges assigned to TP and looking specifically for 5100 modems (which are easy to identify remotely), could very quickly collect the MAC addresses of all such modems in Poland. Needless to say, all of the previously described threats also apply to these devices.

Default password

An attempt to retrieve authentication data for the 5100 using the spoofing script failed. The provisioning script disconnected, just as it does when it receives an invalid response from the modem. It’s likely because the CLI interface was different.

To adapt the spoofing script to “work” with the 5100, I recreated the test setup—this time using the newer modem. Analysis of the captured transmission provided the necessary details and revealed an amusing fact: to prevent subscribers from tampering with the configuration, the factory password had been changed. This means even someone with the modem's manual—including the default password—cannot gain access to the device after a factory reset.

Unfortunately, by analyzing the transmission between the script and the modem, an attacker can easily learn this password.

Countermeasures

It's difficult for me to suggest what actions TP could take to secure the DSL system as I’m certainly unaware of all its features and the requirements it must meet. I also don't know the system's internal architecture or the capabilities of the devices that comprise it. Still, I will briefly discuss some simple remedies that wouldn't require major changes to the system design.

The most reliable solution would be to abandon automatic modem configuration entirely. However, I realize this could increase the cost of installing new modems and maintaining existing ones.

If the packet filters on DSLAMs allow it, a simple measure could be to block fragmented packets. However, this would serve only as a temporary fix, as it doesn’t prevent credential theft from the central database nor stop the use of those credentials when the attacker has physical access to the modem.

A more balanced solution might be to limit automatic modem provisioning to a few trusted locations—for example, one in each major city. In those locations, technicians would configure the modems before installing them at customer premises.