The hassle of touching a delicate application

This is a true (tearful) story about how we at the office tried to make our work colleagues happy and face what most of our customers have gone through previously or might have to go through at some point: migrating a server or an application into modern times.

In our case, that application was a betting game for the soccer world cup in Russia – for good office fun. The idea is that it’s a web application where colleagues could enlist, predict the world champion and guess every single match’s end score. We would have a user database with pseudonyms, email addresses, passwords and everything, so that every user has their personalized view of how the gamble is going and where they are from a ranking perspective.

The target web application we’ve been thinking about has successfully been used for the last two championships and before that, the application was used in several different championships before our time. It evolved over time (almost two decades), was fixed a number of times and made working again when it was broken. When we got it, it’s already had a past of its own – does that sound familiar?

Building a Plan

Installing the application involves several complex steps that never was properly documented (again – sound familiar), including:

• Get a Windows Server box ready (Windows Server 2016)
• Install IIS on it
• Copy the binaries/source files and database file(s) onto the box
• Notice that it won’t start and start making obvious changes in IIS such as:
  • Enable Classic ASP – because, well, it’s classic ASP
  • Enable 32bit application support
  • Make sure that the Application Pool can run Classic ASP
  • Set explicit permissions on the database.

By the time log on to the system with administrative credentials, we get reminded of how truly messed up and out of date the application is. The application’s rusty-looking admin interface reminds us of the good old 2000er years. The database is an Access MDB file with clear text password storing. I’ll get my aspirins while you let that sink in.

Facing the Truth, back to Reality

Needless to say, it gets increasingly hard to look at yourself in the mirror with that kind of solution run in a productive fashion with your colleague’s credentials stored in there. Let’s be honest, there’s a number of problems:

• It’s classic ASP and would be exposed to the internet. God knows how bad and dated the code is and how easily data can be exported through the dated code without actually compromising the OS or IIS.
• Admins have access to less-than-optimally protected passwords. Even if we told our colleagues that they must choose passwords they never use anywhere else – would they listen?
• We don’t have a domain or anything set up for TLS/SSL. While this isn’t a problem per-se and could be remediated, clearly we haven’t accounted for that. And would be extra effort.
• I mean – does anyone really know what’s going on any more with that acronym?
• Authentication is based on username+password with a separate (MDB based) user store

To make it all worse – we’re not developers and that’s even more dangerous: not knowing what you’re doing but still doing it.

It’s now eight days before the world cup, time is running, and people are asking to get access to the betting game. Wouldn’t it be okay to use this just for once? Absolutely not – so we’ve put together a to do list for this application which looks as follows:

• Migrate the MDB to Azure SQL and change all the code that handles DB access (read/write).
• Get rid of all the code that handled passwords and turned it into a secure hash-based password treating password
• Make sure that even in the hashed passwords were stored securely in Azure SQL.
• Get TLS/SSL working
• Get rid of admin’s power of reading user’s passwords (or hashes once we were there)

Time to Move on

This involves already lot of changes and coding which would consume too much time in the short days we have left. Even with the changes mentioned above, we wouldn’t be able to solve any of the following problems:

• It’s potentially still dated, untrustworthy code – written by someone a long, long time ago, as a side-project
• It’s still classic ASP, whose lifetime was already commented on by ScottGu in 2005
• The code isn’t separated for UI, business logic and database layer.
• We’ve turned off all kinds of useful functionality in IIS that made it potentially vulnerable to attacks – and yes, there’s been a lot of progress on IIS since 2005.
• Authentication still happens against our database and we can’t prevent users from choosing passwords they use for something else.

On the the last point – we consider this a problem because, should any of these colleagues get compromised at any point in time, we could potentially end up being suspects of stealing the passwords from that platform and trying it on their Amazon, eBay, Facebook…

So what did we end up doing? Our choices were:

(1) Develop the thing from scratch using newest technology. As a side note, if you are a developer, financially independent (you don’t need the cash) and looking for a side project – talk to us.

1. Offer a good set of Identity Providers to users they trust – we just consume the identity and don’t store credentials at all
2. Use a Modern Development Language and a Modern Platform as a Backend (PaaS)
3. Design the Database layout in a way that has protection of user information (usernames, pseudonyms, mail addresses) built-in
4. Overkill for a betting game but – choose an architecture that allows for scaling and re-deployment for future world cups and other betting scenario. Heard of it? Microsoft is going big with Volleyball too.
5. A must have for a betting game: automatically load the respective match results from a trusted website, so that administrators don’t have to enter results manually… Imagine the revolt, when there’s an error typing the end result in!
6. Get it on a modern architecture that doesn’t make you rip your hair out just looking at the pages and spaghetti code – and that separates DB access from UX and that has a business logic in the middle.

(2) Get an existing SaaS app that does this for us and use that.

…obviously, we chose (2).

Conclusion, what is your take away?

How does this link back to your situation with your business or customers? Every business has some old applications with minimal insights on code and binaries. As we’ve outlined in this post, how bad could the consequences be when data is leaked? What would be the impact be to your business? The goal of this post is to share our thinking process and outline the little problems server administrators are confronted. Stay tuned for another post on a migration scenarios for servers and applications.