RE: Penetration Testing using OSSTMM

[miguel.dilaj () pharma novartis com]

Indian Tiger <indiantiger () mailandnews com>
15/01/2003 07:31

 
        To:     Miguel Dilaj/PH/Novartis@PH
        cc:     isecom-news () lists sourceforge net, Pen-test <Pen-test () securityfocus com>
        Subject:        RE: Penetration Testing using OSSTMM


> Hi Nekromancer,

Hi Indian Tiger


> Your suggestions are very much to the point and this is what I was 
looking 
> for.
> Here is the link for Open Source Security Testing Methodology Manual
> www.isecom.org/projects/osstmm.htm

Yes, I know it, but it has been ages since I read it. I presume that it 
has changed a lot since then...


> Comments in-line

Mine as well.


> > > Network Surveying
> > >
> > > Examine tracks from the target organization.
> > > ? Search web logs and intrusion logs for system trails from the target
> > > network.
> > >
> > > What could be the possible "keywords" to search here for web and
> > intrusion
> > > logs?
> >
> > Look for Snort's rules and use them as a basis on what to look for.
> > HINT: install Snort and avoid investigating by hand at a later time ;-)
>
> humm more HINT pl.

Do you know the NIDS Snort? (www.snort.org)
It works sniffing the network and looking for certain "footprints" of 
known attacks.
A really silly example is looking for "cmd.exe", because it's used by 
attacks and worms in the string "../../winnt/system32/cmd.exe"
If you look at Snort's rules, you'll surely get a lot of ideas on what to 
look after in the system's logs.
Programs like logwatch for Linux also have some rules (again, for Linux) 
that help to detect standard patterns of problems in the logs.
I can't state a general recipe, you've to read those, learn about the 
attacks implied by the different signatures, and then look after this 
information in the logs.
I hinted installing Snort as your NIDS, because it's Open Source, free, 
has versions both for Linux and Win32, and it's really a VERY GOOD NIDS.


> > > Information Leaks
> > > ? Examine target web server source code and scripts for application
> > servers
> > > and internal links.
> > >
> > > What to check here? Is it indicating to check client side script?
> >
> > Yes and no.
> > You also have to look for comments left by the developers, phone 
numbers,
> > emails, passwords, links to internal resources, etc.
>
> I got your idea. Please shed some more light on this if possible with 
some 
> examples, especially on internal resources. Comments are really a good 
help. 
> Several programmers write their password at Client Side Script in plain 
text. 
> Which is really a good finding.

Well... I found the usedID and password of an account used to upload the 
web contents to the server in a comment. It seems that the web developer 
put this information there to avoid forgetting it, and later forgot to 
remove it.
You mentioned a similar example.
emails are interesting as well. If a company isn't using virtual emails, 
the userID portion of the email means a user account in the system, and 
this is half of the information you need to get access.
Trying to get the global.asa file in a vulnerable IIS is a nice finding as 
well.
Looking at the source in order to find the site's structure (i.e. 
directories) is good, because many a server fails to denegate access to 
directories where no index.html is present, and will show you the files in 
the directory.
Download the presentation about web hacking from www.penetrationtest.com, 
it will give you more ideas.
Of course if you manage to get the source code of scripts and CGI is 
really good in order to discover ways to make them "behave funny" (i.e. do 
things they're not supposed to do), etc.


{snip}

> > > Enumerate Systems
> > > ? How to "Collect broadcast responses from the network".
> > >
> > > Is it to stop Smurf kind of attacks? What setup I need in my Lab to 
test
> > this?
> >
> > First, learn how DDoS works, then send appropiate packets from the 
outside
> > (i.e. Internet) to the network's broadcast addresses, and see if they
> > answer.
> > If so, implement egress filtering.
> > It's easier to test in the real network than to setup a lab for this.
>
> Good Idea. What could be a Ideal flood? How many packet in specific time 
over 
> specific bandwidth?

A flood is a flood, and means as many packets as possible in a given 
period of time ;-)
I was joking, in case you only want to detect if there're broadcast 
responses exiting the network, a few packets will be enough, you only need 
to watch if there's response or not.


> > > Services Identification
> > >
> > > Tasks to perform for a thorough service probe:
> > > ? How to "Locate and identify service remapping or system redirects".
> >
> > Mmmm... maybe I've to read OSSTMM again, didn't remember that.
> > I understood either services listening on a different port than the
> > standard and/or web redirects.
> > For the first task, nessus will work very good (producing some false
> > positives), because it really interrogates an open port.
> > For the second, I'm not aware of automatic tools, but they'll become
> > evident while auditing the web contents.
> >
> >
> > > ? Use UDP-based service and trojan requests to all the systems in the
> > network.
> > > How to use UDP-based service requests to all the systems in the 
network.
> > NetCat, with the -u modifier, is an option.
> > nmap can also help you to determine which UDP ports are "open".
> > Nessus surely helps here as well.
>
> How they'll become evident while auditing the web contents? What I'll 
gain by 
> doing this task?

I mean that web redirects will become evident while auditing web contents, 
and perhaps I didn't make it very clear.
One of the first pieces of information I get from webservers is 
information about the servers, not the contents.
For example, with netcat (copied from a paper I'm writing):

$ nc webserver.example.com 80
HEAD / HTTP/1.0
{enter}{enter}
HTTP/1.1 200 OK
Date: Wed, 18 Dec 2002 12:00:23 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.1
Connection: close
Content-type: text/html

With this simple use we got information about the webserver used and its 
version (Apache 1.3.26), the kind of OS (Unix), and additional programs or 
extensions in use by the webserver (PHP 4.2.1).
Currently is much more common for webservers to use HTTP v1.1, due to the 
use of virtual servers. We can interrogate such servers with NetCat as 
follows:

$ nc webserver.example.com 80
HEAD / HTTP/1.1
Host: webserver.example.com
{enter}{enter}
HTTP/1.1 200 OK
Date: Wed, 18 Dec 2002 12:00:23 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.1
Connection: close
Content-type: text/html

You'll see a redirect here in the response code (i.e. different from "200 
OK").
Other redirects (for example when a page you ask for didn't exists) will 
be also seen during the testing.
Again, it's not so easy to make a general recipe, because every server in 
the world is configured slightly different or at least has different 
contents inside...
I'm in the [terribly slow] process of writing a good paper on penetration 
testing, trying to make it useful for the real world, trying to put some 
real examples, but it's hard work, and I've many other duties...


> Thanks for everything.

You're welcome! Hope my comments are of help!


> Cheers!
>
> Indian Tiger, CISSP

Cheers,

Miguel Dilaj
aka Nekromancer



----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/