[ILUG] SSH dictionary attacks.

[Aine Douglas]

On 8/25/06, Badger <badger at scattermail.com> wrote:
>
>
> I agree with what Colm Mac Carthaigh said in the alternate reply
> to your post Aine, but I just wanted to drill down on some of the
> other points:

What Colm said was that anyone could implement their own tool using
the PKCS standards, break the standard and make it do something
entirely different. Sure. Thats a given which wasn't worthy of a
response. I could re-write a webserver and make it a mailserver. You
could rewrite a telnet tool and make it talk SSH. You could turn a
road into a canal if you build walls and add tanking. Woop de doo.
Thats all given. Its old territory, "hackers" have been doing it for
years, re-writing ls so that it doesn't show their files in a
directory listing.

> On Fri, Aug 25, 2006 at 11:35:53AM +0100, Aine Douglas wrote:
> > On 8/25/06, Badger <badger at scattermail.com> wrote:
> > >I'm not sure that I fully understand your description of the
> > >ROS service. For instance, when you say the user's password is
> > >XOR'd, what exactly is it XOR'd with? Also, could you clarify
> > >if there are two passwords in operation: one for the private
> > >key, and one for the keystore (the pkcs12 file).
> >
> > A PKCS12 file is both, check the RSA faq for more details. I forget
> > what its XOR'd with, probably itself, or itself backways. If its
> > really important to you, I can check it out, still have the rebuilt
> > code here somewhere.
> >
>
> Well it's not going to be XOR'd with itself and then have it's last
> bit flipped - they'd have just used the number 1 instead. In asking
> this question I was trying to ascertain whether the password for the
> file was trivial to attain from the password the user provided. From
> your reply I gather that you think it is a trivial transformation. If
> this is the case then it should also be a trivial matter for someone
> to write a tool that changed that password to something that defies
> the company password policy.

The specifics are unimportant. The point is that you can adopt
standards, tried and tested standards, and through a software scheme
implement password policies that cannot be readily changed with other
software which implement the same standard.

Sure Colm will come back and say, but IF someone else implements your
modification on the standard they can break your standard. Sure. Thats
a given. Which takes more effort? reverse engineering software and
re-writing it or remembering a password that conforms to a password
policy? People take the path of least resistence. Anyone with the
technical capabilities to decompile, de-obfuscate, and re-implement
the code won't be making a dumb password anyway.

Ok... so then you come back and say, but they could release it to
everyone and anyone. Sure. And when they do, I'll just revoke all the
certs and change the scheme. But they'll just go and break that? Then
I'll just give certs a validity period of a week and change the scheme
weekly. Its trivial to do on my end and will take the "attackers"
longer to re-engineer the scheme than the scheme is valid for.
However, for a password, they won't go there in the first place as ts
a dumb proposition.

> It's possible that it's not a trivial transformation though - perhaps
> it uses a private key on the ROS server to generate a HMAC of the
> user's cleartext password which is then sent to the client to be
> XOR'd with the password the user provides, or something like that.
> Under these circumstances then, it would not be trivial to write a
> tool to change the password/passphrase which guards the users private
> key. Having said this, it's important to note that nothing like this is
> covered in the PKCS12 spec.

Trivial transformation or not, it serves no direct security function
whatsoever. All it does is prevent use of the PKCS12 file in other
tools which implement the standard. That is an indirect security
enhancement through preventing private keys being imported into
insecure keystores such as a webrowser keystore. Nothing more.

> I'm no security geek, so please patch my understanding if you see fit.
> I've skimmed through the PKCS12 spec as posted at:
>
>    http://www.rsasecurity.com/rsalabs/node.asp?id=2138
>
> Is this the document that you are talking about when you say "RSA faq"?
> If not, could you provide a link to the document you are talking about
> as I would like to understand this stuff a lot better than I presently
> do.

http://www.google.ie/search?hl=en&q=rsa+faq&meta=
its the very first hit.

There are independent docs on the standards which go deeper into the
specifics, but for an understanding of anything in encryption, the RSA
FAQ should be your first port of call.

> Found the following document from Peter Gutmann (Professional Paranoid
> and author of the Godzilla Tutorial) quite amusing:
>
>    http://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html
>
> It's titled "PFX - How Not to Design a Crypto Protocol/Standard".

The content is very vague, and where it is specific he talks about
confused standards. For a coporate level PKI rollout, thats sweet,
you'll buy everything from Baltimore or RSA and implement against
their ca's using their toolkits and have no problems, the guys in
Colm's organisation so hell bent on setting weak password will
implement their stuff using something like Bouncycastle and have
compatibility problems. Superb.

That is, if and only if there are such compatibility problems through
confused standards as he claims. Bouncycastle implementation works
fine with P12 files from both RSA and Baltimore CA's and a few others
I've worked with. I've yet to come across any issues.

> > There would be legal implications of that with respect to non
> > repudiation, and ROS couldn't actually legally depend on signed tax
> > returns in such a manner. The key must be in the posession and control
> > of the signer. Thats stipulated by law. Hushmail provide a secure
> > communications platform, they're not interested in the legal validity
> > of digital signatures for the purposes of non repudiation.
> >
>
> That's a fair point about the legality of the situation, I hadn't
> considered it from that perspective. It's ironic though, from a
> technical point of veiw I would imaging that keys are a hell of a lot
> less likely to be abused when they are sitting encrypted on Hush's
> servers, than when sitting password-protected on the average
> user's hard disk.

Think about it. If I make a false income tax return I can be
imprisioned for it. If I can claim I didn't sign the false
declaration, I can't be held liable for having filed a false income
tax return.

> While the private key is in possession of the user, I think it's more
> than a stretch to say that it's in their control. Even though this is
> somewhat off-topic, I comment on it more below.

If I use a software applet on my computer, to read a keystore which
can only be read from my computer, use my password to unlock it, and
ask it to digitally sign a return, that places the entire transaction
in my control because everything is in my posession.

> > >The actually service carried out by ROS occurs over a closed
> > >protocol. I imagine that if you could reverse engineer your own
> > >client that could communicate with the ROS server using that
> > >protocol then you could store the private key in plaintext if
> > >you wanted.
> >
> > No. The PKCS12 format does not permit this, check the RSA faq...
>
> Perhaps you could elaborate on what you understand PKCS12 to be. From
> what I understand it can be used for (at least) two different things.
> First, it can be used as a basic keystore format for saving you private
> keys (and a bunch of other stuff). And, Secondly, it can be used as a
> transit envelope to transfer personal information from one computer to
> another. In the second case, the "personal information" is usually
> private keys in PKCS#8 format that are symmetrically encrypted in
> their own right.

What I should have said was the PKCS12 standard doesn't permit this.
As Colm pointed out, the file itself does nothing to prevent it. If
you break the standard you can do anything you like.

> I would imagine the ROS are using PKCS12 as a keystore format only (as
> in the first case above). Their applet would access the PKCS12 keystore
> (utilizing code that is not in the Java Standard library since PKCS12
> is not natively supported in Java) to extract your private key. After
> extracting said key and using it to sign tax return, the applet would
> submit that tax return via a HTTP post. I doubt that ROS would
> bother to use PKCS12 on the wire (second case above) as a format to
> transmit your tax return - what would be the point?

Probably.... its really such a moot point at this stage its sickening...

> Thus, if I were to reverse engineer a client I could store the key on
> the disk in plaintext bypassing the whole PKCS12 thing altoghther. In
> other words, the 'PKCS12 format' would not be in any position to permit
> or restict my client.

Sure you could also format your PC and wipe the sob out of all
existence if you wanted. You have the freedom to do anything you want,
go break a leg.

> It's a little off-topic, but it's worth noting that the ROS were a
> corporate, rather than a Governmental, entity, it's highly unlikely that
> the would have been able to role out such a service:

Well, until the Department of Finance outsources the Revenue
Commissioners roles in socitey to a private firm, you are absolutely
and entirely correct.

> - They provide you with your private cert

Private key perhaps? The public key pairing for which can signed by
their CA turning it into a cert. Anyway, there is nothing untoward
about this at all, its called "enrollment".

> - They keep a copy of your passphrase for customer support reasons

Which can only be used to unlock your keystore which is only in your posession.

> - They provide you with the code to manage your private key

No they don't.

> - They provide you with the code that extracts that key for use

No they don't.

> - They probably use the standard java api to sign with the key

I can't remember if they do or don't. They probably drink beer and do
a whole lot of other normal things too.

> It's comical that all of this exists so that the user of the ROS
> service cannot repudiate a signature made with 'their' private key. If
> your local bookmakers provided you with such a fancy service which
> allowed you to place bets on credit with them, would you use it?

I don't see your point, nor your comedy, and quite frankly, I don't
care to see it. You're making points alluding that there is a breach
of security possiblity possible without actually stating the security
breach. If you do state it, you'll be stating something that in all
probability is not possible. But go on state it, because unless there
is someone here from Ros nobody here will be able to definitively
comment on it anyway, hence, you'll receive no response at all!

Are we done?

Aine.