Next message: John M. Millican: "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
: Sat Jun 02 2001 - 07:10:41 PDT