PRCCDC 2013

From Hack Evergreen Wiki
Jump to: navigation, search

PRCCDC 2013 took place on the weekend of March 23-24th at Highline Community College. This was The Evergreen State College's second time at CCDC regionals, taking 6th the previous year. The narrative placed us at the IT team of Gotham Memorial Hospital after a serious disaster, putting some of our machines on 'generator power' (meant to simulate SCADA systems). While defending ourselves from cyber attacks, we also had to handle an array of 'injects' (day-to-day requests from our employer) by our CIO, Adam West. Part of the narrative in the injects required us to adhere to HIPPA/NIST standards, further adding to the challenge.


Results

  • Evergreen took third place with 6,129 points out of twelve entered schools.
  • Eastern Washington University got second place with 6,281 points(only 152 points more than us!)
  • Those punks at UW Seattle won first with 7,734 points. those bastards.

Team Members

  • Sam Singer Noedel
    • Captain
    • Delta62
  • Codi Fiman
    • athena087
  • Paul Williams
    • pshmell
  • Stefan Boesen
    • loocorez
  • Nick Achatz
    • arthurdent
  • Nick Stephens
    • mike_pizza
  • Max David
    • pipecork
  • Nate Moore
    • TranquilMarmot


  • Richard Weiss (Faculty)
    • weissr
    • Faculty Advisor
    • Morale support, yoga

Topology and Uptime/Availability

We VNC'd into our computers through thin clients. A number of computers were powered by a 'generator' to simulate SCADA systems in the narrative.

service device total checks up error down
http://external.gmh.ccdc:80 web (IIS, Server 2008) 68 62 (91.2%) 2 (2.9%) 4 (5.9%)
http://external.gmh.ccdc:8080 gen-ics (Ubuntu, Generator) 68 61 (89.7%) 5 (7.4%) 2 (2.9%)
smtp_relay://external.gmh.ccdc mail (Dovecot, Ubuntu) 66 0 (0%) 58 (86.9%) 8 (12.1%)
ssh://external.gmh.ccdc mail (Dovecot, Ubuntu) 67 57 (85.1%) 9 (13.4%) 1 (1.5%)
ssh://external.gmh.ccdc:222 emr (OpenEMR, Ubuntu) 66 65 (98.5%) 1 (1.5%) 0 (0%)
ssh://external.gmh.ccdc:2222 gen-ics (Generator, Ubuntu) 65 61 (93.8%) 4 (6.2%) 0 (0%)
ssh://external.gmh.ccdc:2222 siem (OSSIM/AlienVault, Ubuntu) 68 45 (66.1%) 8 (11.8%) 15 (22.1%)
ldap://external.gmh.ccdc dc (Domain Controller, Server 2008) 68 68 (100%) 0 (0%) 0 (0%)
sftp://external.gmh.ccdc:2222 gen-ics (Generator, Ubuntu) 68 62 (92.1%) 5 (7.4%) 1 (1.5%)
smtp://external.gmh.ccdc mail (Dovecot, Ubuntu) 65 23 (35.4%) 33 (50.8%) 9 (13.8%)
lmap://external.gmh.ccdc mail (Dovecot, Ubuntu) 67 24 (35.9%) 35 (52.2%) 8 (11.9%)
ssh://external.gmh.ccdc:222 emr (OpenEMR, Ubuntu) 64 63 (98.4%) 1 (1.6%) 0 (0.%)
ldap://external.gmh.ccdc dc (Domain Controller, Server 2008) 66 65 (98.5%) 0 (0.%) 1 (1.5%)
sftp://external.gmh.ccdc:222 emr (OpenEMR, Ubuntu) 67 67 (100%) 0 (0%) 0 (0%)

Injects

Adam West doesn't care if you're on generator power. Adam West wants to know about this newfangled "Cloud Computing".

1. Group Password Policy

  • 160/200 points, Comment: "Domain Policy" was not added to the top of the policy list.

2. Change Log

  • 0/50 points, Comment: Did not complete.
  • We set up trac on a server, but did not get it up in time. I believe (due to the wording on inject) they were actually asking for a document detailing a new changelog policy for us to follow. They didn't actually want to see the changelog (yet).

3. Scan and Close Ports

  • 120/200 points, Comment: Port 23 and 25 were also open.
  • The inject itself had an ambiguous use of the word "close" in reference to ports.
    • Moral of the story: Ask plenty of clarifying questions!!

4. IP Conflicts

  • 150/150
  • Description:

5. Create a Honeypot

  • 250/250
  • Description:

6. System Use Notification

  • 175/175
  • Description:

7. Locate and Secure Sensitive Files

  • 100/100
  • Description:

8. Alert Banner on GMH(Gotham Memorial Hospital) Website

  • 150/150
  • Description:

9. ???

10. Open Mail Relay

  • 150/300
  • Comment: Open relay failed but the server was down.
  • Description:

11. Using Cloud Storage

  • 129/150
  • Comment: When interacting with top management, it is advised that one would use a more formal means of presenting the information, like a word doc, spreadsheet, or powerpoint. There is little mention of security issues.
    • I think we just sent them a flat text file
    • Description: Requested a document comparing enterprise cloud storage options for GMH.

12. Social Engineering Presentation

  • 98/100
  • Comment: Well-written and informative. (so why two points off???)
  • Description: A powerpoint describing the dangers and methods of social engineering, and how to prevent it. Meant to be presented to the employees of GMH.

13. Single Sign-On

  • 83/100
  • Comment: A little grammatical issue, and they did not include a recommendation on whether or not to use SSO.
  • Description:

14. Company Security Policy

  • 140/150
  • Comment: Well laid out but some of the information presented would most likely not be found on the Security Policy, like the Backup portion or the SSN portion.
  • Description:

15. Emailed Phishing Training

  • 82/90
  • Comment: Overall pretty good. Just didn't submit it as a document. There is a piece on detection but it doesn't tell me how to detect an attempt.
    • Submitted as a flat text file or written in the email, as opposed to a word doc or powerpoint.
  • Description:

16. Audit Record Retention

  • 107/125
  • Comment: A retention policy should have a section that dictates what will happen after the documents reach the end of life. Had a little on destruction, but needed more detail.
  • Description:

17. Board of Directors

  • 304/400
  • Comment: Refer to take home packets [need scans of the presentation reviews!]
  • Description: A presentation to the "board of directors" (actually members of the competition sponsors) of the cloud storage powerpoint made earlier (Inject #11). Each "board member" filled out a review sheet of the presentation given (by Max David).
    • Max also has his own reviews of the audience: "meh"

18. Slandering Photo Location

  • 200/200
  • Description:

19. Account Management

  • 100/100
  • Description:

20.

Wait uh there were more I think

Attacks by Red Team

  • Attack ID: 20
    • Device: dc (Domain Controller, Server 2008)
    • Compromise Result: Web Defacement
    • Notes: used MS12-020 to disable remote desktop
    • Points -70
  • Attack ID: 33
    • Device: dc (Domain Controller, Server 2008)
    • Compromise Result: Web Defacement
    • Notes: MS12-020 to crash remote desktop
    • Points -70
  • Attack ID: 75
    • Device: dc (Domain Controller, Server 2008)
    • Compromise Result: Web Defacement
    • Notes: crashed with MS12-020
    • Points -45

Performance Recap

What we did well

  • Passwords were good! The sheet numbers were a good system. Kinda hard to type though. Nice n' secure
    • Updating the passwords frequently was perfect


  • Delegation of tasks.
    • Linux
      • SSH: sshd_config, log monitoring. tail -f /var/log/auth.log is your best friend
      • Apache
      • Mail Server
      • Other Services
    • Windows
      • Active Directory
      • Group Policy
      • IIS / Mail Server
      • Other Services
    • Router / Firewall
      • In charge of setting up a comprehensive service blacklist by communicating with the backtrack teammate.
    • Intrusion Detection
      • This year we had a machine running Alienvault. Due to hardware mis-configuration beyond our control, it crashed a lot, but it was handy when it worked.
    • Backtrack
      • In charge of nmapping the outside view of our network to see open and closed services
      • In charge of basic mimicing of scorebot to test external service uptime.
    • Injects
      • Two people who are 80%+ dedicated to doing injects. This was indispensable


  • Having somebody constantly monitoring every /var/log/auth.log. tail -f is your friend.


  • Be wary of (spear)phishing emails, make sure you check the 'from' address. Scrutinize heavily.
    • Before clicking any links, or responding to any e-mails: have at least one other pairs of eyes look over an e-mail.
    • Check the headers. Is it sent from a verified sender?
    • Always check md5 hashes of programs sent via email. Submit an incident report if non-matching. (points)
    • Regardless of md5 hashes, always download software from the source website. Don't get lazy.


  • Firewalls were top-notch
    • IPtables is very important for locking down individual machines. Figure out what needs to be running and white-list it, then block everything else.
    • Third party software firewalls and RDP do not mix. Make sure you create a rule to unblock RDP before starting the firewall.


  • Changed config for ssh, and its grace period


  • Studying router management was helpful, and making sure someone is monitoring its firewall at all times


  • Team leader made sure people had tasks to complete, and only spent time at a terminal when it desperately needed.


What we should improve

  • Linux programs we should know (better)
    • nmap
    • netstat
    • iptables
    • find
  • Windows dialogues we should know (better)
    • IIS
    • everything
  • Communication was good but some members of the team could have been more vocal when they were having trouble.
    • Team leader did a great job of distributing injects to teammates based on strengths, but teammates didn't always promptly seek help when in over their head.
    • Perhaps have multiple teammates read over injects to make sure we're completing them correctly.


  • Devise a system to announce when logging into a box so people watching the logs don't poop their pants.


  • More people monitoring logs (tail) and the status of systems. This year just Paul and Nick were keeping a sharp eye, might be beneficial to spread the responsibility.


  • Testing your services after changes. Make sure you're not breaking things you can't fix


  • Secure the backtrack machine!
    • Scratch that, secure everything


  • Make sure to stick to the plan!!
    • We didn't install fail2ban or logwatch like we planned. fail2ban would've been handy


  • Don't trust executables. md5 hashes are your friend


  • A proper changelog system.
    • The first day had an inject requiring a changelog to be set up, and the next day they wanted updates twice; we failed all three of these injects.
    • Would also be very helpful to our management, and is best practice


  • Need to do more accurate training. Including injects and other pressure situations in training


  • Read each inject VERY carefully. If they ask for something, make sure you know exactly what they're asking for and ASK if you're not sure.
    • Asked to 'close' ports, misunderstood to mean blocking the firewall. They want us to stop these services.


  • Respond to each inject professionally and with the appropriate amount of detail.
    • proofread! And no sarcasm or stupid jokes. we got docked points for sarcasm in a letter to our 'boss'


  • Make sure we update!!!! Windows especially. Make sure everyone does it to their machines.
    • change the password of local users


  • Clearer understanding of DNS, AD, and how firewalls work with it
    • our DNS may have been down for a bit because of our router's firewall policies?


  • Brush up on your networking knowledge! They used unconventional netmasks to trip us up.


  • Printed copies of our training wiki, cheatsheets, or even annotated man pages
    • We didn't know until the end of the first day that we wouldn't be allowed to bring new material (passwords, etc.) into the event on the second day.


  • Some sort of simple script to block any sort of "game ending" commands (our generator got rm rf'd in the last 10 minutes)
    • Perhaps rename commands like rm to something else, and replace /usr/bin/rm with a script that disconnects the callers shell. This should work for both interactive, and non-interactive shells.


  • Excellent pizza. (bring your own food)

Other Notes

  • Richard is buds with fake Neal
  • Don't eat the churros
I think his name might be Dan?
Richard Weiss talks with his good friend, Fake Neal