Last week, Alexandre and Andras from CIRCL.lu
gave a MISP workshop to a packed crowed of ~ 60-70 people in Vienna.
MISP stands for "Malware Information Sharing Platform". See also misp-project.org
. It allows us to synchronise IoCs with those who need the relevant information about attacks against their information systems.
This blog post is part of a series of blog posts related to our CEF-Telcom-2016-3 project.
Author: L. Aaron Kaplan
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.
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.
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:
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.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:
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:
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:
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
As I wrote in our initial DROWN blogpos
t, 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:
So it is slowly
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
2015/03/11I 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
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 220.127.116.11 nameserver also does DNSSEC validation.
Author: Otmar Lendl