NYC InfraGard Capture The Flag Event
On July 21-22, 2009 Renaud and I attended the New York City Infragard CTF event. It was a great experience being able to participate in the games, learn and teach people about security. Below is a breakdown of how the event was organized, including several examples of attack and defense techniques we performed.
Day 1 - The Game
The game is divided into two areas; one for attackers ("Red Cell") and one for defenders ("Blue Cell"). The Blue Cell is further divided into teams, each defending a set of machines that represents a real company. The attackers can use whatever tools they have at their disposal. The defenders must defend everything from mock SCADA systems, VoIP, Microsoft Exchange and web servers running several different web applications. It is a good representation of what a real company may look like, which makes this type of exercise particularly educational.
Renaud Deraison and I spent the first day participating in the exercise and attacking the Blue Cell. We gained access to the first system by guessing the password based on web reconnaissance (they had renamed a directory to the same value as the root password). This may seem like something that never happens in the real world, but don't forget the Blue Cell teams are under a lot of pressure, and when stressed in this environment, tend to make mistakes. This is one value of the exercise; you get to see what mistakes are made during the game so you don't make them in the real world. Passwords can be the weakest link in your defense and need to be audited frequently by either attempting to crack them or brute force attempts against exposed services. I recommend that organizations implement a password policy and enforce it.
We penetrated the Blue Team chat channel and performed social engineering attacks in the chat room.
The team we were attacking was doing their best to fend off our attacks. They were actively terminating our connections on the firewall, which made it difficult to maintain connections after we gained access to a system. We managed to lock the defenders out of the system by adding new users and then changing the attributes on the /etc/passwd and /etc/shadow files to slow them down when removing our changes. Monitoring system changes for suspicious activity is critical. For example, you could use the Tenable Log Correlation Engine's user tracking feature to identify new users and their IP addresses. You can also use Nessus Compliance Checks to identify changes to file permissions.
One weakness, common in many organizations and in the systems used for the game, was the use of LANMAN hashes. NTLM is a very insecure method of storing password hashes for Windows systems. It is considered a legacy authentication protocol, however it remains in widespread use for backward compatibility. During the game, we were able to use our access to the Linux systems to then compromise the Windows systems. Once a Windows system was compromised, we would obtain the password hashes. Without cracking or brute forcing the password, this gave us access to any other system using the same password. You can use Nessus and smbshell to perform further auditing of hosts with just the password hashes. As a defender, it is important to disable the NTLM hashes . You can use Nessus Compliance Checks to audit registry values across all Windows machines in your environment. Various audit policies will check to be certain that NTLM password hashes are not being stored. For example, the CIS Benchmarks for Windows systems contain checks such as:
|
|
We spent some time with web application attacks as well, and found several vulnerabilities, including XSS and SQLi. However, a wide-open phpMyAdmin installation (i.e. did not require a password) on the team's systems was by far the most useful attack vector. PhpMyAdmin allows you to manage your MySQL databases using a web interface. It is the equivalent of a prompt at the MySQL command line. An attacker who has unrestricted access to the database can easily gain full control of the system. We constructed the following SQL query to give us command execution access:
This query will write out a new PHP file that will allow remote command execution. In order to be successful you need to specify a valid table name, a file path that is writable by the database server and accessible by the web server. From the defenders perspective, it is important not to leave phpMyAdmin open to the world without a password. In fact, a better solution is to make sure phpMyAdmin is not accessible, even with a password, to prevent attackers from accessing the database. If this type of application is required, you can use the Passive Vulnerability Scanner to detect SQL injection attempts. In addition, PVS contains rules that look for the result of operating system commands going across the network. For example, plugin ID 0105 looks for the result of the "id" command on Linux:
There are also plugins that look for Windows commands being run. For example, plugin id 0202 looks for a common error on the Windows command line:
The event was held at the Cisco Systems office in New York City. Depicted above is the "Human Network".
Day 2 - The Debrief
The second day provided an opportunity to teach the players (both Red and Blue teams) how we compromised the systems, the tools that were used and some defensive measures that could have been implemented. I provided a demonstration of several tools used by the attackers, including Nessus, how to integrate Nmap data into Nessus, import Nessus results into other tools and use the new Nessus web application testing features. The interesting part of the demonstration was that I was attacking a live network that was actively being defended. I showed how Nessus is configured to run a scan, and went through the results in real-time, showing how it was able to find anonymous FTP access, cross-site scripting and missing Windows patches. It was a great opportunity for everyone to see Nessus in action and ask questions. Since we were hosted in the Cisco office in New York City, there were some questions about whether or not Nessus had support for IPv6 (which was added in version 3.2-beta).
Conclusion
This was an educational event for both the defenders and the attackers. It provided an opportunity for people to test their skills in computer security and learn about tools and techniques in a real-world environment. From the attacker's perspective, a combination of automated tools,manual testing and persistence was a successful strategy. Automated tools, such as Nessus, proved very useful for the attackers to quickly identify vulnerabilities in the target systems. The defenders also benefitted from tools such as Nessus to help identify vulnerabilities and remediate as quickly as possible. Tenable's enterprise tools contain functionality that help the defenders identify attacks, both on the network and from the system logs.