MIT course "Computer Systems Security". Lecture 8: "Model of network security", 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

Audience: Why does a random token always be included in the URL, not in the request body?
')
Professor: HTTPS is involved in this way, but there are no compelling reasons for not including random variables in the request body. There are just some forms of inheritance that work in this way through a URL. But in practice, you can put this information anywhere else in an HTTPS request, other than the header.

However, note that simply moving this information to the request body is potentially unsafe if there is something there that an attacker can guess. Then the attacker will still somehow be able to call the URLs he needs. For example, when I make an XML HTTP request, and then explicitly put in the body some content that the attacker can guess.



If you simply set the frame in the URL, then the attacker can control it. But if you use an XML HTTP request and the attacker can generate one of them, then the XML HTTP interface allows you to set the request body. XML HTTP request is limited to the same origin. However, if an attacker can do something like:

<script> var x = “ntrusted”; </script> 

It will then be able to inject an HTTP HTTP request that will be executed with inline page authority.

It all depends on what the attacker has access to. If it can force the page to execute an untested script, as shown above, then it can use a JavaScript property called internal HTML to get all the HTML content of the page. If an attacker can or cannot generate an AJAX request, this one, if he can or cannot see the correct HTML code, this is another, and so on. In short, this randomly generated token can prevent CSRF attacks.

There is one more thing that needs attention: network addresses. They relate to the part of our conversation that said who the attacker could not communicate with via an XML HTTP request.

Regarding network addresses, the frame can send HTTP and HTTPS requests to (host + port) corresponding to its origin. Please note that the security of the same policy of the same source is very closely related to the security of the DNS infrastructure, because all such policies are based on what you are called.

So if you can control how they call me, you can make some rather vicious attacks, like a DNS re-bind attack. The purpose of such an attack is to launch a JavaScript-controlled JavaScript attacker with the authority (or on behalf of) of the victim’s website, called victim.com. In this case, the attacker uses the rules of the policy of the same source and is going to somehow run the code written by him with the permission of another site.

This is done as follows. First, the attacker registers the domain name, say, attacker.com. It's very simple, just pay a couple of bucks - and on the way, you have your own domain name. The attacker must also configure the DNS server to respond to requests coming in the name of objects located on attacker.com.



The second thing that should happen is that the user must visit the site attacker.com. In particular, he should visit some site that depends on this domain name. In this part of the attack, too, there is nothing tricky.

See if you can create an ad campaign, for example, to offer a free iPad. Everyone wants a free iPad, although I don't know anyone who ever won a free iPad. So, click on such a message in a phishing mail, and you are already on the site of the attacker. Nothing special, this part is not complicated.

So what happens next? The browser will start generating DNS queries for the attacker.com site, since the page you visited contains objects that refer to objects located on attacker.com. But the browser is going to say: “I have never seen this domain before, so let me send a DNS request for permission to contact attacker.com”!



And the attacker's DNS server responds to this request, but its response contains a very short TTL lifetime, which prevents the response from being cached. Therefore, the browser will think that it is valid only for a very short period of time before it has to go out and confirm this, which in effect means disabling caching.

It turns out that as soon as the user goes to the hacker domain, the attacker's DNS server first returns the real IP address of the web server, which provided the user with a malicious code. This client-side code refers to attacker.com because the origin policy allows such requests. The user receives a response, and now the malicious website is running on the client side.

Meanwhile, the attacker is going to configure a DNS server, which he controls, to bind the name attacker.com and the IP address victim.com. This means that if a user's browser requests the resolution of a domain name for something inside attacker.com, it is actually going to get some internal address victim.com.



Why can the attacker's DNS do this? Because the hacker configures it for this, and the attacker's DNS server should not be consulted to re-bind to victim.com.

Moreover, if our site wants to get a new object through, say, AJAX, it will assume that this AJAX request goes to attacker.com somewhere outside, but in fact this AJAX request goes inside, to victim.com. This is bad, because now we have this code on the side where the attacker.com web page is located, which actually accesses data from victim.com from a different source of origin.



Simply put, when the script is executed in the victim’s browser due to the outdated previous DNS response, a new DNS query is made for this domain, which, due to the caching ban, goes to the attacker's DNS server. He replies that now attacker.com seems to have a new IP address of some other website, and the request goes to another server. And then to return the information collected by the attacker, the attacker will provide his or her correct IP address in one of the following DNS requests.

Audience: would it not be wiser to make an attack on the contrary, from victim.com to get all the attacker's cookies and the like?

Professor: yes, this option will also work. This will allow you to do such good things as port scanning. I mean, your approach will work correctly. Because you can step by step constantly rebind attacker.com to various computer names and various ports on victim.com's network. In other words, the attacker.com webpage will always think that it is going to attacker.com and receive an AJAX request from there.

In fact, every time the DNS server re-connects to attacker.com, it sends requests to some other IP address within victim.com. Thus, he can simply step through the IP addresses one by one and see if someone answers these requests.

Audience: but the user you are attacking does not necessarily have internal access to the victim.com network.

Professor: As a rule, this attack is that there are certain firewall rules that could prevent the external site attacker.com from viewing the IP addresses inside the victim.com network. However, if you are inside a corporate network such as corp.net behind a corporate firewall, then computers often have the ability to connect to machines outside their network.

Audience: Does this method of attack via HTTPS work?

Professor: this is an interesting question! The fact is that HTTPS uses keys. If you use HTTPS, then when sending an AJAX request, the victim’s machine will not have the attacker's HTTPS keys, and the encryption check on the victim.com computer will show the key mismatch. Therefore, I think that HTTPS rules out this type of attack.

Audience: what if the victim uses only HTTPS?

Professor: I think it will stop the attacker.

Audience: why does an attacker first of all respond to the victim's computer with his IP address?

Professor: because the attacker must somehow run his own code on the victim's machine before he can take further steps to search for something within the victim's network. But let's not waste time, so if you have questions about DNS reassignment, come to me after the lecture.

So how can you fix this? One way to fix this vulnerability is to modify the client DNS permissions module so that external host names are never allowed to access internal IP addresses.

It’s kind of stupid that someone outside your network should be able to create a DNS linked to something inside your network. This is the easiest solution.



One can imagine that the browser can do something called “DNS pinning”, or DNS pinning. As a result, if the browser receives a record of resolved DNS, it will always consider this record valid, for example, to interact for 30 minutes, regardless of what TTL the attacker assigns, and will be able to withstand the attack in this way.
This solution is a bit tricky, because there are sites that intentionally use dynamic DNS for things like load balancing on a server and the like. Thus, the first solution with DNS binding is the best option.

And now we consider what the policy of the same source protects. What about pixels? How does the origin policy protect the pixels?

As it turned out, the pixels actually have no origin. Thus, each frame gets its own little bounding box, basically just a square, and the frame can draw anywhere within this area.

This is actually a problem, because it means that the parent frame can draw on top of the child frame. And this, in turn, can lead to very insidious attacks.

Say, an attacker creates a page that says: “click here to win an iPad”. The same standard technique. This is the parent frame.



And this parent frame can create a child frame, which is actually a Facebook button’s Like frame. Thus, Facebook allows you to run this little piece of Facebook code that you can put on your page.

You know that if a user clicks “like”, it means that he will go to Facebook and say: “Hey, I like this particular page”! So, we now have this child frame Like button.



Now an attacker can impose this frame on the area of ​​the screen on which the user should click to get a free iPad, and also make this frame invisible, CSS allows it.

So what happens when this happens? As we have already installed, everyone wants to get a free iPad. The user is going to go to this site by clicking on this area of ​​the screen, being sure that he clicks on exactly what the free iPad will give him. But in fact, he presses the invisible Like button. It's like layering on top of C.

This means that now, perhaps, the user enters the profile of Facebook, where he notes that he liked the site attacker.com. You know, he won't even remember how it happened. So this is actually what is called a click jacking attack - support for a click attack. In the same way, you can do a lot of bad things - steal passwords, get personal data, in short, this is crazy. I emphasize that this is possible due to the fact that the parent frame is able to draw anything within this rectangle bounding it.

So, the parent frame is what you see on the page, the call to get a free tablet, and the child frame is the “like” button, which is transparently superimposed on the parent frame.

There are different solutions to this problem. The first is the use of the frame lock code frame busting code. That way, you can use JavaScript expressions to find out if someone has put their own frame into your frame. For example, one of these tests is a comparison of the following form: if (self! = Top).

Here, the self operator refers to the top of the top frame, which is compared to the hierarchy of the entire frame. Therefore, if you do this test and find that self is not equal to the top of the parent frame, you will understand that you have a child frame. In this case, you can refuse to download it.

This happens if you try to create a frame, for example, for CNN.com. If you look at the source code of JavaScript, you can see that it performs this test, because CNN.com does not want other people to use its content. Therefore, this frame always occupies the highest position. So this is one solution that can be used here.

The second solution is for your web server to respond with an HTTP header called x-Frame options. Therefore, when the web server returns a response, it can set this header, which says: “hey, browser, don't let anyone put my content inside the frame!”. This solution allows the browser to perform enforcement actions.

So it's pretty simple. But there are still a bunch of other crazy attacks you can organize.

As I mentioned earlier, the fact that we now live in an international Internet creates problems with the use of a domain name or host.

Suppose we have the letter C. But in what language? From which alphabet is this letter from Latin ASCII or is it C in Cyrillic? This allows you to organize attacks that use different interpretations and the use of different, but externally similar letters. For example, an attacker registers the domain name cats.com. And users will go to this domain, thinking that they will visit the site “cats.com”, but in reality they will get on the site of the attacker “satss.kom”, because the first letter here is not Latin, but Cyrillic.

An attacker can register a domain fcebook.com, but people are inattentive, they will perceive it as facebook.com and go there. So if you control Facebook, you’ll get a bunch of traffic from people who think they’ve logged in to Facebook.



There are a lot of different, kind of, stupid attacks that you can launch through the domain name registration system, from which it is difficult to defend yourself, because how can you prevent users from making typos? Or, as the browser tells the user: “Hey, is it Cyrillic, not Latin?”?

If the browser warns the user every time Cyrillic fonts are turned on, it will piss off people who actually use Cyrillic as their native font. So it is not entirely clear how such issues can be solved from a technical point of view, therefore very sensitive security problems arise here.

Another interesting thing is plugins. How do plugins interact with the origin policy? Plugins often have incompatibility with the rest of the browser in relation to the same source of origin. For example, if you look at a Java plugin, it assumes that different host names that have the same IP address also have the same origin.

In fact, this is a rather large deviation from the standard interpretation of a policy of the same origin. This approach means that if you have something like xycom and zycom and they are projected onto the same IP address, then Java will assume that they have the same origin. This can be a problem, since in reality one site has a trusted source of origin, and the other does not. There are many other difficulties associated with plug-ins, which you can find from publicly available sources on the Internet or from the outline of this lecture.

The last thing I want to discuss is a screen sharing attack, or a screen sharing attack.

HTML5 actually defines a new API, through which a web page can share all of its bits for sharing with another browser or server. This seems like a really cool idea, because there is a possibility of simultaneous work of several users on one document. This is great because we live in the future.

But the funny thing is that when they developed this new API, they did not even think about a common source policy!

Suppose you have a page on which several frames are located, and each of them has the right to take a screenshot of your entire monitor. It can take a screenshot of all the frames located on the screen and all the content regardless of the sources from which they originate.



So in fact, this is a rather destructive flaw in the policy of the same source of origin, so you should think about correcting it. For example, if a person from the right frame has the ability to take screenshots, then he will be able to take a screenshot of only the right frame, and not the entire screen.

Why didn't the browser developers implement it this way? Because they are experiencing competitive pressure and are forced to focus their efforts on the development of new and new features, new features, rather than focusing on improving things already developed.

Many questions that students asked on the Internet regarding this lecture, sounded like this: “why didn't the developers do what they could do? Is this not clear? ”Or:“ It seems that this particular scheme is dead. Wouldn't the other be better? ”And so on.

I'll tell you honestly - yes, that’s for sure, almost everything would have been better if the developers reacted to this responsibly. So I feel ashamed that I am connected with this.

But the fact is that this is what we had before. If you look at all the elements that existed before, you will see that web browsers are evolving, and people have begun to take a little more care about security. But not in the case of screen sharing, where developers were so concerned about the innovative features of the browser that they completely forgot about the possibility of bits leaking.



Therefore, I ask you to always pay attention to the things we discussed today. Imagine if we were going to start from scratch, destroy everything that was before us, and try to come up with a better security policy, how do you think, how many sites would work for us? I think no more than 2%. So users would surely complain about us.

There is another interesting property related to security. - , , . , origin, .


.

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?