How I found 15 CVEs in 3 nights and how YOU can too.

The internet is a massive thing. It’s constantly evolving, changing and growing. If you’ve ever done a internal or external penetration test engagement you’d know about the bizarre services, software’s, technologies and applications that organizations use. Whether it be county, state or federal government, Fortune 10, 100, 500 or not even being on the list, every single engagement with an organization is different.

It’s there where most journeys of CVEs discovery start. As a security consultant, security engineer or penetration tester you have a extremely unique perspective, talent and opportunity. You get to see the obscure, the utilized, the expensive technologies that are being used behind the scenes (or that once were) of all kinds of organizations. You have the critical mindset, you are interested in the details, you are patient. My suggestion, note these technologies, note these vendors and research them in your free time. (Looking at you [the infamous] ManageEngine!!)

If I told you that my first two CVEs, CVE-2017-16744 and CVE-2017-16748 were from a >$50,000/license software (Tridium Niagara) would you believe me? Would you think that I paid that to test the software? Or that I worked for Tridium that makes it?

Well I didn’t pay for a Tridium Niagara license or work for Tridium either. I had the opportunity to test this software because of a external penetration test I was performing against a government entity. I was thorough, stuck by the basics, paid attention to my Burp Suite intruder results and that led to both a Path Traversal and Improper Authentication vulnerability being discovered. At the time, the last Tridium Niagara vulnerability was found in 2012 and was a 0-day used against Google Australia.

To me this was massive and although it is attributed to 2017, I discovered it within the first year of my professional career. I couldn’t be happier at the time and I was proud of my accomplishment.

This achievement sparked the beginnings of my unique methodology when it comes to any offensive security engagements; Downloading software or software trials when possible and using that to create wordlists and discover attack surface is one my staples.

Of course I’m not the first one to come to this conclusion, and often IoT/hardware penetration tests include this, (Joe Grand is a great example of that). However in my seven years of being an consultant, I have yet to have met one other consultant who shares this step in their methodology especially when it comes to External/Internal/Web Application penetration tests.

Now obviously I couldn’t nor you can’t download a trial or a copy of Tridium Niagara as it costs an INSANE amount of money so I’m not going to go into any more detail of those vulnerabilities (or how exploit-db asked for a copy of the software when I submitted my PoC to them, like I had a copy of the 50k software lying around!) But you can read some more details about the CVEs HERE if you’d like.

HOWEVER, I can tell you how I managed to find 15 CVEs in 3 nights over the course of 3 weeks in 2022.

  1. Look for the less popular, the less used, BUT default installed.

In my case, CVE-2022-34108, CVE-2022-34109 and CVE-2022-34110 are all from MSI Feature Navigator. You know, the software running when you visit Best Buy and play with the (MSI) laptops. These vulnerabilities are not public yet, as I’m giving MSI a responsible amount of time to respond to my emails but they will be in ~1.5 months if I don’t hear back. That said, obviously MITRE has already accepted and reserved CVEs for them.

How I found these was literally looking at the default software/applications installed on my gaming laptop out of the box. What functionality the applications have and what vulnerabilities have been discovered within them.

Then utilizing basic reverse engineering , basic thick client-ish penetration testing , CWEs and most importantly a critical view I found a vulnerability immediately.

The other two lead me to my second although NOT necessary point

2. Two brains are better then one. Whether that be two experts, or one expert and noob to teach.

The other two CVEs relating to this software came from walking through a trusted co-worker that I was willing to share details and split credit with. I walked him through the functionality, I tested some stuff relating to the first vulnerability I found , he suggested some stuff to try, we bounced ideas back and forth and that lead to two other vulnerabilities being found.

CVE-2022-34615, CVE-2022-34621, CVE-2022-34623, CVE-2022-34624 CVE-2022-34613, CVE-2022-34618, CVE-2022-34619, CVE-2022-34625 were all found in one sitting. The first four have yet to be published but will be within the next few weeks while 34613, 34618, 34619 I posted about HERE and 34625 I posted about HERE. To be honest again it isn’t like we typed together to find every one of these. In fact a large vulnerability, Path Traversal to Arbitrary File Write, was purely my co-workers discovery and was never even submitted although it was ultimately used in chaining the Server-Side Template Injection (SSTI) to Remote Code Execution (RCE). That discovery made the RCE possible with a lower privilege user greatly increasing the severity. If that isn’t teamwork, I don’t know what is.

Continuing with this point, I have been teaching a friend of mine about web application penetration testing and so we attacked some open source web applications together. We ended up waking away with three CVEs! We shared credit because there was definitely some cases where talking through what I was doing helped the both of us! Specifically CVE-2022-35142, CVE-2022-35143, CVE-2022-35144 which I posted about HERE and CVE-2022-34009 which I posted about HERE.

Now I really want to stress that a “partner in crime” isn’t NEEDED at all. Do I think I would’ve found all the vulnerabilities regardless? In these cases yes, but I only say that because nothing is insanely technical or left me feeling lost. Would I have found all these CVEs in the same amount of time? There’s no fucking way.

Let’s move on to point three!

3. Practice makes perfect, Basics are king, Develop your own methodology!

I hack shit for a living, everyday, for many years. I hacked shit for fun, before I was a consultant for years. The point is, I have been practicing both the hands-on technical side of “hacking” and the critical thinking, soft skill side of “hacking” for a long time. Work both the soft skills and technical skills as much as your comfortable/happy doing. Every little bit helps. Running commands, using a CLI over GUI (CLI>GUI imo), looking at the code, setting up infrastructure, it all adds up! Looking at both my co-worker who has a few years in the industry and my friend who has zero years, each of us bring our own value and each of us practice in our own way. The point is to practice, not how long you practice for.

Do not underestimate the basics. That does not mean running a nikto scan everyday. That means learning to actually understand your gobuster, dirsearch or Burp Intruder results. Learning what to actually test for, what to focus on during the “discovery” phase of the engagement, etc. If you don’t know what you’re looking for, you won’t see it a lot of the times. None of these findings required some new XSS polygot or some crazy shit like that. Just thorough testing.

SecLists, Burp Extensions and so on are great! They really are! But stop relying on them completely. There are SO many applications that SecLists does not have a wordlist on, so download the fucking software and make one yourself! Download a software on a VM and compare it to the installation you’re testing. Take fuzzing files/wordlists and add your own entries! I can’t tell you how many times the RTLO entries on my starting fuzz wordlist (Line 1161 and Line 1162) causes an application to do something it isn’t supposed too. And guess what?! Line 1161 (and RTLO) in general is GREAT for file names/file types and anything else you can think of! Here is my file uploads utilizing RTLO that lead to some of the CVEs I found HERE. In fact, there was those awesome (although semi-trivial) RTLO vulnerabilities which I had a few quotes published about in 2021. I’ve had a few of my co-workers already come and tell me how useful those two lines alone are in my starting fuzz wordlist.

Finally my last point I’m going to make in this post!

4. (Open source) popular applications; check their CVEs

There are so many sites that contain “alternatives to” so why not search something like “alternative to Apache” and see what comes up. Why not check if there’s any CVEs or exploits relating to it? Why not download, install, configure and poke around if it looks prime for the picking?

The most important thing when you take this path is to follow responsible disclosure guidelines as outlined by the industry, your employer or your personal morals. I wouldn’t suggest toeing the line or disregarding ethics but it’s your career and your life so do you.

Alternatively instead of poking at closed source software (and my recommendation) is to check lists like Awesome Self-Hosted, picking a popular open source application and looking up if it has CVEs or not. If it doesn’t (or doesn’t have many or recent ones) use Heroku, Docker, Manual install to a VM or however you want to deploy it and start going crazy! In this case you can run static analysis tools and do manual source code review as well!

You’ll notice most of the CVE-2022-* I found, I took the open source path!

Hope this is helpful and don’t hesitate to reach out with any questions or concerns!

END TRANSMISSION

Leave a Reply