BLOG

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/

Wed, 12 Jun 2019 20:09:00 +0000

---

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
Wed, 12 Jun 2019 20:07:00 +0000

---

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:



Wed, 12 Jun 2019 20:04:00 +0000

---

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

• 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

Thu, 06 Jun 2019 12:53:00 +0000

---

Docker Vulnerability

    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
Sat, 01 Jun 2019 00:20:00 +0000

---

Intel VISA: Through the Rabbit Hole Undocumented Concern ??

    The end of last month at Black Hat Asia 2019, Mark Ermolov and Maxim Goryachy from Positive Technologies gave a presentation titled “Intel VISA: Through the Rabbit Hole”. Slashdot characterized the presentation as researchers had discovered and abused new and undocumented features in intel chipsets.

    The capability is named Intel Visualization of Internal Signals Architecture (Intel VISA) and it is a utility included in modern Intel chipsets to help with testing/debugging during manufacturing. It is included with Platform Controller Hub (PCH) chipsets, is a part of modern Intel CPUs, and functions much like a logic signal analyzer. It is able to collect signals sent from internal buses and peripherals to the PCH and CPU. Effectively this means unauthorized access to the VISA would expose ANY data to examination by an unscrupulous person to intercept and collect data from the computer memory and function at the lowest possible level.

    The real question is: Is there a real threat? The researchers said they have several methods of enabling Intel VISA and capturing data, including the secretive Intel Management Engine (ME) which has been housed in the PCH since the release of the Nehalem processors and 5-Series chipsets.  But there are caveats. On the positive side, Intel has not publicly disclosed the feature and is only shared with others under a non-disclosure agreement. Additionally, the feature is disabled by default, so attackers must first figure out how to enable it before exploiting it. On the negative side, the researchers found a way to disable Intel VISA using an older Intel ME vulnerability. Intel released a firmware patch that fixes that particular vulnerability in 2017 (INTEL-SA-00086), but unless there was an explicit update to the firmware (it’s not correctable via OS update) the CPU remains affected.

      It’s worth noting that if the attacker has exploited the Intel ME vulnerability, they are well into your system and there is little additional capability offered via VISA that they don’t already have. But back on the negative side, if an attacker finds an alternate to enable VISA, that could indeed become a new attack vector.

     The researchers indicated that they know three alternate ways to enable VISA, which they revealed in the presentation slides (link below). The bigger question remains: what other secret or undocumented modes/ features lie in Intel's CPUs? Intel may try to keep them secret from the public, but security through obscurity is no paradigm to follow.
   As the researchers proved, people will uncover those secret features, and some will abuse them.

Sources:

• https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Goryachy-Ermolov-Intel-Visa-Through-the-Rabbit-Hole.pdf

• https://www.zdnet.com/article/researchers-discover-and-abuse-new-undocumented-feature-in-intel-chipsets/
Thu, 30 May 2019 13:44:00 +0000

---

Steganography techniques that deliver malware

    Researchers at Blackberry’s Cylance Labs have discovered novel techniques utilizing steganography, the practice of concealing a file, message, image, or video within another file, message, image, or video, to load malware payloads onto victims’ machines. 

    The Advanced Persistent Threat (APT) group “OceanLotus”, primarily believed to be Vietnam-based, is using steganography techniques to deliver malware backdoors on compromised systems. The malware loader utilizes steganography techniques to read an encrypted payload contained within an image file to decrypt and execute the malicious payload which loads one of two backdoors onto the machine. The backdoors are associated with OceanLotus’ parent cyber espionage group, APT32, and were first discovered back in 2017, namely the Denes backdoor and the Remy backdoor. 

    Researchers at Cylance labs pointed out that it would not be difficult to swap out the backdoors for some other malicious payload and that what is essential is the tactic of using steganography to hide the payload and that it would still be just as effective. The threat actor would encode the image with their payload of choice before distributing it with a simple decoder to the target.   The obfuscation of the malware payload loading portion of the technique is what’s impressive from a security detection point of analysis.

    The group has seemingly avoided discovery using common steganography detection techniques. To accomplish this, they utilize the “bespoke” tool to encode data into the images using a least significant bit approach to both minimize visual differences between the encoded image with it’s original and to avoid detection/ analysis by discovery tools.

    “The user does not interact with the image (nor is the image sent via email), rather the image is used to hide the payload from analysts/tools/monitoring software. In a way, the payload is hiding in plain sight, as an image carrying a payload will be virtually indistinguishable from an original image”, said Tom Bonner, BlackBerry Cylance director of threat research.  

    The payload, once executed and loaded onto the machine, then downloads Dynamic Link Libraries (DLL) and Command and Control communications libraries that are heavily obfuscated with large quantities of useless junk code, said researchers from Cylance. The junk code significantly inflates the library’s size which makes both static analysis and debugging more difficult.

Source:
• https://cyware.com/news/oceanlotus-threat-actor-group-leveragessteganography-to-deliver-backdoors-781be11c 
Thu, 30 May 2019 13:36:00 +0000

---

NIST Mobile Application Single Sign-On: 2nd Draft of SP 1800-13 Available for Comment

The National Cybersecurity Center of Excellence (NCCoE) at NIST is seeking comments on a revised draftof the practice guide NIST SP 1800-13, Mobile Application Single Sign-On. The guide aims to help public safety first responder personnel efficiently and securely gain access to their mission-critical data via mobile devices and applications. 

The goal of this project is to illustrate a method for public safety organizations to deploy efficient and interoperable multifactor authentication and single sign-on tools to protect access to sensitive information while meeting the demands of an operational environment that relies on rapid response. This revision of the original NIST SP 1800-13 was updated at the request of the public safety community to incorporate iOS version 12. Organizations are encouraged to review the draft and provide feedback for possible incorporation into the practice guide.

This project will result in a publicly available NIST Cybersecurity Practice Guide (NIST SP 1800 series) --a detailed implementation guide of the practical steps needed to implement a cybersecurity reference design that addresses a particular challenge. 

The public comment period ends on June 28, 2019. See the publication details for links to the document files and instructions for submitting comments.

Publication details:
https://csrc.nist.gov/publications/detail/sp/1800-13/draft

Project homepage:
https://www.nccoe.nist.gov/projects/use-cases/mobile-sso

 

Thu, 30 May 2019 13:32:00 +0000

---

What new in Windows 10 build 1903

Sat, 25 May 2019 18:11:00 +0000

---

Microsoft Releases a critical Remote Code Execution vulnerability for Windows 7, Windows Server 2008 R2, and Windows Server 2008

Microsoft released fixes for a critical Remote Code Execution vulnerability, CVE-2019-0708, in Remote Desktop Services – formerly known as Terminal Services – that affects some older versions of Windows. The Remote Desktop Protocol (RDP) itself is not vulnerable. This vulnerability is pre-authentication and requires no user interaction. In other words, the vulnerability is ‘wormable’, meaning that any future malware that exploits this vulnerability could propagate from vulnerable computer to vulnerable computer in a similar way as the WannaCry malware spread across the globe in 2017. While we have observed no exploitation of this vulnerability, it is highly likely that malicious actors will write an exploit for this vulnerability and incorporate it into their malware. 

Now that I have your attention, it is important that affected systems are patched as quickly as possible to prevent such a scenario from happening. In response, we are taking the unusual step of providing a security update for all customers to protect Windows platforms, including some out-of-support versions of Windows. 

Vulnerable in-support systems include Windows 7, Windows Server 2008 R2, and Windows Server 2008. Downloads for in-support versions of Windows can be found in the Microsoft Security Update Guide. Customers who use an in-support version of Windows and have automatic updates enabled are automatically protected.  

Out-of-support systems include Windows 2003 and Windows XP. If you are on an out-of-support version, the best way to address this vulnerability is to upgrade to the latest version of Windows. Even so, we are making fixes available for these out-of-support versions of Windows in KB4500705. 

Customers running Windows 8 and Windows 10 are not affected by this vulnerability, and it is no coincidence that later versions of Windows are unaffected. Microsoft invests heavily in strengthening the security of its products, often through major architectural improvements that are not possible to backport to earlier versions of Windows.  

There is partial mitigation on affected systems that have Network Level Authentication (NLA) enabled. The affected systems are mitigated against ‘wormable’ malware or advanced malware threats that could exploit the vulnerability, as NLA requires authentication before the vulnerability can be triggered. However, affected systems are still vulnerable to Remote Code Execution (RCE) exploitation if the attacker has valid credentials that can be used to successfully authenticate. 

It is for these reasons that we strongly advise that all affected systems – irrespective of whether NLA is enabled or not – should be updated as soon as possible.  

Resources
Links to downloads for Windows 7, Windows 2008 R2, and Windows 2008
Links to downloads for Windows 2003 and Windows XP  

Source Microsoft TechNet
Tue, 14 May 2019 19:36:00 +0000

---