#NotQuite0DayFriday

By -



In our spare time, we like to hunt for bugs in various pieces of software. To help teach people this skill, we decided to write up our analysis on some of the crashes we find. The goal is to help people learn how to debug, analyze the problem, determine why it’s happening, and what the impact is. For example, is this just something which will cause the software to crash and merely cause a brief denial of service, or is this a vulnerability which can be exploited to take complete control over the computer?
We follow NIST’s example and privately disclose the details of the issue to the software producers and then to the public either when the vendor tells us the issue is patched, isn’t going to be patched, or 45 days elapses. This is intended to protect the software users.
We call it Not Quite 0-Day Friday because most of the bugs are 0-day vulnerabilities when we find them, but recently patched when we release them. So they’re not quite 0-days at the time of release. Most of the time the issues are patched quickly and a new release is pushed out to users within a matter of days, but there have been some cases where the vendor didn’t patch the issue within the 45-day deadline in which case they were still 0-days at the time of public disclosure, but these are the exception, not the rule.
Why do we do this? Finding bugs, coordinating disclosure, writing up and publishing details on the issue and the impact doesn’t pay the bills, but there are several reasons we do this anyway. First and foremost, we think it’s fun to find the bugs that everyone else has overlooked and figure out what can be done with them. We also like teaching others how to do this type of work so they can join us in finding bugs. It also serves as a public demonstration of our technical skills. There are a lot of people and companies out there who make a lot of tall claims and it can be difficult to tell who is all hype and who is the real deal. We hope that other companies out there who can walk the walk will join us in publishing some of their work. Finally, it arguably makes software more secure in a number ways. The bugs we find are generally getting patched as a result of this work. If others join in and help scale up this effort, it helps the software vendors who do invest in security stand out amongst their competitors and gives users the ability to make an educated decision, rather than a decision based on marketing and propaganda. Ultimately, we think that #NotQuite0DayFriday is an effective tool for educating the general public, teaching our colleagues, and hopefully, making the Internet a safer place for all of us.

Popular posts from this blog

New Old Bugs in the Linux Kernel

By Anonymous -
Image
  Introduction Dusting off a few new (old) vulns Have you ever been casually perusing the source code of the Linux kernel and thought to yourself "Wait a minute, that can’t be right"? That’s the position we found ourselves in when we found three bugs in a forgotten corner of the mainline Linux kernel that turned out to be about 15 years old. Unlike most things that we find gathering dust, these bugs turned out to still be good, and one turned out to be useable as a Local Privilege Escalation (LPE) in multiple Linux environments. Who you calling SCSI? The particular subsystem in question is the SCSI (Small Computer System Interface) data transport, which is a standard for transferring data made for connecting computers with peripheral devices, originally via a physical cable, like hard drives. SCSI is a venerable standard originally published in 1986 and was the go-to for server setups, and iSCSI is basically SCSI over TCP. SCSI is still in use today, especially
Read more

Automated Struct Identification with Ghidra

By Anonymous -
Image
At GRIMM, we do a lot of vulnerability and binary analysis research. As such, we often seek to automate some of the analysis steps and ease the burden on the individual researcher. One task which can be very mundane and time consuming for certain types of programs (C++, firmware, etc), is identifying structures' fields and applying the structure types to the corresponding functions within the decompiler. Thus, this summer we gave one of our interns,  Alex Lin , the task of developing a Ghidra plugin to automatically identify a binary's structs and mark up the decompilation accordingly. Alex's writeup below describes the results of the project, GEARSHIFT, which automates struct identification of function parameters by symbolically interpreting Ghidra's P-Code to determine how each parameter is accessed. The Ghidra plugin described in this blog can be found in our GEARSHIFT repository . Background Ghidra is a binary reverse engineering tool developed by the National Sec
Read more

SOHO Device Exploitation

By Anonymous -
Image
Netgear R7000 SOHO Device Exploitation After a long day of hard research, it’s fun to relax, kick back, and do something easy. While modern software development processes have vastly improved the quality of commercial software as compared to 10-15 years ago, consumer network devices have largely been left behind. Thus, when it’s time for some quick fun and a nice confidence boost, I like to analyze Small Office/Home Office (SOHO) devices. This blog describes one such session of auditing the Netgear R7000 router , analyzing the resulting vulnerability, and the exploit development process that followed. The write-up and code for the vulnerability described in this blog post can be found in our NotQuite0DayFriday repository. Initial Analysis The first step when analyzing a SOHO device is to obtain the firmware. Thankfully, Netgear’s support website hosts all of the firmwares for the R7000. The Netgear R7000 version 1.0.9.88 firmware used in this blog post can be downloaded from this web
Read more