Next message: Steve Chapin: "Re: Penetration test report - your comments please?"
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
johnat_private
-----Original Message-----
From: Brian Nottle [mailto:bnottleat_private]
Sent: Friday, June 01, 2001 5:45 PM
To: peteat_private; pen-testat_private
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" <peteat_private>
To: "Brian Nottle" <bnottleat_private>; <pen-testat_private>
Cc: "bacano" <bacanoat_private>; <netw3at_private>
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:bnottleat_private]
Sent: Thursday, 31 May, 2001 05:32
To: pen-testat_private
Cc: bacano; netw3at_private
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" <bacanoat_private>
To: <pen-testat_private>
Cc: "Curt Wilson" <netw3at_private>
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.>/<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
This archive was generated by hypermail 2b30
: Sun Jun 03 2001 - 09:58:01 PDT