Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Windows

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

Posted by msmash from the security-woes dept.
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.
This discussion has been archived. No new comments can be posted.

Researcher Finds Simple Way of Backdooring Windows PCs and Nobody Notices for Ten Months More

Researcher Finds Simple Way of Backdooring Windows PCs and Nobody Notices for Ten Months

Comments Filter:

  • Cite please? (Score:5, Interesting)

    by NewtonsLaw ( 409638 ) on Wednesday October 17, 2018 @01:51PM (#57493826)

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

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

      • Re:Cite please? (Score:5, Interesting)

        by Anonymous Coward on Wednesday October 17, 2018 @02:29PM (#57494070)
        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.

    • Re:Cite please? (Score:4, Informative)

      by Gravis Zero ( 934156 ) on Wednesday October 17, 2018 @02:42PM (#57494164)

      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. [github.com] (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. [twitter.com]

      I'm quite inclined to believe their claim.

    • Re:Cite please? (Score:4, Interesting)

      by hwihyw ( 4763935 ) on Wednesday October 17, 2018 @02:59PM (#57494272)

      https://www.youtube.com/watch?... [youtube.com]

  • 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.

    • 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.
    • 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 is also an old technique, at least on the Unix side, where attackers would create a new account with UID 0.

    • Re: (Score:3)

      by hey! ( 33014 )

      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

  • If you can add someone to the administrator group. (Score:5, Funny)

    by Kaenneth ( 82978 ) on Wednesday October 17, 2018 @02:00PM (#57493896) Journal

    "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."

  • 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.

  • is a worm/virus that installs linux on a target system (overwriting windows) with a background that says something like:

    "You're too stupid to be allowed to run windows"

    • "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.

  • 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."
    • Exactly. The old trick of adding "rroot" to /etc/passwd with uid 0 and hoping no one notices.

      • Re: (Score:2)

        by Kaenneth ( 82978 )

        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 progra

        • and now you've learnt to validate your inputs.

        • 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, add

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

      • Re: (Score:2)

        by Bert64 ( 520050 )

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

  • 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?

  • 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.

  • 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.
  • If a hacker has physical access to the hard drive of a computer, it isn't secure! (Barring encrypting the drive in a way that ties it to specific hardware, in which case, if that hardware fails, then all your data is lost.)

  • If no one can see the problem here, they're avoiding it.

    https://blogs.technet.microsof... [microsoft.com]

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

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

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close