I'm fortunate to be a member of many communities online. And, the cybersecurity industry is one in which the more seasoned veterans are willing and able to help and assist newcomers. It's a wondrous and encouraging thing, and I've seen it time and time again. In participating in these communities, I oftentimes observe newcomers (particularly those new to application security) take a vulnerability-first approach.
They'll ask questions like:
- "What is XSS and how do I find it?"
- "What is SQLi?"
- "How do I bypass MFA?"
- and more.
At first glance, there's nothing wrong with these questions. These are important vulnerabilities and it's important to know what they are and how to find them. In fact, one might argue that this is foundational, the first-steps on the journey, and many practice labs/arenas/challenges focus on a vulnerability-first approach. Yet, due to the ingenuity of the human imagination and the time-constraints of challenge builders, the learning materials often only present specific variations of vulnerabilities intended to be found. They cannot reflect the infinite number of variations seen in real systems.
Inevitably, newcomers often focus on specific vulnerabilities or classes of vulnerabilities but lack the tools to go deeper and more complex. And, because of this, vulnerability-first approaches kind of miss the mark. It's equivalent to starting at the tip of the iceberg, missing the mass lurking below the surface.
A better way
Just as Honest Abe noted about chopping down a tree, you need the right tools. Similarly, if you want to find more complex and higher-risk bugs, you need to be better prepared with the right tools. Within cybersecurity, we like our tool, but there's no greater tool than your understanding of the system/application you're assessing. Taking the time to first understand the application/system as it was built - not as it should be, but as it is - gives you a foundation to begin looking for discrepancies that may be exploited.
I've told this story before, but, when I was very new to application security, I had never assessed a .NET multi-factor implementation. I was familiar with types of vulnerabilities in authentication processes, and had even done the labs where you could use SQLi to bypass authentication controls. I knew there was distinct possibility that, if I was handed a MFA process, I might be able to find some things wrong but there could be something big I'd miss.
So, my team had me go build a basic .NET application, shred it to pieces, and then report back on my findings. This app had no multi-factor; my goal was simply to understand how .NET authentication works "out-of-the-box". I looked at session management, password policy criteria, how users register, etc. My goal was simply to understand.
In the next assessment I performed, I was given a .NET app that had - you guessed it - MFA added to it. Now, because I had an understanding of .NET "out-of-the-box" authentication, I was better prepared to note where things just didn't feel right. There were deviations from the baseline, and my spidey-sense was attuned to pick up on those deviations. By the time the assessment was complete, I had found multiple distinct avenues of compromising the MFA process. All because I started with trying to understand the framework and application first, and then worried about vulnerabilities after that.
Application-first
What do application-first approaches look like? Considering I'm an app pentester, the following examples take an application slant, but the principles apply to networks as well. Let's take authentication. If you want to find authentication bypass, instead of asking "How can I bypass MFA?" or immediately inserting '-- into the username field, first take the time to really understand how the authentication process works. Application-first questions may be:
- How does the application determine who you are? (How does it know you from Bob?)
- How does a user move from unauthenticated to authenticated?
- If self-registration is present within an application, is there a difference between a first time login after self-registration versus any other login attempt?
Or, alternatively, let's say you're taking a look at output encoding vulnerabilities. Instead of asking "Where is XSS in this application?" or dropping a script tag in every field, try asking application-first questions.
- How does the application perform output encoding?
- What are the contexts at work within any given page?
- What client-side functions are in use and are any of them using vulnerable sinks?
One more. Let's say you want to find privilege escalation. This is a high-risk issue in any network or application.
- Have you investigated how the application or server makes its authorization determinations?
- What permissions does a high-level user have that a low-level user doesn't?
- Are page-level, feature-level, and role-based controls enforced consistently and comprehensively?
These questions and more take an application-first approach. They approach a system seeking to first understand how it is operating, the controls/processes/flows in use - before looking for a vulnerability. Once you know how the application works, you are better prepared to look for, find, and exploit more complex vulnerabilities because they start to stick out like a sore thumb.
Sharpening your axe
So how do you sharpen your axe? Particularly in appsec, the best way is to build web apps. Building your own app gives you a great understanding of how apps are put together. Going back to the above example, let's say you want to know how to better assess .NET applications.
- Go to https://dotnet.microsoft.com/learn/aspnet, pick a tutorial and follow it through. This MVC movie app is pretty good.
- With the application built, connect a proxy to it and examine the calls going back and forth. I particularly like BurpSuite, but you can use OWASP ZAP, Fiddler, or something else. At this point, you're not hacking, just observing.
- Start asking questions about the authentication, the authorization, session management, encoding, etc. The how's and why's become critical here.
- How does a user authenticate?
- Why is the flow designed this way?
- How does the app know you're a low-level user and not an admin? Or vice versa.
- When you make a selection on a page, how does the server know you made the edit?
- Etc.
Once you feel like you know the answers to these questions, you've now covered your "use" cases. Put on your hacker hat and start exercising the "abuse" cases. What happens if you...
- ...skip steps of the authentication process?
- ...revisit steps out of order?
- ...force cookies to be a certain value?
- ...change that POST parameter to be something other than what you selected or that's an option for you?
And this is the general method. Want to get better at looking for and exploiting MFA bypasses .NET? Add MFA to the login flow of your .NET and take a crack at it. Privilege escalation? Add a restricted section that only an admin should be able to get to and analyze it with a low-level user. This same method/thought process works for Angular, React, or application technologies such as OAuth, SSO, blockchain, etc.
It also can be applied on the network-side. Want to get better at pivoting? Deploy multiple VMs on your host, establish a subnet between them and try your hand at using proxychains. Active Directory got you down? Deploy a virtualized Windows Server with AD, add some users, and start exploring how this technology is supposed to be used. The better you are at understanding a technology, its intended use cases, and the way it was designed to be deployed the better you will be at identifying when deployments have deviated from the intended path.
Ultimately, this comes down to trying to truly understand the application/technology/system you're assessing. If you take the time to sharpen your understanding, you'll be on your way to finding deep and complex bugs in no time.
0 comments:
Post a Comment