To start, I won't say who the exact company is for legal reasons. I really don't feel like getting sued. I do feel like talking about a common situation of developers not caring about the product their company produces. Now I'm not going to say the devs behind this software are trash because there can be a number of reasons that explain why an application comes out as insecure (i.e. harsh due dates, lack of knowledge, horrible bosses, etc.). I am going to explain, however, that the company's response to a potential security threat to it's customers isn't the proper approach for any company. For the love of God, listen to security researchers!!!

The Vulnerability

The vulnerability lies within a classic Windows vulnerability, unquoted service paths. For those new to it, it occurs when a services executable path has spaces, but doesn't have quotes. The space acts as a delimiter. Without the spaces, the path allows regular users to potentially add a malicious .exe to one of the parent directories to where they can restart the service the file path is originally intended for or restart the computer if the service is set to auto-run on start. Seems kind of odd, but let's dive deeper. What does this look like?

Vulnerable Printer Application

The image above shows what the printer application looks like. As we can see, it relays basic printer information like ink levels and the status of printer or a currently queued job. Seems like a nice, useful application that probably didn't need a full, stand alone application for such a small service like this, but I don't mind.

How Did I Come Across This?

Well, I was minding my business. Working on a Windows Internals class for things when I wanted to provide a nice case-study of a common vulnerability. So I came across a one-liner to search for any vulnerable services (shown below) and BOOM! POW! KERCHOW! This showed up in my terminal:

Oh Noes We Have a Vulnerable Path
Oh Noes We Have a Vulnerable Path

 To my surprise, my first thought was "oh snap, I got got by a H@X0R!" From here, I initiated my own checks to ensure there weren't any unknown outbound connections over a 24 hour time period or any unnecessary processes running + an anti-virus scan. After they all came back clean, I began my investigation into this.

How Windows searches for an Executable to Run

This is how a service is laid out in the registry.

Registry Layout
Registry Layout

Registry keys for services are stored in "\HKLM\SYSTEM\CurrentControlSet\Services." As you can see, we have a path that is two directories deep until Windows finds the .exe to execute. As the CreateProcess() function is called in the compiled application it searches for the first .exe it comes across from left-to-right then appends that .exe as the end of the file path. Now, whatever the first executable, no matter the name, is executed and the user is set up for a huge privilege escalation vulnerability. In this case, after "Common Files", we see that are two directories. Theoretically, once you enter the first directory, it's game on. Alright, we have our vulnerability squared away. Now it's time to let the company know because it's a quick, easy fix.

"Hello. Operator? Yes, we have code 0, call the engineers."
"Hello. Operator? Yes, we have a code 0, call the engineers."

Reporting

It's not uncommon for hackers to do the right thing. However, when a hacker does try to do the right thing, don't become shut them down. You messed up, it happens. Now let's work together to fix the issue for the greater good.

It's about 1300 EST. This company is based on the west coast (US obviously). Time should be fine. I find a company number that was reasonable to call. Customer support/business line. I don't have time to dig through a companies call roster to find Joey Bag-Of-Donuts in IT. Dial in and call the line to be patched through to a rep with an Indian accent. I can hear other Indian accents in the background. Great, they outsource their customer service. Priyu asks about the issue. I explain that there seems to be a flaw in the status software. She's already confused. "Ok Priyu, is there a way you can let me talk to the engineers or someone in IT about this?" She put's me on hold to talk to her manager. After 20 minutes of presumed deliberation if I was worth the time, they give me a shot. I go on hold once again while they try to contact the engineer team in California for about an hour. I'll play along because I, somehow, actually care to help this company. She comes back on the line. "Hello, yes, we're having trouble trying to reach them, let us try to contact someone else." Sweet, this lady actually cares. After another 30 minutes of mildly soothing jazz, she's back. I can hear her manager saying something to her in the background. Definitely, don't like the tone in Samid's voice back there... In a jumbled hurry, "Hello, Brian? Yes, our software is not vulnerable to any malware and is totally fine and never will be because our engineers are great. Have a good day."

Uhh what?

Priya, my girl, c'mon. Why you gotta do me like this? With a response like that, I can't really care to help the company anymore. I'm out, yo. DEUCES. It takes a special kind of ignorance to produce a response like that. Maybe it was because the call center in India also got frustrated. For the uninformed, India is ranked as one of worst "Cyber-Secure" countries in the world. Sure, they produce great engineers, but the country's cyber security as a whole is straight up awful. If you want a real case study on this, check out @fs0c131y's crusade against the Indian government's websites/mobile applications. Probably one of the funnier twitter beefs to happen in recent days. Maybe, the company genuinely doesn't care. Either way, I don't really care anymore.

Given the circumstances, I have a couple options. Go through Mitre's responsible disclosure program and register it as a CVE, sell the vulnerability which affects a very large portion of consumer owners, or hold on to it. I could get some cred in the industry with option one, but I really don't care for having a pissing contest with other people. I could make some money with option two, but morally and ethically, this doesn't feel right to me. That leaves me with option 3, which I am currently at and teaching off of. I've moved on from it, but it taught me a lot about how to go about responsible disclosure.

  1. Be patient
  2. Try to contact more than just the customer support line (I just don't care enough)
  3. Be cool about it. I'm no all masterful hacker. After all, I stumbled upon it, definitely did not hunt for it in this application specifically.

Oh well, sucks to suck large printer company.