1

Improving the Security of Your School by Breaking Into It

David N. Blank-Edelman Director of Technology dnb@ccs.neu.edu

August 11, 2000

2

(With Apologies To Dan Farmer and Wietse Venema)

• Improving the Security of Your Site by Breaking Into It, 1993

• http://www.fish.com/security

3

Request for Discretion

4

Background: The Incident

• Extra! Extra! Read all about it!

• Northeastern University student hacks government computers!

• (student was in my College too, sigh.)

5

The NU Truth Revealed

• I get approached by a student with ties to both Colleges.

• S/he knows how the cracker got to the sensitive NU data.

• S/he offers to show me the advanced hacking tools employed.

6

7

Let the Meetings Commence!

• The student and I visit the University Counsel.

• UC/President’s office calls a high-level meeting.

• I get asked to head up a team to make sure the other College is now “secure.”

8

Now What Do I Do?

• Step 1: define what I’ve really been asked to do.

• Step 2: get adequate coverage for my buttocks.

9

The Memorandum of Power

• Memo circulated to:– My boss (Dean)

– University Counsel

– Staff from insecure College

• Two parts:– Goals

– My Requirements

10

Goals

1. Determine the current level of security for the <sensitive> data at the College of <something>.

2. Make specific recommendations for improving this security should it prove lacking. A written report will be prepared. This report will be submitted to University Counsel for dissemination at their discretion.

3. (optional) Confirm that these recommendations have been followed after a reasonable time frame has elapsed.

11

Goals (Subtext)

• …for the <sensitive> data.– Specified and limited scope of investigation

• Make specific recommendations…written report…submitted to University Counsel…their discretion.

– Specified what it will yield, in what form, and to whom. Puts the decision on what to do with the bad news on power center, not me!

• (optional)– I may be back, I may not, you decide.

12

Requirements #1: The Team

• a team of 3-4 members will work for up to 2 days performing penetration testing and security auditing. This team will consist exclusively of members chosen by me from the NU community. Team members who are NU staff must be given leave from their normal duties during testing.

13

Requirements #1: The Team (Subtext)

• 3-4 members…from the NU community…up to 2 days– How many people, not outsiders, working for a

specific duration.

• chosen by me…given leave– Who gets to pick them (important!, deadweight

is bad.) No negative ramifications for people picked.

14

Requirements #2: Access

• Three levels:– Physical access to network.– Normal student account.– Server (privileged) access.

• Access to source code that touches <sensitive> data.

• Access to programmer of this code if possible.

15

Requirements #3: Privacy

• Due to the sensitive nature of this work, the team will require physical and social privacy to conduct its work.– Subtext: leave us alone while working

16

Requirements #4: Informed Written Consent

• Must come from either owner of systems (Dean level) and network (central IS) or NU President.

• Why required:– Testing could violate state/federal laws if performed

without consent.

– It is likely sensitive data (even that not directly related to investigation) will be accessed.

– May disrupt normal computing/networking services with little or no warning.

17

18

Step 1: Remote Reconnaissance

• Dump DNS zone – Nslookup’s ls– Now I’ve got:

• Network topology• Name of important

servers/workstations

• Ping/port scan?– Solarwinds/nmap – Not everything in DNS– Find all NFS servers

19

Step 2: Find the Data

• showmount (-e) NFS servers– Locate mail spool

– Locate user home directories

– Determine mount scheme

• Become a trusted host

• Mount mail spool (nfsshell)– Learn important UIDs

20

Step 3: Poke Around

• History files

• Administrative scripts

• CGI-bin

• Jumpstart/new machine installation directory

• Found potential locations for sensitive data, now need to get into them

21

Step 4: Sniff

• Used dsniff, ethereal, sniffit.

• Saw much too much.

• Could easily have hijacked most anything.

• Looked for NIS/NIS+ servers.

• Would have used macof if necessary.

22

Step 5: Active General Probing

• No stealth used

• Snmp scans using Solarwinds tool

• Nmap for OS versions (or just look at banners)

• Search for relevant exploits

• Use helpful exploit scanners (rpc, pcnfs, etc.)

23

Step 6: You’ve Got Root!

• Server susceptible to rpc.cmsd.

• Got root shell, can get into desired directory, but need to act as special user.

• Su doesn’t work, so I used Perl.

24

Game Over!

25

The Report

• Submitted 4 page report

• Repeated the goals

• Caveats – (Security is a process; This is

not a prescription; This is not a complete audit)

• Ordered list of non-systemic problems, impact, fixes

• Ordered list of systemic problems, impact, fixes

26

Parting Observations #1

• Get the Pope (or the nearest equivalent) to bless the effort.

• Communicate clearly in writing and in person to all levels in the command chain.

• Make sure you are the protagonist, not the dead messenger.

27

Parting Observations #2

• Try your best to avoid owning the problems you find.

• Use your weaknesses; Add to your strengths.

• Document your work as you do it.

• Share the clue.

28