Posted in Blog, PortSwigger, ProfDev

PortSwigger Academy – 03 Directory Traversal (Start Here)

Alright first things first, I would bump this to position 1 in the learning path. Why? Lower barrier to entry than the SQLi section (not everyone has done SQL, I think you’d be hard-pressed to find someone who has used a computer but hasn’t navigated through files and directories). The labs in this section were also very straightforward and could be completed with just the information in the content provided. There are also only 4 labs, which makes it easier to build momentum than the SQLi section. I understand starting with SQLi, but right now, I would start with Directory Traversal and then do Command Injection (I’ll touch on that one when I do the takeaways for that section). I may change things as I get through the other sections, and hopefully I’ll remember to put a recommended order up at some point.

I think the biggest takeaway I had from this section was to know where the default locations are for interesting files across operating systems. I remember when I first started looking at infosec stuff wondering about /etc/passwd and how people knew to go there. Coming from a very Windows focused background, that gave me pause. The various team manuals available (Purple Team Field Manual,Blue Team Field Manual, Red Team Field Manual – which has a recent update to be  Red Team Reference Manual) are good places to start. I haven’t dug through all mine to see what the differences are, but I’d get the purple team one to start if I didn’t have any. Just remember those are references NOT how-to books, so they don’t do you a ton of good if you aren’t sure at all what you need. This How To Geek article gives a good Linux overview. Mubix’s post-exploitation-wiki has the important file locations for Windows (and a bunch of other great information).

Otherwise, be sure to look at locations that aren’t necessarily high value – you might not be able to hit gold with /etc/passwd and /etc/shadow, but you might be able to access other locations with valuable info. If you have the Web Application Hacker’s Handbook definitely review the associated section (path traversal). Burp Pro has a really good fuzzing list for directory traversal to automate some things easily. Also check out the OWASP resources. Of course, you should probably just have OWASP bookmarked anyways.

Scripting these labs wasn’t really a necessary thing, but I did anyways. I basically built a very simple fuzzing script by building 1 lab upon the next. I definitely have ideas of how to improve on what I have, but building them out this way way kind of fun and helped me approach the labs in Command Injection more efficiently. It also kind of helped internalize the things to try/look for with Directory Traversal. Being able to store different fuzzing options in Python lists and use them to target specific website parameters is helpful. I’m generally a fan of using available tooling when it works well (like Burp Pro – I’ve seen enough through 4 sections of the learning path that I would recommend finding a way to buy it) because it frees you up to do other things, but the practice on small things like this can help down the line when you need to customize things or want to build your own tools.

Short and sweet section. Fun labs that got the concept across. The entire section could be done with the Community version, but Pro would come in handy for the fuzzing aspect.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Web Academy – 02 Authentication

The authentication section was a lot more comfortable. Lots of enumeration and brute forcing – as should be expected for a section on authentication. And I’ve got more practice in this area, so it was a little more familiar. It probably also helped to have knocked the dust off the web app pen testing stuff a bit with the SQLi section.

Labs were solid. Scripting was good for me to work with sessions and passing cookies and CSRF tokens (my scripts are here – link is to the repo in case I get a wild hair and reorganize). There were also some different techniques than I’ve used previously – passing multiple passwords in a single attempt was interesting. These labs build really well from one to the next in terms of difficulty and expanding on techniques. There were a lot of things that were refreshers about looking for vulnerabilities in authentication – especially things like using really long passwords to help test for time response differences. There were some reminders that you shouldn’t just discount obvious bypasses, like the 2FA simple bypass lab. Testing some common usernames and ones that are very unlikely to exist is a good way to look for response differences. There are enough username and password lists available just on a basic Kali distro to enumerate quite a bit and see what you can see.

Takeaways for me were:

  • Try the obvious stuff like going directly to the desired URL
  • Click and fill in all the things with different types of input (long/short, valid/invalid, etc.)
  • Test likely and highly unlikely input
  • Make an account if possible to explore more functionality
  • Carefully track the authentication flow to craft effective exploits
  • Combination of Burp and Python works well (for me)

I found Python to be more effective for some things than Burp. For instance, the 2FA brute force was a bit better for me using Python because I set an alarm to beep when the correct code was found. I think my Python script and Burp Pro were similar in terms of time – it just kind of depends on when the brute-force and 2FA code match. It was also convenient to set a script to work on enumeration while exploring other things. That could be done with Burp (Pro) or Zap as well, but having the scripts to target specific things was helpful. In a pen testing situation, I can see the utility of kicking off a few things to run while I’m doing other things. I didn’t put a ton of focus into making the scripts completely generic, but the practice of building from basic enumeration with different responses to the 2FA brute force gave me some good ideas about how I might take a generic script and build it out while targeting a specific app.

My general framework for looking for authentication vulnerabilities manually:

  • Carefully note responses on different attempts
  • Attempt login with known incorrect information
  • Attempt login with some likely usernames
  • Test different password lengths to look for potential timing differences and password limitations
  • If blocks or rate limiting are in place, experiment with options to mask IP (like X-Forwarded-For)
  • Carefully examine how data is passed to see how what is submitted can be submitted
    • Is it JSON?
    • What needs to be passed?
    • What can be manipulated?
  • Look for ways that other vulnerabilities can be combined to compromise authentication mechanisms
    • Ex: XSS and X-Forwarded-Host
  • If you can make an account, try different password lengths and strengths to see what complexity requirements exist
    • Is the username an email or something else?

Reviewing/getting familiar with HTTP headers is also critical for web app pen testing. I think this reference from Mozilla is solid and easy to understand.

One of the things I think about a lot when working through labs is “how can this be translated to the real world?”. I think overall the PortSwigger labs are fairly easy to look at and see how an individual lab could be used. And the way that the labs scaffold can help build a roadmap for pen testing. One of the things I’m trying to do (with all of the labs not just authentication) is pay attention to see when the different techniques might be useful (never testing without permission of course) as I’m on different sites/applications. I think asking yourself “what would I do next?” as you go through each lab is also helpful. If we think of it in terms of the typical chain, the next step after gaining additional access is enumeration – so how would you do that? It can be easy when doing labs to get so focused on the solution that you lose the application part.

I also would not necessarily recommend scripting the labs (or all of the labs) to everyone. I’m doing so with a very specific purpose in mind – I want to get better with Python. Is there some utility in terms of potential use for pen testing? Yes, for me perhaps with some bug bounty programs and for someone with a more offensive focus for general usage. Is it forcing me to make sure I understand what’s going on? Yes because scripting it doesn’t let me just point and click through. But if you are already comfortable with Python (or don’t have a need to improve that skillset), I think your time is better spent focusing on the techniques and content within BurpSuite than doing the extra work on scripting.

PS/Side note

Something else I want to mention – my write-ups here are quite informal. I try to not slip too much into technical writing because that’s not my intent here. But if you need to work on your report writing (which is probably all of us), consider presenting your labs as you would a pen test report. Writing for different audiences was something a lot of my students struggled with, and I think taking the time to practice is valuable. Depending on your goals, you may want to consider building out examples of several types of report – executive, technical, etc. to demonstrate how you would change your approach for different stakeholders. Those can also demonstrate some potential/experience when you are job hunting.

Posted in Blog, PortSwigger

PortSwigger Web Academy – What have I gotten myself into? (SQLi)

So I’ve started working on the PortSwigger Web Academy because why not? Well, maybe because I’m (still) working on the IHRP stuff from eLearnSecurity and have started the THP course to help prep for that. Why do web app pentesting stuff? The short answer is because I think it nicely complements what I’m doing. Maybe I’m trying to justify my habit of chasing squirrels, but I’m seeing direct application already of what I’ve learned doing the SQLi section and what I need to do day-to-day. I am focused on the incident response/threat hunting/threat intel side of things, but I believe the info in the Web Academy supports those. It’s giving me ideas for things to look at and valuable hands-on keyboard stuff to go with the more theoretical stuff I’m doing to prep for IHRP.

I hope to script out the labs to get more practice with Python (one of the things I’m working on – those will end up on my GitHub), and I’m planning to make some short notes on here to kind of summarize what I’ve learned and how I’m applying it. The labs are excellent and build well (as in from one lab to the next) for the most part. There are some jumps, but solutions have been provided for every lab I’ve looked at so far. The community solutions are solid too. The community solutions aren’t available on all labs yet, but it looks like Rana Khalil and Michael Sommer are both working on getting labs done. They have different styles, but both are helpful.

Need To Know

The content helps with the labs, but there are sometimes jumps or connections that aren’t presented. Since the solutions are provided, it’s not bad. If you have the Web Application Hackers Handbook, it’s good to have on hand. You will also need Burp Pro to do some of the labs. It’s not cheap, but it’s not terrible. You can do a lot with the free community version, but there are some things you just can’t do with it. It’s also rate limited so some things will be painfully slow. Scripting can help but not completely. Scripting something out can mean it takes minutes instead of hours (and hours) in the Community version though. I’d recommend picking up the Pro version if possible.

Either way, take some time learning about how to use Burp Suite. Definitely tweak the options to set up the fonts and theme to your liking. I find the default fonts a little hard to read. And if you are a keyboard shortcut addict (like me), use the keyboard shortcuts and add your own. My little cheat sheet for keyboard shortcuts is here and includes the ones I’ve added to make my life easier (Burp is toward the bottom – I put everything here because it works for me).

I think someone with little to no technology background could do these, but it would be very frustrating. With the solutions, getting through the labs without knowing what you are doing is possible, but I don’t think that would help with either passing the certification or developing a solid skillset. If someone were to use the content in the Learning Path as a guide, I think you could go from limited skills to a decent set of web app pen testing skills (to use for bug bounties for example). I think supplementation would be necessary.

My General Approach

I try to at least get started on my own, but I go to the solutions after a bit. That’s just the reality of my limited time. I’ll do what I can without looking, but I’m not willing to spend hours tracking stuff down. Initially at least. The good thing about the PortSwigger provided solutions is they are broken into steps so you can unhide to get an idea of where to go next and hide again to see how far you can get with that breadcrumb. The solutions also don’t give exactly what to do (because of variability in the labs), so you can’t just point and click your way through. I used them to work through the first section (SQLi), and then I went back through using the Khalil videos on a couple to improve my understanding. After a few of those, I decided scripting the exploits would force me to understand the process more deeply, so I went that route. Plus Python practice. I do recommend going through the content before the associated lab – that will help quite a bit. If you are experienced pentesting web apps, it might not be worth the time.

My goal is to get the information in an efficient manner, and this approach works well for me. I repeated the labs until I could solve them quickly and consistently to ensure I had the concept down. If I didn’t understand something, I went searching so I understood what was going on. I feel a little bleh about going to the solutions, but I have to prioritize where my time goes. Yes, I’m rationalizing. No, I don’t care. At least not enough to not do it.

SQLi Takeaways

The biggest takeaway is to have a framework/methodology. The labs hint at this by their order and scaffolding. I think the biggest disconnect between the labs and real-life pentesting is the labs told you where to look. Burp Scanner is incredibly helpful, but if you don’t understand how the exploits work, having the payload provided may not be enough. A big bonus of working through this section was getting really familiar with BurpSuite. I’m still not great, but I’m much more comfortable with it than I was. I think that will help make future labs a little bit easier since I’m better with the toolset.

My general framework for checking for SQLi manually:

  1. Poke around and see possible injection points – use Burp Proxy, Inspector, etc. to see where I can mess with things.
  2. Try things that will work for each of the popular database types (Oracle, MySQL, MS, etc.).
  3. Try messing via basic injections like ', '--', ' OR 1=1-- to see if it breaks anything.
  4. Depending on what happens in earlier steps, determine if UNION approach might work, if so try UNION approach.
    1. Try to determine columns using ORDER BY.
    2. See if any columns take text using UNION SELECT null,'a' approach.
  5. If nothing is obvious, try basic blind SQLi attacks.
  6. If still nothing, give the DNS lookup option a shot.

Depending on what you are doing, using a scanner might save you valuable time. But scanners can sometimes be problematic (or too noisy when pen testing). If you use Burp Scanner, make sure you look through the options. The default scan doesn’t take the everything but the kitchen sink approach, so if you have an idea of what to look for, you may want to customize the scan.

I probably won’t be doing a lot of lab explanations/walkthroughs. I think looking at how people approach the problem is helpful, so I might jot down a few notes if I have time, but more than likely, I’ll throw scripts on GitHub (probably with more documentation than is Pythonic) and section reflections here.

Going Forward

How long will it take to finish all the sections? Kind of feel like forever given it’s not my primary focus. But it’s fun and a nice way to shift my focus and wake my brain up a bit. The scripting practice is really good for me.

I would definitely recommend this if you want to get into web-app pentesting. It’s a good way to get practice even if you stick with just the Community version. If you are a staunch blue teamer, it might not be the best use of your time, but I think it’s helpful to switch things up occassionally.

Posted in Blog, Cons

HouSecCon 2021 – D2

It’s nice talking on day 1 so day 2 is more chill. Also incredibly great to have an employer, boss, and colleagues who are like “go conference, we’ve got this under control.”

Session Notes

First up Gregory Pollmann and Chrissy Grove on using identifying/prioritizing using crown jewel analysis. I like the crown jewels approach and repeatable process. Dropping the blog link here because it’s got links to the whitepaper and what not. Good approach that can make it easier to tie things to the business impact.

Then Ross Burke on operationalizing threat intel. Big takeaway here was you have to close the feedback loop so you aren’t just awash in IOCs. And that context matters. CTI can’t be set it and forget it.

The last talk I was able to get to was Clint Bodungen on hacking the cybersecurity workforce. What he talked about for getting started and growing your career are exactly what I’ve done – get involved, be part of the community, be accepting. Also mentioned letting people help you – that’s one I need to work on. I just about fell over when he mentioned getting a job is pretty much SE. Because, yeah, it is.

The rest of the day was talking to people and checking out vendors. There were a few new to me companies there so it was cool to see what they were doing. Caught up with some reps I know (and of course reminded them that helping out the K12 space is a good thing to do). I like checking out what new things are coming up. Yes, some of it is a little snake oil-ish, but even that gets you thinking.

I’m looking forward to talks being posted because there were several I would have liked to hear but couldn’t for various reasons. A huge thank you to Michael, Sam, all the volunteers, and all the sponsors who make HouSecCon happen. The hard work to put on a great conference is appreciated!

Posted in Blog, Cons

HouSecCon 2021 – D1

Day 1 in the books. It was a little odd to be at an in-person function, but it was a good time. I’ll theoretically add links to the videos when they come out.

Quick summary of my day…

Session notes

Opening keynote by Lesley Carhart on IR was jam packed full of tips for making IR hurt less. I’m going to have to watch this one when it’s posted. My biggest takeaway was an ounce of prevention is better than a pound of cure. I think any org looking to get a functional IR plan in place would benefit from watching.

Next for me was Nathan Wenzler on shifting to the cloud. Key points for me were don’t let tools become shelfware and make sure your APIs don’t suck. Also make sure that you are reading the fine print in your agreements. Know your SLAs and who is responsible/accountable for what.

Then Andy Bennett on ransomware. BEC costs more, but ransomware hurts more. One point I really liked was that your communication plan needs to be different for the IR team than for the upper level people. Good reminder. And MFA all the things. ALL THE THINGS.

After lunch was Deborah Watson on MITRE ATT&CkK to reduce risk. I liked the emphasis on risk based controls and the reminder that if it’s someone’s job to open emails and attachments, we really can’t fault them for that. But we need to make it safer. And do you really have controls in place if the majority of the company is excepted form them?

Ricky Allen talked about cyber resilience. I liked the focus on recovery – I do think that part often gets neglected. He highlighted checklists as well. There’s a reason high pressure situations tend to have checklists. We forget things under stress. I’m a big believer in checklists (and documentation).

Then came my talk (Everything’s on fire and I’m not okay – managing priorities and workloads as an army of 1 [or more]), which I think went well, but I’ll also always think could have gone better. It was fun for me at least. Slides and links below. I think we can do better in focusing our priorities and stress levels. I hope people took away that priorities will look different at different places, that finding a way to match your needs for infosec with the needs of the org is a good thing to do, and that work boundaries are good.

My talk stuff

The references