RE: Penetration Testing using OSSTMM

From: <miguel.dilaj(at)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 
        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

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

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
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
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
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!

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/ Received on Thu Jan 16 13:23:02 2003