The Security Skeptic

Facebook offers a ton of mindless distractions, from quizzes to surveys, fan pages to communities of interest. After seeing a long time IETF friend's result from taking the quiz "Which IETF RFC are YOU?" I could not resist taking the test myself.

The test purports to be "proven by scientists (and verified with supercomputer simulation) to accurately classify any human being to a single, conclusive IETF RFC". Nice, but slightly unnerving. I had nightmarish moments while answering the questions. Will I be one of the RFCs I wrote? Would I be an RFC affiliated with a technology I abhor (WHOIS/RFC954, IP over ATM/RFC1932, SMTP on X.25/RFC1086) or something classic (Telnet/RFC097, QOTD/RFC865, NTP/RFC1129)? Worst case scenario: would I be a MIB?

Happily, my result was RFC 791, Internet Protocol! My answers identify me as " a solid, dependable person, and more consistent than your peers. You value time-honored things in life and prefer standards over the latest fad. If you were an ice cream flavor, you would be vanilla: natural, elegant, and classic". YAY! How wonderful to be associated with IP and by extension, its revered author, Jon Postel.

And how grateful am I that my result did not associate me with IPv6, RFC 2460:-)

Archived at http://www.securityskeptic.com/arc20090601.htm#BlogID734 by Dave Piscitello  

I finally created a Facebook account, but not for any of the conventional reasons folks join social networks.

I worry about impersonation and reputational harm.

Perhaps I'm too long in the security business, but I began to consider how easy it would be for someone with malicious intent to create a social networking account for a targeted identity. For folks who have considerable online "visibility", this isn't really that difficult. Let's assume I'm targeted. All a miscreant needs is an email account to which the membership confirmation email for Dave Piscitello is sent. Once he confirms the account, he can populate the newly created account with personal information he gathers from other sources: my personal page at SecuritySkeptic.com, bios at Core Competence. ICANN, and conferences where I've given presentations, etc. provide enough information for a convincing deception, especially if the deception targets colleagues over family. Next, the miscreant begins building a social network. Since social network sites constantly suggest friends to add, this is trivial. As the miscreant grows a friends list, he can use my Facebook wall or the walls of my colleagues, family and friends to post abusive, insulting or libelous comments, lies or misinformation. He can intimate that I'm unhappy with my employer, my wife or children. He can post photos that might be embarrassing, or for a truly worst case scenario, use the account for predatory or porn publishing purposes.

It's quite likely that someone who really knows me will undoubtedly contact me using one of my legitimate email accounts or phone numbers to read me the riot act or fire me. At this point, however, my Facebook situation is no different from any web defacement attack. I've been victimized and I'll have to take action to recover from the incident. I've got to contact the social network operator, provide compelling evidence of the impersonation, and get the page removed. And like all defacement attacks, my reputation is tarnished. Not a pretty picture, is it?

There are too many social networks to join purely for defensive purposes. Perhaps having *one* that is truly mine is somewhat comforting. At the very least, perhaps I will create a social network identity that is sufficiently mine to repudiate claims that an impostor might make on other sites. Or perhaps I should open a chocolate cafe near a local Starbucks and get out of this business before the paranoids come to get me.

Archived at http://www.securityskeptic.com/arc20090601.htm#BlogID733 by Dave Piscitello  

When you register a domain name, you typically identify a name server that will host the DNS information for that domain (the zone file).A best common practice recommends that you identify that name server using a name from another domain (also called an out of bailiwick assignment since the name is not in your "bailiwick", e.g., your zone). Let's look at an example.

Imagine that I have registered domains example.NET and example2.INFO, and have identified NS1.example.INFO and NS2.example.INFO as the name servers for example.NET. In the NET zone file we find the name server (NS) and A records (also called glue) for example.NET, as follows:

example.NET NS ns1.example2.NET
example.NET NS ns2.example2.NET
.
.
.
ns1.example2.NET A 10.0.1.53
ns2.example2.NET A 10.0.2.53

Somewhere in the INFO zone file you'll find my name servers for example.NET, e.g.,

example2.NET NS ns1.example2.INFO
Example2.NET NS ns2.example2.INFO

Now, let's suppose example2.INFO is removed from the INFO registry. Assuming I registered example2.INFO, this might occur if I had failed to renew my registration for example2.INFO. It might also occur if the domain was suspended because it had been associated with malicious activity (hold this thought). Irrespective of the reason, the INFO registry operator removes example2.INFO. The NET registry operator, however, won't remove the NS records. Unilaterally removing glue records might interrupt name service for any other domain that also used ns1.example2.INFO or ns2.example2.INFO to host zone files (this is pretty common). In cases like my example, where the domains involved are not in the same top level domain, the registry operators don't know unless they are notified by the registrant(s) involved in the zone change. We now have an orphaned name server, i.e., the name server record exists in NET but the parent domain name no longer exists in INFO. NET will return name server information for example.NET, and the physical host will continue to serve up records from the example.NET zone file.

Let's go back to that thought I asked you to hold. Imagine that a bad actor registers a bunch of phish domains in NET, and hosts them at an orphaned name server in INFO. Now imagine that the parent domain is removed in the same manner as my example, as a result of a suspension action by a registrar. The orphaned name server is now a dark corner from which other phishing domains can operate name service.

The preliminary results of an APWG study of the prevalence of this form of DNS abuse by Internet Identity and Karmasphere indicates that there is a correlation between malicious domains and orphaned name servers. I'll link the report when it's published. Meanwhile, don't orphan your name servers, and if you find an orphan, report it!

N.B. I gave a presentation on this subject at the Sydney ICANN meeting.

Archived at http://www.securityskeptic.com/arc20090601.htm#BlogID732 by Dave Piscitello