Confessions of a Zero Day Initiative Bug Hunter

[Nytro]

Confessions of a Zero Day Initiative Bug Hunter

Brian_Gorenc| October 23, 2013

A lot of people would argue that making a living out of solo, full-time bug hunting for the Zero Day Initiative is hard. It can be stressful at times, just like any other job, and if anything, it requires more dedication – a lot more. However, from my personal experience, it’s fun.

Motivation

The first bug I submitted to the Zero Day Initiative (ZDI) program was on 2005-10-02, and it was refused. At the time, the ZDI program was not interested in that specific product. The first bug that I submitted to the ZDI that was purchased was on 2009-08-01, and it changed my perception of bug bounty programs. It was much more rewarding than I expected. Back then, ZDI bought that first bug for approximately $2k - which was more than I earned in an entire month working in Lebanon.

It seemed that this bug-hunting game could be quite rewarding, so I did it again and sold my second bug to ZDI. I loved this idea, and I remember wanting to quit my job and hunt for bugs full-time. Later, I was given this opportunity when I moved to Canada for personal reasons.

Finding a job in Canada was a bit hard due to the French and Canadian experience requirements (of which I had none). So luckily, this was my chance to bug hunt full-time. I spent a year and a half as a bug hunter, submitting to ZDI and other bug bounty programs and made a decent living at it.

Of course, there’s more to bug hunting than just the money. Being credited for finding a bug is equally rewarding, and it helps to build your profile.

Picking targets

Initially, I started picking soft targets—this allowed me to find bugs fast and maintain a stable income. A “stable income” means finding at least 3 bugs per month. I usually checked ZDI’s list of selected vendors and then made my pick. Today, I would look at the ZDI published advisory page for guidance on which targets to audit.

It’s always frustrating when you spend some time auditing a product, and then you submit a bug and it gets refused because the bounty program isn’t interested in that product. I would sometimes submit a bug, and then if it was accepted, I would go ahead and audit for more. You can also email the bounty program and ask them if they’re interested in a certain product before you do any auditing.

At the time, I mainly focused on IBM/SAP/HP/Citrix and had some success finding bugs in their products. Most of my initial vulnerability discoveries were in server side products. As I got better, I started exploring client side applications and spent a lot of time reversing Microsoft Internet Explorer.

Good reports vs. bad reports

As a researcher, I’m an example of someone who used to submit bad reports. I got better over time, and I’ve learned a lot since I started. Submitting good reports to bounty programs increases the potential bounty, and decreases the analysis time required by the bounty program (so it’s good for everyone).

Some bounty programs are willing to provide feedback on bugs/reports you’ve submitted. This feedback can be a really helpful resource, and can teach you a lot about research. I’ve had a lot of bad reports back in the days—here’s one of my awesome bad ones (this has been disclosed and was a duplicate of another ZDI submission at the time):

CA XOsoft Replication and High Availability r12.5 pre-auth buffer overflow

Overview: 
From the vendors site:"Whether you're looking to ensure the business continuity of your Microsoft Exchange, Microsoft SQL, Microsoft IIS, Oracle or any other file or application server, CA XOsoft solutions will provide you with just the level of disaster immunity and application availability you need."

The Bug:
XOsoft fails to handle exceptional conditions when sending a long domain/username in the login form of its web application.  The bug exists in mng_core, which is loaded by ws_man.exe the CA XOSoft control service that listens on TCP 8088.  When sending a long domain/username a SEH will be overwritten. When an exception happens our SEH kicks in thus controlling execution.
A snip of the SEH chain is as follows that shows a SEH has been overwritten:

SEH chain of thread 000009D0
Address SE handler
030BFF58 mng_core.036691A1
030C385C 41414141
The exception happens here:

03522118 8B06 MOV EAX,DWORD PTR DS:[ESI]
0352211A 8B50 50 MOV EDX,DWORD PTR DS:[EAX+50] //boom, where EAX is controlled.

Please find attached a PoC for this issue.

Regards,

This report clearly showed that XOsoft had an issue but was missing several key items that would have resulted in a quicker turnaround time and a higher bounty. I could have provided better information about the root cause for the crash and the exact reason it happened. In addition to this, I could have provided a description of the protocol used and any additional vectors to reach this vulnerable code.

So what does a good report look like? Ideally, a good report is composed of the following details:

1. Program version
   
2. Download link
   
3. Tools used to find/debug the bug
   
4. Where/why the crash happened
   
5. Exploitability
   
6. PoC
   
7. Exploit (optional)
   

In future blog posts, I will go over some of my more complete reports and provide tips to get the most out of the Zero Day Initiative.

-- Abdul-Aziz Hariri, HP Security Research

Sursa: Confessions of a Zero Day Initiative Bug Hunter - HP Enterprise Business Community