HackTheCTO (and Prelude)
HackTheCTO (and Prelude)
The First Task When Entering the Prelude Security Team
I recently joined Prelude as a Security Engineer. Just like the previous article written by @Xanthonus, one of the first taskings you get when joining the company is called "HackTheCTO".
Previously this was mostly scoped towards our CTO @privateducky, but recently it was expanded to pentesting our company infrastructure. You get two weeks to do this, which might seem like a long time, but is quite short since a lot of the time is spent learning and understanding the architecture of our Operator product. This is a great task for new hires, since not only is the new member orientating themselves to the infrastructure, but it allows a new pair of eyes to look over everything and find out any vulnerabilities that may have been overlooked in the past.
I would have liked to spend more time targeting our CTO, but I ended up focusing a lot of my effort on testing the APIs which Operator communicates over. As many of us in the security sector enjoy our privacy, I will be going over my methodology and less details about my findings.
DISCLAIMER: This information should not be used for unlawful tracking or stalking. I was given permission to do this research, doing something like this without permission might land you in a bad place.
The CTO
Thanks to @Xanthonus' previous post, I thought I would pick up where he left off. One of the goals on my list was to narrow down a particular birth date, since @Xanthonus had found the month and year. I've had some experience with tracking people, so when I do this kind of research, I start off by scoping the information to specific identifiers, these identifiers are then combined to build a persona, which can then be further exploited to build a detailed profile of the individual. My workflow follows along these lines:
Methodology
Step 1: Research specific identifiers.
An identifier can be anything that is/might be associated with the current target. When the target is a person, it often starts with their name. If the target was a business, then it would often start with an address (website or physical). From there you start utilizing search engines to find other associated identifiers. Often these identifiers are email addresses, screen names, telephone numbers, etc... The main things you want to focus on for each identifier are the oldest date and most recent date. Dates are a significant role since they allow you to filter out any red herrings. Once you have all these identifiers, you want to start building a persona.
Step 2: Modeling a Persona
The important thing to know about a persona is that it may or may not be an actual representation of the person; there are often multiple personas that an individual might have online. An example of this is a professional vs personal persona, you should treat these as individual personas at this stage. Security minded folks may create false personas online, just to make it more difficult for someone researching (cough David cough). This is where you might have to go back to step one and find some additional identifiers for family members. It is good to keep an eye out for conflicting information between a target and family members. If a sibling is close in age, then it might be beneficial to follow their persona to glean information from their identifiers. If you start getting dates (especially birth dates) that you want to ensure are correct, then a voter registration website can be extremely helpful.
Step 3: Build a Profile
This is where you build a summary of the individual. You drop any false information that the personas might have contained, and you cross reference between all the personas to narrow down specific dates and life events. Your goal is to have enough information that would allow the person to be a main character in a story. Pictures can go a long way in ensuring you have the right target, so finding pictures of the individual throughout their lifetime is extremely helpful.
Final Step: Malicious Intent
So, this is where the bad guys eventually end up, what can they do with all this information? Depending on the overarching goal of the targeting that just took place, there are two common pathways. Phishing and Identity Theft, both of which require some social engineering. On the phishing side, not only do you need to identify the bait, but also the target. Depending on the information from the previous steps, it might be better to exploit one of the relationships between the target instead of the target themself. On the identify theft front, depending on the amount of information collected, the next step would be to make it official. Requesting a birth certificate or marriage certificate from one of the many online repositories (local county or state offices) is a good start.
The CTO's story:
David ++++ Hunt was born on ++++++++ to the parents, +++++. He is the +++ child and has ++++ +++++ +++++ (runs the ++++++++) and +++. Some sources of information mention hometowns and birthplaces located in ++++++++ and +++++++++, though after researching it would lead me to believe that David was born in ++++++, as ++++++++ seemed to have addresses there during +++++. He lived in +++++, ++++++, +++++, ++++++++, +++++++, and ++++++. He met his wife +++++++ around ++++++ while living in +++++++ and got married in +++++++ on +++++++. He has ++++++++++++ born around +++++++.
The Pentest
Most of my time was spent orientating myself within our infrastructure. After looking through all the bells and whistles, I decided focusing on API calls would be best. I found a couple of things, but once again I am going to concentrate on the methodology and not the findings. Blackbox web pentesting can be a pain and often relies on the fuzzer more than the pentester, so having the source code is a pleasant change of pace. Here is my workflow for a whitebox API pentest, following the OODA loop as mentioned in the most recent Prelude podcast.
Methodology
Observe:
1. Use the product.
If you don't understand how the product is used and its normal behavior, you will miss things that are not found in code (i.e. business logic errors).
2. Read/Scan all company written source code (you can skip standard libraries or well-known libraries at this point, but make sure you circle back when you have time to find log4j😁).
Orient:
1. Understand the interactions between different modules and the user side application.
2. Find functionality in the source code that a user can affect. (This is done by identifying parameters/variables that change based on who/what is calling it)
Decide:
1. Sort these identified functions by usefulness. (Writing to a database or filesystem and Reading from a database or filesystem are always useful)
2. Trace code paths. (To help with this most IDE's have the functionality to right click a function and "find references to." Make sure you don’t lose track of the user affected parameter/variable, throughout the call stack)
3. Hypothesize interactions that could lead to abnormal activity. (Remember, you are looking for anything a program is NOT supposed to do; just because you don’t think it is exploitable, doesn’t mean it is not exploitable.)
Act:
1. Test your hypothesis.
2. TEST YOUR HYPOTHESIS!
You know how they say, "a picture is worth 1,000 words", well my saying is "a POC (Proof-Of-Concept) is worth 10,000 words". I often see something like "we couldn't do this, but someone could" in penetration test reports. Don't get me wrong, "threat modeling" has its place in pentesting. Most pentest engagements are way too short, but as a pentester you should always attempt to write a quick POC to give credence to your hypothesis.
Takeaways:
Going after our CTO was quite the task, he does an excellent job of keeping the attackable surface area to a minimum. It makes me wonder what I can find about myself, though after the OPM hack I am certain most of my information is already out in the wild. As for the pentest, I did get some ideas for some new Operator chains that focus on web APIs, I am hoping I can add those soon!