Security Now 223
Topic: The Latest SSL Exploit
Recorded: November 18, 2009
Published: November 19, 2009
Security Now 223: The Trouble With SSL
News & Errata
03:00 - 05:05
- Vote for Security Now in the podcast awards Here
07:23 - 13:54
- Their is a problem with the embedded open type fonts, EOT fonts in Windows
- It's a font-parsing bug which allows remote code execution that is also a kernel bug
- So its a buffer overflow in the Kernel
- It is expected this exploit will no be detected by many anti virus products as it can come in encrypted
- You can fall victim to this exploit just by loading a malicious webpage
13:55 - 15:32
- The exploit that is being used against jailbroken iPhones is now stealing data from the users phones
- If you have a jailbroken iPhone you need to change the SSH password
15:33 - 18:17
- There's a recently acknowledged by Microsoft zero-day problem with Windows 7 and Server 2008 Release 2.
- This is another problem with Server Message Blocks, the SMB protocol.
- Microsoft is suggesting people block ports 139 and 445
18:18 - 20:54
- Another reason Steve does not like port knocking is:
- It is susceptible to a Denial of Service attack where a person sends random packets to your IP address and causes the port knocking sequence to never be completed
20:55 - 24:45 Troy Starkey (Unknown)
A listeners hard drive died so he illegally downloaded a copy. It fixed his drive so he has now purchased a copy.
He offers a tip for users whose hard drives are clicking: Place your clicking hard drive in a anti static bag and put it in a freezer for an hour. Wrap it in a towel, to avoid condensation build-up and then power it up straight away whilst it is still frozen. This may allow the drive to succesfully complete its initialization, be detected by the BIOS and your data recovery software before it heats up due to its own activity.
The Latest SSL Exploit
29:31 - 01:29:31
31:00 - 36:50
- When a client wants to initiate a connection to the server:
- It establishes a TCP connection
- Then it sends a Client Hello packet
- That packet contains the highest protocol version that it supports; a blob of randomness that it has made up for itself; a session ID; a list of the cryptographic ciphers that it is equipped to use; the compression method that it proposes to use.
- The server receives that Client Hello packet containing all of that and it responds with its Server Hello.
- This contains all of the things that it has decided to use based on what it understands and what are the latest versions it can handle,
- It also sends its certificate to prove who it is and a blob of randomness
- The client now knows what versions and ciphers it can use
- So it takes the randomness that it generated, the randomness that the server provided, and it then does a key negotiation.
- It then looks at who signed the servers certificate and checks they are trustworthhy
- The certificate also contains the server's public key.
- So it will encrypt the data composed from the randomness that they both have, using the server's public key, and send that back in what's called the client key exchange packet.
- So what that's doing is, that's saying, okay, here's the master key for this session that I'm proposing.
- Since it encrypted it with the server's public key, only if the server contains the matching private key will the server be able to decrypt that in order to get the same data that the client has.
- So nobody listening in the middle is able to do that.
36:51 - 39:00
- The next packet sent is the change cipher spec packet which is the client saying I've given you everything you need. Now I'm going to switch to secure mode using the ciphers that we have agreed on.
- That is the last packet sent in the clear.
- It then sends, using the agreed-upon encryption, a finished message which ends the handshaking, which is it contains the master secret encrypted under the cipher and a hash of all the preceding handshake messages.
- So all of their conversation up to that point is hashed.
- All of that is encrypted under the current encryption, and that's sent to the other end.
- So what's significant here is that, until that cipher change spec message, everything is in the clear.
- The server does the same thing.
- It also sends a change cipher spec message to the client saying, okay, here we go. The next thing you're going to receive from me is the finished message encrypted from my end, proving that I have everything that we've each received.
39:01 - 45:35
- It is possible for either end to request renegotiation
- To do this the end that wishes to renegotiate sends a hello request message
- All of this renegotiation occurs in the current secure tunnel
45:36 - 52:00
- ARP maps mac addresses to IP address
- When a computer on a network turns on it broadcasts a message asking what peice of hardware has the IP address set as its gateway
- The gateway then responds with its IP address and the computer creates a table with IP addresses matched up with MAC addresses
- It is possible for a man in the middle to tell the computer it has the IP address of the gateway and now every packet that computer sends out, goes to the man in the middle who can do what ever they want with them
- It was believed that an SSL connection protects you from a man in the middle but now in some circumstances it does not
52:01 - 01:04:43
- So to carry out this attack, you first insert yourself in the middle of the connection using ARP spoofing and then wait till you see a request to initiate a HTTPS connection and hold that packet
- They go through the protocol negotiation, just as I said.
- So now the attacker has a secure connection to the remote server.
- At that point the attacker sends a malicious request to the server.
- So the attacker sends this command which is unfinished to the remote server and then sends a new Server Hello message.
- So in one packet it sends the beginning of a command, then sends a Client Hello message
- So the malicious guy in the middle sends a Client Hello.
- The server goes this guy wants to renegotiate. That's fine.
- So the bad guy sends the Client Hello message that it had been holding and blocking from the real client.
- And so that it forwards it to the server, and the server believes it is renegotiating the existing connection; whereas the actual good guy, the innocent client, thinks it's establishing a new connection.
- So what happened was the man in the middle was able to hold the client's hello message briefly, send its own, negotiate a connection, get a secure connection, send some stuff to the server
- Then allow the client's hello message to pass through it, and all it then does is allow the standard handshake to proceed, and essentially knitting the innocent client's SSL connection to the server.
- The Client doesn't know anything about a previous SSL connection.
- The server sees it as a renegotiation of an existing one.
- What happened was, as a consequence of this, the attacker was able to send some stuff ahead using the, well, on this little brief sort of a stub of a connection, but over SSL.
- Now, how is that useful?
- One of the ways that we see the web is being used is that requests to servers, like standard HTTP get requests, have these very complex-looking URLs with all kinds of gobbledy-gook in them.
- Remember, you know, it'll be https:, for example, or just :// and then the domain, then the directory and the page.
- Then there'll be a question mark which starts the parameters.
- And then you have all these parameters afterwards which are sophisticated command directions, causing things like PayPal to transfer money or banks to log you in, causing purchases on Amazon and so forth.
- So there's all this parameterization in this - contained in the URL.
- That's normally protected within the SSL secure wrapper. So it can't be seen by someone eavesdropping. It can't be synthesized by a man in the middle. It's protected.
- After that get request are a series of headers, things like, for example, the host header is required by HTTP 1.1, the current version of HTTP, where it says, you know, www.amazon.com.
- It'll say this is the host I am trying to connect to. And then things like time and date and also cookies.
- Every one of these header lines ends with a carriage return line feed and then the next header.
- Well, imagine what happens if what the attacker in this scenario sends is a sophisticated command with a URL and all of this extra stuff padded on the end which the receiving server knows this is a command for it to do something.
- Then it adds a couple headers.
- But the last header it leaves open.
- For example, the header is ignore this colon, space.
- And that's where it ends its insertion.
- It leaves that last header unterminated.
- Now it passes the innocent client's Client Hello message through.
- The client establishes an SSL connection.
- And the client sends its valid get request, its HTTP get command.
- Well, because the malicious man in the middle left that last header unterminated, what the server sees is ignore this colon, space, and then the client's request, which looks like just a header, and it is a header of the malicious request.
- Which means the client's actual command is absorbed.
- But then - here's the good part.
- The client, because it's got a connection that's secure to a web server it knows, it continues, its command follows with other things, including its cookies.
- So that ends up getting tagged onto the attacker's command, allowing the attacker to perfectly impersonate the client, the innocent client.
01:10:00 - 01:29:31
- The latest version of TLS has a feature called extensions which the latest version of SSL doesnt have
- A client which can use extensions tells the server this in the client hello packet
- It turns out that all we have to do is add one more, and it is a renegotiation info extension.
- All it contains is that finished data from the prior negotiation
- So the idea is that, remember that in this attack scenario the server saw the real client's Client Hello message.
- It saw that as a renegotiation of the existing connection, whereas the client thought it was its initial contact packet.
- So all we need to do is enhance the protocol.
- We add a renegotiation info type of extension which contains the payload from the previous finished message.
- That finished message is this - basically it's the I'm proving to you everything which has gone on before we're in agreement on.
- We simply change TLS so that renegotiation must have the payload from the previous security context as part of the hello message, the problem is solved.
- The server, who is aware of this, would never accept a renegotiation that didn't have that packet from the previous security context.
- And in the scenario we painted, the client wouldn't think it was renegotiating. It wouldn't have any context to share. So the server would deny the renegotiation and drop the connection.
Go To Meeting
- Go To Meeting
- Ad Time: 00:00:56-00:01:10 and 00:05:03-00:07:14
- Sync My Ride
- Ford SYNC-2
- Ad Time: 00:00:36-00:00:54 and 00:25:00-00:29:09
- Carbonite Offer Code: TWiT
- Ad Time: 00:01:12-00:01:26 and 01:04:27-01:07:27
- Edited by: Tony
|This area is for use by TWiT staff only. Please do not add or edit any content within this section.|