Re: Penetration test report - your comments please?

[Curt Wilson <netw3 () netw3 com>]

Brian and everyone, thanks for the comments. I will modify my
procedures and methods of doing business. One thing that was not
communicated clearly through the posting of the report was that
there were several meetings with the client and clients
development team to discuss issues in detail. They are aware
that the assessment/pentest was of limited scope and they
are OK with that.

The technical issues are what I find most interesting, but
doing business in a sound manner is equally challenging and
I appreciate the chance to discuss with other security
professionals.

Curt Wilson
Netw3 consulting
www.netw3.com


At 08:31 PM 5/30/2001 -0700, Brian Nottle wrote:
> 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


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Curt R. Wilson   *   Netw3 Consulting  *   www.netw3.com    |
|    Internet Security, Networking, PC tech,  WWW hosting     |
| Netw3 Security Reading Room : www.netw3.com/documents.html  |
|  Serving Southern Illinois locally and the world virtually  |  
|            netw3 () netw3 com     618-303-NET3                 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=