Insecure DNS for internet banking
The Internet’s domain name service (DNS) was originally designed three decades ago. Back then no security mechanism were included into the specification of DNS, which would guarantee the authenticity of DNS query responses. This deficiency is exploited by widely known DNS cache poisoning and DNS hijacking attacks. DNSSEC is a security extension to DNS, which uses cryptographic signatures in oder to protect against forged DNS data.
DNS is fundamental for the proper functioning of Internet services. Besides the most prominent task of translating domain names (e.g., www.sthu.org) to IP addresses (e.g., 22.214.171.124), DNS also provides information to e-mail1 servers, anti-spam software2, chat software3, or remote shell software4. Without DNSSEC, no guarantee can be given that the DNS query answers are authentic, which causes a severe security gap.
Since customers’ trust is of particular interest for banks and other financial institutes, one would expect that they would be especially eager to implement DNSSEC for their respective domains. Unfortunately and surprisingly, the opposite seams to be true. On August 4, I had a look at the domains of Oberbank, Volksbank, Sparkasse, Raiffeisenbank, Hypo, BAWAG and PayLife. None of them used DNSSEC back then. I sent a mail to Oberbank and quickly got a response: They are grateful for my proposal to use DNSSEC and the responsible people have been informed. However, no schedule for the implementation is fixed yet. I also sent a mail to PayLife: They even gave me a call telling me something similar as Oberbank.
So at least there seems to be a general awareness.
The Austrian top-level domain .at is managed by nic.at, which enabled DNSSEC support in Feb 12, 2012. For more than 1.5 years it is possible5 to ship DNSSEC for .at domains. There are at least two ways to check whether a domain uses DNSSEC:
- Whois has an appropriate entry:
% whois sthu.org | grep DNSSEC DNSSEC:Signed % whois nic.at | grep DNSSEC DNSSEC: Signed
- With dig one can directly ask
domain name servers for respective RRSIG, DNSKEY, or DS records.
% dig -t RRSIG +multiline sthu.org [...] ;; ANSWER SECTION: sthu.org. 86336 IN RRSIG SOA 7 2 86400 ( 20131214000000 20131116134802 33932 sthu.org. CIZqmJUtkNvinXfOTtbVAXgO3ohOFZN0AchV5/XKve+n d9ySmnAXW2wwNLoAlpqJbukd7fGBNOE0+HuEUlj4W0sY gyv1aVZnrU5l01mmT4/J2//d4R7srGuYIUBVDf7wr/NU Z47bWcGE63MM/PpJM7Jn0IqXrplFQzaNwFoUHek= ) [...] % dig -t RRSIG +multiline nic.at [...] ;; ANSWER SECTION: nic.at. 900 IN RRSIG A 7 2 900 ( 20131128154422 20131029145637 21170 nic.at. czKDiEerZ4i+ORO2/OtBacTIomUmYXEUDflzILn7vn/q eu1C1CnkUZTQ1wNSqoGb4QLG/wziNUqrkAqltUfpQ2+v v0WXSVqnNCEsxPKqL5/F0NbB/wA12RHtUmfWEw2ZLb0s a4Xa74bR968J4W2VUPKVIj2+nSHpcsCJPvsMB2w= ) [...]
Also, if you use a validating nameserver (e.g., Google’s nameservers, or a local unbound), then the AD flag will be set if the DNS data could be authenticated:
% dig @126.96.36.199 sthu.org [...] ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 [...] % dig @188.8.131.52 nic.at [...] ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 [...]
I have again tested various financial institutes whether they support DNSSEC, using the above methods. None of the following does:
So, I still remain curious which of the above domains will be the first to adopt DNSSEC in order to provide a secure DNS for their e-banking services. Without DNSSEC it is simply unclear whether a DNS server’s response for any of the above domains is authentic or forged.
Update. On November 17, I wrote the above companies an e-mail to ask whether or when they will add DNSSEC support.
Volksbank and PayPal did not provide any e-mail address in their impressum, hence I did not contact them. This is per se noteworthy as § 5 (1) Z.3 ECG requires them to publish an electronic postal address.
Oberbank were the first to concretely respond and they were quite verbose. Their nameservers are operated by Telekom, and they have posted their wish to add DNSSEC support. They look forward to implement DNSSEC within the first quarter of 2014, at latest in the second quarter. Anyhow, it seems to be pretty clear for Oberbank that DNSSEC is a necessity.
PayLife also responded on November 18, only to ask to whom I talked to back in August. On November 20 they wrote again to tell me that they will soon discuss this matter. After a few weeks, on December 13, they informed me that due to the takeover by SIX Group, there will be several migrations and adaptions, and hence it will take 6 or 12 months until DNSSEC will be implemented.
BAWAG’s response on November 21 was quite short: They will discuss with their sysadmins if and when they will activate DNSSEC.
All others did not answer (yet).
MX records tell SMTP servers to which servers a specific mail shall be sent. ↩
SPF records are shipped by the DNS. ↩
SRV records tell XMPP (e.g., Google Talk) client software to which server to connect. ↩
SSH fingerprints can be shipped by DNS. ↩
Technically speaking, it would have been possible to roll out DNSSEC for a domain even if the parent zone is not supporting DNSSEC yet. ↩
The .com top-level domain supports DNSSEC since April 1, 2011. ↩
paypal.com uses DNSSEC and paypal.at is redirected to paypal.com. However, as long as paypal.at does not use DNSSEC, any user entering paypal via paypal.at is not protected by DNSSEC. ↩