4 Replies Latest reply on Jun 9, 2010 6:53 AM by MichaelvdV@Atos

    Small security issue on vCampus login

    MichaelvdV@Atos

      I found a (small) security issue regarding the login on vCampus.

       

      Background:

       

      A few years ago there was an OpenSSL bug, which did kind of the same thing as I'm describing here. The issue was the following:

       

      If a user/pwd combination was incorrect, but the username was an existing user, the timespan between the initiation of the login, and the return error message was different then from a user/pwd combination where the user did not exist. This gave away information about existing usernames. The same (but even more visible) issue is happening on vcampus.

       

      Description:

       

      vCampus credentials are made up from two parts, a username and password. While the password is the 'more secure' part of the authentication, it is still a two-part authentication (a specific password for a specific username).

       

      It is important not to give any information away about the combination of the two to 'outsiders'.

       

      There is a little catch tough:

       

      If I login with a non-existing username, like 'foofoo', with a jibbrish password, you are presented with the following message:

      
      

      Invalid credentials. Be sure to Register if a first time user.

       

      If I login with a known username, and a jibbrish password, you are presented with the following message:

      
      

      Please check your username or Password and try again.

       

      So, the vCampus software is giving away information about the username-password combination. More precisly, outsiders can check for existing usernames, making a brute force attack far more optimized.

       

      I have no information if there are login-attempts lockouts implemented in the vCampus software, but this could mean that an attacker can collect known usernames, and bruteforce a password in a night.

       

      With all the information available on the internet (google/linkedin/etc) it is easy to find companies and individual users that use PI/vCampus. Therefore it would not be that difficult to create an extended dictionary with possible usernames (and variations) for vCampus to have an highly optimized bruteforce/dictionary attack. Important to note is that usernames are not case sensitive. This increases the chance of getting a positive hit on an existing username by almost 2.

       

      As there is a lot of information available on vCampus, but more importantly: there is a ton of (commercial) software available for download. This could mean that OSIsoftware can be cracked/illegally distributed, and that someone with the account (who is ignorant of the situation) will take the blame.

       

      Example of exploit:

       

      Searching for OSIsoft PI on google.com gives a lot of results. The fourth result is Rhys's company website: http://www.rjksolutionsltd.co.uk/main/. Rhys's company is called 'RJK Solutions'. (the term 'vcampus' is mentioned on this website/forum)

       

      From his company name and information on his website, it is not very difficult to compile a list of possible loginnames (simplified example):

      
      

      Rhys

      Kirk

      RhysKirk

      Rhys-Kirk

      KirkRhys

      RJKSolutiosn

      RJK-Solutions

      rkirk

      kirkr

      (...)

       

      Another example:

       

      Searching for OSIsoft vcampus on LinkedIn produces a couple of results. The first result being Steve Pilon. Again, it is not difficult to produce a list of possible usernames (simplified):

      
      

      Steve

      StevePilon

      Steve-Pilon

      Pilon-Steve

      (...)

      pilons

      spilon

       

      Workaround:

       

      In these examples, the only way to make it very difficult (or near impossible) for an attacker to use your particulair account, is to choose a very strong password. This only 'protects' for accounts that have that strong password.

       

      Proposed Solution:

       

      Have the authentication error messages give away no information. This means that all security error messages must produce the same message.

       

      Enforce strong passwords.

       

       

       

      edit: @Rhys & @Steve: If you mind these examples, please contact me and I'll remove them. It's just to illustrate this case.