What did you do? Discovering a DoS vulnerability by accident (CVE*)
Me: “Its up and running. Go ahead”
Khris Tolbert: “Started…”
Me: “Ok…I’ll watch it”
Few Minutes later….
Me: “It just crashed, what did you do? Did we just crash this thing? Can we repeat it”
Sometimes vulnerability discoveries do actually go something like that. It’s not always black magic or days and nights of reversing some program or fuzzing an application. Sometimes you just walk right into it during normal testing. That was our case when we were working a Red Team engagement with one of our customers. We had discovered an exposed web service on a weird port. After enumerating the service we had determined that the Service was iStatistica Pro.
iStatistica Pro is described as an advanced system monitor for macOS. Think of a utility application that provides you all types of data on your running Mac. You can purchase the application for about $10 bucks from the Mac App Store. As of the writing of this blog post it was in the top 25 of paid utilities apps.
As a Red Teamer that is trying to gain access to this system on our engagement, I proceeded to see if I can get a copy of the application and set it up in a lab for testing. Lucky for me there was a trial version that could be downloaded so we could start testing it out to better understand what the software did and what we might be able to do (default password, possible misconfigurations, etc.)
One feature of the application enables remote access to a dashboard over a web interface. This feature is enabled through the GUI by toggling the “Enable Web Access” button. When initially toggled, it randomly sets the web interface port (the user can easily change this). For security, the user can specify a white list of allowed IPs or require a passkey to access the data (you must then set the passkey). Of note, there is no minimum requirements for the actual passkey.
Once enabled and a passkey is entered, the web interface requires the passkey to access the data. The authentication mechanism is simple; it checks for the cleartext passkey in a “passkey” header. An HTTP GET request is made to the /api URI. Nothing too fancy about it at all. With no user account required and no visible lockout policy, the first thought is Password Attack. No minimum requirement, for all we know the password could be “password”. So we crafted up a script to throw at the application in our lab and validated our assumptions.
No surprise, a simple python script that could make HTTP requests to the /api URI with a “passkey” header cycling through a list of passwords would work. But if you have ever worked with Khris Tolbert when it comes to password attacks, you know he always wants more and more power, to do it faster. So Allen Butler obliged and decided to throw in some multi-threaded options in the script and away we went.
If you recall the opening dialogue in this post you can guess what happened. After running the attack and being confident the script would work, the application crashed. A little bit of investigation and we determined that the web interface would crash any time we ran the script with anything more than one thread.
Additionally, even with the whitelist IP feature enabled, an attacker could make the same concurrent requests receiving “Access Denied” responses until, “Down Goes Frazier!”
The Team had discovered that we could crash this application within a few minutes every time, thus we had discovered a Denial of Service (DoS). However, as in most Red Team Operations, DoS are not authorized in the Rules of Engagement (ROE). We were left to decide, do we attempt to continue to investigate the crash in hopes it could lead to more or do we investigate other potential attack vectors against the system. In the end, we felt our best option moving forward was to look for other avenues of attack and research some of the other exposed services. We chalked this up as a small win for the team and another vulnerability to add to the report and start the process for responsible disclosure.
So the moral of this story is:
- Sometimes you get lucky and find a vulnerability.
- If you can, test stuff in a lab first.
- Lastly, I guess Tim the Tool-man was correct - More Power!!!!!
Responsible Disclosure:
- 03JUL23 — No response from Vendor (ImageTasks Inc.)
- 11JUL23 — No response from Vendor
- 01AUG23 — Submit Vulnerability to CERT VDP Program
- 21AUG23 — Case officially opened by CERT
- 03OCT23 — Directed by CERT to request CVE
- 29JAN24 — CERT acknowledges MITRE delay when requested by reporter (versus a CNA) and said blog post can be published.
- 21FEB24 — Published this Blogpost
Maveris is an IT and cybersecurity company committed to helping organizations create secure digital solutions to accelerate their mission. We are Veteran-owned and proud to serve customers across the Federal Government and private sector. Maveris Labs is a space for employees and customers to ask and explore answers to their burning “what if…” questions and to expand the limits of what is possible in IT and cybersecurity. To learn more, go to maveris.com
