From security em unicamp.br  Fri Jul  5 17:12:05 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Fri, 5 Jul 2013 20:12:05 +0000
Subject: [SECURITY-L] [US-CERT@public.govdelivery.com: TA13-088A: DNS
	Amplification Attacks]
Message-ID: <20130705201204.GB11992@unicamp.br>

----- Forwarded message from US-CERT <US-CERT em public.govdelivery.com> -----

From: "US-CERT" <US-CERT em public.govdelivery.com>
Subject: TA13-088A: DNS Amplification Attacks
To: security em unicamp.br
Date: Fri, 05 Jul 2013 14:21:48 -0500

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-088A: DNS Amplification Attacks [ https://www.us-cert.gov/ncas/alerts/TA13-088A ] 03/29/2013 02:26 PM EDT 
Original release date: March 29, 2013 | Last revised: July 05, 2013

Systems Affected

  * Domain Name System (DNS) servers 

Overview

A Domain Name Server (DNS) amplification attack is a popular form of distributed denial of service (DDoS) that relies on the use of publically accessible open recursive DNS servers to overwhelm a victim system with DNS response traffic.

Description

A Domain Name Server (DNS) amplification attack is a popular form of distributed denial of service (DDoS) that relies on the use of publically accessible open recursive DNS servers to overwhelm a victim system with DNS response traffic. The basic attack technique consists of an attacker sending a DNS name lookup request to an open recursive DNS server with the source address spoofed to be the victim???s address. When the DNS server sends the DNS record response, it is sent instead to the victim. Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. Because the size of the response is typically considerably larger than the request, the attacker is able to amplify the volume of traffic directed at the victim. By leveraging a botnet to perform additional spoofed DNS queries, an attacker can produce an overwhelming amount of traffic with little effort. Additionally, because the responses are legitimate data coming from valid servers, it is especially difficult to block these types of attacks.

While the attacks are difficult to prevent, network operators can implement several possible mitigation strategies. The primary element in the attack that is the focus of an effective long-term solution is the detection and elimination of open recursive DNS resolvers. These systems are typically legitimate DNS servers that have been improperly configured to respond to recursive queries on behalf of any system, rather than restricting recursive responses only to requests from local or authorized clients. By identifying these systems, an organization or network operator can reduce the number of potential resources that the attacker can employ in an attack.

Impact

A misconfigured Domain Name System (DNS) server can be exploited to participate in a distributed denial of service (DDoS) attack.

Solution

DETECTION

Several organizations offer free, web-based scanning tools that will search a network for vulnerable open DNS resolvers.  These tools will scan entire network ranges and list the address of any identified open resolvers.

"Open DNS Resolver Project"
http://openresolverproject.org
The Open DNS Resolver Project has compiled a list of DNS servers that are known to serve as globally accessible open resolvers.  The query interface allows network administrators to enter IP ranges in CIDR format [1].

"The Measurement Factory"
http://dns.measurement-factory.com
Like the Open DNS Resolver Project, the Measurement Factory maintains a list of Internet-accessible DNS servers and allows administrators to search for open recursive resolvers [2].  In addition, the Measurement Factory offers a free tool to directly test an individual DNS resolver to determine if it allows open recursion.  This will allow an administrator to determine if configuration changes are necessary and verify that configuration changes have been effective [3].  Finally, the site offers statistics showing the number of open resolvers detected on the various Autonomous System (AS) networks, sorted by the highest number found [4].

"DNSInspect"
http://www.dnsinspect.com
Another freely available, web-based tool for testing DNS resolvers is DNSInspect.  This tool is similar to The Measurement Factory in that it tests a specific resolver for vulnerability, but it offers the ability to test an entire DNS Zone for several other potential configuration and security issues [5].

Indicators

In a typical recursive DNS query, a client sends a query request to a local DNS server requesting the resolution of a name or the reverse resolution of an IP address.  The DNS server performs the necessary queries on behalf of the client and returns a response packet with the requested information or an error [6, page 21].  The specification does not allow for unsolicited responses.  In a DNS amplification attack, the key indicator is a query response without a matching request.  

MITIGATION

Unfortunately, due to the overwhelming traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based, distributed denial-of-service attack.  While the only effective means of eliminating this type of attack is to eliminate open recursive resolvers, this requires a large-scale effort by numerous parties.  According to the Open DNS Resolver Project, of the 27 million known DNS resolvers on the Internet, approximately ???25 million pose a significant threat??? of being used in an attack [1].  However, several possible techniques are available to reduce the overall effectiveness of such attacks to the Internet community as a whole.  Where possible, configuration links have been provided to assist administrators with making the recommended changes.  The configuration information has been limited to BIND9 and Microsoft???s DNS Server, which are two widely deployed DNS servers.  If you are running a different DNS server, please see your vendor???s documentation for configuration details.

Source IP Verification

Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victim???s system, the first step to reducing the effectiveness of DNS amplification is for Internet service providers (ISPs) to deny any DNS traffic with spoofed addresses.  The Network Working Group of the Internet Engineering Task Force released a Best Current Practice document in May 2000 that describes how an Internet service provider can filter network traffic on its network to drop packets with source addresses not reachable via the actual packet???s path [7]. The changes recommended in this document would cause a routing device to test whether it is possible to reach the source address of the packet via the interface that transmitted the packet. If it is not possible, the packet obviously has a spoofed source address. This configuration change would considerably reduce the potential for most current types of DDoS attacks.

Disabling Recursion on Authoritative Name Servers

Many of the DNS servers currently deployed on the Internet are exclusively intended to provide name resolution for a single domain.  These systems do not need to support resolution of other domains on behalf of a client, and therefore should be configured with recursion disabled.

Bind9

Add the following to the global options [8]:
options {
     allow-query-cache { none; };
     recursion no;
};

Microsoft DNS Server

In the Microsoft DNS console tool [9]:


  * Right-click the DNS server and click Properties. 
  * Click the Advanced tab. 
  * In Server options, select the ???Disable recursion??? checkbox, and then click OK. 

Limiting Recursion to Authorized Clients

For DNS servers that are deployed within an organization or ISP to support name queries on behalf of a client, the resolver should be configured to only allow queries on behalf of authorized clients.  These requests should typically only come from clients within the organization???s network address range.

BIND9

In the global options, add the following [10]:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
options {
  allow-query { corpnets; };
  allow-recursion { corpnets; };
};

Microsoft DNS Server

It is not currently possible to restrict recursive DNS requests to a specific client address range in Microsoft DNS Server.  The most effective means of approximating this functionality is to configure the internal DNS server to forward queries to an external DNS server and restrict DNS traffic in the firewall to restrict port 53 UDP traffic to the internal server and the external forwarder [11].

Response Rate Limiting (RRL) of Recursive Name Servers

There is currently an experimental feature available as a set of patches for BIND9 that allows an administrator to restrict the number of responses per second being sent from the name server [12].  This is intended to reduce the effectiveness of DNS amplification attacks by reducing the volume of traffic coming from any single resolver.

BIND9

Patches are currently available for 9.8.latest and 9.9.latest to support RRL on UNIX systems. Red Hat has made updated packages available for Red Hat Enterprise Linux 6 to provide the necessary changes in advisory RHSA-2013:0550-1. On BIND9 implementation running the RRL patches, add the following lines to the options block of the authoritative views [13]:
rate-limit {
    responses-per-second 5;
    window 5;
};

Microsoft DNS Server

This option is currently not available for Microsoft DNS Server.

"*Disclaimer:*" RRL of DNS responses may prevent legitimate hosts from receiving answers. Such hosts may be at increased risk for successful DNS cache poisoning attacks.

References

  * [1] Open DNS Resolver Project [ http://openresolverproject.org ] 
  * [2] The Measurement Factory, "List Open Resolvers on Your Network" [ http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl ] 
  * [3] The Measurement Factory, "Open Resolver Test" [ http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl ] 
  * [4] The Measurement Factory, "Open Resolvers for Each Autonomous System" [ http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html ] 
  * [5] "DNSInspect," DNSInspect.com [ http://www.dnsinspect.com ] 
  * [6] RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES [ http://tools.ietf.org/html/rfc1034 ] 
  * [7] BCP 38: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing [ http://tools.ietf.org/html/bcp38 ] 
  * [8] Chapter 3. Name Server Configuration [ http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch03.html#id2567992 ] 
  * [9] Disable recursion on the DNS server [ http://technet.microsoft.com/en-us/library/cc787602.aspx ] 
  * [10] Chapter 7. BIND 9 Security Considerations [ http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch07.html#Access_Control_Lists ] 
  * [11] Configure a DNS Server to Use Forwarders [ http://technet.microsoft.com/en-us/library/cc754941.aspx ] 
  * [12] DNS Response Rate Limiting (DNS RRL) [ http://ss.vix.su/~vixie/isc-tn-2012-1.txt ] 
  * [13] Response Rate Limiting in the Domain Name System (DNS RRL) [ http://www.redbarn.org/dns/ratelimits ] 

Revision History

  * March 29, 2013: Initial release 
  * April 18th, 2013: Minor updates to Description and Solution sections(Source IP Verification and BIND9) 
  * July 5th, 2013: Added disclaimer for DNS request rate limiting 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ] 

SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ]  |  Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.6a6fc2cec2b9952ff27f6db27530aead&destination=security em unicamp.br ]  |  Help <support em govdelivery.com>

________________________________________________________________________

This email was sent to security em unicamp.br using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]



----- End forwarded message -----


From security em unicamp.br  Wed Jul 10 11:13:35 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Wed, 10 Jul 2013 14:13:35 +0000
Subject: [SECURITY-L] US-CERT@public.govdelivery.com: TA13-190A: Microsoft
	Updates for Multiple Vulnerabilities
Message-ID: <20130710141335.GB56985@unicamp.br>

----- Forwarded message from US-CERT <US-CERT em public.govdelivery.com> -----

From: "US-CERT" <US-CERT em public.govdelivery.com>
Subject: TA13-190A: Microsoft Updates for Multiple Vulnerabilities
To: security em unicamp.br
Date: Tue, 09 Jul 2013 14:11:26 -0500

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-190A: Microsoft Updates for Multiple Vulnerabilities [ https://www.us-cert.gov/ncas/alerts/TA13-190A ] 07/09/2013 02:56 PM EDT 
Original release date: July 09, 2013

Systems Affected

  * Microsoft Windows 
  * Microsoft .NET Framework 
  * Microsoft Silverlight 
  * Microsoft Office 
  * Microsoft Visual Studio 
  * Microsoft Lync 
  * Internet Explorer 
  * Windows Defender 

Overview

Select Microsoft software products contain multiple vulnerabilities. Microsoft has released updates to address these vulnerabilities.

Description

The Microsoft Security Bulletin Summary for July 2013 [ http://technet.microsoft.com/en-us/security/bulletin/ms13-jul ] describes multiple vulnerabilities in Microsoft software. Microsoft has released updates to address these vulnerabilities.

Impact

These vulnerabilities could allow remote code execution or elevation of privilege.

Solution

*Apply Updates*

Microsoft has provided updates for these vulnerabilities in the Microsoft Security Bulletin Summary for July 2013 [ http://technet.microsoft.com/en-us/security/bulletin/ms13-jul ], which describes any known issues related to the updates. Administrators are encouraged to note these issues and test for any potentially adverse effects. In addition, administrators should consider using an automated update distribution system such as Windows Server Update Services [ http://www.us-cert.gov/redirect?url=http%3A%2F%2Ftechnet.microsoft.com%2Fen-us%2Fwsus%2Fdefault.aspx ] (WSUS). Home users are encouraged to enable automatic updates [ http://www.us-cert.gov/redirect?url=http%3A%2F%2Fwindows.microsoft.com%2Fen-us%2Fwindows-vista%2FTurn-automatic-updating-on-or-off ].

References

  * Microsoft Security Bulletin Summary for July 2013 [ http://technet.microsoft.com/en-us/security/bulletin/ms13-jul ] 
  * Microsoft Windows Server Update Services [ http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx ] 
  * Turn Automatic Updating On or Off [ http://windows.microsoft.com/en-us/windows-vista/Turn-automatic-updating-on-or-off ] 

Revision History

  * Initial Release 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ] 

SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ]  |  Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.6a6fc2cec2b9952ff27f6db27530aead&destination=security em unicamp.br ]  |  Help <support em govdelivery.com>

________________________________________________________________________

This email was sent to security em unicamp.br using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]



----- End forwarded message -----


From security em unicamp.br  Wed Jul 10 17:43:20 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Wed, 10 Jul 2013 20:43:20 +0000
Subject: [SECURITY-L] [cais@cais.rnp.br: Resumo dos Boletins de Segurana
	Microsoft - Julho/2013]
Message-ID: <20130710204320.GN56985@unicamp.br>

----- Forwarded message from Centro de Atendimento a Incidentes de Seguranca <cais em cais.rnp.br> -----

From: Centro de Atendimento a Incidentes de Seguranca <cais em cais.rnp.br>
Subject: Resumo dos Boletins de Segurança Microsoft - Julho/2013
To: pop-seg em cais.rnp.br, rnp-alerta em cais.rnp.br, rnp-seg em cais.rnp.br
Date: Wed, 10 Jul 2013 16:07:38 -0300 (BRT)

-----BEGIN PGP SIGNED MESSAGE-----

Prezados,

A Microsoft publicou 7 boletins de segurança em 9 de julho de 2013
que abordam ao todo 35 vulnerabilidades em produtos da empresa. A
exploração destas vulnerabilidades permitem execução remota de código
e elevação de privilégio.

Até o momento da publicação deste alerta não foram divulgados códigos de
exploração para as vulnerabilidades listadas.


SEVERIDADE

. Crítica

- - MS13-052 - Vulnerabilidades no .NET Framework e Silverlight podem 
             permitir a execução remota de código

- - MS13-053 - Vulnerabilidades nos drivers Kernel-Mode do Windows podem 
             permitir a execução remota de código

- - MS13-054 - Vulnerabilidades no GDI+ podem permitir a execução remota de código

- - MS13-055 - Update de segurança cumulativa para Internet Explorer

- - MS13-056 - Vulnerabilidades no Microsoft DirectShow podem permitir a 
             execução remota de código

- - MS13-057 - Vulnerabilidades no Windows Media Format Runtime podem 
             permitir a execução remota de código


. Importante

- - MS13-058 - Vulnerabilidades no Windows Defender podem permitir a 
             execução remota de código


. Moderada

- - Nenhum boletim


. Baixa

- - Nenhum boletim


O sistema de classificação de severidade das vulnerabilidades adotado
pelo CAIS neste resumo é o da própria Microsoft. O CAIS recomenda que se
aplique, minimamente, as correções para vulnerabilidades classificadas
como crítica e importante. No caso de correções para vulnerabilidades
classificadas como moderadas o CAIS recomenda que ao menos as
recomendações de mitigação sejam seguidas.

. Crítica - Vulnerabilidades cuja exploração possa permitir a propagação
  de um worm sem a necessidade de interação com o usuário.

. Importante - Vulnerabilidades cuja exploração possa resultar no
  comprometimento de confidencialidade, integridade ou disponibilidade
  de dados de usuários ou a integridade ou disponibilidade de recursos
  de processamento.

. Moderada - exploração é mitigada significativamente por fatores como
  configuração padrão, auditoria ou dificuldade de exploração.

. Baixa - uma vulnerabilidade cuja exploração seja extremamente difícil
  ou cujo impacto seja mínimo.


CORREÇÕES DISPONÍVEIS

Recomenda-se atualizar os sistemas para as versões disponíveis em:

. Microsoft Update
  https://www.update.microsoft.com/microsoftupdate/

. Microsoft Download Center
  http://www.microsoft.com/pt-br/download/security.aspx

MAIS INFORMAÇÕES

. Resumo do Boletim de Segurança da Microsoft de julho 2013
  http://technet.microsoft.com/pt-br/security/bulletin/ms13-jul

. Microsoft TechCenter de Segurança
  http://technet.microsoft.com/pt-br/security/

. Microsoft Security Response Center - MSRC
  http://www.microsoft.com/security/msrc/

. Microsoft Security Research & Defense - MSRD
  http://blogs.technet.com/srd/

. Central de Proteção e Segurança Microsoft
  http://www.microsoft.com/brasil/security/


Identificador CVE (http://cve.mitre.org <http://cve.mitre.org/>):

CVE-2013-3129, CVE-2013-3131, CVE-2013-3132, CVE-2013-3133,
CVE-2013-3134, CVE-2013-3171, CVE-2013-3178, CVE-2013-1300,
CVE-2013-1340, CVE-2013-1345, CVE-2013-3129, CVE-2013-3167,
CVE-2013-3173, CVE-2013-3660, CVE-2013-3129, CVE-2013-3115,
CVE-2013-3143, CVE-2013-3144, CVE-2013-3145, CVE-2013-3146,
CVE-2013-3147, CVE-2013-3148, CVE-2013-3149, CVE-2013-3150,
CVE-2013-3151, CVE-2013-3152, CVE-2013-3153, CVE-2013-3161,
CVE-2013-3162, CVE-2013-3163, CVE-2013-3164, CVE-2013-3166,
CVE-2013-3174, CVE-2013-3127, CVE-2013-3154


O CAIS recomenda que os administradores mantenham seus sistemas e
aplicativos sempre atualizados, de acordo com as últimas versões e
correções oferecidas pelos fabricantes.

Os Alertas do CAIS também são oferecidos no formato RSS/RDF e no Twitter:
http://www.rnp.br/cais/alertas/rss.xml
Siga @caisrnp


Atenciosamente,
Equipe do CAIS/RNP

################################################################
#   CENTRO DE ATENDIMENTO A INCIDENTES DE SEGURANCA (CAIS)     #
#       Rede Nacional de Ensino e Pesquisa (RNP)               #
#                                                              #
# cais em cais.rnp.br       http://www.cais.rnp.br                #
# Tel. 019-37873300      Fax. 019-37873301                     #
# Chave PGP disponivel   http://www.rnp.br/cais/cais-pgp.key   #
################################################################
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iQCVAwUBUd2w/ukli63F4U8VAQFKNQP8CNWp0lH41/c6qeeaQBi9SKmS4ZuEL9sz
Eok4lki8JC0uOdSqCWtUq+v2Dki3ileiNOrHF5tPaxvISxgKBXT5HaQ4jmIGU7Tg
xUm/IDUVw6DifGJh0d2Gs1VC7rFTOjXJjfMdHOFD/G+mD5TmwyMR179fqzUPqwZB
H2OSXXLerYM=
=+1Aw
-----END PGP SIGNATURE-----


----- End forwarded message -----


From security em unicamp.br  Tue Jul 23 09:25:34 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Tue, 23 Jul 2013 12:25:34 +0000
Subject: [SECURITY-L] [US-CERT@public.govdelivery.com: TA13-088A: DNS
	Amplification Attacks]
Message-ID: <20130723122534.GA4641@unicamp.br>

----- Forwarded message from US-CERT <US-CERT em public.govdelivery.com> -----

From: "US-CERT" <US-CERT em public.govdelivery.com>
Subject: TA13-088A: DNS Amplification Attacks
To: security em unicamp.br
Date: Mon, 22 Jul 2013 14:26:50 -0500

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-088A: DNS Amplification Attacks [ https://www.us-cert.gov/ncas/alerts/TA13-088A ] 03/29/2013 02:26 PM EDT 
Original release date: March 29, 2013 | Last revised: July 22, 2013

Systems Affected

  * Domain Name System (DNS) servers 

Overview

A Domain Name Server (DNS) amplification attack is a popular form of distributed denial of service (DDoS) that relies on the use of publically accessible open DNS servers to overwhelm a victim system with DNS response traffic.

Description

A Domain Name Server (DNS) Amplification attack is a popular form of Distributed Denial of Service (DDoS), in which attackers use publically accessible open DNS servers to flood a target system with DNS response traffic. The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target???s address. When the DNS server sends the DNS record response, it is sent instead to the target. Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. In most attacks of this type observed by US-CERT, the spoofed queries sent by the attacker are of the type, ???ANY,??? which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic directed at the victim. By leveraging a botnet to produce a large number of spoofed DNS queries, an attacker can create an immense amount of traffic with little effort. Additionally, because the responses are legitimate data coming from valid servers, it is extremely difficult to prevent these types of attacks. While the attacks are difficult to stop, network operators can apply several possible mitigation strategies.

While the most common form of this attack that US-CERT has observed involves DNS servers configured to allow unrestricted recursive resolution for any client on the Internet, attacks can also involve authoritative name servers that do not provide recursive resolution. The attack method is similar to open recursive resolvers, but is more difficult to mitigate since even a server configured with best practices can still be used in an attack. In the case of authoritative servers, mitigation should focus on using Response Rate Limiting to restrict the amount of traffic.

Impact

A misconfigured Domain Name System (DNS) server can be exploited to participate in a distributed denial of service (DDoS) attack.

Solution

DETECTION

While it is not easy to identify authoritative name servers used in DNS reflection attacks as vulnerability is not caused by a misconfiguration, there are several freely available options for detecting open recursive resolvers.  Several organizations offer free, web-based scanning tools that will search a network for vulnerable open DNS resolvers.  These tools will scan entire network ranges and list the address of any identified open resolvers.

"Open DNS Resolver Project"
http://openresolverproject.org
The Open DNS Resolver Project has compiled a list of DNS servers that are known to serve as globally accessible open resolvers. The query interface allows network administrators to enter IP ranges in CIDR format [1].

"The Measurement Factory"
http://dns.measurement-factory.com
Like the Open DNS Resolver Project, the Measurement Factory maintains a list of Internet accessible DNS servers and allows administrators to search for open recursive resolvers [2]. In addition, the Measurement Factory offers a free tool to test a single DNS resolver to determine if it allows open recursion. This will allow an administrator to determine if configuration changes are required and verify that configuration changes have been successful [3]. Finally, the site offers statistics showing the number of public resolvers detected on the different Autonomous System (AS) networks, sorted by the highest number found [4].

"DNSInspect"
http://www.dnsinspect.com
Another freely available, web-based tool for testing DNS resolvers is DNSInspect. This site is similar to The Measurement Factory???s ability to assess an individual resolver for vulnerability, but offers the ability to test an entire DNS Zone for several other possible configuration and security issues [5].

Indicators

In a typical recursive DNS query, a client sends a query request to a local DNS server requesting the resolution of a name or the reverse resolution of an IP address. The DNS server performs the necessary queries on behalf of the client and returns a response packet with the requested information or an error [6, page 21]. The specification does not allow for unsolicited responses. In a DNS amplification attack, the main indicator is a query response without a matching request.  

MITIGATION

Unfortunately, due to the massive traffic volume that can be produced by one of these attacks, there is often little that the victim can do to counter a large-scale DNS amplification-based distributed denial-of-service attack. However, it is possible to reduce the number of servers that can be used by attackers to generate the traffic volumes.

While the only effective means of eliminating the use of recursive resolvers in this type of attack is to eliminate unsecured recursive resolvers, this requires an extensive effort by various parties. According to the Open DNS Resolver Project, of the 27 million known DNS resolvers on the Internet, approximately ???25 million pose a significant threat??? of being used in an attack [1]. However, several possible techniques are available to reduce the overall effectiveness of such attacks to the Internet community as a whole. Where possible, configuration links have been provided to assist administrators with making the recommended changes. The configuration information has been limited to BIND9 and Microsoft???s DNS Server, which are two widely deployed DNS servers on federal networks. If you are running a different DNS server, please consult your vendor???s documentation for configuration details.

Source IP Verification

Because the DNS queries being sent by the attacker-controlled clients must have a source address spoofed to appear as the victim???s system, the first step to reducing the effectiveness of DNS amplification is for Internet Service Providers to reject any DNS traffic with spoofed addresses. The Network Working Group of the Internet Engineering Task Force released Best Current Practice 38 document in May 2000 and Best Current Practice 84 in March 2004 that describes how an Internet Service Provider can filter network traffic on their network to reject packets with source addresses not reachable via the actual packet???s path [7]. The changes recommended in this document would cause a routing device to evaluate whether it is possible to reach the source address of the packet via the interface that transmitted the packet. If it is not possible, then the packet obviously has a spoofed source address. This configuration change would substantially reduce the potential for most popular types of DDoS attacks. As such, we highly recommend to all network operators to perform network ingress filtering if possible.

Disabling Recursion on Authoritative Name Servers

Many of the DNS servers currently deployed on the Internet are exclusively intended to provide name resolution for a single domain. In these systems, DNS resolution for private client systems may be provided by a separate server and the authoritative server acts only as a DNS source of zone information to external clients. These systems do not need to support recursive resolution of other domains on behalf of a client, and should be configured with recursion disabled.

Bind9

Add the following to the global options [8]:
options {
     allow-query-cache { none; };
     recursion no;
};

Microsoft DNS Server

In the Microsoft DNS console tool [9]:


  * Right-click the DNS server and click Properties. 
  * Click the Advanced tab. 
  * In Server options, select the ???Disable recursion??? check box, and then click OK. 

Limiting Recursion to Authorized Clients

For DNS servers that are deployed within an organization or Internet Service Provider, the resolver should be configured to perform recursive queries on behalf of authorized clients only. These requests typically should only come from clients within the organization???s network address range. We highly recommend that all server administrators restrict recursion to only clients on the organization???s network.

BIND9

In the global options, include the following [10]:
acl corpnets { 192.168.1.0/24; 192.168.2.0/24; };
options {
  allow-query { any; };
  allow-recursion { corpnets; };
};

Microsoft DNS Server

It is not currently possible to restrict recursive DNS requests to a particular client address range in Microsoft DNS Server. To approximate the functionality of the BIND access control lists in Microsoft???s DNS Server, a different caching-only name server should be set up internally to provide recursive resolution. A firewall rule should be created to block incoming access to the caching-only server from outside the organization???s network. The authoritative name server functionality would then need to be hosted on a separate server, but configured to disable recursion as previously described.

Response Rate Limiting (RRL)

There is currently an experimental feature available as a set of patches for BIND9 that allows an administrator to limit the maximum number of responses per second being sent to one client from the name server [11]. This functionality is intended to be used on authoritative domain name servers only as it will affect performance on recursive resolvers. To provide the most effective protection, we recommend that authoritative and recursive name servers run on different systems, with RRL implemented on the authoritative server and access control lists implemented on the recursive server. This will reduce the effectiveness of DNS amplification attacks by reducing the amount of traffic coming from any single authoritative server while not affecting the performance of the internal recursive resolvers.

BIND9

There are currently patches available for 9.8.latest and 9.9.latest to support RRL on UNIX systems. Red Hat has made updated packages available for Red Hat Enterprise Linux 6 to provide the necessary changes in advisory RHSA-2013:0550-1. On BIND9 implementation running the RRL patches, include the following lines to the options block of the authoritative views [12]:
rate-limit {
    responses-per-second 5;
    window 5;
};

Microsoft DNS Server

This option is currently not available for Microsoft DNS Server.

"*Disclaimer:*"  Rate limiting DNS responses may prevent legitimate hosts from receiving answers. Such hosts may be at increased risk for successful DNS cache poisoning attacks.

RRL of DNS responses may prevent legitimate hosts from receiving answers. Such hosts may be at increased risk for successful DNS cache poisoning attacks.

References

  * [1] Open DNS Resolver Project [ http://openresolverproject.org ] 
  * [2] The Measurement Factory, "List Open Resolvers on Your Network" [ http://dns.measurement-factory.com/cgi-bin/openresolverquery.pl ] 
  * [3] The Measurement Factory, "Open Resolver Test" [ http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl ] 
  * [4] The Measurement Factory, "Open Resolvers for Each Autonomous System" [ http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html ] 
  * [5] "DNSInspect," DNSInspect.com [ http://www.dnsinspect.com ] 
  * [6] RFC 1034: DOMAIN NAMES - CONCEPTS AND FACILITIES [ http://tools.ietf.org/html/rfc1034 ] 
  * [7] BCP 38: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing [ http://tools.ietf.org/html/bcp38 ] 
  * [8] Chapter 3. Name Server Configuration [ http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch03.html#id2567992 ] 
  * [9] Disable recursion on the DNS server [ http://technet.microsoft.com/en-us/library/cc787602.aspx ] 
  * [10] Chapter 7. BIND 9 Security Considerations [ http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch07.html#Access_Control_Lists ] 
  * [11] DNS Response Rate Limiting (DNS RRL) [ http://ss.vix.su/~vixie/isc-tn-2012-1.txt ] 
  * [12] Response Rate Limiting in the Domain Name System (DNS RRL) [ http://www.redbarn.org/dns/ratelimits ] 
  * [13] The Measurement Factory, "Open Resolvers for Each Autonomous System" [ http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html ] 
  * [14] Configure a DNS Server to Use Forwarders [ http://technet.microsoft.com/en-us/library/cc754941.aspx ] 

Revision History

  * March 29, 2013: Initial release 
  * April 18, 2013: Minor updates to Description and Solution sections(Source IP Verification and BIND9) 
  * July 5, 2013: Added disclaimer for DNS request rate limiting 
  * July 8, 2013: Updates to Description, Detection, and Mitigation sections 
  * July 22, 2013: Minor updates to recursion and RRL advice 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ] 

SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ]  |  Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.6a6fc2cec2b9952ff27f6db27530aead&destination=security em unicamp.br ]  |  Help <support em govdelivery.com>

________________________________________________________________________

This email was sent to security em unicamp.br using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]



----- End forwarded message -----


From security em unicamp.br  Mon Jul 29 09:39:39 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Mon, 29 Jul 2013 09:39:39 -0300
Subject: [SECURITY-L] [US-CERT@public.govdelivery.com: TA13-207A: IPMI
	TechAlert]
Message-ID: <20130729123939.GK13993@unicamp.br>

----- Forwarded message from US-CERT <US-CERT em public.govdelivery.com> -----

Date: Fri, 26 Jul 2013 17:19:46 -0500
From: US-CERT <US-CERT em public.govdelivery.com>
To: security em unicamp.br
Subject: TA13-207A: IPMI TechAlert

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-207A: IPMI TechAlert [ https://www.us-cert.gov/ncas/alerts/TA13-207A ] 07/26/2013 04:08 PM EDT 
Original release date: July 26, 2013

Systems Affected

Any system connected to the internet running the Intelligent Platform Management Interface (IPMI) may be affected. IPMI is resident on many server platforms, and provides low-level access to a system that can override operating system controls.

Overview

Attackers can easily identify and access systems that run IPMI and are connected to the Internet. It is important to restrict IPMI access to specific management IP addresses within an organization and preferably separated into a separate LAN segment.

Description

*What is the Intelligent Platform Management Interface (IPMI)?*

IPMI is a low level interface specification that has been adopted by many hardware vendors.  It allows a system administrator to remotely manage servers at the hardware level.  IPMI runs on the Baseboard Management Controller (BMC) and provides access to the BIOS, disks, and other hardware.  It also supports remote booting from a CD or through the network, and monitoring of the server environment.  The BMC itself also runs a limited set of network services to facilitate management and communications amongst systems.

*What Is the Risk?*

Attackers can use IPMI to essentially gain physical-level access to the server.  An attacker can reboot the system, install a new operating system, or compromise data, bypassing any operating system controls.  Some issues identified by Dan Farmer [ http://fish2.com/ipmi/itrain.html ]: 


  * Passwords for IPMI authentication are saved in clear text. 
  * Knowledge of one IPMI password gives you the password for all computers in the IPMI managed group. 
  * Root access on an IPMI system grants complete control over hardware, software, firmware on the system. 
  * BMCs often run excess and older network services that may be vulnerable. 
  * IPMI access may also grant remote console access to the system, resulting in access to the BIOS. 
  * There are few, if any, monitoring tools available to detect if the BMC is compromised. 
  * Certain types of traffic to and from the BMC are not encrypted. 
  * Unclear documentation on how to sanitize IPMI passwords without destruction of the motherboard. 

Attackers can easily search and identify internet-connected target systems, and IPMI is no exception.

Impact

An attacker with knowledge of IPMI can search for, and find, open management interfaces. Many of these interfaces utilize default or no passwords, or weak encryption.  Further consequences depend on the type and use of the compromised system.  At the very least, an attacker can compromise confidentiality, integrity, and availability of the server once gaining access to the BMC.

Solution

*Solution*

*Restrict IPMI to Internal Networks*

Restrict IPMI traffic to trusted internal networks. Traffic from IPMI (usually UDP port 623) should be restricted to a management VLAN segment with strong network controls.  Scan for IPMI usage outside of the trusted network and monitor the trusted network for abnormal activity.

*Utilize Strong Passwords*

Devices running IPMI should have strong, unique passwords set for the IPMI service.  See US-CERT Security Tip ST04-002 [ http://www.us-cert.gov/ncas/tips/ST04-002 ] and "Password Security, Protection, and Management" [ https://www.us-cert.gov/reading_room/PasswordMgmt2012.pdf ] for more information on password security.

*Encrypt Traffic*

Enable encryption on IPMI interfaces, if possible.  Check your manufacturer manual for details on how to set up encryption.

*Require Authentication*

"cipher 0" is an option enabled by default on many IPMI enabled devices that allows authentication to be bypassed.  Disable "cipher 0" to prevent attackers from bypassing authentication and sending arbitrary IPMI commands.  Anonymous logins should also be disabled.

*Sanitize Flash Memory at End of Life*

Follow manufacturer recommendations for sanitizing passwords.  If none exists, destroy the flash chip, motherboard, or other areas the IPMI password may be stored. 

*Identify Affected Products*


  *  Most server products 
  * HP Integrated Lights Out 
  * Dell DRAC 
  * IBM Remote Supervisor Adapter 

References

  * A Penetration Tester's Guide to IPMI and BMCs [ https://community.rapid7.com/community/metasploit/blog/2013/06/23/a-penetration-testers-guide-to-ipmi ] 
  * Dan Farmer's IPMI++ Security Best Practices [ http://fish2.com/ipmi/bp.pdf ] 
  * Dan Farmer's Page on IPMI Security [ http://fish2.com/ipmi/ ] 

Revision History

  * July 26, 2013 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ] 

SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ]  |  Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.6a6fc2cec2b9952ff27f6db27530aead&destination=security em unicamp.br ]  |  Help <support em govdelivery.com>

________________________________________________________________________

This email was sent to security em unicamp.br using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]



----- End forwarded message -----


From security em unicamp.br  Tue Jul 30 16:05:08 2013
From: security em unicamp.br (CSIRT - UNICAMP)
Date: Tue, 30 Jul 2013 16:05:08 -0300
Subject: [SECURITY-L] [US-CERT@public.govdelivery.com: TA13-207A: Risks of
 Using the Intelligent Platform Management Interface (IPMI)]
Message-ID: <20130730190508.GA5147@unicamp.br>

----- Forwarded message from US-CERT <US-CERT em public.govdelivery.com> -----

Date: Tue, 30 Jul 2013 13:20:31 -0500
From: US-CERT <US-CERT em public.govdelivery.com>
To: security em unicamp.br
Subject: TA13-207A: Risks of Using the Intelligent Platform Management Interface (IPMI)

US Computer Emergency Readiness Team banner graphic

National Cyber Awareness System:

TA13-207A: Risks of Using the Intelligent Platform Management Interface (IPMI) [ https://www.us-cert.gov/ncas/alerts/TA13-207A ] 07/26/2013 04:08 PM EDT 
Original release date: July 26, 2013 | Last revised: July 30, 2013

Systems Affected

Any system connected to the internet running the Intelligent Platform Management Interface (IPMI) may be affected. IPMI is resident on many server platforms, and provides low-level access to a system that can override operating system controls.

Overview

Attackers can easily identify and access systems that run IPMI and are connected to the Internet. It is important to restrict IPMI access to specific management IP addresses within an organization and preferably separated into a separate LAN segment.

Description

*What is the Intelligent Platform Management Interface (IPMI)?*

IPMI is a low level interface specification that has been adopted by many hardware vendors.  It allows a system administrator to remotely manage servers at the hardware level.  IPMI runs on the Baseboard Management Controller (BMC) and provides access to the BIOS, disks, and other hardware.  It also supports remote booting from a CD or through the network, and monitoring of the server environment.  The BMC itself also runs a limited set of network services to facilitate management and communications amongst systems.

*What Is the Risk?*

Attackers can use IPMI to essentially gain physical-level access to the server.  An attacker can reboot the system, install a new operating system, or compromise data, bypassing any operating system controls.  Some issues identified by Dan Farmer [ http://fish2.com/ipmi/itrain.html ]: 


  * Passwords for IPMI authentication are saved in clear text. 
  * Knowledge of one IPMI password gives you the password for all computers in the IPMI managed group. 
  * Root access on an IPMI system grants complete control over hardware, software, firmware on the system. 
  * BMCs often run excess and older network services that may be vulnerable. 
  * IPMI access may also grant remote console access to the system, resulting in access to the BIOS. 
  * There are few, if any, monitoring tools available to detect if the BMC is compromised. 
  * Certain types of traffic to and from the BMC are not encrypted. 
  * Unclear documentation on how to sanitize IPMI passwords without destruction of the motherboard. 

Attackers can easily search and identify internet-connected target systems, and IPMI is no exception.

Impact

An attacker with knowledge of IPMI can search for, and find, open management interfaces. Many of these interfaces utilize default or no passwords, or weak encryption.  Further consequences depend on the type and use of the compromised system.  At the very least, an attacker can compromise confidentiality, integrity, and availability of the server once gaining access to the BMC.

Solution

*Solution*

*Restrict IPMI to Internal Networks*

Restrict IPMI traffic to trusted internal networks. Traffic from IPMI (usually UDP port 623) should be restricted to a management VLAN segment with strong network controls.  Scan for IPMI usage outside of the trusted network and monitor the trusted network for abnormal activity.

*Utilize Strong Passwords*

Devices running IPMI should have strong, unique passwords set for the IPMI service.  See US-CERT Security Tip ST04-002 [ http://www.us-cert.gov/ncas/tips/ST04-002 ] and "Password Security, Protection, and Management" [ https://www.us-cert.gov/reading_room/PasswordMgmt2012.pdf ] for more information on password security.

*Encrypt Traffic*

Enable encryption on IPMI interfaces, if possible.  Check your manufacturer manual for details on how to set up encryption.

*Require Authentication*

"cipher 0" is an option enabled by default on many IPMI enabled devices that allows authentication to be bypassed.  Disable "cipher 0" to prevent attackers from bypassing authentication and sending arbitrary IPMI commands.  Anonymous logins should also be disabled.

*Sanitize Flash Memory at End of Life*

Follow manufacturer recommendations for sanitizing passwords.  If none exists, destroy the flash chip, motherboard, or other areas the IPMI password may be stored. 

*Identify Affected Products*


  *  Most server products 
  * HP Integrated Lights Out 
  * Dell DRAC 
  * IBM Remote Supervisor Adapter 

References

  * A Penetration Tester's Guide to IPMI and BMCs [ https://community.rapid7.com/community/metasploit/blog/2013/06/23/a-penetration-testers-guide-to-ipmi ] 
  * Dan Farmer's IPMI++ Security Best Practices [ http://fish2.com/ipmi/bp.pdf ] 
  * Dan Farmer's Page on IPMI Security [ http://fish2.com/ipmi/ ] 

Revision History

  * July 26, 2013 
________________________________________________________________________

This product is provided subject to this Notification [ http://www.us-cert.gov/privacy/notification ] and this Privacy & Use [ http://www.us-cert.gov/privacy/ ] policy.

________________________________________________________________________

OTHER RESOURCES: Contact Us [ http://www.us-cert.gov/contact-us/ ] | Security Publications [ http://www.us-cert.gov/security-publications ] | Alerts and Tips [ http://www.us-cert.gov/ncas ] | Related Resources [ http://www.us-cert.gov/related-resources ] 

STAY CONNECTED: Sign up for email updates [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/new ] 

SUBSCRIBER SERVICES:
Manage Preferences [ http://public.govdelivery.com/accounts/USDHSUSCERT/subscribers/new?preferences=true ]  |  Unsubscribe [ https://public.govdelivery.com/accounts/USDHSUSCERT/subscriber/one_click_unsubscribe?verification=5.6a6fc2cec2b9952ff27f6db27530aead&destination=security em unicamp.br ]  |  Help <support em govdelivery.com>

________________________________________________________________________

This email was sent to security em unicamp.br using GovDelivery, on behalf of: United States Computer Emergency Readiness Team (US-CERT) · 245 Murray Lane SW Bldg 410 · Washington, DC 20598 · (703) 235-5110 Powered by GovDelivery [ http://www.govdelivery.com/portals/powered-by ]



----- End forwarded message -----