Pwning through antispams

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”.

The information reported by Shodan.

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

The web interface of the Barracuda antispam.


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.

Default credentials are always hard to discover.

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.

The domain administrator’s credentials. Ouch.

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.

Sometimes, testing is fun. And profitable.

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.

I will pay a couple of beers to anyone who could explain me the goal of this feature.

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.

Practical routing attacks (3/3): BGP

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-meme

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-scenario

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:

UPDATE:

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