Dan Rogers wrote:
A lot of the motivation for this testing is usually passed down from
senor management who just want to feel are secure, so they tell their
IT managers to get a pen test without knowing what it means.
You, on the other hand, need to be very specific about what you
will do, what you won't do, and what the deliverables are. But I probably
don't need to say that.
1. Ask IT manager to identify critical network infrastructure
(servers, routers, wireless access points, Domain Controllers) - chose
a representative sample for review
2. Attempt to establish general network architecture using a
network-mapping tool
3. Perform internal scanning of network using NMAP/Nessus or GFI LANguard
4. look for really obvious problems. E.g. public/private SNMP or
default passwords, missing patches, well known open trojan ports
Personally, I would probably drop both 1 and 2, unless there was
a specific requirement to do either (for instance, 'we worry that
we may have P2P servers on the net'), and instead concentrate on 4
and essentially look for low-hanging fruit of every kind.
When I conduct the tests, time is usually very tight, and therefore
scanning of internal networks is quite costly time wise (especially if
there is a class A/B to scan).
Don't try to cover all systems -- there usually won't be time enough.
Try to cover specific vulnerabilities instead. That is, there's no need to
scan for everything: you only scan for the things you have well-tested
exploits for.
nbtscan is often a good place to start: you quickly get a list of
netbios systems, and those are prime targets for Win- or SMB-related
vulnerabilities. In many environments, this will be the bulk of the
systems.
Remaining addresses (i.e. those that didn't respond nbtscan) can then be
probed in further steps (nmap -sP, dnsscan, ...), and then scanned
for further vulnerabilities in turn.
Some of my favourites are (in no particular order):
nbtscan followed by scans for open shares & trivial passwords.
(Mount and look through open shares if you're allowed to: some people
are very careless about leaving passwords in files or scripts, and
other sensitive information. Look over these systems in more detail:
there may be personal web servers, open FTP servers etc.)
Open X Windows clients. Attach X keyboard event sniffer, and
check transcripts for passwords.
RPC/portmap. (Lots of dangerous services here.)
Finger/rusers for user ids to be used for password guessing.
Banner grabbing (SMTP, FTP, ...).
port 2301 -- Compaq systems. Older versions gave you lots and
lots of information, and on some you could get at backup SAM
files.
Databases with empty or default master passwords.
... and in general anything with a good, reliable exploit.
(Reliable in the sense that you don't want to be surprised by
it.)
--
Each of these requires fairly little scanning effort. On
*very* populated networks, it's may be a good idea to scan
C net by C net -- in order to know what C nets to start with
your step 1 could be useful. These nets will not be
completely covered anyway.
So how do you lot approach testing a lage network? Also, how do you
decide what to report to the client on?
Don't report that you were able to access shares X, Y and Z on system
PROTEUS, or that you got user-level access on systems JANUS and ACME.
They won't know what that means. If you can identify PROTEUS as a billing
system, JANUS as a configuration system used for their IT department, and
ACME as the workstation of the CEO, they will sit up and listen. You may
need a post- or mid-test session with someone who knows the net to get these
connections efficiently. And you may need to spend some time
going over a system once you're inside in order to find these connections.
--
Anders Thulin anders.thulin@tietoenator.com 040-661 50 63
TietoEnator Telecom & Media AB, Box 85, SE-201 20 Malmö
