Geekly Articles each Day
📜 ⬆️ ⬇️

Implement security in the development of a large project



In this article, we would like to share our experience of introducing our team of pentesters into the development cycle of the large project “MyOffice”. It is almost impossible to find material of a similar subject with real cases in Russian. Anyone who is interested in fashion trends pentest, theory, practice, methods, tools and actually found vulnerabilities in the context of secure development - welcome under cat. The article is replete with useful links to theoretical and practical materials. But let's order.


Disclaimer:
The article consists of two parts. The first part is the organizational one, which defines the problem, tells in general about the approaches to penetration tests and about our ways of solving the set tasks (certainly contains information that many people know). The second is more technical, with a description of the tools used and the vulnerabilities found.
If you,% username%, like technical details, you can proceed to the second part.
And, of course, do not forget your tea with cookies.


We collect and distribute


Some presentation of approaches to pentest


It is worth starting with a short introduction describing approaches to pentests and their features. Based on our experience covering various companies of a diverse profile, the following division seems optimal.


Single penetration test


The classic option is when an organization (including banks and public sector companies) comes to a company that provides penetration testing services and issues scopes of addresses to pentesters. After work, the executing team makes recommendations for fixing vulnerabilities.


Types of jobs:



In security, as in any complex process, there is no “silver bullet” - no tool in itself will give full confidence in the security of the system, be it antivirus software, intrusion detection systems, etc. The same can be said about penetration tests, in which there are no universal approaches, since each of them has its own minuses and advantages.


A one-time penetration test is effective for assessing the overall state of security — Pentesters conduct a simulation of a situation in which an attacker with limited finances and in a short time tries to penetrate the system, and how much damage it can cause to the customer’s company.


Penetration test with repeat N once a year.


The approach repeats the “one-time pentest” or its individual parts. In this case, the security audit is performed several times a year. Types of work are the same as in the first approach.


After the first audit with an assessment of common security problems, this approach makes it possible to keep up-to-date with the applied patches to the found vulnerabilities during past audits, problems encountered when applying patches (yes, it happens) and based on the results of the following audits.


This option allows for a more thorough examination of the company's perimeter by auditors due to their increased awareness of services on the results of past penetration tests.


Bagbounty outsource


The essence of this approach is in the creation of its own bug-bout program on an open / closed basis, which is managed by an outside organization. Such a team attracts pentesters to their work on constant conditions and makes payments for each vulnerability separately. This is a good opportunity for additional income for researchers. An example of using this approach is the American company SYNACK.


A reasonable question arises: “How does this differ from HackerOne?” The main difference is in the number of researchers and their skills. To get into the program you need to have an interview and a test task, as when applying for a job in an off-line company. Consequently, it turns out fewer participants, but above the general level of skills (and the absence of all the well-known characters who like to throw the reports of scanners).


Types of work (within the framework of this approach):



The approach involves the constant study of their services by dozens of human “scanners”, motivated by rewards for vulnerabilities. It allows you to provide greater coverage during the work.


Despite the above advantages, the approach has its drawbacks:



Work on the analysis of security on an ongoing basis


This approach is considered in detail in our article. Its essence is in the constant research of the products being developed from release to release.


The list of types of work in this case is somewhat broader than the approaches described above. It includes:



As for items such as Desktop applications and Hardering, the task is not to search for binary vulnerabilities (if we talk about desktops) and not to totally tighten the screws (in the case of Hardering). The main thing is to look at the system from the Pentester side.


The peculiarity of the approach is that it is as close as possible to the work of security guards on the ground in companies that create protection from within, namely:



As a result, it turns out that the works are carried out not by black, but by all of us, the beloved white box.




It is important to note that this approach also helps to solve such a problem as the lack of the company's own resources (security specialists) for analyzing application security. Many researchers prefer off-line companies to work because of the presence of permanent experience in different areas of information security, and outsourcing them can compensate for the lack of resources.


A little about SDLC and his friend SecureSDLC


SDLC


Let's start with the definitions. SDLC is the development framework that defines the process organizations use to create an application from the inception of the idea to launch.


At the moment there are a large number of SDLC models, the most famous of them are Waterfall, Iterative, Agile (for more information about them you can read here ). All of them have their advantages and disadvantages, each of them is very variable in use; it all depends on the size of the project, budget, amount of human resources and other features. All of them are united by the presence of six key stages:





Securesdlc


SecureSDLC - the same SDLC, but with the prefix Secure. Just add a prefix, and everything becomes safe (no). The essence of all this is quite simple: as seen in the beautiful picture from the Internet, safety-related actions (risk calculations, static / dynamic code analysis, fuzzing, training, etc.) are added to each of the development stages.


image


In the classical SDLC implementations, the security check was limited to the testing phase, if at all.


Extended implementation aims to:



What is it all based on?


Currently there are a large number of companies practicing safe development. For example, such large and famous, as Microsoft, Cisco, Dell. Today, any self-respecting vendor monitors the security of their decisions (but this is not always the case). Absolutely each manufacturer has its own approach, which is formed on the basis of the internal features of the development.


As a skeleton, in building their safe development, many people use common practices in the world:



In the next picture from the Internet, you can see the compliance of business functions and security practices.




Conditions of the problem


We are currently conducting a large project (details and features further), working in two major areas: pentest of developed products and binary research. In this article we will focus on the Pentester part.


Initially, our process of searching for vulnerabilities in this project went from one-time pentest to pentest, repeating several times a year - both the external perimeter services and the products being developed. These approaches, in our opinion, proved to be not so effective, in contrast to projects on the analysis of security on an ongoing basis.


What did not suit us in the classical approaches? A single pentest has some drawbacks:



Due to the low awareness of the auditors about the internal features of the products being developed and the absence of any division into components (for a pentester, the products look like a certain scopa of addresses, mobile application packages or desktop binaries), the list of products looks like a bookshelf with a large number of books on the backs Which names are absent - eyes run up from abundance of services.



')

Because of this, the problem of allocating time appears - it is allocated to the entire project as a whole, and some component may be given less attention. Resources are allocated inefficiently, and it is not suitable for in-depth study of products. Therefore, it was decided to divide the products into conditional components.


We collect the list of products


In our case, we are working with the company "New Cloud Technologies" on their product "MoiOffice", which is a platform for the joint editing of documents, file storage, mail system, messenger. For all this, there are both mobile and desktop versions.




Before starting work on such an extensive product as MoiOffice, it is necessary to single out its main modules and parts (even seemingly indivisible) so as not to have the same bookshelf. This is also necessary for a better understanding of the internal processes of applications and the distribution of team resources.


We did it this way:



All of this together provides a great interest for the researcher: as an opportunity to explore some previously unseen technologies, and to get more into the already studied topic.


Sprint planning


In order to seamlessly integrate into the process of developing such a product, we need to adapt to its global planning cycles, in our case release cycles. The release of new versions of "MyOffice" occurs every three months. Therefore, we live in sprints for just three months. What is the sprint in our understanding?


Sprint for us is a cell of time, within the framework of which we try to plan our works as much as possible. Inside the big sprint we have a smaller unit of measure - a slot, which is equal to one week. We take the products available to us, we look at the cycles and terms of changes in them, and in the necessary sequence we put the audits of these products in the schedule of our sprint, splitting into slots.


Naturally, we understand that planning deadlines in the development, to put it mildly, is very bad, because we expect a legitimate question: “And if deadlines are coming, what are you doing?”




Here comes the old game of childhood - “tag”. Remember, there was an empty cell, through which it was possible to move other chips, and thereby change the order, without going beyond the box? In our case, the box is this “sprint”.


It was decided to increase the number of empty slots, since there are various “unscheduled” works, re-surveys of third-party solutions used in the products being developed, as well as other works that may be related to the project. Thus, we are mobile in planning, and empty slots can always be filled.


An example of one of the sprints (the first number is the week number of the sprint):


  1. Component Web Applications (Mail, Contacts, Calendar)
  2. Component Web Applications (Mail, Contacts, Calendar)
  3. Native mobile apps for Android, iOS, Tizen
  4. Native mobile apps for Android, iOS, Tizen
  5. Authentication server; Web application backend
  6. File server backend, Web panel and admin API
  7. Document Editor Web Panel, Backend Editors
  8. Desktop client for file server
  9. Desktop client for mail, calendar, contacts, documents
  10. Messengers for Web, MacOS, Win, Linux and their API
  11. Misc
  12. Misc
  13. Misc

Misc are just those free slots, their presence is very important. As you can see, for some, quite large parts (like the Web, where the API part is also checked), we put in more time (10 working days). Also, Misc includes additional research and joint development of a security-oriented architecture together with the customer’s specialists.


Team of auditors


For such a project from our side, it was very important to choose a team that has expertise in all areas of interest at once (all, of course, universals, but everyone understands something more, for example, in the analysis of mobile applications). In the end, it turned out three people working fulltime on the project and in constant contact with the customer.


Based on the availability of expertise for everyone in any direction, inside the team there is sharing experience between auditors. Even with the rotation of auditors with other teams, the experience remains inside, because, if necessary, only one person is replaced. “Newbie” during the week learns the organizational peculiarities of the work and after the first sprint has expired gets a complete picture and understanding of the interaction of a large number of components with each other.


Stands


In our tests, we use a complete copy of what is delivered to customers, with all the latest updates. Looking ahead, we say that we considered it quite important to fully deploy the entire “MyOffice” from scratch and understand every step, where, what and how is deployed and configured, along the way trying to compare it with the documentation. Considering that our specialization is far from system administration, it was a difficult task for the “Padawan of the Young”.


Reporting


Since we are big fans of bugbounds and are not like writing reports and generating official texts, it was decided to move away from the reports inherent in the classic penetration tests, and learn from the experience of bugbaunt programs.


In our approach, we use JIRA to create tickets (developers and testers use this, why not start it, too), where there are absolutely standard fields like on HackerOne:





With such a report of information, absolutely anyone will understand how critical this vulnerability is, even without any qualification in security or in general in IT.


Security analysis. Little practice


Disclaimer: we try to make articles so that everyone can take something new and interesting out of the article. So, from the first part, the manager or team leader can probably learn the tactics of project management, while from the second part, information security researchers and developers can be useful.


It looks like the introductory part is revealed. Let's go directly to the very analysis of security (hooray, technical details).


One of the interesting components of the work for an experienced pentester is the use of fashionable and modern technologies. Let's look at them. Before we begin, we, of course, looked at the Web, registering along the way with the names:


'“><svg onload=alert(1)>{{7*7}}

Picked files, sent mail, put mobile applications and generally looked around how everything works.

Then we went to the development team and together we sat down over the server architecture diagram on a large sheet of A1, which hardly fits on the wall of the office. We will not insert it here, but on the whole everything is pretty standard and cool:



Web


The client part is AngularJS and a full-fledged SPA without obvious crutches from the server API (such as “here we’ll give back the backend form!”).


The server part is different, nginx is used as the front, followed by many java / golang services that process client requests.


Analyzing SPA-applications is very cool and quite convenient, from the point of view of requests-responses, everything is logical and smooth. Finding vulnerabilities in the SPA itself is, of course, a rather difficult task.


Burp suite


Yes, there is no secret, we, like many, use Burp (no Larry Lau, only a license) and its modules to search for all sorts of vulnerabilities (injections, IDOR , SSTI and others). Without this tool in any way.


Also, developers can use it to check the result after fixing a vulnerability, instead of asking us and stretching the whole process. For this, a free version and two tabs Proxy and Repeater will suffice.




We also use a bunch of custom scripts, consider one of them.


As you already know, among the products we are researching is mail. One of the most powerful attacks here can be XSS in letters. And it is still complicated by the fact that in letters you can use HTML to create beautiful letters in corporate styles, and not just plaintext. The developer has the task of making it possible to use HTML so that the sender cannot inject his javascript.


In the security world, there is a researcher Mario Heiderich @ 0x6D6172696F (.mario), who spent a lot of time searching XSS in various large services like Google, participated in the creation of the DOMPurify library for safe unsafe html substitution in the DOM right away (more details will be discussed below). And most importantly - he published autotests for her, which use various tricks and subtleties of browsers and HTML5. The ideal solution for testing mail service on the possibility of implementing JS.


→ Link to demos and tests
→ And don't forget about the special vectors for HTML5


What have we done? We took these tests (+ added some of our secret bins) and sent them to the IMAP server with our Python script of ten lines, because usually HTML cannot be sent from the Web client, but only directly to the mail server, simultaneously opening letters in the browser. JS is over? We get a ticket.


Surely everyone knows that it is possible to detect the opening of a letter by the user using the image (img tag) in the letter, but other tags may allow us to do this. Here again, the Cure53 repository will help us . With it, you can find tags that merge information about users.


The restriction of schemes for some tags, for example, why file: /// cannot be used for the same "img src" (for details on the link from ValdikSS ), were immediately taken into account during development.


The next problem is investments. Be sure to test attachments of different formats with XSS-load, you can take them here . By this we check how the server stores and sends the attached files in letters.


Mobile applications


All applications for each of the platforms are classic native applications.


Both approaches are used to study iOS and Android: automated and manual. For Tizen - only manual. Pro automated - MobSF is very helpful in removing “low-hanging fruits”.




It allows you to automatically collect typical problems, revise receivers, services, etc. things in Android and even performs some sort of source code analysis (after decompiling). It also checks for flags (Stack smashing protection, PIE ...) when compiling.


Manual analysis - Android (+ root), iOS + jailbreak (at the moment we are using the latest available jail for iOS 9.3.3).


But with Tizen is not so simple. He himself is very strange and unaccustomed. The system is one big browser with support for HTML5, has been in development for a long time and is also of interest to security researchers as something new and unexplored.


For starters, the question is - how much did you keep phones with TizenOS? Here are the same articles and security tools for this platform. We went through the developer way - we downloaded the Tizen SDK, connected to the phone and debugged the application. In this mode, you can browse the file system, get a debug console, and do other things that let you find problems in security. Unfortunately, the functionality is rather limited, and there is no direct console access to the OS.


The tool is on the official Tizen website. You can use the emulator if you want to get acquainted with this operating system.




The Tizen platform itself currently has a large number of security flaws. We can recall the recent news about forty grain makers in the platform and this publication . Also about some vulnerabilities in SmartTV, where TizenOS was affected, told BeLove - the presentation .


Desktop


There will be a separate article about binary fuzzing about desktop applications “MoyOfis”. Within the framework of these works (specifically in pentest), such areas as interaction with the file system (temporary folders, rights to them, etc.), DLL hijacking, work with the network (data transfer via secure channels - TLS), storage tokens and the like.


Many desktop applications are based on Electron, on which GitHub, Slack, Discord, and many other solutions are created. Electron itself is an open project and is a webview, that is, a small browser that cannot be visually distinguished from a native application.


Research third-party products. DOMPurify and where does Safari


Often, when studying the safety of a product, there is a problem related to the fact that it is not always transparent and understandable where the vulnerability was found: in the customer’s custom written code or in a third-party product, libraries, and frameworks that are used in development. We also had such a case.


In the study of one of the components, we found a rather critical client-side vulnerability - JS code injection, well, or just XSS. Initially, it was not clear why this happened, because this component used the very JS DOMPurify library to protect against XSS.


DOMPurify is a DOM-only, ultra-fast, uber-tolerant XSS disinfecting solution for HTML, MathML and SVG (a little bit of the description from Gita). MathML is an XML-based markup language for representing mathematical symbols and formulas. All this, of course, works in the context of HTML5 chips. That is, this product contains all the newest and most modern.


It is written in JavaScript and works in all popular browsers:



The tool is developed by the Cure53 company, in particular, Mario Heiderich @ 0x6D6172696F (.mario), and such famous guys as @filedescriptor , @shafigullin and others donate to it. It turns out that such a team of the coolest web security researchers is working on open source software to protect against client-side vulnerabilities.


A reference to Git .


Having a little thought about it, we came to the conclusion that the vulnerability is not really in the developed application, but in the connected JS-library.


Next, we checked the vulnerability on the latest version of DOMPurify and were very surprised that such a simple payload worked without any tricks, but only under Safari.


 Payload: <svg onload=alert(document.domain)>



The guys quickly fixed the vulnerability, and the company FastMail, which took DOMPurify under the wing of its bug-out program, paid us a little bit of money “for beer”.


But this was not the end, since the hole worked only for Safari, we dug up a little in his direction and it turned out that the DOMParser function does not work correctly, and when parsing the html page it executes JS, which no popular browser does (yes, yes, IE), which we reported to Apple.


 Payload: new DOMParser().parseFromString('<svg onload=alert(document.domain)>', 'text/html');



And just the other day, Apple issued CVE-2017-7038 - something very similar to UXSS — vulnerability, but without SOP bypass. In more detail about all possible vulnerable functions, perhaps, we will sometime describe in separate article.


As a result, such a non-trivial scheme turned out: XSS in the application “MoyOffice” was possible due to the connection of the DOMPurify library, which did not process SVG tags (although it should have been), but gave directly to the standard browser function DOMParser, which was implemented with an error.


In this long way, we fixed the vulnerability not only for our client, but also made the world a bit safer.


Real vulnerabilities


It is impossible to write something big and not to allow any bugs, there is no such methodology. Therefore, we analyze a couple of real vulnerabilities with a high level of criticality.


Implementing external XML entities


Since we have the storage and editing of documents, we somehow have to draw the document to the user and make changes to them, if necessary. As you may know, modern office documents are a collection of XML files packed into an archive. And what is editing documents without an XML parser?


Every Web browser immediately thinks about XXE . How to see this vulnerability in action in this case?



That's just step number three is dangerous, it is carried out using an open source library in which it was possible to connect external entities. What we did:



 <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> … <foo>&xxe;</foo>


And after processing, we saw the contents of / etc / passwd. But using this vulnerability can not only read files on the server.




Anyway, we did not manage to read anything important, since all the parsing takes place in an isolated container (docker). Vulnerability was promptly closed.


By the way, to generate such files and check XXE you can use the tool . With its help, some researchers have found the XXE and in the bug-out programs too.


Remote Command Execution via EL Injection


Let's tell about honest RCE - remote execution of OS commands on the server. Some microservices are written in Java, including using Spring. Vulnerabilities of this kind ( EL Injection ) for Spring (and not only) are very well fuzzy, if you send {{7 * 7}} to the server, then in the answer on the page you will receive a mathematical function equal to 49.


Next, you can already try to perform the functions of the language and even run the command with:


 ${T(java.lang.Runtime).getRuntime().exec("ls")}

More details about a similar vulnerability in the Spring Boot Oauth module can be found here . And then the ticket on the gita, describing the problem that caused the execution of the code in our case.


But in our particular situation, such a simple sending of payload did not work, because when sending a request to the Web server, our quotes passed the URL-encode and were not perceived by the Spring as special characters. What to do in this situation? Everything is quite simple: you can, using standard language tools, encode from numeric values ​​to characters using the java.lang.Character.toString () function and concatenate all characters. About this trick you can read here .


As a result, we got a big and scary payload (read / etc / passwd /):


 ${T(org.apache.commons.io.IOUtils).toString(T(java.lang.Runtime).getRuntime().exec(T(java.lang.Character).toString(99).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(116)).concat(T(java.lang.Character).toString(32)).concat(T(java.lang.Character).toString(47)).concat(T(java.lang.Character).toString(101)).concat(T(java.lang.Character).toString(116)).concat(T(java.lang.Character).toString(99)).concat(T(java.lang.Character).toString(47)).concat(T(java.lang.Character).toString(112)).concat(T(java.lang.Character).toString(97)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(115)).concat(T(java.lang.Character).toString(119)).concat(T(java.lang.Character).toString(100))).getInputStream())}

It is worth noting that the RCE was also inside the docker-container, and although it was not created for protection, it still provides some sort of isolation.


Conclusion


Phew, that’s the end of the article. Let's now summarize how our approach differs from the classic penetration tests:



Each approach should be improved and, for the sake of completeness, you can expand the team with highly targeted specialists, add more vigorous action to the developers and engage in their training in the field of security.


Of course, this approach also does not give one hundred percent confidence in the safety of products, but it is more methodical and extensive than the classic penetration tests. It is aimed at responding as quickly as possible to the release of a new code and the elimination of vulnerabilities as early as possible.


We hope that you were able to bring out something new for yourself and have gained an understanding of how work is done on finding vulnerabilities in large projects.


useful links



PS I express my gratitude for the help in the preparation of the material BeLove .

Source: https://habr.com/ru/post/334692/

More articles:


All Articles