Re: [PEN-TEST] Your opinions are solicited ...

[Paul Robinson <paul () AKITANET CO UK>]

On Mon, 30 Oct 2000, Jim Miller wrote:

> .. on the configuration of security for an Internet application to be
> ddeployed.  The bank that I work for is planning to deploy a cash mgt
> application on the internet.  They propose to secure the application and
> its face on the Net with SSL and MS Certificate Server.

Can we infer that by using MS Cert Server that you are also planning on
rolling out IIS as your web server? If that's the case (and it may not be,
but just humour me a moment), you may want to re-consider. There are a bunch
of "armoured" http servers out there that will do a far better job than IIS
at ensuring that "rogue" requests get put to sleep quietly and most of them
only cost a few thousand dollars for a fully-audited solution. I'm sure the
guys on here will have their own reccomendations on this one. Personally, I
like Zeus which although not sold purely on security merits, allows for a
strong configuration with high-performance etc.

> The sessions will be protected from Net snooping by SSL's 132 bit
> encryption, " as strong as IP tunnelling".

So, you're assuming that IP tunneling is strong enough. SSL is a good start,
but don't just stop there. Smile.co.uk is one of the UK's largest on-line
banks and they appear (although I've not prodded enough to take a proper
look) to load a Java applet on the client's machine via SSL, and then this
applet has it's own stronger encryption going on, over the top of SSL. At
least, that's what it appears like, and seeing it's dog-slow even for Java,
and the login process involves a "seeding" process by moving the mouse around
I wouldn't imagine I'm far off the mark. Oh yeah, they also claim to be the
only on-line bank in the world to have gained a BS7799 accreditation. You
might want to give them a ring. :-)

> Access will be controlled by installing a certificate on each remote
> client.  The installation is done via download from the Certificate Server,
>  but is a manual process:  the remote will request the certificate and the
> server will download only after a process is started by support.

As others have pointed out you're entering a nightmare of support at your end
here. You're going to have to look after the issuing and revocation of
certificates which gets hideous. I've just spent the last 5 minutes working
out how I would write a system to handle this in a secure and reliable
manner, at reasonable scale (assuming your bank has quite a few customers)
and my head is already starting to hurt. Your main problem is that you are
then trusting a machine that has that certificate installed without appearing
to take into account that it may be a shared machine (any of your customer's
college students working in labs?), and that the user is only ever going to
do this from one single machine. I think it's probably a solution best suited
for the WAN/tele-working market than what you are proposing, but I'd have to
do some more reading up on the matter.

> The IT staff is unsure where the certificate resides on the client.  They
> suppose it to be both file based and in the Registry.  They have tried the
> "certificate export" process in IE and found that it will not export, so
> they are satisfied that it provides the level of security required to
> secure a cash mgt application.  They note that the HTML page presented to
> IE without the certificate is an error page.  There is no way to get at the
> certiciate on the Net site.

You've just showed your hand a little too much with this paragraph. You are
trying to deploy a security solution you don't fully understand. This is a
mistake. Can I suggest that before you even think about going any further,
you sit down with some manuals and attempt to learn as much as possible about
how this is working, because otherwise you are likely to make mistakes early
on in your development process. In fact, I think most people subscribed to
this list make their money from pointing out holes in systems that the
developers and admins deployed without understanding completely.

> The cash mgt application has its own security, but I note that it is
> application level security, and that using only logonid / password
> authentication across the Net is generally held to be a mistake.

Hmmmm... not true. The problem you have is that login/password is weak, but
you can toughen it up relatively easily, just not very well. For example, you
might go to Amazon who on the face of it try to strengthen this up a little
by using cookies (but then we go back to the problem of shared computers) in
addition to passwords, e-mail notification, etc. but you can do even more
than this. IP authentication is a nice start espeically in on-going sessions
to stop hijacking cookies, but it still isn't quite there.

Think about how your bank does "authentication" in the real world. Signatures
are used widely in the real world, and on the whole don't work that well -
how often do they really get checked? Electronic signatures are better by
far, but then we're getting into the whole certificate issue again, and there
is real loss of functionality inherent in that solution. If I phone up and
query something with a bank, they might ask me my mother's maiden name which
can easily be found out, so we're onto a no-starter there as well.

The best on-line banking system I've seen handles this by requiring you to
answer a whole group of questions at registration. Every time you log-in you
get one of these questions to answer, in addition to having to know a pin
code, and all the account details. It's still not brilliant, but it's
portable, more secure than just one question/answer, but your spouse probably
knows you better than you might think and might successfully guess the
answers to the questions.

Thinking about it, I'm starting to warm to the certificate solution again,
but I'm still not convinced.

> I have recommended using VPN, now readily available in Win2000, but have
> been rejected.  "A support nightmare." was the reason given.

There are commercial products that make this a bit more viable, and when I
went around about 6 months ago to the vendors and started talking about
deploying a few thousand copies, the price per machine dropped rather
dramatically. The standard these days is so easy, that I reckon my Mum could
work out how to use it given a piece of A4 paper with instructions covering
one side. You still have that whole "shared computer" thing to worry about
though, so you're still going to need strong authentication.

However, you're moving the support issue to the client, and your solution
keeps the support issue on your side. OK, I'm starting to slowly agree, the
more and more I think about this. :-)

> What do you think of the security schema planned?

In principle, not a bad stab. I think there is some clouding of issues
between securing the communication between the client and server, and
authentication that is making people give conflicting advice however. I also
think you haven't thought about the all-possible-uses scenario in that you
appear to be rolling out a solution that is perfect for a customer running
IE5 or Netscape 4.x on Windows, and who is the sole user of the machine. You
are running a great chance of 10% of users phoning you up and complaining
that it doesn't work. Tricky.

> What schema would you use?

I'd probably favour the Java applet doing crypto over crypto solution, with a
large set of human "authentication" challenges. It's portable, simple (well,
I can wirte Java, so it is for me), and allows you to not worry about
securing a cert server, just get yourself a decent bullet-proof webserver. In
addition I'd probably do some session-authentication with changing cookies
per transaction, combined with IP authentication. Oh, and don't forget that
you're only covering half the problem here - you still need to choose the
right server platform and tighten the security down there as well, and
preferably on every machine on the network. Don't trust the packaging on
switched hubs that say traffic can't be sniffed - assume everything on the
network to be a potential threat to you.

> What do you think of the reason given for not using VPN?

Understandable, but weak in that if this is the only communication you got
back, you guys need to go on a team-building exercise or something. The least
I would expect is a *reason*! At the end of the day, the absolute most you
want in an ideal world on the client's machine is a web browser. What's more
it should work with any browser. This is of course, impossible, but to ask
customers to fiddle with the things in the Control Panel is probably asking
for trouble, and I'd hate to think what your lawyers and insurers would think
when the word "liability" came up in conversation over this. It's a good
solution, but one that is best suited for a corporate WAN/tele-working
environment rather than a consumer application.

> I hope your conclusions will be the same as mine.  To make my point, I will
> most likely have a URL for testing later in the week.  If you are
> interested in hitting against it, please let me know directly.  Any
> questions I can answer to clarify, please let me know.

You're new to this list aren't you? Do you know how much a pen test costs?
No. Hmmm. Well, expect people to look at the URL for ten minutes, tell you
it's broken beyond belief, and you're going to have to give them $30,000 for
a 2-week pen test to come and fix it for you and give you a report to give to
your managers explaining why you are so terrible at your job. :-)

I liked the approach though - but I doubt you're going to get a free pen test
out of this.

--
.------------------------------------------------------------------------.
| Paul Robinson - Technical Director @ Akitanet - http://www.akita.co.uk |
|------------------------------------------------------------------------|
| T:+44 (0) 161 228 6388  F:+44 (0) 161 228 6389  E: paul () akitanet co uk |
`------------------------------------------------------------------------'