Deutsch | English
This blog does not contain official statements of CERT.at, only personal opinions of the individual contributors.
Heartbleed: (Almost) three years later
2017/01/27

Shodan recently published a report on the state of Heartbleed which was picked up by lots of media outlets.

I took this as an opportunity to have a look at our statistics. Shodan performs its scan based on IP-addresses and makes the results searchable. CERT.at also runs daily scans, but these are based on the list of domains under the Austrian ccTLD .at. We published a first report on these results in the summer of 2014. We're close to the three year mark now, which is a very long time the Internet. So how do our numbers look like in January 2017?

We start by a list of domains under .at and look for web and mail servers as found by MX and A records. For web servers, we use either the domain itself, or www.$domain. This gives the following frame for the rest of the graphs: the roughly 1.5 million domains under .at are served by 200 thousand web servers and 100 thousand mail servers.

2017-01-hb-basics

Looking a the best TLS support these servers offer, we see that both for HTTPS (web) and SMTP (mail) about half of the servers support encrypted connections.

2017-01-hb-tlssupport

As the larger mail-servers are much more likely to support TLS than smaller ones, the percentage of domains who can receive emails over TLS is actually about 90%.

Testing all those servers for the Heartbleed vulnerability gives the following result:

2017-01-hb-ip-status

The vulnerable server barely show on the graph, for both protocols they are about 0.12% of all servers and about 0.22% of all servers offering TLS.

Over time, the numbers have fallen in the usual long-tail drop-off curve. As the domain-list and domain to IP-address mappings are not refreshed daily, these refreshes show up as upward spikes in the graph. This implies that a part of the decline in vulnerable servers was caused by IP and domain churn.

2017-01-hb-ip-timeline

What does this mean for Domains?

It's pointless to graph vulnerable vs. not-vulnerable domains, the bar for vulnerable servers is not visible. In numbers: 1557 domains (0.29% of all TLS-enabled ones) are still vulnerable on HTTPS, and 320 on SMTP (0.05%). Graphing the development yields:

2017-01-hb-domain-timeline

This graph is a rough approximation as the historical domain to IP mappings are not kept in the system. Anyway, something weird is going on. Lets have a closer look with regards to how important single servers are for the overall domain score. For that we'll use a combined graph showing the contributions of each server to the total number as well as the cumulative distribution function showing how many servers you need to fix to achieve x% of the vulnerable domains (Excel calls it the "Pareto Line").

Let's start with the domains:

2017-01-hb-smtp-cdf

The largest mailserver contributes about a third of the vulnerable domains, take the first three and they cover half of the heartbleed-affected Domains. Those are run by a small ISP, a PR/web agency and a private person, respectively.

The same graph for HTTPS looks like this:

2017-01-hb-https-cdf

This is far more concentrated: The first server hosts 809 domains (about half of the total), the second one 480 and third one 11. About 100 server comprise the long tail of vulnerable servers hosting just one .at domain. Checking some of the domains on these servers shows that the first one is run by a local ISP/registrar and is used for domains that are not in use. The second one only serves "this domain is for sale".

Summary: While Shodan still found a good number of vulnerable servers on the Austrian Internet, these are mostly not the servers that host relevant content.

Author: Otmar Lendl

DROWN update
2016/04/11

As I wrote in our initial DROWN blogpost, we're scanning .at for mail- and web-servers which are still supporting SSLv2. We're notifying our constituency and we see a steady drop in the number of servers (as measured by IP-Addresses) that are vulnerable:

drown-status-in-dotat

So it is slowly getting better.

Looking at the feedback we receive there is one point though that needs extra attention: Disabling all SSLv2 ciphers might not be enough. You need to disable the SSLv2 protocol.

See this FAQ from the DROWN website:

DROWN is made worse by two additional OpenSSL implementation vulnerabilities. CVE-2015-3197, which affected OpenSSL versions prior to 1.0.2f and 1.0.1r, allows a DROWN attacker to connect to the server with disabled SSLv2 ciphersuites, provided that support for SSLv2 itself is enabled. CVE-2016-0703, which affected OpenSSL versions prior to 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf, greatly reduces the time and cost of carrying out the DROWN attack.

We will thus continue to send warnings as long as SSLv2 is not completely disabled. For the typical Linux setup, this openssl.org post contains suitable configuration advise.

Author: Otmar Lendl

One quick note on DNSSEC Validation failures
2015/03/11

I wrote back in 2010 that ISPs should prepare for the inevitable backlash if their DNSSEC-aware resolvers black out an important domain.

We now had just such a case: the protagonists make it even juicier than I imagined: Comcast customers could not access the new HBO website where they could get the HBO programming without paying for a full cable TV package.

Accusation were flying, emergency debugging and cache clearing ensued and we're now in the "What went wrong?" and "./ style discussions" stage.

It looks like Comcast weathered that storm pretty well. This may be a result of good social media work, a quick fix from HBO, and the fact that Google's 8.8.8.8 nameserver also does DNSSEC validation.

Author: Otmar Lendl

Lesestoff: Ron Deibert
2014/11/26

Wir leben nicht nur in einer technisch interessanten Zeit, sondern auch die gesellschaftliche Diskussion rund um Geheimdienste, Privatsphäre, Verschlüsselung, 0-Days bis hin zu "Cyberwar" ist für die Zukunft des Internets sehr relevant.

Dazu wird viel geschrieben und publiziert, ich will hier auf einen aktuellen Artikel von Ron Deibert hinweisen, weil er auch die Rolle der CERTs in diesem Kontext anspricht:

There are international implications of the cyber security syndrome. Top-down, secretive approaches breed vicious cycles of mutual suspicion and hostility that stifle numerous forms of lower level cooperation. Consider the deleterious impact on the information sharing practices of national-level computer emergency response teams (CERTs). In an ideal world, CERTS are entirely apolitical and operate as early-warning systems that share network threat information with each other seamlessly. But as Asia Pacific CERT coordinator Yuri Ito explained at the 2013 Bali IGF, the growing influences of national security agencies and the rivalries and suspicion they engender have eaten into the system of international trust and cooperation. If CERTs are seen as "instruments of state competition," says Ito, "it can become very hard to share information." Jeopardizing the integrity of CERTs in this way -- the frontline sensors for computer security threats worldwide -- is a clear indication that we are down the wrong path.

Ich kann nur empfehlen, den ganzen Text zu lesen.

Author: Otmar Lendl

Next >>
Email: reports@cert.at
Phone: +43 1 5056416 78
more ...
Heartbleed: (Almost) three years later
2017/01/27 | Shodan recently ...
DROWN update
2016/04/11 | As I wrote ...
more ...
Last Change: 2017/1/27 - 16:33:17
Haftungsausschluss