This blog post is a more general one than my usual posts. I'll try and cover two things; an SSRF bug in an API, and a cool productivity system I use.
SSRF with Secondary Context Path Traversal
This writeup presents another thing to test for when you have a full-or-partial-read SSRF. It's an interesting case that I recently encountered during an in-person collaboration with bendtheory while I was visiting him in the US. I won't go into detail about this bug to preserve the anonymity of the program.
I will assume for brevity's sake that you're already familiar with SSRF and the different types of SSRF. I introduce you to the lesser-known Secondary Context Path Traversal, courtesy of Sam Curry. I would recommend reading that article - in the modern web landscape, it's a very useful tool to have in your arsenal.
In the particular case I encountered, I could perform SSRF, and set the headers and body but not the domain. I could navigate to a variety of internal routes using certain keywords in the request instead. I could also specify the path. Setting the
Host header in the SSRF allowed me to switch between internal virtual hosts.
Combining this with path traversal in the
path parameter allowed me to climb out of the internal routing, and from that point I could explore the virtual hosts with a greater degree of freedom (rather than being limited to the aforementioned keywords). It was also possible to observe where exactly you were in the path by triggering errors (which, in some cases, also leaked the type of software in use). So, this was effectively a controllable secondary context path traversal.
From a technical standpoint, this was really interesting to test. Modern proxy configurations have their own interesting attack vectors that are always worth exploring. In the event that you have some type of read SSRF (such as via webhook testing functionality), I would recommend testing for this.
The next topic I'd like to discuss is productivity systems. This one is for you productivity geeks out there. Generally speaking, productivity systems have two resources that must be managed together; tasks and time, which must be managed as efficiently and as seamlessly as possible.
While frameworks like PARA are good for organising tasks, they don't consider the individual. Instead, I will advocate for a more Taoist approach to task management, that accounts for how your brain is feeling on a given day.
My old boss once said, "people will always revert to their nature". Whether you agree or disagree with this statement, the intent behind it is that you shouldn't fight the flow of life, or the fundamental state of your being.
So, in this sense, we introduce another question; are you capable of coherent thought? Is your brain working properly today?
We can subdivide our projects into the tasks that require a functioning brain cell, and the tasks that do not.
To prioritise tasks in this system, we maintain two lists:
- Yes Brain: the priority-list of tasks that require a functioning brain cell
- No Brain: the priority-list of tasks that do not require a functioning brain cell
I'm not saying that you should ignore high-effort critical tasks. I'm not advocating for laziness. There's an important distinction between being lazy, and doing the tasks that suit your current energy levels.
Fighting your "flow" (forcing yourself to do tasks when you're not in the right frame of mind) causes burnout. Do the tasks from the "Yes Brain" section when you're motivated, and the "No Brain" section when you're not. If your mood changes during the day, we can even schedule tasks accordingly, thus maximising your energy consumption efficiency, regardless of your current state. A few hours of "No Brain" isn't a waste of time. It's just an opportunity to do less intensive things. You need not limit yourself to just two stages of awakeness either. Sometimes my eyes get tired so I'll listen to something instead. And so on.
My girlfriend originally developed this "Yes Brain / No Brain" system to choose which book to read, and she visualised it in quadrants / grids. I've just developed it to the general case and introduced priority and scheduling.
“He will win, who knows when to fight and when not to fight." - Sun Tzu
If someone else has created this type of system before, I would be happy to cite them if you ping me on Twitter about it.
If anyone wants to collaborate in-person, I will be travelling a lot this summer.
- Turkey (July 10th-17th)
- Las Vegas (August 2nd-15th, for H1-702 and Def Con)
- Milan, Bern, Frankfurt, Hamburg, Copenhagen (August 21st-28th)
- Singapore (September 24-25, for BountyCon)
So, reach out to me on Twitter if you want to hang out.