My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

Secunia's DNS/domain hijacked?

Published: 2010-11-25. Last Updated: 2010-11-25 08:57:08 UTC
by Bojan Zdrnja (Version: 1)
4 comment(s)

We received quite a bit of reports of people saying that Secunia’s web site has been defaced. And indeed, when I visit Secunia’s web site from my machine (located in Europe), I see a defaced web site as below:

Secunia's defacement

However, after double checking it appears that their DNS records have been modified. The “defaced” web site is located (for me) at the following IP address:

$ host www.secunia.com
www.secunia.com is an alias for secunia.com.
secunia.com has address 81.95.49.32
secunia.com mail is handled by 0 secunia.com.

Checking my passive DNS system, I can see that previously www.secunia.com was at 213.150.41.226.

And, as suspected, after checking manually we can see that the original Secunia’s web site is still there:

$ telnet 213.150.41.226 80
Trying 213.150.41.226...
Connected to secunia.com (213.150.41.226).
Escape character is '^]'.
GET / HTTP/1.0
Host: secunia.com

HTTP/1.1 200 OK
Date: Thu, 25 Nov 2010 08:46:29 GMT
Server: Apache
...
        <meta name="Title" content="Secunia.com">
                <link rel="stylesheet" type="text/css" href="/css/secunia.css">

Checking WHOIS entries will show more, but this "defacement" again shows how DNS is a critical resource.

--
Bojan
INFIGO IS

Keywords: dns hijack secunia
4 comment(s)
My next class:
Web App Penetration Testing and Ethical HackingAmsterdamMar 31st - Apr 5th 2025

Comments

From http://secunia.com/blog/153/:

Redirection of DNS traffic

10:15 CET on the 25th November 2010
Entry written by Thomas Kristensen.

On Thursday 25th November at 00:40AM CET the authoritative DNS hosting was redirected for 1 hour 10 minutes.

This has resulted in traffic temporarily being redirected to a non-Secunia site.

Due to standard DNS caching at some Internet Service Providers, some users may still be redirected.

The incident is currently being investigated and we will update our blog with relevant information.

Customers may contact our Customer Support Center at csc@secunia.com or call +45 7020 5144 with any questions.

Kind regards,

Thomas Kristensen
CSO
This is an issue for their PSI/CSI product; they only work when connected back to the Secunia servers. I wonder if they actually check for the Secunia SSL certificate, or if they'll work with *any* valid SSL certificate.
According to their WHOIS, "Record last updated 11-24-2010 06:49:51 PM" (unknown timezone), which probably correlates with 1h10 after 00:40 CET as mentioned in Secunia's announcement. So, I'm guessing someone obtained access to their domain registrar account and directed resolvers to another DNS service for a short time. The TTL of those records seems to be fixed at 2 days, so some visitors may still be affected for that period.

If the domain registrar had supported DNSSEC, that wouldn't have offered any additional security here, because the attacker's DNS zone could have carried a genuine signature.

Someone may even have been able to sign up for an email-validated SSL certificate from a trusted CA during the hijack, since the activation email (as well as Secunia's other email) may have been directed to an attacker's server. That could be a risk to customers of their PSI/CSI product.

Better be very careful with your domain registrar accounts; they're a huge vulnerability, and far too much trust seems to be put into them. I'm surprised this doesn't happen more often.

I guess this weakness in the system exists for political reasons, to allow governments or law enforcement to shut down a site via the domain registrar. The Tor network's ".onion" TLD seems like a superior design, where the domain name itself is a public key where only the operator holds the corresponding private key. It occurs to me now that a similar TLD on the 'real' Internet might be quite awesome.
Actually, in the scenario above I'd recommend the vendor just generates their own SSL CA key, ships the public counterpart with their software, and verifies SSL connections to the service use a key signed by that CA. Rather than trusting any of the major CA's out there that will issue a certificate based on little more than a verification email.

Diary Archives