Intrusion Theory

Whenever possible, we exploit existing gaps.  Failing that, we create gaps.  – Warfighting

As I have been playing in more CTFs, I’ve come to respect time and it’s relation to exploitation.  In the course of a normal engagement, I sort of view my job as a mad scientist.  Testing, playing, researching, poking and fiddling with apps.  By watching behaviors and attributes of the response, the application reveals it’s dark inner secrets.  While this approach is can be very thorough, it tends to be quite slow.  Either way, it doesn’t change the reality that not all vulnerabilities are directly helpful as an intrusion point.

It’s from these games, I have come to believe that intrusion/breach* targets can be roughly placed into two categories: direct and indirect.  Direct vulnerabilities are ones that by finding and attacking can immediately lead to a security breach.  Indirect vulnerabilities, on the other hand, require not only finding and attacking– but require an extra actor to actually realize a breach.  This distinction has little to do with real risk.  It’s only useful for understanding the time and size of feedback loops– and the cycles it takes to actualize an attack.  Direct breach points would always be my preference for intrusion, however indirect breaching is still possible– especially in production environments with real people.  They are also, often far more fun and complex.

If we compared SQL injection and XSS together– I think the concept is pretty easy to understand.  If I found SQL injection on a box, I can directly attack the box and either exfiltrate data or maybe get a shell on it.  With XSS (reflected or persistant) however, even if I found the vulnerability– I still need to find a way to target someone of appropriate privilege to trigger my attack and bypass security measures.  This would be where some spearfishing or other such attacks are of value**.

I was working on a list for myself, but so far it includes:

Direct Intrusion points:

  • SQL Injection
  • Command Injection
  • Directory Traversal
  • Local and Remote File Inclusion
  • Unpatched remote exploits of a framework / OS / 3rd party application
  • 0-day remote exploits of a framework / OS / 3rd party application

Indirection Intrusion points:

  • XSS
  • Lack of SSL
  • CSRF
  • Insecure Session Generation
  • Insecure Password Policies (lack of passwords, brute force prevention)

Business rule violations could be either indirect or direct points of intrusion.  Though this gets kind of muddy here.  Is it really a breach if no security exists?  Sometimes the ability to guess additional functionality will lead to further insight / detail of the application which I could use for other attacks– but isn’t directly an intrusion point.  Whereas, sometimes simply guessing might give me exactly what I was looking for (such as a database.db.bak).

It’s also worth noting that some direct points of intrusion might not always lead to a direct breach of the box or system.  Finding SQL injection might just lead toward giving me extra insight into how the app was built– but it might not be the target or goal I wanted to achieve.  I could just as plausibly use SQLi to create an XSS attack that lets me take over accounts, or an XSS based attack that lets me reach a parameter in another parts of the application I don’t have access to for SQLi.

Being able to consider targets in this way, I personally am finding it useful in engagements and games where time is important.  If I want a better pace, I should target the things which would give me the greatest gains.  Again, that isn’t to say that indirect targets are not of value– I consider them to be just as valid as an attack vector, and almost always the glue that allows for greater exploitation.


* When I say breach I mean it in the literal technical sense.  When cops/military rip open a door to a home, that is a breach.

** One of my favorite ideas for this is creating and account with persistant XSS– then trashing the system until an Admin needs to unlock my account.  Especially when the account needs to be manually unlocked on a web-page.

Post a comment or leave a trackback: Trackback URL.


  • cktricky  On July 9, 2011 at 3:51 am

    It sounds like what you are saying is that the methodology chosen is largely based on scoping of the assessment or penetration test that you are performing. My question is, do you see more value in one type of test over the other?

    • pinvoke  On July 9, 2011 at 4:18 am

      Depends on who is benefiting from the value. 🙂

      The technical answer is really “it depends on the client”, because each client is going to be in a different place. Knowing when to apply either of these is the trick to really helping people out. Tests are tools, not an ends in and of themselves. As a well rounded tester I should be able to preform both of them very well.

      That said, my gut says a penetration test is more valuable in the sense that everything points back to it. Ideally when I am doing a test (penetration or assessment) I shouldn’t ever lose sight of how people might attack this and I should try and operate as closely as I can to that. It will help me prioritize my tasks, and actually understand the risks I apply to things. It will also give the proper perspective about what constitutes a real fix.

      Having experience breaking into something must be at the heart of a testers perspective. Reducing defects in a product and telling them to patch will only get the so far– and it doesn’t preclude it’s “secure.” Being able to demonstrate that is a skill ever tester should have, assessment or otherwise.

  • cktricky  On July 9, 2011 at 6:58 am

    So I would say that a penetration test and assessment should be differentiated. Personally, and I am not sure if this is what you meant, an assessment where credentials, directory listings what not can help immensely within a short window of time. From my perspective, having those takes it from a penetration test to an assessment. But I totally agree that while performing that assessment (which I find to be of more value than a penetration test within a time-boxed scenario) we should keep our perspective as that of an attacker.

    Again, like your article a lot and the organization. Hopefully you’ll share more of that list when ready 🙂

  • CG  On July 10, 2011 at 3:37 am

    nice article andrew, i ❤ appsec guys that get the idea of using those vulns to put a foot in the ass of that network/company/CTF

    on the password thing, you may want to add flavors of insecure password resets to the direct attack section. if i can guess the reset question without requiring an email i can directly use that to break into the app, or at least get user access.

    • pinvoke  On July 10, 2011 at 4:27 am

      Good points.

      I think the reason I put insecure password as indirect is because of causality. That is, if a system allows for horrible passwords an end user still till has to set one for it to be attacked. It’s plausible (though unlikely) that all of the users could create excellent passwords despite the policy. Same is kinda true for password reset. Now, if password reset is totally broken (like ones where I’ve been able to control the email address the reset link goes to…) I can see that being a direct attack.

      I will flesh this out some more, as I’ve been coupling this with targeted information gathering approaches. How to identify areas that may be weak to critical vulnerabilities quicker than trying to absorb the whole app and it’s complexity.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: