[ILUG] SSH dictionary attacks.

[Badger]

On Fri, Aug 25, 2006 at 06:25:11PM +0100, Aine Douglas wrote:
> 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.
> -- 
> Irish Linux Users' Group mailing list
> About this list : http://mail.linux.ie/mailman/listinfo/ilug
> Who we are : http://www.linux.ie/
> Where we are : http://www.linux.ie/map/


Sorry Aine. Clearly your not in the mood to discuss this further and I'm
certainly not going to try and stong-arm you into doing so. I've been
asking questions and making statements because things just don't add up
in my mind. I had hoped the the answers would reveal themselves through
discourse, but it doesn't look like that will happen. It's quite possible
that all the answers have been provided but I'm just too dense to see 
them. 

I would just like to make a couple of points to finish, just to clarify 
where I was coming from. After all, I don't want this list left with the 
impression that I was making wild statements about security breaches.

My understanding is such that the Java does not natively support PKCS#12
format. Therefore, for a java applet to access a PKCS#12 filestore, it
needs extra code installed. Since this code doesn't ship with Sun's
JVM, I assumed that it was installed by the ROS at some part of the
signup process - hence my statement that "they provide you with the code
that extracts the key" from your keystore. 

Another statement that I made was that "they provide you with the code
to manage your private key". I said this because you previously said: 

     "Sing up at www.ros.ie and try and change the password for
     that PKCS12 file outside of the ROS system. Can't be done
     with any PKCS12 tool available."
     
     and then in a later
     
     "So your ROS java applet does that operation on the
     password you enter before applying the password
     to the security libraries, and similarly, if you
     change the password, once your password passes the
     policy requirements, it is xor'd and the last bit
     flipped and applied to your P12 file, and a copy of the
     cleartext password sent back to the ROS system over PKIK
     communication where it is archived for customer support
     reasons."
     
I read this to mean that you could only really manage your key with 
the java applet provided by ROS - not with standard tools like openssl.

When I added this up in my head it said that the same entity (ROS) that 
the held you accountable for the use of your key was the very one who 
controlled your access to your key. Personally, I would not like to 
be held accountable for my signatures under such circustances.

>From a detailed technical veiwpoint I would rather that the code 
from ROS or whoever to run in the java sandbox and make calls to the 
standard java crypto libraries to request (rather than arrange) a
signature from me. I would also like to be able to have full control 
over how my private key is stored so that I can use standard tools like 
openssl to protect it. But I guess we can't all get what we want.

No need to reply to this, I just wanted to show that there was some 
trace of logic in what I was saying.

As for the other points, I'm sure you were right and I was just 
confused. I'll take a look at the RSA Faq, thanks for the tip.

- badge