Take a closer look...

Step 1: Update the BMC firmware

After updating the Baseboard Management Controller firmware, the fan speed slopes changed.  The fans now have a lower minimum speed and are noticeably quieter.  Dell Poweredge 2950 BMC firmware update v.2.50, A00


Step 2: Replacement fans

I selected the Top Motor FA60TM3BMP as a replacement, since the FA60TM3BEP isn't carried any more by BestByte.com.  A representative at BestByte named Barry was very helpful in referencing the spec sheet for top motor fans they did carry.

The Top Motors seem to be just a re-brand of Dynatron parts. According to the spec sheet the Top Motor FA60TM3BMP corresponds to the Dynatron DF126025_M. With 7000RPM, 38.28cfm, 48.1 DBA, and 13.55 mm/H2O of static pressure, these fans should give an acceptable margin for error.

Now for the frustrating parts. All the replacement fans needed to have their connectors swapped with the stock fans, as well as having the closed mounting holes opened up. A simple re-pin didn't work because the pins are not compatible for a simple swap. Specifically, the Top Motor pins were too large for the stock fan connector.

The solution:

1. Simply cut the wires:
   
   


2. Swap the connector leads, solder the wires back together, and apply some heat shrink tubing:



Voila!  Some Top Motor fans with proper connectors.

3. Used a hacksaw, long handled pliers, and a Dremel cutting wheel to open up the closed mounting holes:





4. Modified fans in cages:





5. Modified fans installed:








6. Results:



Poweredge 2950 at idle with modified fans




Poweredge 2950 at full load with modified fans

Also of note is that the power supplies had the same high speed fans as the stock cpu coolers. Solder swapping the connectors for those as well with two more Top Motors resulted in the server failing to get past the first POST screen when the power supply fans are at too low of an RPM.  For the time being, the stock PSU fans were reinstalled, but the planned solution is to hack the BMC.

Some users on the Hacking guide thread have commented that the BMC hacking guide works on the 2900 as well as the 2800, and by extension the 2950.

One more thing. Unrelated but someone may find it useful. I was able to replace a 2950 Gen I motherboard for a 2950 Gen II motherboard and everything worked just fine. No weird boot up issues or anything. With the Gen II motherboard I now have quad core cpu capability, and I was able to install those nice quad cores without issue.

• Defend a nuclear reactor from attack as well as maintain services and generate energy
• Actively exploit and attack opponents to obtain flags
• Scan network and identify hidden assets and obtain flags

Tools

All team members used Kali 1.0.4 as their operating system of choice for game play.  Tools within Kali used in the game included: metasploit 4.7.0 with postgres 9.1, armitage, nessus 5.0.3, and ufw/gufw.

Special note.  If using metasploit 4.7.0 as your framework, you must use Nessus 5.0.3 if you want to load the Nessus plug-in.  Visiting Tenable's download page only leads you to links for 5.2.x.  Here are a couple shortcuts to 5.0.3 to save you time from analyzing their site code and finding the package names:

Nessus 5.0.3, 32-bit

Nessus 5.0.3, 64-bit

Sharing the Database

Prior to the competition, the team agreed that to eliminate duplication of effort, we needed to use a shared database for offensive purposes.  At the same time, the shared database needed to be protected.  We set up the postgres database, nessus, and an armitage team server instance to all be accessible remotely.  To protect the centralized infrastructure, we leveraged ufw/gufw, which works great since it starts out with a default deny for incoming traffic.  When the competition started, team members quickly fed me their IP addresses, and I loaded the rules into gufw.  I'll be posting a separate guide on how to share out the database, which is simple once you've done it a couple times.

Defense

Once the game began, offense provided the defense the results of scanning the team Scram server with the identified ports (80, 22).  Accessing the team server via HTTP on port 80 showed us the web page where the actual Scram game was running:

Check out the video above for the full briefing, or click here to jump to what our interface looked like.

After logging in to the server via SSH, the root password was changed.  With the password changed, the defenders set about learning how to play the Scram game since megawatts per hour (MwH) was a scored component.

Discoveries

We learned about halfway through the game that another team analyzed their team server's game code and found a way to accelerate their point gain.  We did not dedicate enough resources to emulating this approach until the last hour of the game (fail!). 

The Scrame game itself was built in python and had multiple components.  There was an environment.py script which contained variables and formulas in which the score was calculated.  In another directory was a network.py script which took the results and sent them to the scorebot.  The packet was ultimately crafted using scapy in another python script.  The service for these python scripts was something called "twisted" that utilized websocket initialization scripts, also written in python.  A danger in altering the game code was that depending on the alteration, teams would need to restart the service components and do so in the right order.  Failure to do so would result in a loss of accumulation of points.  Note to self, learn things...

Offense

As soon as the team was wired in, offense scanned both the internal network and the external network to identify hosts.  The scan was run using Armitage, and because we didn't know of any hosts, we included the whole ranges.  Results populated "live" hosts and "ghost" hosts.  Scanning a "ghost" host resulted in no open ports.  Not having read Armitage's documentation, Armitage may automatically place an entry for each host in the range through its scanning script.  For cleaning our visual display, we set the view to table view and removed "ghost" hosts.  Note to self, learn to avoid this in the future.

With the remaining live targets, we ran multiple port scans and nessus scans against them.  We were able to get shells on two or three linux machines.  All Windows machines were running Windows 7.  More on that in the next paragraph.

Discoveries

From one of the shells, there was limited command line access.  Commands like "ls" worked, but "cd" and pretty much anything else did not.  We did not attempt to load another shell (fail!).

Several of the Windows machines were Windows 7 Service Pack 1, build 7601.  The default install of Metasploit 4.7.0 does not have any exploits for that build.  MS_09_50 did not work.  Enumerating these machines using the endpoint mapper auxiliary module revealed 6 to 7 machines were part of the same domain (PONY_GROUP), while 3 to 4 were part of another domain (NOVAC).  Had we gained access to one Windows 7 machine in either domain, we could've used pass the hash to get access to the others.  Shoulda, coulda, woulda...

Lessons Learned

• CTFs in this format are "unknowns", meaning be prepared the best you can and expect something new and different
• In CTFs where hacking the game mechanism itself is allowed, resources should be devoted to analyzing the game code at the start
• Where CTFs provide information about the infrastructure, such as in this case the game Scram, study and any all related resources prior to the start of the competition
• Have a tool such as WinSCP or know how to secure copy in Linux to copy files and folders from an SSH session
• Identify all known metasploit modules/exploits built by others for use against Windows 7 and test usage 

Additional Information

• Altamira's Blog Post about the event
• Altamira's list of machines available in the environment

USCC Summer Camps feature one week of specialized cyber security training that includes workshops, a job fair, and a culminating “Capture the Flag” competition.  The workshops are lead by college faculty, top SANS Institute instructors, and cyber security experts from the community.  The workshops and presentations focus on a variety of topics ranging from intrusion detection, penetration testing and forensics.  Participants can also participate in a job fair that provides them the opportunity to meet with USCC sponsors and discuss potential employment.  The week-long program ends with a competitive “Capture the Flag” competition and an awards ceremony attended by notables in the cyber security industry and government.

Image Credit: vmpyrdavid

• Day 1 - Scapy
• Day 2 - Android Pen Testing
• Day 3 - Memory Forensics with Redline and Volatility
• Day 4 - Tactical Incident Handling & Hacking Techniques