finding SSL "master key" on a local machine

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

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 :)

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.

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

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

Quote:

---

Originally posted here 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.

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.

Quote:

---

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.

;)

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...surement&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.

:)

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