Deluvian Scanning Platform -- DoxPara Infrastructure Validation Project (DIVP)
Presently analyzing: Misc. Services
Primary Contact: Dan Kaminsky, DoxPara Research, +1-408-933-8195
Details on DNS Scans (12-Apr-2008) Small DNS check, just looking into some of Amit Klein's work. Should only be hitting known DNS servers.
Details on NTP Scans (29-Sep-2007)
Checking clock variability across Internet.
Details on DNS Scans (15-Apr-2007) Microsoft DNS RPC issues.
Details on Misc Service Scans (02-Apr-2007)
More global estimates, doing longitudinal comparison against older data (DNS, SSH, etc.) Contact me for further details.
Details on LDAP Scans (14-Sep-2006) Collecting a global estimate on publicly hosted LDAP servers. As always, ping for details.
Details on SSL Scans (01-Aug-2006) New SSL scans. Things seem to have changed since the last sweep. Reconstructing new data to compare. As always, call if there's a problem.
Details on SSL Scans (12-Dec-2005) I'm looking into a potential issue with some SSL servers. This is under disclosure, but I'm measuring (obviously, not through exploitation) potential impact. US-CERT has been notified in advance.
Details on maddns.net scans (27-Nov-2005)
Slowly but surely, I'm detangling the actual topology of the worldwide DNS. Normally, we think of DNS servers as connecting directly to the root servers to service requests. In actuality, the situation is rather more complicated, with complex pre-set forwarding relationships set up between tiers of servers. The maddns.net traffic you may be seeing looks for differences between the IP I make a request to, versus the IP that comes back to me to service that request. This first level approximation of DNS graph complexity will then be routed through some of the more accurate but slower mechanisms discussed here.
Details on new DNS scans (25-Oct-2005) Mike is checking up on ancillary services that are accompanying name servers, while I am seeing if anything has been fixed since the previous round of scans. Here are details on ports that will be checked:
- TCP management port information - TCP/179 (BGP) - TCP/21 (FTP) - TCP/22 (22) - TCP/23 (telnet) - TCP/80 (http) - TCP/6681 (bittorrent) - TCP/6969 (bittorrent)New FPDNS runs will be sourced from this IP, as will banner scans of TCP/80, TCP/22, and TCP/21. A larger set of IP's will be scanned in this run as well. As always, feel free to call at any time with questions about what you're seeing.
Details on emergency Port 1117 Scan (16-Aug-2005) The worm, Zotob.d, has taken out some fairly high profile resources (CNN, ABC, Capitol Hill). This scan is intended to detect infected nodes.
Details on emergency Port 445 Scan (14-Aug-2005)
Significant vulnerabilities against Windows 2000 and, to a much lesser extent, Windows XP SP1 have been detected and exploited in the wild. In response to the Internet Storm Center's rating of these vulnerabilities as a yellow alert, I am attempting to identify all vulnerable nodes on the Internet. The goal is notification, not exploitation, with a secondary goal being measuring the change over time. As always, I can be contacted at 1-408-933-8195 if there are any questions regarding these packets. Or just email me.
(In case you're wondering -- no, I'm not going to either exploit or patch hosts with a detected fault. I am going to interrogate hosts w/ 445 open, though.)
Details on DNS scan:
Hello, My apologies if I've caused you any concern. My name is Dan Kaminsky, and I'm a security researcher specializing in both massive-scale network security research as well as issues specific to the stability of the DNS. Recently, there was a major attack against the DNS infrastructure: Taking advantage of chaining between Microsoft's name server and an older version of BIND, unexpectedly large portions of the net were returning invalid results for sites as common as Google. It is my sense that problems of this nature are only going to get worse, and of course, one cannot manage a problem one cannot measure. So I've set out to measure, on a massive scale, the precise topology of the DNS. The existence of automated scan detectors belies that fact that those with malice are doing similar scans; we cannot defend against those with better reconnaissance than us! I will be reporting on the results of this research at the Black Hat Briefings security conference in Las Vegas at the end of the month. It will be my fifth year speaking.
Please let me know if you have any questions, and feel free to call me at: +1-408-933-8195. Thanks!
P.S. I would appreciate any related network blocks be lifted. Accurate data is important to any research operation.
P.P.S. On request, here's some useful further info identifying myself and what I'm doing. I compliment those who are asking questions, and hope these provide sufficient answers. The following information is provided so as to provide credibility to the claim that this is a legitimate research operation by a credible member of the security community.
DNS servers are being checked for neighboring services, such as SSH and HTTP. If you're wondering why you're receiving traffic on these ports -- you had a name server on that IP at one point. I have logs, and can provide on request.
(A few more details -- I can't fully document everything yet, but I can say more about what I'm looking for.)
More details, for engineers:
DNS is a gigantic cooperative caching system, very unique in functioning to (for example) the web. We depend on third party servers, as a matter of course, to distribute accurate information. I had thought, this time last year, that DNS poisoning was dead, and that the only real risk left in DNS was tunneling into and out of heavily firewalled networks.
I was wrong. Some astonishingly nasty poisoning attacks have been quietly, and not so quietly occuring. Though maybe in the future DNSSec may become a real force in how we authenticate the flow of name routing data; for now, it's practically nonexistent. Worse, if the infrastructure controlling these routes is left simultaneously hosting other, less secure services -- it doesn't matter how well protected the name daemon is, as weaknesses elsewhere will allow subterfuge.
We at least need to know how bad this problem is. Without measurement, there can be no management. As a legitimate member of the security community, I've asked Prolexic -- a company who's no stranger to suffering malicious activity -- to assist with a massive scale defensive operation to determine simply what is out there. We cannot allocate resources without valid data, and the nature of what I've found thus far has been...astonishing. I am aware that some of the packet traces appear as potential precursors to malicious activity. I assure you; I would not make it so easy to find me if I intended any harm. Similar data to this can be (and likely has been) extracted via large networks of penetrated hosts -- so called botnets -- on the scale of hundreds of thousands. As a legitimate researcher, I cannot break into hundreds of thousands of hosts to "protect the Internet". I can, however, receive your letter, and hope to put your mind at ease.
Please let me know if you have any further questions. I will be making a full, public report (obviously with IP address information scrubbed) soon.
Contact info: dan@doxpara.com
--Dan Kaminsky