microlab.red

Encryption keys & algorithms, directory servers and channels

References:

• https://spec.torproject.org/
• https://spec.torproject.org/tor-spec/negotiating-channels.html
• https://spec.torproject.org/cert-spec.html

Other articles on the topic:

• Introduction and general Tor concepts
• Encryption keys & algorithms, directory servers and channels (this one)

Disclaimer 1:

While I did my best to be as accurate as possible, the topic is complex and I am really good at doing mistakes. If you notice anything wrong, please reach out. Moreover, I skipped some details to keep the content concise; so please, use the references above to deepen your knowledge.

Disclaimer 2:

I could be wrong, but I think that the Tor documentation contains some error in the naming of the keys. In particular, the public and private keys seem swapped in multiple places (you are not supposed to use a public key to generate a signature). Take your time and investigate deeper, if needed.

In the previous article I did my best to provide an introduction to the main concepts of the Tor network. What follows is an overview of the various encryption keys in use, how relays can be contacted and how channels are established.

Generating keys is free. Encryption algorithms are free too. So let’s use plenty of them.

Important note before starting: in the following paragraph, if the name of an asymmetric key starts with "kp", I am speaking about a public key, while if the name starts with "ks", it is a private key. Moreover, inside the round brackets you can find the name of the keys as defined inside the Tor official documentation.

To function, a Tor relay needs the following key pairs:

• Identity keys;
• Online keys;
• Circuit extension keys (a.k.a. onion keys);
• Link keys.

Identity Keys (kp_relayid_ed / ks_relayid_ed – kp_relayid_rsa / ks_relayid_rsa)

This is an Ed25519 key pair that is used to uniquely identify the relay inside the Tor network. They never expire and are never regenerated. If they change, the identity of the relay changes too. If it happens, the relay becomes brand new for the Tor network.

Having long-lasting, critically important keys poses a problem: if they are compromised, the impact is huge. For this reason, the private identity key is kept offline and used only when strictly necessary.

A 1024 bit RSA key pair is also generated, even if its existence is for legacy purposes. Whenever a signature generated by the identity key must be verified, the following process applies:

• if the signature generated by the RSA key cannot be verified, the process stops;
• if the signature generated by the RSA key can be verified, the process continues and the signature generated by the EC key is also verified;
• for the signature verification to be completed successfully, both signatures must be verified.

Online keys (kp_relaysign_ed / ks_relaysign_ed)

This is also an Ed22519 key pair. It is used to sign all the other keys, or when other key pairs cannot be used. They are signed by ks_relayid_ed and their sole purpose is to allow the private identity keys to remain offline for most of the time.

This key pair is used to sign:

• the server descriptor sent to the directory servers;
• the other keys pairs.

Circuit extension keys (kp_ktor / ks_ktor – kp_onion_tap / ks_onion_tap)

Each relay has one or more circuit extension keys (also called onion keys), which last on the order of weeks and whose purpose is the creation or the extension of a circuit, to perform a one-way authenticated key exchange.

The *_ktor key pair is based on Curve25519 and is used for the ntor and ntorv3 circuit extension handshakes, while the *_onion_tap RSA 1024 key pair is used for the legacy tap circuit extension handshake.

Link keys (kp_link_ed / ks_link_ed)

During the channel negotiation handshake between relays, these short-term keys are used for the link authentication. These keys are signed by the ks_relaysign_ed key and are regenerated frequently.

Ephemeral keys. Non-ephemeral security.

The asymmetric keys above have two goals: authenticating relays and sharing ephemeral keys securely. This second goal is achieved with a brilliant key exchange protocol called Diffie-Hellman, in our case based on elliptic curves.

This key exchange allows the relays to share ephemeral, symmetric keys that are used for that specific session and that are never used again. Which is cool but… why bothering?

These keys provide two advantages:

• they guarantee the forward secrecy
  • if the current session key is compromised by an attacker, no session can be decrypted/recovered other than the current one;
  • if the long term keys are compromised, no session can be decrypted recovered without the associated session keys.
• symmetric algorithms do provide better performances.

Certify identities without certification authorities. The directory servers.

On Internet, the Certification Authorities (CA) are the ones in charge of authenticating entities (services, companies, people, etc…) by signing the entity’s certificate with the CA private key. Any other entity receiving this signed certificate can use the CA public key (that is well known and normally embedded in the OS/browser) to verify the entity’s identity.

On Tor, there is no CA. How can be relays authenticated? The process is not that straightforward.

First of all, any relay generates what is called a server descriptor, that is a text document whose content is defined in the directory protocol. Broadly speaking, it contains:

• kp_relayid_ed;
• kp_relayid_rsa;
• kp_relaysign_ed;
• kp_ktor;
• the IP address of the relay;
• additional information, like contact points, TCP ports in use, policies, etc…;
• the signature of all the above information.

The list of the server descriptors is downloaded at the first start by the client/relay and is updated when needed. This is all is needed for contacting a relay and establishing a channel.

One important detail: the addresses of the directory servers are fixed and provided together with the Tor application. In theory, a user could change them, but this would completely undermine the client security and it does not make any sense at all (in common usage scenarios).

Establishing channels.

In the following paragraphs, I will use the term “initiator” to indicate both a client a relay initiating a connection. If there is any difference between the two, this will be explicitly explained. The term “responder” indicates the endpoint to which the channel is being established. Those are the terms used by the Tor documentation.

As you may recall from the first article, you can think of a channel as a pipe between a client and a relay or between two relays. A set of channels connecting a client with the exit node or with the destination onion service is called a circuit.

Now, how are those channels established?

From outside, a channel is nothing more than a TLS session. If compared against a normal TLS session, the ones established by Tor have two important differences: there is no CA to be used to validate the exchanged certificates and the communication inside the TLS session is encapsulated in additional layers of encryption.

The first check against the responder’s identity is done by checking if the certificate sent during the establishment of the TLS session is signed with the responder’s ks_relayid_ed private key.

Once the session has been established, this is used by Tor to exchange multiple cells (the messages exchanged by parties in Tor), leveraged by the link protocol to create a real Tor channel.

The first cell is the CERTS cell sent by the responder. It describes the keys that the Tor instance is claiming to have, and provides certificates to authenticate that those keys belong to it.

The responder’s CERTS cell has two certificates inside. They contain the following keys, respectively:

• the kp_relaysign_ed, signed with the ks_relayid_ed;
• a TLS certificate, signed with the ks_relaysign_ed.

If the two certificates can be verified by the initiator using the certificates it has (the kp_relayid_ed from the directory servers and the kp_relaysign_ed from the CERTS cell), the identity of the responder is considered verified.

If the initiator is a relay (e.g.: between the first and the second hop during the creation of a circuit), the responder sends an AUTH_CHALLENGE cell, to which the initiator must respond with a CERTS cell and an AUTHENTICATE cell. The initiator is not authenticated until both the cells are received by the responder.

The initiator’s CERTS cell is identical to the one sent by the responder, but the key inside the signed TLS certificate is deemed to be the public link key, i.e. kp_link_ed. Of course, it is signed with the ks_relaysign_ed of the initiator.

From the responder’s AUTH_CHALLENGE cell, the initiator extracts a challenge (a set of randomly generated bytes) and an authentication method, that currently can only be Ed25519-SHA256-RFC5705.

For authenticating itself, the initiator uses the private link key, i.e. ks_link_ed, to generate a signature over the challenge; it than puts this signature, together with other stuffs (check the official documentation for the details), inside an AUTHENTICATE cell and sends it to the responder. If the responder successfully verifies the content of this second cell, the channel is considered established.

To be honest, one last cell is exchanged, called NETINFO cell, but I will possibly cover it in a future article. It does not use any encryption key, so I skip it for now.

Introduction and general Tor concepts

References:

• https://spec.torproject.org/ .

Other articles on the topic:

• Introduction and general Tor concepts (this one)
• Encryption keys & algorithms, directory servers and channels

Disclaimer:

While I did my best to be as accurate as possible, the topic is complex and I am really good at doing mistakes. If you notice anything wrong, please reach out. Moreover, I skipped some details to keep the content concise; so please, use the references above to deepen your knowledge.

Tor is the implementation of The Onion Routing protocol.

What follows is the first of a series of articles trying to explain how Tor works with only one goal: save you the hours I spent understanding all of this.

Disclaimer: I did my best to study and verify everything in details. But I do mistake and the topic is quite complex. If you find anything wrong, please let me know in the comments.

Is ChatGPT sleep deprived?

Sleep deprivation, if put to the extreme, leads inevitably to alucination. Hence, we can conclude that ChatGPT must be sleep deprived because most of the times I tried to ask it something about Tor, it get confused or provided plain wrong answers.

TL;DR: once again, don’t blindly trust GenAI whatsoever, especially when dealing with less known, deep technical topics.

Tor 101

Tor is an overlay network.

It is composed by thousands (~ 6-11k) relays, connected through channels that form circuits inside which cells are sent and received.

A relay is a host running an instance of the Tor daemon/service configured to make it a relay. If you install Tor on a host, that host does not automatically become a relay. It must be configured that way.

From a networking point of view, channels are nothing more than TLS sessions connecting hosts around the world. It is how these sessions are instantiated and what is communicated within that is different from a normal connection.

When a client access Tor, it selects a set of relays (three, by default) that will be connected as a chain, one after the other. The path from the client to the last relay is called a circuit.

Both the internal messages exchanged between the relays (and also with the client) and the actual traffic generated by the client is encapsulated inside fixed length messages, called cells.

Onions and layers

Tor, like onions, cakes and ogres, have layers. Plenty of layers.

Tor communications are wrapped inside layers of encryptions. Basically, it takes one piece of information and uses different keys and algorithms one after the other to allow only the correct recipient to be able to access that information.

Every moment needs it own encryption algorithm

Tor uses symmetric and asymmetric cryptography, hashing and key exchange algorithms (like Diffie-Hellman) to do its job, depending on what it is being done in the moment.

You know nothing about cryptography?

Cryptography is hard and complex, but don’t be intimidated. Luckily, smart women and mens in the last 100 years spent plenty of energy in engineering strong algorithms and correct ways to deal with most of the situations we daily face.

So, you don’t need to invent anything. Just understand how things work.

I am not good enough to explain these concepts here, but I suggest you my preferred technical book of all time:

“Serious Cryptography: A Practical Introduction to Modern Encryption”

written by Jean-Philippe Aumasson (ISBN-13: 978-1593278267).

Buy the book and study it in details. Believe me, it is worth the effort.

The current state of an ever changing network

Relays appear and disappear from the network, but for them to be useful they must be reachable and selectable by clients and other relays as well.

A relay generates a server descriptor containing all the information about the relay, like its IP address, some of its public keys, the flags it uses (e.g., if it can be used to reach Internet or not) and so on.

This document is then signed with the private identity key of the relay itself and sent to a set (5-10) ok semi-trusted server that are called directory servers.

Those directory servers keep receiving the service descriptor of the nodes. They then “vote” the state of the network, which means that they decide tor a new version of the directory, a “document” containing the last, agreed-upon-those-servers state of the whole network, i.e. the states of the relays composing the network.

Inside the official Tor Browser (and official Tor installers in general), a list of the directory servers is provided. It is possible for a user to change them, but this undermines the trust one can have in that client/relay.

This list is used by clients and relays to download the updated version of the directory, which in turn provides the most updated state of the whole network.

Whenever a client wants to access the Tor network, it selects a set of nodes (three by default) which act as entry/guard node, middle node and exit node.

A diamond is forever. An entry node lasts months.

The first node contacted by the client is called entry node or guard node.

As said, the client selects the nodes it wants to use in advance but, at the first run, it chooses three entry nodes it is going to use for the next few months.

It behaves this way to make some attacks more difficult to carry out.

Brefly, the idea is that if the same client keeps changing the entry nodes, sooner or later it will use some relays that are malicious. If the entry nodes are almost always the same, this condition should almost never occur.

Counterintuitive, uh?

Entry nodes are flagged as such due to their reliability and availability inside the network.

What is left: the middle node and the exit node.

Once the client establishes a channel with the guard node, it then uses that node to reach the second node, called middle node. This is achieved by extending the circuit, i.e. by instantiating a new channel between the first and the second node that can be used by the client to reach the latter.

The exit node is reached in the same way, by extending the circuit from the middle node.

The owner of the exit node can decide some exit policies, that are shared inside the directory and that allows the client to know when a specific relay is the right one to use. For example, exit policies can be used to define which protocol is allows to exit and which it not.

One important detail that is used by Tor to make correlation attacks harder to mount is the need for the guard node and the exit node to reside to a different /16 network.

Once the circuit is established, the client can then reach Internet and visit the services he/she/it wants to reach.

What is next?

The next article is focused on understanding some of the cryptography that Tor uses to achieve its goals. This will prove useful for the the future articles on the topic.

Introduction

One of the activity provided by Microlab is what is called “zero-knowledge penetration test”, where the target is the whole customer infrastructure and the only information given before starting is the name of the company.

The goal is to mimic, as much as possible, a real attack scenario where the first part is dedicated to information gathering and to the discovery of the low hanging fruit, i.e. the weakest target to attack. This provides the customer with an overview of the publicly available resources and how they can be abused by a threat actor.

During this kind of activities, it has been possible to get complete control of the customer network by leveraging antispam systems. How? Just keep reading.

Attack surface

The first phase of a penetration test is normally dedicated to gathering as much information as possible about the target, regardless of its nature: it could be an application, a device, a whole network, a company. It really does not matter: you have to know what you are going to attack.

While doing a zero-knowledge pentest for one of my customer, let’s call it Acme Inc., I started by passively mapping (i.e.: without direct interaction) the attack surface, that in this case was composed by all the systems and the applications owned by Acme Inc. that were directly reachable from Internet.

After mapping quite deeply this surface and after checking with the customer that all of the discovered targets were under its whole control, I moved to Shodan to get an idea of the exposed services and applications. One of the reachable system was fingerprinted as “Barracuda Network Spam Firewall”.

This has been confirmed by visiting the web interface exposed on port 443/TCP.

Default creds should burn in hell

Guess what? The first thing I did was to jump to Google and search “barracuda email security gatewat default login”, get admin/admin as result and acquire access to the system, because those default credentials were still valid.

There are multiple attacks that a threat actor could carry out after getting access to this kind of systems:

• get an almost complete list of the email addresses of the company;
• get access to the emails waiting to be delivered;
• allow malicious emails to be delivered to the mailboxes;
• copy / forward emails to a third party address (this is very stealthy);
• get insights of the private network(s) behind the antispam;
• get Domain Admin credentials;
• get instant access to the network behind the antispam.

Wait. Everything is clear but, “Domain Admin credentials”? “Instant access to the network behind the antispam”? No way.

Retrieve the credentials

One of the feature that is present in almost any enterprise antispam solution is the ability to connect to a Microsoft Active Directory to get the list of the users and to allow them to authenticate on the system with their domain’s credential. Unluckily, more often then not, domain privileged accounts are used to allow the antispam to access the Active Directory. In this case, my customer used the domain administrator’s account for this task.

Thanks to some limitations in the web interface imposed by Barracuda, it is not possible to directly recover the credentials. This can be achieved with a simple trick, by changing the “LDAP Server” address to a system under your control and by selecting “OpenLDAP” as “LDAP Server Type”. Then through the “Test LDAP” button the antispam will connect to your system and will deliver the plaintext credentials to you.

Be careful though, because you have to setup an SSL/TLS connection between the antispam and your fake OpenLDAP server; if not, you are going to expose the credentials to anyone listening to the traffic between the two hosts.

Port forward & antispam

In case the customer is using a read-only, limited domain account to retrieve information from the Active Directory, there is another feature an attacker could leverage: port forwarding.

While I still have to find a scenario where it is ok to have the antispam managing port forwarding (this is normally in charge to the firewall), it seems that this is a feature made available by different producers. For sure, Barracuda is one of them.

An attacker could configure multiple port forwarding rules to use the antispam as an hop to the internal network. Moreover, it is the perfect way to create a backdoor for example for a malicious employee who is leaving the company, thanks to the fact this feature is quite hidden into the menus and because it is normally not expected (at least for me) to have an antispam who is capable to do this kind of stuffs.

Conclusions

I do not know why but from my experience it is quite common to find antispam systems running with default credentials.

If you are a pentester, it makes sense to spent some time to test for default login or to try to break into the system with weak passwords associated to the local administrator account.

If you are a network administrator who is running an antispam, double check the configuration and, in any case, never use domain administrator’s credentials on these kind of stuffs. Less is more. Lol.

Introduction

This is the last article about practical routing attacks, after the one against RIPv2 and the one having OSPF as target. Today, we are going to see how an attacker could leverage the BGP protocol on his or her own advantage.

Based on the fact that this topic has been widely covered on great articles online, this one will be nothing more than an introduction; I will let some references in the last section.

Routing theory: precedence

Whenever a router needs to decide where a specific packet has to be forwarded, it has to evaluate its routing table, containing the association between subnets and the gateways that have to be used to reach them.

While in theory subnets never overlap, in practice this is not always the case.

Let’s imagine that we are a router with the following routing table:

• current subnet is 192.168.254.0/24
• subnet A is 192.168.0.0/24, reachable through GW-A 192.168.254.100
• subnet B is 192.168.1.0/24, reachable through GW-B 192.168.254.101
• subnet C is 192.168.2.0/24, reachable through GW-C 192.168.254.102

What happen if a new routing entry is added, defining subnet B1 as 192.168.1.128/25, with GW-B1 192.168.254.200? Basically, the more specific a subnet is, the higher its priority when a packet has to be routed.

Before inserting the entry B1, every host between 192.168.1.1 and 192.168.1.254 is reachable through GW-B; after inserting the more specific route, every host between 192.168.1.1 and 192.168.1.127 is still reachable through GW-B, while every host between 192.168.1.129 and 192.168.1.254 is now assumed to be reachable through GW-B1.

This is not a big deal, unless someone could inject arbitrary, more specific routes inside routers around the world. And yes, this is something that could happen when using BGP.

BGP: the theory

BGP stands for Border Gateway Protocol, that is the gateway protocol that actually runs the whole Internet (it is normally used as exterior gateway protocol, but can be also used as an interior gateway protocol, whenever it is used inside an AS). It is defined, in details, inside different RFCs:

• RFC 4271 defines BGP version 4, that is the one in use today;
• RFC 4760 describes how BGP have been extended in order to be able to deal with protocols different from IPv4, such as IPv6, IPX, etc… (for this reason, the title of the RFC is “Multiprotocol Extensions for BGP-4”).

While the protocol is quite complex, we are more or less only interested in how routers exchange information. Basically, it is only a matter of trust: routers accept new announcements from the peers defined in their configuration, without nearly any check against the content of the announcement.

A weak form of protection for those messages can be applied by using a shared secret between the peers, that is used for cryptographically sign the messages, using an MD5 hash; unluckily, as explained in the previous article, this hashing function is badly broken.

This is only one of the most straightforward BGP vulnerability to understand and exploit, but there are plenty of them. As a proof of this, there is also an RFC (RFC 4272) describing various vulnerabilities and various attack scenarios. Ehm.

BGP: attack analysis

Based on the fact that BGP runs more or less the whole Internet, an attacker could potentially generate huge damages with “little” effort; in the past, various / attacks / proved / that / this / is / absolutely / the / case.

An attacker could in fact diverge the traffic from a specific country, having a specific subnet (or a set of subnets) as destination, gaining the possibility to carry out different attacks, such passive sniffing or Man-In-The-Middle .

There are plenty of different ways to achieve this, but the most straightforward way is to compromise a router, if and only if you are not a malicious actor legally owning the access of one or more routers. Like, you know, a nation.

BGP: exploit lab

Even in this case, the whole scenario will be simulated using GNS3, with Cisco based firmware emulated inside it. What follows is a screenshot of a possible scenario, using known ISP to identify different AS (the name are randomly selected, as the associated AS number); I just decided to use ISP names because ISPs are an example of entities managing an AS.

BGP: exploit impact

Being able to inject malicious routes is always bad, but it is even worst if this affects the traffic of a whole country or company. Unluckily, while such attacks could lead to huge security problems for the users having their traffic redirected, they are hard to stop, due to weaknesses in the protocol specification.

While there are different companies providing monitor of the BGP routes announced around the world, every user and every company can do their part, by using (or providing), secure protocols, such as the one protected by TLS (e.g.: HTTPS). Unluckily, as you can see in the articles linked below, sometimes this is not enough.

BGP: references

There are plenty of great articles online describing vulnerabilities, attacks and countermeasures online, such as:

• A Survey of BGP Security Issues and Solutions
• Are BGP Routers Open to Attack? An Experiment
• BGP Vulnerability Testing: Separating Fact from FUD v1.1
• Defending Against BGP Man-In-The-Middle Attacks
• Breaking HTTPS with BGP hijacking
• The state of BGP security: Internet plumbing for network security professionals
• BGP Hijinks and Hijacks – Incident Response When Your Backbone Is Your Enemy

UPDATE:

A good friend of mine reminded me also the hijack attributed in 2015 to Hacking Team:

• Hacking Team orchestrated brazen BGP hack to hijack IPs it didn’t own