Category: Microsoft

Differences between availability modes for an Always On availability group

Applies to:  SQL Server (all supported versions)

In Always On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary’s session-timeout period).

 Note

If primary’s session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

Supported Availability Modes

Always On availability groups supports three availability modes-asynchronous-commit mode, synchronous-commit mode, and configuration only mode as follows:

  • Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.For more information, see Asynchronous-Commit Availability Mode, later in this topic.
  • Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.For more information, see Synchronous-Commit Availability Mode, later in this topic.
  • Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. A replica in configuration only mode does not contain user data. In configuration only mode, the replica master database stores availability group configuration metadata. For more information see Availability group with configuration only replica.

The following illustration shows an availability group with five availability replicas. The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

Availability and failover modes of replicas

The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

Current Primary ReplicaAutomatic Failover TargetsSynchronous-Commit Mode Behavior WithAsynchronous-Commit Mode Behavior WithAutomatic failover possible
010202 and 0304Yes
020101 and 0304Yes
0301 and 0204No
0401, 02, and 03No

Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability Mode

Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in situations where performance is more important than synchronized data protection. Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. The failover target transitions to the primary role, and its copies of the databases become the primary database. Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. This means that some or all of the new primary databases might be lacking recently committed transactions. For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability Mode

Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. The secondary database remains SYNCHRONIZED as long as data synchronization continues. This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

In This Section:

Factors That Disrupt Data Synchronization

Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. The synchronized secondary replica will remain healthy unless one of the following occurs:

  • A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout. NoteFor information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).
  • You suspend a secondary database on the secondary replica. The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. The secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.
  • You add a primary database the availability group. Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.
  • You change the primary replica or the secondary replica to asynchronous-commit availability mode. After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.
  • You change any secondary replica to synchronous-commit availability mode. This causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state until all of its databases are in the SYNCHRONIZED synchronization state.

 Tip

To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

How Synchronization Works on a Secondary Replica

Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

Synchronous operation is maintained in the following manner:

  1. On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.
  2. Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. The primary replica waits for confirmation from the synchronous-commit secondary replica.
  3. The secondary replica hardens the log and returns an acknowledgement to the primary replica.
  4. On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client. NoteIf a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

Synchronous-Commit Mode with Only Manual Failover

When these replicas are connected and the database is synchronized, manual failover is supported. If the secondary replica goes down, the primary replica is unaffected. The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). For more information, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Mode with Automatic Failover

Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. You can have up to three automatic failover replicas.

Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. If the primary replica becomes unavailable under these conditions, automatic failover occurs. The secondary replica switches to the role of primary, and it offers its database as the primary database. For more information, see the “Automatic Failover ” section of the Failover and Failover Modes (Always On Availability Groups) topic.

 Note

For information about WSFC quorum and Always On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

Data latency on secondary replica

Implementing read-only access to secondary replicas is useful if your read-only workloads can tolerate some data latency. In situations where data latency is unacceptable, consider running read-only workloads against the primary replica.

The primary replica sends log records of changes on primary database to the secondary replicas. On each secondary database, a dedicated redo thread applies the log records. On a read-access secondary database, a given data change does not appear in query results until the log record that contains the change has been applied to the secondary database and the transaction has been committed on primary database.

This means that there is some latency, usually only a matter of seconds, between the primary and secondary replicas. In unusual cases, however, for example if network issues reduce throughput, latency can become significant. Latency increases when I/O bottlenecks occur and when data movement is suspended. To monitor suspended data movement, you can use the Always On Dashboard or the sys.dm_hadr_database_replica_states dynamic management view.

For more information on investigating redo latency on the secondary replica, please see Troubleshoot primary changes not reflected on secondary replica.

Related Tasks

To change the availability mode and failover mode

To adjust quorum votes

To perform a manual failover

To view availability group, availability replica, and database states

Related Content

See Also

Overview of Always On Availability Groups (SQL Server)
Failover and Failover Modes (Always On Availability Groups)
Windows Server Failover Clustering (WSFC) with SQL Server

Source :
https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver16

WP Shield Security PRO – Release 16.1

It’s been a few months in the making, but it’s finally here – our most exciting release (yet again!) of Shield Security for WordPress.

This release is absolutely packed with goodies and our headline feature – integration with CrowdSec – deserves an article all to itself.

Here you’ll discover all the exciting things we’ve packed into ShieldPRO v16 and why you should be upgrading as soon as it’s out.

Let’s dig into all the new goodies…

#1 Partnership with CrowdSec for Crowd-Sourced IP Intelligence

This is, to our mind, one of the most exciting developments for WordPress security for a very long time.

We’ve wanted to achieve this level of protection against bots for years, as we firmly believe that good WordPress security starts with intelligent blocking malicious IP addresses.

Shield does an effective job of this already with its automatic block list system, but we’ve now achieved group intelligence so all WordPress sites running on Shield will benefit from the experiences of all the other websites running Shield.

This is a big topic so we’ve dedicated a whole article to it – learn about the new partnership here.

#2 Brand New IP Rules and Blocking Engine

IP Blocking has been a part of ShieldPRO, practically from the outset. It’s core to our WordPress security philosophy.

With such a long-standing feature, you can imagine that the knowledge and experience used to create that original system isn’t as thorough as it is today. We’ve come a long way, I can promise you.

This release, spurred on by the new CrowdSec integration, sees the much-needed overhaul of our IP management system. It’s smarter and more versatile, and altogether much faster!

Shield must lookup a visitor’s IP address on every single request to a WordPress site. If we can improve the speed of that lookup, we improve Shield performance overall.

#3 Improved UI

Shield has a number of different subsystems, many of which are related. The scan results page is linked to the scanner configuration page, for example.

To-date when you wanted to view any section of the plugin, it would reload the entire page. We’ve done some work to reduce full page reloads so that you can stay “where you are” while viewing the contents of another page.

In particular we’re referring to “Configuration” pages. Links to such areas will now open in an overlay, letting you keep your current page active while you review and adjust settings.

Another UI enhancement is a new title bar across every page of the plugin, letting you see more clearly where you are, along with important links to help resources.

This title bar also includes our brand new “super search box”…

#4 Shield’s Super Search Box

We mentioned UI improvements already, but this deserves a section all to itself.

To say Shield is a large plugin is understating it. There are many options pages, as well tools, tables, data, and charts etc.

Finding your way around can be a bit tricky. Since we built it, we know it inside out. But for everyone that uses it as a tool to protect their sites, it’s not always obvious where to go to find the “thing” you need.

No longer!

With Shield’s “Super Search Box”, you can find almost anything you need, and jump directly to it. Currently you can search for:

  • Specific configuration options
  • Tools such as Import/Export, Admin Notes, Debug
  • Logs such as Activity Logs and Traffic Logs
  • IP Rules
  • IP addresses – it’ll open a popup to review the data Shield holds on any particular IP
  • External links such as Shield’s homepage, Facebook page, helpdesk, crowdsec etc.

We’ll develop this a bit more over time as we get feedback from you on what you’d like to see in there.

#5 Lighter, Faster Scan Results Display

Shield’s scans can turn up a lot of results and some customers have reported trouble on some servers with limited resources.

We’ve redesigned how the scan results are built, so it’s faster and lighter on both your browser and the WordPress server.

#6 Improved Human SPAM Detection

After working with a customer on some issues she faced with Human SPAM, we’ve developed enhancements to how Shield will detect repeated human spam comments.

For example, a SPAMer may post a comment and trigger our human SPAM scanner. But then they’ll fire off more comments which might bypass the same scanner. We’ll now use previous SPAM detections by Shield to inform future comments, too.

We also squashed a bug where Shield wasn’t properly honouring the “disallowed keywords” option built into WordPress itself.

#7 Custom Activity Logs and Events

Shield covers a lot of areas when it comes to monitoring events that happen on a WordPress site. But we typically don’t cover 3rd party plugins.

So, based on the feedback from a number of interested customers, we’ve added the ability for any PHP developer to add custom events to Shield’s Activity Logs.

When might you find that useful?

You could, for example, track WooCommerce orders, or you could be facing a particularly menacing visitor that repeats an undesireable action on your site that’s not covered by Shield, and decide to block their IP.

You can do whatever you want with this, though you should always take care when allocating offenses to actions as you may inadvertently block legitimate users.

#8 All-New Guided Setup Wizard

When first installing a platform like Shield Security for WordPress, it can be a little overwhelming. Shield is a large plugin, with many features, tools and options.

We’ve had a “Welcome Wizard” in Shield for a while, but it was a little rough around the edges. For this release we decided to revamp it and provide a new guided setup wizard, helping newcomers get up-to-speed more quickly.

Anyone can access the Guided Setup from the Super Search Box (search: “Wizard”), or from the Shield > Tools menu.

A Change To Minimum Supported WordPress Version

We try to make Shield Security as backward-compatible as possible, while it makes sense to do so.

However, this means that our code development and testing must reflect this and means that the burden of support increases the farther back we support older versions.

Our Telemetry data suggests that there are no WordPress sites below version 4.7 running the Shield plugin. Of course, we can only go on what data has been sent to us. But we have to draw the line somewhere, and with Shield v16, we’re drawing the line at WordPress 4.7.

As more data comes through and time marches on, we’ll gradually increase our minimum requirements so we strongly suggest you keep your WordPress sites, and hosting platforms as up-to-date as possible.

Comments, Feedback and Suggestions

A lot of work has gone into this release that will, we hope, improve security for all users by making it much easier to see what’s going on and what areas need improved. The Security Rules Engine is one of our most exciting developments to-date and we can hardly wait to get the first iteration into your hands and start further development on it.

As always, we welcome your thoughts and feedback so please do feel free to leave your comments and suggestions below.

Source :
https://getshieldsecurity.com/blog/wp-shield-security-pro-release-16-1/

ShieldPRO 16.1.0 Upgrade Guide

ShieldPRO 16.1.0 for WordPress is a major release packed with many changes and improvements, including UI enhancement, adding integration with CrowdSec and the ability to permanently block IP any much more.

This guide outlines what have been added/removed, changed, or improved and what fixes we’ve made.

Firstly, we’re going to explain what major changes are made and which options you’d need to review.

New Added Features

For 16.1.0 release we added

With the CrowdSec integration, your WordPress sites will have access to intelligence about malicious IP addresses before they’ve ever accessed your website. (This intelligence will have already been gathered for you by other websites.)

This reduces that “window” available to malicious bots to zero.

The settings can be found under the IP Blocking section:

There are 2 options available

  1. CrowdSec IP Blocking – how Shield should block requests from IP addresses found on CrowdSec’s list of malicious IP addresses.
  2. CrowdSec Enroll ID – link site to your CrowdSec console by providing your Enroll ID.

There is now the option to log custom events to Shield’s Activity Log. It’s impossible that Shield can log every possibly event for every plugin and scenario, so you can now add logging for all your desired site events. This is an advanced option and will require professional software development experience to implement. 

  • Logging: App Password Creation

Shield now captures creation of new Application Passwords in the Activity Log.

  • Shield’s Super Search Box

This search box will look for almost anything you need and provide you with links directly to the item in question. 

Currently you can search for:

  • Specific configuration options
  • Tools such as Import/Export, Admin Notes, Debug
  • Logs such as Activity Logs and Traffic Logs
  • IP Rules
  • IP addresses – it’ll open a popup in-situ to review the data Shield holds on any particular IP
  • External links such as Shield’s homepage, Facebook page, helpdesk, CrowdSec etc.

The Super Search Box is accessible and visible from every page inside the plugin.

Enabling the Shield Beta Access option allows you to gain access to beta versions of the Shield Security plugin.

  • All-New Guided Setup Wizard

For this release we revamped it and provide a new guided setup wizard, helping newcomers get up-to-speed more quickly.

You can access the Guided Setup from the Super Search Box (search: “Wizard”), or from the Shield > Tools menu.

For whitelisted IP addresses, there are no restrictions for the user related with that IP whatsoever –  none of the setting will apply to that IP, including the hiding login URL. 

We added a special notice for a user with a whitelisted IP:

Changes

Change 1: Improved UI

We’ve done some work to reduce full page reloads so that you can stay “where you are” while viewing the contents of another page.

In particular we’re referring to “Options/Configuration” pages. Links to such areas will now open in an overlay, letting you keep your current page active while you review and adjust settings.

Example

Also, IP analysis dialog now opens in an overlay, for example:

Another UI enhancement is a new top title bar across every page of the plugin, letting you see more clearly where you are and with some important links to help and other resources.

Example

Change 2: Completely New IP Rules and Blocking Engine

This release, spurred on by our CrowdSec integration, sees the much-needed overhaul of our IP management system. It’s smarter and more versatile and altogether much faster.

We also made some UI enhancements on the Management & Analysis section:

  • “Manage IP” section is renamed to “IP Rules”
  • IP blocking and bypass list are merged and a new table is used now
  • IP Analysis dialog is now separated and can be loaded for each IP directly from within IP Rules, Activity Log, and Traffic Log. Example, loading from within IP Rules:

  • “Reset” option added into the IP analysis dialog

  • Manual adding IP to the block or bypass list is merged now and can be accessed from within “Add New IP” option:
  • Manually or auto blocked IP can be now permanently blocked

    You can do this by manually adding IP to the block list or directly from within IP analysis dialog

Change 3: Improved Build Custom Charts option

The Shield event(s) are now displayed in a form of list. Selecting desired events is much easier now.



Improvements

For 16.1.0 release we’ve made the following improvements

  • Improved and Faster Scan Results Display

    We’ve redesigned how the scan results are built so it’s faster and lighter on your browser and on the server itself.

    Eliminated errors and slow processing when displaying scan results pages for large datasets. Shield now uses highly optimised queries to request only the records required to display the current table page.
  • Improved Human SPAM Detection
    We’ve added some enhancements on how Shield will detect repeated human spam comments.

    We also squashed a bug where Shield wasn’t properly honouring the “disallowed keywords” option built into WordPress itself.
  • A change to minimum supported WordPress version: 4.7
    Based on Shield telemetry data, we’re pushing our minimum supported WordPress version up to 4.7. We’ll continue to push this upwards as usage data suggests it make sense to do so.
  • Protection Against Unauthorised Deactivation
    The Security Admin feature that protects against unauthorised deactivation has been further strengthened with offenses.
  • Shield Navigation Bar
    Shield offer a much better navbar on the dashboard with built-in search, helpdesk links and updates.

Removed Options

For 16.1.0 release we removed the following options

  • Auto Block Expiration (under Config > IP Blocking section) we removed “1 minute” option.
  • Leading Schema Firewall Rule
    This rules flags too many false positives for members.

Fixes

For 16.1.0 release we’ve made various fixes

  • Mitigate a fatal error caused by the latest wpForo plugin passing NULL to locale filters.
  • Bug when specifying a particular list when adding/removing an IP address using WP-CLI.
  • Shield no longer attempts to solve the issue of invalid ‘from’ email addresses on a WordPress site.

For more information on Shield 16.1.0 release, read this blog article here.

Source :
https://help.getshieldsecurity.com/article/476-shieldpro-1610-upgrade-guide

How to set up the Surveillance Station of QNAP NAS?

Introduction

To satisfy the increasing demand for embedded network surveillance solutions on NAS, QNAP unveiled a value-added application ‘Surveillance Station’ on its All-in-One Turbo NAS Series. The Surveillance Station enables users to configure and connect many IP cameras at the same time and manage functions including live audio & video monitoring, recording, and playback. Installation and configuration can be easily carried out remotely in a web browser in a few steps. Various recording modes are provided: continuous recording, motion-detection recording, and scheduled recording. Users can flexibly define the recording settings according their security plans.
The Surveillance Station supports a large number of IP camera brands. You can find a list of supported cameras at: https://www.qnap.com/compatibility.

Contents

  • Plan your home/office network topology
  • Set up the IP Cameras
  • Configure the Surveillance Station on the QNAP NAS
  • Configure Alarm Recording on the QNAP NAS
  • Play Video Files from the Surveillance Station

Plan Your Home/Office Network Topology

Write down your plan of the home/office network before starting to set up the surveillance system. Consider the following when doing so:

  • The IP address of the NAS
  • The IP address of the cameras
  • The IP address of your router and the wireless SSID

Your computer, the NAS, and the IP cameras should be installed to the same router in LAN. Assign fixed IP addresses for the NAS and the IP cameras.
For example:

  • The LAN IP of the router: 192.168.1.100
  • Camera 1 IP: 192.168.1.10 (fixed IP)
  • Camera 2 IP: 192.168.1.20 (fixed IP)
  • NAS IP: 192.168.1.60 (fixed IP)

Set up the IP Cameras

Configure the IP address for both IP cameras using the following steps.
You can download a camera IP Finder from official website of your camera’s vendor.
The name of the IP finder may differ between vendors. IP Finder is a utility that helps you search for the IP address of the camera.
CONNECT the IP camera to your home/office network with a network cable and run the IP Finder. Set the IP address of the cameras so that they are on the same LAN as the computer. You will then be able to login to the configuration page of the camera with a web browser. Enter the IP address of the first camera as 192.168.1.10. The default gateway should be set as the LAN IP of the router (192.168.1.100 in our example).

Note: The default IP and ID of administrator may differ based on what camera model is used.

ENTER the web configuration page of the IP camera.
You will then be able to view the monitoring image.

GO to ‘Network/ Network’ and check the IP settings of the camera.

NEXT, if you are using a Wireless IP CAM, please go to “Network/Wireless” and configure the wireless setting of your camera. Please ensure the camera’s settings are completed.

Repeat the above steps to set up the second camera.
To summarize, so far you have finished the following settings:

  • Camera 1 IP: 192.168.1.10
  • Camera 2 IP: 192.168.1.20

Note:
If you forget the camera settings, please press the reset button at the back of the camera for 5-10 seconds. The camera will be restored to default settings. You can then set the IP address and login to the camera’s configuration page with using the default login name and password. The reset function may differ by the brand of the camera. Please refer to the camera’s user manual in advance.

Configure the Surveillance Station on the QNAP NAS

Go to “Control Panel” > “System Settings” >”Network” > “TCP/IP” and press the “Edit” button to specify a fixed IP to the NAS: 192.168.1.60. The default gateway should be the same as the LAN IP of your router, which is 192.168.1.100 in our example.

Install Surveillance Station

  • Auto installation: Go to “App Center” > “Surveillance” > “Surveillance Station” and click “Add to QTS” to start installation.
  • Manual installation: Download the Surveillance Station QPKG from the App Center on the QNAP website. Then you can install it by clicking the “Install Manually” button and by selecting the location of the Surveillance Station QPKG to start installing.

Please note: To ensure proper operations of Surveillance Station, we recommend rebooting the Turbo NAS after its installation is completed.

In the Surveillance Station, please go to “Settings” and select “Camera 1” then click “” to add the camera configuration, e.g. name, model, IP address, recording setting and recording schedule.

In our demonstration we will assign the following IPs to each camera:
Camera 1 IP: 192.168.1.10
Camera 2 IP: 192.168.1.20

Note:
Before applying the settings, you may click “Test” on the right to ensure the connection to the IP camera is successful.

You can enable or change the recording option of the camera in next page. Click “next” to move to the next page.

On this page, you will see the “Schedule Settings.” In the table, 0~23 represents the time period. For example, 0 means 00:00~01:00, 1 means 01:00~02:00. You can set a continuous recording in any period that you want.

Then you will see the “Confirm Settings” on the next page.

After you have added the network cameras to the NAS, go to the “Monitor” page. The first time you access this page by browser, you have to install the ActiveX control (QMon.cab) in order to view the images of Camera 1 and Camera 2.

Note:
You can use the Surveillance Station in Chrome, Firefox or IE. The browser will prompt you to install the “ActiveX control” (QMon.cab) before using Monitor or Playback functions. Please follow the on-screen instructions to complete the installation.

Note:
When you click on the monitoring screen of a camera, the frame will become orange. You can use the s configuration page.
In Surveillance Station 5, there is a new feature called “Instant Playback”. You can click the floating button to play recording and find recent event.

Configure Alarm Recording on the QNAP NAS

The Surveillance Station supports alarm recording by schedule. To use this function, go to “Camera Settings” > “Alarm Settings” in the Surveillance Station. You could select ‘Traditional Mode’ to do basic configurations or ‘Advanced Mode’ to define advanced alarm events.

  • Traditional Mode :
    You may define criteria enabling alarm recording then click ‘Apply’ to save the changes.
  • Advanced Mode :
    You may select the event on the left side and add an action on the right side by clicking “Add”.

Then you may choose the action type you need for this event.

The event “Motion Detection” has a corresponding action “Recording”.

Play Video Files from the Surveillance Station

You have to click or to enter the playback page and follow the steps below to play the video files on the remote Surveillance Station.

1. Drag and drop camera(s) from the server/camera tree to the respective playback window(s) to select the channel(s) for playback.

2. Select playback date from.You can examine each channel to know the time range when the files were recorded for each IP camera. The blue cells indicate regular recording files and the red cells indicate alarm recording files. If it is blank, it means no files are recorded at that time.

3. Clickto start the playback. You can control the speed and playback direction by dragging the button to right or left on the shuttle bar.

4. Specify the time to play back the recording files at that moment. You can view the preview image on the timeline bar to search the moment you want to play.

5. Clickto control all the playback windows to play back the recording files. When this function is enabled, the playback options (play, pause, stop, previous/next frame, previous/next file, speed adjustment) will be applied to all the playback windows.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-the-surveillance-station-of-qnap-nas

Online RAID Capacity Upgrade

https://www.youtube.com/embed/V6VFGkeFN8I?enablejsapi=1&origin=https%3A%2F%2Fwww.qnap.com

A New Challenge for Modern Businesses

For modern businesses, one of the greatest challenges is to select and set up a reliable network-attached storage server to secure and share important data to increase work efficiency. Meanwhile, the necessity to reduce the risk of data loss by backing up data increases the demand for higher capacity storage. With the increasing storage capacity of hard drives, QNAP provides a solution to hot swap lower capacity drives with larger capacity drives so that your QNAP Turbo NAS can grow with your business.

The QNAP Turbo NAS series provides a high-performance and low-TCO (total cost of ownership) solution for modern businesses. In addition to best-in-class hardware specifications and easy-to-use applications, the QNAP Turbo NAS series also offers innovative features such as Online RAID Capacity Upgrade (for example, replace three 500GB hard drives with three 1TB hard drives) and Online RAID Level Migration (for example, RAID level migration from RAID 1 to RAID 5). These advanced features used to be exclusive to corporations with large budgets, but QNAP implements an intuitive way to allow more businesses to enjoy these powerful technologies.

The scenario below demonstrates how users can benefit from using Online RAID Capacity Upgrade.

Use Case

  • Jeffrey bought three 500GB drives for the initial setup of a TVS-882 and used a RAID 5 configuration for these drives.
  • Six months later, the storage needs of his department sharply increased and the current storage capacity of his TVS-882 was no longer enough. At the same time, the price of 1TB hard drives had significantly dropped. Thus, Jeffery decided to buy three 1TB hard drives.
  • Jeffery now wants to upgrade the capacity of his TVS-882 NAS.

Operation procedure

Log in to QTS with an administrator account. Go to  “Storage & Snapshots” > “Storage/Snapshots”. Select the storage pool that will be expanded, then click “Manage“. The “Storage Pool Management” window will appear, select the RAID group that will be expanded and click “Replace Disks One by One” in the “Manage” menu.

Highlight the first disk to be replaced, and click “Change“.

Tips: After you replace hard drives, the description field will show the message “You can replace this drive”. You can now replace the hard drive to a larger one or skip this step if the hard drives have already been replaced.
Caution: When the hard drive synchronization is in process, DO NOT turn off the NAS or swap hard drives.

When the description field displays “Please remove this drive”, remove the hard drive from the NAS. Wait for the NAS to beep twice.

When the description field displays “Please insert the new drive”, insert the new drive to the same drive slot.

After inserting the hard drive, wait for the NAS to beep. The system will start rebuilding.

When the RAID is finished rebuilding, repeat the steps above to replace the other hard drives one by one.

After swapping out hard drives and the rebuilding completes, click “Expand Capacity” to expand the RAID.

Click “OK” to continue.

The NAS will beep and start expanding the capacity.

Depending on the drive sizes, the process may take anywhere from a few hours to tens of hours to complete. Please wait patiently for the process to finish. DO NOT turn off the NAS.

After RAID expansion is finished, the new capacity will be shown and the RAID group status will be “Ready”. The process is now complete and the new storage space is available for use.

Tips: To expand the capacity of closed NAS models (those without accessible drive bays) you need to shut down the NAS, unplug its cables, lay the NAS on a flat surface, open its cover, and then replace the hard drives within. Then replace the cover, plug in the cables, turn on the NAS, and then follow the instruction on the screen.

Source :
https://www.qnap.com/en/how-to/tutorial/article/online-raid-capacity-upgrade

Manually Install QRescue to recover Qlocker-encrypted files on QNAP NAS

Overview:

QRescue is the data recovery tool for Qlocker-encrypted 7z files. It contains:

  • PhotoRec (Open Source Project / GNU General Public License / Project Link):
    File recovery software designed to recover lost files from hard disks and CD-ROMs, and lost pictures (thus the Photo Recovery name) from storage medium.
  • QRescue (Powered by QNAP):
    The script to recover file structures from the encrypted 7z files and PhotoRec files.

Requirements:

  • Download the QRescue app from this link.
    https://download.qnap.com/QPKG/QRescue.zip
  • Prepare an external hard disk drive with a capacity larger than the total used storage space on your NAS.
    • Note: It’s advised to prepare an external HDD with 1.5 to 2x free space than the total used storage space on your NAS. Additional space might be required during the recovery process. If the available space is less than the suggested value, error and other issues may occur.

Demo Video:

Steps: 

Part 1. Configure external HDD with the name “rescue” and create folders with the name “recup1” for recovery.

QRescue will process the recovery process to external drive first, and we need to do some configuration for this recovery process and create the specific destination and folder name.

  1. You need to prepare an external HDD that its usable capacity is larger than the total used storage size of your NAS. This is because you will recover the files to the external device first. Please check your used volume size first by clicking More > About on the QTS desktop.
  2. Insert the external drive to your NAS. Please go to Storage Manager > External Device > Select your external device > Click “Actions” > Click “Format” to format the external drive.
  3. The File System must be “EXT4”, and the Label name must be key in “rescue”. If these configuration is ready, please click “Format”

    Notice:
    The QRescue app will use “rescue” as the external drive name. If you use other names, the recovery process might fail.
  4. (Optional) If you disable the admin account or you don’t use admin to login QTS, you might not see the external drive on the File Station. Please go to Control Panel > Privilege > Shared Folder > Edit Shared Folder Permission to enable or change read / write permission for “rescue” folder and to match the account that you log in the NAS.
    • Sample:
      Grant other administrator group account (Example: “_qnap_support” is the administrator group account for read/write permission to external hard drive naming “rescue”).


       
  5. Using File Station to check the volume for the correct external device name.
  6. Create the new folder and name as “recup1” (format: recup+{number}). If you have more than one storage volume, you need to add more folders for recovery.



    Notice:
    The QRescue app will use “recup+{number}” as the folder name. If you use other names, the recovery process might fail.Part 2. Download and Manually Install the QRescue AppThis QRescue app is a special build. Therefore, you need to manually install this app from the QTS App Center.
  7. Please go to this link to download the QRescue app.
    https://download.qnap.com/QPKG/QRescue.zip
  8. Please go to App Center > Click Install Manually > Click Browse to find the QRescue app location on your computer.
  9. After selecting the app location, you can click Install. Wait until the installation completes and open the QRescue app on QTS desktop or side-bar.
  10. When you open the QRescue app, you will see the web console. It can help to run PhotoRec and QRescue to recover your files.Part 3. Run PhotoRecRunning PhotoRec can help you to recover the lost files from hard disks to the external drive. Now you will recover the NAS files to the “recup1” (example: recup+{disk_number}) folder on the external drive.
  11. Type this command and press Enter on your keyboard. You will start to run PhotoRec.
    Command:
    photorec
  12. Use Up/Down arrows to choose the hard drive. And you can start to select the NAS disk for running recovery by PhotoRec.
    • Sample:
      • /dev/mapper/cachedev1 as 1st data volume
      • /dev/mapper/cachedev2 as 2nd data volume
        …
      • /dev/mapper/cachedev20 as 20th data volume
    • Note:
      You can check the number of data volumes in Storage & Snapshots > Storage/Snapshots
  13. Select the “ext4” partition and press “Enter”
  14. Select the file system as [ ext2/ext3 ] and click “Enter” key.
  15. Select the space as [ Whole ] and click the “Enter” key.
  16. Now we need to select the external device’s folder as the recovery destination. 
    • Source Destination: /share/external/DEV3301_01/qpkg/QRescue   [QRescue qpkg]
    • Recovery Destination: /share/rescue/recup1 [External Device]
    • Click “..” to go back to the upper level folder
       
      • Sample destination: External disk on QRescue app
      • Sample: External Device (name: rescue) > Destination Folder (name: recup1)
  17. Please click “C” on the keyboard when the destination is “/share/rescue/recup1”.
  18. Start to run the recovery process by PhotoRec. Now you can see the estimated time to completion.
  19. When you finish the PhotoRec, you can press enter when you select  [Quit] or type in “ctrl-c” to exit.
    Part 4. Run QRescueRun QRescue can help you to recover the files retrieved by PhotoRec. Now you will recover the files from the “recup+{number}” folder to the “restore+{number}” folder which auto creates on your external drive.
  20. Type this command and click Enter on your keyboard. You will start to run QRescue.
    Command:
    qrescue.sh
  21. (Optional) If you have two or more data volumes on your NAS, the screen will let you select which data volume you will start the process. Please type the number and press “enter”. If you only have one data volume, you might not see this step.

  22. (Optional) Now you can see the progress for which files were completed in the recovery process.
  23. When all of the QRescue process is completed, the screen will show the result summary and the process for sending the system log.
  24. QRescue app also will send the event log to QuLog Center / System Log and notify you on finishing the whole recovery process. If you have opened the QNAP support ticket, don’t forget to make the feedback for your case. QNAP support team will help you to double check. Thank you very much.

Part 5. Move the recovery data to your NAS.

You can move the recovery data to your NAS by File Station


Source :
https://www.qnap.com/en/how-to/tutorial/article/manually-install-qrescue-to-recover-qlocker-encrypted-files-on-qnap-nas

How to set up myQNAPcloud to remotely access a QNAP NAS

Requirements

Register your NAS with myQNAPcloud

  1. Log in to your QNAP NAS.
  2. Open myQNAPcloud.
  3. Click Get Started.

    The Welcome to myQNAPcloud! window appears.
  4. Follow the steps to register your NAS. Click Next to move to the next step.
    1. Enter your QNAP ID and Password.
    2. Enter a Device name for your NAS.
      Note: This name is used to identify your NAS on myQNAPcloud and must be unique across all users.
    3. Choose what NAS services will be enabled and the Access Control setting.

      Your device is registered on myQNAPcloud.

      A summary page displays all the registration details and services guidelines of your NAS.

Remotely access your QNAP NAS with myQNAPcloud

  1. Go to https://www.myqnapcloud.com/.
  2. Sign in using your QNAP Account.
    Note: If you are already signed in you are automatically redirected to My Devices .
  3. Go to My Devices.
    The devices registered to your QNAP Account are displayed.
  4. Click the ”  ” button next to the device to display the device IP and SmartURL.
  5. Click SmartURL.

    A login page for your NAS appears.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-myqnapcloud-to-remotely-access-a-qnap-nas

Moving the Mission Forward: Mandiant Joins Google Cloud

Google’s acquisition of Mandiant is now complete, marking a great moment for our team and for the security community we serve.

As part of Google Cloud, Mandiant now has a far greater capability to close the security gap created by a growing number of adversaries. In my 29 years on the front lines of securing networks, I have seen criminals, nation states, and plain bad actors bring harm to good people. By combining our expertise and intelligence with the scale and resources of Google Cloud, we can make a far greater difference in preventing and countering cyber attacks, while pinpointing new ways to hold adversaries accountable.  

When I founded Mandiant Corporation in 2004, we set out to change how businesses protected themselves from cyber threats. We felt the technologies people depended on to defend ultimately failed to innovate at the pace of the attackers. In order to deliver cyber defenses as dynamic as the threats, we believed you had to have your finger on the pulse of adversaries around the world. To address this need, we set out to respond to as many cyber security breaches as possible. We wanted to learn first-hand how adversaries were circumventing common safeguards with new and novel attacks; monitor the development and deployment of attacker tools, their infrastructure, and their underground economies; and study the attacker’s targeting trends.

Armed with this knowledge and experience, we felt we were best positioned to close the gap between the offense and the defense in the security arms race.  

As we investigated thousands of security incidents over the years, we honed the deep expertise required to find the proverbial needle in the haystack: the trace evidence that something unlawful, unauthorized, or simply unacceptable had occurred. We believed this skill was the foundation to automating security operations through software, so that organizations and governments around the world could easily implement effective security capabilities. 

By joining forces with Google Cloud, we can accelerate this vision. I am very excited that Mandiant and Google Cloud can now work together to leverage our frontline intelligence and security expertise to address a common goal: to relentlessly protect organizations against cyber attacks and provide solutions that allow defenders to operate with confidence in their cyber security posture. More specifically, we can leverage our intelligence differentiator to automate security operations and validate security effectiveness.

Mandiant Remains Relentless

While we are now part of Google Cloud, Mandiant is not going away—in fact, it’s getting stronger. We will maintain our focus on knowing the most about threat actors and extend our reputation for delivering world-class threat intelligence, consulting services, and security solutions. 

Automating Security Operations

Today’s announcement should be welcome news to organizations facing cyber security challenges that have accelerated in frequency, severity, and diversity. I have always believed that organizations can remain resilient in the fight against cyber threats if they have the right combination of expertise, intelligence, and adaptive technology. 

This is why I am a proponent of Google Cloud’s shared fate model. By taking an active stake in the security posture of customers, we can help organizations find and validate potential security issues before they become an incident. Google Cloud and Mandiant have the knowledge and skills to provide an incredibly efficient and effective security operations platform. We are building a “security brain” that scales our team to address the expertise shortage.

Validating Security Effectiveness

Google Cloud’s reach, resources, and focus will accelerate another Mandiant imperative: validating security effectiveness. Organizations today lack the tools needed to validate the effectiveness of security, quantify risk, and exhibit operational competency. Mandiant is working to provide visibility and evidence on the status of how effective security controls are against adversary threats. With this data, organizations have a clear line of sight into optimizing their individual environment against relevant threats.

Advancing Our Mission

Google Cloud has made security the cornerstone of its commitment to users around the world, and the Mandiant acquisition underscores that focus.

We are thrilled to continue moving our mission forward alongside the Google Cloud team. Together, I believe Mandiant and Google Cloud will help reinvent how organizations protect, detect, and respond to threats. This will benefit not only a growing base of customers and partners, but the security community at large.

You can learn more about this milestone moment and the exciting opportunities ahead in this blog post by Google Cloud CEO Thomas Kurian, “Google + Mandiant: Transforming Security Operations and Incident Response.”

Source :
https://www.mandiant.com/resources/blog/mandiant-joins-google-cloud

GIFShell attack creates reverse shell using Microsoft Teams GIFs

A new attack technique called ‘GIFShell’ allows threat actors to abuse Microsoft Teams for novel phishing attacks and covertly executing commands to steal data using … GIFs.

The new attack scenario, shared exclusively with BleepingComputer, illustrates how attackers can string together numerous Microsoft Teams vulnerabilities and flaws to abuse legitimate Microsoft infrastructure to deliver malicious files, commands, and perform exfiltrating data via GIFs. 

As the data exfiltration is done through Microsoft’s own servers, the traffic will be harder to detect by security software that sees it as legitimate Microsoft Team’s traffic.

Overall, the attack technique utilizes a variety of Microsoft Teams flaws and vulnerabilities:

  • Bypassing Microsoft Teams security controls allows external users to send attachments to Microsoft Teams users.
  • Modify sent attachments to have users download files from an external URL rather than the generated SharePoint link.
  • Spoof Microsoft teams attachments to appear as harmless files but download a malicious executable or document.
  • Insecure URI schemes to allow SMB NTLM hash theft or NTLM Relay attacks.
  • Microsoft supports sending HTML base64 encoded GIFs, but does not scan the byte content of those GIFs. This allows malicious commands to be delivered within a normal-looking GIF.
  • Microsoft stores Teams messages in a parsable log file, located locally on the victim’s machine, and accessible by a low-privileged user.
  • Microsoft servers retrieve GIFs from remote servers, allowing data exfiltration via GIF filenames.

GIFShell – a reverse shell via GIFs

The new attack chain was discovered by cybersecurity consultant and pentester Bobby Rauch, who found numerous vulnerabilities, or flaws, in Microsoft Teams that can be chained together for command execution, data exfiltration, security control bypasses, and phishing attacks.

The main component of this attack is called ‘GIFShell,’ which allows an attacker to create a reverse shell that delivers malicious commands via base64 encoded GIFs in Teams, and exfiltrates the output through GIFs retrieved by Microsoft’s own infrastructure.

To create this reverse shell, the attacker must first convince a user to install a malicious stager that executes commands, and uploads command output via a GIF url to a Microsoft Teams web hook.  However, as we know, phishing attacks work well in infecting devices, Rauch came up with a novel phishing attack in Microsoft Teams to aid in this, which we describe in the next section.

GIFShell works by tricking a user into loading a malware executable called the “stager” on their device that will continuously scan the Microsoft Teams logs located at $HOME\AppData\Roaming\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.leveldb\*.log.

Microsoft Teams log folder
Microsoft Teams log folder
Source: BleepingComputer

All received messages are saved to these logs and are readable by all Windows user groups, meaning any malware on the device can access them.

Once the stager is in place, a threat actor would create their own Microsoft Teams tenant and contact other Microsoft Teams users outside of their organization. Attackers can easily achieve this as Microsoft allows external communication by default in Microsoft Teams.

To initiate the attack, the threat actor can use Rauch’s GIFShell Python script to send a message to a Microsoft Teams user that contains a specially crafted GIF. This legitimate GIF image has been modified to include commands to execute on a target’s machine.

When the target receives the message, the message and the GIF will be stored in Microsoft Team’s logs, which the malicious stager monitors.

When the stager detects a message with a GIF, it will extract the base64 encoded commands and execute them on the device. The GIFShell PoC will then take the output of the executed command and convert it to base64 text.

This base64 text is used as the filename for a remote GIF embedded in a Microsoft Teams Survey Card that the stager submits to the attacker’s public Microsoft Teams webhook.

As Microsoft Teams renders flash cards for the user, Microsoft’s servers will connect back to the attacker’s server URL to retrieve the GIF, which is named using the base64 encoded output of the executed command.

The GIFShell server running on the attacker’s server will receive this request and automatically decode the filename allowing the attackers to see the output of the command run on the victim’s device, as shown below.

For example, a retrieved GIF file named ‘dGhlIHVzZXIgaXM6IA0KYm9iYnlyYXVjaDYyNzRcYm9iYnlyYXVJa0K.gif’ would decode to the output from the ‘whoami’ command executed on the infected device:

the user is: 
bobbyrauch6274\bobbyrauIkBáë

The threat actors can continue using the GIFShell server to send more GIFs, with further embedded commands to execute, and continue to receive the output when Microsoft attempts to retrieve the GIFs.

As these requests are made by the Microsoft website, urlp.asm.skype.com, used for regular Microsoft Teams communication, the traffic will be seen as legitimate and not detected by security software.

This allows the GIFShell attack to covertly exfiltrate data by mixing the output of their commands with legitimate Microsoft Teams network communication.

Even worse, as Microsoft Teams runs as a background process, it does not even need to be opened by the user to receive the attacker’s commands to execute.

The Microsoft Teams logs folder have also been found accessed by other programs, including business monitoring software, such as Veriato, and potentially malware.

Microsoft acknowledged the research but said it would not be fixed as no security boundaries were bypassed.

“For this case, 72412, while this is great research and the engineering team will endeavor to improve these areas over time, these all are post exploitation and rely on a target already being compromised,” Microsoft told Rauch in an email shared with BleepingComputer.

“No security boundary appears to be bypassed.  The product team will review the issue for potential future design changes, but this would not be tracked by the security team.”

Abusing Microsoft teams for phishing attacks

As we previously said, the GIFShell attack requires the installation of an executable that executes commands received within the GIFs.

To aid in this, Rauch discovered Microsoft Teams flaws that allowed him to send malicious files to Teams users but spoof them to look as harmless images in phishing attacks.

“This research demonstrates how it is possible to send highly convincing phishing attachments to victims through Microsoft Teams, without any way for a user to pre-screen whether the linked attachment is malicious or not,” explains Rauch in his writeup on the phishing method.

As we previously said in our discussion about GIFShell, Microsoft Teams allows Microsoft Teams users to message users in other Tenants by default. 

However, to prevent attackers from using Microsoft Teams in malware phishing attacks, Microsoft does not allow external users to send attachments to members of another tenant.

While playing with attachments in Microsoft Teams, Rauch discovered that when someone sends a file to another user in the same tenant, Microsoft generates a Sharepoint link that is embedded in a JSON POST request to the Teams endpoint.

This JSON message, though, can then be modified to include any download link an attacker wants, even external links. Even worse, when the JSON is sent to a user via Teams’ conversation endpoint, it can also be used to send attachments as an external user, bypassing Microsoft Teams’ security restrictions.

For example, the JSON below has been modified to show a file name of Christmas_Party_Photo.jpeg but actually delivers a remote Christmas_Party_Photo.jpeg………….exe executable.

Microsoft Teams JSON to spoof an attachment
Microsoft Teams JSON to spoof an attachment
Source: Bobby Rauch

When the attachment is rendered in Teams, it is displayed as Christmas_Party_Photo.jpeg, and when highlighting it, it will continue to show that name, as shown below.

Spoofing a JPEG file
Spoofing a JPEG file
Source: Bobby Rauch

However, when the user clicks on the link, the attachment will download the executable from the attacker’s server.

In addition to using this Microsoft Teams spoofing phishing attack to send malicious files to external users, attackers can also modify the JSON to use Windows URIs, such as ms-excel:, to automatically launch an application to retrieve a document.

Rauch says this would allow attackers to trick users into connecting to a remote network share, letting threat actors steal NTLM hashes, or local attackers perform an NTLM relay attack to elevate privileges.

“These allowed, potentially unsafe URI schemes, combined with the lack of permissions enforcement and attachment spoofing vulnerabilities, can allow for a One Click RCE via NTLM relay in Microsoft Teams,” Rauch explains in his report on the spoofing attack.

Microsoft not immediately fixing bugs

Rauch told BleepingComputer that he disclosed the flaws to Microsoft in May and June of 2022, and despite Microsoft saying they were valid issues, they decided not to fix them immediately.

When BleepingComputer contacted Microsoft about why the bugs were not fixed, we were not surprised by their response regarding the GIFShell attack technique, as it requires the device to already be compromised with malware.

“This type of phishing is important to be aware of and as always, we recommend that users practice good computing habits online, including exercising caution when clicking on links to web pages, opening unknown files, or accepting file transfers.

We’ve assessed the techniques reported by this researcher and have determined that the two mentioned do not meet the bar for an urgent security fix. We’re constantly looking at new ways to better resist phishing to help ensure customer security and may take action in a future release to help mitigate this technique.” – a Microsoft spokesperson. 

However, we were surprised that Microsoft did not consider the ability of external attackers to bypass security controls and send attachments to another tenant as not something that should be immediately fixed.

Furthermore, not immediately fixing the ability to modify JSON attachment cards so that Microsoft Teams recipients could be tricked to download files from remote URLs was also surprising.

However, Microsoft has left the door open to resolving these issues, telling BleepingComputer that they may be serviced in future versions.

“Some lower severity vulnerabilities that don’t pose an immediate risk to customers are not prioritized for an immediate security update, but will be considered for the next version or release of Windows,” explained Microsoft in a statement to BleepingComputer.

Source :
https://www.bleepingcomputer.com/news/security/gifshell-attack-creates-reverse-shell-using-microsoft-teams-gifs/

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)

Summary

The Distributed Component Object Model (DCOM) Remote Protocol is a protocol for exposing application objects using remote procedure calls (RPCs). DCOM is used for communication between the software components of networked devices.  

Hardening changes in DCOM were required for CVE-2021-26414. Therefore, we recommended that you verify if client or server applications in your environment that use DCOM or RPC work as expected with the hardening changes enabled.

To address the vulnerability described in CVE-2021-26414, you must install updates released September 14, 2021 or later and enable the registry key described below in your environment. We recommended that you complete testing in your environment and enable these hardening changes as soon as possible. If you find issues during testing, you must contact the vendor for the affected client or server software for an update or workaround before early 2022.

Note We recommend that you update your devices to the latest security update available to take advantage of the advanced protections from the latest security threats.

Timeline

Update releaseBehavior change
June 8, 2021Hardening changes disabled by default but with the ability to enable them using a registry key.
June 14, 2022Hardening changes enabled by default but with the ability to disable them using a registry key.
March 14, 2023Hardening changes enabled by default with no ability to disable them. By this point, you must resolve any compatibility issues with the hardening changes and applications in your environment.

Registry setting to enable or disable the hardening changes

During the timeline phases in which you can enable or disable the hardening changes for CVE-2021-26414, you can use the following registry key:

  • Path : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
  • Value Name: “RequireIntegrityActivationAuthenticationLevel”
  • Type: dword
  • Value Data: default = 0x00000000 means disabled. 0x00000001 means enabled. If this value is not defined, it will default to enabled.

Note You must enter Value Data in hexadecimal format. 

Important You must restart your device after setting this registry key for it to take effect.

Note Enabling the registry key above will make DCOM servers enforce an Authentication-Level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation.

Note This registry value does not exist by default; you must create it. Windows will read it if it exists and will not overwrite it.

New DCOM error events

To help you identify the applications that might have compatibility issues after we enable DCOM security hardening changes, we added new DCOM error events in the System log; see the tables below. The system will log these events if it detects that a DCOM client application is trying to activate a DCOM server using an authentication level that is less than RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. You can trace to the client device from the server-side event log and use client-side event logs to find the application.

Server events

Event IDMessage
10036“The server-side authentication level policy does not allow the user %1\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.”(%1 – domain, %2 – user name, %3 – User SID, %4 – Client IP Address)

Client events

Event IDMessage
10037“Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with explicitly set authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.”
10038“Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with default activation authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.”(%1 – Application Path, %2 – Application PID, %3 – CLSID of the COM class the application is requesting to activate, %4 – Computer Name, %5 – Value of Authentication Level)

Availability

These error events are only available for a subset of Windows versions; see the table below.

Windows versionAvailable on or after these dates
Windows Server 2022September 27, 2021KB5005619
Windows 10, version 2004, Windows 10, version 20H2, Windows 10, version 21H1September 1, 2021KB5005101
Windows 10, version 1909August 26, 2021KB5005103
Windows Server 2019, Windows 10, version  1809August 26, 2021KB5005102
Windows Server 2016, Windows 10, version 1607September 14, 2021KB5005573
Windows Server 2012 R2 and Windows 8.1October 12, 2021KB5006714

Source :
https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c