The Cyber Risk Report this week contained a short mention of the attacks against the Apache Software Foundation (ASF). These attacks were documented last week in fantastic detail by Philip M. Gollucci of the ASF. The attackers used a previously undisclosed cross-site scripting vulnerability and password brute forcing to gain initial access to the ASF systems. They then used additional attacks to learn user credentials, browse file systems, and access other computers. The level of openness demonstrated last week is not a first for the ASF; in May 2001 and in August 2009 they published similar reports in response to security incidents.
When reading the ASF report several things came to mind. For example, “wow, if they only did…” or “people always say that is not a big deal…” Well, hindsight is always 20/20 and, in this case, it was a relatively big deal.
There was a somewhat lively debate among my teammates about the ASF blog post. Nobody disagreed that it provided a great window through which to examine a real world attack. But of course, there were many opinions presented as to what the key takeaways for organizations should be. I have listed some of these takeaways below.
- The trust placed in software vendors is tremendous: First off, there was absolutely zero indication that any packages were modified in the recent ASF incident. However, for some of us, our minds immediately jump to the prospect of an attacker modifying source code or binary packages that are ultimately distributed to users. The risks in these scenarios are not to be overlooked. Are the checks and balances within a software vendor or open source project strong enough to detect malicious modification, whether intentional or otherwise? And after how much time has passed? For mature vendors and projects the “answer” is most likely and probably pretty quickly. For less mature organizations, I am significantly less confident. Even malicious modification of less frequently used components of widely used software might remain undetected, as was the case with the Vietnamese language pack for Firefox which contained malicious code for two months before being noticed. The precautions Shiva mentioned recently in the context of add-on software could certainly be expanded to any form of software we use.
- Despite what some will say cross-site scripting can be a big deal: Many people will downplay the threat of cross-site scripting (XSS) attacks, perhaps because XSS and Cross-site Request Forgery are artifacts of the World Wide Web and we long for “real attacks” like buffer overflows and DNS cache poisoning. However, the attacks against the ASF show that XSS can have a real security impact, especially in the hands of a determined adversary. The next time you are evaluating your exposure to a new XSS vulnerability, you would be well served to keep this scenario in mind.
- URL shortening services can fool even the most knowledgeable users: The disguising of URLs using a URL shortening service such as Bit.ly and TinyURL.com can indeed lead knowledgeable users to badness. We would all probably think twice before opening a shortened URL in an unsolicited email or instant message; let us at least hope so. However, would we exhibit the same hesitation when presented with a URL inside a tool that we use frequently, where shortened URLs are common? I suspect that many of us would have followed the same shortened link that caught the ASF administrators.
- Reusing passwords is bad: This is not a new thought. Security experts have been saying for a long time that we users shouldn’t be reusing passwords between systems or applications. That we shouldn’t for example use the same password on Facebook as for our email. What is interesting in this instance is that the reuse of passwords described as aiding attackers was between applications and systems entirely within one organization. Given years of effort within enterprises to promote unified authentication architectures for their users, where does this leave us? In the “What are we changing?” section of their write-up the ASF lists plans to deploy one time passwords for all super-users. How would you marry the apparently competing objectives of unified authentication and no password reuse within your organization?
- Log monitoring is good: According to the ASF blog posting the attackers used both a XSS attack and password brute forcing “attempting hundreds of thousands of password combinations” to gain initial access. If the login process that was targeted by the attackers was instrumented with sufficient logging, and that logging was actively monitored, could that portion of the attack have been defeated? Most likely, but then again, it is easy for us to say.
In my opinion the ASF attacks from earlier this month bring up many important topics for discussion. Do you see other items mentioned in the report that you feel are important for organizations to think about? Let me know!