Based on some background knowledge that we received (update 2018/5/14 14:00 UTC+1: we now know it's the efail.de
bug. The researchers went forward with the public release today), I am taking the liberty to document a setup which protects an Apple Mail installation that I have.
The security measure is simple: disable remote content on Apple Mail. Go to Preferences -> General and uncheck the checkbox "Load Remote content in messages".
However, there is an even stricter mechanism which does not rely on Apple Mail directly. Think of it as a second, very secure safety net. The idea: should any
software component get hacked in my Apple Mail or should it leak information (such as encrypted Mail content), I want to make sure that my Apple Mail talks to one and only one single point of enforcement: the IMAP server it should talk to. And nothing else. Therefore, data exfiltration gets much harder.
Luckily there is a good tool for this: Little Snitch
(and as far as I know, this is the only tool of its kind on OS X). With Little Snitch, which acts as an outgoing firewall, I am able to protect and filter the communication flows.
My Little Snitch setup only allows port 25 (SMTP) as well as IMAPs (port 993) connection for Apple Mail. HTTP(s) connects are definitely forbidden. That means that , yes, I won't see all images which reside on some web server. But in practice this does not matter. Either such a mail was spam / marketing in the first place or it was legit and is also visible via a browser if really needed (remember those "can't see this in your mail client? click here..." links in mails?).
In other words: this is a super simple trick to get rid of a whole class of exfiltration attacks. I'd appreciate it if we had such a tool on Linux. Though... hang on... there is an initial attempt by @evilsocket: https://github.com/evilsocket/opensnitch
. Haven't tested that yet. Eager to hear some feedback from you if it works on Linux.
Anyway, thanks to Little Snitch (and maybe opensnitch), mail client hacking data exfiltration is not a threat anymore.
Author: L. Aaron Kaplan
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