Home Tags Checksum

Tag: Checksum

VU#507496: GIGABYTE BRIX UEFI firmware fails to implement write protection and...

GIGABYTE BRIX UEFI firmware for the GB-BSi7H-6500 and GB-BXi7-5775 platforms,versions vF6 and vF2 respectively,fails to properly set the BIOSWE,BLE,SMM_BWP,and PRx bits to enforce write protection. It also is not cryptographically signed. These issues may permit an attacker to write arbitrary code to the platform firmware,potentially allowing for persistent firmware level rootkits or the creation of a permanent denial of service condition in the platform.

JSA10770 – 2017-01 Security Bulletin: Junos Space: Multiple vulnerabilities resolved in...

CVE CVSS base score Summary CVE-2016-1762 9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) The xmlNextChar function in libxml2 allows remote attackers to cause a denial of service (heap-based buffer over-read) via a crafted XML document. CVE-2016-444...

VU#884840: Animas OneTouch Ping insulin pump contains multiple vulnerabilities

Animas OneTouch Ping insulin pump contains multiple vulnerabilities Original Release date: 04 Oct 2016 | Last revised: 11 Oct 2016 Overview The Animas OneTouch Ping insulin pump contains multiple vulnerabilities that may allow an unauthenticated remote attacker to obtain patient treatment or device data, or execute commands on the device.

The attacker cannot obtain personally identifiable information. Description CWE-319: Cleartext Transmission of Sensitive Information - CVE-2016-5084 The Animas OneTouch insulin pump transmits patient treatment data and device data such as encryption passwords over the network in cleartext.

An unauthenticated remote attacker may be able to sniff all associated wireless transmissions from the device.According to Johnson and Johnson, parent company of Animas: "Information between the pump and meter is unencrypted, which could allow a malicious actor to capture patient treatment data, however this data does not include personally identifiable information." CWE-330: Use of Insufficiently Random Values - CVE-2016-5085The Animas OneTouch insulin pump uses a CRC32 checksum as if it were an encryption key.

This value then does not change between authentication handshakes between the same device and remote station.

According to Animas and Rapid7, "A malicious actor may be able to listen to communication between the pump and meter remote and obtain the necessary information to spoof being the meter remote."CWE-294: Authentication Bypass by Capture-replay - CVE-2016-5086The Animas OneTouch insulin pump uses a custom communication protocol that does not provide sufficient protections to guard against capture-replay attacks.

According to Animas and Rapid7, "Once a malicious actor has spoofed being the meter remote, he/she could learn commands a patient initiate from the meter remote to the pump and attempt to replay them from a device other than the meter remote to the pump. Please refer to the mitigation section [see Resolution below] for details on controls in place to reduce this risk."CWE-290: Authentication Bypass by Spoofing - CVE-2016-5686The Animas OneTouch insulin pump uses a custom communications protocol that does not provide sufficient protections to guard against spoofed responses. Reportedly, it may be possible for an unauthenticated remote attacker to spoof acknowledgement packets to perform actions or commands on the device, or cause a remote to believe an acknowledgement was received after performing a command. Impact An unauthenticated remote attacker may be able to sniff patient treatment or device data from communications, or execute commands on the device and/or remote, or prevent actions from occurring by spoofing acknowledgement packets.

The attacker cannot obtain personally identifying information. Solution Johnson and Johnson has provided the following statement: "There are no plans to release a firmware update, however a notification is being sent to patients and HealthCare Professionals.
In addition, there are a number of documented and proprietary mitigating controls in place to ensure the safe delivery of insulin, outlined below.
If patients are concerned about unauthorized access for any reason, the pump’s radio frequency feature can be turned off, which is explained in Chapter 2 of Section III of the OneTouch® Ping® Owner’s Booklet. However, turning off this feature means that the pump and meter will no longer communicate and blood glucose readings will need to be entered manually on the pump.
If patients choose to use the meter remote feature, another option for protection is to program the OneTouch® Ping® pump to limit the amount of bolus insulin that can be delivered.

Bolus deliveries can be limited through a number of customizable settings (maximum bolus amount, 2-hour amount, and total daily dose).

Any attempt to exceed or override these settings will trigger a pump alarm and prevent bolus insulin delivery.

For more information, please see Chapter 10 of Section I of the OneTouch® Ping® Owner’s Booklet.

The company also suggests turning on the Vibrating Alert feature of the OneTouch® Ping® System, as described in Chapter 4 of Section I.

This notifies the user that a bolus dose is being initiated by the meter remote, which gives the patient the option of canceling the bolus.

The bolus delivery alert and the customizable limits on bolus insulin can only be enabled on the pump and cannot be altered by the meter remote.

This is also true of basal insulin. Patients can also be reminded that any insulin delivery and the source of the delivery (pump or meter remote) are recorded in the pump history, so patients can review the bolus dosing."
Vendor Information (Learn More) Vendor Status Date Notified Date Updated Johnson & Johnson Affected 09 May 2016 04 Oct 2016 If you are a vendor and your product is affected, let us know. CVSS Metrics (Learn More) Group Score Vector Base 9.3 AV:N/AC:M/Au:N/C:C/I:C/A:C Temporal 7.3 E:POC/RL:OF/RC:C Environmental 6.5 CDP:H/TD:M/CR:H/IR:H/AR:H References Credit Thanks to Tod Beardsley of Rapid7 for reporting this vulnerability. This document was written by Garret Wassermann. Other Information Feedback If you have feedback, comments, or additional information about this vulnerability, please send us email.

A malicious pairing of cryptor and stealer

We have already seen some cryptor attacks where malicious programs with different functions have been used in combination.

For example, one version of the Shade cryptor checks victim computers for signs of accounting activity; if it finds any, it doesn’t encrypt the files, but instead installs remote control tools in the infected system.

The bot can then be used by cybercriminals to steal money, a much more profitable outcome than just receiving a ransom to decrypt some files. The owners of the RAA cryptor, however, took a different tack.

The Trojan is delivered in emails that mostly target corporate users.

After a successful infection, RAA executes its main task, i.e. encrypts the user’s files. However, it doesn’t stop there: some versions of RAA also include a Pony Trojan file, which steals confidential information from the infected computer. Using the stolen data, the cybercriminals can gain access to the victim’s mail clients and other resources. We can assume that the owners of RAA use these resources to carry out targeted attacks – sending out emails with the cryptor malware to the addresses on the victim’s contact list.

This substantially improves the probability of subsequent infections. In this article, we will provide details of how a pair of malicious programs – a new version of the RAA cryptor and the Pony stealer Trojan – work in unison. The RAA cryptor The RAA cryptor (Kaspersky Lab verdict: Trojan-Ransom.JS.RaaCrypt) was first detected in June 2016.
It caught the attention of researchers and analysts due to the fact that it was written entirely in JavaScript, which is a rarity when it comes to ransomware cryptor Trojans. We recently detected a new version of this Trojan that has a few differences from earlier known modifications. Let’s have a closer look at this particular sample, which has been assigned the verdict Trojan-Ransom.JS.RaaCrypt.ag. Propagation The body of this new version of RAA is a script in JScript (with a .js file extension).

The malicious script is sent to potential victims attached to a spam message in a ZIP file with the password ‘111’. The attack is aimed primarily at corporate users: the message mimics finance-related business correspondence, and the script’s name is similar to those shown below: Счета на оплату _ август 2016 согласовано и отправлено контрагенту для проведения оплаты _aytOkOTH.doc.js (Invoice_August 2016 approved and sent to contractor for payment _aytOkOTH.doc.js) Счета на оплату _ август 2016 согласовано и отправлено контрагенту для проведения оплаты _EKWT.doc.js (Invoice_August 2016 approved and sent to contractor for payment _ EKWT.doc.js) “Let’s presume we made a concession when we allowed you to postpone your due payment. “We understand you may have difficulties, but do we have to wait for another two months? To be honest, we don’t really want to go to court. Please make all the payments in next few days.” The message includes a notice saying: “The company… notifies you that in line with internal security regulations, all outgoing emails are subject to asymmetric encryption. Dear client, your password for this message is 111.” People who know what ‘asymmetric encryption’ is will probably just smile at this; however, the message is obviously targeting a different audience. It should be noted that sending malicious content in a password-protected archive is a well-known trick used by cybercriminals to prevent anti-malware systems installed on mail servers from unpacking the archive and detecting any malicious content.

To unpack an archive like this, the anti-malware product must automatically retrieve the password from the message, which isn’t always possible. For an infection to occur, users have to unpack the archive themselves and launch the .js file. Script obfuscation The code of the malicious script was deliberately obfuscated to complicate things for malware analysts.

The content of the script looks like this in the source code: Fragment of the obfuscated code If we restore the line breaks and indents, it becomes obvious that the obfuscation involves renamed variables and functions, as well as strings hidden in the global array.

After de-obfuscation and function renaming, the same section of code becomes much easier to read. Fragment of de-obfuscated code The script is nearly 3,000 lines long. Most of this is taken up by an implementation of the legitimate DLL CryptoJS, and an implementation of the RSA encryption procedure, which was also taken from public sources by the cybercriminals. How the Trojan works To lull the victim into a false sense of security, the RAA cryptor demonstrates a fake Microsoft Word document immediately after it launches.

This document is in fact an RTF file specially crafted by the cybercriminals. (The document is contained in the Trojan’s body encoded in Base64 format.) The fake document displayed to the victim While the user is reading the message about a document that’s supposedly not being displayed properly, the Trojan is doing its dirty work: Registers itself to be autostarted with Windows; Deletes the registry key associated with the VSS service (to prevent the restoring of files from shadow copies); Sends a request to the C&C server (unlike all previous versions of this Trojan, this version doesn’t wait for the delivery of keys from the server – the request is only sent so the cybercriminals can collect statistics); Proceeds to search for files and encrypts them. Key generation Unlike earlier RAA modifications, this version of the cryptor does not request an encryption key from the C&C.
Instead, the Trojan generates a session key on the client.

To do so, it calls the WinAPI function RtlGenRandom which is considered a cryptographically secure generator of pseudorandom numbers. To ensure it can call WinAPI functions from JS code, the Trojan uses a legitimate third-party OCX component called DynamicWrapperX.

The Trojan stores it in its body in a Base64-encoded format, and installs it in the infected system. RAA has both 32-bit and 64-bit versions of DynamicWrapperX so it can attack systems running under both Windows architectures. The Trojan encrypts the generated session key with an RSA algorithm (the public RSA-2048 key is contained within the script) and saves it to a file with the name “KEY-…”, where the multiple periods stand for a unique 36-character infection ID. File encryption RAA searches for and encrypts files with the extensions .doc, .xls, .rtf, .pdf, .dbf, .jpg, .dwg, .cdr, .psd, .cd, .mdb, .png, .lcd, .zip, .rar, .csv whose names do not contain the substrings “.locked”, “~”, “$”. When searching for files, the Trojan skips folders named “WINDOWS”, “RECYCLER”, “Program Files”, “Program Files (x86)”, “Windows”, “Recycle.Bin”, “RECYCLE.BIN”, “Recycler”, “TEMP”, “APPDATA”, “AppData”, “Temp”, “ProgramData”, and “Microsoft”. When processing each file, RAA uses the session key to generate a file key and initialization vector (IV).

The contents of the files are encrypted in different ways depending on the file size: 0 to 6,122 bytes: the file is encrypted in full. 6,123 to 4,999,999 bytes: three fragments are selected for encryption in different sections of the file.

The first, 2000- to 2040-byte fragment is selected at the beginning of file; the location and size of the two other fragments depend on the size of the first fragment and the overall size of the file. 5,000,001 to 500,000,000 bytes: two fragments of 90000-125000 bytes are selected for encryption (from the beginning and end of the file). 500,000,001 bytes and larger: not encrypted. A string is added at the end of the encrypted file that contains “IDNUM” (infection ID), “KEY_LOGIC” (indexes to construct the file key from the session key), “IV_LOGIC” (indexes to construct the IV from the session key), and “LOGIC_ID” (possible values are “1”, “2” or “3” – the selected encryption method depending on the file size).

The encrypted file is given the additional extension .locked. The string added to the end of the encrypted file Ransom demand When the files are encrypted, RAA displays a file with the cybercriminals’ demands and contacts in WordPad.

The Trojan fills the text template with a 36-character ID which is unique for each case. The file containing the cybercriminals’ demands The cybercriminals suggest that the victims purchase a file decryption key and software from them.

Two methods of communication are available: email and the Bitmessage service.

The victim is expected to pay for the decryption key in bitcoins. Plus a stealer Trojan The damage caused by the Trojan is not limited to encrypting files. Like some of the earlier versions of RAA, the version we are examining has some added features.

The Trojan contains an executable file encoded in Base64, which it writes to the hard drive at ‘C:\Users\<username>\Documents\ii.exe’ and launches after it has finished encrypting files.

Analysis revealed that ‘ii.exe’ is none other than Pony, a known password-stealing Trojan (detection verdict: Trojan-PSW.Win32.Tepfer.gen). Pony has proved to be an unusually long-lived Trojan.
Its early versions supposedly emerged back in 2011, while in December 2013, as reported by the mass media, it stole the credentials of over 2 million users. Naturally, after all that time Pony’s source code appeared on the web at some point.

Analysis showed that the executable file we are analyzing here was constructed using Pony source code. Pony: confidential data theft To recap, Pony’s main task is to collect confidential information from an infected computer and then send it to the cybercriminals. Step 1.
Stealing information Below is a short list of the information that Pony hunts for. Passwords stored in web browsers Microsoft Internet Explorer Google Chrome Opera Mozilla Firefox K-Meleon Яндекс.Браузер Flock Credentials to dozens of the most popular FTP clients CuteFTP 6\7\8\9\Pro\Lite FTP Navigator FlashFXP 3\4 FileZilla FTP Commander Bullet Proof FTP Client SmartFTP TurboFTP FFFTP COREFTP FTP Explorer ClassicFTP SoftX.org FTPClient LeapFTP FTP CONTROL FTPVoyager LeechFTP WinFTP FTPGetter ALFTP BlazeFtp Robo-FTP 3.7 NovaFTP FTP Surfer LinasFTP Cyberduck WiseFTP Accounts with the most widespread mail clients Microsoft Outlook Mozilla Thunderbird The Bat! Windows Live Mail Becky! Internet Mail Pocomail IncrediMail Various cryptocurrency wallet files PPCoin Primecoin Feathercoin ProtoShares Quarkcoin Worldcoin Infinitecoin Fastcoin Phoenixcoin Craftcoin The Trojan also has the following capabilities: Pony steals the user’s digital certificates. Pony stores a list of the most widespread combinations that users use as passwords. Using this list, it attempts to gain access to the accounts on an infected computer. Step 2.

Data encryption and sending Before sending the collected information to cybercriminals, Pony encrypts it using the RC4 algorithm. When doing so, the Trojan keeps records of the checksums for the obtained data (slightly modified results of the CRC32 algorithm are used.) The sequence is as follows: Calculate the checksum of the non-encrypted data. Write the obtained value next to the input data. Encrypt input data with the RC4 algorithm using the key that the cybercriminals specified when they compiled the Trojan. Calculate the checksum of the encrypted data. Write the obtained value next to the input data. Generate a random 4-byte key Encrypt the input data with the RC4 algorithm using the generated key. Generate a data package ready for sending that can be described with a ToSend structure (see below) struct ToSend { dword random_key; byte* double_encrypted_data; }; struct ToSend dword random_key; byte* double_encrypted_data; A non-encrypted fragment of the generated report Fragment of the report that is ready for sending.

The encryption key is highlighted in red
When the data is brought up to the required form, Pony sends it to the cybercriminals. MD5 Trojan-Ransom.JS.RaaCrypt.ag:68288a9f7a6bc41c9550a417d1721321 Trojan-PSW.Win32.Tepfer.gen (Pony):1de05ee1437d412cd328a6b3bd45fffc

Windows 10: What’s New in the Security System

Operating system security is one of Microsoft’s priorities.

The developers of the new generation of Windows have vigorously responded to the most significant and relevant threats that target the Windows platform by developing numerous security technologies that were previously available only in third-party solutions.

The system has become better protected, making the life of cybercriminals more difficult. Nevertheless, in some cases, the tools provided by the operating system are not sufficient – the developers have had to make compromises in a number of areas, which has negatively affected system security and makes it necessary to use third-party IT security tools. Because it is so widespread, Windows has been, and remains, the target of choice for cybercriminals of all stripes.

Each new version is researched thoroughly by thousands of blackhats in search of new moneymaking opportunities. Whitehats, for whom Windows is the main battleground in their fight against the bad guys, also explore it. Naturally, Kaspersky Lab always carries out a painstaking analysis of all changes introduced by Microsoft to the security system in order to provide its users with the best possible protection against cyberthreats. This review consists of three parts devoted to the most prominent new Windows 10 features that affect security.

These are the Microsoft Edge browser, virtualization-based security and an updated built-in anti-malware solution called Windows Defender.

All of these features have brought new capabilities to the Windows security system, but, unfortunately, they also come with some weaknesses of their own.
In this paper, we use examples to demonstrate how Windows 10 protection technologies work and how they can be complemented by third-party solutions to improve system security. Microsoft Edge The latest browser, Microsoft Edge, is intended to replace Internet Explorer.
It is included in Windows 10 as the default browser.

The company has worked hard to implement numerous new features, some of which are security-related. Content Security Policy and HTTP Strict Transport Security technologies were introduced to combat cross-site scripting attacks.

These technologies are designed not only to lower the chances of a successful attack but also to notify the web service’s owner about the attempt to carry it out. Microsoft has also come up with ways to protect Edge against exploits, which were the curse of Internet Explorer. Now, by using containers and separating content handling operations into different processes, exploiting vulnerabilities has been made much more difficult.

Finally, integration with SmartScreen should prevent users from visiting sites with malicious content. In addition to supporting new technologies, the security of Edge has been enhanced by retiring vulnerable old ones.

The browser no longer supports VML, BHO and ActiveX, which are used by a multitude of advertising apps and malicious browser add-ons. However, a browser’s security is determined by its ability to combat real attacks.

The majority of malicious programs designed to steal money via Internet banking work successfully with browsers such as Internet Explorer, Chrome, Firefox and Opera.

Typically these are Zeus (Zbot), the infamous Dyreza (Dyre), and the peer-to-peer bot Cridex (Dridex), all of which, despite being old, are nevertheless still used by virus writers. The functionality of a typical banker leads to the implementation of an MiTB (Man-in-The-Browser) attack. Most bankers pull off such an attack by integrating their code in the browser process and intercepting the network-interaction functions. However, these functions are implemented differently in different browsers, forcing virus writers to constantly modify and update their malicious software so that it can work with all possible browsers and versions. In November 2015, it was reported that the Dyreza Trojan had been given functionality that enabled it to attack Microsoft Edge. However, the activity of that particular botnet fell to zero soon afterwards: updates ceased to be released and the command-and-control servers were taken offline. Another infamous banker Trojan, Kronos, caught up with Edge in 2016. We checked out its capabilities on a Windows 10 virtual machine.
In the code of the new Kronos version we found a function that checks the name and checksum of a process, as well as the hashes of the functions hooked by the malware. Function that identifies the browser based on the checksum of its process name Kronos checks the process’s name, converts the string to lower case, calculates its checksum and squares it.

The hash obtained in this way is checked against a table – if it is found there, the Trojan will attempt to hook the functions it needs in the browser’s process. Browser process names known to the Trojan: Process name Checksum iexplore.exe 0x64302d39 chrome.exe 0x05d66cc4 firefox.exe 0x39ace100 opera.exe 0x9420a4a1 microsoftedge.exe 0x9b6d5990 microsoftedgecp.exe 0x949b93d9 In order to perform malicious operations that will make money for its owners, Kronos hooks the functions that create and send HTTP requests in the Wininet library. List of wininet.dll functions hooked: API function Hash HttpOpenRequestA Y7D4D7E3T2T2A4U3 HttpQueryInfoA C8C0U1A2G4G5Y2B5 HttpSendRequestA Y4U1P2F2G7T2A4U3 InternetCloseHandle A7S3H3X3D5Y7T7F7 InternetConnectA H0S6D5Q7E8P3P6U5 InternetCrackUrlA E6F2A3S8Y4C7D5A5 InternetOpenA B7P8P7T4E3U2H5A5 InternetQueryOptionA C1Y0B7E2B0P2P3T7 InternetReadFile D6X2S6E3Q3C5B5X2 InternetSetOptionA X3Y6Q2T7Q5Q2A5X6 Kronos hooks functions using the splicing method, adding a JMP (unconditional jump) instruction at the beginning of the code.
Since the malicious code injected into the browser is loaded as a shellcode rather than a library, the Mitigation Policy enabled in the browser will not block it from being executed. InternetReadFile function hook in MicrosoftEdgeCP.exe Handler for the hooked function Successfully hooking these functions enables the Trojan to inject data into web pages.
It also enables Kronos to get information about the user, the user’s credentials and bank account balance, to redirect the user to phishing sites, or to include additional entry fields to the bank’s legitimate page (enabling the malware to find out the user’s reply to the secret question, credit card number, date of birth or phone number). Web injection on a bank’s page Note that Kronos can only attack Edge on the 32-bit version of Windows 10.

But this is not a fundamental constraint – there are now bankers that work with the 64-bit version of Edge, as well. In the beginning of the year, a new modification of the infamous Gozi banker appeared.

Among other things, it was designed to carry out an MiTB attack against Edge under a 64-bit version of Windows 10.

The Trojan injects its code into the RuntimeBroker.exe process, launches the browser on behalf of that process and injects its code into the browser’s own processes. Part of the function that checks process names for injection As in the case of Kronos, the injected code hooks functions that create and send HTTP requests. However, instead of splicing, it substitutes IAT pointers as well as function addresses in the Export Table. Part of the function that checks process names to set the right hooks for each browser HttpSendRequestW hook set by Gozi banker in the MS Edge browser Note that Windows Defender successfully blocks the current versions of Kronos and Gozi. Nevertheless, new malware and adware will emerge that is capable of using Edge for its own purposes. Virtualization-Based Security In the corporate version of Windows 10, Microsoft has implemented a new approach to security that is based on Microsoft Hyper-V, a hardware-assisted virtualization technology.

The new paradigm, called Virtualization Based Security (VBS), is based on a whitelisting mechanism that only allows applications that are on the trusted-application list to be executed, and on isolating the most important services and data from other components of the operating system. VBS depends on the platform and CPU features, which means that the technology needs the following to operate: Windows 10 Enterprise. UEFI firmware v2.3.1+ with Secure Boot support. CPU supporting Intel VT-x/AMD-V virtualization features. Ability to block some features of the UEFI firmware and its secure updating. TPM (optional). Microsoft uses the Hyper-V hypervisor as its virtualization platform.

The less code a hypervisor contains, the fewer attack vectors against it exist.
In this aspect, the compactness of Hyper-V is very beneficial for security. Unlike previous Windows versions, the hypervisor starts not as a kernel-mode driver but in UEFI, at an early stage of the computer’s startup. Hyper-V initialization procedure In VBS, with the hypervisor active, each virtual CPU is assigned a Virtual Trust Level (VTL) attribute.

Two attributes are currently used: VTL 1 (“Secure World”) and VTL 0 (“Normal World”).
VTL 1 is more privileged than VTL 0. Secure Kernel Mode or SKM (Ring 0, VTL 1) includes a minimal kernel (SK), a Code Integrity (CI) module and an encryption module.
Isolated User Mode or IUM (Ring 3, VTL 1) includes several isolated services called Trustlets that are isolated not only from the external world but also from each other.
In “Normal World” (VTL 0) mode, the traditional kernel, kernel-mode drivers, processes and services work according to the former rules. Diagram describing the two worlds When the hypervisor is active, physical RAM pages and their attributes are only controlled by the secure isolated kernel (SK).
It can manipulate page attributes, blocking or allowing reading, writing or executing code on specific pages.

This makes it possible to prevent execution of untrusted code, malicious modification of trusted application code, as well as to make leaking protected data more difficult. In this architecture, the only component that controls the execution of any code in the system is the secure isolated Code Integrity (CI) module.

The kernel from “Normal World” cannot set the attributes of kernel-mode physical pages. Credential Guard Credential Guard is one of the main functional blocks of VBS.
It isolates secrets in such a way as to ensure that only trusted code has access to them.

This helps to withstand direct memory access (DMA) attacks, as well as pass-the-hash and pass-the-ticket attacks. System Information.

Credential Guard and HVCI
We have tested the technology, attempting to get secret data using direct memory access. We used Mimikatz and Inception hacker tools for this. Nothing worked.

These hacker tools were powerless against Credential Guard. DMA attack using the Inception tool Device Guard The Device Guard technology that is part of VBS is the successor of Microsoft AppLocker.
It controls the launching and execution of all code: executable files and dynamic libraries, kernel-mode drivers and scripts (e.g., PowerShell).

This is based on a code integrity policy created by the system administrator that defines which software is regarded as trusted. The main difficulty in using Device Guard is in creating a proper policy, which can be difficult even for experienced system administrators.
Ideally, the procedure is as follows: Enable the necessary Windows 10 VBS mechanisms on a test computer. Prepare a master image of Windows OS. Install all the necessary software. Create a code integrity policy based on certain rules and leave it in audit mode for some time.

During this time, software can be added or changed. Watch the event log for CI events. Perform any necessary policy adjustments, such as signing any software that is not signed. Consolidate the original policy with the version created while the policy was in audit mode. Disable audit mode in the code integrity policy, replacing it with enforced mode. Distribute the prepared policy to end users. A code integrity policy defines the conditions for executing code both in user mode (User Mode Code Integrity or UMCI) and in kernel mode (Kernel Mode Code Integrity or KMCI).
Secure loading of the Windows kernel itself is provided by the Secure Boot technology.

The integrity policy needs to be maintained and updated based on the software requirements in place at a specific organization. In addition to the integrity policy, there are other restrictions on executing code.

A physical memory page gets the “executable” attribute only if the certificate is validated.

Additionally, a kernel-mode page cannot have “writable” and “executable” attributes at the same time (the W^X restriction), which prevents most exploits and hooks from working in kernel mode.
In the event of an attempt to modify the contents of a kernel mode page that has “readable” and “executable” attributes, this will lead to an exception.
If it is not handled, Windows will stop and display a BSOD. As a result, it is impossible to execute unsigned drivers, applications, dynamic libraries, UEFI modules and some script types when the hypervisor and all the security options, such as Secure Boot, TPM, IOMMU, and SLAT are active.

Depending on settings, code that is signed but not trusted can also be blocked from being executed. To protect the policy from unauthorized changes or substitution, Microsoft suggests that it should be signed using a certificate generated by the administrator.

To remove a policy or change settings, another policy signed with the same certificate is required.
If an attempt is made to remove a policy or ‘plant’ an unsigned policy, the operating system will not start. Still, Device Guard is not perfect.
Increased protection comes at a price – in the form of performance degradation.

This is unavoidable due to the presence of a hypervisor.

The convoluted process of creating, configuring and maintaining a code integrity policy can be considered a weakness of the technology.

The options used by the policy are scattered across the operating system and cannot be managed through a single control panel.

As a result, it is easy to make a mistake, leading to weaker protection. Since Secure Boot plays a key role in this technology, the level of protection very much depends on the quality of UEFI code, which is developed by a third party over which Microsoft has no control.

Finally, the absence of protection against exploits in user mode is disappointing. Testing VBS If malicious code makes its way onto a computer with VBS by taking advantage of a vulnerability, it will have to elevate its privileges to kernel mode to be able to attack the hypervisor, the “Secure World” or UEFI. We tried to do this using a signed and trusted kernel mode driver. Kernel mode penetration testing results: Test Result Test Result W+X PE section .INIT + (by design) Allocate NP/P MEM, hack PTE manually + (BSOD) W^X PE section .INIT + (as is) R+X section, remove WP in CR0 + (BSOD) W+X PE section + (no start) Stack code execution + (BSOD) Allocate MEM, execute + (BSOD) Allocate MEM, hack MDL manually + (BSOD) R PE section, write, execute + (BSOD) None of the attack methods that we tried was successful.

Attacks based on changing Control Registers (CR0-CR8, EFER etc.) and Model-Specific Registers (MSR) did not work either – they all invariably ended in a Privileged Instruction exception (0xC0000096). We also carried out some tests in user mode, trying to circumvent a code integrity policy in enforced mode.

The objective was to execute an unsigned application or load an unsigned dynamic library into a trusted process. We were unable to do this directly, but we found a curious error in the Windows 10 preview release (10154). The error lies in the fact that, although Device Guard checks whether an application, driver or library is signed, it does not verify that the signature is valid for the application signed with it.

This makes it possible to extract a valid signature from any trusted application and insert it into any untrusted application – after this the system will consider the application to be trusted.
So, by inserting a signature from another application, we were able to execute an untrusted application and to load an untrusted dynamic library. We immediately reported the error to Microsoft and it was fixed within a few days. Windows 10 RTM (10240) does not include that error. We also discovered a denial-of-service error that makes it possible to crash the system and cause a BSOD for the hypervisor from the user space with just one Assembler instruction.

A fix for this error was included in Windows 10 TH2 (10586). The hypervisor’s BSOD Overall, Microsoft has done a great job in developing new security mechanisms. However, as in previous versions, there are still opportunities for attacks via the firmware.

Another problem is that the system administrator needs to be highly qualified to configure protection properly.
In the event of faulty configuration or loss of the private certificate, all protection becomes useless.
In addition, there is no protection against user-mode vulnerabilities.
It is also important to keep in mind that VBS is only available to users of the corporate Windows 10 version. We have notified Microsoft of all the vulnerabilities discovered during testing. Built-in Anti-Malware Protection in Windows Let’s have a look at the Windows component that protects the system against malware in real time.
It is enabled by default and, for users who do not install third-party anti-malware solutions, it is the main Windows IT security tool. The principal purpose of built-in protection is to prevent the installation and execution of malware.
It scans files and active processes in real time, identifying those that are malicious by checking them against a regularly updated signature database.
In most cases, this protection is sufficient. However, if you are an active Internet user and often perform critically important operations on your computer – such as managing your bank accounts via online banking – you need multi-tier protection.

Even the best anti-malware solution can miss new, as yet unknown malware.
In this case, only additional layers of protection can save the day by preventing a Trojan from carrying out malicious activity in the system. We did some research and found a few real-life examples demonstrating that built-in protection may not be sufficient. Keystroke Interception Some banker Trojans intercept data entered on the keyboard to steal the user’s online banking account.

Examples of such malware include Qadars, Zbot and Cridex. Many anti-malware solutions, including Kaspersky Internet Security, have a component that detects and blocks attempts by programs to intercept the sequence of keypresses.
In some cases, this can be enough to prevent criminals from making money at the victim’s expense, even if they have managed to infect the computer. We tested the response of built-in protection to keystroke logging with the help of a test application that uses the GetAsyncKeyState WinAPI function (this method is similar to the one used in the latest MRG testing). We were able to intercept the user’s login and password for a PayPal account with Windows Defender enabled. Logging the user credentials while entering a PayPal account Unauthorized Web Camera Access In the next test, we tried to gain unauthorized access to the web camera.

This functionality has been increasingly used in Trojans and other hacker tools in the past years.

The fact that a surveillance module using the web camera is included in the AdWind Trojan is a telling example of the popularity of this functionality among cybercriminals. Monitoring victims using their own web cameras can provide a wealth of information about them, which can later be used to make money illegally – for example, by blackmailing a victim with intimate videos. Some anti-malware solutions can control application access to the camera.
In real life, there are practically no situations in which a legitimate application could need to use the camera without notifying the user, which is why providing such notifications is a convenient and widely accepted practice.

The user can decide in each specific case whether the application really needs to use the camera or whether this is suspicious activity that should be blocked. Our test application used a publicly available library called OpenCV (which is what the Rover Trojan does, to give one example).

A simple Python script captured video from the web camera and displayed it in a separate window.

This means that an application was able to intercept video from the web camera on a Windows 10 machine with protection enabled, without the user being notified of this in any way. Capturing the screen with a script Control of Drive-By Downloads Another problem that is among the most serious issues faced by Windows users is the numerous exploits that can be used to infect the system via vulnerabilities in various applications. We tested the built-in protection with one of the latest exploits for the CVE-2016-1019 vulnerability in Adobe Flash Player. The exploit’s file is an SWF object compressed using the ZLIB algorithm. The flash exploit In this form, the file is recognized by the Windows Defender and quarantined. Successful detection of a packed exploit However, if the file is decompressed into the original SWF, the security system will miss it. Moreover, a compressed file that was detected on the hard drive is downloaded from websites in drive-by attacks and successfully executed from the browser’s context.
If a vulnerable version of Adobe Flash Player is installed in the system, an infection can occur, because Windows Defender does not include a drive-by download control component. Successful download of a Flash exploit that was previously detected on the hard drive In addition, we want to mention that Microsoft Windows has embedded component (SmartScreen) which could successfully stop drive-by attacks using reputation-based analysis, but in some cases, especially in targeted attacks, heuristic content analysis is needed for successful detection of exploitation process. We used this test case, which could not be covered with SmartScreen component to show that if threat actors will use Flash exploit with bypass techniques for Edge security mechanism user could be infected.

Currently we have not registered usage of such bypass techniques yet. Conclusion Today, a multi-tier approach is required to provide reliable protection for user systems, combining standard detection methods (signature-based analysis, behavioral analysis, etc.) with additional modules designed to detect attack techniques commonly used by cybercriminals. As our brief review has demonstrated, in some cases the IT security technologies built into Windows 10 are not sufficient for full-scale protection against malicious attacks.

As in previous Windows versions, all possible attack vectors should be blocked using dedicated Internet Security class security solutions.

RHSA-2016:1225-1: Important: kernel security and bug fix update

An update for kernel is now available for Red Hat Enterprise Linux 6.5 AdvancedUpdate Support.Red Hat Product Security has rated this update as having a security impact ofImportant. A Common Vulnerability Scoring System (CVSS) base score, which givesa detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section. The kernel packages contain the Linux kernel, the core of any Linux operatingsystem.Security Fix(es):* Two flaws were found in the way the Linux kernel's networking implementationhandled UDP packets with incorrect checksum values. A remote attacker couldpotentially use these flaws to trigger an infinite loop in the kernel, resultingin a denial of service on the system, or cause a denial of service inapplications using the edge triggered epoll functionality. (CVE-2015-5364,CVE-2015-5366, Important)Bug Fix(es):* At a process or thread exit, when the Linux kernel undoes any SysV semaphoreoperations done previously (ones done using semop with the SEM_UNDO flag), therewas a possible race condition with another process or thread removing the samesemaphore set where the operations occurred, leading to a possible use ofin-kernel-freed memory and then to possible unpredictable behavior. This bugcould be noticed with software which uses IPC SysV semaphores, such as IBM DB2,which could in certain cases have some of its processes or utilities getincorrectly stalled in an IPC semaphore operation or system call after the racecondition happened. A patch has been provided to fix this bug, and the kernelnow behaves as expected in the aforementioned scenario. (BZ#1326343) For details on how to apply this update, which includes the changes described inthis advisory, refer to:https://access.redhat.com/articles/11258The system must be rebooted for this update to take effect.Red Hat Enterprise Linux Server AUS (v. 6.5) SRPMS: kernel-2.6.32-431.72.1.el6.src.rpm     MD5: f28da237a23f9520e8251d80ae208537SHA-256: 954a57290ea973008a7bc007366f1e8a516190e19099954012a1f7661ed19ad1   x86_64: kernel-2.6.32-431.72.1.el6.x86_64.rpm     MD5: f0054fed510687f9e6aa926af52f0488SHA-256: 9f876aaed9f96415006e6b743ed52beac7e06e4b5c455ba0a7ee6dc204ced54b kernel-abi-whitelists-2.6.32-431.72.1.el6.noarch.rpm     MD5: 6f3a7a6a57405f05b27c44c53f25d551SHA-256: a3cb2e50f6d0423d71426ee58224d6271f4c98b94006fb204ec7b55037eb104e kernel-debug-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 3827e6723733e6bba857a8f9b372e225SHA-256: 98d7201511cca63b4af1488826f1752dde254084d085bc019e5f71432d69af33 kernel-debug-debuginfo-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 94452c7fc65adf66e204f7abf4bcb38bSHA-256: 47f0d642797ac6628c27856afa4c56c762eecaf2898389b3a46c80e265b9427f kernel-debug-devel-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 9a15e4d7895802d740445b1aadd960f3SHA-256: 44d45d59c0495aa0f41aea892e74dfe584d58bac0b9c14e42aed9f13d31599db kernel-debuginfo-2.6.32-431.72.1.el6.x86_64.rpm     MD5: ee373a2ed32951725214a4a9efd662afSHA-256: 1b026f11c2b8ef7b726e58d3d3c0c72ed809731feacc51950aa40be691cccb89 kernel-debuginfo-common-x86_64-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 454d2b368e3835bb70b2d6abebb5be44SHA-256: 4fd14a7928a41ed22cc3f5d47a9364858c928324a30cfed25a4b37ebc5a57774 kernel-devel-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 9ef22d950d04c7e73e085fc0c6e080d8SHA-256: 2ff1afabe1e8103368d607c1edc81a8c3b83ae9b314e6566441227abb2616b66 kernel-doc-2.6.32-431.72.1.el6.noarch.rpm     MD5: 658bab6cc347b34f95a92c726bbc8af7SHA-256: bc92fe0a236fef9a4262c05953c9f585ffc5d5f357b4c72dfd44179608ace560 kernel-firmware-2.6.32-431.72.1.el6.noarch.rpm     MD5: 7652e10d198707c79db54f57adae21c7SHA-256: b22839b905bfd7df036afadeacd41d9569603192091c0a69731de423f9ccc742 kernel-headers-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 0edc3f06cd4ee842e5bec8336b32457aSHA-256: 321093f0cc5c925aecf4e75e89b563303d641cc434fad0a2f9739296061e118b perf-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 9f3f3c1b27d90fccfeee162e1ffb1fa2SHA-256: 15505c8a8c667ff1ea4e7409fab01678915a25a64c2f1a44253c254e289e8cdb perf-debuginfo-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 02ad9f3e0ab77abb2a9e385839a6ff97SHA-256: c4940315196136b2fafce81ef6c811e6ab016b3ce3b68cabb59cc0996616e0ef python-perf-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 62b0af59f8d1ef3e1929662b0205645fSHA-256: f8823cb9a4c1d5d1ef80c7ed273a7a9434749347e5f427fa2705fd48325b801b python-perf-debuginfo-2.6.32-431.72.1.el6.x86_64.rpm     MD5: 5e6840dff2586855b286137ceb9ec3e4SHA-256: f4136fd72b83c265e0d1da9389e95f665dd1b4f9566f9bca5f4e2c062fdeee35   (The unlinked packages above are only available from the Red Hat Network) 1239029 - CVE-2015-5366 CVE-2015-5364 kernel: net: incorrect processing of checksums in UDP implementation These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from: