Month: January 2019

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

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

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
      

Impact

Solution

    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.

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

• ISC Blog: DNS Flag Day; https://www.isc.org/blogs/dns-flag-day/
• APNIC Blog: DNS Flag Day; https://blog.apnic.net/2018/10/11/dns-flag-day/
• ISC EDU Report; https://ednscomp.isc.org/compliance/edu-report.html  (note: data will be incomplete)

      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

     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

• https://thehackernews.com/2019/01/linux-systemd-exploit.html
• https://www.theregister.co.uk/2019/01/10/systemd_bugs_qualys/
• https://quantus.biz/security/2019/01/10/new-systemd-privilege-escalationflaws-affect-most-linux-distributions/01

     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