Tutorial: Wargames: Part 4 -- LONG
Wargames: Part 4
This will be the last of the war games tutorials (for now -- I'm pondering doing a segment on attack types). This particular one will deal with what you do at the end from the view point of my advanced class which spends 4 months building a secure network and participating in wargames during those 4 months.
If you missed part 1, you can find it here
If you missed part 2, you can find it here
If you missed part 3, you can find it here
As someone mentioned in the Real World you don't really get an opportunity to talk to your attacker to find out what they did against your machine nor do attackers really want to. But there is one type of "attacker" that does do this: security auditor. Sometimes referred to as an "ethical hacker" or "white hat hacker", this individual's job is to stress test your network and security practises with known attacks (you know they are attacking you) to unknown attacks (you don't know they are doing it). Generally, from what I've experienced and for those interested, you will find these individuals at security consulting firms as well as large accounting firms like Price-Waterhouse and KPMG.
Let's start with the "victim's" view.
Computer Forensics
During the wargames, students know they will be attacked at one point or another. They need to show me what they figured out from those attacks and how they dealt with it in their reports. Generally the following has to be done:
1. Isolate the compromised machine if possible or remove it from the network
2. Determine how the attack occurred
3. Find the vulnerability and the necessary fix
4. Record all info
5. Fix the problem and place back on the network.
Now this isn't following all the steps of a forensics methodology as we have limited resources. One of the steps would be to create a complete backup of the compromised machine and invest that and then place a new clean machine with fixes up ASAP.
1. Isolating the compromised machine
Generally the students just remove the network cable so that it's not on the network. In some cases, they may simple shutdown the network card (if it's a *nix box).
2. Determining how the attack occurred
As I mentioned in the real world, you'd make a backup of the hard drive (ideally a bit-to-bit copy so that nothing is changed in the copying) but due to limitations in our classroom/wargame setup this cannot be done. So we dive into actually finding out how someone attacked them. Much like the real world, you will be attacked at some point. You may or may not know how, why or when but you need to be able to find proof or evidence of it in order to deal with it and in some cases, get more money for more security features/resources (as needed).
The first place that many students look is their IDS but it only is a reflection of what the IDS detects. And what the IDS detects (usually SNORT) is limited to the ruleset signatures in place. So students have to look a little deeper. Some of the things they have to look for are:
- hidden directories and/or files: in *nix systems these start with a . ; in windows, it's a permission item. Also check to see if any files have changed size. Something like Tripwire could watch for commands that might have changed in the /bin, /sbin, /usr/bin, /usr/local/bin and so on. Check the /tmp directory for any new files that appear that don't seem "normal"
- processes running that are unknown: do research on all processes running. Google and/or other search engines can be helpful for this. You should be able to find all your processes that are running and should be able to identify what is running them. If it's an unidentifiable, then it can become suspect. In *nix the command ps -aux | more can be helpful. In Windows, Task Manager is the place to start but consideration for 3rd party tools to look at more than just what TM offers is a good thing.
- check to see if there have been permissions changes: maybe you removed the Everyone user from various directories and, oh look, it's back. Assuming that you've recorded how you built your system and/or know exactly where/what permissions were set, then you should be able to search to see if any permissions have been changed. Tools like find in *nix (use your man pages to find out what options to set) and dumpacl from SomarSoft (this is a free util) can be beneficial in this search.
- check the Tripwire logs (as the admin you did install a HIDS -- Host based IDS -- to detect these kinds of things)
- virus checks: definate requirement for Windows users and might be even worthwhile for *nix ones
- rootkit checks: chrootkit and other rootkits are good to check for *nix boxes (where these tend to appear)
- logs, logs, logs: /var/log directories and Event Viewer have been logging lots, right? Check to see if users have logged in (especially the ones that shouldn't be logged in)
- accounts: check for new accounts and be thorough about it. I've seen people put in mial as an account and it got glossed over because people thought it was the mail account (used for sendmail). Don't just check passwd but also the shadow files (on *nix). Also check the /etc/groups file. On Windows check the User and Group Manager for accounts. To be doubly sure, run the SAM through something like l0phtcrack to see what accounts it finds.Also, check to see if locked accounts have become unlocked.
Record everything and begin to put together a picture of how the attacker got in. If you are able to get enough detail, you should be able to find some clue they have left behind. (there is always a clue; it's a question, however, of how "anal" you want to be looking for it).
3. Find the vulnerability and fix
From the investigation above you should be able to find the hole that was used and determine what fix, if any is available, can be applied. If there is no immediate fix (on the rare chance it's a new find), then develop a work-around (kludge) that will do for the time being.
4. Record all info
Now this should have been done all along but now it's a matter of making sense and making the report understandable. It's not enough to say "They used a ptrace() exploit". Explain what the exploit/hack was, how they did it, what vulnerability it opened and how to fix it. Total understanding of the attack is critical. It helps when dealing with future attacks. In addition, the audience reading the report may not fully understand everything. If you are able to explain it, then your understanding of what happened is far greater. When I do this, I play the role of a "dumb CEO" of a company called Hackers 'R Us, Inc. This CEO knows nothing about security beyond that he/she thinks it might be important. This forces the student to make the report simplistic and yet informative without condescending. It is a challenge. Spelling and grammar are important. If you have to create reports like this in Real Life, "leet" speak won't keep you employed that long.
5. Fix the problem and place the machine back on the network
Obviously, you've learned something from the compromise and would have fixed it before returning it to active duty (save for honeypots -- the more holes, the more attrative it is). You would have also removed any extra accounts, programs, etc. that might lead to future compromises.
Now this is one portion of what students hand in to me for their final documentation. (Final docs in the advance courses take care of a few small forests sometimes).
Auditing
On the other side is the attacker. They usually have to document (as an "audit") the following:
1. What vulnerabilities were found
2. What attacks were used
3. Success rate of the attacks
4. What the victim should do to fix the problem
1. What vulnerabilities were found
If you remember, during the attacker's attack one of the first things they do is "footprint the network". That is, determine what is on the network and what vulnerabilities exist on the network. So as part of their report they have to identify what risks they found and how "risky" are they. Will that vulnerability cause a BSoD or give full root access? References to various databases that keep track of vulnerabilities are helpful here (CVE, Mitre, CERT, etc.).
2. What attacks were used
Source code of exploits, log records, etc. of the attacks used to compromise the system are beneficial here. Being able to explain what and how the attack worked is even more critical. It tends to expose not just technical issues but non-technical problems like social engineering, etc.
3. Success rate of the attacks
The biggest drawback to wargames is a time factor. The reality is not all attacks are successful in a few minutes but rather take time (months in some cases) which often isn't available. Determining how successful an attack is can very from not very successful (victim detected attack/attack was useless) to "r00t3d". The thing I tend to look for is methodology. As long as the methodology is sound, then it is likely that a compromise will happen in time if time was available.
4. What the victim should do to fix the problem
Again, similar to what the victim does after they see how they were broken into, the need to find the solution to prevent it from happening again is imperative. It might be a simple hotfix but then again, it could be a kludge if no fix exists at this point.
The same thing applies when writing this report. "leetness" doesn't go too far as much as details and understanding. The ability to get the point across is far more important than anything else. The ability of the attacker to be able to describe in detail how they did what they did and where they did it is key here.
The whole process gets repeated as need be. In the advanced course I go through 3 rounds of "wargames": groups do "audits" on themselves, groups do known audits on each other, groups do unknown audits against each other (sometimes straightout melee). In the last two, the victim groups get copies of the audits performed against them. The unknown audits are anonymous.
I hope this has been a worthwhile series. I may yet add some more to the WarGames tutorials as the WarGames themselves change over time. The PDF for all the WarGames Tuts is on it's way.
