
Zero-Day Vulnerability in Microsoft Windows Leaked on Twitter - tzury
https://twitter.com/SandboxEscaper/status/1034125195148255235
======
trollied
Here's the exploit description from the writeup .doc file that is included in
the .rar file that's hosted on GitHub:

    
    
      The task scheduler service has an alpc endpoint, supporting the method “SchRpcSetSecurity”.
      The prototype looks like this:
    
    	long _SchRpcSetSecurity(
    		[in][string] wchar_t* arg_1, //Task name
    		[in][string] wchar_t* arg_2, //Security Descriptor string
    		[in]long arg_3);
    
      Tasks created by the task scheduler will create a corresponding folder/file in c:\windows\system32\tasks. 
      This function seems to be designed to write the DACL of tasks located there, and will do so while impersonating.
     
      However, for some reason it will also check if a .job file exists under c:\windows\tasks and try to set the DACL 
      while not impersonating. 
    
      Since a user, and even a user belonging to the guests group can create files in this folder, we can simply create 
      a hardlink to another file (all we need is read access). 
      Because of the hardlink, we can let the task scheduler write an arbitrary DACL 
      (see second parameter of SchRpcSetSecurity) to a file of our choosing.
    
      So any file that we have read access over as a user and that system has the write DACL permission for, 
      we can pivot into full control and overwrite it.

~~~
LeifCarrotson
Please don't quote text with code blocks:

> _The task scheduler service has an alpc endpoint, supporting the method
> “SchRpcSetSecurity”. The prototype looks like this:_
    
    
        long _SchRpcSetSecurity(
            [in][string] wchar_t* arg_1, //Task name
            [in][string] wchar_t* arg_2, //Security Descriptor string
            [in]long arg_3);
    

> _Tasks created by the task scheduler will create a corresponding folder
> /file in c:\windows\system32\tasks. This function seems to be designed to
> write the DACL of tasks located there, and will do so while impersonating._

> _However, for some reason it will also check if a .job file exists under
> c:\windows\tasks and try to set the DACL while not impersonating._

> _Since a user, and even a user belonging to the guests group can create
> files in this folder, we can simply create a hardlink to another file (all
> we need is read access). Because of the hardlink, we can let the task
> scheduler write an arbitrary DACL (see second parameter of
> SchRpcSetSecurity) to a file of our choosing._

> _So any file that we have read access over as a user and that system has the
> write DACL permission for, we can pivot into full control and overwrite it._

~~~
buntress
Please don’t repost other user’s posts, because you have a formatting
preference.

~~~
sigotirandolas
He didn’t post the other user post again, but rather posted the original text
from the writeup again.

------
scottydelta
Quote from blog post[1] dated 14th June:

    
    
        I really did not get anything for this bug, and I know I'm probably forfeiting an acknowledgement 
        too right now. But I wasted alot of time on this bug, and nobody but me should be able to decide 
        what to do with it. People who criticize this type of behavior I find frankly annoying. 
        I used to be one of those self-righteous types, but I'm also pretty annoying, so perhaps there is a correlation.
    
        Besides, this bug is way to silly in its complexity to be of any use to anyone. 
        I would not drop a full 0day exploit, which I can assure you, 
        I have totally sitting on my hard drive (not referring to this bug :).
    
    

For the people wondering why she released the exploit instead of claiming
bounty on it, in the blog post[1] dated 14th June, she said she would not drop
a full 0day exploit. I guess that changed when she did not get credit for her
last bug (cve-2018-8314) according to her another blog post[2] from Aug 17th.

[1] [https://sandboxescaper.blogspot.com/2018/06/using-
filepicker...](https://sandboxescaper.blogspot.com/2018/06/using-filepickers-
to-escape-sandboxes.html)

[2] [https://sandboxescaper.blogspot.com/2018/08/all-good-
things-...](https://sandboxescaper.blogspot.com/2018/08/all-good-things-must-
come-to-end.html)

~~~
nailer
Fixed:

> I really did not get anything for this bug, and I know I'm probably
> forfeiting an acknowledgement too right now. But I wasted alot of time on
> this bug, and nobody but me should be able to decide what to do with it.
> People who criticize this type of behavior I find frankly annoying. I used
> to be one of those self-righteous types, but I'm also pretty annoying, so
> perhaps there is a correlation.

> Besides, this bug is way to silly in its complexity to be of any use to
> anyone. I would not drop a full 0day exploit, which I can assure you, I have
> totally sitting on my hard drive (not referring to this bug :).

------
ghostbrainalpha
"Here is the alpc bug as 0day:
[https://github.com/SandboxEscaper/randomrepo/blob/master/PoC...](https://github.com/SandboxEscaper/randomrepo/blob/master/PoC-
LPE.rar) … I don't fucking care about life anymore. Neither do I ever again
want to submit to MSFT anyway. Fuck all of this shit."

So is this person upset because Microsoft wouldn't patch the bug? Or that they
didn't want to pay for the information?

Comments seem to reference Apple pays 25k for this type of info.

Can anyone with background give some context here?

~~~
qeternity
Earlier tweets from this account seem to indicate they believe MS
intentionally sabotaged the process so that they could sell the bugs,
including to oppressive governments:

[https://twitter.com/SandboxEscaper/status/103411618937352192...](https://twitter.com/SandboxEscaper/status/1034116189373521920)

[https://twitter.com/SandboxEscaper/status/103411292604562227...](https://twitter.com/SandboxEscaper/status/1034112926045622274)

 _EDIT_ as @dixie_land points out, it appears the author is open to selling
indiscriminately.

~~~
mockingbirdy
_Please
see[https://news.ycombinator.com/item?id=17860480](https://news.ycombinator.com/item?id=17860480)
before downvoting._

From her website -
[http://sandboxescaper.blogspot.com](http://sandboxescaper.blogspot.com):

> I'm also transgender. But my transition so far has been really difficult
> (social isolation, lack of support.. etc), my voice is still really manly
> and I don't really pass at all (which probably weirds people out.. so I
> would rather say it upfront so I don't need to have anxiety about it, I have
> alot of anxiety issues). I also have not been able to change my name yet,
> legally its still "Thomas".

\- - -

w.r.t. the 0-day release: Well that's some seriously irresponsible stuff right
there.

I think she has a tough time (she's transgender and doesn't have support from
her peers). It's sad that she hasn't found a way to live a happy life although
she clearly has serious skills. I hope she'll be fine.

It's just annoying that a lot of users are now at risk, I hope the patches
will be installed ASAP.

~~~
daxorid
Full disclosure is not "irresponsible", and plenty of researchers do it even
in the absence of armchair psychoanalysis by the Internet.

~~~
mockingbirdy
Most of them follow specific timelines for those disclosures which are
communicated with the affected vendor.

~~~
throwawayjava
And also don't follow up a disclosure with an offer to sell exploits to the
highest bidder.

Is selling an exploit to a foreign government even 100% legal? (Serious
question; that seems like the sort of thing that could get one in trouble.)

~~~
LinuxBender
If you sold to a country with standing sanctions, that could be an issue.
0-day's can also be considered munitions in some interpretations of law,
though I am not a lawyer nor a weapons dealer.

------
pwaai
I'm always curious about the individuals discovering these zero day
vulnerabilities.

What framework do they use to find it? Is it just educated trial and error
until you hit something?

~~~
2trill2spill
Fuzzers[1] as well as reverse engineering tools. For fuzzers there is both the
publicly available ones like AFL [2] and custom/closed source ones. It seems
to me every zero day author has their own fuzzers or fuzzing frameworks or at
least a closed fork of an open source fuzzer. But to me finding the bug is
less difficult then turning it into an exploit. Shoot you can still find bugs
in modern software by bit flipping, as an example I wrote a fuzzer that opened
up random PDF files and flipped some bits at random and then opened them with
Preview. it did this about 40,000 times a day and after a couple days I would
come back and my mac had kernel panicked. Now turning one of these PDF files
that cause kernel panics into an exploit is going to require significantly
more effort then writing and running a dumb fuzzer.

[1]:
[https://en.wikipedia.org/wiki/Fuzzing](https://en.wikipedia.org/wiki/Fuzzing)

[2]:
[https://en.wikipedia.org/wiki/American_fuzzy_lop_(fuzzer)](https://en.wikipedia.org/wiki/American_fuzzy_lop_\(fuzzer\))

~~~
pwaai
wow....that is pretty interesting. how do you write your own fuzzer, seems
like that's where the edge comes from? How much more of an effort is it to
write an exploit? Is it necessary to build a Proof of Concept or is simply
disclosing the vulnerability enough?

If I buy ADA what software/API can I start tinkering with?

What you described seems like so much fun but scared of the writing exploit
part. Now that seems really hard especially considering it needs to be fully
undetectable for a long time until the buyer gets their return on investment.

Is there a course or resource I can use to begin this path?

I love love poking around with things to see how they work....basically the
chase or the process is what I enjoy most and curious to know more.

How did you get into all of this?

~~~
2trill2spill
> wow....that is pretty interesting. how do you write your own fuzzer, seems
> like that's where the edge comes from? How much more of an effort is it to
> write an exploit? Is it necessary to build a Proof of Concept or is simply
> disclosing the vulnerability enough?

Dumb fuzzers can be written in anywhere from a day to a few weeks of work,
smart fuzzers can take several years to write, also lots of fuzzers
continually evolve over time because they have to. Its the Red queen
effect[1], fuzzers keep finding bugs so they have to keep getting better to
keep finding harder and harder to find bugs in a target codebase. So I would
say an exploit is usually the harder task but some of the things smart fuzzers
like SAGE[2] do would be incredibly hard to implement.

> If I buy ADA what software/API can I start tinkering with?

I'm not sure what ADA is. However for testable software I would go for
programs that come installed on your operating system of choice. So in my case
I was using MacOS at the time so I was targeting MacOS default applications.

> What you described seems like so much fun but scared of the writing exploit
> part. Now that seems really hard especially considering it needs to be fully
> undetectable for a long time until the buyer gets their return on
> investment.

Fuzzer development and exploit development are pretty different tasks. Fuzzer
development is basically normal software development, while exploit
development at least with security mitigations turned on is an entirely
different beast. For example in exploit development your going to need to know
x86-64 assembly, as well as general memory layout, how a particular operating
system implements ASLR[3] so you can bypass that. As well as bypassing
DEP/NX[4] which is often done using ROP[5] and now recently newer
techniques[6]. The fuzzer I was describing above was a dumb file mutation
fuzzer which can be extremely simple. So first it was a file fuzzer, meaning
it fuzzed programs that take files as inputs, stuff like video and music
players or in my case pdf files. The mutation part means the fuzzer took
existing valid files and added random mutations as opposed to generative
fuzzers that build semi valid files from scratch. The dumb part means it
didn't do cool stuff like AFL that use a genetic algorithm and probe system to
better test code paths in a target program.

> Is there a course or resource I can use to begin this path?

Search fuzzers online until you've seen every/most pages, no joke thats
basically what I did theres a few books but most of the info they have can be
found online for free. Also make sure to try building a fuzzer or two, go
simple at first. As well as using existing opensource fuzzers like AFL,
Trinity and syzkaller.

> How did you get into all of this?

I forget how I got into fuzzing but I did try and start a fuzzing company a
few years ago, but it turns out its way easier making money doing web
development then selling fuzzing software or doing bug bounties for a living.

[1]:
[https://en.wikipedia.org/wiki/Red_Queen_hypothesis](https://en.wikipedia.org/wiki/Red_Queen_hypothesis)

[2]: [https://patricegodefroid.github.io/public_psfiles/SAGE-
in-1s...](https://patricegodefroid.github.io/public_psfiles/SAGE-in-1slide-
for-PLDI2013.pdf)

[3]:
[https://en.wikipedia.org/wiki/Address_space_layout_randomiza...](https://en.wikipedia.org/wiki/Address_space_layout_randomization)

[4]: [https://support.microsoft.com/en-
us/help/875352/a-detailed-d...](https://support.microsoft.com/en-
us/help/875352/a-detailed-description-of-the-data-execution-prevention-dep-
feature-in)

[5]: [https://en.wikipedia.org/wiki/Return-
oriented_programming](https://en.wikipedia.org/wiki/Return-
oriented_programming)

[6]: [https://www.endgame.com/blog/technical-blog/rop-dying-and-
yo...](https://www.endgame.com/blog/technical-blog/rop-dying-and-your-exploit-
mitigations-are-life-support)

------
polishedcat
Ah, the old "trick a system process into overwriting a link destination" ploy.
That used to be a popular exploit method on UNIX in the 1980s.

~~~
lima
It still is a common vulnerability on *NIX

------
smpetrey
Yikes, that's a nasty one. Sad MSFT didn't want to pay bounty on this.

------
billpg
Exactly how terrified should I be right now?

~~~
luch
Not terribly terrified. At best it seem to be a Medium IL to SYSTEM. In other
words a slightly better UAC bypass than most, but I don't think you can use it
to escape from a browser sandbox for example.

~~~
dmix
People always seem to overlook this distinction... escalating admin privileges
is typically one of the easier things for a hacker to do. Getting in is the
harder part (ie, remote/browser exploits, etc).

~~~
3pt14159
(Hey dmix; hangs soon?)

I'm not really sure if that is true. Adobe exploits are pretty cheap and
unless your target is in software you can usually get a click on a link one
way or another.

Really, to me, the hard part is getting in without needing to have the user
consciously do _anything_ since then you're in and nobody could even have
noticed you doing something.

~~~
dmix
> Really, to me, the hard part is getting in without needing to have the user
> consciously do anything

That's why I said remote/browser, everything else is noisy and therefore the
'easy' route. Usually this is sufficient for low tech nation states because
they attack organizations not individuals, so all you need is a weak human
link where noisey isn't a big deal. Then moving horizontally across the
organization.

But more importantly OS are terribly insecure and privesc bugs are a dime a
dozen. You don't need zero days to achieve that the vast majority of the time.

~~~
3pt14159
Yeah, sorry, a no-click / _remote_ exploit is hard. I agree with you there.

But a _browser_ exploit isn't. They're a dime a dozen. Also, I'm surprised
that email is still a primary vector that's used to get people to click on
links with their work computer. It seems like such a monitored method compared
to, say, a LinkedIn contact.

