I’m not experienced enough to tell the difference between a complicated exploit and a rabbit hole. I’m also studying for the OSCP and success depends on identifying and avoiding rabbit holes. I was hoping some experienced players could offer some rules of thumb for identifying workable vulnerabilities and - most importantly - identifying when to call it quits and try another approach.
I’m not experienced enough, so take my advice with a big grain of salt, but as far as my knowledge goes, enumerating is the answer:
It’s tempting to see a path and take it, it’s harder to find a more complete map and see multiple paths.
Sometimes it seems like a big waste of time to build a complete map if you have a clear opportunity to jump onto, certainly if you see the movies where they almost walk in a straight path to the flags… but I don’t think that’s reality, just entertaining videos (as well as a sane way of teaching things). The straight paths are great to aspire for, but also great to take it with the understanding that they probably spend hours to figure out that narrow path.
Anyway, once we enumerated a more complete map of possibilities, then the depth and time we invest in one path can be compared to all other options we have:
If the path you are on, still seems sane and less time-consuming compared to all other options you have, then follow it.
But question then becomes: when do you step back and invest more time in enumerating, right.
I guess that’s where it becomes an art, more than a science, and where experience starts to play.
In a way: if we know where a path leads to, then you’ll know what options are down the road.
I’m always concerned about trying to find ‘what are the requirements, for an exploit to work?’. As long as you see the requirements fulfilled, it’s a valid path.
And then sometime we’re just stabbing in the dark, at the borders of our knowledge… It’s frustrating, but it’s how we grow, so it’s a good place to be in, if you’re not on a deadline.
I guess what I’m trying to say is that rabbit holes are part of it, ‘wasting time’ as well.
Sometimes the only way to figure out we are wasting time is by following that hole. What could save time, though is from time to time step out of it, look around, enumerate and take the mindset of “what don’t I see?” and look with fresh eyed to the same thing until you see more.
If you looked around with fresh eyed and still don’t see anything else than the one hole you’re in, then dive back in and dig. If it leads to nowhere, it’s just a wake-up call about the fact that we missed stuff in our remuneration (misjudged conditions for an exploit to be valid, misjudged other opportunities)… can be confronting, but that’s just the path to growing and learning… there is no other way to ‘experience’ I’m afraid…
Not sure if it helps, but I hope it may at least inspire you. Good luck with the OSCP!
@gnothiseauton said:
I guess that’s where it becomes an art, more than a science, and where experience starts to play.
This ^^^^.
I dont believe there is a way to automatically detect rabbit holes. You have to be disciplined enough to stop trying something after a certain period of time.
Early on - or if you lack confidence - this is super hard because you genuinely can’t tell the difference between a rabbit hole and not doing the commands properly. After a while you will have the confidence to know that what you are doing is right and the lack of results means rabbit hole.
There isn’t (as far as I can see) and easy answer and experience can be hard earned.
Windows boxes can be a good learning curve here - when you run nmap, you often find dozens of ports open but almost no one bothers with 99% of them. Its just a matter of extending that prioritisation and having the discipline to stop when you aren’t getting anything back.
So, my best suggestion is to make a plan before you start. Decide what things you will do (for example if port 80 is open you run dirb, nikto, wfuzz, visit in a browser whatever) and stick to it. You can always go back if you need to.
You can always de-prioritise some ports, simply because is nearly always impossible to directly exploit (eg. SSH is a nightmare to exploit without other information at the bare minimum).