Forem: Thiago Macedo

SSL Pinning Exposed: Can the Web Save Us?

Thiago Macedo — Sun, 21 Jan 2024 07:26:14 +0000

Data security in mobile applications today depends on SSL pinning - and it has loopholes. Would it be possible to re-elect the web as safer? That's what I tried.

Sometime ago I received a video that exposed weaknesses in SSL Pinning, the technology that ensures data communication in mobile applications. I had already worked on apps that use the technique - as well as having tried to break it before - so I thought it would be interesting to investigate.

This data transmission security solution consists of establishing an SSL certificate together with the application build - for exclusive client-server communication through this key. As the build embeds its own set of certificates, it protects itself from attacks on the Certificate Store of the client's operating system, for example.

Along with its popularity, the technique has been receiving attention from cyber defense authorities as it has weaknesses that allow apps to be tampered with bad keys. Through reverse engineering, it is possible to tamper a build with malicious keys and thus expose the client to impersonalization attacks.

Web or Mobile? The safe choice

After investigating the structure of these attacks, I realized that the web environment had the potential to be more resilient to tampering.

Mobile applications are delivered directly to the client host, thus being exposed to the fate of the OS and device itself. At the other end, let's say a PWA Web application, its release is restricted to the browser context only.

However, to reach the level of security that pinning proposes, a web release would need to contain at least two characteristics:

allowing the validation of original certificates;
being resilient to the tampering of this information.

SSL pinout: Authority is what counts

I started the research with SSL Pinning. Conceptually, the idea is great: linking the frontend application to an exclusive set of certificates. But in practice, the approach creates problems as it exposes the certificates in the build, being subject to reverse engineering, and tampering, among others.

Would there then be something similar in the browser? The answer is yes.

In 2013, Google created a mechanism to help defend against attacks on the CA Store, called Certificate Transparency. This is an internet standard in which digital authorities must publish public logs with all their issued certificates. This way, the client browser itself can decide whether a given domain has such a certificate, or whether it is fake.

The approach has been gaining ground and since 2018 Google Chrome has required that all certificates be available in a public log.

Tamparing the application

The pinned release can have its certificates patched if the client is exposed. The attacker can also change the frontend to call his domains and impersonate the whole API.

As the web application does not pin the certificate - but rather authenticates it in the global transparency repository - there is no risk of certificate tampering.

Unfortunately browsers, as a rule, do not encrypt the cache, leaving it up to the user to protect themselves with storage encryption solutions. Therefore the attacker, in possession of the host, can manipulate the application cache and its version as well. However, the multiple security layers on the browser (like CORS) will likely make the tampering impractical.

Obscurantist solution: the hack against reverse engineering

A simple and reasonably effective solution is to employ techniques to make it difficult to manipulate compromising information: in this case, URLs in javascript builds or SSL keys embedded in the mobile release.

Code Obfuscation is the means of deliberately creating code that is difficult to read and reverse engineering. There are automatic solutions, but manual care is necessary if the intention is to protect yourself from more skilled attackers.

Another technology being developed is the in-memory validation of code hashes. This approach, promising against tampering, consists of validating at runtime whether the method has been modified, preventing the program from continuing in the event of tampering.

Connecting the dots

Certificate Transparency seems to me to be an important advance and could be incorporated into other environments in the future.

Unfortunately, mobile application frameworks do not evolve with the same cohesion and timing as the W3C or Google Chrome, leaving the promising solution resident of just a few use cases.

How to recover LTC sent by mistake to a BTC wallet

Thiago Macedo — Sun, 21 Jan 2024 06:13:42 +0000

Bitcoin and Litecoin are technically very similar cryptocurrencies, with Litecoin being a fork of Bitcoin created in 2011.

Their wallet addresses are also technically the same. If you have created a BTC wallet and have its key, you are the owner of the same LTC address and can open it with your existing BTC keys.

Given the average user experience in crypto-currency interfaces is improving yet due to their inherent complexity, one can accidentally transfer an X amount of LTC to a BTC address. Well, at least I did.

This post will describe how I have discovered that my LTC tokens could be recovered even if I had transferred them to the wrong address - in this case a known BTC address.

Networks do not communicate

The fact is: that sending LTC to a BTC address does not make the coins never leave the original network. Litecoins sent by mistake are always and only in the LTC network. In this case, as we used a Bitcoin address, the transfer was validated because it is the same format and this address is also valid on the LTC network.

So where is the LTC? On the Litecoin network, at the address provided. And how to recover litecoins? If the person has control of the BTC wallet, they can recover the tokens.

The wallets are similar

A Bitcoin wallet is nothing more than private keys (the keys that are used to sign a transaction) and recovery seeds. Litecoin works exactly the same, including the multisig wallet.

Therefore, the wallet recovery procedure starts in the Bitcoin wallet. And you will learn about the blueprint of the operation below.

Wallets contain keys, not coins

To recap: we send LTC to a “BTC” address. We have already discussed that the coins did not end up on the BTC network, however, the destination address is inviolable and we cannot undo the transaction.

The solution here, paradoxically, lies in the BTC wallet. Once we have this wallet with the destination address, we can retrieve the same address on the LTC network.

In practice, as the networks are similar, a BTC address has parity in the LTC network, and we can take control of both networks with the Private Key or recovery seeds.

Recovering the wallet on the LTC network

To take control of the address on the LTC network we need the private keys of the BTC wallet. Each wallet has a procedure, but there are basically three possibilities:

The wallet allows you to export private keys;
The wallet is non-encrypted and you can access the private key in the wallet files;
The wallet is encrypted and we will need to recreate this wallet.

Look for the first two options and if you have access to the private key, skip the next step.

Decrypting a crypto wallet

If the wallet is encrypted you can still recover it. We can recreate it without encryption. Of course, for this, you need to have the seed phrase. Recovery keys must always be stored, as they are the only way to open the black box of a crypto wallet.

Create a BTC wallet;
The new wallet must be a redemption from the seed phrase;
The new wallet must be non-encrypted.

With the wallet decrypted, we can open the wallet file and access the private keys — which takes us to the next step. It would also be possible to generate the private-key with the seed phrase and the https://iancoleman.io/bip39/ tool.

Taking control of LTC address with BTC private keys

Once you have the private keys for the LTC address that received the tokens, you must start creating the LTC wallet using the private keys.

Create an LTC wallet;
The new wallet must have the same signers number (if it is multisig);
The new wallet must be a restoration from the private keys.

The LTC wallets that I recommend for the process are:

Multisig address: core wallet
segwit address: electrum wallet

Once you have the wallet, just redirect the coins to a definitive LTC address. But if you have sent the coins to an address you don't have the keys you won't be able to recover them unless you know the owners.

Instrumentation for Laravel: visualize operational data and performance metrics

Thiago Macedo — Thu, 07 Nov 2019 00:32:33 +0000

Offloading tasks for background processing is such a great resource in software engineering. And a good job queue does the job of abstracting this complex setup in a safe and maintainable way.

But as the number of jobs and data grows around the queue, we might wonder how much information we have about what is going on in the queue workers.

What instrumentation can answer

How many jobs ran last hour?
What were the lengthiest tasks during that period of time?
When did that job stop processing?
What's the job run rate (how many per hour) and what's its average, max and minimum run times?

Those questions will introduce themselves especially during performance incidents, system malfunctions, data loss, etc - so imagine how useful it is to have an informed dataset about the system health.

Horizon: mileage may vary

For the Laravel Queue there is the good Horizon Dashboard, which is free and readily integrates to redis queues. But if you need customized dashboards or to smash data in order to answers more questions then custom instrumentation comes handy.

Determining what to instrument

For in-house instrumentation where we consume the data ourselves I've been targeting to gather initially:

name of the procedure (the Job class name in this case)
time spent processing
procedure params
caught exception description

There is a tendency to log out as much information as possible. For optimal instrumentation, don't do that. Include in the instrumentation payload only what's most relevant for the system operation.

Ingestion and data analysis

Instrumentation data will be really useful only with log ingestion and visualization tools. There are many projects out there in the market, such as the open-source Elastic Stack (logstash + kibana) and the paid service LogDNA.

Laravel Queue Instrumentation: a implementation

Over the past year, I've solved lots of performance and data loss situations with a similar approach. Above I'm sharing a gist with a sample Laravel Queue instrumentation.

How about your experience, have you ever instrumented system runtime? What tools and process do your team makes use?