Archive for January, 2010

Trust. It is a Two Way Street

Jan 20

One of the most common flaws I am seeing in applications is the lack of mutual authentication. Most systems authenticate that the user connecting to their system is a valid user. What is lacking is that the client verifies that it is connecting to who it thinks it is connecting to.

One of the big examples of this is WiFi. If I have a wireless router named “myrouter” and set my laptop to use that router things work great. If I go down the street and someone else has a router named “myrouter”, my laptop automatically tries to connect to it. This is because the WiFi implementation does not verify that I am connecting to who I think I am connecting to.

This happens a lot on the service level of applications. The client app resolves a DNS name like www.myservice.com to it’s IP address and then sends over some form of authentication. Now what happens if I somehow manage to change the DNS record for www.myservice.com to point to my IP address which contains a service with the same name and same methods exposed to it? The client will connect and divulge its authentication data to this fake service. I can now use the authentication data that you gave me authenticate against the real system and do whatever nefarious things I desire.

The solution for this is for clients to verify that the service it is talking to is actually the service you want to be talking to. This is best accomplished by using some form of shared secret. This takes on many forms but a few methods:

  1. Ask the server to answer a shifting question. i.e. ask the server to hash a certain string. If the hash the server returns matches what you expect then the server might be the one you want (or an attacker managed to replicate the algorithm)
  2. Use windows authentication. For WCF the mutual authentication is implied in this case.
  3. Use certificate authentication. This is the best way to do this task but can be a pain to implement.
Filed Under: Security

Team City Build Versioning

Jan 19

One of the great things about continuous integration is that we can increment our assemblies version number with each build. For our project we also apply a label to our source code repository every time we build a deployment package. This allows us to get the version of source code from the exact point in time that the msi was built.

One of the issues we ran into was that we have three build configurations:
1. “CI” This gets run on every checkin of code
2. “Deploy – ALPHA” This is run manually to deploy to our alpha test environment
3. “Deploy – ALPHA & BETA” This is also run manually and this deploys the same version to both the alpha and beta test environments

The issue we ran into is that each configuration has its own build number that is incrementing so if we ran “Deploy – ALPHA” 10 times we would have v 1.10.0.0 in ALPHA. If we then ran “Deploy – ALPHA & BETA” for the first time suddenly ALPHA now has v1.1.0.0! Obviously this is not very intuitive. In the end we added in the version number from our source code repository into our build numbers for both deploy configurations. Now we get build numbers like this: 1.46347373.0.0

The way we did this was by using the vcs variable in team city: 1.{build.vcs.number.TheNameOfVCSRoot}.0.{0}. The last digit is still an incrementing counter in case you re-run the build that something still increments even though the version in source control has not changed.

Filed Under: General

Remote MSI Execution

Jan 18

One of the things we have started doing as part of our process is having a build script that creates our deployment package in an automated fashion. We then tied that into our build server so that from one click anyone could create the package. The issue is that we have several test environments and copying the setup.msi file to multiple servers and installing it is a time consuming pain. To streamline our deployment we created a vbscript (yes, it was painful) to remotely uninstall previous versions and then install the new version of the msi. Here is the script currently:

strComputer = “mytestserver”

Wscript.Echo “Getting WMI Object”
Set objWMIService = GetObject(“winmgmts:” & “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)

Wscript.Echo “Finding Previous versions”
Set colSoftware = objWMIService.ExecQuery (“Select * from Win32_Product Where Name = ‘My First Setup Project’”)
For Each objSoftware in colSoftware
    Wscript.Echo “Uninstalling a previous version”
    objSoftware.Uninstall()
Next

Wscript.Echo “Getting Software Object”
Set objSoftware = objWMIService.Get(“Win32_Product”)

Wscript.Echo “Installing”
errReturn = objSoftware.Install(“c:\builds\MyFirstSetupProject.msi”, “TARGETENV=DEVL”,True)

Wscript.Echo “Install status: ” & errReturn

In order for this to work the msi must be copied to the remote machine to work. I tried connecting to a central network share but it did not seem to work for me. The script needs a bit of work but now we can deploy to the environments we want updated in a couple of minutes instead of the 15-20 minutes it took us before.

Filed Under: Agile, General

Return To Blogging

Jan 17

I am finally finding some time and desire to write again. Life has been busy with my both my company and my family expanding. It feels like things are starting to get back to normal again so I should be writing more frequently.

Some of the things I have been working with that I hope to write about:

  • nHibernate / fluent nHibernate / Linq to nHibernate
  • WPF
  • Click once
  • Silverlight
  • A fluent .NET build langauage called fluent-build
  • Being a lead on a project
  • Multithreading
  • Caching of large amounts of data
  • Threat modeling
  • Other security items
Filed Under: General