Chapter 1: A Journey Begins

In the realm of cybersecurity, the landscape is often smaller than it appears at first glance.

To contextualize, let’s revisit the first episode where I emphasized the importance of networking in securing your initial role as a Cybersecurity Consultant. Today, I will delve into my experience with Opinium and Tesla, detailing how I uncovered four Remote Code Execution (RCE) vulnerabilities, including two that granted root access. These discoveries were made just two weeks ago, highlighting a zero-day exploit in custom software known as BFLA, along with Insecure Direct Object References (IDORs).

Fictitious Names Used for Privacy:

• Opinium: A staffing agency
• Tesla: A prominent electricity provider in Western Europe, amidst several others.

The Background Story

While searching for a job, I initially interacted with staffing agencies rather than direct clients. This detail significantly influenced my chances of landing a position. These agencies would present candidates to clients for cybersecurity roles, but the ultimate decision rested with their business partners.

I can't recall how it all began, but during my engagement with Opinium, I felt optimistic after receiving a signed offer letter. However, confusion arose when I was told to interview with Tesla, Opinium’s business partner, despite having completed four rounds of interviews with Opinium.

On the day of the Microsoft Teams meeting with Tesla, I naively thought I had secured the position, only to discover that it was a mere evaluation of my skills by Opinium to determine Tesla's interest. Unfortunately, Tesla decided I wasn't a good fit, leading Opinium to retract their offer.

A Twist of Fate

After a frustrating period, I received a far better job offer, which I accepted immediately. Shortly after starting at my new company, a leading consulting firm, I was tasked with uncovering vulnerabilities. To my astonishment, I identified a zero-day and two root RCEs within Tesla’s systems.

As I read through the subsequent emails, I noticed the names Opinium, Tesla, and Frank—the representative from Tesla who had evaluated me. I realized I had compromised the very organization that had once deemed me unqualified because, in their words, "I had much to learn about CS and needed certifications." This moment motivated me like never before to excel in my hacking endeavors.

Technical Deep Dive: Log4Shell Vulnerability

My exploration began with testing various web applications for Tesla, where I discovered an information disclosure vulnerability. During this process, I noticed Java frameworks in use. I promptly suggested to my manager that we could leverage this for an RCE attack, though he was skeptical about Tesla being vulnerable to Log4Shell, given the company's reputation.

The next day, while examining another application, I encountered a familiar pattern. This time, I bypassed discussions and directly initiated an RCE exploit. By meticulously inspecting various endpoints and monitoring traffic via a proxy, I successfully injected a payload, achieving one of the two root RCEs.

Phases of the Log4Shell Attack

While many might consider stopping there, my curiosity drove me to dig deeper. I meticulously documented my findings, preparing comprehensive reports with screenshots for the client. My next objective was to achieve an XSS exploit through a different endpoint.

However, I faced application crashes and shifted my focus to SQL Injection (SQLi). Confirming my suspicions, I discovered the application was indeed vulnerable. Utilizing SQLmap, I accessed extensive data, uncovering a zero-day exploit in a third-party software widely used for document management.

BFLA: A Vulnerability Worth Noting

One of the most intriguing vulnerabilities I found was related to application headers, often overlooked by administrators. After analyzing user level definitions, I used a POST request to modify the request body, effectively exploiting this weakness.

Transitioning to Vertical Privilege Escalation

With my access limited, I explored further and discovered a way to exploit a PUT request, which allowed me to manipulate the system. Upon logging back in, I was astonished to find that I had been promoted to an administrator role.

Exploiting APIs for RCE

Recently, I uncovered two RCEs within Tesla’s API, identified just two weeks ago. These vulnerabilities were particularly satisfying because, unlike standard web applications where documentation is provided, I received only an API key and secret. Testing APIs is inherently more challenging, but I eventually discovered the missing YAML file, which unlocked the API's capabilities.

In just ten minutes, I achieved RCE by sending a payload requesting the system's Java version.

Non-Authenticated RCE

Despite achieving RCE quickly, I sought a more elegant solution. By exploiting a different channel, I found I could obtain RCE simply by knowing the API link—no keys or secrets required. This approach took longer, as I had to wait several minutes for responses, but ultimately led to another successful RCE.

Conclusion

Throughout my journey, I encountered multiple significant vulnerabilities in Tesla, such as Administrator Login bypass and API token weaknesses. These findings reflect broader issues prevalent in major corporations.

What sets Tesla and Opinium apart is their failure to recognize a valuable opportunity. The individual they once deemed unfit is now in a position to guide them in strengthening their security measures, all while being compensated significantly more than they had intended. I trust they have gleaned valuable insights from this experience.