Wednesday, June 12, 2019

Researchers presented a toolkit that automates phishing when 2 factor authentication

    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/

SensorID, the calibration fingerprinting attack

    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

Draft NIST Cybersecurity Whitepaper on Adopting a Secure Software Development Framework (SSDF)


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:


 

Thursday, June 6, 2019

Microsoft releases new Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903

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).

Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes.

This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. This baseline recommends configuring only two of those. However, we have made several changes to existing settings, including some changes since the draft version of this baseline that we published last month.

The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:


  • 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.

Additional changes that we have adopted since publishing the draft version of this baseline include:


  • 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