📆 Join Us Every Wednesday at 9:00PM ET (see our latest events on LinkedIn)
1. Know your adversary
In order to defeat them, you need to think like them.
- Where do they feel safest?
- The weakest parts of the chain will always be where they feel safest.
From experience, blue-team will always put more resources into what they feel is risky. On the other hand, if they feel that a component is secure or benign in functionality, they’ll be more lenient with implementing or reviewing security restrictions. Your entry point will most commonly be a corner-case API call or some old, legacy component that’s mostly been forgotten.
- What is the purpose of the application?
- This question helps us identify potential weaknesses or entry points for our attack.
For example, consider an application that’s built to share files between users. Should you test the file share component thoroughly? Absolutely. Should you consider that your primary entry point? Probably not.
Although this is an important component to test, considering it’s the primary purpose of the web application, it’s likely where most of the security controls will be implemented and tested. That’s not to say it’ll be perfectly secure, only that this component is likely to be more secure relative to other components within the application.
- What threat model is their focus?
- If they only account for external threats, there may be little to no protections against internal ones.
Start by thinking about things from the position of the developer. What is this application’s biggest threat? For most web applications, this will be unauthorized users leveraging broken access controls or authorized users attempting to cross-tamper. By contrast, physical devices may only be considering threats at a protocol-level from external attackers. If their developer resources are stretched thin or inexperienced, you may find these are the only areas with adequate controls.
Consider a web application with a primary threat model for unauthenticated and low-privilege users. What happens if an admin account is compromised? Is there a possibility for RCE?
3. Know your tools
How could you possibly attack without a weapon?
- How do I get better with X?
- CTF challenges and competitions.
The best way to learn is to challenge yourself, and there’s no better place to do that than CTF competitions. CTFs are made to practically test your knowledge and push you outside your comfort zone. You’ll learn how to better utilize your tools, refine the testing process, and think outside the box. Even if you’re not interested in competitions, most challenges are published after the event. This gives you free-reign to try it out and, if you do throw in the towel, view the solution write-up from previous participants.
You may never write a pure-JavaScript, asynchronous web server, so this is the perfect place to experience hell on earth.
- When should I use automated tools?
- Whenever needed, as long as they don’t act as a replacement for your own technical knowledge.
Automated tools are meant to ease the burden of testing across a large attack-surface and to exhaust all options against known-affected endpoints.
While these kinds of tools are incredibly useful, they should not exist as a replacement for your own understanding. Nor should they serve as a Hail Mary for applications in production or applications you don’t understand. Again, in order to effectively exploit systems, you must maintain a working knowledge of the underlying technology stack.
Consider yourself a doctor, and manual tampering to be your scalpel. You wouldn’t use an automated jackhammer to operate on a patient, would you?
- What about Y? Why do I need to use X?
- Use whatever makes you happy; you don’t necessarily need to follow the “industry-standard”.
As long as it gets the job done, use whatever tool makes you happy.
That said, you will sometimes be forced to use tools that you’re not accustomed to or just dislike in general. This can be because of your employer, one of your employer’s clients, or otherwise. My advice is to be proficient enough to use them when required, keep an open mind to potentially more-efficient methods, and remember that the tools you use personally are entirely your own preference. In most cases, use of your preferred tool is not a problem.
For instance, I happen to like the Linux text-editor “nano”. Others may prefer its counterpart, “vi”. Is vi technically more efficient? Of course. Do I want to learn all 72,000 keybinds? Absolutely not. I use what makes most sense to me, and I don’t use Linux text-editors enough to benefit from all of vi’s additional functionality. So while it may technically be more efficient, I know the basics, and it’s not an optimal use of my time to learn advanced vi usage.
2. Know their stack
To know your adversary is to understand why, next you need to understand how.
- What kind of protections are in-place?
- This helps us understand the limitations, boundaries, and in some cases, further our potential attack vectors.
By understanding what restrictions are placed on your attacks from the start, exploits can be better crafted to circumvent these security controls. This not only saves time for us, but in the event that such a protection is outdated or vulnerable in itself, we may have yet another attack vector.
- What frameworks are utilized in the application?
- If you understand the framework, you can understand what components are weaker than others, and best focus your efforts.
There are so many advantages to understanding different application frameworks. You’ll know where to check for debug consoles, you’ll know the expected outcome of certain endpoints or operations, you’ll know what components are framework-provided or homebrew. All of these things help us better attack the application with precision, and by dedicating the time to learn, you’re saved countless hours of testing the wrong components in the future. Essentially, you’ll know where the weakest chain is.
- How do the parts fit together?
- While the technology stack can be fundamentally secure on its own, when combined together, there’s always a risk for misconfiguration.
This is where blue-team experience gives a big advantage. By understanding how things should be configured, its easier to pick out when things have been misconfigured. There could be services exposed where they shouldn’t be, there could be services that don’t communicate securely between each other, there could be libraries that are used insecurely.
A common problem under this category is misconfiguration of OAuth. Although the value is named “client secret”, it’s better defined as the “application secret”. Knowledge of this value allows users to forge authentication tokens on behalf of the application, and is commonly exposed in client-side JavaScript code.
4. Know your limits
Humble yourself and realize: you don’t know everything.
- It’s okay to ask for help.
Everyone on your team should want you to succeed. It’s better for you personally and the business as a whole if your skillset expands and your efficiency rises. No one knows everything, and you can’t grow without admitting that.
- Don’t resign from challenging yourself.
Even accidentally, it’s easy to fall into a habit of pushing challenging things away; as humans, we prefer comfort. The trick is to challenge yourself, exhaust your knowledge (within reason), and only then ask for outside help. There are some circumstances where asking for help sooner is better: consider time constraints. Just keep in mind that these are only exceptions to the rule, and should not be the norm.