Slashdot Mirror


Researcher Finds Simple Way of Backdooring Windows PCs and Nobody Notices for Ten Months (zdnet.com)

A security researcher from Colombia has found a way of gaining admin rights and boot persistence on Windows PCs that's simple to execute and hard to stop -- all the features that hackers and malware authors are looking for from an exploitation technique. From a report: What's more surprising, is that the technique was first detailed way back in December 2017, but despite its numerous benefits and ease of exploitation, it has not received either media coverage nor has it been seen employed in malware campaigns. Discovered by Sebastian Castro, a security researcher for CSL, the technique targets one of the parameters of Windows user accounts known as the Relative Identifier (RID). The RID is a code added at the end of account security identifiers (SIDs) that describes that user's permissions group. There are several RIDs available, but the most common ones are 501 for the standard guest account, and 500 for admin accounts.

Castro, with help from CSL CEO Pedro Garcia, discovered that by tinkering with registry keys that store information about each Windows account, he could modify the RID associated with a specific account and grant it a different RID, for another account group. The technique does not allow a hacker to remotely infect a computer unless that computer has been foolishly left exposed on the Internet without a password. But in cases where a hacker has a foothold on a system -- via either malware or by brute-forcing an account with a weak password -- the hacker can give admin permissions to a compromised low-level account, and gain a permanent backdoor with full SYSTEM access on a Windows PC.

40 of 94 comments (clear)

  1. Cite please? by NewtonsLaw · · Score: 4, Interesting

    Can we have a link to material that might verify this claim?

    1. Re:Cite please? by olsmeister · · Score: 1

      It sounds simple enough that you should be able to verify yourself pretty quickly.

    2. Re:Cite please? by Anonymous Coward · · Score: 5, Interesting

      There are so many errors in TFS that it is hard to say. First, a RID does not describe the user's groups. A RID is simply an offset applied to the computer SID that is incremented by one for each new user account. So that's wrong. Yes, the first RID created is for the administrator account and it is indeed *computer SID*-500. But that doesn't equate to permission groups. Next, it says that you can do this with an unprivileged user. You can't. You have to have admin in order to make the change to the HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList and associated areas where you would be able to make this change. So if you already have admin, there isn't much point in this.

    3. Re:Cite please? by Gravis+Zero · · Score: 3, Informative

      Can we have a link to material that might verify this claim?

      A search of "RID Hijacking" revealed (among other things) a commit to metaploit on Feb 20. (likely merged in from a fork)

      Git commit dates can be faked so there is also an announcement from @BlackHatEvents about it from June 24.

      I'm quite inclined to believe their claim.

      --
      Anons need not reply. Questions end with a question mark.
    4. Re:Cite please? by hwihyw · · Score: 4, Interesting
    5. Re:Cite please? by Anonymous Coward · · Score: 2, Funny

      Linux has a similarly catastrophic security hole :

      Once you get root access, edit /etc/passwd and change the uid for your username to 0.
      Persistent root access for your unprivileged user!

    6. Re:Cite please? by LesFerg · · Score: 4, Insightful

      Precisely.

      "Hey everyone I have a Windows backdoor!!! Just give me admin access and let me edit your registry file."

      Where is the news?

      --
      If I had a DeLorean... I would probably only drive it from time to time.
    7. Re:Cite please? by Bert64 · · Score: 1

      The point is to retain administrative access while not being detected, the extra complication is not useless if it reduces the chance of the backdoor being detected (and thus removed, resulting in you losing administrative access).

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    8. Re:Cite please? by f3rret · · Score: 1

      Any admin worth their salt is just going to monitor usage of administrative privileges, so if a user who is not supposed to have those privileges suddenly uses them, it's pretty clear what is going on.

      --
      Admit nothing. Deny Everything. Make Counter-accusations.
    9. Re:Cite please? by Bert64 · · Score: 1

      Which is the whole point, many people are simply monitoring users who are in the administrators group - and this attack creates a user with administrative privileges while not being a member of the group. If your monitoring depends on such criteria, then this attack defeats it.

      No monitoring strategy is flawless, there are so many things you could keep track of but you also need to eliminate the noise generated by legitimate activity. If you just log everything you'll be flooded with data all day long, if you filter too much or log too little then you will miss things. It's extremely difficult to strike the right balance, especially when strategies such as this are discovered which invalidate previous assumptions about logging and alerting.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  2. Remote Access by Major+Blud · · Score: 1

    But in cases where a hacker has a foothold on a system -- via either malware or by brute-forcing an account with a weak password

    If that's the case, I don't think the hacker needs to worry much about mucking around in the Registry to get administrative access.

    --
    If you post as Anonymous Coward, don't expect a reply.
    1. Re:Remote Access by ole_timer · · Score: 1

      yeah, once you're on the system and can manipulate the registry you have privs to just create an account with whatever privs you want. doh.

      --
      nothing to see here - move along
    2. Re:Remote Access by jbmartin6 · · Score: 2

      You would need admin access to make the change in the first place, this is just a persistence mechanism. There are so many others it is no surprise this one isn't seeing any use.

      --
      This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    3. Re:Remote Access by jbmartin6 · · Score: 1

      This is also an old technique, at least on the Unix side, where attackers would create a new account with UID 0.

      --
      This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
    4. Re:Remote Access by hey! · · Score: 2

      I think you're missing the point of the back door. Sure, it doesn't enable the attacker to anything he couldn't otherwise do right now, but you don't necessarily want to do anything right now. This could be because the machine doesn't have the information you want to steal yet, or because you want to interfere with something the user may be involved with in the future (e.g., conducting a military or political campaign).

      The problem is just because you can get in now doesn't guarantee that the system won't get patched later, or passwords updated, or malware files scanned. Any kind of vulnerability you leave behind could simplify your job later.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    5. Re:Remote Access by ole_timer · · Score: 1

      there's no guarantee that the path in will be there either...persistence requires the entire path be there too...

      --
      nothing to see here - move along
    6. Re:Remote Access by hey! · · Score: 1

      Well, if you want guarantees, hacking isn't for you.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    7. Re:Remote Access by im_thatoneguy · · Score: 1

      The only thing I can think of is that you could allow an application "registry access" when you're looking at the requested permissions.

      So like a phone says "This application wants access to your GPS location" you might be willing to grant it GPS location but not microphone data. So you could grant a user registry access thinking that it's a one time limited permission of the installer to modify the registry but instead you end up with an application creating an admin level account.

      Then again... a keylogger would be way easier to install in the BG.

    8. Re:Remote Access by viperidaenz · · Score: 1

      You don't grant an installer just registry access, you grant it all access.
      There's nothing stopping the installer from using the regular API's for modifying local users after you've given it local admin access.

  3. If you can add someone to the administrator group. by Kaenneth · · Score: 5, Funny

    "Oh yes, I thought of something," panted Ford.

    Arthur looked up expectantly.

    "But unfortunately," continued Ford, "it rather involved being on the other side of this airtight hatchway."

  4. Re:If you can add someone to the administrator gro by ole_timer · · Score: 1

    +1

    --
    nothing to see here - move along
  5. Why bother granting admin privileges by nadass · · Score: 1

    Why bother granting administrative privileges when the device is physically accessed and any nefarious payloads can already be executed?! Just because a "slow-burn" strategy might be employed to take down a target network, that doesn't make this "vulnerability" a big deal. Instead the underlying issue is that when poor security practices are employed and registry access is readily offered... anything bad can happen, from granting elevated privileges or printing out codes for the nuclear fusion reactors.

    Sure, it's a bit of an issue, but the only sensible fix is to store all RID-encoded permissions into an alternate location (cloud) which is not otherwise accessible on the local machine. But then all Windows machines would *require* internet access... or all log-ins would be susceptible to man-in-the-middle attacks during authn/authz checks against the cloud (or proximate central auth directory).

    Come to think of it, the solution already exists: domain-join all workstations against a locally-deployed AD. Yay, problem solved.

  6. There is nothing to notice by Zero__Kelvin · · Score: 1

    This is the equivalent of a Linux newbie who fancies himself a "security researcher" discovering that the root user can add any user to any group and thinking he thought of a new "trick" and found a "vulnerability."

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    1. Re:There is nothing to notice by 110010001000 · · Score: 1

      Exactly. The old trick of adding "rroot" to /etc/passwd with uid 0 and hoping no one notices.

    2. Re:There is nothing to notice by snapsnap · · Score: 1

      Or can change UIDs in /etc/passwd. That's the Linux equivalent of this.

    3. Re:There is nothing to notice by Kaenneth · · Score: 1

      If I could force one change on Linux, I would make the root uid random/settable per system.

      It's too easy to fuckup having the uid be the default value of unused memory.

      For example, when I was first learning Linux I setup a fax-to-web server with every step under its own user. Fax modem to raw image was FAXRCV, raw image to pages/thumbnails/ocr processing was FAXIMG, images/data to intranet site was FAXSRV; each only had access to the programs/paths needed for their job.

      But I launched them all using a program that expected numeric user *numbers* not user *names*, and the default parsing of atoi for "FAX???" is 0, so it launched them all as root.

      I figured that out on my own before too long, and the machine was never internet visible; but a zero is easier to slip into malicious code than something like a "GetSystemRootUID()" function call.

    4. Re:There is nothing to notice by viperidaenz · · Score: 1

      and now you've learnt to validate your inputs.

    5. Re:There is nothing to notice by techno-vampire · · Score: 1

      If I could force one change on Linux, I would make the root uid random/settable per system.

      I don't think that would work the way you expect. Under *nix, there's nothing special about the username "root". You can change it to anything you want and it still works the same. The magic is in the userid of 0 and changing it the way you suggest would require that every program that needs elevated privileges would have to be rewritten to find out what that userid is on this system every time it's invoked, adding an extra layer of complexity. (This, of course, assume that those programs check to see what user is running them to find out if they have permission to do what's needed. If not, it might not be an issue.)

      --
      Good, inexpensive web hosting
    6. Re:There is nothing to notice by Bert64 · · Score: 1

      Except /etc/passwd is an easily human readable text file, making such a change trivially easy to notice.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  7. Re:The other side of the airtight hatchway by MachineShedFred · · Score: 1

    It could be thought of as a very slight issue.

    Someone could combine a privilege escalation attack with this to persist a user that is an admin, without visibility. E.g. they would essentially be in the "Administrators" group without showing up in that group.

    Yes, this is incredibly sensationalized for what it is. There are far bigger risks if some rogue process or actor has administrative privileges to begin with. Once you're owned, you are already owned.

    --
    Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
  8. Stupid by duke_cheetah2003 · · Score: 1

    This is dumb. The exploit requires you break into the system by other means. And if you're successful with that, why the hell would you need this after you've already compromised the system?

  9. Millenial discovers user and group permissions? by Fly+Swatter · · Score: 1

    I guess that is news.

  10. Bit of a lack of detail by viperidaenz · · Score: 1

    But it doesn't say a low privilege account can run this exploit.

    Sounds more like "admin level account can give admin access to non-admin account" issue. Which you can do anyway...

    Now if the guest account had permission to alter those registry keys, that would be more serious. No where do they say that's the case.

  11. Re:Not a backdoor by viperidaenz · · Score: 1

    They're doing their job fantastically.
    That being "post click-bait headlines to increase ad revenue"

  12. Re:What I would really like to see by viperidaenz · · Score: 2

    "You're too stupid to be allowed to run windows, so here's something that's harder to use and easier to fuck up"
    Good one.

  13. If you have admin rights, you can grant them by Attila+Dimedici · · Score: 1

    If I am reading the summary correctly, what they are saying is that if you have admin rights, you can grant other users admin rights.

    --
    The truth is that all men having power ought to be mistrusted. James Madison
  14. Re:Wait what? by Locke2005 · · Score: 1

    Not if you take the hard drive out, attach it to another computer, and edit the file, you don't.

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
  15. for an encore by spongman · · Score: 1

    he went on to show that `sudo passwd root` was a privilege elevation exploit.

  16. welp by evanchik · · Score: 1

    at least its fixed now.....10 years later. I found a couple 0days in my life, i took the fame and money though