From: Anders Thulin (Anders.Thulin@tietoenator.com)
Date: Tue Mar 08 2005 - 03:16:56 EST
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ö
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:17 EDT