heartbleed_cupid

Heartbleed, Cupid and Wireless

Since my presentation on cupid has gotten quite a bit of attention, I feel it’s necessary to provide a bit more context about this issue and what it is exactly. I’ve received some questions and I’ll try to post all the answers here.

 

What is cupid?

cupid is the name I gave to two source patches that can be applied to the programs “hostapd” and “wpa_supplicant” on Linux. These patches modify the programs behavior to exploit the heartbleed flaw on TLS connections that happen on certain types of password protected wireless networks.

hostapd is a program that sets up a configurable Access Point on Linux, so it is possible to create almost any kind of Wireless Network configuration and let clients connect to it.

wpa_supplicant is a program used to connect to wireless networks on Linux and also on Android.

Interesting side note: both hostapd and wpa_supplicant were written by the same author and share a lot of code, so the patches are very similar.

 

How does the attack work?

This is basically the same attack as heartbleed, based on a malicious heartbeat packet. Like the original attack which happens on regular TLS connections over TCP, both clients and servers can be exploited and memory can be read off processes on both ends of the connection.

The difference in this scenario is that the TLS connection is being made over EAP, which is an authentication framework/mechanism used in Wireless networks. It’s also used in other situations, including wired networks that use 802.1x Network Authentication and peer to peer connections.

EAP is just a framework used on several authentication mechanisms. The ones that are interesting in this context are: EAP-PEAP, EAP-TLS and EAP-TTLS, which are the ones that use TLS.

To exploit vulnerable clients, hostapd (with the cupid patch) can be used to setup an “evil” network such that, when the vulnerable client tries to connect and requests a TLS connection, hostapd will send malicious heartbeat requests, triggering the vulnerability.

To exploit vulnerable servers we can use wpa_supplicant with the cupid patch. We request a connection to a vulnerable network and then send a heartbeat request right after the TLS connection is made.

I saw a misconception on a lot of sources regarding heartbeat and it is a common question that I get: It’s not necessary to fully establish a TLS connection to perform the heartbleed attack. No actual keys or certificates need to be exchanged.

I have found it to be possible to send and receive heartbeat responses right after a “Client Hello” message (before certificates are presented or session keys are exchanged).

 

Do I need to provide a valid user/password to exploit this vulnerability?

In short, no. The vulnerability is triggered before a valid password needs to be presented. Sometimes in order to exploit a vulnerable server you must present a valid username (not password), as the specific EAP mechanism may request a valid username/realm to redirect the user to the proper authentication server.  But this can be easily sniffed off the air when a regular user tries to connect.

 

How to spot vulnerable systems:

You basically use cupid to trigger the vulnerability and look for a behaviour consistent with heartbleed on a packet sniffer.

The following image shows wpa_supplicant_cupid exploiting a vulnerable network:

heartbleed_cupid_img1

 

First we provide a username (EAP Identity), then we will create a TLS connection over EAP to authenticate (using EAP-PEAP). Note that cupid sends heartbeat requests right after “Client Hello”, there’s no need to perform the full TLS handshake. Up to 64kb of memory can be read for each heartbeat request.

 

The second image shows hostapd_cupid exploiting a vulnerable client in the same fashion:

heartbleed_cupid_img2

 

Note that, in this case, we didn’t even send a “Server Hello” message. The vulnerable client requested a TLS connection, sent a “Client Hello”, and we proceeded to send an heartbeat request. The client is happy to respond, leaking up to 64kb of process memory.

 

What is present on the memory that can be read?

Not enough testing was made to go into such detail, so we can only speculate. Most of the memory is zeroed out, but cursory inspection found interesting stuff on both vulnerable clients and servers. I can speculate that most likely the private key of the certificate used on the TLS connection is in memory. What can also be in memory is the user credentials used for authenticating the connection.

 

What software is affected?

Note that I’ve done very limited testing on this. I have confirmed however that on Ubuntu, if you are using a vulnerable version of OpenSSL the default installations of wpa_supplicant, hostapd, and freeradius can be exploited.

Android 4.1.0 and 4.1.1 use a vulnerable version OpenSSL. Also, all versions of Android use wpa_supplicant to connect to wireless networks, so I have to assume that these are probably vulnerable.

Regarding vulnerable clients:

If you have an Android device running 4.1.0 or 4.1.1 you should avoid connecting to unknown wireless networks unless you upgrade your ROM.

If you have a Linux system/device you’re using to connect to wireless networks you should make sure to upgrade your OpenSSL libraries, so if you followed heartbleed mitigation recommendations you should be fine.

 

Regarding vulnerable servers:

If you have an home router you are probably safe from this specific attack vector. This is because most home routers use a single key for Wireless Security (a pre-shared key), and do not use EAP authentication mechanisms.

 

If you have a corporate wireless solution on your company you should look at this problem, since most of the managed wireless solutions use EAP based authentication mechanisms. And some companies use OpenSSL. You should look at having your equipment tested or contacting your vendor and ask for more information.

You should also look at this issue if you have any type of EAP authentication mechanism on your corporate network. Note that 802.1x Network Access Controlled wired networks might also suffer from this problem.

You can contact us at SysValue if you need assistance on testing your corporate network regarding this issue.

 

Conclusion:

I hope this comprehensively addresses all the questions you have about cupid. I’ve put the source code online so that you can test more networks and devices. Please let me know of the results of your testing so I can update this post with the types of devices and configurations that are affected / not affect by this issue.

 

References:

Article written by Luis Grangeia

sysblog

Firewalling (1/5)

About this article

With the fast growing of the Infrastructure as a Service (IaaS) concept, usage and applicability, fueled by the cost-effectiveness demands and high-availability requirements of modern services provided in the cloud, more and more Platform as a Service (PaaS) and Software as a Service (SaaS) providers rush to find the most state of the art, performant and cost-effective IaaS provider to host the very engine of their online businesses.

These demands and the diversity of the requirements of small to medium-scale implementations, may lead to a single PaaS or SaaS provider to host its infrastructure in multiple IaaS providers, directly increasing the complexity, heterogeneity and/or disparity, either logical, virtual or physical, of the design of their globalized infrastructure.

While many IaaS providers already provide multiple services for integrated Firewalling, VPN, QoS, Caching, Load-Balancing, vRacks etc., when an infrastructure is based on a multi-vendor approach, a clean and low cost integration may be difficult to achieve.

This article will be focused on the Firewalling elements of a multi-vendor IaaS infrastructure by addressing ways to implements robust firewalls with simple low-cost solutions already available on the Open-Source Community. One of such solutions is the FWBuilder by Netcitadel, Inc. being it the one that will be referenced to build a hipotetical firewall throughout the main sections of this article.

Structure

This article is structured in five main Sections and five Annexes, enumerated below:

— Section I – Setting up the Skeleton

— Section II – Populating the Policies

— Section III – Deploying the Firewall Objects

— Section IV – Taking Advantage of Traffic Accounting

— Section V – Managing all nodes at once

— Annex I – Compiled Script for Skeleton

— Annex II – Deployment Scripts

— Annex III – SSH and DSA keys

— Annex IV – Monitoring Scripts

— Annex V – VPN: The first wall of defense

Assumptions

The contents of the following sections assume that the reader as some knownledge regarding Infrastructure and Networking design. Altough this article tends to be easy to understand for any professional in the IT business, an average understanding of the two elements pointed above will greatly enhance the experience and, hopefully, learning of the reader.

Base Environment

A minimalistic, hypothetical infrastructure will be described here in order to allow us to design a possible firewalling solution for such scenario. The infrastructure will be formed by two major platform components, being them a simple Webserver Cluster and a simple DBMS Cluster, each consisting of two nodes for core service delivery and another two nodes for High-Availability and Load-Balancing layers:

Webserver Cluster:

* 2 x HAProxy

* 2 x Apache Webserver

Database Cluster:

* 2 x MySQL Proxy

* 2 x MySQL Servers

As we’re assuming a multi-vendor infrastructure, the diverse network nodes are also assumed to be geographically distant, whose IP network addresses will uncontinous, or, in other words, not prone to be configurable in the same subnet. A theoretical addressing scheme, with interface specification, will be also used as described below:

* webclu-proxy-node-01

: eth0 IPv4 : 11.12.13.14 /24

: eth0 IPv6 : 1001:2001:3001:4001::1 /64

: gateway : 11.12.13.1

* webclu-proxy-node-02

: eth0 IPv4 : 20.21.22.23 /24

: eth0 IPv6 : 2001:3001:4001:5001::1 /64

: gateway : 20.21.22.1

* webclu-http-node-01

: eth0 IPv4 : 30.31.32.33 /24

: eth0 IPv6 : 3001:4001:5001:6001::1 /64

: gateway : 30.31.32.1

* webclu-http-node-02

: eth0 IPv4 : 40.41.42.43 /24

: eth0 IPv6 : 4001:5001:6001:7001::1 /64

: gateway : 40.41.42.1

* dbmsclu-proxy-node-01

: eth0 IPv4 : 50.51.52.53 /24

: eth0 IPv6 : 5001:6001:7001:8001::1 /64

: gateway : 50.51.52.1

* dbmsclu-proxy-node-02

: eth0 IPv4 : 60.61.62.63 /24

: eth0 IPv6 : 6001:7001:8001:9001::1 /64

: gateway : 60.61.62.1

* dbmsclu-mysql-node-01

: eth0 IPv4 : 70.71.72.73 /24

: eth0 IPv6 : 7001:8001:9001:1001::1 /64

: gateway : 70.71.72.1

* dbmsclu-mysql-node-02

: eth0 IPv4 : 80.81.82.83 /24

: eth0 IPv6 : 8001:9001:1001:1101::1 /64

: gateway : 80.81.82.1

Section I – Setting up the skeleton

This introductory section, aims to explain the fundamental concepts for proper usage of the FWBuilder interface, from installation of the application itself, to the deployment of the firewall into the configured target nodes.

Each sub-section will address a very specific component of the application and the importance of its role when designing long-term, manageable, firewalls. A few illustrations will be added on each sub-section when a clear idea of the interface is intended to be passed to the reader.

1.1. The FWBuilder

The FWBuilder is an Open-Source project being developed and improved by the Netcitadel, Inc. for more than a decade. It is a Graphical User Interface (GUI) firewall management application, serving as an abstraction layer for many firewall solutions on the market, including iptables, PF, Cisco ASA, Cisco PIX, Cisco FWSM and many more.

It’s centralized and scalable design, allows the management of literally hundreds of firewalls from a single, simple and dependable User Interface (UI).

The combined experience of its developers, sum more than 30 years of hands-on experience in networking and security technologies.

This turns the FWBuilder one of the most used and recommended Open-Source projects regarding firewall manangement.

1.2. Installing the FWBuilder

The FWBuilder can be downloaded from the http://www.fwbuilder.org. Along with an extremely well documented product, the support community around the project grants the users a reliable source of information to solve any issues that may occur.

It can be installed on 3 major Operating Systems (OS): GNU/Linux based, Windows and Mac OS X.

This article will guide the reader through an installation of the FWBuilder in a GNU/Linux OS, more specifically, the Debian 7 OS.

From the command line, enter the following command as superuser:

# apt-get install fwbuilder

This will install the FWBuilder and all it’s dependencies. As soon as the package manager finishes the installation of the newly requested packages, the FWBuilder will be ready to use.

To load the FWBuilder application, execute the following command:

$ fwbuilder

This will load the GUI, which will be explained in the next section.

1.3. User Interface – First Contact

The user will find the UI of the FWbuilder very familiar. It’s a typical and intuitive firewall GUI that allows an easy creation and deployment of firewalls, allowing a true centralized management. When the GUI is loaded, the following window will show:

front

In order to create a new firewall, the “Create new firewall” button should be pressed and the following dialog will show:

create

Here, the “NewFirewall” is set as the name of the firewall object. As we’re creating a firewall object for each of the nodes described in the environment section of this article, this name should be changed to one of the nodes, for example, “webclu-proxy-node-01”.

The initial setup for creating new FWBuilder firewall objects is completed in three simple steps:

The first step is shown above, where the user should set the firewall object name, the target software for which it should be compiled, and the target operating system where the firewall will run.

The second step is shown after clicking the “Next” button, diplaying the following dialog:

create_next

This will allow the user to choose the configuration method for the network interfaces of the target system. In order to cover the the manual interface configuration of the GUI and assuming the target node doesn’t have a SNMP server, we’ll opt to “Configure interfaces manually” by clicking “Next”:

create_next_next

On this dialog, it’s possible to configure the interfaces for the target node by clicking the ‘+’ button and entering the interface settings. If multiple interfaces exist, one can keep pressing the ‘+’ button in order to configure a new network interface for this node. As the interface configuration will be covered through the left context of the GUI interface, one can skip this dialog by clicking the “Finish” button. This will result in the following window to be displayed:

main_window

1.4. Base Firewall Object Structure

As the firewall rules may drastically increase over time for a single firewall object, a good practice to keep the simplicity of the object management is to create an initial base structure of well identified “Policy Rule Sets” (PRS) to allow a fast identification of the traffic processed through them. TheBased on this concept, we’ll create the following PSRs:

– Accounting

– Blacklist

– Default

– Inbound

– Outbound

To create a new PRS, right-click on the firewall object (in this case, the “webclu-proxy-node-01”) and left-click the “New Policy Rule Set” option. To change the PRS name, double-click the newly created PSR named “Policy_1” and change the “Name” field, located at the left-bottom corner of the displayed window. After changing it to “Accounting”, the user should have a similar content as diplayed in the following image:

new_policy

Repeat the steps to create the remaining suggested PSRs, except for “Default”, as this will not require the creation of a new PRS, since the “Policy” PRS can be renamed.

After all the PRSes are created, we’ll need to ‘route’ the traffic to each of the PSRs. This can be acomplished by making use of the “Default” PRS, by inserting “Branch” action rules:

— Configuring Outbound PRS:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Insert New Rule”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Outbound PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Outbound”.

— Configuring Inbound PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Bottom”.

– Right-click on Rule #1 Action column and select “Branch”.

– Drag and Drop the Inbound PRS into the “Policy ruleset object” field.

– Right-click on Rule #1 Direction and select “Inbound”.

— Configuring Blacklist PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Top”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Blacklist PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Both”.

— Configuring Accounting PSR:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Top”.

– Right-click on Rule #0 Action column and select “Branch”.

– Drag and Drop the Accounting PRS into the “Policy ruleset object” field.

– Right-click on Rule #0 Direction and select “Both”.

— Configuring a Clean-up rule:

– Double-click the “Default” PRS.

– Right-click on the rules dialog and select “Add New Rule at the Bottom”.

– Right-click on Rule #4 Action column and select “Deny”.

– Right-click on Rule #4 Direction and select “Both”.

The following image illustrates the current configuration:

init_structure

At this moment, any packets entering a specific “Branch” will not be allowed leave unless a “Continue” target is set at the bottom of each branch. In order to do so, the following procedures should be performed:

— Double-click the “Branch”.

— Right-click on the rules dialog and select “Insert New Rule” or “Add New Rule at the Bottom”.

— Right-click on Rule Action column and select “Continue”.

branch_continue

This rule must always be the last on each branch. Failing to do so, will cause any other rule below it to be ignored.

1.5. Configuring Interfaces

Once we skipped the network interface configuration on the previous sub-sections, these procedures will be addressed here. All the procedures here described can be replicated to create other devices in other firewall objects, as well as multiple interfaces on these same objects.

By creating interfaces in the firewall object, the FWbuilder will automatically enforce that configuration when deployed in the target firewall node. This usually is a great advantage, but the user should confirm twice any new or changed configuration, in order to grant that no incorrect settings that could stop the interface from running are present. If that happens, the remote node will stop responding from the misconfigured interface.

To create an interface on a firewall object, proceed as described below:

— Right-click on firewall object “webclu-proxy-node-01”.

— Click “New Interface”.

— Double-click on “Interface”.

— Change the name field to eth0.

— Right-click on “eth0” of the firewall object.

— Click “New Address”.

— Double-click the “webclu-proxy-node-01:eth0:ip” object.

— Change the “Address” field to: 11.12.13.14

— Change the “Netmask” field to: 255.255.255.0

— Right-click on “eth0” of the firewall object.

— Click “New Address IPv6”.

— Double-click the “webclu-proxy-node-01:eth0:ipv6” object.

— Change the “Address” field to: 1001:2001:3001:4001::1

— Change the “Netmask” field to: 64

The following image represent the current interface configuration for the IPv4 address:

interface_ipv4

The following image represent the current interface configuration for the IPv6 address:

interface_ipv6

1.6. Creating Objects

As the images presented in the previous sub-sections show, there’s a “Objects” category on the left dialog of the FWBuilder GUI. This folder contains a set of sub-categories that allow the user to create other types of objects other than firewall nodes and respective dependencies.

For now, we’ll be focused in the “Addresses” sub-category of the “Objects” main category. We’ll rely on this category to create the gateway addresses for each firewall node in order to allow us to configure the Routing table of the firewall (described in the next sub-section).

To create an Address object, go to the left upper corner of the GUI, expand the Objects category and proceed as follows:

— Right-click the “Addresses” category.

— Select “New Address”.

— Change the “Name” field contents to “webclu-proxy-node-01:gw”.

— Change the “Address” field contents to “11.12.13.1”.

address

The image above illustrates the newly created address. The user may now create all the remaining gateway addresses by repeating the specified steps for address creation.

1.7. Setting up the Routing Table

The FWBuilder also supports the configuration and maintenance of the routing table for the target nodes. This is specially useful from the point of view of centralized management for network devices or critical exposed systems.

Altough useful, it still is a dangerous configuration element that must be handled with extremelly care, as a wrong configuration entry may prevent the target node from being able to communicate out of its broadcast domain.

When used, the user must grant that all required routing table entries are configured for that particular firewall object, as the compiled configuration to be deployed, generated by FWBuilder, will replace any current configurations running on that node with the ones defined in the routing Routing Policy.

We’ll only address the default gateway entry for each firewall object referenced in this document. The user must configure any other required Routing entry and ensure that it contains all the required data in order to avoid the node from being unreachable.

The process to configure the default gateway entry in the “Routing” policy is described below:

— Double-click the “Routing” policy entry of the current firewall object.

— Right-click on the “Routing” policy rules panel.

— Select “Insert New Rule”.

— Drag the “webclu-proxy-node-01:gw” Address Object into the “Gateway” field of the Rule #0.

— Drag the “eth0” Interface Object into the “Interface” field of the Rule #0.

— Leave or grant that the “Destination” field of the Rule #0 is set to “Default”.

The following image demonstrates the result of the configuration steps described above:

routing

1.8. Compiling and Testing the Skeleton

We’re now able to compile and test the skeleton for the “webclu-proxy-node-01” firewall object. Since this skeleton isn’t allowing any inbound or outbound traffic yet, our test will be simply a compilation test in order to grant that everything is fine at this stage. The resulting script should not be installed and executed in the target node, as this will cause it to be unreachable.

To compile the skeleton, go to the FWBuilder tool bar and click on the Compile icon. This will open the following dialog:

compile_skeleton

By clicking the “Next” button, the compilation process will start. If everything is correctly configured, no errors nor warnings will occur. If the compilation process detects any errors or warnings, please review all the steps from the beggining of this document in order to fix any issues that may exist. After the compilation process is complete, the following dialog will show:

compile_skeleton_finish

The user may click on the “Inspect generated files” button to further analyze the resulting script and grant that everything is correctly generated. A copy of the resulting script from the current configuration can be found on Annex I – Compiled Script for Skeleton.

By clicking “Finish”, the dialog will close and the user will return to the main GUI window.

1.9. Section Final Thoughts

Thoughout this section, we’ve analyzed and/or reviewed some of the most important configuation elements of the FWBuilder. The user should now be familiarized with the GUI and have a clear “big picture” of the overall GUI functionalities.

The next sections will focus on creating the firewall rules for each of the hypothetical nodes described in the beggining of this document, as well as the steps for automated installation of the generated firewalls.

A final section (Section IV) will address some important aspects of the “Accounting” PRS, which will allow the integration of those results with a monitoring system.

Annex I – Compiled Script for Skeleton

annex1_firewalling

Autor: Pedro Hortas @ SysValue

sysblog

Análise de malware em resposta a incidentes de segurança (3/3) – Análise de malware

Este é o terceiro e último de uma série de 3 posts sobre análise de malware e o seu papel na resposta a incidentes de segurança. Depois da identificação dos ficheiros descrita no post anterior, neste artigo é apresentada sumariamente a metodologia que poderá ser seguida para a análise do malware, mais concretamente do seu comportamento e capacidades.

A análise de malware tem dois grandes objectivos. A identificação do tipo de ameaça e dos seus objectivos e a recolha de informação que permita uma resposta eficiente, bloqueando o ataque e controlando os danos já sofridos. Por exemplo, indicadores que permitam detectar a presença do malware num sistema, indicadores que permitam detectar actividade do malware na rede e  tácticas de remoção do malware e de resposta ao incidente que deverão ser aplicadas.

Esta análise pode ser efectuada com níveis de profundidade que vão desde uma análise automatizada com recurso a sandboxes à engenharia reversa e análise pormenorizada do código Assembly, pelo que é necessário algum pragmatismo na selecção da metodologia para que seja identificado o máximo de informação sem que se perca demasiado tempo com detalhes de pouca utilidade prática.

A forma mais eficiente de fazer a análise e um bom primeiro passo de análise é o recurso a malware sandboxes que permitem executar o malware num ambiente controlado, monitorizando as suas acções e produzindo um relatório de forma automatizada.

Estas ferramentas permitem tirar conclusões rápidas sobre as capacidades e o funcionamento do malware. No entanto, têm diversas limitações (e.g. Detecção por parte do malware, utilização de criptografia, condições específicas de execução do malware) e muitas vezes não oferecem a flexibilidade necessária para chegar às conclusões pretendidas.

Assim, após análise inicial em sandbox, quando a informação produzida não é suficiente, é realizada uma análise estática manual dos ficheiros. Esta análise consiste na análise dos binários do malware, de forma a inferir sobre o seu comportamento. Para o fazer são realizadas operações tais como a identificação de strings presentes no ficheiro ou a análise das bibliotecas importadas. Este processo nem sempre é directo, uma vez que o malware recorre muitas vezes a técnicas que impedem a análise dos binários, sendo por isso necessário algum pré-processamento para unpacking dos binários antes da análise.

Em seguida, é normalmente realizada uma análise dinâmica, que consiste na execução do malware num ambiente controlado e especialmente preparado para o efeito. Este tipo de análise vai para além da análise efectuada por sandboxes automatizadas, já que é possível a simulação de comportamentos do utilizador mais completos para levar o malware a realizar operações adicionais e a configuração do sistema para a análise específica do malware em questão. Por exemplo, poderá ser fornecido ao malware informação que este está programado para roubar tais como credenciais ou documentos e analisar o seu comportamento nessas situações.

Por fim, quando as metodologias de análise simples não são suficientes para a obtenção da informação pretendida, poderá ser necessária a realização de engenharia reversa do malware com recurso a disassemblers e debuggers de forma a compreender a fundo o comportamento do malware. Este é um procedimento moroso e que exige conhecimentos muito especializados, pelo que na grande maioria dos casos não é levado a cabo.

Uma vez finalizada a análise, deverá ter sido gerada diversa informação util, tal como:

  • Modo de infecção (e.g. Emails ou sites visitados);
  • Vulnerabilidades exploradas para a infecção;
  • Indicadores de infecção para a pesquisa de hosts infectados;
  • Indicadores de rede para pesquisa de hosts infectados através da análise de tráfego de rede e criação de regras IDS;
  • Medidas a tomar para parar de imediato a comunicação com os servidores de comando e controlo;
  • Amostras de malware para envio a fabricantes de antivírus;
  • Informação útil sobre a ameaça, para programas de awareness e comunicação de tentativas de fraude a clientes e colaboradores;

Esta informação poderá então ser utilizada para uma resposta adequada e eficiente ao incidente, recuperando o controlo dos sistemas e tendo a capacidade de responder às questões sobre qual o incidente e o seu impacto real.

Autor: Tiago Pereira @ SysValue