The Heartbleed Bug

CVE-2014-0160 – Heartbleed Bug

CVE-2014-0160 HeartbleedThe Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

What leaks in practice?

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

How to stop the leak?

As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.

Why it is called the Heartbleed Bug?

Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.

You can check if you’re vulnerable via the following link: http://filippo.io/Heartbleed/

Source: heartbleed.com

Update:

Make sure that you only update your password if that site is no longer vulnerable.

But suggestions by Yahoo and the BBC that people should change their passwords at once – the typical reaction to a security breach – could make the problem worse if the web server hasn’t been updated to fix the flaw, says Mark Schloesser, a security researcher with Rapid7, based in Amsterdam, Netherlands.

Doing so “could even increase the chance of somebody getting the new password through the vulnerability,” Schloesser said, because logging in to an insecure server to change a password could reveal both the old and new passwords to an attacker.

Source: The Guardian

NTP reflection attacks

NTP reflection attacks across the Internet.

reflection-attackNTP is the Network Time Protocol, it is a relatively obscure protocol that runs over port 123 UDP and is used to sync time between machines on a network. If you have ever set up a home computer or server and been asked which time server you want to use, that is an NTP connection.

NTP is one of those set-it-and-forget-it protocols that is configured once and most network administrators don’t worry about it after that. Unfortunately, that means it is also not a service that is upgraded often, leaving it vulnerable to these reflection attacks.

How do NTP reflection attacks work?

Similar to DNS amplification attacks, the attacker sends a small forged packet that requests a large amount of data be sent to the target IP Address.

In this case, the attackers are taking advantage of the monlist command. Monlist is a remote command in older version of NTP that sends the requester a list of the last 600 hosts who have connected to that server. For attackers the monlist query is a great reconnaissance tool. For a localized NTP server it can help to build a network profile. However, as a DDoS tool, it is even better because a small query can redirect megabytes worth of traffic:

[user@server ~]# ntpdc -c monlist [hostname]
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  53949 127.0.0.1              1 7 2      0      0       0
tock.usshc.com           123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      53
198.52.198.248           123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      54
rook.slash31.com         123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      55
eightyeight.xmission.c   123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      56

 

Most scanning tools, such as NMAP, have a monlist module for gathering network information and many attack tools, including metasploit, have a monlist DDoS module.

How can you protect your servers? The easiest way to update to NTP version 4.2.7, which removes the monlist command entirely. If upgrading is not an option, you can start the NTP daemon with noquery enabled in the NTP conf file. This will disable access to mode 6 and 7 query packets (which includes monist).

By disabling monlist, or upgrading so the the command is no longer there, not only are you protecting your network from unwanted reconnaissance, but you are also protecting your network from inadvertently being used in a DDoS attack.

NTP security notice


Reference: NTP public service project

DNS-based Authentication of Named Entities

DANE: DNS-based Authentication of Named Entities

Authentication of Domain Name System (DNS) names for Transport-Layer Security (TLS) endpoints is a core security challenge in many Internet protocols, most famously Hypertext Transfer Protocol (HTTP). Today, the cryptographic bindings that underlie TLS authentication are asserted in Public Key Infrastructure for X.509 (PKIX) certificates issued by third-party certification authorities (CAs). The DNS-based Authentication of Named Entities (DANE) working group is developing protocols that allow certificates to be bound to DNS names using Domain Name System Security Extensions (DNSSEC).

Complete article: read more
DNSSEC: Wiki information

DNS amplification attack

DNS Amplification AttackDNS amplification explained

A DNS amplification attack is a type of distributed denial of service (DDoS) attack that takes advantage of the fact that a small DNS query can generate a much larger response. An attacker can direct a large volume of network traffic to a victim’s system by initiating relatively small DNS queries. The attacker spoofs the IP address of the victim to reflect the network traffic using the DNS server. This makes it difficult to trace the attacker.

In order to launch a DNS amplification reflection attack the attacker needs to perform two tasks. First the attacker spoofs the address of the victim. This is the reflection part, it will cause all the reply’s from the DNS server to be directed to the victim’s server. This can easily be done since in UDP no handshake (like in TCP) is being done between the client and the server. Secondly the requester searches for responses that are several times bigger than the request. The attacker achieves an amplification factor because the response is many times larger than the request. The amplification can even be larger when DNSSEC is used, because of the signatures used the size of the response increases.

Explained by NLnetlabs: download