back to article Do you really think crims would do that? Just go on the 'net and exploit a Windows zero-day?

The Windows ALPC security hole that emerged early last week remains unpatched, even though it is being actively exploited by hackers to gain total control over PCs. As we reported at the end of August, a person behind the now-deleted Twitter account SandboxEscaper publicly revealed the system-level privilege escalation zero- …

  1. Anonymous Coward
    Anonymous Coward

    How does a machine first get infected, usual suspects:

    Phishing / Dodgy email link / Infected USB memory / Compromised website?

    1. diodesign (Written by Reg staff) Silver badge

      Re: How does a machine first get infected, usual suspects?

      Yes. d) all the above.

      C.

    2. big_D Silver badge

      Re: How does a machine first get infected, usual suspects:

      Exactly, you have to get the .exe on the machine in the first place.

      There was no mention in the article about the infection vector, just what could happen, once infected.

      Given this is a local escalation problem only, while not insignificant, it does mean that your machine is already compromied, if they can use this exploit.

      1. thepip3r

        Re: How does a machine first get infected, usual suspects:

        The point is you don't need an EXE on the machine. Any standard user-level exploit will suffice but most commonly, phishing. Arbitrary code execution through a PDF/Office Document or running of any PE image file can easily perform this action. Lets re-cover the exploit with a bit more granular of an explanation:

        1. User tricked into executing arbitrary code (PE image file (executable), or script file) most likely via email.

        2. Code runs to create a scheduled task object targeting a system file.

        3. MAGIC HERE ---> Task Scheduler API is invoked to use a function called SchRpcSetSecurity which inappropriately allows ANY user to invoke it which can be done via PowerShell and P/Invoke. This lack of permissions-check allows a standard user (or abritrary code running as a standard user (see step 1)) to set ANY permission on the task, which in turn, sets permissions on the task-target.

        And in this case, where a file would normally be protected by Windows ACLs, due to the permissions overwrite SchRpcSetSecurity, any user can change overwrite the target with whatever they want. And because this file is a loaded library but a Windows service running as NT Authority\System the attckers just needs to either cycle the service (if they can) or initiate a reboot (which will cycle the service). When the service starts back up as NT Authority\System and executes your code--voila, local privilege escalation.

        If you don't understand why that's bad, then the above will be way too deep for you.

      2. diodesign (Written by Reg staff) Silver badge

        Re: "Given this is a local escalation problem only"

        I think you're overlooking the fact that this exploit gives you full system control - rather than running as a normal user.

        C.

  2. John Smith 19 Gold badge
    Unhappy

    So classic way to find an exploit.

    1) Read what the manual says a Windows function can do and will allow

    2) See if its parameter checking stops you from doing whatever you want.

    3) Check next function.

    It shouldn't be possible to change access permissions to system files without Admin privileges.

    But it turns out it is.

    I wonder if the code to check was in a dev version but some PHB decreed "Nah, that slugs performance, and it'll never be a problem IRL"

    Or did they just not bother to write parameter checking code?

    1. MacroRodent

      Re: So classic way to find an exploit.

      I think this method was already in Andrew Tanenbaum's operating systems text book (the one that introduced Minix) in the security chapter: Something like "Read the documentation looking for passages that say Don't do X. Try as many variations of X as possible".

      1. Anonymous Coward
        Anonymous Coward

        Re: So classic way to find an exploit.

        An incredibly long time ago, back when I used to follow IBM system engineers around at the university, I was told to always read the manual(s). Amazing what you can get to work right, as well as amazing what you can get to system to do that no one would knowingly allow. For example, turning off accounting on your job on the IBM System/370 given certain parameters on the $JCL card.

      2. John Smith 19 Gold badge
        Coat

        "I think this method was already in Andrew Tanenbaum's operating systems text book "

        I'd suggest "peopleware" that dates from 1987

        The discussion of "The Black Team" would be the area to look.

        I guess this shows the difference between software and hardware.

        Software manual. Functions do what they say but lack checking.

        Hardware manual (Intel memory management) functions don't do what they say.

    2. Blitheringeejit
      Joke

      Re: So classic way to find an exploit.

      What's a "manual"?

      1. phuzz Silver badge
        Headmaster

        Re: So classic way to find an exploit.

        What's a "manual"?

        It's the difference between a BOFH and a PFY.

      2. Anonymous Coward
        Anonymous Coward

        Re: So classic way to find an exploit.

        Manuel is the guy writing the exploit?

    3. bombastic bob Silver badge
      Unhappy

      Re: So classic way to find an exploit.

      "I wonder if the code to check was in a dev version but some PHB decreed 'Nah, that slugs performance, and it'll never be a problem IRL'"

      more like "I don't want to do extra work to check for this" by some lazy overpaid millenial "child" since (it appears that) nearly all senior devs and QA people have left Micro-shaft over the last decade or so... maybe taking their stock options, or getting out while the getting's good, or being hit by a round of lay-offs that target the senior people because they earn more... [this has been somewhat confirmed by NYT and Forbes and other news sources, showing how average age at tech companies is much lower than you'd normally expect]

      I surfed around a bit, which led me to the github site where the sample was posted, but it was deleted 3 days ago. Did a little commit history digging and managed to download the (otherwise deleted) RAR file containing source and binaries, a docx file [that I did not open], and an mp4 video. I just followed links from the article and applied some web-common-sense and voila!

      a comment from the source says the following (for what it's worth):

      "_SchRpcSetSecurity which is part of the task scheduler ALPC endpoint allows us to set an arbitrary DACL. It will Set the security of a file in c:\windows\tasks without impersonating, a non-admin (works from Guest too) user can write here. Before the task scheduler writes the DACL we can create a hard link to any file we have read access over. This will result in an arbitrary DACL write."

      1. EnviableOne

        Re: So classic way to find an exploit.

        like "I don't want to do extra work to check for this" by some lazy overpaid millenial "child" since (it appears that) nearly all senior devs and QA people have left Micro-shaft over the last decade or so...

        More like they never even thought they had to, just coppied some other code that did what they wanted, and as it was an example, didnt have the checking in.

        Cos Coders arent Programmers

    4. Cem Ayin
      Holmes

      Re: So classic way to find an exploit.

      """

      1) Read what the manual says a Windows function can do and will allow

      2) See if its parameter checking stops you from doing whatever you want.

      3) Check next function.

      """

      I dont think anyone could have found this particular vuln using the above receipe. The problem here ist not insufficient validation of input to a privileged system function - as I read the article (and the linked explanation) it's rather a game of "spot the unintended side effect":

      %SYSTEMROOT%\Tasks allows any authenticated user to create files there [NT AUTHORITY\Authenticated Users:(RX,WD)] and some system utility can be coaxed to change this file's permissions without checking if it isn't really an alias pointing elsewhere (say, a system library...) => game over :(

      The problem is more akin to the classical "Unix /tmp-race" class of vulnerability. And now that this can of worms has been opened on Windows also, I would not be suprised if there was still more to be had where this particular vuln came from.

      (If one absolutely wanted, one could of course subsume the creation of a file under "user input" to a "function" and checking for aliases in world-writeable directories under "parameter checking" but for my taste that would be stretching the meaning of those concepts a bit far.)

  3. Anonymous Coward
    Anonymous Coward

    I haven't heard word one if the various Windows Server incarnations are vulnerable or not. I'm leery of assuming not when it just ain't so.

    Never mind: Windows Server 2016 is also effected.

    1. Dan 55 Silver badge
      Headmaster

      I am affected by your 'effected'.

      1. onefang

        That's just an affectation of yours.

      2. Will Godfrey Silver badge

        but he effected a very polite response :)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like