Malicious System Administration

If you want to backup your files, use the 'rm' utility to mark which files...

Transcript

1. Malicious System Administration “if you want to backup your files, use the ‘rm’ utility to mark which files…”
2. Attack and Defense —  Use their computers without them knowing —  Use your computers without anyone else using it
3. Usual scenario for A/D CTF Anonymity cloud Your computer The Other Guys Scoring System Need this traffic Don’t want this
4. Without anonymity, this is simple —  Block traffic from anyone not scoring system, problem solved —  Generally you have to be permissive and allow traffic from the entire game world —  If you can classify “good” from “bad” at the network level…
5. Defense
6. Situational awareness —  How do you know if someone else is using your computer? —  This depends on how much the person using your computer cares —  This also depends on how much you can “see” or are permitted to see
7. Situational awareness: taps —  If you’re using a computer, doing nothing on the network, and yet it’s talking to the network, you might be owned —  For CTFs this can be a problem because you need to be able to put the system into a quiescent state —  This could mean shutting down the ability to make points off of a service poll, which could be bad if done for too long
8. Monitoring —  Exactly what can be monitored depends on the system and how much control you have —  As a user, you are limited to what system services will tell you —  UNIX-style wtmp logs recording login/logout accessible via ‘w’ —  When someone pops a shell, they don’t log in —  Process listings via ‘ps’ —  If someone backdoors your ‘ps’ binary, you have problems —  Information in some kind of procfs (if your platform has it) —  Or inotify, if your platform supports it —  netstat
9. Monitoring —  The operating system kernel brokers access to system resources —  Tracking global file or network activity needs kernel cooperation —  Dumping all packets coming in our with wireshark/ tcpdump —  Problem: discerning good from bad? —  Sometimes you can create honest signatures for vulnerabilities that you have identified
10. Monitoring —  Continuously dump the active process list —  Look for things you haven’t seen before —  Things to consider: on your platform, how can you have a thread running code? —  Sometimes they need their own PID, sometimes not —  Could an attacker inject a thread into a process that you trust? —  Maybe you can get more information about programs internal state —  What is heap size —  What is memory map
11. Monitoring —  Your programs will crash when other teams try to exploit them and fail because they haven’t perfected the exploit yet —  This is a great opportunity to capture another teams exploit! —  Pros have capture frameworks where they correlate socket information and time of crash to a packet capture —  Extract failed exploit, identify bug, fix it up, and turn it around on other teams before the failed exploit team fixes their own exploit
12. Monitoring the network —  Unbackdoored netstat will tell you about what programs are connecting to what remote hosts —  Long-lived connections would be weird —  Or would they? Ask your reverse engineers if challenge binaries should have long running connections
13. Case study: DEFCON —  DEFCON network conceals source addresses —  Some clever people did profiling of the IP headers received by their game systems —  Discovered a difference between scoring system traffic and contestant system traffic —  Implemented a classification algorithm and used this to guide all contestant system traffic to a honeypot
14. Fine grain process monitoring —  Consider running every challenge binary on your system under gdb with break-prints on calls to ‘open’ —  If you see programs opening files they normally don’t… problems? —  This isn’t perfect —  Attacker – how would you evade detection by this scheme? —  When present, facilities like inotify  can help identify changes to the filesystem in near real time
15. Monitoring summary - awareness —  Process activity —  Process launch / death —  Process memory maps —  Network activity —  What processes are connecting to what hosts for how long —  File activity —  Use gdb to get into processes —  Periodically re-scan the system for changes using some tools you write
16. Attack
17. Remember every defensive trick —  When using Other People’s Computers, they will be trying to find you the same way that you find people using your computers —  Generally, speed is good —  Persistent access is also very good (how long until they patch the bug)
18. Persistence —  How to get persistent access to Other People’s Computers? —  Where can you write text on the filesystem that turns into programs running at some later point? —  Example: crontab , bashrc —  Another example: cat your own key into their authorized_keys —  Do you always need this? —  Find some long-running process and put something there in memory-only using some handy tool you wrote previously
19. Hiding —  Making new processes is noisy and potentially detectable —  Back-dooring system binaries seems like it would be appropriately devious but the other guys could have file-integrity tools that tells them when you do this —  Or they might not? Maybe you should have those tools too… —  Just take everything you can think of to defend, and invert it
20. Conclusion —  Be evil