KALYPTO (IN)SECURITY

Research, demonstrations, and popcorn

The ‘RID’ vulnerability is not a vulnerability…

Recently a “researcher” has gone on a marketing blitz trying to convince the world he found a vulnerability that doesn’t exist.  This vulnerability has been dubbed ‘RID Exploitation.’  According to this researcher, the RID is the relative identifier at the end of a SID (security identifier) that generally denotes the level of access an account has.

  • Example of Guest account SID:  S-1-5-21-5556071421-4546327964-2791644642-500
  • Example of an Admin account SID:  S-1-5-21-5346061422-3931128441-1901660643-501
What is a SID and RID?

The -500 or -501 at the end is what they call the RID.  This is tied to a access level.  If you look at Microsoft’s documentation about SIDs, you will see all the different types of SIDs and RIDs.  As you can see from the documentation, all normal user accounts start with S-1-5-21, followed by a 30 numeric character identifier, and then followed with the RID (access ID).

The supposed exploit of this vulnerability is the ability to modify the registry to change an accounts access level.  So you would change a guest account that ends with -500 to -501, in turn supposedly changing it to a full admin.  There are several problems with this ‘vulnerability:’

  1. You must have admin rights to the machine to make the registry change to begin with.  This means you already have admin rights and you are assigning them to an account that shouldn’t have admin rights.  Admins can already do this.  This isn’t a vulnerability… this is how security is designed to work.
  2. If you have admin rights already, you don’t have to hack the registry to change the permissions.  You can use any number of standard methods for making this change, be it WMI, PS, CMD, GUI via the computer management tool, the control panel, etc.
  3. This does not change domain rights.  You can’t change a person to an admin on a box and then have that permission propagate out to a domain.  It’s local only and will not grant them domain admin rights.

What this means is this is basically an over complicated persistence issue at best.  You can temporarily get admin rights and then persist that level of access to another account that you have rights to (such as guest).  Again, this isn’t a vulnerability.  If you have admin rights to make the change via the registry, you also have admin rights to make the change at the machine level via normal methods.  Changes like that are still registered in the event log when you escalate permissions to edit the registry… so this doesn’t even get done without any trackability.

Can I take over SYSTEM?

I had another person state online that they took it as you could exploit this to escalate to SYSTEM level access from Admin access.  This is not true either.  The local SYSTEM SID is S-1-5-18 and is not followed by a 30 digit ID and does not have a ‘RID’ at the end.  There can be only one SID of S-1-5-18 and there is no way to take it over via the method described by the researcher.

Be scientific and don’t try to get e-famous.

I appreciate researchers trying to find vulnerabilities… but we should be presenting our findings in the same manner as any scientific community.  Have your method documented and peer reviewed.  Make sure it’s actually what you are claiming.  Otherwise, you make yourself look worse, you make other people trust news about security issues less, and you just cause confusion.  At the very least it is irresponsible, at most, dangerous and self serving to try and look like some elite hacker.

Kalypto • October 21, 2018


Previous Post