Transcript Improving the Security of Your School by Breaking Into It David N.

Improving the Security of Your
School by Breaking Into It
David N. Blank-Edelman
Director of Technology
[email protected]
August 11, 2000
1
(With Apologies To Dan Farmer
and Wietse Venema)
• Improving the Security of Your Site by
Breaking Into It, 1993
• http://www.fish.com/security
2
Request for Discretion
3
Background: The Incident
• Extra! Extra! Read all
about it!
• Northeastern
University student
hacks government
computers!
• (student was in my
College too, sigh.)
4
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.
5
6
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.”
7
Now What Do I Do?
• Step 1: define what
I’ve really been asked
to do.
• Step 2: get adequate
coverage for my
buttocks.
8
The Memorandum of Power
• Memo circulated to:
– My boss (Dean)
– University Counsel
– Staff from insecure
College
• Two parts:
– Goals
– My Requirements
9
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.
10
Goals (Subtext)
•
…for the <sensitive> data.
–
•
Make specific recommendations…written
report…submitted to University Counsel…their
discretion.
–
•
Specified and limited scope of investigation
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.
11
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.
12
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.
13
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.
14
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
15
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.
16
17
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
18
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
19
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
20
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.
21
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.)
22
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.
23
Game Over!
24
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
25
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.
26
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.
27
28