An Analysis of the Analysis of the Apache.org Attack
Over at the Apache blog, you’ll find a nice and detailed incident report on the recent, successful attack on Apache.org. I thought it might be worth a few minutes to share my thoughts on their write-up.
First, I would like to say that the level of transparency in this response is truly commendable. Rather than sweep this under the rug, they have chosen to share the details of what happened, why it happened (more on that in a moment) and what their plans are to, hopefully, prevent future breaches.
I encourage you to read the entire post, because it is a good account of how actual, real-world attacks happen. Targeted attacks take advantage of trust (both in people and machines), shared and weak passwords, too much privilege and an assortment of other security 101 vulnerabilities.
The attacks consisted of a XSS vulnerability, brute-force logins, a shortened URL, password sniffing, password re-use and social engineering. Pretty typical stuff, really.
What I find most interesting about this report is the emphasis on technical countermeasures in the What are we Changing? section, when the attack succeeded primarily due to vulnerabilities in human beings.
- The Infrastructure Team members clicked on a cloaked and untrusted link, which launched a XSS attack.
- A brute force login succeeded against a poorly chosen password. But prior to it being successful, no one seemed to be getting alerts on so many failed login attempts.
- They once again exploited the Infrastructure Team by getting them to log in with a password that the team members, themselves, did not choose.
- They took advantage of cached passwords on the server.
- Slicehost didn’t respond to the attack when notified, which enabled one host to continue its attack against someone else.
These are all people issues. It’s the same stuff that we security types have been trying to hammer into the brains of people for years now. There are certainly technical countermeasures which could have helped, but this was an attack on people.
It’s easy for us to play armchair quarterback and be critical of the response, however that is not my intention, Rather, it is my intent to simply cast another light on the response so we can all learn and secure our assets more effectively.
The focus is on technology, because that is what you can change and enforce with rules.
For the ASF, our infrastructure team is made up of dozens of individuals, many of whom we have never met in person (though, a fair number of the root@ members have met), but our goal is to still be accessible to new blood — because we are a volunteer group.
We could make more social changes, but the truth is they would be forgotten by the ‘next generation’ of volunteers. Our best bet is to increase the technology standards for security we use, because the people we have change all the time, and most of all, they are volunteers, and therefore lazy.
Thanks for you point,
Paul
Paul,
Thanks for stopping by and commenting. I appreciate all constructive comments.
I understand the nature of open source development and how dynamic it is. I also understand how many open source people seem to understand and appreciate technical countermeasures. I, myself, tend to be a technologist.
At the same time, I feel like we have yet to master the security 101 stuff that we have been told and have been teaching others for many years now. It’s rare that targeted attacks don’t take advantage of vulnerabilities in people, precisely because it is so effective.
I also don’t think a development model which includes volunteers and an agile, open source type of iterative process necessarily precludes user awareness training. There are many forms this can take. It could be as simple as an awareness e-mail when people join the team, with periodic reminders. It could be something more formal like established policies and procedures which define how information is handled.
If someone can be persuaded to take an action, such as was the case in several instances here, there’s not a whole lot that technology can do. The attacker will simply design an attack around the countermeasures. People are choosing poor passwords? Enforce key authentication. Then what happens? They don’t protect their key with a passphrase.
I think it’s clear that Apache has some valuable assets. Even though it is open source, the reputation alone is worth a lot. So if there are measures that can be put in place commensurate with the threat, I think all options need to be explored.
Some day we’ll design countermeasures that work with the way people do, not against their trusting nature, and they will still be effective. But we’re not there yet, so in the mean time I think we need a more holistic approach.