MIT course "Computer Systems Security". Lecture 13: "Network Protocols", part 3

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: "Introduction: threat models" Part 1 / Part 2 / Part 3
Lecture 2: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" Part 1 / Part 2 / Part 3
Lecture 9: "Web Application Security" Part 1 / Part 2 / Part 3
Lecture 10: "Symbolic execution" Part 1 / Part 2 / Part 3
Lecture 11: "Ur / Web programming language" Part 1 / Part 2 / Part 3
Lecture 12: "Network Security" Part 1 / Part 2 / Part 3
Lecture 13: "Network Protocols" Part 1 / Part 2 / Part 3

Suppose a client issues a request to receive a certain message, for example, “give me message number 7” and encrypt this piece with the key Kc, mail. It seems that everything is wonderful.
The mail server has a shared key that will decrypt this message, after which the server will send back the body of this email, also encrypted with Kc, mail, to the client. Does anyone see this as a problem? Why can it be bad?
')


Student: there is a possibility when a hacker can replace a message or fake it.

Professor: Yes, this is a concern, because I can send you any email you want. Suppose I intend to delete some message that is in your incoming letters, because I do not want you to read it. Suppose this letter is numbered 23.

Therefore, I am going to send you a letter that says: “delete # 23”, and you are going to read it. You are going to receive it, and the response coming from the mail server with the command “delete No. 23” will be encrypted with this key Kc, mail. And so far it has not been sent to the mail server.

But if I browse the network at the right time and fix this package, I can send it back to the mail server. This will look like a “delete number 23” message encrypted with a key. In this case, the mail server will say: “Oh yes, of course, you want to delete this message, and I will do it”!

So there is a problem here, because we allow the adversary to confuse the mail server as to whether our message was generated by it or sent to it first.

This is what is commonly called in the cryptography and protocol description "reflection attack". Do you have any suggestions how to avoid this problem?

Student: Is it possible to simply include a message headline that tells about its origin?

Professor: Yes, as a rule, you want to have some kind of definitive way to state what is happening. One way is to have a header in each message that says "from client to server" or "from server to client." Another best way to practice is simply to use two separate keys.

Because you may want to have a long data stream that may not have room for header bits. Thus, each time you connect to a service, Kerberos 5 negotiates the use of two keys instead of one. The first key will be used to encrypt data from the client to the server, and the second key to encrypt data from the server back to the client. This is the best way to protect for practical use.

Let's talk now about what's happening with the KDC. The Kerberos server is very important for the system, but what happens if this KDC falls? How bad is it for our system? How will the “fall” of the KDC affect your life if you use Athena?

Student: you probably won't be able to log in?

Professor: yes it is. Secondly, you also will not be able to get tickets for new requests. But the cool thing is that KDC is largely located outside the critical path for an existing connection. Therefore, no data passes through the KDC. And if you already have a ticket for something, you can continue to use it and save the entrance to some network services. Actually it is pretty nicely cached. I think the second good thing developers have envisioned is the potential to replicate the KDC. Therefore, the system has one main Kerberos server that stores the initial copy of the entire database. This allows you to read only replicas that contain a copy of the initial database. It does not allow any updates, such as registering users or updating keys, but allows you to respond to login and TGS requests.

Thus, the “clone” record of the Kerberos database allows you to continue logging in and communicating with services, even if the KDC crashes, until it is eliminated and full functionality is restored.

Student: How difficult is it to compromise a KDC server and the system as a whole?

Prof: KDC is the backbone of any system that runs Kerberos. If this service is compromised, the attacker will gain complete control over the system. He will be able to get tickets for any service you want, pretending to be the right customer, so this is pretty bad. We really want to ensure the security of the KDC, but it is difficult. Although I don’t know of a single case where the KIT MIT would really be compromised for about 20 years. But, apparently, what you really need to worry about is the software implementation of the security of things that the two services exchange, Kerberos and TGS. Because if a buffer overflow occurs in them or some other similar vulnerability occurs, this is really bad.



For example, if an SSH server is running on a KDC Kerberos and someone guesses the root password of this SSH server, then it will simply log in and copy the database. So I think that you really want to minimize the attack surface here, so be very careful when writing KDC code. Do not let anyone directly enter this service. Of course, there are some places to which you should be paranoid security, but in terms of servers it is not so important. Of course, they store data, but if someone hacks a mail server or a print server, they can be recovered.

Here is an interesting question. Suppose someone hacked a mail server. What should you do to recover from this attack? For example, if someone stole your mail, it is bad. But what needs to be done to prevent an attacker from gaining access to your mail in the future?

There is no undo operation in Kerberos, but you can generate a new key for the mail server and insert it into the KDC database. Then you install a new mail server, give it a new key, and then some attacker who has the old key from the mail server cannot influence it in any way.

On the other hand, suppose that you do not change the mail server key, Kmail. Where it leads?



Student: the key does not fit the new server.

Professor: OK, suppose you are installing a new mail server, correcting the error that the hacker used. But he still has the Kmail key. It may have taken a whole day to restore the server, so all the tickets were expired. Can this hacker do something interesting with the system? If you provide the old mail server with the old Kmail - is it bad?

Student: an attacker can penetrate the mail server, because it can decrypt the first ticket.

Professor: Exactly, that's why Kmail is actually very important. You say that you can decrypt everything that happens on the mail server. Suppose a client connects to the mail server after it has been fixed, but the attacker still knows Kmail, which has remained since the last system hacking. Therefore, he can decrypt this Kmail ticket, look inside the ticket and get a session key. With it, he will be able to decrypt all the messages you send, all the answers you receive, and so on. Therefore, after the restoration of the mail server, it is very important to change this Kmail.

In many ways, this is even worse than just tracking traffic, because if an attacker knows this Kmail key, he can synthesize new tickets for the mail server without contacting the KDC. Suppose I know Kmail and want to read mail from the mail server. I'll just write out this ticket, I will collect all these five fields in the correct order, generate a new key and encrypt it with Kmail. It will look like the real thing generated by the KDC.

Therefore, I will simply connect to the mail server, it will correctly decrypt the message and think that it is a particular user, so that you can provide it with mail, share the public key with it, and so on. Therefore, it is crucial that no one knows the secret key of this service, because otherwise it is possible not only to make the traffic decrypted and browsed, but also to imitate anyone in this service.

Student: if the mail server is restored after a failure, then you probably need to change its key in the database?

Professor: yes, after you restore the mail server after a failure, you need to call the guy who is working with this KDC and say: “our mail server was hacked, so delete his old Ks key from the database and insert a new one”! So, you probably want to have some kind of mechanism outside the database to prove that you really are a mail server.

Because we will see in a second how you change keys, for example, using the password change protocol. You can passwords in the Kerberos protocol, because if you know the old password, you can change the user password to a new password in the KDC. But since the hacker can intercept the password sent by mail, you may have to contact the account registration office and ask them to change your password to the mail server. They will generate a new key and give it to you so that the hacker cannot recognize it.



Otherwise, if the attacker knows this Kmail key, the mail server has nothing to distinguish the attacker from the correct client. In reality, the attacker probably changed the key, so now he knows the new parameters, and you do not, as if you are no longer on the mail server. So you need external protocols for the principles of initial registration in the database and for changing keys if you forgot your password or someone changed your password so that you lost access.

Therefore, MIT has a group of people who help users register accounts and change their passwords. To do this, you present to them your MIT ID, and whatever happens, they can change the key for you.

Therefore it is very important to do it right. Because if the person who allows you to reset the password makes a mistake when checking your MIT ID, then you can compromise the system, right? So these people in Kerberos are part of a trusted computing base.

Let's look at another interesting use of Kerberos. You can use Kerberos to log into the remote computer over SSH. And the way it works is very similar to working with the mail server. You get a ticket for the SSH server, and you send the ticket along with your SSH connection. But what if you connect to Athena.dial-up and you don’t have a Kerberos client on your computer? You just want to log into Athena.dial-up with your regular password.

So, how does Athena dial-up authenticate you if you just connect to this machine with a password? You do not have a password for Athena.dial-up, this is the password for the Kerberos server. So what should a dial-up computer do if you log in with a password?

Dial-up dial-up access will work using the same protocol as the login. So he is going to send a request from the client to the Kerberos server with a request to give a ticket, for example, in the name of the user “Alice”. And back the client will receive a response, encrypted with Alice's password. Then he will try to use the password and see if he decodes correctly. If it decrypts correctly, then you can log in to the system.

Student: you do not even need to send your key to the SSH server, because in this connection the KDS server can send the user Kc back over the SSH connection.

Professor: it is possible that yes, but it requires some fantasy of an SSH client, which may not be. But in principle, this is true. If you want to do this correctly, you probably want to have a Kerberos client on your computer and receive the ticket yourself or perhaps use an SSH server for forwarding, while not allowing the SSH server to have your key.

This is probably a good plan. But it turns out that in fact, this is a pretty dangerous thing that allows anyone to log in on an SSH server. Earlier we talked about a client trying to log in. This client knew that by providing a legitimate password, he received a response from the correct Kerberos server, and if he can decrypt the answer, then the password probably works correctly.

However, there is nothing in this protocol that confirms the fact that this response comes from the correct Kerberos server. Therefore, if I try to log in to the machine, just by entering the password, the machine will send this request to the server. Then the answer will be returned to this request, which seems to be encrypted with the password I entered, but this answer may not come from the Kerberos server.

Suppose I have a car with which I want to log in. I enter the password X, and then the machine sends this request with, s to the Kerberos server.



But before the Kerberos server sends the real answer to the client, I will send my own answer, which looks like the real answer, encrypted with my password X. And then the workstation I am trying to enter, or the SSH server, will try to decrypt this answer with my fake password. It will look fine, because this response was generated by me instead of the real Kerberos server. Therefore, I can log in instead of you. Why is this happening?

Student: because there is no authentication from the Kerberos server.

Professor: Yes, there is nothing here that links it to a real Kerberos server. The way Kerberos fixes this inconvenience for remote computers, such as Athena.dial-up, is that dial-up computers themselves have a sort of secret key that they share with the KDC. Therefore, in order to enter dial-up or any workstation that really cares about checking whether you really are the right user, two things are being done.

The first login to Kerberos is as shown in the diagram. But he will not trust anyone just because this answer is decrypted correctly. He will try to get a service ticket for himself using TGS, because this dial-up computer has its own secret key. At the first stage, he simply registers you, after which he turns to the TGS, saying: “please give me a service ticket according to my own principle, on the principle of dial-up, for this client”.

Then he receives the answer and checks whether he can decipher it correctly, because he knows the dial-up key for this Ks. And if it is decrypted, it means that the computer spoke to the correct Kerberos server. Because only the correct Kerberos server at the second stage can send me a ticket encrypted with my secret key Kdial-up.

So actually it is very important. As a rule, Athena workstations do not take this extra step, because Athena workstations do not have a secret key stored on them that is shared with the KDC. Why is it normal for Athena workstations to give you the opportunity to log in at the first stage, but not give such an opportunity for dial-up?

Student: this is normal if you do not have access to any services, because the attacker could not forge a ticket.

Professor: yes, this is true, because there is nothing interesting in the dial-up workstation itself. Even if you have root access, or you enter a workstation with a fake password, nobody cares. It’s not like you could do anything else outside your workstation. On dial-up everything is much more interesting. You may have other processes running from other sessions on a dial-up workstation, and it’s important that you log in with a Unix UID, and there they really want to make sure that you are the right entity. . That is why they make such a two-step process for entering a machine that is simultaneously used by several users.

The last thing I want to talk about is how we replace keys. We have put forward the idea that you can compromise the mail server key. But as a user, you probably also want to change your password. For example, you thought that your password was not secure enough, you wrote it on a piece of paper, and someone could spy on it, so now you want to change it.

In a sense, this is quite simple. In the Kerberos server interface, in addition to the Kerberos and TGS services, there is an additional service called Kpassword, which allows you to change your password.



You get a ticket to use this service in the same way as a ticket to a mail server or any other server. After this, you send your new password to this Kpassword service, encrypted with your session key. And then, if all the checks pass, your key in the database will be updated to the new key.

If you remember, we had a goal - if someone steals your ticket, it should not be good enough to give you the opportunity to completely seize your account. For this reason, the Kpassword service does not accept any ticket, but only the ticket that you initially receive from the Kerberos service with your Kc key. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».

, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.

Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.



Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.

, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .

, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .

, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.

: , ?

: K . Kerberos , . , K. - K, .

: , ?

: , - , , . .

, , , , , , .

: , , .

: , , . , , Kerberos , , . , . . , , .

: K, ?

: , K – 56- DES, , , 56 , , 7 , . .

, , . , , , , . Kerberos?



: …

: , , , , , , . ?

: .

: , .

: - , , , , …

: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .

: , Kerberos ?

: , . « -», , , . , .

, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.



gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .

: - G.

:Yes of course. G is some parameter that you could send at the beginning of the protocol or place it in Kerberos in advance; this is not very important. In any case, if you use the Diffie-Hellman exchange encryption protocol, Kerberos 5 does this correctly. But you need to know about the existence of this protocol if you are developing a new protocol of your own. So that's all I wanted to talk about Kerberos, and on Monday let's talk about SSL.


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?