UPDATE 2014-03-29: fixed broken links to the gzip’d CSV and MySQL files.
 
In EXCLUSIVE: Leaked “RSA dump” appears authentic at Risky.biz I read that on August 15th 2011 the “RSA Employee #15666” dump was posted here. I have no opinion on its authenticity. Please read the post at Risky.biz for analysis; I merely provide additional data and stats here.

The original dump contains 870 entries consisting of:

1. hostname
2. IP address

I enriched the data by adding:

3. my own lookup of the A-record for (1)
4. my own lookup of the PTR-record for (2)
5. GeoIP data for (1) = country, state, city, zip, GPS, organization
6. IP2ASN mapping for (1) = ASN, network description via whois.cymru.com

All lookups were run from an IP address in AS1103 (SURFNET-NL) on August 18th 2011 at 20:00-21:30 UTC+2. I mention the latter because the DNS/AS situation may have been deliberately changed since the dump was publicly posted (August 15th) or announced (August 18th).

Here is the enriched dump (SSL cert sig should be 01:00:00:00:00:01:1C:9E:A3:54:3F):

20110818_RSA15666_enriched.csv.gz (CSV)
20110818_RSA15666_enriched.sql.gz (MySQL dump)

Some quick stats: HERE (mirror).

DO NOT TRUST MY DATA. VERIFY IT. If the data or stats are wrong, please inform me (Twitter: @mrkoot or e-mail: koot=>uva.nl). I will change this blogpost to reflect advancing insight.

On August 4th 2011, D.J. Pangburn‘s An Open Letter to Defcon Hackers: Don’t Sell Out to the NSA turned up. Later that day, Bill Brenner wrote Hackers selling out by working for NSA? I’m not convinced. Here’s what John Young thinks of Brenner’s piece (cited from e-mail w/permission):

Completely idiotic article, quite deceptive. It omits the lifetime 
secrecy agreements required for NSA employees and that any 
whistleblowers are prosecuted if they reveal anything really 
secret. There are hundreds of court cases showing what NSA 
does to anyone who tries to leave or tells what goes on inside 
the Agency.

One does not leave NSA as if the military, one does not leave
without agreeing to never tell what goes on inside. That is a 
solemn contract agreed to before entry and an even more
serious sterilization undergone if one insists on resigning.
Severe criminal penalities are described in great detail and
you sign that you understand them without reservation.

And you are forever watched to assure you don't do what
the silly author says you can do to bring about change. He is
a lying son of a bitch, either through unwitting ignorance or 
through witting deliberate misrepresentation.

These conditions apply to all secrecy organizations. The
periodic disclosures by ex-members are not to be believed,
they make the not terribly revealing disclosures as a 
continuing part of their job through whistleblowing, novels,
movies, confessions, and the like.

You cannot escape, this is what was taught in the ancient
days of one-way-in, no-way-out secret societies and remains 
true today. Recruiters are devious as they must be or nobody
would join the secretkeepers if they knew the truth of what was
in store for them to give up control of their lives and minds 
forever, and remain compelled to lie, lie and lie some more,
and, to be sure, recruit noobs by writing noobish nonsense.

John 

Now, how is one to decide where to draw the line between realistic concern and paranoia?

UPDATE 2011-10-19: files containing raw data have been taken offline.

To shed a broader light on the state of DNS zone transfer configuration, I sent AXFR requests for 1063954 domains (zones) collected from the Google Trends sitemaps.

Results:

• 151684 out of 1063954 zones (14%) were AXFRable via
• 51407 out of 223619 nameservers (23%), in
• 210 out of 250 TLDs, yielding
• 26 million DNS records.

Here (.html) is a table w/breakdown per TLD.

Why bother about AXFR? DNS zones can contain information that is useful during reconnaissance activities. Needlessly giving away partial blueprints of IT infrastructure by permitting AXFR is probably a bad idea. US DoD DISA also recognizes lack of zone transfer limiting in the BIND section as a topic in its DNS Security Checklist v4r1.12 (.zip):

Group ID (Vulid): V-4483
Group Title: Zone master server does not limit zone transfers.
Rule ID: SV-4483r7_rule
Severity: CAT II
Rule Version (STIG-ID): DNS0460
Rule Title: A zone master server does not limit zone transfers to a list of active slave name servers authoritative for that zone.

Vulnerability Discussion: The risk to the master in this situation, is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone. To protect against this possibility, the master must first have knowledge of what machines are authorized slaves.

(…)

Fix Text: The DNS software administrator should configure each zone master server to limit zone transfers to a list of active slaves authoritative for that zone. Configuration details may be found in the DNS STIG Section 4.2.8.  

(I don’t know whether that checklist is applied to all .mil domains; AXFR was allowed in 3 out of 59 .mil cases – centcom.mil, dma.mil and dodlive.mil. For .gov, AXFR was allowed in 104 out of 984 cases. Presumably, DNS zone information that does not need to be publicly known may in some cases qualify as Sensitive But Unclassified — a category of information that the DoD recently proposed a new safeguarding rule for.)

UPDATE 2011-06-15: this issue has been added as bug #1124 on the Diaspora Issue Tracker. If fixed, I will remove the .txt.gz file containing (only) the names of Diaspora users. It has then served its purpose of eliciting a potential gap between an expectation of privacy (e.g. “my name should not be shown to Diaspora-members I don’t know”) and actual privacy (e.g. “my name is shown to any Diaspora-member”).

Here is the list of all ~55k users of the Diaspora social network at JoinDiaspora.com, retrieved without committing cybercrime: 20110610_diasporaUsersOn20110329-csv.txt.gz

Why publish it here? For the same reason as collecting 35M Google Profiles and blogging about it. Like any social network, Diaspora (software for decentralized social networking) too is designed to hand out this kind of information. In this particular case, I believe demonstrating what can be gathered by unknown third parties (like me) with hardly any effort will, in the end, do more good than bad. But I do understand objections — I encourage you to explain them in comments below; I will be happy to read them and respond if applicable.

In this case, two minor privacy invasions(*) might occur:

1. Given a known real or fictitious person name, ‘reveal’ (hint at) a login/username;
2. Given a known login/username, ‘reveal’ (hint at) a real or fictitious person name;
3. Given either, ‘reveal’ (hint at) X being a user of the Diaspora network at JoinDiaspora.com.

Some thoughts on social media in general:

1. Do users really ‘know’/expect that their data can and probably will be collected by unknown third parties, companies, govts, outside their control?
2. Do users really ‘know’/expect that all data of the network can and probably will be collected by unknown third parties, companies, govts, outside their control? (The ‘network effect‘ also holds true for copies of social network data. A network that is easy to harvest completely is more likely to be harvested completely, and will be a more attractive ‘starting point’ for, e.g., filtering out interesting targets than networks that are difficult to harvest.)
3. Do users have sufficient risk assessment skills and information to decide what chance x impact to associate with their personal data and communication being copied into rogue databases outside their control?
   

Although social media providers can enforce restrictions at their servers –e.g. only allow search by name, only allow 1000 queries per day from the same IP address–, searching, matching and linking is completely unrestricted to unknown third parties once they gathered a rogue copy of the data. The data can be collected slowly, over a longer period of time and from varying IP addresses/ranges, ‘staying under the radar’ of monitoring and restricting measures. In this particular case there is no ‘real’ problem and publishing the data is mostly harmless; otherwise I wouldn’t have. To repeat from my blogpost about Google Profiles: my activities are directed at inciting, or poking up, debate about privacy.

Mind you, I’m a happy Diaspora user myself and support the work of the developers. They’re doing good work!

(*) Whether or not these would be perceived as a privacy invasion depends on each of the 55k individual users – because in the end, privacy is an individual experience.