Posted in Blog, PortSwigger

PortSwigger Web Academy – 09, 10, & Server-Side Wrap-Up

It’s a little hard to believe that I’ve made it through all of the Server-Side topics of the web academy, but so I have. The last two sections were SSRF (server-side request forgery) and XXEi (XML eternal entity injection). Both were good. The SSRF section was a little shorter than I would have liked, but there were bits of SSRF in other places as well. The labs were good and introduced interesting techniques. You do need pro for the last one, but that seems reasonable.

The XXEi section was a bit odd. I did a couple of the labs earlier before doing the rest of the sections. Coming back to the rest now, they made a lot more sense. I like this section being the end of the server-side topics. I think it works well. I do think this section will be very tough if you don’t have any experience with XML. The provided solutions make it doable, but a fair amount of practice would be needed to get comfortable.

So 10 sections in, all the server-side topics down, where does that put me? From a web app pen testing standpoint, do I feel like I could sit down and do an effective pen test from memory? Meh, not without references. I think I could run a basic web app pen test. I know I’m capable of more in-depth testing, but I also recognize there are holes. Probably will fill in some of those in the client-side modules. I feel like I’m recognizing patterns and seeing possible exploits better. This was the deepest dive I’ve taken in some of these areas, which was helpful. I feel like I wanted to really internalize the info, I’d need to take a couple weeks and really focus on just this. Since my goal was more around getting ideas for detections and recognizing malicious activity in logs, I’m not as concerned with that. If I get time, I could apply this to bug bounty programs. Squeezing these in between other trainings (I did the Getting Started in Packet Decoding w/Chris Brenton and Securing the Cloud w/Andrew Krug since the last blog – reviews to come, both were very good), made this less of a priority.

If someone can prioritize these sections and combine it with bug bounty programs, I think they could come a long way very quickly. And that’s with all the client-side topics to go. I’m happy with my order for these – I’d leave XXEi to the end, but I would bump SSRF up compared to where PortSwigger has it.

  • Directory Traversal
  • Information Disclosure
  • Access Control
  • File Upload Vulnerabilities
  • Command Injection
  • Authenticaion
  • SSRF
  • Business Logic Vulnerabilities
  • SQLi
  • XXEi

I think this order builds well to allow someone with little to no experience to get to a decent level of web application pen testing fairly quickly. I would recommend doing them in a more compressed time frame than I have if you can. The content is really good for the most part. There are some gaps in the content that mostly get filled in with the labs (places where there’s a jump in the tactics or skills from the provided material to the labs). For free content put out by a company that isn’t focused on content, I’m good with that. I think if you are lost on how to do a specific lab going to the solutions will at least give you enough information to do more research. For several, just looking at the solutions was a face palm moment where I realized what I was missing. The best part for me was seeing what to look for in logs and getting ideas about ways to monitor. I would like to give the content more attention than I am, but that’s not my priority at the moment.

Posted in Blog, PortSwigger, ProfDev

PortSwigger Web Academy – 08 File Upload Vulnerabilities

This section is basically brand new. It was added after I started the Academy. The section was relatively short with enough labs to get comfortable with the basic concepts. You don’t need to know how to create the web shells yourself, but you should at least be familiar with what they are. The labs give you some practice combining techniques – I think this is incredibly valuable and appreciate when this is included. There is a little practice with ExifTool, which is just a good thing to get familiar with if you’re not already. The race condition lab was pretty cool.

I would put this section 4th so far. I feel fairly comfortable with my order for the server-side content:

  • Directory Traversal
  • Information Disclosure
  • Access Control
  • File Upload Vulnerabilities
  • Command Injection
  • Authentication
  • SSRF
  • Business Logic Vulnerabilities
  • SQLi
  • XXEi

I might switch Authentication and SSRF, but I think Authentication is a more familiar topic to those new to web app pen testing. I’ve got about half of SSRF and 2/3 of XXEi to go, but I think the above order make a lot of sense. I don’t have them ordered in terms of “value” for bug hunting or pen testing, but in the order that I think would build most logically for those just getting started. I think basic technology skills will help you get through the first few sections and provide more gradual build than the PortSwigger order. I don’t have a problem with the PortSwigger, but I think I’m coming at it from a different perspective. The content and labs are excellent, so the order probably isn’t that important. My order is just what I would recommend to people looking to transition into infosec or someone with more of a defensive focus to work on some offensive skills.

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.