Penetration Testing mailing list archives
RE: Penetration test report - your comments please?
From: "John M. Millican" <john () nctech org>
Date: Sat, 2 Jun 2001 15:00:37 -0400
Can we all just agree that the statement was too flat? Ultimately, no matter how much time is spent or how thorough the tests are, all risk statements break down to "the system is secure against the testing procedures utilized". Once this statement is made, it is then appropriate to describe the testing procedure utilized and why that particular methodology was chosen. This could include a clear statement regarding any client imposed constraints on the process, and the impact of those constraints on the results. This makes the consultant responsible for what they were retained to do and the client responsible for establishing the scope of the assignment. John M. Millican New Concept Technologies john () nctech org -----Original Message----- From: Brian Nottle [mailto:bnottle () telus net] Sent: Friday, June 01, 2001 5:45 PM To: pete () ideahamster org; pen-test () securityfocus com Subject: Re: Penetration test report - your comments please?
From the responses I was apparently not clear about
my main message - "Do not assume unnecessary risk" I agree with many of the opinions that you want to include, because they reduce your risk and inform your clients. To be specific: FIRST NOTE: My (non-expert) understanding of this area of the law is that a person who lets it appear that they are competent in a professional matter are legally liable if they do not perform to the level of an Expert. So, be informed I have NO claim to competence in the Law. - Any way, I think that to state your opinion that a system is likely secure after doing testing that all involved agree was limited, is definitely assuming unnecessary risk. Why? Because you can be sued for "misleading" the client, if a later hacking attempt succeeds. - Advising that testing was limited and that undetected weaknesses may remain, although partly opinion, is NOT assuming any risk. On the contrary it is a comparatively weak, but very useful, form of disclaimer that shows the limits of the work done. Say it every time it is true. (A real disclaimer essentially says the you cannot be held liable for anything, not even if the work you did was useless or misleading. Unpleasant but true, look at any software User Agreement) - Ultimately the choice is a personal one. Until there are law suites in this area, I will just sound paranoid. If and when they occur (I think it is a matter of time), the degree of caution required will depend on the judgments made. Examples that a scary are the small aircraft industry (90% of new plane cost is for liability insurance), consumer product design engineers, all medical doctors. ----- Original Message ----- From: "pete" <pete () ideahamster org> To: "Brian Nottle" <bnottle () telus net>; <pen-test () securityfocus com> Cc: "bacano" <bacano () esoterica pt>; <netw3 () netw3 com> Sent: Thursday, May 31, 2001 1:10 PM Subject: RE: Penetration test report - your comments please? Sorry but I have to disagree with this to some degree-- the customer is paying for our opinions as experts. Sure there is responsibility in stating an opinion which is why analysts who write reports should have proper training and education. Perhaps the opinion is overly simplified and doesn´t need to be worded as such, but it is very important to state your expert opinion. I like that you would say, x amount of time with y tools and z methodology but I think it´s also okay to say what wasn´t but should also be investigated due to possible dangers (like the network itself) and of course that would be opinion. -pete. -----Original Message----- From: Brian Nottle [mailto:bnottle () telus net] Sent: Thursday, 31 May, 2001 05:32 To: pen-test () securityfocus com Cc: bacano; netw3 () netw3 com Subject: Re: Penetration test report - your comments please? There is a clear risk in the way you have worded your report. It puts you, the writer, at unnecessary risk. In all professional reports, there is one basic rule that you must follow, if you are to survive in business. The rule is "Never assume any unnecessary risk" This means always stick to the facts in a report. NEVER say anything like, and I quote you "therefore it is likely that <sitename.com> is fairly secure" You can not know any such thing (not factually, it is opinion). What you do know is that you were unable to penetrate the site with the tools you used in the time you had. Period. That's all folks. Any more and you are providing the client with a clear reason to sue just as soon as they are hacked. Brian Nottle (former Professional Geologist) ----- Original Message ----- From: "bacano" <bacano () esoterica pt> To: <pen-test () securityfocus com> Cc: "Curt Wilson" <netw3 () netw3 com> Sent: Wednesday, May 30, 2001 11:22 AM Subject: Re: Penetration test report - your comments please? Hi2all,
Enclosed is a text report on a pen test I did recently. I was given
three
hours to attempt penetration from remote without touching any other
hosts,
using brute force, relying on DOS, social engineering or physical
attacks. Accepting that the level of a penetration test is a client option (leaving out those untouched topics), I wonder about the basis for limit the test for 3 hours ... I can't say that I would not do a test under that condition, because I'm not the 'boss', but I have strong doubts if less then a working day for tests and other for reports is aceptable.
I'm curious if I missed anything obvious, and would be thankful for
any
comments or suggestions from other penetration testers, especially if
you
are one of the people who authored one of the messages included from various security mailing lists. Thanks for any input folks.
I don't know about obvious, but if you by any chance missed anything under those conditions nobody can blame you ... at least I will not do that for sure.
Initial Audit and Penetration test: <company name>. Submitted by Curt Wilson, Netw3 Consulting
Because of the refered limitations in the test, it can be a good idea doing an introduction about *how* limited was the test, and that most likely something may be missing, at least comparing to the real effort that an attacker can make to penetrate that or *any* host.
I was unable to penetrate into the operating system or database within
the
allotted time, therefore it is likely that <sitename.com> is fairly
secure
from all but the most determined attackers or those with pre-existing
access. I would change this to something like "(...) therefore it is likely that only regarding the same tests/attacks reported here, that <sitename.com> is fairly secure." I may be wrong, but ethically speaking (and commercial too, from your - and also the client, at the end - point of view), a strong feeling that this test was not enough must be communicated to the client. (**)
Enumeration and penetration attempts: The nmap tool was used to scan
all
listening TCP ports and attempt to identify the Operating System.
Results
were obtained for TCP, but some mechanism is in place that blocked my
nmap
UDP scan and revealed that all UDP ports were listening (which is
obviously
not the case; this result is often caused by a firewall. An attempt to
scan
UDP from windows was also met with unreliable results). [root@premis netw3]# nmap -sS -P0 -n <IP address> -O Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ ) Interesting ports on (<IP address>): (The 1527 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 80/tcp open http 111/tcp open sunrpc 443/tcp open https 5432/tcp open postgres 8007/tcp open jserv 8080/tcp open http-proxy TCP Sequence Prediction: Class=random positive increments Difficulty=3308963 (Good luck!) Remote operating system guess: Linux 2.1.122 - 2.2.16 The TCP portscan can be made less attractive by the use of TCP
wrappers
plus a tool such as portsentry to block access from IP addresses that generate a number of connection attempts that exceed a set threshold.
Care
must be taken to ensure that a Denial of Service (DOS) condition does
not
result from an attacker sending spoofed or decoy IP addresses that
belong
to the systems upstream routers or other important clients or Internet access points. Such a condition could be easily fixed, however. TCP sequence prediction indicates that the spoofing of TCP connections based on sequence numbers would be a nearly impossible task. The basic Linux kernel has been resistant to TCP sequence number prediction
attacks
for some time. The remote operating system guess can be circumvented through kernel modifications, if this is considered important. Attackers use this information during a reconnaissance phase to determine attack
methodologies. This is a nice report of the situation, regarding the nmap scan ... but again i wonder, without the 3 hours limit, using also other tools/precesses whatelse could bring more results/information?
My attempts at implementing this null-byte exploit were met with
failure,
perhaps due to the limited time allocated to this phase of the
project, or
due to the possibility that the site is not vulnerable. The only thing
I
could do was to return a blank page instead of the logout or login
page for
the main case search servlet as such: http://www.<sitename.com>/<path>/<path>/<servletname>?page='\000\' Ensure that the java code is written in a manner to restrict use of
the
null-byte exploit technique. Java code checklist: http://java.sun.com/security/seccodeguide.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=coll&doc=secbull/201 &typ
e=0&nav=sec.sbl&ttl=sec.sbl Java security bulletin Feb 2001.
At this point it's clear that you feel that the time was not enough, and that you could not use all possibilites, so you can only say that using some specific technic the host is or is not vulnerable, but at the end the limited time had limited the possible results. Again, if you by any chance missed anything under those conditions nobody can blame you ... at least I will not do that for sure. Sometimes, it's also important to know who will read the report, at the client. Some technical, technocratic or burocratic dude? (**) For example, at the client, a CIO may had limited the test for 3 hours (God knows why ... but a lucky guess, for you can't find 'those thangs'?) and a CEO (who wants to know where the money goes) may consider things in other way, to have the conclusion that the test was not ok (and it was not your fault!). And since there are some nasty badhass CEO's around, I hope you will not find one saying "I'll not pay for this shit!! now sue me, who cares ..." Of course the CIO can always say "no no, it was a lovelly test, pay the guy. We are secure, lets forget this and go to real important things" ... or is just me that is watching too many movies and reading too many novellas =;o) [ ]'s bacano
Current thread:
- Re: Penetration test report - your comments please? R. DuFresne (May 31)
- <Possible follow-ups>
- RE: Penetration test report - your comments please? pete (Jun 01)
- Re: Penetration test report - your comments please? Brian Nottle (Jun 02)
- Re: Penetration test report - your comments please? Steve Chapin (Jun 03)
- Re: Penetration test report - your comments please? Brian Nottle (Jun 02)
- RE: Penetration test report - your comments please? John M. Millican (Jun 03)