When we need to deploy an application to Azure from VSTS (Visual Studio Team Services), we use the Azure tasks prepared by Microsoft. These tasks require a contributor account in Azure AD to make changes to your subscription. As this account is not a regular user account but an application account we call it a Service Principal. A very basic build pipeline might look as follows:
The “Azure App Service Deploy” task is an example of a task that will use a Service Principal account to update your App Service in Azure. VSTS makes it easy to create the Service Principal account; it also automatically assigns a contributor role in your subscription to this newly created account. When you want to have full control over your Azure AD you may manually create an App Registration (another name for the Service Principal) in the portal and give it the required rights. You will also need a key to authenticate the service in Azure:
In the next step, you create a new Azure Resource Manager Service Endpoint, providing all the collected information:
While preparing slides and demos for the upcoming BSides Warsaw conference, I spent some time digging through the code of the old ASP.NET Crypto stack. In case you do not remember, six years ago researchers reported multiple cryptographic design flaws in ASP.NET. One of the critical issues was that ASP.NET did not authenticate ciphertexts. Thus they were vulnerable to the padding oracle attack. Microsoft learned its lesson and rewrote the crypto stack in ASP.NET 4.5. If you want to find out more, have a look at those three excellent articles by Levi Broderick: Part 1, Part 2, Part 3. As I plan to demo the padding oracle attack during my presentation I wanted to restore the old behavior using the latest version of the ASP.NET framework. In this post, I am presenting how I achieved that. But to watch the live demo, I invite you to come to my presentation at 10:00, Saturday, October 14th :).
Always Encrypted is a feature of the SQL Server 2016/Azure SQL which allows you to take full control over the encryption process of the sensitive data stored in your SQL databases. Thanks to this mechanism the encryption key is stored only on the client side and is never revealed to the SQL Server. In consequence, data traveling from the server to the client is also encrypted (although I would not rely too much on this fact and always use encrypted connections to the SQL Server). That is a very different approach to Transparent Data Encryption or Cell-level Encryption, in which it is the server role to encrypt/decrypt data received/sent to the client. Server-side encryption is completely transparent to the client and does not impact the way the client builds SQL queries. In Always Encrypted model, any query against an encrypted column will perform comparisons on byte arrays of cipher text. As you can imagine this raises some challenges when building a data model. In this post, I am going to cover some details of how the Always Encrypted feature is implemented and, hopefully, help you use it effectively.
Each build and release definition in TFS has a set of custom variables assigned to it. Those variables are later used as parameters to PowerShell/batch scripts, configuration file transformations, or other tasks being part of the build/release pipeline. Accessing them from a task resembles accessing process environment variables. Because of TFS detailed logging, it is quite common that values saved in variables end up in the build log in a plain text form. That is one of the reasons why Microsoft implemented secret variables.
The screenshot below presents a TFS build configuration panel, with a sample secret variable amiprotected set (notice the highlighted padlock icon on the right side of the text box):
Once the secret variable is saved, it is no longer possible to read its value from the web panel (when you click on the padlock, the text box will be cleared).
And this is how the output log looks like if we pass the secret variable to a PowerShell script and print it:
Let’s now have a look where and how the secret variables are stored.
Recently, the idea of protected variables in TFS struck my attention and pushed me to do some more research on how exactly those variables are stored. I hope I will write a separate post on that subject, but today I would like to share with you a small trick I use whenever I need to work with managed application traces (and TFS is one of them).
On Windows, when I want to know how things work internally, I usually start with procmon. Seeing which paths and registry keys are accessed, combined with TCP/IP connections is often enough to get an idea where to put breakpoints in further analysis. My TFS investigation was no exception to this rule. I collected a trace while saving a protected build variable – this is how such a variable looks like (in case you are interested :)):
TestLib, Version=188.8.131.52, Culture=neutral, PublicKeyToken=769a8f10a7f072b4
If the above line means anything to you, you are probably a .NET developer. You also probably know that the hex string at the end represents a public key token, which is a sign that the assembly has a strong name signature. But do you know how this token is calculated? Or do you know the structure of the strong name signature? In this post, I will go into details how strong naming works and what are its shortcomings. We will also have a look at certificate-based signatures and, in the end, we will examine the assembly verification process.
Process Monitor (or procmon) is a very powerful diagnostics tool for Windows. I remember when I first run it, a few years ago, I was overwhelmed by the number of events happening on my system each and every second. Thankfully, procmon has features to help you deal with this bulk of data, including filters, highlighters, and bookmarks. But sometimes even a filtered log is not enough to find the root cause of a problem. On such occasions, other log sources may contain the missing bits of information. We only need to correlate them with our procmon trace. And today, I would like to show you how I do that.
Application Insights is a performance monitoring service, created by Microsoft and available on Azure. It gives you space to store the performance metrics and logs of your application (1GB for free!), as well as functionalities to search and manage them. In this post I am not going to present you the whole platform – Microsoft already did it in the Azure documentation, but rather focus on an element of the log collection, named dependency calls tracking. I did some analysis on the Application Insights libraries, and decided to publish my findings, in the hope that the results might interest some of you too.
Dependency calls are requests, which your application makes to the external services (such as databases or REST services). When this telemetry type is enabled, all the dependent actions form a timeline within the scope of the parent action. Using this timeline we may easily verify whether the delay in our application is caused by an external service, or the application itself. Let’s analyze in detail how this data is collected.
The title mentions ASP.NET 4.5.x, but the encryption algorithm is exactly the same in ASP.NET 4.6.x. It won’t work however in earlier versions of ASP.NET.
Some time ago I published a post entitled “Decrypting ASP.NET identity cookies”. In that post we wrote a Python script to decrypt ASP.NET Identity cookies. You could have also learnt how the derived keys, used to encrypt those cookies, are calculated. If you are interested in details, please have a look at that article. But to summarize, the following steps are performed by ASP.NET:
- Extract the encryption and the validation key from the web.config file
- Calculate the derived keys using the SP800-108 specification, with the context and the label taken from an adequate Purpose class instance
- Validate and decrypt the cipher
The above procedure applies not only to the cookies decryption, but also to many other cryptographic operations, such as ViewState encryption, Forms Authentication, Anti-Forgery tokens creation etc. However, there is still a missing gap in the presented flow. What if the encryption and the validation keys are not explicitly set in the web.config file? Today, we will answer this question.
In today’s short post I would like to present you a new tool in my diagnostics toolkit: wtrace, and an update to procgov (or Process Governor). Let’s start with wtrace.
On Linux, when I need to check what a given process is doing, I usually use strace. I was always missing such a tool for Windows. We have procmon (which is great), but it does not run in a console, and thus can’t be used in the command line scripts, or on a Nano server. This might change soon, as in one of the latest episodes of the Defrag Tools show, Mark Russinovich shared the plan of releasing the procmon version for Nano. Till then though we don’t have much choice when it comes to real-time tracing. You may think of xperf or wpr, but those tools only record ETW events for further analysis. However, we may use the same ETW events in a realtime session, and print information they provide to the console output. This is how the idea for wtrace was born in my head. Few weeks ago Sasha Goldshtein released another tool for ETW processing named etrace, which basically does something very similar and has many interesting options. I decided to publish wtrace nonetheless, as my point was to create a tool with an extremely simple interface. Wtrace is collecting only a small subset of events (FileIO, TcpIp, Process/Thread Start) from the kernel provider. It may either start a process, or trace one that is already running. At the end of the trace it also shows some statistics (unless you use the –nosummary switch). Trace session will end either when you press Ctrl+C, or when the traced process terminates. Events are printed in the console window. An example session might look as follows: