We are now releasing videos of our sessions at this year’s CERIAS Symposium from late March.
We had a fascinating session with David Medine, chair of the PCLOB discussing privacy and government surveillance with Mark Rasch, currently the CPO for SAIC. If you are interested in the issues of security, counterterrorism, privacy, and/or government surveillance, you will probably find this interesting:
We are also making available videos of some of our other speakers — Amy Hess, Exec. Deputy Director of the FBI; George Kurtz, President & CEO of CrowdStrike; Josh Corman, CTO of Sonatype; and two of our other panel sessions: http://www.cerias.purdue.edu/site/symposium_video/
(You have to put up with my introductions of the speakers, but into every life a little rain must fall.)
That was the 15th Annual CERIAS Symposium. Planning for the 16th Symposium is underway for March 24 & 25, 2015: http://www.cerias.purdue.edu/site/symposium2015
A few weeks ago, I wrote a post entitled “Patching Is Not Security.” Among other elements, I described a bug in some Linksys routers that was not patched and was supporting the Moon worm.
Today, I received word that the same unpatched flaw in the router is being used to support DDOS attacks. These are not likely to be seen by the owners/operators of the routers because all the traffic involved is external to their networks — it is outbound from the router and is therefore “invisible” to most tools. About all they might see is some slowdown in their connectivity.
Here’s some of the details, courtesy of Brett Glass, the ISP operator who originally found the worm on some customer routers; I have replaced hostnames with VICTIM and ROUTER in his account:
Today, a user reported a slow connection and we tapped in with a packet sniffer to investigate. The user had a public, static IP on a Linksys E1000, with remote administration enabled on TCP port 8080. The router was directing SYN floods against several targets on the Telus network in Canada. For example:
10:00:44.544036 IP ROUTER.3070 > VICTIM.8080: Flags [S],
seq 3182338706, win 5680, options [mss 1420,sackOK,TS val 44990601 ecr 0,nop,scale 0], length 0
10:00:44.573042 IP ROUTER.3071 > VICTIM.8080: Flags [S],
seq 3180615688, win 5680, options [mss 1420,sackOK,TS val 44990603 ecr 0,nop,scale 0], length 0
10:00:44.575908 IP ROUTER.3077 > VICTIM.8080: Flags [S], se
q 3185404669, win 5680, options [mss 1420,sackOK,TS val 44990604 ecr 0,nop,scale 0], length 0
10:00:44.693528 IP ROUTER.3072 > VICTIM.8080: Flags [S],
seq 3188188011, win 5680, options [mss 1420,sackOK,TS val 44990616 ecr 0,nop,scale 0], length 0
10:00:44.713312 IP v ROUTER.3073 > VICTIM.http: Flags [S],
seq 3174550053, win 5680, options [mss 1420,sackOK,TS val 44990618 ecr 0,nop,scale 0], length 0
10:00:45.544854 IP ROUTER.3078 > VICTIM.http: Flags [S],
seq 3192591720, win 5680, options [mss 1420,sackOK,TS val 44990701 ecr 0,nop,scale 0], length 0
10:00:45.564454 IP ROUTER.3079 > VICTIM.http: Flags [S],
seq 3183453748, win 5680, options [mss 1420,sackOK,TS val 44990703 ecr 0,nop,scale 0], length 0
10:00:45.694227 IP ROUTER.3080 > VICTIM.http: Flags [S],
seq 3189966250, win 5680, options [mss 1420,sackOK,TS val 44990716 ecr 0,nop,scale 0], length 0
10:00:45.725956 IP ROUTER.3081 > VICTIM.8080: Flags [S], se
q 3184379372, win 5680, options [mss 1420,sackOK,TS val 44990719 ecr 0,nop,scale 0], length 0
10:00:45.983883 IP ROUTER.3074 > VICTIM.8080: Flags [S],
seq 3186948470, win 5680, options [mss 1420,sackOK,TS val 44990745 ecr 0,nop,scale 0], length 0
10:00:46.985034 IP ROUTER.3082 > VICTIM.http: Flags [S],
seq 3194003065, win 5680, options [mss 1420,sackOK,TS val 44990845 ecr 0,nop,scale 0], length 0
In short, the vulnerability used by the "Moon" worm is no longer being used just to experiment; it's being used to enlist routers in botnets and actively attack targets.
One interesting thing we found about this most recent exploit is that the DNS settings on the routers were permanently changed. The router was set to use domain name servers at the addresses
The "Moon" worm was completely ephemeral and did not change the contents of flash memory (either the configuration or the firmware). The exploit I found today changes at least the DNS settings.
Shame on Belkin for dragging their feet on getting a fix out to the public. But more to the point, this is yet another example why relying on patching to provide security is fundamentally a Bad Thing.
Over the past couple of months I’ve been giving an evolving talk on why we don’t yet have secure systems, despite over 50 years of work in the field. I first gave this at an NSF futures workshop, and will give it a few more times this summer and fall.
As I was last reviewing my notes, it occurred to me that many of the themes I’ve spoken about have been included in past posts here in the blog, and are things I’ve been talking about for nearly my entire career. It’s disappointing how little progress I’ve seen on so many fronts. The products on the market, and the “experts” who get paid big salaries to be corporate and government advisors and who get the excessive press coverage, also serve to depress.
My current thinking is to write a series of blog posts to summarize my thinking on this general topic. I’m not sure how many I’ll write, but I have a list of probable topics already in mind. They break out roughly into (in approximate order of presentation):
Each of these will be of moderate length, with some references and links to material to read. If you’re interested in a preview, I recommend looking at some of my recent talks archived on YouTube, some of my past blog posts here, and oral histories of various pioneers in the field of infosec done by the Babbage Institute (including, perhaps, my own).
I’ll start with the first posting sometime in the next few days, after I get a little more caught up from my vacation. But I thought I’d make this post, first, to solicit feedback on ideas that people might like me to add to the list.
My first post will be about the definition of security — and why part of the problem is that we can’t very well fix something that we can’t reliably define and thus obviously don’t completely understand.