finding SSL "master key" on a local machine

[brm]

I have recently become interested the information a program (non-browser)sends and recieves from a server. the program is propietary, uses SSL and i have no access to the server. I was wanting to analyze the packets. but to do this i would need the master key generated during handshaking, correct? Is there a ususal place the key is stored? I'm guessing it is probaly just stored in memory, but i I guess it could be stored in a temp file too.

anyone else ever attempted something like this?
Is this under the right topic?

any help apprieciated

BRM

[nihil]

1. What program is it?
2. What operating system is the server running?
3. What operating system is the client running?

As you are on the client side what is your concern?

1. That what you are sending to the server is getting adulterated, or

2. That the replies you are recieving are?

Your question is a little too vague at the moment :)

[brm]

I am running the client on windows 2k, but it runs on 98 and above i think. I have no clue what operating system the server is. I am mainly concerned about the incoming packets.

My main concern is that my sensative information is being sent to other identical clients. The clients do not show any of this information but I have reason to believe that some other security smart people are able to analyze the packets inbound for there client to get information of others. Although I have doubts as to this security flaw, as it would be the result of some very bad design, it is definatly worth my time in checking this out.

I am going to withhold the name of the program and the nature of it untill i finish my investigation. I hope that clears some stuff up?

I have googled the app thoughly and have not turned up any know problems with it.

[nihil]

Ah! yes,

You might like to activate your privatel messages (PM) option, that way you can send someone information that you do not wish to share with the world at large.

As this would constitute a private conversation, slander and defamation actions would be nullified.

OK, please let me get this straight in my own mind.

You are running a Win2K client and use an application on a server?

The server responds to you, and you wonder who else may be getting this information?

Well, as you say it is not a browser I will assume we are talking about a local area network?

So, you don't need to know what is in the packets?...........you know that, they are yours?

What you want to know is what anyone else could find out/ intercept?

Sorry, it is a national holiday week-end, and I am a little slow :D

[brm]

Sorry, Im new to this site. I think all my PM options are turned on now. and no need to apologize for any misunderstanding.

The program uses client/server architecture. The client runs on my PC.

The server is on the internet, no LAN.

I have reason to believe that when communicating to another client via the server, that information is sent to the other client that shouldn't be sent. The client does not make use of this information, but someone could sniff and decrypt packets sent to their PC to obtain this information.

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.

It is my understanding (which may be very poor) that once SSL handshakes a "master key" is generated that all future communication is encrypted with. Also this master key is used to generate "session keys", which might really be what i need to view the information in the packets. I was just curious where to find these on my machine.

Once I have found the location of the key or keys i need i should be able to write a simple sniffer using some ethereal source and some openSSL source to display the information in the packets, and hopefully disprove my theory.

I realize this might sound a little odd. but if someone could even point me in the direction to figure this out it would be very helpful.

BRM

[zencoder]

Originally posted here (http://www.AntiOnline.com/showthread.php?threadid=267958#post838287) by nihil
Sorry, it is a national holiday week-end, and I am a little slow
That means he has been drinking and is likely 'pissed' as they say on the Emerald Isle.

And whether the "little bit slow" part is due to drink or genetics, we leave that to the readers opinion. ;)

Keep in mind that in this process of trying to break the encryption (that is what you are doing, regardless of why or how you describe it), you may well could be violating the EULA, licensing requirements, and the law.

Just a heads up.


I can tell you a bit of high level cryptography and how it applies to SSL. Please bear with me; while not a national holiday, it is late Sunday and I have been indulging as well.

There are two basic forms of encryption, symmetric and asymmetric. Symmertric is a single key that is used with the protocol to encrypt and decrypt the data in question. Symmetric algorithms tend to compute a lot faster than Assymetric, but they are vulnerable because both parties must have the same key to use it...sharing that key can be problematic, since if it is sent in the clear, it could be intercepted and used by a third party to decrypt the data.

Assymetric deals with a key-pair...sometimes referred to as Public Key Cryptography. Asymmetric is based on 2 "really big prime numbers" and is usually only a one way encryption. This means that if you encrypt data with key A, you can only decrypt it with key B (not even key A can decrypt its own data). So, you give everyone key A (the public key), and keep key B (the private key) secret.)

So, the problem with SSL is you can't use Symmetric encryption because everyone has the key, right? So you do it with 'session keys'. The application creates a symmetric key for your session, and it is shared with the client and server...but the problem of sharing the key securely still exists. This is where Asymmetric encryption comes in...the client and server each have key-pairs and should have the public key of the other. They authenticate to each other, and then the session key is encrypted by the server and sent to the client with the public/private key pair.

(Please note this is a pretty fast and crude explanation. It probably has some errors in the details, but it should give you the general point.)

So why this whole Cryptography 101 post? Because, if you are using SSL and it is a Symmetric protocol, then your system MUST have the key somewhere, somehow. But these are generally well protected. So yes, you have the key...if it's symmetric. But if it's Asymmetric, well...good luck cracking it.

I think you are better off working directly with the application developer, looking into EULA legalities and their business practices, then trying to crack open the encryption just to see what data is sent where. Also...you will very likely have to do CONSIDERABLE reverse engineering of the application as well, to see what, if anything, is done with the data.

[brm]

Yes I have done some reading on public key encryption, with SSL in paticular. it is my understanding that SSL uses an asymetric key (public/private) to establish the connection and to verify the server is who it says it is, but then passes a symetric key that all further communication uses. and this key is usually a standard 256 bits.

I have found a temp file that changes everytime a new connection is made, it is just over 256 bits.

Is there any standard way of storing this key? maybe a few bytes lead or trail (or both) this key.

The developer would deny anything unless proof was shown. I'm sure doing this would violate their licensing agreement, but I can say with confidence It would not violate the law.

As far as the reverse engineering goes, It should be fairly simple(once decrypted). plus it is right down my alley.

would there be anything to tip off a possible key in a temp file or a dump of the application's allocated memory? I can't think of anything that would stick out, since at first glance it would look like random bytes.

[thehorse13]

My main concern is that my sensative information is being sent to other identical clients.

If your only concern is that data is going to hosts it shouldn't then there is no need to crack SSL key pairs. Fire up a sniffer and look at the packet headers. The headers are not encrypted and will show you precisely where the packets came from or have gone out to. The data payload is not necessary to determine if information is going places it shouldn't.

As for the rest of you, tsk, tsk. Don't feed the bears.

;)

[nihil]

Hmmm,

I think I see the issues now. This is really a composite security question is it not?

This may be of interest:

http://216.239.59.104/search?q=cache:Mb5QYk2Ccc0J:www.moonhaze33.net/ncfcdocs/psst.pdf+SSL+strength+tool+measurement&hl=en

Basically what we are asking is:

1. Does the application send confidential data?
2. Can that data be intercepted?
3. How difficult would it be to read that data?

My answers would be as follows:

1. You should know this from running the application and knowing what information it returns to you. I believe that for a balanced analysis you need to look at what you are sending to initiate the transaction, and how secure is that? After all if I am sending insecure confidential data to initiate a secure session, the security of that session is pretty much moot or academic?

2. Yes. It is prudent to assume that the data can be accessed by one means or another. You might consider using VPN for a more secure solution, it is not infallible but it certainly makes life more difficult for the attacker.

3. You do not need to attempt to crack the algorithm. The answers can be calculated or looked up. It depends on the type of algorithm used and the length of the key, factored by the computing power you can throw at it.

Now, I would suggest that you need to "think outside the box" a bit, and extend the scope of your investigation.

1. What is the physical security and electronic security of the client and server? after all the security of transmission and packets would be pretty irrelevant if the final results were being stored in insecure databases?

2. What is the "currency" of the information at risk? How long is the data sensitive for, given that it will take a certain time to crack it? For example, Hot Stock Tips are probably worthless after 48 hours, medical records are a different story.

3. Are there additional features? MAC addresses, tokens, that sort of thing

4. How valuable is the information? The higher the value the more you should protect it and the more resource the attacker is likely to throw at it.

There comes a point where it is just not acceptable to send information over the internet. Armaments, national security and such come to mind.

I think that thehorse13 has an excellent suggestion. Look at the packets and the unencrypted data, and see if there are any "holes" there. Whilst you are at it, watch out for any metadata that may be floating around.

:)

[slarty]

If you are using a closed-source SSL client application, you have to take it on trust from the developers that it is secure. This is because there is no way of knowing that the application does not contain (deliberate or accidental flaws).

An SSL client application which uses constant hard-coded session keys would not be violating the protocol (I *think*), but it would be insecure as hell.

Slarty

[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 :drink: 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 (http://www.AntiOnline.com/showthread.php?threadid=267958#post838319) 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 (http://www.AntiOnline.com/showthread.php?threadid=267958#post838356) 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* :cool:

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

:D

[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/devtools/debugging/installx86.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.aspx?scid=kb;en-us;286350#6a

Your on your own as far as reading the memory.