Apache.org incident: started with a XSS flaw
Apache.org has suffered a targeted attack between the 5th and the 9th of April. The Apache infrastructure team wrote a comprehensive incident report that is worth reading.
I find this report interesting because it is well written, and it is a good example of a successful attack that is not too difficult to understand from a technical point of view. It outlines well that a successful attack is most of the time the result of successive exploitations of different vulnerabilities.
The exploitation of a single vulnerability is often not enough to compromise a system (this can happen though). Most of the time, it is the presence of several vulnerabilities and the smart exploitation of a combination of them that enable attackers to achieve their goals.
It's important to bear this in mind when assessing the security of system. If you use risk classification for vulnerabilities and you only look at them individually you may underestimate the risk.
Reflected XSS risk?
This attack leaded to a compromise of two servers used by the foundation (shell access, one server with root privileges), numerous passwords were stolen, a web application has been modified to steal even more passwords etc. and this wouldn't have been possible without the exploitation of the first weakness: a non-persistent (or reflected) XSS.
This type of cross-site scripting issue on web applications is very common. Because this type of XSS is non-persistent, I unfortunately still often see on security reports a level of risk Minor for this type of XSS. Obviously, a non-persistent XSS won't give you a remote root account, but as you can see on the Apache compromise, this was the first step. Without this first step the apache compromise wouldn't have been possible (at least this scenario).
Ironically, I understood that XSS vulnerability is stepping down from rank 1 to rank 2 on the new 2010 OWASP Top Ten because from now on, the team will focus more on risks that probability. This is my understanding listening to this podcast. (The 2010 OWASP Top Ten is not published yet at the time I wrote this article).
What can we learn from this incident?
In the report, the team explain, what the issues were and how they fixed them (Sections What worked?, What didn't work?, What are we changing?).
As said at the beginning of this article, this attack was not particularly sophisticated. Using XSS to steal a session cookie is a case study, brute force attack is obviously not new, improper file/folders permissions on a webserver is more than common and issues related to storage of passwords are basics as well etc.
Although some of the vulnerabilities on the hacked servers/application could have been fixed before, humans make mistakes and this is not going to change. An important issue in my opinion is that the attack was left undetected for a few days. With the current technology, the Apache team had to be alerted in real time for a least:
- Brute force attack (hundred of thousands of password combination attack cannot be left undetected)
- Change of an application administration settings (change the path to upload attachments)
- Change of an application (New JSP files, JAR file that would collect all passwords on login and save them)
It's a common mistake to focus only on preventive controls. On the report I can't read much about plans for detective controls. Even in the section "What didn't work?" and "What are we changing?" there is no mention of being alerted that something is going wrong.
Today, it is important to have pro-active monitoring on what is happening on our servers. Logs should be monitored and alerts should be raised based on some criteria/threshold, operating systems and applications configuration and program files should be monitored using integrity checking tools etc. Procedures should be in place to monitor and react based on these events. At the end of the day it's people that will take actions so their involvement in the monitoring process should not be overlooked.
Regarding technology for monitoring, many products are available, on the OpenSource side, I would definitely recommend having a look at ossec, this is a Host Based Intrusion Detection System (HIPS)
Also, it is important to mention that this kind of attack is very common and it's not possible to rely on network infrastructure security to prevent those attacks: firewalls, network Intrusion Prevention Systems etc. are likely to let the attackers in. There was no buffer overflows or usage of unauthorized network ports used in this attack for instance.
- Tinyurl and the others URL shortening websites
are used now to deceive you clicking on the link and being victim of cross-site
scripting attacks. You should be careful clicking on these links and I would
recommend using the Preview feature.
- On this attack,
once an administrator session was hijacked exploiting the XSS vulnerability,
the next steps were possible because of a badly configured web applications: it
was possible to copy JSP files to a folder that will execute them. This is an
issue I see very often: the operating system user that run the web server
should not have the right to write to a folder that execute dynamic web