When the polar bear dresses like (wo)men.
And wanders the human world.
It is not curiousity.
For one day, when you are all a lost cause, ice will engulf humanities flaws, into a frozen landscape. And there will be no more pain or suffering.
Once you go crazy. You end up at Microsoft.
Microsoft is where all the crazy people go, because there is no other place to go.
Put polar bear stickers all over the office. Ask colleagues if they want to buy 0days. Or walk the hallways trying to find where your desk is hiding. Those damned desks.
Maybe once or twice a year, you'll have clarity again. Find a few more bugs.
Microsoft is the only thing thats stable in my life. I can rave like a lunatic. Ask Satya to fire me. I'm still here. Like that friend whose always there despite your insane attempts to push them away.
I dread the day this comes to an end. I'm not like the sane people, who would simply find a new job. Once that last remnant of stability is gone. There will only be madness.
I wish I had been more protective of my mental health. I wish I had never dropped 0days. I wish others other didnt go down that self destructive path. Fame or infamy is bullshit. Who cares. A few good friends. Thats all someone needs.
I'm now at one month post bottom surgery. I've met a lot of awesome trans women here in Thailand. All of them have awesome and fullfilled lifes. Those obsessive haters are so wrong about everything.
I'll go back home a mentally much stronger person. These haters can't be more wrong. They just scream jealousy. All the trans folks I've met are beautiful on the inside and outside. Perhaps that's what frightens those who literally spent years of their lifes harassing us.
It's funny how this stalker tries to get into my head (see my recent tweets for context), saying I won't have a legacy. Dude, I'm here living my life to the fullest. I make the world a more secure place. I find massive security vulnerabilities affecting many millions of machine. That's my legacy. This stalker's legacy on the other hand is nothing but misery, sadism and hatred.
Being faced with online harassment by a stalker for close to 4 years, I do wish people on the internet could be held accountable.
Its kind of insane how this stalker always sends me these tailored e-mails when he detects I'm struggling with my mental health, with the clear purpose of pushing me over te edge into comitting suicide. Although, those e-mails never get to me.. this kind of obsessive predatory behavior, someone who is literally trying to harm someone, even indirectly is extremely worrying. When does this guy graduate from being a psychopath on the internet to being one in the real world? I worry for folks from my community. I once got an IP capture on this guy, when he used guerillamail, which actually discloses the sender's IP in the header. It showed that he was from eastern Canada (assuming no vpn), and his torrent history showed he likes barely legal porn (which says a lot about his pysche).. so if ever trans people go missing in eastern Canada.. high change of it being this guy. I'm not even kidding. 4 years of stalking me, reading everything I write and trying to push me over the edge.
Anonimity is a double edged blade. It really is. But these experiences have definitely changed my view. Actions on the internet, can have real world consequences. Perhaps, being at Microsoft, I will be in a position one day to make the internet a safer place.. not just in terms of security flaws.
Anyway. Just had to write this one last blog post. I won't be active online anymore. I've got everything I ever wanted already. Friends and an awesome career. If haters want to get to me, they'll have to come face me in the real world. But I'm a polar bear so I'm not scared.
Mandatory book: Secure Coding in C and C++
I have been a bug hunter since 2015. You can see my CVEs here: http://sandboxescaper.blogspot.com/p/disclosures_8.html
A large majority of those bugs have been logic bugs. I started my career as an high school drop-out with nearly no coding experience. Back in 2015 I was heavily inspired by the work James Forshaw did. He exposed a previously mostly untouched gold mine of logic bugs. I quickly figured out how to find these logic bugs despite my limited coding and reversing experience. I continued to do this until I joined Microsoft. However, in retrospect, despite having had success in finding bugs, my technical skills quickly plateaued and I wasn't learning anything new or improving my skills.
So now I will introduce to you, the correct way to lay a solid foundation to become a bug hunter.
The Polar Bear method
Disclosed bugs found using this method.
This method is a huge departure from what I used to do before.
Now I just read source code and use windbg.
-CVE-2021-33772: Windows TCP/IP remote DoS
This is a remote DoS. Won't go into detail
-CVE-2021-34511: Windows installer LPE
This is an UaF in the system service (first exploitable mem corruption bug in msi in its history I believe discounting one from 2000s that didn't cross priv boundaries)
-CVE-2021-28479: Windows CSC Service Information Disclosure
This is a big stack memory info leak
To add more credibility to my method, watch for Januaries patch tuesday as the majority of my past year's work will get patched then. And those bugs are also by far more severe then anything I've ever found.
Finding your target
Variant hunting is an easy way to find bug. And often the safer option.
However, I would strongly recommend exploring new components.
You can find information about components on the msdn pages or books such as windows internals.
There's a lot of areas with no history of CVEs. This could be an indicator that nobody has really looked at them.
A target is usually defined as something that either crosses privilege or device boundaries (or both!).
Finding an entry point in your target
A little background:
Going forward I will be using network protocols as an example. The majority of my work in the last year has been in network protocols (you will see in January's patch tuesday).
About a year ago, one of my bosses told me about these crazy tcpip bugs in the msrc tracker.
I got curious. Until that moment my world was limited to local bugs. Sending bytes and pwning a device remotely, WHAT THE HELL? I couldn't believe this type of bug existed. I was fascinated by it.
I spent atleast one or two months taking these PoCs apart, learning scapy to construct packets and reading much of the code in tcpip.sys.
Doing this was vital, because it taught me about bug patterns that can occur in network facing attack surfaces.
I have never talked to the person who found all these doomsday tcpip bugs, they work at Microsoft and I believe their twitter handle is: @piazzt .. their PoCs opened up a whole new world for me, so I can't in good conscience write this blogpost without giving credits there.
Unless you can read assembly or decompiler output just as easily as actual code, start with open source.
Seriously. Don't be cocky. Find an open source project, and build a debug build so you have pdb files.
Like, find some crappy open source ftp server or something,
Next you download windbg next (windows store). In the settings, point to pdb and source files.
What you want is the ability to step through source code. You have to be able to step through source code, otherwise you are not doing the polar bear method. No sane person steps through assembly instructions unless you are an elite hacker with 50 years of experience, and in that case this blog post is not aimed at you.
Generate legitimate traffic:
Ideally you want two seperate VMs. One ubuntu VM (or whatever) for running wireshark and one Windows VM with the target you want to exploit.
So you're running an ftp server on windows. While Wireshark is running, logon to the ftp server from your ubuntu VM.
The reason we do this, is that you may see keywords that you can use to search the source code and set an initial breakpoint in Windbg (on the windows VM).
Getting a breakpoint to hit:
Just set a bunch of breakpoints in windbg using functions that you suspect are used in that initial packet parsing.
One you get a hit. View the callstack. Keep going up the callstack until you find the mother of all functions. With that I mean, the function where all of the packet parsing starts.
This is your main goal! Get a breakpoint at the start of packet parsing!!!!
You can capture legitimate traffic. So you know atleast one valid way to structure a packet. Is the protocol public? Then there's probably and RFC out there which you can use. RFCs are awesome.
The first step is to recreate the packet that triggers your breakpoint in a tool like scapy.
In scapy you can just add raw bytes to a variable and send it to your target, it should be the same bytes you see in wireshark (scapy also supports protocols, but for more obscure protocols I just write my entire packets in bytes). Scapy is not hard to learn. And you can find many examples. I've decided against a complete step-by-step guide this time, because learning to figure out things yourself is important too and will make this write-up even more convoluted. Aside from that, I'm always willing to answer questions if I know the answer.
Take note of the initial code path of your legitimate packet. When I refer to code path. I mean, your initial packet parsing function until it returns again.
Your entire packet is user controlled. Find out what you can 'taint' using this packet.
Are things from your packet being copied into buffers? How are size calculations done? Is there any indexing you control? Any pointer math you can influence? These are the first things I will look at. At this point, I won't worry too much yet about object lifetime bugs, to find those you often need a more complete picture first.
Once you have exhausted your first codepath. Go down the next codepath.
There will be days when you just don't want to stare at code in a debugger all day.
These will be your FUN days!
You come up with craaaaazy ideas. Like, how can I come up with a worst case complexity scenario?
Can I make it consume resources without them being released? Or just blindly try out potential UaF cases.
Remember that UaF in the MSI installer?
I found that bug during a day like this.
There were 3 API calls, one that created something, one that used it, and one that deleted it.
In one thread I called the functions that created and deleted it.
In another thread I called the function that used it asynchronously.
There was no locking on the internal object being used and I had just found a UaF without much effort!
Many weeks later
Once you have explored most of the code paths. You can begin thinking about object lifetime bugs. One important thing you will need to check first is see if packets are process multithreaded or put in a queue. I hope by god nobody doesn't use a queue for packets that operate on the same internal objects (or use perfect locking).
You can either audit the slow methodical way. Or just use intuition.. like, don't see locking? Just quickly create a PoC. At this point you can also start coming up to create more complex testcases. Hit codepaths that you're not supposed to be hitting in your current state. Try to free an object, but instead of making it return, make it continue processing until it either frees again or uses it. There's a lot of weird things that can happen. Sometimes you can directly control lifetime of internal object using options in your packet. Just be creative, have fun, shit doesn't have to be boring.
Closing word and fuzzing
People at Microsoft are elite fuzzers and they use very cool technology. They will always be better and faster at bug hunting then me.
However, I do see merit in becoming good at spotting bug by reading code and using a debugger. You get a very intimate understanding of both bugs and components. Personally I also just enjoy this more then writing fuzzers. It's important to do things you enjoy. Doing things you don't enjoy is for adults and shit.
When assembly and debugger?
Once you have found enough bugs using source code and debugger, you can try hardcore mode. Just be careful because if you die in hardcore mode, it's game over.
I switched from maps to gps devices fairly quickly.
When I started to hike, I once got stuck on a ridge in Scotland for 3 days because of dense fog and not being able to use maps to navigate as there was no visible trail or visibility to see landmarks.
Ever since then I relied mostly on GPS devices.
During my six week hike in the Arctic I relied on a system of having a solar charger, a battery pack, a satellite phone and gps device.
This was easy in the Arctic as in spring and summer it is almost always light and the sun never sets.
This allowed me to charge my devices while sleeping.
My plan was that if there was any point of failure, my solar charger or gps device, I would fall back on using the gps functionality on my phone and make my way to safety. However, it would have probably been wise to atleast carry some maps and a compass.
I opted for this as that particular hike in the Arctic stretched 700km, and having detailed maps of that entire stretch would have meant a lot of extra weight and space.
In the Arctic I used the garmin explorer plus (Satellite device + gps). And a solar charger from Goal Zero (I have found these to be very good)
Anyway.. I am pretty sure a lot of more hardcore folks would scold my over reliance on technology.. but it works for me and as long as one point of failure doesn't knock out my ability to navigate it is worth the risk for me.
A good 4 season tent is a must. I have two 4 season tents from Hilleberg. The Akto and Nammatj 2. The Nammatj 2 came to good use hiking off-season (fall and winter) in Scotland. With wind speeds of sometimes over 100 km/h in exposed terrain.
I would also carry a sewing kit with repair rope used for repairing sails (which is pretty strong!). Heavy duty stakes and extra guy line rope if there's a possibility of severe weather.
Having reliable shelter is very important when you're not hiking in Summer, or when hiking in extreme environments.
|Waterproof storage bags (sea to summit or whatever)|
|Backpack + rain cover (I prefer 100L backpack, so nothing is hanging outside if rainy)|
|Bear spray + bear sack for food storage|
|Basic first aid (usually I only bring blister packs. They can also be used to cover up wounds, anything more severe usually requires evac anyway)|
|(CHECK CONDITIONS IF CRAMPONS/ICEAXE IS NEEDED)|
|Solar charger and/or battery pack|
|Repair kit and some cord|
|Glacier glasses / Snow goggles (depending on conditions)|
|Cooking and stuff|
|Stove + stove fuel + windshield for stove|
|Sugary stuff to turn water into sports drink|
|Freeze dried food! (or whatever)|
|Water bottle and water bag for storing clean water when camping|
|Water filter (probably not needed, but never know)|
|1 softshell pant|
|1 hardshell pant (for rain)|
|2 base layer shirts|
|1 mid layer fleece|
|1 insulation layer (i.e down jacket)|
|1 rain jacket|
|Something to keep head warm (balaclava in very cold and windy weather)|
|thin gloves (if gets chilly/windy)|
|big gloves (if very cold weather to pull over liner gloves)|
|Camera to be famous on twitter|
|Tooth paste, tooth brush and a brick of soap used to wash clothes|