Automatic Visual Studio Update Reboot If Necessary

The patches for CVE-2020-0601, CVE-2020-0605 and CVE-2020-0606 caused a pending reboot on my build servers after updating visual studio.So my hope that the unattended visual studio updater script would be finished has not come true So I added a pending reboot detection: Additionally I wanted some more details in the event log regarding the version being updated and the version after the update. I added a few lines using the FileInfo class.Beside that I stop the build agent service during the update process, so that builds do not fail while MSBuild is not available. So here is the full script:

Machine Key Section validation and decryption key rotation on build

Rotating keys, making their lifetime shorter, decreases the attack window size and that is a good thing.For instance when using ASP.NET forms authentication the cookie can be encrypted when the `protection`-attribute is set to `all` – see here. I thought it would be handy to automate the rotation of keys during the publish phase of a web project. So here is a target file to be included into a web project.

Create a link to a UWP app to run as administrator

I’m a console enthusiast. I used to work with cmder over the last years. In general I was pretty happy. But the announcement of the Windows Terminal really caught my attention.One thing that annoyed me is the disabled checkbox, when creating a link, that does not allow to have it automatically prompt for elevation.So here is my work around. Open windows explorer and enter shell:AppsFolder into the address bar to open the apps folder:Drag‘n’drop the Windows Terminal to any folder.Now patch the lnk-file: Create another lnk file pointing to cmd {path to the first lnk file}, running minimized and having a nice icon.Now just use the second lnk file and it works as expected.Windows Terminal, PowerShell 6 and oh-my-posh up and running.

Scheduled task to automatically delete Fiddler HTTPS interception certificates

I really like Fiddler, the web debugger. I like TLS. I develop software. Therefore I find the interception and decryption of secure traffic very useful.On the other hand I’m into security for a few years now and from that perspective it is a man in the middle attack. So you might want to allow this for the shortest period of time.Fiddler installs a Trusted Root Certificate and dynamically issues certificates for the requested targets for the requested host names. This messes up the certificate store and under certain circumstances leaves risk for potential abuse of these certificates – which are trusted on your machine.So let’s do some automation to clean up. First a few lines of PowerShell:And Finally a scheduled task to import that runs on log on:HTH

Using the Windows Credential Manager from MsBuild

Today I needed to make a web service call with authentication from MsBuild. Of course storing the credentials in plain text is not an option.The Windows Credential Manager User Interface can be opened by running the command:control /name Microsoft.CredentialManagerThere is also a command line interface:cmdkey.exeAs the Windows APIs are not provided as wrapper through the BCL a NuGet package comes to help:nuget.exe install CredentialManagementFinally everything wrapped up in a MsBuild Task:

Handling Request too large and identify limits in ASP.NET

For security reasons request sizes are limited by default. This is configurable in the web.config file through the httpRuntime sections maxRequestLength attribute. The value is an integer and it’s default value is 4096 (KB) and therefor is 4,153,344 bytes or 4 MB. The configured values can easily be read using the .NET configuration API: If an request is larger than this value a HttpException is thrown when the HttpRequest properties Forms, Files or InputStream are accessed. The HttpException class has a property named WebEventCode which contains a value of the WebEventCodes lookup class: RuntimeErrorPostTooLarge which is an integer with the value 3004. If you catch this exception you can handle the error in your application code and for instance return a custom error message. But… When hosted in Internet Information Services (IIS) there might be another barrier: The request filtering module. This also has a section to configure the maximal length of a request using the requestLimits section and its maxAllowedContentLength property. By default this is set to 30,000,000 (bytes) and therefore is 29.297 KB or 28.61 MB. If this limit is hit IIS will return a HTTP error 404 with sub status code 13 with the reason phrase “Content Length Too Large”. The .NET configuration API refuses to load this section. And even if accessed raw using the system.webServer sections SectionInformation property and its GetRawXml method the possible inheritance is not reflected. So values configured on server and not on site level divergent from the default cannot be found here. IIS at startup create a configuration file located at *{windows drive}\inetpub\temp\appPools\{appPoolName}\{appPoolName}.config. The IIS application pool identity (the account running our web application) of course has read access to the file. To build up the path we need to get the application pool name at runtime. There is a server variable called APP_POOL_ID that will provide the neccessary information. The following code get the local overwritten values from the web.config, the server level configured, the default value or null if request filtering is not installed: At application startup the configuration can now be validated – request filtering schould always have a bigger value when you want to handle these kind of errors in your application code – and the values of a maximal request length can be read and possibly displayed.

Using credentials based on a SecureString that is disposed

Today I was building a credential store API. One implementation against the Windows Credentials Manager (CredMan), the other one persisting information in a database. Of course the data is not persisted in clear text. I use either the MachineKey functionality or a RSA certificate based encryption.So far so good, but I want the passwords to be secure in memory to. The .NET Framework already has a Type built in for that purpose: SecureStringThe SecureString class implements the IDisposable interface and having a property in a class of that type means losing control of the destruction.The implementation will return ICredentials instances to authenticate mostly web requests or provide proxy authentication. So I created a test to figure out how the combination of NetworkCredential and SecureString behaves. All green – It’s possible to use a NetworkCredential object that is constructed with a SecureString even after the SecureString has been disposed. Looking inside the credential object using redgate's Reflector reveals that NetworkCredential internally uses the copy method to clone the SecureString. When a normal string is passed to the constructor it is wrapped into a SecureString also.Sadly the NetworkCredential class does not implement IDisposable. So the issue is carried out to the user code.Keep in mind: When using NetworkCredential to call SecurePassword.Dispose() after the credentials aren’t required any more!