Indian Tiger <indiantigerat_private> 15/01/2003 07:31 To: Miguel Dilaj/PH/Novartis@PH cc: isecom-newsat_private, Pen-test <Pen-testat_private> 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 2b30 : Thu Jan 16 2003 - 10:06:18 PST