From: miguel.dilaj@pharma.novartis.com
Date: Wed Jan 15 2003 - 03:13:58 EST
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/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:27 EDT