Security Vulnerability in Universal Dashboard Premium\Enterprise

Please read the below bulletin. We have identified and resolved and issue in UD Premium\Enterprise that will require you to upgrade your dashboards.

3 Likes

Mad respect for the honesty dude, appreciated!

1 Like

@adam
I agree with @BoSen29, mad respect! Thank you for being transparent on this issue and making everyone aware. More companies need to follow suit.

With that being said I attempted to install version 2.9 on my test box, and I am getting the below error.

Am I doing something wrong?

Thanks,
Guy

3 Likes

@guy

I just tried again myself and it looks fine here. Look like I’m running PSGet 2.1.2. It could also be a PS Gallery thing where it hasn’t quite published it to all regions.

PS C:\Users\adamr> install-module universaldashboard -scope currentuser -force -acceptlicense                           PS C:\Users\adamr> Start-UDDashboard -Port 10000                                                                        
Name        Port Running DashboardService
----        ---- ------- ----------------
Dashboard0 10000    True UniversalDashboard.Services.DashboardService


PS C:\Users\adamr> Invoke-WebRequest 'http://localhost:10000/api/internal/component/terminal' -Method POST -Body "dir"
Invoke-WebRequest : The remote server returned an error: (404) Not Found.
At line:1 char:1
+ Invoke-WebRequest 'http://localhost:10000/api/internal/component/term ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS C:\Users\adamr> Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   3.1.0.0    Microsoft.PowerShell.Management     {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con...
Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...}
Script     1.3.1      PackageManagement                   {Find-Package, Find-PackageProvider, Get-Package, Get-Pack...
Script     2.1.2      PowerShellGet                       {Find-Command, Find-DscResource, Find-Module, Find-RoleCap...
Script     2.0.0      PSReadline                          {Get-PSReadLineKeyHandler, Get-PSReadLineOption, Remove-PS...
Script     2.9.0      UniversalDashboard                  {Add-UDElement, Clear-UDCache, Clear-UDElement, ConvertTo-...


did you try

Update-Module UniveraslDashboard -AcceptLicense

Sometimes PS is picky when you already have a module installed

Hi @Jacob-Evans

Thanks for the input! I did originally try and run Update-Module -Name UniversalDashboard -AcceptLicense and received the same error as the one in the screen grab in my original post.

I did get it installed using a work around. I downloaded the module on a different box and then copied it over to my test box. I’m not sure what the issue is but it must be caused by something local on my test box. Since I was able to download the latest module without issue from other machines on the same network.

Thanks again!
guy

1 Like

Hey @adam thanks again for bringing this to our attention.

I am trying to load up 2.9.0 in an Azure Web App and I just keep getting 500 errors. I noticed the webconfig is different from 2.8.3 to 2.9.0 where the process path in 2.9.0 is PowerShell.exe and previous versions was a universaldashboard.server.exe stored in the net472 folder.

is there something im missing?

Read this topic

this change now support people who wants to run their dashboard using powershell core Vs. windows powershell so the web.config entry drive which powershell platform you would like to run your dashboard.

Thanks @wsl2001 that did the trick getting past the loading of the dashboard.ps1 but now im onto a new issue where the dashboard wont load at all in 2.9.0 in an Azure Web App with Authentication enabled :expressionless:

I’ll open a new post for that.

thanks

I also had to configure the web.config ([2.9.0] Broken Page - Missing files? [RESOLVED]). On top of that I got the following error:

Start-UDDashboard : The Win32 internal error "The handle is invalid" 0x6 occurred while setting character attributes for the console output buffer. Contact Microsoft Customer Support Services.

To solve that issue, i had to set to following configuration on top of the dashboard.ps1

$WarningPreference = "SilentlyContinue"

This probably has something to do with -AllowHttpForLogin. I leave HTTPS to Azure and not to UD. I am in the understanding that should be sufficient. If this is not OK, please let me know.

I think the problem can also be solved by using stdoutLogEnabled=“false” in the web.config

Ahh thank you for posting that - I was getting the same error when running UD in an Azure Web App.

Just stumbled into another error - The underlying connection was closed: An unexpected error occurred on a send. :expressionless:

[Edit] - I had to add this as well to the top of my dashboard.ps1

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

between 2.8.X and 2.9.0 there seems to be some fundamental changes that impact how UD runs in environments like Azure Web App… i’m scared to move my docker containers :expressionless:

I am not sure that UD is responsible for this TLS error, @adam maybe you can answer that and if this is the case the documentation should point to the TLS 1.2 requirement.
But I am aware that Microsoft is doing a lot in the background in order to remove old ciphers and for this reason it can also be a TLS 1.2 mandatory option on Azure Web App

UD doesn’t do the TLS\HTTPS when running in Azure\IIS. Azure Web Apps and IIS provide the TLS support since they are a reverse proxy over the top of the UD Kestrel web server.

There might have been some circumstance where that SecurityProtocol setting was being set but I’m not aware of where that would be. Since it’s a process wide setting, it could have been anything in the UD process setting it.