IDenticard PremiSys vulnerabilities

ICS-CERT
Industrial Control Systems Cyber Emergency Response
Team Advisory: 

 

01/31/2019 10:00 AM EST
 
This
advisory provides mitigation recommendations for use of hard-coded
credentials,
use of hard-coded password, and inadequate encryption strength
vulnerabilities
reported in the IDenticard PremiSys access control system. 
 
   
 
 




 

    

Cybersecurity Awareness Briefings

DHS Header

 

 
 

Cybersecurity Awareness Briefings Start Next Wednesday

Webinar:
Chinese Cyber Activity Targeting Managed Service Providers

On December
20, 2018, the Cybersecurity and Infrastructure Security Agency (CISA)

 announced that malicious actors
working on behalf of the Chinese government have

been carrying out a campaign
of cyber attacks targeting managed service providers (MSPs).

Victims of these
attacks have suffered from the loss of sensitive or proprietary information,

 as well as service disruptions, financial loss, and reputational harm.
Organizations of all

sizes, from all sectors, are still at risk for similar
attacks in the future. Previously posted

information on this threat can
be found here: http://www.us-cert.gov/China.

Join CISA
for a virtual Awareness Briefing to review the background of this threat, as
 

well as recommended steps MSPs and their customers can take to protect
themselves

from future attacks.

Register
now
for one of two upcoming Awareness Briefings.

 Content is the same
for each session.

  • Wednesday, February 6 at 1:00 p.m. ET
  • Friday, February 22 at 1:00 p.m. ET

Registration
is limited, so please register early
to guarantee your spot.

This is
the latest installment in CISA’s ongoing Awareness Briefing series.

  Recordings of previous Awareness Briefings are available at
https://www.us-cert.gov/ccubedvp/events.


 
 

Chinese APT10 intrusion activities target Government, Cloud-Computing Managed Service Providers and Customer networks worldwide

The following information is being provided by the FBI, with no guarantees or warranties, for potential use at the sole discretion of recipients in order to protect against cyber threats. This data is provided in order to help cyber security professionals and system administrators to guard against the persistent malicious actions of cyber criminals.  

This FLASH has been released TLP:WHITE. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction.

Chinese APT10 intrusion activities target Government, Cloud-Computing Managed Service Providers and Customer networks worldwide. The following information was obtained through FBI investigations and is provided in accordance with the FBI’s mission and policies to prevent and protect against federal crimes and threats to the national security.

The FBI is providing the following information with HIGH confidence:

SUMMARY: 

The FBI obtained information regarding a group of Chinese APT cyber actors stealing high value information from commercial and governmental victims in the U.S. and abroad.  This Chinese APT group is known within private sector reporting as APT10, Cloud Hopper, menuPass, Stone Panda, Red Apollo, CVNX and POTASSIUM.  This group heavily targets managed service providers (MSP) who provide cloud computing services; commercial and governmental clients of MSPs; as well as defense contractors and governmental entities.  APT10 uses various techniques for initial compromise including spearphishing and malware.  After initial compromise, this group seeks MSP administrative credentials to pivot between MSP cloud networks and customer systems to steal data and maintain persistence.  This group has also used spearphishing to deliver malicious payloads and compromise victims.  

WE NEED YOUR HELP! If you find any of these indicators on your networks, or have related information, please contact  FBI CYWATCH immediately. Email:  cywatch@fbi.gov Phone: 1-855-292-3937

Deploying the Azure Information Protection scanner to automatically classify and protect files

If you heard me talk I say many time we need to start classify our data so the we can protect the critical files and add additional security to those files that are at the highest risk.
We need to protect data based on the risk.  You may have heard me talk About RMS (Right Management Service) or AIP (Azure information Protection). Here is an article on an tool that will help you find and automatically classify file for you.

This article is for the current general availability version of the Azure Information Protection scanner.

If you are looking for deployment instructions for the current
preview of the scanner, which includes configuration from the Azure
portal, see Deploying the preview version of the Azure Information Protection scanner to automatically classify and protect files.

Use this information to learn about the Azure Information
Protection scanner, and then how to successfully install, configure, and
run it.

This scanner runs as a service on Windows Server and lets you
discover, classify, and protect files on the following data stores:

  • Local folders on the Windows Server computer that runs the scanner.
  • UNC paths for network shares that use the Server Message Block (SMB) protocol.
  • Sites and libraries for SharePoint Server 2016 and SharePoint
    Server 2013. SharePoint 2010 is also supported for customers who have extended support for this version of SharePoint.

To scan and label files on cloud repositories, use Cloud App Security.

Overview of the Azure Information Protection scanner

When you have configured your Azure Information Protection policy
for labels that apply automatic classification, files that this scanner
discovers can then be labeled. Labels apply classification, and
optionally, apply protection or remove protection:

The scanner can inspect any files that Windows can index, by
using IFilters that are installed on the computer. Then, to determine
if the files need labeling, the scanner uses the Office 365 built-in
data loss prevention (DLP) sensitivity information types and pattern
detection, or Office 365 regex patterns. Because the scanner uses the
Azure Information Protection client, it can classify and protect the
same file types.

You can run the scanner in discovery mode only, where you use the
reports to check what would happen if the files were labeled. Or, you
can run the scanner to automatically apply the labels. You can also run
the scanner to discover files that contain sensitive information types,
without configuring labels for conditions that apply automatic
classification.

Note that the scanner does not discover and label in real time. It
systematically crawls through files on data stores that you specify, and
you can configure this cycle to run once, or repeatedly.

You can specify which file types to scan, or exclude from scanning.
To restrict which files the scanner inspects, define a file types list
by using Set-AIPScannerScannedFileTypes.

To learn more go Here

CERT/CC Reports Microsoft Exchange 2013 and Newer are Vulnerable to NTLM Relay Attacks

Original
release date: January 28, 2019

The CERT Coordination Center (CERT/CC) has released information to address
NTLM relay attacks affecting Microsoft Exchange 2013 and newer versions. A
remote attacker could exploit this vulnerability to take control of an affected
system.

Overview
      

Microsoft Exchange 2013 and newer fail to set signing and
sealing flags on NTLM authentication traffic, which can allow a remote
attacker to gain the privileges of the Exchange server.

Description

      

Microsoft Exchange supports a API called Exchange Web Services (EWS). One of the EWS API functions is called PushSubscription,
which can be used to cause the Exchange server to connect to an
arbitrary website. Connections made using the PushSubscription feature
will attempt to negotiate with the arbitrary web server using NTLM
authentication. Starting with Microsoft Exchange 2013, the NTLM
authentication over HTTP fails to set the NTLM Sign and Seal flags. The lack of signing makes this authentication attempt vulnerable to NTLM relay attacks.
Microsoft
Exchange is by default configured with extensive privileges with
respect to the Domain object in Active Directory. Because the Exchange
Windows Permissions group has WriteDacl access to the Domain object,
this means that the Exchange server privileges obtained using this
vulnerability can be used to gain Domain Admin privileges for the domain
that contains the vulnerable Exchange server.

Impact

An
attacker that has credentials for an Exchange mailbox and also has the
ability to communicate with both a Microsoft Exchange server and a
Windows domain controller may be able to gain domain administrator
privileges. It is also reported that an attacker without knowledge of an
Exchange user’s password may be able to perform the same attack by
using an SMB to HTTP relay attack as long as they are in the same
network segment as the Exchange server.

Solution

The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workarounds:

Disable EWS push/pull subscriptions

If
you have an exchange server that does not leverage EWS push/pull
subscriptions, you can block the PushSubscription API call that triggers
this attack. In an Exchange Management Shell window, execute the
following commands:

    New-ThrottlingPolicy -Name NoEWSSubscription -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0
    Restart-WebAppPool -Name MSExchangeServicesAppPool

Remove privileges that Exchange has on the domain object

Please
note that the following workaround was not developed by CERT and is not
supported by Microsoft. Please test any workarounds in your environment
to ensure that they work properly.

https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1
is a PowerShell script that can be executed on either the Exchange
Server or Domain Controller system. By default this script will check
for vulnerable access control entries in the current active directory.
When executed with Domain Admin privileges and the -Fix flag, this script will remove the ability for Exchange to write to the domain object.

Note
that if you encounter an error about Get-ADDomainController not being
recognized, you will need to install and import the ActiveDirectory
PowerShell module, and then finally run Fix-DomainObjectDACL.ps1 :

    Import-Module ServerManager
    Add-WindowsFeature RSAT-AD-PowerShell
    Import-Module ActiveDirectory
    .Fix-DomainObjectDACL.ps1

If the script reports that faulty ACE were found, run:

    .Fix-DomainObjectDACL.ps1 -Fix

PowerShell may be configured to block the execution of user-provided .ps1 files. If this is the case, first find your current PowerShell execution policy:

    Get-ExecutionPolicy

Temporarily allow the execution of the Fix-DomainObjectDACL.ps1 script by running:

    Set-ExecutionPolicy unrestricted

Once you are finished running the Fix-DomainObjectDACL.ps1script, set the policy back to the original value as reported by Get-ExecutionPolicy:

    Set-ExecutionPolicy [POLICY]
    The National Cybersecurity and Communications Integration Center (NCCIC), part of the Cybersecurity and Infrastructure Security Agency (CISA), encourages users and administrators to review CERT/CC’s Vulnerability Note VU#465632 and consider the listed workarounds until patches are made available.

Important Alert DNS Flag Day February 1, 2019 – Ensure Your Institution is Prepared

    On Friday, February 1, major DNS (Domain Name System) software and public DNS providers will remove support for workarounds accommodating authoritative DNS servers that don’t follow published operational standards1. Most EDU sites will not be affected; however, institutions using authoritative servers that don’t meet standards may find their IT-based resources unreachable by large portions of the Internet.

    How to Determine if You’re Affected  • Make a list of all the domains your institution owns. • Test the domains using tools at DNS Flag Day site2 or ISC EDNS Compliance Tester3. Note that all domains hosted at a given server will either pass or fail.
How to Fix an Apparent Non-Compliant Server
  • For domain names served by a third-party, contact the responsible party immediately.
  • Make sure the failure isn’t a false report due to your authoritative server rate limiting the test tool.
  • Make sure firewalls are not blocking EDNS traffic. Allow UDP packets greater than 512 bytes and see the firewall discussion on the DNS Flag Day site2.
  • Update your authoritative DNS server software. 
 

Background:

    The “resolver”, or client side of DNS, initiates a sequence of queries ultimately leading to an “authoritative DNS server” that can answer a requested mapping (e.g. happy.edu = 10.0.0.1). The client resolver on your device is supported in the sequence-of-queries by a “recursive resolver”, usually provided by the institution or Internet Service Provider. Most recursive resolvers now support EDNS (Extension Mechanisms for DNS). Absence of EDNS support in authoritative DNS servers requires workarounds by the recursive resolver. DNS Flag Day removes support for these workarounds.
 
     Even if an institution doesn’t upgrade its own recursive resolvers to a version that removes support for the workarounds, because others in the world will be upgrading their recursive resolvers, access to the institution’s IT-based resources will be affected by the institution’s non-compliant authoritative DNS server.
 
     This post was provided by The Research and Education Networking Information Sharing and Analysis Center (REN-ISAC). 
 
    To see how this might affect our members, REN-ISAC quickly inspected 53 institutions residing within one U.S. state, we found that 30 showed no problem, 15 showed minor problems, and six showed serious problems. Two tested schools returned with a result of “Fatal Error Detected”.
 
The following sites provide more information on how your organization can prepare:
                                                           
2 DNS Flag Day; https://dnsflagday.net/
3 ISC EDNS Compliance Tester; https://ednscomp.isc.org/ednscomp
 
Additional information can be found here https://dnsflagday.net/

Manufacturing RF Vulnerabilities

      Radio-frequency (RF) remote controllers are everywhere: they open your car and your garage, they connect peripherals to your computer. You will also find them widely used in manufacturing and construction. Being able to remotely control large and/or multiple pieces of equipment from one device offers convenience and increased productivity, but remote solutions are often implemented with security as an afterthought, if thought of at all.
      We’ve seen how trivial it is to hack a key fob or a wireless keyboard, and it’s not much more difficult to hack a controller for large machinery. This week, Trend Micro released a report on how pervasive and vulnerable RF controllers are in the industrial world and they found that garage door openers are more secure than industrial RF controllers. Potential attack vectors might be as simple as a replay attack, where the attacker sniffs the RF packets and sends them back to the machine to gain control—something any script kiddie could do. From there the attacker could modify packets to inject commands.
     Another relatively simple attack is called e-stop abuse, where the emergency stop command is replayed to the machine until it causes a denial-of-service (DoS). This could bring an entire factory to a grinding halt or disrupt safety mechanisms, putting workers in danger.
On the other end of the spectrum is a more difficult and more remote attack vector. An advanced hacker could remotely rewrite the firmware on a remote control with their own malicious code in order to gain and maintain access. This impacts all of the vendors tested by Trend Micro that support reprogramming on their devices. Researchers also noted that none of those devices had authentication implemented.
    The vulnerabilities discovered have been reported to the manufacturers in the hopes that those companies will take a closer look at the security of their devices. It remains to be seen whether any changes will be made. Physical security is usually very good at manufacturing and construction sites, possibly thwarting a local attack, but it’s never one hundred percent. A determined hacker will find a way and industry provides a large attack surface with many possibilities. 
Sources:
https://www.theregister.co.uk/2019/01/15/ even_cranes_are_hackable_trend_micro/
https://documents.trendmicro.com/assets/white_papers/wp-a-securityanalysis-of-radio-remote-controllers.pdf

Flaws in Systemd Privilege Escalation in almost all of the systemd based Linux distros

     Researchers at Qualys have revealed three security vulnerabilities in a component of systemd. This is believed to be affecting almost all of the systemd based Linux distros. The silver lining is that most of the distros have been made aware of the issue and have been working on fixes for these exploits.
     The patches are respectively CVE-2018-16864, CVE-2018-16865, and CVE-201819866. They should be appearing in repos soon. This has been attributed to coordinated disclosure by Qualys. Debian will remain vulnerable for the time being, however, according to The Register, Qualys’s Jimmy Graham has said “that they are aware of the issue and we should be seeing a fix soon.”
     The bugs were found in system-journald, a component of system that handles the collection and storage of logs. The first two, CVE-2018-16864 and CVE-201816865, are memory corruption flaws. CVE-2018-16864 can be leveraged by malware to crash and potentially hijack the system-journald service, there-by elevating access from a user to root for the attacker. CVE-2018-16865 and CVE2018-16866 can be used together to crash or hijack a root privileged journal service by a local attacker.
     These exploits are believed to affect almost all of the systemd based Linux distros in use today. However, SUSE Linux Enterprise, openSUSE Leap 15.0, and Fedora 28 & 29 do not seem to be affected. This is thought to be due to their user-land code being compiled with GCC’s –fstack-clash-protection.
      CVE-2018-16864 entered into the code base in April of 2013, then became exploitable with system v203 in Feb 2016. CVE-2018-16865 seems to have appeared in the code base in 2011 in system v38 and became exploitable in April 2013 (systremd v 201). CVE-2018-16866 was introduced in June of 2015. However, it was inadvertently fixed in August of 2018.

Sources

Card Access Control System Accessed

     What you know, what you are, and what you have. These are three of the key components of security. Key cards are a common form of security that can deny access to a space or object to anyone without an object with the proper credentials. Researchers at Tenable have discovered a series of flaws discovered in September of last year. The flaws pertain to PremiSys Identicard Access control System.
     The researchers at Tenable found a hardcoded set of credentials in version 3.1.190 of PremiSys IDenticard. This set of credentials would allow an adversary all the capabilities of an administrator including modifying access to existing users, deleting users, and adding users. Though it’s doubtful that an adversary could act without trace, they can certainly act without hindrance.
The researchers also found that the sensitive information in the system was stored with an insecure hashing algorithm. It currently uses the MD5 which has not been recommended since 1996 and is subject to commonly known collision vulnerabilities.
     Backups within the system are stored in password protected zip files. Unfortunately, the password has been hardcoded into each instance of the product with no option for the user to change the password without the intervention of the vendor. Along with backups being barely protected by a hardcoded password, the database also comes with a preselected username and password with no opportunity for the user to change those credentials. They must once again go to the vendor for a custom solution.
     These issues seem fairly pressing and can be crippling in a product that promises security. The common practice of providing a grace period for a company to patch the issues seems generous in the face of such glaring flaws. So far a patch has not been released and the product is still vulnerable.
Workarounds include network segmentation and restricting access to systems from outside of the network. It might not be possible to maintain vigilance over the entirely of a database without verification hashes.
     John Fox, Senior Product Manager at Identicard, has provided a statement to Bleeping Computer claiming to be vigilant of the situation. They “anticipate releasing improvements in the near term” which should be expected of any company experiencing any such complications in their product.
Sources:
https://www.tenable.com/security/ research/tra-2019-01
https://medium.com/tenabletechblog/trumping-physical-securitywith-software-insecurity3945a63e1f1a
• https:// www.bleepingcomputer.com/news/ security/flaws-in-a-card-accesscontrol-system-may-allow-hackersto-bypass-security/Flaws

CISA Emergency Directive on DNS Infrastructure Tampering UPDATE

U.S. Department of Homeland Security US-CERT


National Cyber Awareness System:

 

01/22/2019 06:48 PM EST
 
Original
release date: January 22, 2019

The U.S. Department of Homeland Security (DHS) Cybersecurity and
Infrastructure Security Agency

(CISA) issued an emergency directive to
address ongoing incidents associated with global Domain

Name System (DNS)
infrastructure tampering. CISA is aware of multiple executive branch agency
 

domains that were impacted by the tampering campaign and has notified the
agencies that maintain

them. The directive requires Federal agencies to
take specific steps and comply with reporting

procedures to mitigate risks
from undiscovered tampering, prevent illegitimate DNS activity, and

detect
unauthorized certificates.

Federal agencies should review Emergency
Directive 19-01
for required actions and reporting
procedures.