Pulling sleight of hand tricks in a security vulnerability report, or maybe it was a prank

Raymond Chen

It can sometimes be hard to tell the difference between somebody who is playing an elaborate prank and somebody who has no idea what they’re doing. (Just like how it can sometimes be hard to tell the difference between a very advanced question and a very naïve one.)

A security vulnerability report came in that claimed that an unprivileged user could extract certain types of information from an object despite not having access to it. The evidence for this alleged vulnerability did not take the form of a document that explained the nature of the problem, however. It came in the form of a video, a silent screen recording that purported to demonstrate the vulnerability.

The video contained no narration. You just had to sit there and watch a twelve-minute silent movie. There was no accompanying description, so it was like watching a magic trick performed by a silent magician, where you see the story unfold before your eyes without knowing where it’s going to go next. You just have to sit back and wait for the surprise ending. For a magic trick, the suspense is part of the enjoyment. Not so much for a security investigation.

The video did seem to demonstrate that a user was indeed extracting information from the resource. But at the eight-minute mark, the video shows the user being added to the Administrators group. The user then signs on, opens an elevated command prompt, and runs the alleged exploit. The finder claimed that an unprivileged user could extract the information, but that’s not what their demonstration video showed. We asked for clarification.

The finder came back with another video, this one even longer than the previous one. (At least they didn’t reply with just a meme GIF.) The second video was still unnarrated, but at least it provided more details, showing each step in painstaking detail. Opening the security dialog to show the permissions on the resource and confirming that the user did not have access. Opening the source code in Notepad and scrolling through it.

C:\demo>notepad exploit.cpp

C:\demo>

And then it ran the proof of concept.

C:\demo>notepad exploit.cpp

C:\demo>exploit.exe

And then in another window, they made changes to the object, and the exploit was able to detect it:

C:\demo>notepad exploit.cpp

C:\demo>
2019/04/01 07:00:01: Value is now 3.
2019/04/01 07:00:05: Value is now 1.
2019/04/01 07:00:09: Value is now 4.

I tried playing along at home, but could not get the reported results.

So I studied the video more closely, and I observed a sleight-of-hand trick. Maybe you noticed it, too.

Look closely at the contents of the console.

Observe that the command line exploit.exe is not present any more.

In the video, the finder types exploit.exe into the command line, but instead of hitting Enter, they appear to hit ESC and erase the line. Despite the fact that exploit.exe was not run from the command line, it was nevertheless generating output.

What I suspect happened is that the finder had a copy of exploit.exe running already. That copy of exploit.exe was started while the standard user still had access to the resource. The security check happens at the acquisition of the handle, and once you have a handle, it’s yours to keep. So the already-running copy of exploit.exe was able to gain access to the resource, and it was able to retain that access even after the ACLs on the resource were changed so that the standard user no longer has access.

It is that already-running copy of exploit.exe that was monitoring the resource. Just like how the magician has an identical red ball already hiding under the cup, but fools you into thinking it’s the same red ball that vanished just moments ago.

So you tell me: Was this somebody carrying out an elaborate prank or somebody who simply didn’t understand what they were doing?

Whether it was intended as such or not, this ended up being an effective denial-of-service attack against me personally, since I ended up spending quite a bit of time watching the videos closely, then reverse-engineering what the finder believed the vulnerability to be, and then studying the videos again to find out where they went wrong.

 

9 comments

Discussion is closed. Login to edit/delete existing comments.

  • Erik Fjeldstrom 0

    I think that the appropriate course of action to this is to make a video of you typing “This was a waste of my time” into the ticket and clicking “Resolve”, then sending the video to the customer.

  • word merchant 0

    You should’ve sent them a 45 minute video back of blackness, with a note explaining to the customer that this is the security team working on the problem, all 10,000 of them, but that security is so strong at Microsoft even the photons need permission to leave the premises.

  • Yukkuri Reimu 0

    Sounds like someone is absolutely certain they are right even though they can’t seem to get it to work, so they tried to give you a rigged demo of what they KNOW should be happening.

    Like a medieval monk modifying a text he’s copying because he KNOWS for certain what it should say even though it, well, doesn’t…

  • Reinhard Weiss 0

    There’s the kind of people who already know the obvious answer you will give them, but they believe that this answer isn’t appropriate in their case. Therefore they will try eagerly to make it look like a different case and distract you from that obvious answer, mostly by omitting any useful evidence. I had people getting angry at me when I demanded the missing information (“I will not do this because I have to believe it won’t help”).

  • Lucas A. 0

    hmmm how can you get a prompt a type someting if the previous command/executable is still running ? You can’t get a prompt, unless handled by the running executable.

    • GL 0

      start "title" /b command runs command in the current console without waiting for it.

    • Stefan Kanthak 0

      OUCH!
      The command processor only waits for “console” programs (since these use their parents console).
      This is (or at least should be) basic knowledge.

    • Jernej Simončič 0

      You can obtain a handle to the console and write to it later – I’ve seen several programs that do that (which can be annoying, since I do a lot of work in FAR Manager, which is a console file manager). You can run a program, get the shell prompt (or in my case, the FAR UI) back, then the program you ran before starts spewing stuff to console.

  • Manuel Berrueta 0

    Great piece! I am glad that you made it out of the DoS alright 🙂

Feedback usabilla icon