CVE- 2020-1350 aka SIGRed

A new critical CVE is in the wild and actively being exploited. As below:

A remote code execution vulnerability exists in Windows Domain Name System servers when they fail to properly handle requests. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account. Windows servers that are configured as DNS servers are at risk from this vulnerability.

To exploit the vulnerability, an unauthenticated attacker could send malicious requests to a Windows DNS server.

The update addresses the vulnerability by modifying how Windows DNS servers handle requests.

Advise is to update ASAP. The workaround can be found here: https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

A powershell command is available to disable large DNS requests and responses

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters" -PropertyType DWORD -name TcpReceivePacketSize -Value '0xFF00' -Force Restart-Service "DNS Server" -Forced

Ideally, the patch needs to be applied as soon as possible.

More can be found here https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/

Migrate your Unifi Cloud Controller

Moving Unifi Cloud Controllers can be difficult. You may need to do this because you are:

  • Hosting on an old operating system
  • Moving platforms
  • You want to change the FQDN or inform address
  • Like making life hard for yourself

There is no defined way on how to do this – however, we’ve found a way that works quite well.

Scenario

We had a very old Ubuntu server running Unifi Cloud Controller. The version had a few issues, specifically around mongodb database packages. Instead of trying to fix this, we decide to move to a new server based on Debian 9.5.

We tried simply standing up another server with Debian 9.5 installed with a backup of our Unifi Cloud Controller applied. We then change our DNS to point from the old server to the new server.

This didn’t work

We got many issues around too many devices being connected at once. This is the new DDoS protection built in to the Cloud Controller. Also, some devices simply refused to connect to the new server, even though everything was essentially the same.

The Correct Way

We found the correct way to do this is to migrate your sites. In order to do this you need to have your second server built. We configured a new server, again on Debian 9.5 on AWS.

Old Server: wireless.contoso.com
New Server: unifi.contoso.com

Now you are ready to migrate your sites.

  1. Log in to your old controller and select the site you want to migrate
  2. Select settings -> Site and click Export Site
  3. You will first need to download the settings from this site and apply it to your new server
  4. Once this is done, select next confirming you have applied the settings, then set the FQDN of the new server and the devices which you want to migrate
  5. You will now see the device show up on your new Unifi Controller – note they will re-provision and anything connected will be briefly disconnected
  6. The last option is to forget the device on the old controller. I wouldn’t do this unless you are sure. Make sure your device is working as expected on the new server before the old device is removed.

There you go – you’ve done it.

2019 Storage Spaces Write Performance Guide

This guide was posted on the Microsoft forms.

RS5 (Build 17763, Windows 10 1809) update brings improved parity write performance to storage spaces. The improvement comes from being able to bypass the parity space write cache for full stripe writes. Previously created storage spaces will also benefit from these improvements (once the storage pool is upgraded with Update-StoragePool). For best results, you will need to create a new storage space with specific interleave size.

Step 1

Upgrade your storage pool to the latest version.

Get-StoragePool <NameOfPool> | Update-StoragePool

Confirm

Are you sure you want to perform this action?

This will upgrade the StoragePool “TestPool” to the latest version. This is an irreversible action.

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is “Y”):  

Verify that your pool is at least at “Server 2019” version or later

Get-StoragePool | ? IsPrimordial -eq $false | ft FriendlyName,Version

FriendlyName Version

———— ——-

NameOfPool   Windows Server 2019

Step 2

 Create a new parity virtual disk, with an interleave size of 32KB, 3 columns. This maximizes your flexibility in adding capacity to your space, and ensures that the data stripe size is 64KB, which will match the NTFS allocation unit (cluster) size of 64KB that you will use in the next step. (If you use the Storage Spaces Control Panel UI to create the space, it will typically have an interleave size of 256KB and an NTFS cluster size of 4KB, which doesn’t guarantee that all writes will be aligned to data stripe boundaries)

New-VirtualDisk -StoragePoolFriendlyName <NameOfPool> -ProvisioningType Thin -Interleave 32KB -FriendlyName FastParity -Size 1TB -ResiliencySettingName Parity -NumberOfColumns 3

Step 3

Go to disk management, initialize the disk corresponding to the newly created virtual disk, and format it with NTFS (or REFS) filesystem with an allocation unit (cluster) size of 64KB.

Step 4

Verify that copying large files to this volume is fast. Provided you are copying from a source that is *different* from any of the virtual disks in the storage pool, you should be able to achieve a write performance that is close to 2x the write performance of the slowest physical disk in your storage pool. With typical consumer SATA hard disks, if your source is sufficiently fast (e.g. internal SSD), you should be able to hit 200MB/sec for copying large files.

You can use the performance monitor (perfmon.exe) to verify that your new virtual disk has a high “Write Bypass %”. When correctly configured, you should expect this value to be >99%. The  Counter set name is “Storage Spaces Write Cache”

Parity (Single disk failure resilient) recommended configurations for Archival workloads

Storage Spaces Interleave Size

Number of Columns

Data Stripe Size

FileSystem

Allocation Unit Size
(Cluster Size)

Expected Write Performance
(Multiples of single disk performance)

32KB

3

64KB

NTFS

64KB

2x

32KB

3

64KB

REFS

64KB

2x

16KB

5

64KB

NTFS

64KB

4x

16KB

5

64KB

REFS

64KB

4x

Dual Parity (Two disk failure resilient) recommended configurations for Archival workloads

Storage Spaces Interleave Size

Number of Columns

Data Stripe Size

FileSystem

Allocation Unit Size
(Cluster Size)

Expected Write Performance
(Multiples of single disk performance)

16KB

7

64KB

NTFS

64KB

4x

16KB

7

64KB

REFS

64KB

4x

Sharing error OSE204 from OneDrive

If you’ve tried sharing a file outside of your organisation team share in OneDrive to anonymous parties, you might run in to a problem with sharing settings.

This is not easily solvable at first. There are a number of settings in Office 365 which can affect this, from:

  • Office Active users page, you can select individual users, select One Drive and see the sharing access they have
  • One Drive Admin: on the sharing page, there are a number of options here
  • SharePoint Admin: Again, there are a number of options here.

Make sure you check those above sections to ensure the correct settings are set. If you still cannot share the files, you will need to connect to SharePoint Online via power shell.

  1. Make sure the power shell command is installed:
    Install-Module -Name Microsoft.Online.SharePoint.PowerShell
  2. Connect to your instance
    $adminUPN="<the full email address of a SharePoint administrator account, example: jdoe@contoso.onmicrosoft.com>" $orgName="<name of your Office 365 organization, example: contosotoycompany>" $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password." Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $userCredential
  3. Set the permissions on your site
    set-sposite -identity 'https://contoso.sharepoint.com/sites/Sales' -sharingcapability ExternalUserAndGuestSharing

The above should do the trick. Just note that it does take some time to take affect.

See: Sharing Errors

Sopho: Patch your firewalls – zero day runs wild

Over the weekend, Sophos announce it had released a hotfix for Sophos XG firewalls. This hotfix patched an SQL injection attack which allowed attackers to download payloads to the device.

It looks like the hashed usernames and passwords have been stolen from the XG devices. This means all XG owners should reset the passwords for administration and any local VPN users as well.

It appears the attack was done either on the admin portal (port 4444) or the user portal (port 443). Normally the administration portal is closed on the WAN, however, it is normal practice to have the user portal exposed on the WAN.

If your firewall has been compromised, Sophos recommends these steps

  1. Reset device administrator accounts
  2. Reboot the XG device(s)
  3. Reset passwords for all local user accounts
  4. Although the passwords were hashed, it is recommended that passwords are reset for any accounts where the XG credentials might have been reused

We are awaiting further information from Sophos.

dpkg-divert: error: rename involves overwriting

When upgrading from Ubuntu 16.04 to 18.04 LTS you may recieve this error. Use the following command to manually move the file

sudo mv /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.bak

Now run the upgrade process again

sudo apt upgrade

If this does not work, try

sudo apt -f upgrade

Teams – new features for April 2020

Microsoft is about to roll out new features for Teams.

You likely saw last week that Microsoft introduced new backgrounds for meetings, likely to combat Zoom’s popularity. Microsoft really needs to add more than 4 people on screen at one time, but we hear this is coming soon.

New features coming this April:

  • Raise hands in meetings – I hope this extends to live events so we can have more than one person on screen able to grab control
  • Multi-chat window
  • End meeting for all participants – this has just been release
  • More settings for organizers once a meeting is in progress
  • Downloading of a participant report once a meeting has finished
  • New policy to enforce lobby settings for external users
  • New policies around creating and joining meetings. You will be able to stop everyone being able to create meetings. If the user does not have the create meeting option, when they join meetings the meeting will not start until someone with this privilege joins

And finally coming for May 2020 we have more than 4 people on video within a Teams meeting.

Full details:

We are increasing the number of participants who can be viewed simultaneously on the Teams meeting stage from 4 to 9. This new experience optimizes for attendees who have enabled video and places the remaining audio-only participants below the meeting stage. To provide a high audio and video quality experience, the layout logic will consider user bandwidth and alter the number of videos shown to provide the best meeting experience. We’ll be gradually rolling this out to customers near the end of April and expect the rollout to be completed in early May.