.NET Security is easy

We present interviews with leading security experts: Vladimir Kochetkov (head of application security analysis research at Positive Technologies ) and Mikhail Scherbakov (independent developer and consultant in information security).

What is this article about? I will quote one of Michael’s remarks:

“Developing a secure application is a special case of developing an application that does not contain errors at all. In addition, your application uses third-party libraries, the security of which is also not guaranteed, then it runs on the OS and hardware. Often we can not even say on which OS and on which hardware. And all this changes with time! ”

Vladimir Kochetkov - since 2006 he worked in the subject area of ​​information security. In 2012, Positive Technologies came to the position of the leading expert of the web application security analysis group. He participated in projects on the analysis of application security, investigated application testing techniques. With the participation of Vladimir implemented the product PT Application Inspector. In 2014-2016, he led the development team for analyzers of compiled applications and led the project to develop a binary code analysis module. Since September 2016, she has headed the application security analysis research department. He is directly involved in theoretical research in the direction of analyzing the security of applications and prototyping promising products of the company. He has published articles in HITB Magazine, Hacker, and RSDN Magazine. Repeatedly participated in the international forum Positive Hack Days (as organizer and speaker) and the .NET developer conference DotNext, regularly speaks at user group developer meetings. Takes part in the development community of Russian-speaking developers RSDN. One of the organizers of the Positive Development User Group is an initiative aimed at immersing developers in the application protection domain. Keeps the blog kochetkov.imtqy.com .

At DotNext 2017 Moscow arrives with the report “Winning Injections”.

Mikhail Shcherbakov - Microsoft .NET MVP, participant of the .NET Core Bug Bounty Program, co-organizer of the .NET programmers community, independent developer and consultant. Professional interests: static and dynamic code analysis, information security, code debugging automation, .NET CLR internal device research.

DotNext 2017 Moscow arrives with the report “ASP.NET Core: Attack Prevention Mechanisms 2.0”.

- What types of vulnerabilities are usually found in the .NET Framework now?

Mikhail Shcherbakov : Here we need to separate vulnerabilities in the .NET Framework itself and in applications that are written based on the .NET platform. The .NET Framework is a platform for developing various types of applications: from websites and services to desktop applications. And this is an integral part of the Windows operating system, so the .NET Framework security should be treated like an OS. The main part of the vulnerabilities in it is not the usual web developers XSS, CSRF, SQL / XML / JSON and other injections, but the execution of arbitrary code, elevation of user privileges, information disclosure, denial of service.

- Tell us, please, what do you know about the vulnerabilities found recently in ASP .NET and in .NET Core?

Michael : A detailed story would not have turned out for one hour :) I made a report about vulnerabilities in the “big” .NET Framework a year ago at DotNext Moscow. With a demonstration of examples of exploits and analysis of errors that lead to these vulnerabilities. Of course, in 45 minutes it turned out to include less than I would like, I tried to focus on the vulnerabilities that developers can allow in their products, primarily in web applications, in ASP .NET. There have been examples of DoS, Elevation of Privileges, XXE, Information Disclosure, data deserialization attacks.

For .NET Core this year a large patch was released, fixing several vulnerabilities: DoS, Elevation of Privilege, protection bypass. Including the vulnerability CVE-2017-0256 I found in protection against Open Redirect. The problem, as is often the case, was the lack of validation of user input. You should also pay attention to Kestrel, I am now in my free time doing a review of this code, and my opinion coincides with the position of Microsoft and the .NET Foundation, that it is not yet ready for use on the front. Be sure to close it with any reverse proxy (Nginx, Apache, IIS). I think I can soon tell you more about this.

Vladimir Kochetkov : Over the past couple of years, there has been another surge in platform vulnerabilities related to the processing of XML documents. In 2013, our guys made a report at the BlackHat EU conference about the OOB techniques of attack introducing external XML entities, which resulted in the elimination of a large number of vulnerabilities in a wide variety of XML libraries, including System.Xml. However, progress does not stand still and, a few years later, we again see in .NET a set of quite traditional XML processing vulnerabilities: XXE (CVE-2016-3255), signature forgery of XML documents (CVE-2016-0132), DoS via specially crafted XSLT documents leading to recursive transformations (CVE-2016-0033). Not without the vulnerabilities of the OS level, which directly determines the security of the overlying levels. Thus, the CVE-2016-0145 vulnerability in win32k.sys (in fact, the Windows kernel) allowed an attacker to execute arbitrary code in the system using a specially crafted font (!!) embedded in any document. Of course, using this vulnerability could be successfully attacked and .NET-applications that work with documents of suitable formats.

Separately, it is worth noting immediately two vulnerabilities of remote execution of arbitrary code found in .NET this year: CVE-2017-0160 and CVE-2017-8759 . A detailed analysis of the first (as well as the proof-of-concept code for its operation) can be found at https://www.exploit-db.com/exploits/41903/ . The second article is devoted to a separate article in the FireEye company blog . It is noteworthy that this vulnerability, among others, was used for the introduction of the FinSpy government spy system, which became known due to another publication on WikiLeaks.

- What could be the goal of attacking the .NET Framework in the first place? Have the attackers changed their goals over a period of, say, five years?

Michael : The main goals are the components used in web applications, various parsers working with input data that an attacker can manipulate. Since the .NET Framework is on every modern version of Windows, any of its components is potentially interesting for information security researchers to implement an attack to elevate the privileges of a local user. For example, CVE-2014-0257 was used to exit Internet Explorer 11 Sandbox, and CVE-2014-4073 from ClickOnce. Access to the .NET object from the code executed in the sandbox was implemented through Managed DCOM. This year, the story of DCOM repeated, and CVE-2017-7293 was found, similar in attack technique. You can read the whole fascinating story in the blog of the Google Project Zero team .

Over the past few years, it has become less interesting in applying the attack to exit the .NET Sandbox, because the technology itself is used all in fewer products. It was not included in .NET Core, the ASP .NET team finally refused to use the sandbox to isolate applications inside IIS, Silverlight is almost dead, the latest versions of IE warned the user about the execution of third-party XBAP applications. Four years ago it was possible, using CVE-2013-0073, to launch the Remote Code Execution attack on a user's computer simply by opening a specially prepared page in the browser. I showed an example of this exploit at DotNext Moscow 2014.

I mentioned the .NET Core, so when working on it, the vulnerabilities in the RyuJIT compiler were fixed: CVE-2015-2479, CVE-2015-2480, CVE-2015-2481. The open-ended Bug Bounty .NET Core vulnerability scan program with rewards of up to $ 15,000 is now open, and the .NET Core components, of course, are now excellent targets for information security researchers.

Vladimir : It depends, first of all, on who the attacker is and what kind of attack he is conducting. In the case of an automated mass attack, the goal may be, for example, the seizure of control by as many network hosts as possible. Accordingly, in this case, fresh vulnerabilities of the platform, popular frameworks, engines, and libraries are attacked at random, and credentials are selected for known entry points using a small dictionary.

In the case of a competent targeted attack, the scenario develops in the best traditions of the notorious killchein: reconnaissance is being carried out, exploits are being prepared, being introduced into the system, fixed in it and performing actions aimed at achieving the attacker's goal. The goal in this case, as a rule, is the one-time receipt of any confidential information or its continuous monitoring. With regard to .NET, this means a scrupulous analysis of any source available to him attacking the attacked application (including the source of the platform itself), using the identified zero-day vulnerabilities, possibly focusing on code that directly interacts with databases (System.Data, ORM ) or other external repositories of the extracted information.

In purely technical terms, the targets of attackers have changed little over the past 5 years - the same set of vulnerabilities, attacks and threats, varying from year to year within insignificant limits (see OWASP Top 10 , if we talk about web applications). Of the noticeable changes - in the last two or three years, there has been a tendency towards a significant development of consolidation techniques in Windows systems, which inevitably affects the consequences of successful exploitation of vulnerabilities in .NET applications, which are still traditionally attributed to this OS in most cases.

- Can knowledge of the main types of attacks help develop protected applications, and if so, how?

Michael : It can help. Often, developers' eyes are filled with knowledge of “template” web vulnerabilities: XSS, Path Traversal, various injections, and they pay little attention to logical errors that lead to a violation of application security. Therefore, examples of successful attacks on the platform under which you are developing expands the horizons and allows you to take a fresh look at your code. But to develop secure applications, you need a systematic approach. Vladimir and I conducted one of the first meetings of the SPB .NET Community dedicated to the security of .NET applications, and tried to solve the topic from both the theory and the practice side. The network has a video of this meeting.

Vladimir : If we talk about the principle of “hack-yourself-first”, then it simply does not work. In order for a developer to effectively protect an application, thinking the categories of an attacker, he must be as professional in this regard as the average intended attacker is professional. For developers, this actually means getting a second specialization. Fighting attacks is not their area of ​​responsibility. From the point of view of ensuring the security of the application, the main task of the development stage is to combat flaws - an ineffective implementation of application domain control, which leads to the emergence of vulnerabilities to attacks of various kinds . In sufficient detail, this topic was revealed at the CodeFreeze community meeting in Moscow, in April last year. There were also several examples of how the struggle of developers against attacks instead of flaws can lead to the appearance of vulnerabilities in their applications.

Of course, it is worth knowing the main types of attacks for developers, at least for general development. But you should not use this knowledge to make decisions regarding the protection of the applications they develop. Developers interested in the specifics of carrying out attacks on ASP.NET applications may be interested in my article “ Hack a ASP.NET website? Difficult, but possible! ”, Published in the 165th issue of Hacker magazine (p. 63).

- What aspects of the security of the .NET Framework should the developer focus on and why?

Mikhail : For the developer, this is, first of all, validation of all input data, sanitization of output data. About validation of input data speak from school. Everything that comes from the user should be checked for compliance with the requirements (including the requirements of the security model). And the main thing is to do it correctly: use white list checking, where possible, to correctly describe the grammar of the input data format (this I mean, you don't need to parse XML or HTML with regular expressions ). This is also following all bored principles of Secure by Design / Default / Deployment .

Plus, there is a best practice set for developing secure applications, for example, the OWASP Developer Guide , and Knowing and following them is just as important as knowing the architectural patterns and principles of SOLID.

Vladimir : First of all, it is worth paying attention to the preliminary processing of input and output data. With reference to .NET, this means:

a) Strong typing of all data received from outside. Any external data received in the form of System.String should be transformed into specific entities of business logic and then used in this form (unless, of course, the semantics of the input data does not imply that this is a string entity, such as "message text on forum "). However, despite the need for typing all the input data, it must be remembered that for any non-primitive types, it can entail serious security problems, such as SSRF, deserialization vulnerabilities, etc.

b) Semantic validation of all typed external data. Ideally, it is necessary to define invariants for each entity and to ensure their observance by means of contract programming, such as CodeContracts or PostSharp Contracts.

c) Syntactic sanitization of all data sent out in accordance with the grammar of the receiving party. It must be remembered here that the need to apply certain sanitizers depends not only on the host grammar, but also on the context in which the data is transmitted. So, for example, using HttpUtility.UrlEncode for data transmitted, for example, in JavaScript code, will leave the application vulnerable to an XSS attack. Most sanitizers in .NET are concentrated in the HttpUtility , HttpServerUtility , WebUtility and System.Web.Security.AntiXss classes. You should also pay attention to our library LibProtection , the first public release of which is scheduled for November 13 of this year and which is dedicated to my report at the upcoming DotNext Moscow 2017 .

- What types of vulnerabilities in the .NET Framework that interfered (or hindered earlier) in your work could you name?

Michael : Any vulnerabilities help my work more than they interfere :) By analyzing vulnerabilities in .NET FW, you can learn new types of attacks and (anti) code writing patterns. It helps to develop secure applications and analyze system security.

Vladimir : The nature of my work is such that any vulnerability in .NET contributes to it rather than interferes. But if we talk about your favorite .NET vulnerabilities, then this is definitely the sensation in 2010 of the suspicion of attacking an oracle in the ASP.NET WebForms encrypted token pattern (CVE-2010-3332), which allowed you to read arbitrary web server files and forge authentication tokens. A detailed analysis of this attack can be found in the presentation .

- What security errors are most often made by developers of the .NET Framework application?

Michael : In my experience of conducting a security review of web projects, these are all kinds of injections “in the broad sense of the word”: XSS, SQLi, XXE, Path Traversal, and application configuration problems. This is also confirmed by the data on the basis of which the well-known OWASP Top 10 rating of this year and the information security reports of companies were compiled.

Injections are possible only with insufficient validation of input data and improper sanitization of the weekend, I mentioned above. Configuration errors are resolved by following best practices and using vulnerability scanners.

Vladimir : As I said above, a very significant part of security problems is associated with inefficient preprocessing of data. This is confirmed by the annual statistics of vulnerable web applications published by Positive Technologies. So, according to the data for 2016 , the most typical for ASP.NET applications are vulnerabilities to cross-site scripting, credential selection and information leakage.

- What are the most effective methods of dealing with attacks on .NET applications you can name?

Michael : Usually the goal of any software vendor is not to fight attacks, but to develop secure applications, to guarantee the confidentiality of user data. Therefore, security must be approached from the point of view of protection, not attack.

Developing secure applications is, first and foremost, thoughtful risk management. It is impossible to develop the most secure application "accidentally", only due to the qualifications of the developers. The security level of each component of the application is the same requirement for which resources are required both at the design stage and at the testing stage. It is necessary to understand the price of the risk of an attack on each component, and on this basis to decide how much effort to spend on preventing this risk. And in any case, have a plan of action if the risk has been realized, i.e. Your application has been successfully attacked.

If you are still ready for additional costs, then a systematic approach is important. It is necessary to systematically introduce the Secure Development Lifecycle (SDL) techniques into the development process, improve the development culture in the company: add a security review step to the product release process, develop and implement best practices for writing secure applications, train developers in the company, pay attention to security during testing, carry out penetration tests (both internal and external), constantly use “white box” and “black box” scanners in order to maximally automate the process of searching for vulnerabilities, to accept Venting protection measures, for example, use a Web Application Firewall (WAF).

Vladimir : Whatever the specifics of .NET, the general principles for ensuring application security are:

• Embedding SSDL (Secure Software Developent Lifecycle) into the overall software development cycle;
• focusing developers on combating flaws in the code;
• use of application-level firewalls during the operation phase.

In addition, specifically developers of .NET applications should pay attention to the .NET security cheat sheet from OWASP and Stan Drapkin 's remarkable book “Security Driven .NET” , revealing the specifics of ensuring security of .NET applications with a bias in cryptography.

- Have you ever hacked your own .NET applications? If so, can you tell more about it? Maybe you can tell a couple of cases about similar situations with applications of familiar developers?

Mikhail : I had no interesting examples. The first thing that comes to mind is the study of the Strangelove SCADA team, in which they “modeled” the attack on the Siemens WinCC SCADA / HMI system. The WinCC Web Navigator server is written on the .NET platform, and researchers have found a whole bunch of vulnerabilities in it: XPath Injection, Path Traversal, more than 20 XSS, CSRF, SQLi, and others. Using these vulnerabilities, the guys suggested what an attack on a real SCADA system might look like if the attacker is located outside the perimeter of the attacked network, as in the real world. You can see a report with PHDays about this attack.

Vladimir : The most memorable incident was an attack on the users of the forums of the site RSDN.org in May 2014, whose engine is currently running on ASP.NET MVC. One of the regulars, offended by the policy of moderation, began methodically brutessing the credentials of other users and using them to publish an avalanche of meaningless or offensive messages. At that time, the site's engine did not use any means of controlling the complexity of the passwords used, and as a result, the attacker managed to pick up passwords for more than a dozen accounts before the attack was stopped. In the registration and change password forms, control of its complexity was implemented and the passwords of users whose accounts the attacker managed to get were reset.

After that, we took a database of user password hashes and carried out an offline dictionary attack of dictionary selection of ~ 250K elements. As a result, 83,165 registered at that time users accounted for 11,017, whose passwords were able to pick up in a reasonable time. Their passwords were also reset, and notifications were sent to the mail about the need to undergo a password recovery procedure.

It is noteworthy that after all this, the attacker still had the opportunity to use the accounts under which he had already managed to log in and whose authorization cookies he used to organize the attack. The fact is that the authentication token ASP.NET implements the concept of so-called. "Disconnected authentication" and, by virtue of the ASP.NET design, is life-long valid, without the ability to revoke it from a specific user.

Thus, even after changing the passwords of the affected users, the attacker was left with working authentication tokens, using which he could easily enter under these users in the future. In order to invalidate all of its tokens, we had to change the machine key used to encrypt authentication tickets, which made absolutely all previously issued tokens invalid and caused the mass reauthentication of all users of the site.

- Is it possible to make a 100% protected application using the .NET Framework? What is required for this?

Michael : No. It is impossible to make a 100% protected application on any platform. Everything is even worse, if you create a 100% protected application with the help of magic and deals with the devil, you cannot prove that it is 100% protected! It is theoretically impossible to verify any nontrivial algorithm for an adequate time, including the requirements of security.

Developing a secure application is a special case of developing an application that does not contain errors at all. I think every developer intuitively understands that this is an unattainable perfect result, to which we all endlessly strive. In addition, your application uses third-party libraries, the security of which is also not guaranteed, then it runs on the OS and hardware.

Often we can not even say on which OS and on which hardware. And all this changes over time! I think any attempt to achieve 100% is doomed to failure with so many unknowns.

In my opinion, the .NET Framework is a good choice for building secure applications. I would already bet on .NET Core. This is a small, cross-platform open source framework supported by a large company with vast experience in the development of secure systems. I foresee the skepticism of Linux users about the last phrase :) Without going into the statistics of the found and fixed vulnerabilities, for me was an indicative battle “Windows vs. Linux ”at one of ZeroNights , where at the end the audience decided that it was a more secure platform ... The majority voted for Windows!

Vladimir : Let's fantasize a bit and imagine that this is really possible. In other words, we assume that there is some finite set of rules, following which the developer is guaranteed to receive a safe application at the output. What is each such rule? This is a kind of algorithm that describes step by step the developer’s actions to create a secure application for him. As we have already agreed, the set of all such algorithms is finite, and, therefore, is enumerable and solvable. Consider the addition of this set, i.e. a set of all other theoretically possible algorithms that do not affect the security of the application. Obviously, it is infinite and includes algorithms based on the fact that they have a very specific nontrivial and invariant property. And this means that, by the Rice theorem, it is insoluble. But, since it is not solvable, its addition (that is, the very set of rules for developing a secure application) is not enumerable, according to the Post theorem. And therefore, to be finite, well, can not.

If we move from the theoretical plane to the applied one, the concept of managed code and strict type control saves .NET developers from having to think about low-level security problems associated with memory corruption, dereferencing null pointers, format strings, type mixing, etc. However, all high-level security flaws associated with data preprocessing, access control, and multithreaded access to resources are still possible. Not to mention the shortcomings of business logic, for which at the moment there is not even an intelligible classification or formal model, and therefore, recommendations on how to avoid them.

- What do you think is missing in .NET in terms of security?

Mikhail : I would like to see a data sanitization process that is more transparent for the developer so that the programmer does not think about the context where this data will be inserted. This can be partially implemented with the current approach. For example, the cshtml page parser knows about the context into which the data will be inserted, namely, it knows all the nested grammars of the current node in the parse tree. This means that he can fully sanitize the data in this context in order to avoid even a theoretical possibility of an injection. Now the programmer needs to take care of this and choose the correct sanitization algorithm, i.e. valid encoder call or call sequence.

Since .NET Core is a completely open project, I hope that my hands will reach at least proof-of-concept-implementation of this idea in the near future. Or I will be happy if someone from the readers picks up this idea and implements it.

The next thing is session data protection. This problem has been known since the “big” .NET Framework. In .NET Core, it has somewhat worsened, and the attacker has more opportunities to conduct an Session Fixation attack. I will talk in detail including about this in a few days in the report “ASP.NET Core: Attack Prevention Mechanisms 2.0” at DotNext 2017 Moscow.

And third, in my opinion, ASP.NET-templates by default should impose the best security patterns in writing web applications in order to instill the right approaches in the development of secure systems. Mostly minor changes are needed, such as enabled and properly configured CSP, protection against CSRF for all POST / PUT / DELETE requests, added security headers to server responses. But often it is the absence of these little things that can be the cause of a successful attack on your application.

Vladimir : First of all, the elimination of “childhood diseases” related to safety and stretching from the first versions of the framework. Take at least the BinarySerializer (used in the same Remoting). During deserialization, this serializer does not check the expected and deserializable types before instantiation. This allows an attacker to transfer an arbitrary type to the deserializer, as a result of which the constructor of this type will be executed, all its properties will be filled and its finalizer will be executed later. This is enough for any application deserializing the input data using the BinarySerializer to be unconditionally exposed to attacks on deleting arbitrary files and SSRF on the SMB server controlled by the attacking SMB server, and also (if certain conditions are met) - and attacks on the execution of arbitrary code: https://blog.scrt.ch/2016/05/12/net-serialiception/ . Nothing prevents the BinarySerializer from implementing a preliminary match of the expected type to the deserialized BEFORE creating the instance. And the current behavior is optional for backward compatibility.

If we talk about C #, then, from a security point of view, it lacks the built-in tools of contract programming. At least at the level at which this is implemented in the Nemerle language, where functions can be defined for any method or class, confirming the fulfillment of pre- and post-conditions for the methods or ensuring control of invariants in the case of classes. In C #, one could go further and allow to define such "strict" methods and classes, marking them with a key word like "strict", for which explicit checks of their contracts would be mandatory. This would close a significant part of the problems associated with both the disadvantages of data preprocessing and business logic vulnerabilities.