Month: June 2019

    When something is free, chances are pretty high that “the user” is the product. Services that are free usually generate value for the creator or provider by sharing exposure with advertisers or perhaps using the data collected from the “free” product for other means such as market studies or product testing before a final product. But sometimes free is the juicy apple with a parasite waiting to land its hook inside the consumer’s gut.

    Researchers from ESET and Malwarebytes labs have found cryptominers within high end music production software products provided for free to download and use. Named LoudMinerby ESET and simultaneously named Bird Miner by MalwareBytes Labs, the cryptominer hides by bundling itself inside already large files. The pirated versions of Virtual Studio Technology programs seem to function normally except that they are slower due to increased processor load. This obfuscation not only hides the existence of the additional malicious installation software, but also focuses their targets on users with high processing power: users who need to process visual and audio media. These two operate themselves within a lightweight virtual machine(VM) in the background. This keeps it hidden from the user, but also generalizes itself for both Mac, Windows, and Linux users, lowering the skill threshold of the developer.

    The cryptominer hides itself once installed by watching the usage of the Activity Monitor, pausing its functions when it might be watched and can consume of up to 90% of the CPU. While the user might notice difficulties, troubleshooting it will be more troublesome than just looking at what’s running. It can even detect what kind of CPU is used and how many cores are available, running up to two VMs simultaneously to more efficiently siphon off processing power. The Mac version runs QEMU, and the Windows version runs VirtualBox, and while the installation of the emulators require a trust verification, they name themselves “Oracle Corporation Network Service” to disguise their clandestine nature while setting the folders to which they are installed to hidden. The VM runs a version of Linux called Tiny Core Linux 9.0 and is set to mine Monero using XMRig, mining to a Mining pool. Profits are shared with other Monero users in the mining pool, but they are also untraceable to the attacker.

    It is always inadvisable to use pirated software, but if one ends up using software from less than reputable sources, be wary of unexpected CPU consumption, trust requests, services, or launch Daemons. While it can be nice to provide some value to a service that is otherwise free, it’s definitely better when you’re an aware and willing participant.

Sources

• https://www.welivesecurity.com/2019/06/20/loudminer-mining-cracked-vst-software/
• https://blog.malwarebytes.com/mac/2019/06/new-mac-cryptominer-malwarebytes-detects-as-bird-miner-runs-by-emulating-linux/

Summary

NIST is seeking comments on Draft
NIST Special Publication (SP) 800-171 Revision 2, Protecting Controlled
Unclassified Information in Nonfederal Systems and Organizations, and Draft
NIST SP 800-171B, Protecting Controlled Unclassified Information in
Nonfederal Systems and Organizations: Enhanced Security Requirements for
Critical Programs and High Value Assets.

The public comment period for both publications ends on July 19,
2019. Comments can also be submitted on a Department of Defense (DoD) cost
estimate for implementing the enhanced security requirements of SP 800-171B.
See the publication details links below for document files and instructions on
submitting comments.

Details

Draft NIST SP 800-171 Rev. 2 provides minor editorial changes in Chapters
One and Two, and in the Glossary, Acronyms, and References appendices. There
are no changes to the basic and derived security requirements in Chapter Three.
For ease of use, the Discussion sections, previously located in Appendix F (SP
800-171 Rev. 1), have been relocated to Chapter Three to coincide with the
basic and derived security requirements.

Publication details for SP
800-171 Rev. 2:
https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/draft

////////

Draft NIST SP 800-171B, Protecting
Controlled Unclassified Information in Nonfederal Systems and Organizations:
Enhanced Security Requirements for Critical Programs and High Value Assets, was developed in the spring of 2019 as a
supplement to NIST SP 800-171. This new document offers additional
recommendations for protecting Controlled Unclassified Information (CUI) in
nonfederal systems and organizations where that information runs a higher than
usual risk of exposure. When CUI is part of a critical program or a high value
asset (HVA), it can become a significant target for high-end, sophisticated
adversaries (i.e., the advanced persistent threat (APT)). In recent years,
these critical programs and HVAs have been subjected to an ongoing barrage of serious
cyberattacks, prompting the Department of Defense to request additional
guidance from NIST.

The enhanced security
requirements are to be implemented in addition to the basic and derived
requirements in NIST SP 800-171, since the basic and derived requirements are
not designed to address the APT.  The enhanced security requirements apply
only to components of nonfederal systems that process, store, or transmit CUI
or that provide protection for such components when the designated CUI is
contained in a critical program or HVA. The enhanced security requirements
are only applicable for a nonfederal system or organization when mandated
by a federal agency in a contract, grant, or other agreement.

All public comments received on
Draft NIST SP 800-171B will be posted at both https://csrc.nist.gov/projects/protecting-cui/public-comments and https://www.regulations.gov/docket?D=NIST-2019-0002
(Regulations.gov docket no. NIST-2019-0002) without change or redaction,
so commenters should not include information they do not wish to be posted
(e.g., personal or business information). 

The DoD has completed a cost
analysis to provide stakeholders insight into the estimated cost of
implementing the enhanced security requirements in Draft NIST SP 800-171B. The
cost analysis is available for review and comment at the publication details
link below. Please submit any comments regarding the DoD cost analysis
review by July 19, 2019 to www.regulations.gov/docket?D=DOD-2019-OS-0072
(Regulations.gov docket no. DOD-2019-OS-0072).

Publication details for Draft SP
800-171B (including the document, DoD Cost Estimate, and recommended comment
template):
https://csrc.nist.gov/publications/detail/sp/800-171b/draft

 

NOTE: A call for patent claims
is included in both draft publications. For additional information, see
the “Information
Technology Laboratory (ITL) Patent Policy–Inclusion of Patents in ITL
Publications”:
https://www.nist.gov/itl/information-technology-laboratory-itl-patent-policy-inclusion-patents-itl-publications.

Please send any questions to sec-cert@nist.gov.

 

The Cybersecurity and Infrastructure Security Agency (CISA) is aware of an
email phishing scam that tricks users into clicking on malicious attachments
that look like legitimate Department of Homeland Security (DHS) notifications.
The email campaign uses a spoofed email address to appear like a National Cyber
Awareness System (NCAS) alert and lure targeted recipients into downloading
malware through a malicious attachment.

CISA encourages users and administrators take the following actions to avoid
becoming a victim of social
engineering and phishing attacks:

• Be wary of unsolicited emails, even if the sender
  appears to be known; attempt to verify web addresses independently (e.g.,
  contact your organization’s helpdesk or search the internet for the main
  website of the organization or topic mentioned in the email).
• Use
  caution with email links and attachments without authenticating the
  sender. CISA will never send NCAS notifications that contain email
  attachments.
• Immediately report any suspicious emails to your
  information technology helpdesk, security office, or email provider.

    Phishing attacks are perhaps the most common method attackers use to gain access to a target network. It is so common that many companies employ outside companies to generate test phishing campaigns in order to train employees on what to look out for. Even with these types of trainings many employees continue to type their credentials into pages designed specifically to steal them.  Implementing 2 factor authentication mitigates a lot of risk because login credentials became useless to an attacker without the time based one time use code 2 factor authentication provides. 

    In order to defeat 2 factor authentication attackers shifted their methods from collecting credentials to collecting session tokens. This makes the attack more complicated because instead of just setting up a fake login page that saves credentials and forwards the user like nothing happened they have to proxy the traffic in real-time in order to make the user type in their one time code. One time codes aren’t able to be used again however, making storing the captured information for later useless. Instead the attacker must capture the session token given out by the server on a successful login and use it in their own browser to gain access to the target system. While this attack was always possible a recently released toolkit makes it much easier.
    Last month at the Hack in a Box conference in Amsterdam researchers presented a toolkit that automates phishing when 2 factor authentication is involved. The toolkit is comprised of 2 parts that work together to automate the attack. The first is Muraena, a minimal configuration proxy designed to middleman the user and the target login page. It supports automatic resource rewriting so that the attacker doesn’t need to spend much time customizing each specific phish page. More advanced configuration options are available too, for sites which employ advanced anti-phishing defenses. The second part of the toolkit is NecroBrowser, an API controlled headless Chrome browser instance that is designed to utilize the session token stolen by Muraena. It is designed to be setup in an automated fashion so that it can immediately perform tasks on behalf of the attacker during a successful attack.  
    Currently there are very few solutions to successfully mitigate a well run attack with this toolkit . Utilizing Universal 2nd Factor authentication instead of traditional 2 factor services is the most successful way to prevent this attack as it completely prevents it from working. It is also important to continue training employees about the ever evolving attack landscape so that they can successfully identify and avoid these attacks.

Sources:

• https://www.csoonline.com/article/3399858/phishing-attacks-that-bypass2-factor-authentication-are-now-easier-to-execute.html

• http://fortune.com/2019/06/04/phishing-scam-hack-two-factorauthentication-2fa/

    Over the years, app security has improved enough that developers must request permissions to areas of your smartphone that their applications need to access. Now we have some control over which apps have access to things such as your camera or extended storage. But did you know that there are still parts of your phone that require no permissions whatsoever? The average smartphone can have over a dozen sensors in it from accelerometers and gyroscopes to proximity sensors and GPS. When these sensors are calibrated at the factory, each one comes off the line with tiny imperfections. This results in each phone having its own unique fingerprint baked right into the firmware and accessible from any application or website.

    SensorID, the calibration fingerprinting attack, uses the calibration data from iOS magnetometers and gyroscopes and Android accelerometers, magnetometers, and gyroscopes to create a unique profile of a phone. Because this type of a fingerprint doesn’t change, a user could potentially be tracked across any application and on any website without ever knowing about it. The calibration data can be pulled from a device nearly instantly and requires little more than an app download or some JavaScript. 

    Apple devices are disproportionately impacted by SensorID due to the more rigorous calibration processes they go through at the factory, but the good news is that Apple addressed the issue in their March release of iOS 12.2. Junk data is now added to the calibration data to eliminate the fingerprint.
On the other hand, Google has yet to address the vulnerability, leaving some Android devices still open to this attack. It’s mainly the higher-end Androids that are vulnerable as the less expensive devices often skip the sensor calibration step to save on cost, thus there exists no calibration data on the device to exploit. Google researchers are supposedly looking into the issue. 

    Even if your device is open to a calibration fingerprinting attack, there are still plenty of simpler attacks that cyber criminals (or advertisers) are more likely to leverage before one like SensorID.

    While that’s not exactly comforting, hopefully SensorID has been cut off at the pass before it could become a bigger problem. 
Sources

• https://nakedsecurity.sophos.com/2019/06/03/your-phones-sensors-could-be-used-as-a-cookie-you-cant-delete/

• https://www.zdnet.com/article/android-and-ios-devices-impacted-by-newsensor-calibration-attack/

• https://www.ieee-security.org/TC/SP2019/papers/405.pdf

NIST has
released a Draft NIST
Cybersecurity White Paper for public comment, Mitigating the Risk of Software
Vulnerabilities by Adopting a Secure Software Development Framework (SSDF).
This white paper recommends a core set of high-level secure software development
practices, called a secure software development framework (SSDF), to be added
to each software development life cycle (SDLC) implementation.

The paper facilitates
communications about secure software development practices amongst business
owners, software developers, and cybersecurity professionals within an
organization. Following these practices should help software producers reduce
the number of vulnerabilities in released software, mitigate the potential
impact of the exploitation of undetected or unaddressed vulnerabilities, and
address the root causes of vulnerabilities to prevent future recurrences.
Software consumers can reuse and adapt the practices in their software
acquisition processes.

The public comment period ends August 5, 2019. See the publication details link for a copy of
the document and instructions for submitting comments.

Publication details:

Download the content from
the Microsoft Security Compliance Toolkit
(click Download and select Windows 10 Version 1903 and Windows Server Version
1903 Security Baseline.zip).

• Enabling the new “Enable svchost.exe mitigation
  options” policy, which enforces stricter security on Windows services
  hosted in svchost.exe, including that all binaries loaded by svchost.exe
  must be signed by Microsoft, and that dynamically-generated code is
  disallowed. Please pay special attention to this one as it might
  cause compatibility problems with third-party code that tries to use the
  svchost.exe hosting process, including third-party smart-card plugins.
• Configuring the new App Privacy setting, “Let
  Windows apps activate with voice while the system is locked,” so that
  users cannot interact with applications using speech while the system is locked.
• Disabling multicast name resolution (LLMNR) to
  mitigate server spoofing threats.
• Restricting the NetBT NodeType to P-node,
  disallowing the use of broadcast to register or resolve names, also to
  mitigate server spoofing threats. We have added a setting to the custom
  “MS Security Guide” ADMX to enable managing this configuration setting
  through Group Policy.
• Correcting an oversight in the Domain
  Controller baseline by adding recommended auditing settings for Kerberos
  authentication service.
• Dropping the password-expiration policies that
  require periodic password changes. This change is discussed in further
  detail below.
• Dropping the specific BitLocker drive
  encryption method and cipher strength settings. The baseline has been
  requiring the strongest available BitLocker encryption. We are removing
  that item for a few reasons. The default is 128-bit encryption, and our
  crypto experts tell us that there is no known danger of its being broken
  in the foreseeable future. On some hardware there can be noticeable
  performance degradation going from 128- to 256-bit. And finally, many
  devices such as those in the Microsoft Surface line turn on BitLocker by
  default and use the default algorithms. Converting those to use 256-bit
  requires first decrypting the volumes and then re-encrypting, which
  creates temporary security exposure as well as user impact.
• Dropping the File Explorer “Turn off Data
  Execution Prevention for Explorer” and “Turn off heap termination on
  corruption” settings, as it turns out they merely enforce default
  behavior, as Raymond Chen describes here.

• Dropping the enforcement of the default
  behavior of disabling the built-in Administrator and Guest accounts. We
  had floated this proposal at the time of the draft baseline, and have
  since decided to accept it. The change is discussed in more detail below.
• Dropped a Windows Defender Antivirus setting
  that applies only to legacy email file formats.
• Changed the Windows Defender Exploit Protection
  XML configuration to allow Groove.exe (OneDrive for Business) to launch
  child processes, particularly MsoSync.exe which is necessary for file
  synchronization.

GO Here for the full article

    Docker is a well known application that uses operating-system-level virtualization to develop and deliver software in packages called containers. Senior software engineer Aleksa Sarai discovered a flaw that affects all versions of Docker, that could allow an attacker to gain read and write access to any file on the host system. Recently, a proof-of-concept code has been released demonstrating how an attacker could use this vulnerability.

     The vulnerability stems from FollowSymlinkInScope function, allowing a basic time-of-check to time-of-use (TOCTOU) attack that gives read and write access to any file on the host system. The purpose of the FollowSymlinkInScope is to “resolve a specified path in a secure manner by treating the processes as if they were inside the Docker container.” The resolved path is not operated on immediately, meaning that an attack could potentially speculate on the gap and then add a symbolic link path that could resolve on the host with root privileges. The docker cp utility is what allows copying content from Docker containers to the host file system.

    There are a few different approaches being proposed when it comes to addressing this vulnerability. Sarai proposed making changes to “chrootarchive.” This would allow archive operations to take place in a secure environment where the root is the container “rootfs.” However, this would involve changing a core piece of Docker, which is not feasible. According to Sarai, “Unfortunately, changes to this core piece of Docker are almost impossible (the TarUntar interface has many copies and re-implementations that would all need to be modified to be able to handle a new ‘root’ argument). Therefore, another approach that has been proposed is to pause the container when using the file system. This would not actually prevent all of the possible attacks. However, it would protect against some of the more basic attacks. A patch to do just this has been submitted upstream and is currently under review.

    Sarai provided two different scripts to show off the exploit, one for read and one for write. Sarai explained the scripts are “…a fairly dumb reproducer which basically does a RENAME_EXCHANGE of a symlink to “/” and an empty directory in a loop, hoping to hit the race condition. Then our “user” attempts to copy a file from the path repeatedly,” explained the expert. “You can call it like this (note that since this requires exploiting a race condition, only a small percentage of the attempts succeed — however if I had made my reproducer a bit more clever about how quickly it does the RENAME_EXCHANGE it could be more likely to hit the race).” Sarai explained that the success rate with this exploit is about .06%, which seems low, but realistically, it would only take about 12 seconds for this exploit to reach success. 
Sources: • https://securityaffairs.co/wordpress/86272/hacking/docker-race-condition-flaw.html 
• https://nvd.nist.gov/vuln/detail/CVE-2018–
• https://github.com/moby/moby/pull/39252