November 2, 2013 is the 25th anniversary of the Morris Worm. In the intervening years, we have not solved the problems of buffer overflows, reusable single-factor credentials, peer-to-peer trust or password reuse.

What then have we learned from this incident?

1. Access to some files should be restricted.

No more world-readable password files. Shadow files in Unix and Unix-like OS’s and restricted access to the SAM in Windows, however password stealing and cracking are still big in the attacker community, so we never really solved the problem.

2. Sharing malicious code analysis and samples with trusted peers is a good thing[tm.]

When big malicious code events happen, the usual defenders will share their analysis. This helps them to bring mitigations to bear sooner, and it’s a good thing. As we see more and more custom malicious code though, will this process be extended downwards, or will we simply see less cooperation on the side of the defense?

3. Logs are useful for responding to incidents.

Log retention and analysis still is a mostly post-incident activity for most organizations. Many forward-thinking organizations are doing real-time or near-real-time analysis and Log-Based Intrusion Detection Systems (LIDS) have evolved to provide primary incident response initiation data.

4. Homogenous systems are prone to mass infection.

No matter if it’s homogenous services, or homogenous operating systems, if there’s a vector for compromise that’s common, then its exploitation will affect all of those things in your organization and any organization you share an exploitation vector with.

5. Systems not developed with security in mind are open to attack.

Sure, it’s blindingly obvious but even though we have a fair number of “secure” systems available today, the administrative overhead of enabling security features tends to make the advice “disable $security_feature” the first step of deployment for any complex package on many of those systems, such as Linux distributions which enable SELinux by default.

I think it’s safe to say that though we may have learned many lessons from the Morris Worm in 1986, we haven’t systematically applied any real long-term solutions to the problems it uncovered.

======
Source material
http://www.thehackademy.net/madchat/vxdevl/avtech/A%20Tour%20of%20the%20Worm.pdf
http://spaf.cerias.purdue.edu/tech-reps/823.pdf
http://www.snowplow.org/tom/worm/lessons.html

Leave a Reply