1 / 70

Stuff

Stuff. Steve Romig romig@net.ohio-state.edu. Introduction. Summary: things we’ve learned about incident response, computer crime. Things we’ve done right Things we’ve done wrong Vehicle: an investigation that started 4 years ago. Pre-incident.

salena
Télécharger la présentation

Stuff

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Stuff Steve Romig romig@net.ohio-state.edu

  2. Introduction • Summary: things we’ve learned about incident response, computer crime. • Things we’ve done right • Things we’ve done wrong • Vehicle: an investigation that started 4 years ago.

  3. Pre-incident • OSU didn't have much of an incident response team • Incident response was ad-hoc • Response depended on who responded • Had recently hired me part time • I started some minimal initiatives: • Tracking incidents • Logging (authentication, network traffic) • Education/awareness meetings

  4. 19:00 August 27, 1996 • California ISP calls me at home: they'd been compromised • Attack came via our modem pool. • They named a suspect: someone using the nickname XXX on IRC. • I confirmed the activity • Intruder had been logged in through modem pool since 2:00 that morning. • We had several previous incidents for this intruder

  5. Lessons • Publish your contact info • Log lots, log often, retain your logs • Early action can prevent later nastiness

  6. 00:30 August 28, 1996 • Intruder is *still* logged in • Phone traces through Ameritech: • A promising start, sort of • Phone traces work “just like in the movies”

  7. 10:00 August 28, 1996 • Intruder is *still* logged in • Phone traces through Ameritech: • I've definitely seen too many movies • It doesn't work the way I thought! • Lessons: • Publish contact info • Everyone you talk to • Carry at all times

  8. August 28, 1996 • Phone traces through Ameritech: • They keep records • We can request traces after the fact • Lessons: • Work out procedures, info required with your local police, phone company.

  9. August 29, 1996 • Set up tcpdump logging of intruder sessions. • We had to identify sessions through our authentication logs, start/stop tcpdump by hand. Ick. • Also raised legal issues – ECPA? • Talked to our lawyer – “no”. • This indemnifies me (to some degree) - now its the University's problem

  10. Lessons: • Talk to your lawyers. • Create an incident response “team” • Not necessarily full time • Key players: legal, IT, communications, student affairs, help desk, etc. • Make a plan – who decides how/whether incidents will be handled.

  11. August 30, 1996 • We enter the next level of phone trace hell: • Confusion over what sorts of court order/subpoena/search warrant we needed to request the trace. • I don’t recall how this was resolved.

  12. September 3, 1996 • Got tired of starting tcpdump by hand • tacacs-action • Config file lists accounts and actions to take on login/logout. • Actions include "log" and "page" • "page" does what you'd expect • "log" invokes tcpdump on a sniffer on the correct subnet to capture their traffic on login (filtering for just their IP address), or stops tcpdump for that session on logout.

  13. Lessons • Automation is a wonderful thing. • We discovered that there were several people using several accounts.

  14. September 5, 1996 • I got insanely sick of getting paged all the time. Turned off the paging in the control file for tacacs-action. • We discovered that one of the local groups hangs out in #614 on IRC. • Started lurking in #614…

  15. Meanwhile… • Tcpdump logs are piling up • We read through the logs with tcpdump and strings and a program called cleanup that Mark Fullmer wrote. • This is tedious, icky, and prone to errors. Its hard to read terminal escape sequences and other obfuscated traffic.

  16. Review • GUI to browse list of logs, view contents of logs (by "sessions") and contents of sessions.

  17. Log Listing Window • List of logs, sizes • Double click log to see summary

  18. Session Summary Window • List of sessions from one log • Double click to see contents

  19. Session Contents

  20. Session Replay • Escape sequences are hard to read • Replay takes the server to client traffic and writes it at a controlled rate to a terminal emulator

  21. September 13, 1996 • Morning ritual - check mail, download tcpdump logs, run the pre-processing stuff, get a cup of coffee, and settle down to read. • They were doing lots of IRC, email, some probing, some exploits. • They used SSH and PGP • Through telnet sessions • Sent passphrases for private keys via telnet • Sent private keys via FTP and IRC

  22. Lessons: • Weakest link • When you send encrypted email, encrypt it to your public key also :-(

  23. September 21, 1996 • We have been trying to ID the suspects • Maintained “players” list • Original theory: ID them and jump directly to search warrants. • Nope, it doesn’t work that way: phone trace, pen register, search warrant. Builds body of proof. • Phone traces are still up in the air...

  24. Ah, breaking news… • YYY notes that XXX gets accounts by sniffing passwords in an OSU public lab and shares them with friends. • Yes, the labs were sniffable • Despite recommendations to fix this the year before

  25. Lesson • Fix known security problems • Learn from past mistakes • Our labs are mostly fixed now • Now we’re deploying wireless networking…

  26. October 1, 1996 • We tried to find the local 2600 meeting • 2600 magazine claimed they met at a local mall • Not as far as we could tell • XXX says that the local 2600 meeting isn't where its advertised. Aha! • Took some time before we learned true location

  27. October 15, 1996 • The first of the military/government intrusions. • The issue of notification arises again. • We call the FBI and the various military CERTs.

  28. The Issue of Notification • These guys ran a domain/host • They’d run probes, exploits from there • Guess who answers postmaster email? • They’d receive complaints about their activity • Rarely • They’d respond with a polite note “so sorry, we’ve been hacked…”

  29. Notification • At one point they broke into host Q.com • We were all set to send q.com a warning about it • Saw email between “our” crackers and them joking about the breakin – they were friends!

  30. Lesson • To notify or not, that is the question… • Don’t know who you are talking to • Don’t know whether they will follow your instructions (if you have any) • Sticky question

  31. Phf Exploits • They were using the canonical "execute xterm on the remote box as root with DISPLAY set to my X server" version of the phf exploit. • Tom’s nasty xterm…

  32. Review Revisited • X traffic is obscure – requests, results, events are sent in binary form. • I mangled an X debugger called xmond to replay X sessions from the tcpdump logs • Later, Justin Dolske rewrote this in Perl.

  33. Browsing an X session • Server side (next 2 slides) • Key press and other events, replies, errors • What the user typed

  34. Browsing an X session • Client side traffic now (next 2 slides) • Requests sent to the server • ``What the user sees'' • What is the user seeing now?

  35. Replay of an X session • More obvious now: the user was running vi • Works for simple cases

  36. October 23, 1996 • Many of “our” intruders made various confessions to other crimes: drugs, credit card fraud, cell phone fraud… • XXX passes out OSU accounts • Practice sessions, training, playing with new exploits. particularly XXX, WWW.

More Related