finding SSL "master key" on a local machine

[nihil]

What I want to do is to look at the packets inbound for my PC, to see if they contain information of other clients that should not be sent. The packets are encrypted with SSL, but since they are being sent to my PC the informaion to decrypt them must be on my PC.

Sorry brm I missed that first time. Its's the no doubt.

Hoss has the best solution for you. Just sniff what you are receiving and check the (plain) headers to see if they belong to you. If you are getting other people's stuff then they are probably getting yours as you have suggested.

They key won't be on your computer, it will be on theirs, so your key is actually irrelevant. The issue is can the packets be cracked? the answer to which has to be "yes" but with what effort?

I think that I have addressed several of the other issues?

Basically, if they are sending stuff to you that you should not be getting, then they need to sort their system out, if only because it is a gross waste of bandwidth?

[brm]

The bandwidth wasted by sending this information would be negligable (less that 10 bytes).

I'm sure the inbounds packets would "belong to me", but I an concerned that the information in the packets is something that does not belong to me. The application discards this information, but I have reason to believe someone else is exploiting this.

I know this will take a good bit of effort to accomplish but it would be well worth it for me.

The SSL private key will be on there server and i will have no access to that, but the future information is not encrypted with the private key. After handshaking the future communication is is with a client generated symetric key (that i would have to have). I realize that this is not "hard coded" and it will be different with each connection. But even identifing this key after or during the connection should help me analyze past packets to see if the information is there.

If i determine that this flaw is not there I willl post the application, and why I became suspicious. If it is there I will concact the developer and give them ample time to fix this problem before posting this. It will then be apparent why I'm going to this much trouble to find this out.

[zencoder]

Originally posted here by nihil
They key won't be on your computer, it will be on theirs, so your key is actually irrelevant. The issue is can the packets be cracked? the answer to which has to be "yes" but with what effort?

Ah, not true! If I am correct in my beer sotted recollection of SSL, then they are sharing a symmetric key...at least per transaction...so they both have to have said key!

Hoss, I *like* feeding the bears...and when they get cranky, you don't have to run faster than the bear, just your mates.

[cacosapo]

Originally posted here by zencoder
[B]Ah, not true! If I am correct in my beer sotted recollection of SSL, then they are sharing a symmetric key...at least per transaction...so they both have to have said key!

You are right. TSL/SSL uses a session key that is a symmetric key - obviously its a shared symmetric key. SSL/TLS uses a secure tunnel to negociate/transfer the symmetric key using an assymetric key. SSL session key is both computers. But i dont think that any server software stores the session key on disk It is silly do that, isnt it?
So, the answer is: Yes, you can crack the packet. But the resources need to break a 128 bit symmetric algorithm are not easy to get; and since its a session key you must capture ALL packets, save and try to break the key later. But all efforts will work only for those sessions packets.

[nihil]

zencoder

My initial understanding was that brm was receiving packets that don't belong to him, but, following his last post, that does not seem to be the case.

My comment was based on the assumption that if the data belonged to someone else, they would have the key not brm. So his key would not open their packets.

He seems to be suggesting:

1. That the incoming packets contain information that should not be there.
2. That the application drops this information.
3. That "someone" is exploiting this information.
4. The data is less than 10 bytes (my credit card is 19 bytes?).

I am afraid it is not a scenario I can envisage that well. Like how would anyone know it was there to be exploited?

Also, having had many years' experience of full lifecycle applications development, I find the concept of a field with no purpose, suddenly finding itself in a transaction and automagically getting populated with someone else's data very, very hard to swallow.

Errr, unit testing, systems testing, user acceptance testing.................all done in "plain" and no-one spotted it? The encryption is just something added on to the back end.

My approach would be:

1. Capture some packets and look at the plaintext content (which I would expect to be the header). If there is nothing suspicious then:

2. Contact the developer and advise them of my concerns and the reason for it.

3. If they don't convince me, get another application, or look elsewhere for the cause of my suspicions.

[brm]

What I'm trying to get at is that the session key has to be stored on my computer. I'm not trying to crack the encryption. I just want to find the session key on my computer (the client). Once I have this I should be able to analyze the packets. My best guess now is to do a memory dump of the program while in a connection and using standard SSL ciphers (i dont know if there is more that one) try every 256 bit block of memory (i realize this may be thousands) as a key on a packet that i know contains a certain string of text until i get a match. This should reveal the key for that session, and then i should be able to analyze other packets for this session.

I was hoping someone might have some time saving advice before I get started on this.

[brm]

nihil, I think you have a good understanding of the problem now.

I have analyzed plain part of the packets, nothing suspisious there.

The developer has been contacted, but denies a problem.

I am currently not using the application in a way i could be exploited but there is a large community that uses this app it a way that they could.

and yes is possible for a bit of information less than the size of a credit card to be very valueble.

[cacosapo]

My best guess now is to do a memory dump of the program while in a connection and using standard SSL ciphers (i dont know if there is more that one) try every 256 bit block of memory (i realize this may be thousands) as a key on a packet that i know contains a certain string of text until i get a match.

Although it may work, but i dont that anyone will keep a session key in storage without at LEAST obscure it with a XOR or something like that.
But if the packets are hitting your pc, why not get the info AFTER it has been decrypted by SSL? inst easier?

[nihil]

cacosapo Hi, I see what you are saying, I guess it all depends on how the application works?

If it receives packets, does a raw decryption, then processes the data, what you say might be a much better method. If, however, it does the decryption and processing as a seamless activity, it may just populate a temporary workfile with the data that it requires, having already dropped the superfluous field.

brm

I do hope that you carefully read my comments on systems testing based on twenty years of applications development experience in structured environments. I will repeat, strange fields do not appear out of nowhere and get populated, transmitted and processed at the other end.

AT THE VERY LEAST I WOULD EXPECT THE CLIENT APPLICATION TO REJECT IT BECAUSE THE DATA WAS THE WRONG LENGTH/FORMAT!

Soooooooooo? where does that leave us?

1. The attack vector is quite different from the one you envisage.
2. This is a deliberate scam/fraud, and the system actually contains a back door of some sort?

The developer has been contacted, but denies a problem.

That tells me that you will not find anything

Which is NOT the same as saying that there is nothing wrong.

Think about it?..............instead of posting here you could have just sent it to the FBI, DOJ or whoever. They have the resouces to investigate this in a very short time? So if the developer does not think that there is a problem, it means that they know you will not find one. At least not looking where you are.

I assume that it has crossed your mind that the developer may be less than *cough* honourable *cough*

Perhaps you might consider submitting your findings and concerns to the FBI, DOJ, SECC, Gambling Commissioner or whoever? After all, they have the resources that we do not.

Hey we don't even know what it is...........I haven't even got the compiled client objects to reverse engineer (not that one would do anything like that?)

I wish you luck, but assure you that you will not find anything following the route that you are.

But, I will leave you with a local expression "if you can smell smoke, it means there's a fire somewhere"

Cheers

[mohaughn]

My best guess now is to do a memory dump of the program while in a connection and using standard SSL ciphers (i dont know if there is more that one) try every 256 bit block of memory (i realize this may be thousands) as a key on a packet that i know contains a certain string of text until i get a match.

This was my thought on the matter. If you need a tool to do the memory dump on windows go to this website and download the Microsoft debugging tool kit. MS DTK.

http://www.microsoft.com/whdc/devtoo...nstallx86.mspx

The tool you will want to use is called adplus. The syntax will be something like:

adplus -hang -p "process pid"

Here is an article that describes how to use adplus to hang a process and generate a complete memory dump of what that process has in memory.

http://support.microsoft.com/default...n-us;286350#6a

Your on your own as far as reading the memory.