Anonymous domainnames
In the past we've pointed readers in private email and publicly to use whois to find out who's behind domainnames and IP addresses.
Over the years we've seen the whois system deteriorate for domainnames with -paid for- anonymous registrations, with systems that point you to website where you have to interact with the website instead of continuing on the command line, with results that come back as gifs instead of text etc.
But today I was dealing with a .name registration that's likely up to no good, but on the odd chance there was a real company behind it I checked it out in whois:
$ whois [suppressed].name
Disclaimer: [skipping the legalese]
This is the .name Tiered Access Whois. For help, query whois with the
string "help". A whois web service also exists on http://www.whois.name.
A full list of .name Registrars can be found on http://www.nic.name
--------
Domain Name ID: 2899351DOMAIN-NAME
Domain Name: [suppressed].NAME
Domain Status: ok
Ok, nothing of use here, it's basicaly a "see http://www.whois.name/"
On to that website, - it's actually a redirect to https://whois.nic.name/ :
You basically have 3 options:
- the "summary search": equally useless as the whois interface itself
- the "standard search": ah yes, that must give what we need! Let's try it:
Domain Name ID: 2899351DOMAIN-NAME
No such luck apparently.
Domain Name: [suppressed].NAME
Sponsoring Registrar ID: 21
REGISTRAR-NAME Sponsoring Registrar: Directi Internet Solutions d/b/a PublicDomainRegistry.Com
Domain Status: ok
Registrant ID: 2314764
CONTACT-NAME Admin ID: 2314764
CONTACT-NAME Tech ID: 2314764
CONTACT-NAME Billing ID: 2314764
CONTACT-NAME Name Server ID: 1306740
HOST-NAME Name Server: NS1.[suppressed].NAME
Name Server ID: 1306741
HOST-NAME Name Server: NS2.[suppressed].NAME
Created On: 2007-04-25T07:58:33Z
Expires On: 2008-04-25T07:58:33Z
Updated On: 2007-06-25T02:25:20Z
It seems they lowered their standard quite a bit. - There's a third option: "For detailed Whois searches, which are subject to higher privacy protection than Summary and Standard". Now, that sounds like what we need.
Unfortunately, higher privacy protection seems to not apply to those who seek the information at all. They insist on having not just the obligatory hurdle of a CAPTCHA (without escape for the visually impaired), but it almost looks like a typical phishing website as they also want all your private data, including your credit card number.
Yes, you got it: ".name" wants to charge you for knowing who registered what domainname!
I guess I need to say thanks to those who created and run .name for this "wonderful" scheme. I'm sure those up to no good will love you for it.
Before we get flooded by reactions: I can be sympathetic to privacy, but if you have something to say (email, web, ... something that needs a domainname) I want to have the right to know who you are and I want those giving you the domainname to verify you are who you are before letting you have the domainname. If you cannot safely say what you want to say unless you are anonymous: don't get a domainname, there's plenty of services out there to get a message across without your very own domainname.
--
Swa Frantzen -- NET2S
virtualization and security
In the grand scheme of things -think the matrix- the question might not be "to be or not to be", but instead evolve to "to be real or not to be real"
Let's look at the evolutions:
- Malware researchers (as in reverse engineering) tend to use products like VMware to allow them to run malware in a more controlled environment where they also can undo having run it easier (on a to be discarded copy of the image)
- Malware authors more often than not detect VMware and have their malware not give away what it would do on a real machine
- Joanna Rutkowska "Blue Pill" research most likely deserves a mention in here just as well.
- Last month Microsoft fixed in MS07-049 a thread they classified as important that allowed a break out of the virtual OS to the host OS. We had some disagreement on that rating with Microsoft as we saw it as a significant bigger deal than "just" privilege escalation.
- This week VMware released updates that fix a number of vulnerabilities. They've announced the details on a mailing list, but on their own website all seems to be much more rainbows and butterflies unless you dig through some of the release notes (search for "security"): E.g. (there is one for every product):
- http://www.vmware.com/support/ws6/doc/releasenotes_ws6.html
- http://www.vmware.com/support/server/doc/releasenotes_server.html
It fixes quite a few vulnerabilities:
CVE-2007-2446 CVE-2007-2447 CVE-2007-0494 CVE-2007-2442 CVE-2007-2443 CVE-2007-2798 CVE-2007-0061 CVE-2007-0062 CVE-2007-0063 CVE-2007-4059 CVE-2007-4155 CVE-2007-4496 CVE-2007-4497 CVE-2007-1856 CVE-2006-1174 CVE-2006-4600 CVE-2004-0813 CVE-2007-1716 CVE-2006-3619 CVE-2006-4146
Some of these are fixes propagating from DHCP, cron, samba etc, nothing special as such except that they've been around for a while now -with fully documenting source code patches-.
The more spectacular vulnerabilities are:- CVE-2007-4496 A privileged user in a guest OS can execute arbitrary code on the host OS
- CVE-2007-4497 A user on the guest OS can cause a DoS not just on the host OS (and on the guest OS)
- There is also a paper by Google that studied some aspects for multiple vendors in the virtualization world: http://taviso.decsystem.org/virtsec.pdf While two product names are obscured they'll be easy enough to guess for those knowing the platforms they are used on. Ever since Apple moved to Intel CPUs Parallels has been popular on that platform (I use it myself), and we already mentioned Virtual PC from Microsoft above.
Now with all that, how do we react ?
It all depends what you use it for. E.g. I use parallels on my Mac to be able to run windows applications on my mac when (and if) I need it. When teaching about security I run a virtual machine that has known vulnerabilities to demo how easy it is for real attackers to attack a system and how little skill it requires to execute a program that gives you a command prompt on a target. If that is what you run a virtualization suite for, you're not more or less at risk than you were before.
If I'm a malware researcher, I'd be extra careful not to trust the malware to break out of the virtual machine, they already detect it, what could be more delaying in the analysis of their contraption than to zap the host OS ?
If I were to feel my host OS was immune to attack (fanboys to /dev/null please) due to the more targeted OS being in a virtual machine I might be in for a rude awakening down the line as those attacks might start to build in things to break out of their segregated environment. Having that false sense of security is a really bad thing.
If I buy less separated machines but instead buy more redundant hardware that's more powerful and run machines together on a shared hardware platform, I'd watch carefully what I'm putting together. It would be a bad idea to put e.g. the firewall, an IDS probe outside of the perimeter and the web server and database server all on one shared platform as if one if broken, all can be broken without going through the layers separated hardware would have provided. Even if all the hosts are from a same security layer there's increased risk as the machines can talk among themselves without passing through the network layer but that's probably easier to mitigate. So it does depend on your architecture and what you mix together.
If I'm a organization that has air-gapped networks that carry differently classified data on, it would be a very risky move to migrate those two hosts on those who need access to both networks onto a virtual machine setup. Better invest in that KVM switch if you need the real estate on those desks.
--
Swa Frantzen -- NET2S
Comments