Being a Software Consultant - Microsoft Attack Surface Analyzer

I have been working as a software consultant for a long time now. During this time, I have to be at customers' locations adding new products, features and provide recommendations about their design. In order to do all of that, we first need to understand their current domain and eco-system of tools and applications. Many of these applications are custom-built while others are off the shelf toolkits, frameworks and software tools from various vendors. Most of the organizations which don't have Software Development and Design as a line departments don't have a very focused and streamlined approach to these toolkits, frameworks and tools. It is uncommon and rare to find out an individual who could give you an overview of the software eco-system.

During the early part of my professional career one of my mentors once said, "When you are thrown into a mud, don't just panic, just settle down first and then smoothly make your transition out" [I had to clean it up a bit for the respectable blog readers :)]. And this is so true as panicking in a situation like this only makes the situation worse. I have seen some consultants asking for the moon asking for the documentations about the current software design and domain in general. As I said, it is very rare to find such a thing expecting that this would be up-to-date is really an idealized view. Don't think employees would know better than consultants as they have been long enough in the organization. I have never seen this to be the case.

As a tech consultant, we are expected to know the technology bits required to work on the system but understanding the domain and host organization software eco-system is really necessary. Absence of people / documentation makes it really difficult. Organizations also suffer a lot because of this. We see multiple tools which seem to do the same thing (may be doing it differently). You see different design patterns followed in different parts of the same application. It makes it more challenging when development teams are geographically distributed as it affects the communication structure, which has an impact on design as we know from Conway's law, Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

So a convoluted mesh of software tools, frameworks and toolkits is a reality. Finding no navigation support in the systems is common. We need to learn how to deal with it as a technology consultant in order to be successful. Panicking is just not an option. As a software developer, we shouldn't be needing any document to understand the design as we know, Design lives in the code. In order to deal with this situation, I have learnt to follow some fixed steps when I step my foot in the doors of an organization. This includes making a list of the tools and frameworks used and having an externalized view of the software eco-system without first looking into the code.

Let's assume this is your first day in an organization. A software tool is thrown at you to look into that you would need to work on once you gets settled. Never just jump in the code and start looking at the classes and their relationship. This would be needed at later steps. First try to understand what is this tool consisted of? What does it do when it runs? What sort of changes does it make when installed on a client system? What components it loads when it is running. Is there any network activity involved? In order to answer these questions we need tools suitable. I recommend to be hands-on on major SysInternals tools, Profilers and DotPeek / Reflector. I have seen many developers running away from these tools and it appears that they would be turned into stones if they look at them (OK this is exaggerating, I admit :))

A few months back Microsoft has released one tool which should definitely draw our attention as a software consultant. This is Attack Surface Analyzer. The tool was introduced in August last year. It lets us take snapshot of system features including registry, drivers and other details. The recommended approach is to get the snapshot before we install the application being tested. We call it Baseline Snapshot. We then install the product and take a snapshot afterwards. The snapshots are created in the form of CAB files. The tool then supports comparing the CAB files and generates an HTML report which can be used to understand the changes caused by the software in the system. The report is also persisted automatically so we can later review the report.

Attack Surface Analyzer can be downloaded from Microsoft's download site. You can use the following link to download the tool:



The download consists of installation files for x86 and 64-bit operating systems. It also includes a read me file with the details of the tool. Running the download file would install the tool by running the setup program. We can select the folder where we want to install it.



Once installed, the tool is available in Windows Startup. Since the tool is supposed to collect sensitive information about the system, it needs to run with administrative privileges. Based on your system settings Windows UAC can ask about running with admin privileges.



As discussed above, the analyzer is used to run scan and saving the scan report as a cabinet file. The tool can then be used to run the comparison between any two files. Both of these use cases can be selected by selecting the appropriate radio buttons on the view. The idea is to run the scan first. Then install and run the tool running a scan second time.



Running the scan would collect data from the system. The list of details, being collected, is shown in the grid. It also shows the status of collecting each information. Once the collection is completed, the information is updated as Completed.



Once the run is completed, a cabinet file is generated in the selected folder with the specified name. It also generates a new sub-folder as data.



The data folder seems to have following details. The content of these files is based on XML. You can open the file and see the data about any particular details.



After complete scan and generation of these cabinet and data files, the view is updated showing with updated message. It also has information what you might need to do next. If it is baseline scan, you need to install and run the tool again and run a second scan. This scan is called Product scan.



Like the previous scan, we can generate the product scan in a selected folder. For my test scans, I have created them side by side in the same folder as follows:



Since we have both baseline and product scan and we have recorded the scan in the cabinet files. We can compare between these two scans by comparing these files. The tool supports this comparison. We need to update the selection to Generate standard attack surface report.



Clicking Generate button would load both cabinet files as specified in Baseline and Product Cabs. It then compares between both cabinet files. While generating report, it keeps showing the status message which keeps the user updated with each step running by the tool.



Finally it generates the comparison report with title Attack Surface Report. The report is opened in the default browser for the machine running the tool. It compares various aspect of the machine including content of Global assembly cache. We can argue that the report could have further details or the options could be selectable by the user and should be customized.



The report is also persisted for later viewing. The tool also creates a help file to look up the information about the comparison. You can see them persisted in the folder specified in the tool. Please notice the html files for report & help.

RBAC History, Terminologies & Standards

In the last few posts, we have been discussing about access control, specially Role Based Access Control. This access control is based on defining a set of rules and assigning a set of permissions and users to those rules. It is generally shortened to RBAC, which is generally pronounced as R-BACK. In this post we are going to discuss a little about the history and terminologies of RBAC, very briefly.

RBAC is a verb-oriented model which focuses on operations within a system and assigns rights on them by defining roles. These roles are then assigned to identities. A role is basically a semantic construct forming the basis of access control policy [Sandhu, Coyne, Feinstein, Youman]. For Windows world, Role can be a similar concept than group (specially for flat RBAC) but Role should be considered as a set of permissions. On the other hand, group should be considered as a set of users. Now this set of users can have permissions assigned to them. In that case, groups would behave like roles.

History of RBAC Research
Role Based Access Control (RBAC) was first formalized by Robert Kuhn and David Ferraiolo in 1992. In 2000, their model was integrated with Sandhu's framework, which was adopted as ANSI / INCITS standard in 2004 [NIST Reference]. In 2004, the standard received a ballott approval by International Committee for Information Technology Standards and adopted as INCITS 359-2004. In 2010, it was revised to incorporate features of Attribute based Access Control [ABAC].

Other useful reference: Sandhu, Farraiolo, Kuhn

RBAC Security Principles:
There are three RBAC security principles. They are least privileges, separation of duties and Data Abstraction. Here principles of least privilege is apparent, it recommends only those permissions should be assigned to a role which are required to perform the duties for the roles. Separation of duties is discussed later in this post, it is about activation of mutually exclusive roles. Data Abstraction suggests more abstract permissions and not read / write kind of permissions generally used by ACLs in operating system.

RBAC Components & Levels
RBAC can be divided into four levels. These levels are listed in the order of increasing functional capabilities. Each level adds exactly one new requirement to its lower level.

1. Flat RBAC / Core RBAC [RBAC₀: This is the lowest level of RBAC. This requires a many to many relationship between User and Roles, plus another many to many relationship between roles and permissions. The system must ensure that the user can use the permissions of multiple roles simultaneously. There should also be a user-role review process which allows to assign / remove any user from any role. This is also called RBAC₀


2. Hierarchical RBAC [RBAC₁]: This is the next level of RBAC. In addition to the requirements of flat RBAC, the system at this level should support hierarchical role models i.e. roles should be allowed to be defined in terms of other roles. In the role hierarchy, these roles can inherit the permissions of their parent role. This might also be an activation hierarchy where just using a senior role doesn't automatically use the permissions of a junior role unless specifically selected. The user-role review now include hierarchical roles as well. It must be made sure that there is no cyclic relationship.


3. Constrained RBAC [RBAC₂]: This level of RBAC enforces Separation of duties. This requires constraint in user - role assignment or activation of roles for a session. The system must enforce not using conflict of interest roles simultaneously. The conflict of interest might be taken care of by separation of duties amongst different roles. The separation of duties can be static or dynamic. In the static case, the separation of duties is taken care of roles assignment to the user. Any role which could cause a conflict of interest can't be assigned. In the case of Dynamic separation of duties (DSD), conflicting roles can be assigned to the user but the system must enforce that they can't be used simultaneously in the same session. These policies are inherited in the role hierarchies.
   
   Other constrained can be cardinality of roles which refers to the maximum number of users assigned to a role. Additionally, there can be constraint on pre-requesite role i.e. a user can be assigned a role only if it already has been assigned to some other specific role.
   
   The whole idea is to create sets SSD (Static Separation of Duties) and DSD (Dynamic Separation of Duties) sets and assign roles and roles hierarchies to it. For static separation of duties, a role cannot be part of another set once this has already been assigned to another set. For DSD, this enforcement takes place at runtime when the roles are being activated for a session.


4. Symmetric RBAC [RBAC₃]: This is the highest level of RBAC model. At this level, the system allows role - permission review. This review include the direct permissions assigned to the roles assigned to a user. This also include the permissions inherited from a junior role.

Note: Sandhu recommends separate admin roles and permissions which are separate (no inheritence) from regular roles and permissions. The admininstration can also have its respective ARBAC levels (0 - 3), (here A is Administrative).

Other RBAC Attributes
Standard NIST RBAC models don't put a constraint on the following RBAC attributes:

• Scalibility: The standard model doesn't put a constraint on the size of model. This can be in the sense of number of roles, number of users and permissions. This also doesn't include a role - permissions scalibility.


• Authentication: The standard model doesn't discuss authentication of user in the system. The standard doesn't either discuss how the users would be assigned to the roles.


• Negative Permissions: The permissions discussed in the model are positive permissions. Negative permissions are not considered.


• Nature of permissions: The standard model doesn't discuss the nature of permissions i.e if they should be fine grained or coarse grained.


• Administration and revocation: The model doesn't discuss how the users, roles and permissions are administered. Some example systems require a more administrative based centralized model. This can also be based on DAC (Discretionary Access Control) which allow the users to pass on the role permissions to other users.


• Role Engineering: There is no specification of how roles would be created and managed. This also doesn't provide any guideline how permissions are assigned to the roles. This should also include decommissioning of roles.


• Discretionary role activation: The standard model doesn't require role activation individually or a set of roles. The model just specifies the simultaneous use of multiple roles. The Level IV Separation of duties doesn't incorporate obligation constraints. Unlike this, the Level IV constraint prevents things from happening.


• Session Management: RBAC specifies sessions in core and constrained context. But how are these sessions created and managed? There is no reference about this in the original model and it is open to implementation.
  

Attribute Based Access Control [ABAC]
Original RBAC standard is not sufficient for dynamic attributes. These dynamic attributes might include time of day, market conditions, weather or any other dynamic condition which changes over time. It is very difficult to review ABAC system or how much is the risk exposure for a particular employee as the rules are dynamic in nature. The permissions to a user in a session would be the intersection of role-based permission rules and attribute-based permission rules. [Adding Attributes to RBAC [Weil, Coyne, Kuhn]]

Dynamic Parameterized Roles: Dynamic nature of the roles are important because RBAC enforces security on verbs. So users are allowed to perform some actions / operations but it is a matter of how much of these operations are they allowed to perform. This might depend on the time of day i.e. these operations are only allowed in a certain duration during the day.

Note: I have tried to summarize the discussion in the referenced papers. If there is anything wrong, I would be glad to correct it.

WCF Security - Service Authorization Manager

In the previous posts, we have seen two possible options of authorization / access control including PrincipalPermission and directly using ServiceSecurityContext for authorizing users from the same active directory domains. With PrincipalPermission() we need to provide the security logic on each service operation with an option of using PrinicipalPermissionAttribute. Using ServiceSecurityContext, we included the authorization logic in service operation code which makes it convoluted. What if we need to only authorize certain users for the service i.e. all operations of the service. The feature can be implemented by using the extensibility features in WCF. We can use ServiceAuthorizationManager for the same.

Based on Security Architecture document on MSDN, ServiceAuthorizationManager is used to perform two steps for the incoming message. The first step is Authorization Policies Evaluation Stage, Here It is used to evaluate authorization policies where claims can also be added to the evaluation context. Here external authorization policies can also be used. As the second step [Service Authorization stage], the authorization policies can be used to perform the actual authorization. In the document, the steps are specified as follows in the WCF pipeline:



ServiceAuthorizationManager is provided as follows:



As we can see that there are two overloads of CheckAccess() method. Additionally, there are two virtual methods CheckAccessCore() and GetAuthorizationPolicies(). If we dotPeek the code, we can verify the flow described by the MSDN document. As you can see that it iis first calling GetAuthorizationPolicies() and then after using the authorization policies to create a ServiceSecurityContext, it is using the CheckAccessCore() method. The default implementation of CheckAccessCore() is PERMIT ALL i.e. it returns true, we can override this to perform the required authorization.



In order to understand it further let us add a custom definition of ServiceAuthorizationManager. It is non-sealed so we can directly inherit from it and override the virtual members. Based on the code flow of CheckAccess() described above, we just need to override CheckAccessCore() and GetAuthorizationPolicies() methods. For now, let's just use the logic provided by the base class i.e. ServiceAuthorizationManager.

Now in order for the service to use this, we must add this behavior, let's update the App.Config. As you can see we are still using WindowsGroups as the principal permissions. We would be providing the actual authorization using the same groups.

In order to test that the service authorization manager is actually being used by the service. Add some breakpoints and execute the code, you should see that GetAuthorizationPolicies() is called first followed by CheckAccessCore() method.



Here we have used the same WCF Test Client as we have been using in the previous examples:



Now let us provide the same authorization logic we have provided in the last two examples. We only want subjects from Traders group to have access to our service. Since the same WCF pipeline is used for metadata requests as well, we need to first determine if this is such request. If so we can allow the operation. There is no user specific security information for metadata request including claims and domain groups. For other service operations as well, the header action is set accordingly.

Let's execute the code, as you can see the authorization logic is correctly being used.



Here we have provided the code for service level authorization logic. For more fine grained security based, we can use the request header actions.

Download

WCF Role Based Authorization using Principal Permissions for Windows Groups

In the last few post we have been trying to set the stage to start discussing about creating Identity aware application architecture using Windows Identity Foundation [WIF]. We have been going through these posts to ease ourselves into the technology. This post is also to set one step towards that direction. This is to discuss role based security outside the Identity and Claims world. Please remember that this is the most common way we have been implementing security authentication and authorization in our services specially inside the firewall in an intranet organization setup.

Let's consider our organization as a financial type of organization where we have different applications and services to help the employees carrying out their activities. One such users are traders. They execute trades which are then forwarded to any specific exchange for placement. We need to make sure that only traders are allowed to execute trade. One such way is to check at the service level if the requester is a trader and allow the operation only under such case.

In WCF scenarios for a Windows Active Directory based domains, users belong to different domain groups. These groups are used by applications to determine the user privileges before executing the actual operation. The same approach has been traditionally taken to implement security for our services. This is exactly what we would be trying to discuss in this post. For our organization, let us assume that all traders belong to Traders group.

Let's start by creating a WCF Service Library project, TradeExecutionServiceLib.



Now let's update the name of the service contract and the implementation to ITradeExecutor and TradeExecutor respectively. Doing it on the solution explorer level would ensure that the class names are updated inside their respective files. This should also update the service configuration in App.Config file.



Now let us update ITradeExecutor as follows:

Here we have also included a service operation, ExecuteTrade(). This is certainly very simple way on the service side for looking at the trades execution but this should be enough to understand the concept of role based security authorization in WCF, which is the purpose of today's post. This requires the instrument's symbol and quantity to be passed as input parameters. Now we update the service implementation as follows:

The implementation is just writing the details about the symbol and traded quantity on the console. Now let us add authorization code. We need to make sure that only traders belonging to Traders group have access to ExecuteTrade() operation. In WCF and code access security scenarios, this can easily be implemented using PrincipalPermission attribute from System.Security.Permissions namespace in mscorlib assembly. We can also directly use PrincipalPermssion class in a non-declarative way.

Decorating Service Operations with PrincipalPermissionAttribute
One way to authorize user's role is to decorate the operation with PrincipalPermissionAttribute. Here Role would mean the Windows group we are specifically looking for. Now this becomes the responsibility of runtime hosting the service to ensure that the user of the service is a member of the specified group and deny access otherwise.

Now we need to test if the authorization logic is actually working. Since this is a very simple service, we don't need to build a special client just to test the service. Here we can simply use WCF Test Client installed using the framework. We don't even need to host this as Visual Studio would automatically host it to the default WCF Service Host. run this with the default service configuration. Just make sure that you have the service project set as start up project in the solution. Since we have only one project in the solution, this is the default case here. You should see the following toast appear in the system tray when you run the service.



If you double click the icon on the tray, you should see that service is hosted and the status should show as Started.



This should also launch WCF Test Client with the operations listed on the service.



Let us provide the input arguments for ExecuteTrade operation and hit Invoke. Since were debugging it, we should be able to see the following security exception in the visual studio editor:



If you continue the execution then you should see the following on the WCF Test Client side which just shows the client that there is something wrong with the request. When we write our custom clients we should be handling this case more gracefully showing the user the exact cause of the error or how to request permissions if he is a legitimate user of the service.



Since the service operation requires the user to belong to a certain role, it blows up as there is no such membership for the requesting user. Not even such a group exists on the machine [CHEETA]. To keep it simple, let us create a Windows Group using the Computer Management tool as follows:



Let's add the user (requester) to the Traders group now. See the highlighted information requiring the user to login again in order for the changes to take effect.



Now let us update ServiceModel section of the service configuration in App.Config to use Windows security. Here we have updated the binding to net TCP. We have also updated authorization behavior use Windows Accounts.

In order to test that the logic is actually working let us debug the code. Let us insert a break point on the ExecuteTrade operation side and run the service. As described previously the service is hosted and WCF Test Client is launched, we provide the same input arguments as before ("MSFT" and 100) and invoke service operation. since the user has such membership now, the security authorization logic calls the method and hits the break point.



The class hierarchy of PrinicipalPermissionAttribute is as follows:



Non-Declarative Permission Demands
In the above example we provided the required membership requirements by adding PrinicipalPermissionAttribute to the operation contract implementation. The same behavior can be achieved by doing the same thing in the code. The unauthorized access would be determined by WCF Service pipeline and an exception would be generated which would result in a fault for the user. In the below code, we are just updating the code to demand membership using the same Principal Permission, but using code.


The definition of PrincipalPermission is as follows:



If we look at the definition of PrincipalPermissionAttribute, it is using the same IPermission.



Download Code

XPATH Injection

Getting user input and using it directly for some verification is always dangerous. When developers discuss about injection attacks, they generally talk about SQL Injection.

These injection attacks can be targeted to any query language. One of them is XPATH. XPATH expressions are used to query XML documents. They provide easy way to access the desired contents avoiding loops and programming language specific constructs.

These kind of attacks can be minimized if direct use of user input to formulate a query is avoided. This is because the attacker might inject the malicious information which allow him to pass the authentication.

Let's see how an attacker uses this.

We assume a typical Login form which has two text boxes. txtUserName and txtPassword and a btnLogin button. The user is supposed to provide his credentials and hit Login button for verification.

The user data is maintained in the form of XML.


<users>
<user>
<username>Shujaat</username>
<password>Siddiqi123</password>
</user>
<user>
<username>Rose2009</username>
<password>MyP@ssword765</password>
</user>
...
</users>


Now the XPATH expression constructed for user verification is as follows:

string query = "/Users/User[UserName='" + txtUserName.Text + "' and Password='" + txtPassword.Text + "']"


Now a user can easily pass through the security check if he enters in either of the text boxes data like this:

txtUserName: ' or 1=1 or ''='
OR
txtPassword: ' or 1=1 or ''='

We assume he enters this in the txtUserName and txtPassword is provided with any text e.g: 'shujaat'.

Now the variable query would be assigned with the following string query:
"/Users/User[UserName=' ' or 1=1 or ''='' and Password='shujaat']".

Since this expression would satisfy all nodes in the document. The SelectNodes() method on XMLDocument object would give the list of nodes with all the nodes in the document (Microsoft.net).

The attacker is finally in the system freely! :)

So be careful when you construct XPATH expressions from user data, otherwise...

Microsoft Project Zermatt (Claims based security in .net)

Today the most important topic is security whether it is security of the
people's life or it is about their identity. For life saving, we have law
enforcement agencies. For security of identities, different mechanisms do
exist. Microsoft Code Name Zermatt is a step towards the same direction.

In many different applications and APIs there are different ways to build
identity support. Even with .net identity can be seen in different places.
When we have security so widely spread, it is difficult to maintain it. And
that is where hackers and phishers work hard to find a way to get some
place into your application.

Project Zermatt is about developing CLAIMS AWARE applications in .net
environment. It is designed to be simple to understand and open to use.
According to Microsoft, You don't need to be a security expert to implement
security based on Zermatt. A developer should be able to implement its
design based on Zermatt.

Microsoft is talking about identity providers everywhere. In SQL Server it
is doing that with addition of EKM i.e. Enhanced Key Management. Like
there, In Zermatt it has option to add custom identity providers.They are
also referred to as STS i.e. Security Token Services. It provides security
by providing a new CLAIMS MODEL including API support to build custom STS.
These STS implement WS-TRUST protocol.

From the very start of this Project, Micrsoft wanted it to support both B2C
(Business to Consumer) and B2B (Business to Business) Model. For B2C, it
should support ASP.net based application and for B2C, we mean supporting
WCF based applications.

For building Zermatt based applications or services you need to have .net
framework 3.5.

With Visual Guard, People came to the idea of centralized security. But
still at the time of mergers and acquisitions, it is very difficult to
maintain that idea of centralized security and developers had to look at
two different places to verify the identity of a user. By using Zermatt
across the industry, people will no more have this problem. So Zermatt is
towards a step for providing EXTRA FEDERATION for security.

To understand Zermatt first we need to understand what is CLAIMS BASED
security model? This is becaue it is the essence of Zermatt. for claims
based identity mode, user comes with all the information related to his
identity. Just by looking at this identity information user is
authenticated. Remember that this list of claims is also called SECURITY
TOKEN. They are generally signed by issuing authority to provide legitimacy
to the user.

For claims based security model a user needs a list of claims in order to
be authenticated by application (The application doesn't need to receive
username and password any more). The identity of a person is identified
through these claims. These CLAIMS are provided by some AUTHORITY which
have been assigned this role. So based on this discussion, we have
identified three roles.
1. User
2. Claim provision authority
3- Application

These three roles are named as CLIENT, ISSUING AUTHORITY and RELYING PARTY
(also called CLAIMS AWARE or CLAIMS BASED application) respectively in the
context of Project Zermatt. The issuing authority uses SECURITY TOKEN
SERVICE (STS) to provide tokens to clients. You can use built-in or custom
STS. There is complete framework support provided with Zermatt to create
your custom STS. The clients may be smart (active) or Browser based
(passive) clients.

Microsoft has used several WS-* standards to implement Zermatt for smart
clients. They are as follows:

WS-METADATAEXCHANGE:
This is used to retrieve policy by the Relying Party.

WS-POLICY
This is the standard for defining the structure of the policy.

WS-TRUST
This describes the working between smart client and Issuing Authority. This
deals with requesting and issuing security token.

For browser based applications these WS-* based standards are replaced by
HTTP GET, POST and REDIRECT.

In order to understand the tokens issued by the Issuing Authority, the
token must be in a standard format. This has been made easier by adopting
SAML (Security Assertion Markup Language) for security tokens by most
STS(s). SAML is a standard XML standard to represent claims. With this XML
based tokens platform independence for security can be achieved far easier.
This platform independence can appear even bigger if you include the
feature of Single Sign On with it.